Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

[Suresh Krishnan <[e-mail]>]

Hi Eduard,
  Thanks for your comments.

> On Oct 11, 2022, at 3:29 AM, Eduard Metz <[e-mail]> wrote:
> 
> Apologies for the late review, some comments from my side (maybe some have been addressed already earlier, I didn't check, the thread was quite lengthy)

Haha. Yes it is :-). Most of the things you brought up have been discussed and potentially resolved in version -02. There were a couple of new points and I have tried to address them inline.
  
> With regard to RFC4291 I assume the main observation is that the SRv6 SID structure does not match with the structure of RFC4291, in particular the interface ID part. A small discussion on the other aspects of RFC4291 could be added to further clarify this (as done for the subnet-router anycast address). In theory, if the SRv6 SID would start with "000" the interface ID would not even be a problem.

The actual block to be allocated will come from IANA but there are a whole bunch of allocations in this space that are used for special purposes already and the goal might be to make this prefix separate from the existing used blocks. If you have a suggestion for a recommendation from the WG, feel free to put one up.

>  
>  
> Some specific points in the draft-01 text:
>  
> [RFC8754] defines the Segment List of the SRH as a contiguous array of 128-bit IPv6 addresses, and that each of the elements in this list are SIDs.  But all of these elements are not necessarily made equal.  Some of these elements may represent a local interface as described in Section 4.3 of [RFC8754] <https://datatracker.ietf.org/doc/html/rfc8754#section-4.3> as "A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID".  From this it follows that all the SIDs that appear in the SRH are not SRv6 SIDs as defined by [RFC8402 <https://datatracker.ietf.org/doc/html/rfc8402>].
> 
> This paragraph starts with stating that each of the elements in an SR list of the SRH are SIDs (first sentence) and ends with that  all the SIDs in the SRH are not SRv6 SIDs. This is contradicting.

Hmm. The whole point of this paragraph is to establish that all SIDs are not SRv6 SIDs as some SIDs represent local interfaces and are RFC4291 compliant. Not sure where the contradiction is.

>  
>  "Some of these elements may represent a local interface as described in Section 4.3 of [RFC8754] <https://datatracker.ietf.org/doc/html/rfc8754#section-4.3> as "A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID""
> Section 4.3 describes the potential outcomes of an LPM lookup on IPv6 DA address on a packet in an SRv6 capable node, it does not describe the SRH.
>  
> "It is also fairly clear that the non-SRv6-SID elements that appear in  the SRH SID list are simply IPv6 addresses assigned to local  interfaces annd MUST conform to [RFC4291 <https://datatracker.ietf.org/doc/html/rfc4291>].  "
> Having non-SRv6-SID elements in the SRH list seems an error condition? See also RFC8745, section 4.3.2. Non SRv6 SID in DA field of packet with SRH is an error condition here.
>  

When the packet reaches the ultimate end host it will have an SRH with SL=0 and this is not considered an error as per Section 4.3.2 when the DA contains an address assigned to a local interface (non SRv6 SID).

>  
> Section 4.1

Section 4.1. is expected to be removed from the draft pending consensus from the spring WG to pick up the issues. The 6man chairs and the spring chairs will provide further guidance on this. If the text needs to remain in the draft I think your comments make sense and I will address them in the next rev. If not, I will pass along the comments to the authors of C-SID.

>  
> Chapter 6
> The size of the block seems possibly small. How is it sized?

The size was picked based on feedback from some operators who would like to deploy SRv6 with C-SIDs in this block and the suggested block size of /16 provides a good balance between efficiency and address conservation. My personal opinion is that allocating a larger block would be excessive, but if you have arguments as to why it should be larger please make them to the WG.
 
> I would suggest to reserve a block that is sufficiently large and include at least some high-level guidelines regarding its use. For example is it intended to be ULA alike, or globally unique? Is use of the block for SRv6 mandatory, or optional? 

The use of this block for SRv6 is optional. Please let me know if there is any text that states or implies otherwise. 

Thanks
Suresh