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'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>
<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"
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
