Hi Tom, I think this is the very reason for this errata. Type 6 RD does not exist.
Authors of RFC8294 just made it up and no one spotted it during the entire review process before publication :) Interestingly enough it appears between versions -08 and -09 of the draft. Version 08 - No RD type 6 - https://datatracker.ietf.org/doc/draft-ietf-rtgwg-routing-types/08/ Version 09 uploaded by Acee on 2017-08-19 RD type 6 is here - https://datatracker.ietf.org/doc/draft-ietf-rtgwg-routing-types/09/ Now the fun starts .... The diff mainly focuses on addition of BGP/MPLS Ethernet VPNs as specified in RFC7432. However in this RFC there is no mention of new RT or RD formats. But the diff between -08 and -09 reveles this additions: So the -09 version is adding non-existent type 6 not only to RD, but also to Route-Target - there is no such thing. typedef route-target { type string { pattern '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|' ...... and RFC7432, the encoding pattern is defined as: 0:2-octet-asn:4-octet-number 1:4-octet-ipv4addr:2-octet-number 2:4-octet-asn:2-octet-number. 6:6-octet-mac-address. The new type 6 was then copy and pasted into RD Most likely the RT confusion came from mixing RT extended community with general Extended Community Types where indeed type 6 exists and is even relevant to EVPN: 0x06 EVPN (Sub-Types are defined in the "EVPN Extended Community Sub-Types" registry) [RFC7153 <https://www.iana.org/go/rfc7153>] But this is not the end :) The copy and paste continues and we now see addition of type 6 also to route-origin extended community ... which again does not exist. Finally the definitions of RT says: A route target consists of two or three fields: a 2-octet type field, an administrator field, and, optionally, an assigned number field. 2 octet type fields are not really the case neither for Route Target nor Route Origin Extended communities. So really even types 0, 1 or 2 there do not really exist. It looks to me like this RFC8294 requires to be "suspended" and new major surgery done on it with -bis posting replacing all text against all definitions of extended communities present in it. Cheers, Robert On Sat, Nov 19, 2022 at 1:17 PM t petch <[email protected]> wrote: > On 18/11/2022 20:18, RFC Errata System wrote: > > The following errata report has been submitted for RFC8294, > > "Common YANG Data Types for the Routing Area". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid7255 > > > > -------------------------------------- > > Type: Technical > > Reported by: Jeffrey Haas <[email protected]> > > Jeff > > I cannot get my mind around this. > > Following the URL, or searching the IANA web site, I find definitions of > RD Types 0, 1, 2; I cannot find a type 6. > > I wanted to see the definition of type 6 to see when it was defined to > see if that comes after the publication of RFC8294, in which case it > would not be an erratum but I cannot find a definition. > > Tom Petch > > > > > > > Section: 3 > > > > Original Text > > ------------- > > typedef route-distinguisher { > > type string { > > pattern > > '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|' > > + '6[0-4][0-9]{3}|' > > + '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0):(429496729[0-5]|' > > + '42949672[0-8][0-9]|' > > + '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|' > > + '42949[0-5][0-9]{4}|' > > + '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|' > > + '42[0-8][0-9]{7}|4[01][0-9]{8}|' > > + '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0))|' > > + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|' > > + '25[0-5])\.){3}([0-9]|[1-9][0-9]|' > > + '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|' > > + '655[0-2][0-9]|' > > + '65[0-4][0-9]{2}|6[0-4][0-9]{3}|' > > + '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|' > > + '(2:(429496729[0-5]|42949672[0-8][0-9]|' > > + '4294967[01][0-9]{2}|' > > + '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|' > > + '4294[0-8][0-9]{5}|' > > + '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|' > > + '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0):' > > + '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|' > > + '6[0-4][0-9]{3}|' > > + '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|' > > + '(6(:[a-fA-F0-9]{2}){6})|' > > + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):' > > + '[0-9a-fA-F]{1,12})'; > > } > > > > Corrected Text > > -------------- > > typedef route-distinguisher { > > type string { > > pattern > > '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|' > > + '6[0-4][0-9]{3}|' > > + '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0):(429496729[0-5]|' > > + '42949672[0-8][0-9]|' > > + '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|' > > + '42949[0-5][0-9]{4}|' > > + '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|' > > + '42[0-8][0-9]{7}|4[01][0-9]{8}|' > > + '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0))|' > > + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|' > > + '25[0-5])\.){3}([0-9]|[1-9][0-9]|' > > + '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|' > > + '655[0-2][0-9]|' > > + '65[0-4][0-9]{2}|6[0-4][0-9]{3}|' > > + '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|' > > + '(2:(429496729[0-5]|42949672[0-8][0-9]|' > > + '4294967[01][0-9]{2}|' > > + '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|' > > + '4294[0-8][0-9]{5}|' > > + '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|' > > + '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0):' > > + '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|' > > + '6[0-4][0-9]{3}|' > > + '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))'; > > } > > > > Notes > > ----- > > Type 6 route-distinguishers are not defined. See the registry at IANA: > > > https://www.iana.org/assignments/route-distinguisher-types/route-distinguisher-types.xhtml > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8294 (draft-ietf-rtgwg-routing-types-17) > > -------------------------------------- > > Title : Common YANG Data Types for the Routing Area > > Publication Date : December 2017 > > Author(s) : X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger > > Category : PROPOSED STANDARD > > Source : Routing Area Working Group > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > rtgwg mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/rtgwg > > . > > > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
