Subject: Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-nsh-bgp-control-plane-15: (with DISCUSS and COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 Aug 2020 23:11:10 +0100

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>

> (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.
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.
Well, this should really say "SFP"
Clarified to...
               ...and do not apply to the types of SF that may form part of the SFP.

> 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&apos;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&apos;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>

    <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.

> 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>

>   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 😊
Yup, fixed to clarify "of this document"

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 Aug 2020 22:09:58 -0700

Hi Adrian,

>                      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://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#transitive
, 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://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#trans-two-octet-as
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.

> This is in your Comment on section 8.10 and addressed below.

(Yes.)

> "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...

>                ...and do not apply to the types of SF that may form part of the SFP.

... but this seems better.

>        SFFs and Controller have IPv6 addresses.</t>

That does look like it will help; thanks!

> We caught that previously in 8.3 but didn't propagate the fix.

Ah, makes much more sense that way, thanks.

>        considered in <xref target="I-D.ietf-idr-tunnel-encaps" />.</t>

Thanks.

> 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

---

From: John E Drake <[email-masked]>
Date: Thu, 20 Aug 2020 13:43:34 +0000

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 <[email-masked]>
> Sent: Thursday, August 20, 2020 1:10 AM
> To: Adrian Farrel <[email-masked]>
> Cc: 'The IESG' <[email-masked]>; [email-masked]; draft-ietf-bess-nsh-
> [email-masked]; [email-masked]; [email-masked]
> 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,
> 
> > > 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.
> 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$
> 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
> 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.
> > Tl;dr They don't. RDs are encoded according to the operator's choice of
> numbering scheme and do not use v6 addresses.
> >
> > > COMMENT:
> > >
> > 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 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(
> > > 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:
> Thanks for all the explanations and updates, and sorry again for my continued
> confusion about the types.
> 
> -Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 20 Aug 2020 06:48:49 -0700

Hi John,

> 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…

Thanks for helping clarify.  I'm not seeing what guarantees that the first
octet of the RD is always zero going forward, though -- I see
https://www.iana.org/assignments/route-distinguisher-types/route-distinguisher-types.xhtml
that lists values 3-65534 as "Unassigned".  If we are going to rely on
non-overlap between the extended community types used for this document and
RD types in general, don't we need to mark some values in one (or both!)
registry as Reserved with a reference to [this-document]?

-Ben

---

From: John E Drake <[email-masked]>
Date: Thu, 20 Aug 2020 14:06:40 +0000

Ben,

Perhaps, although AFAIK the three values defined in RFC 4364 have not been supplemented since it was published in 2006.

Yours Irrespectively,

John

> Sent: Thursday, August 20, 2020 9:49 AM
> To: John E Drake <[email-masked]>
> Cc: Adrian Farrel <[email-masked]>; 'The IESG' <[email-masked]>;
> [email-masked]; [email-masked]; bess-
> [email-masked]; [email-masked]
> > 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).
> 
> Thanks for helping clarify.  I'm not seeing what guarantees that the first octet of
> the RD is always zero going forward, though -- I see
> https://urldefense.com/v3/__https://www.iana.org/assignments/route-
> distinguisher-types/route-distinguisher-types.xhtml__;!!NEt6yMaO-
> gk!XaVl3FGXv5cbCKTxNwk3iDLsewVmqJqBOHl8SCveaWdUk0BtkI2cbqt92LXsa5E
> $
> that lists values 3-65534 as "Unassigned".  If we are going to rely on non-overlap
> between the extended community types used for this document and RD types in
> general, don't we need to mark some values in one (or both!) registry as
> Reserved with a reference to [this-document]?
> 
> -Ben