Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

["Darren Dukes (ddukes)" <[e-mail]>]

Hi Joel, the SR Source knowing what SIDs it adds is the whole point.

see inline...


> On May 25, 2019, at 11:56 AM, Joel Halpern Direct <[e-mail]> wrote:
> 
> Darren, I do not understand how the source node knowing what it puts on is relevant.
> 
> Suppose we have a packet with an SRH.  And suppose that the SRH uses three different SID types.  And suppose that, per the mutability section of this document, those three SID types have different mutability permissions.
> 
> What does this mean for who is allowed to modify what fields in the SRH when?

SIDs modify what it is defined to modify.

>  the reason mutability matters is that affects both how earlier nodes understand what will be delivered and how later nodes understand the relationship between what they received and what was sent. Unfortunately, a later node may well not know the SID types of the various SIDs in the list, or how those interact with the mutability.

The SID in this document decrements segments left and puts the next segment in the DA, other SIDs may do more than that.  The point is that the SR source knows what each SID does and builds its segment list accordingly.

> 
> Arguably, one could go even further.  From lots of discussions, we expect that SID lists will be provided by control systems.  At that point, while the control system presumably knows what the SID types are and how they affect mutability, there is NOT reason to expect the initial node to understand the SID types, much less their effect on mutability.
> 

The location of the process that computes a segment list is not relevant Joel, it obviously doesn’t matter if I place a path computation algorithm on the same CPU or physical piece of hardware as the SR Source node or somewhere else.

> If we agree, as the chairs have said, taht we need to spell out the mutability, then we need to spell out the mutability.  If mutability depends upon the values in various entries in the SID list (what types of SIDs are used) then that mutability needsto be spelled out and explained how various constraints interact.

Mutability is fully defined for the SRH and the SID defined in this document.  Other SIDs will have other processing definitions, and it is up to the SR Source node to order those SIDs in a segment list to achieve whatever functionality it requires from the segment list.

> 
> Yes, any IETF document can add exceptions, with working group agreement when it approves such a document, to a requirement.  But putting into the document that the spec doesn't actually tell you what the constraints are does not answer the mutability constraint.
> 
> Also, given that tLVs are tied to the entire SRH, not just to a given SID, there seems to be something very strange in a SID type changing the mutability constraints on the TLVs.

The TLV section clearly states what TLV Types Variable Length Data can change en route and those that do not.  The text in 4.3.1 on TLVs simply reiterates the same.

Darren

> 
> Yours,
> Joel
> 
> On 5/25/19 7:54 AM, Darren Dukes (ddukes) wrote:
>> The Sr source node knows fully what sids it adds to a segment list and how they are processed. This is the point of source routing in general and segment routing specifically. The source has full knowledge and control always.
>> The mutability of the srh is fully and correctly defined in this version of the text.
>> Darren
>>> On May 24, 2019, at 10:26 PM, Tom Herbert <[e-mail]> wrote:
>>> 
>>>> On Fri, May 24, 2019 at 4:33 PM Bob Hinden <[e-mail]> wrote:
>>>> 
>>>> Joel,
>>>> 
>>>>> On May 23, 2019, at 12:58 PM, Joel M. Halpern <[e-mail]> wrote:
>>>>> 
>>>>> Let me try rephraising Tom's question, since I think I share his concern.  (Apologies Tom if I ask something else.)
>>>>> 
>>>>> The mutability constraints for SRH are described in teh document as depending upon the SID type.
>>>> 
>>>> Are we discussing from Section 2. Segment Routing Extension Header:
>>>> 
>>>>  Some of the other fields of the SRH change en route (i.e. they are
>>>>  mutable).  The SRH is processed as defined in Section 4.3 of this
>>>>  document, and uniquely per SID type.  The mutability of the remaining
>>>>  fields in the SRH (Flags, Tag, Segment List, Optional TLVs) are
>>>>  defined in that section, in the context of segment processing.
>>>> 
>>>> The document defines a single SID and the mutability fields in the SRH header and TLVs.   It says that in the future other SIDs may be defined.  Of course, a future document can redefine anything, like all new IETF documents.
>>>> 
>>>> The chairs view of the w.g. consensus was to define the mutability of SRH so some future document could specify how AH works with SRH.   It was out of scope to define how AH works in this document.
>>> 
>>> Bob,
>>> 
>>> The consensus was (from your email):
>>> 1) The SRH draft should clearly specific which SRH fields are mutable,
>>> non-mutable, and/or predictable to be consistent with RFC8200.
>>> 2) We don’t think the document needs to specify how AH should work with SRH.
>>>> 
>>>> Would it help to change the language to make it clearer that mutability is not tied to a single SID definition?   Or that future SID definitions need to specify their mutability?
>>>> 
>>> 
>>> The changes in version -19 are very are confusing to me. If version
>>> -19 had just clarified mutability requirements and deferred AH to
>>> other documents then there wouldn't be an issue, *but* this version
>>> introduces additional text in this area, namely the text in section
>>> 2.0 and similar text in section 4.3.1 that makes mutability
>>> requirements of SRH conditional on SID type, as well as the second
>>> paragraph in section 7.5 that attempts to to rationalize why AH is
>>> unneeded with segment routing. AFAICT, none of this content was
>>> previously discussed and I don't believe any of this is pertinent to
>>> meet the directives in the consensus call.
>>> 
>>> Also, I'm very sorry to complain, but I was bit surprised by a couple
>>> of procedural happenings with this:
>>> 
>>> 1) I received email that the draft was going to WGLC even before
>>> seeing the posting of version -19. Mutability was a major issue and we
>>> have been waiting on the draft that fixes the issue, it would have
>>> been nice to have at least a little chance to see if draft actually
>>> addressed the issue.
>>> 2) Ticket #69 "Adding/Deleting TLVs", which was created based on an
>>> email I sent, was closed on the basis of the changes in -19 which
>>> again we had no time to review. Looking again at this issue, and in
>>> light of the new text in section 2.0 and 4.3.1, it is still not clear
>>> to me that TLV insertion and deletion is really prohibited in SRH. I
>>> do not believe this ticket should be closed.
>>> 
>>> Tom
>>> 
>>> 
>>>> Thanks,
>>>> Bob
>>>> 
>>>>> These mutability requirements affect validation of an AH header.
>>>>> This seems to raise several problems.
>>>>> 
>>>>> 1) When the AH is being verified at someplace other than the current SRH SID enadpoint, there is no reason to expect the verifier to know the SID type.  So how can it verify the AH?
>>>>> 
>>>>> 2) More importantly, consider the case where there are several SIDs in the SID list.  Suppose SID 2 has more generous mutability than SID 3. So the endpoint identified by SID 2 modifies some of the SRH according to the SID2 rules.  Then changes the destination to SID 3.  Now the packet arrives at SID 3 and he wants to verify the AH.  But the SRH has been modified in accordance with the SID2 rules.  Which SID3 does not even know about.  How is this supposed to work?
>>>>> 
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> PS: The wording on the mutability is unclear as to whether what can be changed is just the TLV content, or the type value itself.  If you can, please clarify.
>>>>> 
>>>>>> On 5/23/19 12:12 PM, Tom Herbert wrote:
>>>>>>> On Thu, May 23, 2019 at 8:23 AM Darren Dukes (ddukes) <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Ron and Bob, this is not complicated.
>>>>>>> 
>>>>>>> This document refers to "the SID type defined in section 4.3.1” vs calling it END.
>>>>>>> Other documents will refer to it as “the SID type defined in section 4.3.1 of draft-ietf-6man-segment-routing-header”.
>>>>>>> This is simple and all we need to be concerned with for draft-ietf-6man-segment-routing-header-19.
>>>>>> Darren,
>>>>>> I don't know what a "SID type" is, so it's hard to understand the
>>>>>> requirements reference SID types. Please provide a normative
>>>>>> definition for this term or a reference to the document containing the
>>>>>> definition of this term. And if multiple SID types are allowed then
>>>>>> obious question becomes how are different SID types distinguished from
>>>>>> one another in the protocol.
>>>>>> Tom
>>>>>>> 
>>>>>>> The second part of this thread is about draft-ietf-spring-network-programming.
>>>>>>> It defines a set of additional functions that can be associated with a SID and names them End, End.X, End.T, End.DX2, etc.
>>>>>>> It defines a registry to assign each of these SID types a number.
>>>>>>> This is how protocols (ISIS, OSPF, BGP, etc) distributing SIDs and identify their type for use at SR Source nodes.
>>>>>>> As mentioned on the SPRING alias, the definition of End in draft-ietf-spring-network-programming will get updated to better align with section 4.3.1 of draft-ietf-6man-segment-routing-header.
>>>>>>> 
>>>>>>> Darren
>>>>>>> 
>>>>>>> 
>>>>>>>> On May 22, 2019, at 9:58 PM, Ron Bonica <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Works for me!
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Juniper Internal
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Bob Hinden <[e-mail]>
>>>>>>>> Sent: Wednesday, May 22, 2019 9:34 PM
>>>>>>>> To: Ron Bonica <[e-mail]>
>>>>>>>> Cc: Bob Hinden <[e-mail]>; Darren Dukes (ddukes) <[e-mail]>; IPv6 List <[e-mail]>
>>>>>>>> Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>
>>>>>>>> 
>>>>>>>> Ron,
>>>>>>>> 
>>>>>>>>> On May 22, 2019, at 8:25 PM, Ron Bonica <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> Bob,
>>>>>>>>> 
>>>>>>>>> All of the SID in draft-ietf-spring-srv6-nework-programming begin with the word "END". The following are examples:
>>>>>>>>> 
>>>>>>>>> - END
>>>>>>>>> - END.X
>>>>>>>>> - END.DT4
>>>>>>>>> 
>>>>>>>>> So, you are correct in saying that the word "END" doesn't do much to distinguish one SID from another. Maybe the naming convention should be:
>>>>>>>>> 
>>>>>>>>> - SID
>>>>>>>>> - SID.X
>>>>>>>>> - SID.DT4
>>>>>>>>> - etc
>>>>>>>> 
>>>>>>>> I think that would be better.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> As long as we are consistent throughout the network programming draft, I am OK with the change.
>>>>>>>>> 
>>>>>>>>> Also, we need a good collective noun for SIDs of all types. Neither SID nor SRv6 SID work well. If we use the word "SID", it becomes overloaded. The term "SRv6 SID" is a little too close to "SID" to prevent confusion.
>>>>>>>> 
>>>>>>>> Perhaps when meaning all SIDs, just say “all SIDs”.  When one specific SID, by it’s name SID, SID.X, etc.
>>>>>>>> 
>>>>>>>> Bob
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>                                                                                                       Ron
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Juniper Internal
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Bob Hinden <[e-mail]>
>>>>>>>>> Sent: Wednesday, May 22, 2019 7:29 PM
>>>>>>>>> To: Ron Bonica <[e-mail]>
>>>>>>>>> Cc: Bob Hinden <[e-mail]>; Darren Dukes (ddukes) <[e-mail]>; IPv6 List <[e-mail]>
>>>>>>>>> Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>
>>>>>>>>> 
>>>>>>>>> Ron,
>>>>>>>>> 
>>>>>>>>>> On May 22, 2019, at 1:06 PM, Ron Bonica <[e-mail]> wrote:
>>>>>>>>>> 
>>>>>>>>>> Darren,
>>>>>>>>>> 
>>>>>>>>>> We may have made life more difficult for the following reasons:
>>>>>>>>> 
>>>>>>>>> How can anything be more difficult than it already is :-)
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> - Customers are already talking about "The END SID”.
>>>>>>>>>> - At least two other drafts refer to "The END SID".  In the future, will they refer to "the otherwise nameless SID defined in draft-ietf-6man-segment-routing-header”.
>>>>>>>>>> - The naming conventions that the chairs suggest introduces ambiguity. Does the term "SID" refer to all SIDs (END.X, END.DT4, etc.) collectively? Or does the term "SID" refer to one particular SID that is defined in draft-ietf-6man-segment-routing-header.
>>>>>>>>> 
>>>>>>>>> SID would refer to the SID defined in the SRH draft.   I note that in RFC 8402, this appears to be called SRv6 SID.  That seems to be consistent.
>>>>>>>>> 
>>>>>>>>> When we reviewed the changes in what became the -19 draft, we found the use of “END SID” confusing.  We went back to see if there were other kinds of SIDs defined (for example is there a START SID, MIDDLE SID, etc.), but there isn’t.   We thought it would be better to just say SID.   If new SIDs are later defined elsewhere they can have different names that distinguish them from the SID defined in the SRH draft.
>>>>>>>>> 
>>>>>>>>>> If the chairs insist on changing the name of the END SID, let's at least give it a new name.
>>>>>>>>> 
>>>>>>>>> To be clear, we didn’t insist, we made a suggestion that Darren adopted:
>>>>>>>>> 
>>>>>>>>> “We think calling it “END SID” makes it harder to understand, we had to go back to see if there were other SIDs defined that would have different behavior.   Since there is only one kind of SID defined, like FIRST SID.  We wonder if it can be just called “SID” and if in the future other SIDs are defined they can be called something else, for example "FOO SID”, or "SID 2”.  This is not a showstopper, but might make the document clearer.”
>>>>>>>>> 
>>>>>>>>> Bob
>>>>>>>>> 
>>>>>>> 
>>>>>>> --------------------------------------------------------------------
>>>>>>> IETF IPv6 working group mailing list
>>>>>>> [e-mail]
>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>> --------------------------------------------------------------------
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> [e-mail]
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>