Dear Linda, Thank you for your review of this document. Your feedback is much appreciated.
We have clarified and amended the text in response to your review, and these modifications were included as part of the recently submitted revision 9 ( https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/9/). Please also see inline below ([FC]) specific replies to your comments and questions. Thanks, Francois (and behalf of the C-SID co-authors) On Sep 15, 2023 at 20:39:08, Linda Dunbar <linda.dun...@futurewei.com> wrote: > Weiqiang, clarence, Zhenbin, Bruno, and Francois, > > > > Reading through the draft-ietf-spring-srv6-srh-compression-08 for the > first time without prior engagement in the discussion, I think the document > is well written and clear. Here are some comments and questions: > > > > Section 7.2 helps me the most in comprehending the mechanism described in > the draft. It would be nice if adding a reference in Section 3 (Basic > Concepts) to inform readers of the pseudo-code of the SR source node > compressing the SID. > [FC] We added a reference to the source node and segment endpoint sections in section 3. The compressed encoding is achieved by combining a compressed segment list encoding logic on the SR source node (Section 6) with new flavors of the base SRv6 segment endpoint behaviors that decode this compressed encoding (Section 4). > > Section 6.4 (Recommended Installation of C-SIDs in FIB): The first > sentence states that an SR segment endpoint node SHOULD install the > corresponding FIB entry to match only the locator and function parts of > SIDs. It is not clear who is responsible for installing the FIB entry? Is > it by IGP? BGP or manual configuration? > [FC] This would be an implementation decision and may vary based on the SID type. Similar to RFC 8754 and RFC 8986, this document is only concerned that the SR segment endpoint node installs a FIB entry for each of its local SIDs. >From RFC 8754: 4.3. SR Segment Endpoint Node Without constraining the details of an implementation, the SR segment endpoint node creates Forwarding Information Base (FIB) entries for its local SIDs. When an SRv6-capable node receives an IPv6 packet, it performs a longest-prefix-match lookup on the packet's destination address. This lookup can return any of the following: - A FIB entry that represents a locally instantiated SRv6 SID - A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID - A FIB entry that represents a nonlocal route - No Match > > There are many acronyms, LBL, LNL, FL, LNFL, etc., used in the document. > Can you list all of them in the Terminology section? > [FC] We added the missing acronyms in section 2. In this document, the length of each constituent part of a SID is referred to as follows. - LBL is the Locator-Block length of the SID. - LNL is the Locator-Node length of the SID. - FL is the Function length of the SID. - AL is the Argument length of the SID. In addition, LNFL is the sum of the Locator-Node length and the Function length of the SID. It is also referred to as the C-SID length. > > Section 4.1.3: the pseudo code has “Set the packet’s associated FIB table > to T”. I see it is also described in the RFC8986 for multi-table operation > in the core. Can you elaborate what scenarios will a node have multi-table > for IPv6 forwarding? > [FC] Section 4.1.3 (and 4.2.3) define the C-SID flavors for the End.T behavior of RFC 8986. The operators who are relying on the End.T SIDs of RFC 8986 for multi-table operation may find it useful that these SIDs be compressible. > > Section 5.1: states that “a Global C-SID typically identifies a shortest > path to a node in the SRv6 domain”. Earlier sections describe Global SID > is a group of SID in the SRv6 domain. Isn’t “shortest Path” computed based > on IGP advertisement? Why Global C-SID? > [FC] We clarified the definition of global (and local) C-SIDs in section 5. Please let us know if the new text answers your questions. 5.1. Global C-SID A global C-SID is a C-SID allocated from the GIB. A global C-SID identifies a segment defined at the Locator-Block level. The tuple (Locator-Block, C-SID) identifies the same segment across all nodes of the SR domain. A typical example is a prefix segment bound to the End behavior. A node can have multiple global C-SIDs under the same Locator-Block (e.g., one per IGP flexible algorithm ([RFC9350])). Multiple nodes may share the same global C-SID (e.g., anycast). > > > > Thank you, > > Linda > > > > > > > > - > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
