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

[Suresh Krishnan <[e-mail]>]

Hi Adrian,
  Thanks again for the text suggestions. I think we are mostly in agreement regarding the changes. I have snipped out the points where we agree on the text below and brought forward the points that need further discussion

>> 
>> 3.
>> 
>>   When an SRv6 SID occurs in the IPv6 destination address field of an
>>   IPv6 header, only the longest match prefix corresponding to the
>>   locator is used to forward the packet to the node identified by the
>>   Locator.
>> 
>> Possibly you mean s/is used/should be used/
>> Or maybe s/used/used by an SRv6-capable node/
>  
> This is written as a statement about what happens today rather than specifying behavior for the node to follow.
>  
> [AF] Well, I like your confidence about all the implementations that are out there 😊

This text applies to the transit nodes (and those are not required to be capable of processing a segment or an SRH) and I am confident they exist :-)

> I think there are two points:
> You are describing SRv6-capable nodes, I think.

This text applies to transit nodes and these are not assumed to be SR-capable. The preceding paragraph sets the context for this but it might be worth restating that in this sentence. Combined text suggestion to address both point 1. and point 2. below

> You might more accurately provide the normative reference to where this behavior is defined, and then say “As defined in [ref], when an SRv6 SID…” 
>  

Suggest

OLD:
When an SRv6 SID occurs in the IPv6 destination address field of an IPv6 header, only the longest match prefix corresponding to the locator is used to forward the packet to the node identified by the Locator.

NEW:
When an SRv6 SID occurs in the IPv6 destination address field of an IPv6 header, only the longest match prefix corresponding to the Locator [RFC7608] is used by the transit node to forward the packet to the node identified by the Locator.


> 
>> 4.
>> 
>>   A node
>>   taking part in this mechanism accomplishes this by using the ARG part
>>   [RFC8986] of the Destination address field of the IPv6 header to come
>>   up with a new Destination address in some of these flavors.
>> 
>> "to come up with" and "flavors" are a bit colloquial. Maybe say 
>> "derive" and "mechanisms".
>  
> Ack on the “derive” part, but “flavor” is a specific term used in [I-D.ietf-spring-srv6-srh-compression]
>  
> [AF] Hrmph! draft-ietf-spring-srv6-srh-compression is a work in progress, is not a normative reference here, and is not part of this last call. I see it uses “flavor” extensively, but it is a poor choice of word.
>  
> I tell you what: if the meaning of the word is clear, you can tell me what it means in this context. And if you can tell me what it means, you can use that description in your draft.


As Acee pointed out upthread this term predates [I-D.ietf-spring-srv6-srh-compression] and actually comes from [RFC8986] Section 4.16. We can either put in a reference to that or I can simply write it out with a reference to behavior. Suggestion below:

OLD:
   describes how to use a single entry in the SRH list as a container
   for multiple SIDs and defines a few flavors of how to do so.  A node
   taking part in this mechanism accomplishes this by using the ARG part
   [RFC8986] of the Destination address field of the IPv6 header to come
   up with a new Destination address in some of these flavors.

NEW:
   describes how to use a single entry in the SRH list as a container
   for multiple SIDs and defines a few behaviors of how to do so.  A node
   taking part in this mechanism accomplishes this by using the ARG part
   [RFC8986] of the Destination address field of the IPv6 header to come
   up with a new Destination address.


>> 
>> 4.1.
>> 
>>   There are a few issues that need to be addressed in the C-SID draft
>>   prior to its publication as RFC:
>> 
>> Erm, no! You can't have an RFC that chats about the current state of
>> another draft, or that claims it is going to be published as an RFC.
>> 
>> Perhaps the best solution is to compress sections 4, 4.1, and 4.2 into
>> a very short note that "Many approaches to SID list compression have
>> been proposed. It is important that any solution preserves the
>> properties of the LOC as described in Section 3."
>  
> This text was added as requested by one of the spring chairs to specify that the spring document needs to address these issues. It would be great if the 6man/spring chairs and ADs can chime in on this topic.
>  
> [AF] While we wait for them to speak up, let’s just note that if the intention of this text is to set requirements, you should that in terms of “any specification addressing this problem space needs to provide answers to the following questions.”

It is certainly the intention and I fully agree with you that this draft cannot impose this on the spring draft. Joel has asked the spring WG this morning to weigh in on this question asked by Jen as 6man chair

https://mailarchive.ietf.org/arch/msg/spring/ydGtikGr2NvUQGtw26Ye3YnQ1jI/ <https://mailarchive.ietf.org/arch/msg/spring/ydGtikGr2NvUQGtw26Ye3YnQ1jI/>

Depending on the result of that poll I see one of these two things happening

a) the spring WG agrees to move this into the CSID draft as open issues to be tracked and we can delete this from the 6man draft
b) the spring WG does not, and I will rewrite this text exactly like you suggested as a generic set of questions to be answered.

Does that work or do you prefer to make this generic and retain in this draft in either case?

> 
>> I know that the permeability of SR domain boundaries is something that
>> really worries at least one of the current ADs, and it might be good to
>> spend some time discussing what happens when things go wrong and a 
>> packet with a SID in the DA field escapes from the domain (this is
>> distinct from the behavior of a non-SR node within the domain).
> Yes. I certainly do understand that concern and one of the tools in reducing the permeability is moving this traffic to a well known filterable prefix at the borders of the domains depending on the stance of the domain. 
>  
> [AF] This helps so long as we include a remark on what will happen when a packet carrying a DA that uses one of these special prefixes is encountered by a node outside the domain. You possibly need to explain how a non-SR node inside the domain differs from a non-SR node outside the domain.

That is a good point. It really boils down to the administrative stance of the domain. My working assumption (based on what I have been told by operators of non-SR-aware domains) is that a domain that is not interested in SR traffic would filter these prefixes at the border. I personally don’t think this draft should make that recommendation since it is of an operational nature but I don’t have very strong feelings about this.

Regards
Suresh