On March 11, 2021 at 5:46:51 AM, Peter Psenak wrote:
Peter: Hi! > thanks for the review, please see inline (##PP): It looks like you didn't get the whole review (Outlook bug). Take a look at it here: https://mailarchive.ietf.org/arch/msg/lsr/a4a4I4fP73DyfKsdKnRw_tRuStQ/ ... > > Just one high-level comment: It is not clear to me why all the > > behaviors from rfc8986 are not covered in this document. If some are > > not applicable, or are covered elsewhere, please explain in the text. > > ##PP > not all behaviors from rfc8986 are applicable to IGPs. Section 10 > ("Advertising Endpoint Behaviors") lists the ones that are applicable to > ISIS. I understand that -- other readers may not. Also, §8.1/rfc8986 talks about what is expected to be carried in the IGP. End.T is not included in this document. ... > > 148 2. SRv6 Capabilities sub-TLV > > > > 150 A node indicates that it supports the SR Segment Endpoint Node > > 151 functionality as specified in [RFC8754] by advertising a new SRv6 > > 152 Capabilities sub-TLV of the router capabilities TLV [RFC7981]. ... > > [minor] "router capabilities TLV [RFC7981]" What should be the > > flooding scope of the TLV that includes this new sub-TLV? > > ##PP > It's up to the originator to set the S bit or not. We are not limiting > it here. But if the originator doesn't set the correct flooding scope then the information will not make it to where is has to. I would like to see some guidance on the setting of the bit -- I'm assuming that most of the cases require the S bit to be set, right? ... > > 200 4.1. Maximum Segments Left MSD Type ... > > 208 If no value is advertised the supported value is assumed to be 0. > > > > [major] What exactly does this MSD type signal? Is this the > > expectation that the SL will be <= the value when received at the > > advertiser? Is there an example of its use? I'm having a hard time > > picturing when (for non PSP behaviors) the SL would be more than 0. > > > > ##PP > > Yes, you are correct. As described in the paragraph right above it, this > MSD type specifies what is the maximum value of the "Segments Left" > field in the received SRH that this node is capable of processing. > A simple example: an ingress PE encapsulates a packet with a new IPv6 > and SRH. The SRH contains three segments. The Segments Left value of > that SRH is set as per RFC8754 4.1, which in this case is equal to 2. > The router processing the first segment in the segment list, must > support as a minimum an SRH Max SL MSD value of 2 in order to be able to > process such packet. I see. It would be very nice if the text said somewhere that the MSD applies not just to the final endpoint but also to intermediate nodes. ... > > 252 5. SRv6 SIDs and Reachability ... > > 280 In cases where a locator advertisement is received in both a Prefix > > 281 Reachability TLV and an SRv6 Locator TLV, the Prefix Reachability > > 282 advertisement MUST be preferred when installing entries in the > > 283 forwarding plane. This is to prevent inconsistent forwarding entries > > 284 between SRv6 capable and SRv6 incapable routers. ... > > [major] "locator advertisement is received in both a Prefix > > Reachability TLV and an SRv6 Locator TLV" What information results in > > these being an advertisement for the same locator? Is only the > > locator (prefix length, etc.) considered, or should the algorithm, > > metric, etc. also match? > > ##PP > it's just prefix/mask. I added some text to clarify that. So...even if the MT-ID and algorithms are different, the advertisements are considered the same? I don't have a specific case right now, but it sounds to me that this could result in some type of incongruency. I'll think more about this later -- no further action needed. ... > > [major] The SRv6 Locator TLV is a new TLV. If no Prefix Reachability > > TLVs are present, how should the new TLV be used for route > > calculation/installation? The text above suggests its use, but there > > is no specification. > > #PP > The locator TLV advertises the prefix, same way as the Prefix > Reachability. The calculation and installation of the prefix > reachability is equal to what is done for regular Prefix Reachability. > I added the following text to one of the above paragraphs: > > "The processing of the prefix advertised in the SRv6 Locator TLV, > the calculation of its reachability and the installation in the > forwarding plane is similar to one used for Prefix Reachability TLV (236 > or 237)." s/is similar to one used for Prefix Reachability TLV (236 or 237)./follows the process defined for the Prefix Reachability TLV (236 or 237) [rfc5308]. Would that be ok? > > 291 SRv6 SIDs are not directly routable and MUST NOT be installed in the > > 292 forwarding plane. Reachability to SRv6 SIDs depends upon the > > 293 existence of a covering locator. > > > > [major] "MUST NOT be installed" This action depends on how the SIDs > > are advertised. For example, if they are included in a Prefix > > Reachability TLV then the receiver will install them. IOW, this > > action should be specified from the point of view of the sender; > > ##PP > This section talks about received SRv6 SIDs, not locators. SIDs are not > advertised in Prefix Reachability TLV. Remote SIDs are never installed > in the forwarding. > > I updated the text to say "SRv6 SIDs received from other nodes..." > > for > > example, "SIDs MUST be advertised in the sub-TLVs...[or maybe]...MUST > > NOT be advertised in another TLV...". > > ##PP > the previous section talks about how SIDs are advertised, which is the > only way. Just to make sure we're talking about the same thing. The SIDs are covered by the LOC, which is routable, installed in the RIB/FIB, etc. There's nothing in this document or rfc8986 that prevents a SID to have the same value as the IP address on a link (see below). Then that link address could be advertised using normal (non-SR-related) mechanisms. In this case, the receiver would know the address is also a SID. Should that result in "MUST NOT be installed"? Not even the MUSTs that I suggested could prevent this situation. > > [major] If some SIDs are advertised as "sub-TLVs in TLVs 22, 23, 222, > > 223, and 141", how can the "MUST NOT be installed" be satisfied? > > ##PP > above is the only way how SIDs are advertised. This is the text from -11: SRv6 SIDs are advertised as sub-TLVs in the SRv6 Locator TLV except for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a specific Neighbor/Link and are therefore advertised as sub-TLVs in TLVs 22, 23, 222, 223, and 141. SRv6 SIDs are not directly routable and MUST NOT be installed in the forwarding plane. Reachability to SRv6 SIDs depends upon the existence of a covering locator. The text says that there is more than one way to advertise SIDs, *and* that they "MUST NOT be installed". Thanks! Alvaro. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
