Francois,

Thank you very much for the explanation. Your amended text looks good to me.

Thank you,

Linda

From: Francois Clad <fclad.i...@gmail.com>
Sent: Wednesday, October 25, 2023 9:21 AM
To: Linda Dunbar <linda.dun...@futurewei.com>
Cc: spring@ietf.org; draft-ietf-spring-srv6-srh-compress...@ietf.org
Subject: Re: Review comments and questions to 
draft-ietf-spring-srv6-srh-compression-08

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

Reply via email to