RFC Errata
Found 10 records.
Status: Verified (3)
RFC 8466, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", October 2018
Source of RFC: l2sm (ops)
Errata ID: 5615
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-01-28
Verifier Name: Ignas Bagdonas
Date Verified: 2019-07-09
Section 5.10.1 says:
The svc-bandwidth parameter must include a "cos-id" parameter if the "type" is set to "bw-per-cos". The cos-id can be assigned based on either (1) the IEEE 802.1p value [IEEE-802-1D] in the C-tag or (2) the Differentiated Services Code Point (DSCP) in the Ethernet frame header. Service frames are metered against the bandwidth profile based on the cos-id.
It should say:
The svc-bandwidth parameter must include a "cos-id" parameter if the "type" is set to "bw-per-cos". The cos-id can be assigned based on either (1) the IEEE 802.1p value [IEEE-802-1D] in the C-tag or (2) the Differentiated Services Code Point (DSCP) in the IP header. Service frames are metered against the bandwidth profile based on the cos-id.
Notes:
The DSCP field is part of the IP packet header, not the Ethernet frame руфвук.
Errata ID: 6922
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2022-04-05
Verifier Name: Rob Wilton
Date Verified: 2023-10-02
Section 5.5.2.1 says:
...
<network-access-id>LA1</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
...
<network-access-id>LA2</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
It should say:
...
<network-access-id>LA1</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cos-id>10</cos-id>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
...
<network-access-id>LA2</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cos-id>10</cos-id>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
Notes:
The cos-id must be included when the bandwidth type is set to "bw-per-cos".
Errata ID: 6683
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2021-09-14
Verifier Name: Robert Wilton
Date Verified: 2024-01-12
Section 5.10.2.1 says:
QoS classification rules are handled by "qos-classification-policy". qos-classification-policy is an ordered list of rules that match a flow or application and set the appropriate target CoS (target-class-id). The user can define the match using a more specific flow definition (based on Layer 2 source and destination MAC addresses, cos, dscp, cos-id, color-id, etc.). A "color-id" will be assigned to a service frame to identify its QoS profile conformance. A service frame is "green" if it is conformant with the "committed" rate of the bandwidth profile. A service frame is "yellow" if it exceeds the "committed" rate but is conformant with the "excess" rate of the bandwidth profile. Finally, a service frame is "red" if it is conformant with neither the "committed" rate nor the "excess" rate of the bandwidth profile.
It should say:
QoS classification rules are handled by "qos-classification-policy". qos-classification-policy is an ordered list of rules that match a flow or application and set the appropriate target CoS (target-class-id). The user can define the match using a more specific flow definition (based on Layer 2 source and destination MAC addresses, dscp, color-type, etc.). A "color-type" will be assigned to a service frame to identify its QoS profile conformance. A service frame is "green" if it is conformant with the "committed" rate of the bandwidth profile. A service frame is "yellow" if it exceeds the "committed" rate but is conformant with the "excess" rate of the bandwidth profile. Finally, a service frame is "red" if it is conformant with neither the "committed" rate nor the "excess" rate of the bandwidth profile.
Notes:
There is no "color-id" under "qos-classification-policy". The text should refer to "color-type" given that the "qos-classification-policy" substree is as follows:
+--rw service
| +--rw qos {qos}?
| | +--rw qos-classification-policy
| | | +--rw rule* [id]
| | | +--rw id string
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw match-flow
| | | | | +--rw dscp? inet:dscp
| | | | | +--rw dot1q? uint16
| | | | | +--rw pcp? uint8
| | | | | +--rw src-mac? yang:mac-address
| | | | | +--rw dst-mac? yang:mac-address
| | | | | +--rw color-type? identityref
| | | | | +--rw target-sites*
| | | | | | svc-id {target-sites}?
| | | | | +--rw any? empty
| | | | | +--rw vpn-id? svc-id
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
The same applies for "cos" and "cos-id".
The corrected text uses "color-type" instead of "color-id" and removes "cos" and "cos-id" from the flow definition examples.
Status: Held for Document Update (6)
RFC 8466, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", October 2018
Source of RFC: l2sm (ops)
Errata ID: 5921
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2019-11-27
Held for Document Update by: Robert Wilton
Date Held: 2024-01-12
Section 8 says:
identity vpws-evpn {
base service-type;
description
"VPWS service type using Ethernet VPNs (EVPNs)
as specified in RFC 7432.";
identity pbb-evpn {
base service-type;
description
"Provider Backbone Bridge (PBB) service type using
EVPNs as specified in RFC 7432.";
}
It should say:
identity vpws-evpn {
base service-type;
description
"VPWS service type using Ethernet VPNs (EVPNs)
as specified in RFC 8214.";
identity pbb-evpn {
base service-type;
description
"Provider Backbone Bridge (PBB) service type using
EVPNs as specified in RFC 7623.";
}
Notes:
Neither VPWS-EVPN nor PBB-EVPN are mentioned in RFC 7432.
The former is defined in RFC 8214, and the latter - in RFC 7623.
Please note also that RFC 7623 is not mentioned as one of the references.
AD Note: I agree with this errata, but given the change is within a YANG module, it needs a new revision of that YANG module to be published. Hence, I've moved this errata to "Held for Document Update".
Errata ID: 5922
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2019-11-27
Held for Document Update by: Robert Wilton
Date Held: 2024-01-12
Section 8 says:
identity bgp-vpls {
base service-type;
description
"BGP-based multipoint VPLS service type. This VPLS uses a
BGP control plane as described in RFCs 4761 and 6624.";
}
identity vpws-evpn {
base service-type;
description
"VPWS service type using Ethernet VPNs (EVPNs)
as specified in RFC 7432.";
}
It should say:
identity bgp-vpls {
base service-type;
description
"BGP-based multipoint VPLS service type. This VPLS uses a
BGP control plane as described in RFCs 4761 and 6624.";
}
identity evpn {
base service-type;
description
" EVPN service type as specified in RFC 7432"
}
identity vpws-evpn {
base service-type;
description
"VPWS service type using Ethernet VPNs (EVPNs)
as specified in RFC 7432.";
}
Notes:
The service type for an EVPN service as defined in RFC 7432 is missing.
It seems likely that a standalone EVPN identity should have been defined, but that cannot be fixed using the errata process. It requires a new version of the YANG module to be published, hence I've moved this to errata report to "Held for Document Update".
Errata ID: 6383
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Lucek
Date Reported: 2021-01-08
Held for Document Update by: Rob Wilton
Date Held: 2023-10-02
Section 8 says:
container service {
container svc-bandwidth {
if-feature "input-bw";
list bandwidth {
key "direction type";
leaf direction {
type identityref {
base bw-direction;
}
description
"Indicates the bandwidth direction. It can be
the bandwidth download direction from the SP to
the site or the bandwidth upload direction from
the site to the SP.";
}
Notes:
The svc-bandwidth container is triggered by if-feature "input-bw". However, that container can contain input-bw only, output-bw only or both. It might be better to have two separate containers, one for input-bw and the other for output-bw, triggered by if-feature "input-bw" and if-feature "output-bw" respectively.
The bug looks to be valid, but this erratum has been marked as "Hold For Document Update" because further discussion is required as to the solution, and it will require a new revision of the YANG module which will require a new RFC to be published.
Errata ID: 6699
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2021-10-01
Held for Document Update by: Rob Wilton
Date Held: 2023-10-02
Section 8 says:
container lacp {
if-feature "lacp";
leaf enabled {
type boolean;
default "false";
description
"LACP on/off. By default, LACP is disabled.";
}
leaf mode {
type neg-mode;
description
"LACP mode. LACP modes have active mode and
passive mode ('false'). 'Active mode' means
initiating the auto-speed negotiation and
trying to form an Ethernet channel with the
other end. 'Passive mode' means not initiating
the negotiation but responding to LACP packets
initiated by the other end (e.g., full duplex
or half duplex).";
}
It should say:
container lacp {
if-feature "lacp";
leaf enabled {
type boolean;
default "false";
description
"LACP on/off. By default, LACP is disabled.";
}
leaf mode {
type identityref {
base lacp-mode;
}
description
"LACP mode. LACP modes have active mode and
passive mode ('false'). 'Active mode' means
initiating the auto-speed negotiation and
trying to form an Ethernet channel with the
other end. 'Passive mode' means not initiating
the negotiation but responding to LACP packets
initiated by the other end (e.g., full duplex
or half duplex).";
}
Also, make this change:
OLD:
| +--rw lag-interfaces {lag-interface}?
| | +--rw lag-interface* [index]
| | +--rw index string
| | +--rw lacp {lacp}?
| | +--rw enabled? boolean
| | +--rw mode? neg-mode
NEW:
| +--rw lag-interfaces {lag-interface}?
| | +--rw lag-interface* [index]
| | +--rw index string
| | +--rw lacp {lacp}?
| | +--rw enabled? boolean
| | +--rw mode? identityref
Notes:
The LACP mode can be set to active or passive, which is not what neg-mode is supposed to cover. lacp-mode identity should be used, instead.
The errata looks valid, but given this requires a new revision of the YANG module a new RFC needs to be published.
Errata ID: 6555
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2021-04-23
Held for Document Update by: Robert Wilton
Date Held: 2024-01-12
Section 8 says:
container vxlan {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:vxlan')" {
description
"Only applies when the type of the tagged
interface is 'vxlan'.";
}
if-feature "vxlan";
leaf vni-id {
type uint32;
mandatory true;
description
"VXLAN Network Identifier (VNI).";
}
leaf peer-mode {
type identityref {
base vxlan-peer-mode;
}
default "static-mode";
description
"Specifies the VXLAN access mode. By default,
the peer mode is set to 'static-mode'.";
}
list peer-list {
key "peer-ip";
leaf peer-ip {
type inet:ip-address;
description
"Peer IP.";
}
description
"List of peer IP addresses.";
}
description
"QinQ.";
}
It should say:
container vxlan {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:vxlan')" {
description
"Only applies when the type of the tagged
interface is 'vxlan'.";
}
if-feature "vxlan";
leaf vni-id {
type uint32;
mandatory true;
description
"VXLAN Network Identifier (VNI).";
}
leaf peer-mode {
type identityref {
base vxlan-peer-mode;
}
default "static-mode";
description
"Specifies the VXLAN access mode. By default,
the peer mode is set to 'static-mode'.";
}
list peer-list {
key "peer-ip";
leaf peer-ip {
type inet:ip-address;
description
"Peer IP.";
}
description
"List of peer IP addresses.";
}
description
"Container for VXLAN.";
}
Notes:
The description should refer to VXLAN not QinQ.
AD Note: This errata is correct, but YANG modules cannot be fixed as part of the errata process. A new YANG module revision needs to be published so I have put this errata into "Held for Document Update" state.
Errata ID: 6703
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2021-10-05
Held for Document Update by: Rob Wilton
Date Held: 2022-05-19
Section 8 says:
leaf pbs {
type uint64;
units "bps";
description
"Peak Burst Size. It is measured in bytes per
second.";
}
It should say:
leaf pbs {
type uint64;
units "Bytes per Second";
description
"Peak Burst Size.";
}
Notes:
There is a mismatch between the units statement and the description text.
The corrected text assumes that the description reflects the intent. This is the meaning assumed in draft-ietf-opsawg-l2nm
Status: Rejected (1)
RFC 8466, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", October 2018
Source of RFC: l2sm (ops)
Errata ID: 6384
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Lucek
Date Reported: 2021-01-08
Rejected by: Robert Wilton
Date Rejected: 2024-01-12
Section 8 says:
identity pbb-evpn {
base service-type;
description
"Provider Backbone Bridge (PBB) service type using
EVPNs as specified in RFC 7432.";
}
It should say:
identity evpn {
base service-type;
description
"EVPN service type as specified in RFC 7432.";
}
Notes:
The mention of PBB is a mistake, it should be normal (non-PBB) EVPN, given that Section 3.1 lists EVPN and not PBB-EVPN among the supported L2VPN types. However, the reference to RFC 7432 in the original text box above is correct, as that RFC deals with EVPN, not PBB-EVPN.
(n.b. see erratum 5921 that has the "opposite" interpretation, i.e. that pbb-evpn is correct but that the RFC number is wrong)
--VERIFIER NOTES--
I think that this errata report can be regarded as a duplicate of 5922, that I have resolved as "held for document update". Certainly, I don't think that it is possible to infer consensus that the YANG module is wrong by defining pbb-evpn but the accompanying text is correct.