Hey Acee, Well actually YANG model for extended communities seems to be defined in BGP model.
REF: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model So perhaps it is not best idea to keep the same thing defined differently in multiple RFCs ? Thx, R. On Sat, Nov 19, 2022 at 6:46 PM Acee Lindem (acee) <[email protected]> wrote: > 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]> 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
