Hi Robert, From: Robert Raszuk <[email protected]> Date: Saturday, November 19, 2022 at 8:25 AM To: t petch <[email protected]> Cc: RFC Errata System <[email protected]>, Acee Lindem <[email protected]>, Christian Hopps <[email protected]>, "[email protected]" <[email protected]>, Alvaro Retana <[email protected]>, John Scudder <[email protected]>, "[email protected]" <[email protected]>, Jeff Tantsura <[email protected]>, "[email protected]" <[email protected]>, Routing WG <[email protected]> Subject: Re: [Technical Errata Reported] RFC8294 (7255)
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. I think that would be a good job for you. Thanks, Acee Cheers, Robert On Sat, Nov 19, 2022 at 1:17 PM t petch <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/rtgwg > . > _______________________________________________ rtgwg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
