Ben, An RD is encoded using the same format as an extended community but it isn't an extended community. Rather, it is actually part of the NLRI. The first octet is always zero whereas the first octet of an SFIR Pool Identifier extended community will always be non-zero (TBD6).
Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Sent: Thursday, August 20, 2020 1:10 AM > To: Adrian Farrel <adr...@olddog.co.uk> > Cc: 'The IESG' <i...@ietf.org>; slitkows.i...@gmail.com; draft-ietf-bess-nsh- > bgp-control-pl...@ietf.org; bess-cha...@ietf.org; bess@ietf.org > Subject: Re: [bess] Benjamin Kaduk's Discuss on > draft-ietf-bess-nsh-bgp-control- > plane-15: (with DISCUSS and COMMENT) > > [External Email. Be cautious of content] > > > Hi Adrian, > > On Wed, Aug 19, 2020 at 11:11:10PM +0100, Adrian Farrel wrote: > > Ben, > > > > Thanks for the update. > > > > > DISCUSS: > > > > > > I think we may still need some text changes to clarify how the joint > > > list of SFIR-RD and SFIR Pool Identifier Extended Communities is > > > constructed and interpreted, and potentially need to register an RD > > > Type matching the other (TBD6+TBD7) values we allocate. > > > > I think the clue here is that an RD is an extended community of type 0, 1, > > or 2 > with extended type always 0 (together, the RD type) while a pool id is a (new) > extended community of type TBD6 with several extended types defined (1 and 2 > in this document). > > > > The whole extended community is included in the list, so it is always > > possible > to tell the difference between an RD and a pool id. > > You read the first two bytes and get 0:0, 1:0, or 2:0 for an RD and TBD6:1, > > or > TBD6:2 for a pool id. > > > > I'm adding... > > > > <t>Note that an SFIR-RD can be distinguished from an SFIR > > Pool > Identifier because they are both > > BGP Extended Communities but they have different > > extended community types.</t> > > My apologies for being so dense, but I'm still having a bit of trouble with > this. > > To be clear, what you describe sounds clear and makes perfect sense, but I'm > having trouble mapping it up to the specs and IANA registries. For example, > if > the RD is encoded as 0:0, 1:0, or 2:0, then wouldn't the extended community > sub-type value 0 be allocated in the corresponding registries? > > I see where RFC 4360 defines the extended communities attribute with type high > and (optional) type low, and specifically how types 0, 1, and 2 are specified > as > extended transitive communities for AS-specific, IPv4-address-specific, and > opaque extended communities, respectively, with the low-order octet used to > indicate sub-types. I also see RFC 4360 define the Route Target community > with > low-order octet 0x02 (for all three values mentioned for the high-order type > byte). (No mention of Route Distinguishers or low-order octet 0x00, yet, but > more on that below.) > > I also see those types 0x00, 0x01, and 0x02 listed at the BGP Transitive > Extended > Community Types registry at > https://urldefense.com/v3/__https://www.iana.org/assignments/bgp- > extended-communities/bgp-extended- > communities.xhtml*transitive__;Iw!!NEt6yMaO- > gk!TvwIGF3cPlbYP7RKpAVubzXyut36taFS-ruw1KO5IPDqAyNTwEEF-_joPy8pgTg$ > , and when I go to find (e.g) the "Transitive Two-octet AS-Specific Extended > Community Sub-Types" registry indicated for type value 0x00, I end up at > https://urldefense.com/v3/__https://www.iana.org/assignments/bgp- > extended-communities/bgp-extended-communities.xhtml*trans-two-octet- > as__;Iw!!NEt6yMaO-gk!TvwIGF3cPlbYP7RKpAVubzXyut36taFS- > ruw1KO5IPDqAyNTwEEF-_joP98-pcE$ > and see that sub-type value 0x00 is "Unassigned". For the IPv4 and opaque > sub- > type registries 0x00 is also listed as Unassigned, but "Unassigned > (deprecated)", > interestingly enough. > > Getting back to the Route Distinguisher topic, I see RFC 4364 discuss that RDs > are encoded as a 2-byte type field and 6-byte value, defining the format for > types 0, 1, and 2. But with no mention of high or low bytes within the type, > I > assume that those type values are 0x0000, 0x0001, and 0x0002, as opposed to > the 0x0200 that you describe above. I also see RFC > 4364 say that the Route Targets (which AFAICT are the RFC 4360 transitive > extended communities with type 0:2, 1:2, and 2:2) "are structured similarly to > the RDs", but the only discussion of "extended communit{y,ies}" I see in RFC > 4364 relate to RTs, "additional types" that may be defined, and Route Origin. > Specifically, "extended community" does *not* seem to be used in conjunction > with RDs. > > So, while I'm willing to believe that everything is fine and I'm just > confused about > how it works, I still don't see how the pieces line up. > Hopefully the above discussion helps to clarify what I'm stuck up on. > > > > (I'm also not entirely clear how the IPv6 addresses interact with > > > 8-byte RDs.) > > > > This is in your Comment on section 8.10 and addressed below. > > (Yes.) > > > Tl;dr They don't. RDs are encoded according to the operator's choice of > numbering scheme and do not use v6 addresses. > > > > > COMMENT: > > > > > > [retaining the note that I support Roman's Discuss] > > > > Well, hoping that we have addressed that in -15, but waiting to hear from > Roman. > > > > > New comments on the -15 > > > > > > Section 2.2 > > > > > > o The Special Purpose SFT values range is assigned through Standards > > > Action. Values in that range are used for special SFC operations > > > and do not apply to the types SF that may be placed on the SFC. > > > > > > I'm not sure I understand what it means to "place a SF on the SFC". > > > Also, nit: missing "of"? > > > > Nit is correct. > > "Placed on" refers to the fact that an SFC is a computed sequence of SFs > > that > form the chain. > > Ah, "placed on [...] the chain", of course. Sorry for missing that... > > > Well, this should really say "SFP" > > Clarified to... > > ...and do not apply to the types of SF that may form part of > > the SFP. > > ... but this seems better. > > > > o The First Come First Served range tracks assignments of STF values > > > made by any party that defines an SF type. Reference through an > > > Internet-Draft is desirable, but not required. > > > > > > Maybe "Internet-Draft or other stable written specification?" > > > > I think there is nothing to be gained from driving people away from the > > IETF, > so it's still our "desire" that an I-D would be used. > > > > > Section 8.10 > > > > > > The IPv6 examples seem to show RDs that are 127-bit IPv6 prefixes, > > > but an 8-octet RD doesn't seem to have space for that? > > > > Wow, this really is a mistake or embarrassing proportions. I shall claim > > clumsy > editing while in a major grump about having to put in these examples. The > fact is > that *all* that changes in the IPv6 examples is the addresses of the nodes - > the > BGP advertisements are not changed at all and RDs remain as whatever 6 byte > scheme the operator chooses to use. > > > > I have added some text to help with this (as well as fixing the RDs) so > > that in > Section 8 we have... > > > > <t>The SFFs advertise routes to the SFIs they support. These > > advertisements > > contain Route Distinguishers that are set according to the network > operator's > > configuration model. In all of these IPv4 examples we use RDs of > > type 2 > such that the > > available six octets are partitioned as four octets for the IPv4 > > address of > the advertising > > SFF, and two octets that are a local index of the SFI. This scheme > > is chosen > purely for > > convenience of documentation, and an operator is totally free to use > > any > other scheme so > > long as it conforms to the definitions of SFIR and SFPR in <xref > target="sfiRoutes" /> and > > <xref target="sfpRoutes" />.</t> > > > > <t>Thus we see the following SFIRs advertised:</t> > > > > ...and in 8.10 we have... > > > > <t>The SFFs advertise routes to the SFIs they support. These > > advertisements > > contain Route Distinguishers that are set according to the network > operator's > > configuration model. Note that in an IPv6 network, the RD is not > > large > enough to > > contain the full IPv6 address as only six octets are available so, > > in all of > these IPv6 > > examples, we use RDs of type 2 such that the available six octets are > partitioned as four > > octets for an IPv4 address of the advertising SFF, and two octets > > that are a > local index > > of the SFI. Furthermore, we have chosen an IPv6 addressing scheme so > that the low order > > four octets of the IPv6 address match an IPv4 address of the > > advertising > node. This scheme > > is chosen purely for convenience of documentation, and an operator is > totally free to use > > any other scheme so long as it conforms to the definitions of SFIR > > and > SFPR in > > <xref target="sfiRoutes" /> and <xref target="sfpRoutes" > > />.</t> > > > > <t>Observant readers will notice that this makes the BGP advertisements > shown in these examples > > exactly the same as in the previous examples. All that is different > > is that > the advertising > > SFFs and Controller have IPv6 addresses.</t> > > That does look like it will help; thanks! > > > <t>Thus we see the following SFIRs advertised:</t> > > > > > Section 8.10.4 > > > > > > SFP4: RD = 2001:db8::198:51:100:1/104, SPI = 18, > > > [SI = 255, SFT = 41, RD = 2001:db8::192:0:2:1/1], > > > [SI = 250, {SFT = 43, RD = 2001:db8::192:0:2:2/2, > > > SFT = 44, RD = 2001:db8::192:0:2:3/8 } ] > > > [...] > > > When the packets are returned to SFF1 by the SFI the SI will be > > > decreased to 250 for the next hop. SFF1 now has a free choice of > > > next hop SFF to execute the next hop in the path selecting between > > > all SFF2 that support an SF of type 43 and SFF3 that supports an SF > > > of type 44. These may be completely different functions that are > > > to > > > > > > I see a specific (nonzero) RD for SFT=43, so I don't understand why > > > this is a choice of "all SFF2 that support an SF of type 43". > > > > That is s/SFF2/SFFs/ :o( > > We caught that previously in 8.3 but didn't propagate the fix. > > Ah, makes much more sense that way, thanks. > > > > Section 9 > > > > > > You say that RFC 4760 has additional relevant security measures but > > > I'm not sure which measures you're referring to (having skimmed all of > 4760). > > > > Well, yes, erm (looks for excuse, but can't find one quickly). I think we > > just > thought, "Well, we're talking about mBGP so all of the security stuff for that > must apply," and didn't look further. > > > > Changed this to: > > <t>Additionally, this document depends on other documents that specify > BGP > > Multiprotocol Extensions and the documents that define the attributes > that > > are carried by BGP UPDATEs of the SFC AFI/SAFI. <xref > > target="RFC4760" > /> > > observes that the use of AFI/SAFI does not change the underlying > > security > issues > > inherent in the existing BGP. Relevant additional security measures > > are > > considered in <xref target="I-D.ietf-idr-tunnel-encaps" />.</t> > > Thanks. > > > > This document does not fundamentally change the security behavior of > > > BGP deployments which depend considerably on the network > > > operator's > > > > > > nit(?): maybe comma before "which"? > > > > OK > > > > > perception of risk in their network. It may be observed that the > > > application of the mechanisms described in this document are scoped > > > to a single domain as implied by [RFC8300] noted in Section 2.1. > > > > > > I can't tell if this means section 2.1 of 8300 or this document. > > > > It's obvious from the XML 😊 > > "v3 XML will fix it, of course" > > > Yup, fixed to clarify "of this document" > > Thanks for all the explanations and updates, and sorry again for my continued > confusion about the types. > > -Ben _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
