Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

[Fernando Gont <[e-mail]>]

On 7/12/19 04:19, Suresh Krishnan wrote:
> (responding on spring mailing list)
> 
> Hi Fernando,
> 
>> On Dec 7, 2019, at 11:07 AM, Fernando Gont <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> On 6/12/19 23:47, Brian E Carpenter wrote:
>>> Again, comment at the end...
>>> On 07-Dec-19 14:37, Fernando Gont wrote:
>>>> On 6/12/19 22:15, Brian E Carpenter wrote:
>>>> [...]
>>>>>
>>>>>> and if such a thing is required, an update to RFC8200 should be done.
>>>>>
>>>>> Why does that follow? Alternatively,
>>>>> draft-ietf-spring-srv6-network-programming could acknowledge that
>>>>> it deviates from RFC8200.
>>>>
>>>> You can deviate from s "should", not from a "must". This is an outright
>>>> violation of a spec, rather than a mere "deviation".
>>>>
>>>>
>>>>> Whether that's acceptable would be a question for the IETF Last
>>>>> Call rather than any single WG.
>>>>
>>>> I would expect that a WG cannot ship a document that is violating an
>>>> existing spec, where the wg shipping the document is not in a position
>>>> of making decisions regarding the spec being violated.
>>>>
>>>> That would be like a waste of energy and time for all.
>>>>
>>>>
>>>>
>>>>> At the moment, the draft only mentions RFC8200 in a context that
>>>>> discusses neither insertion nor removal of extension headers, which
>>>>> is beside the point. Like draft-voyer, if it describes a violation
>>>>> of RFC8200, shouldn't that be explicit in the text?
>>>>>
>>>>> There's a lot of jargon in
>>>>> draft-ietf-spring-srv6-network-programming. I can't tell from the
>>>>> jargon whether "insert" means "insert on the fly" and whether "Pop
>>>>> the SRH" means "delete on the fly". Should those terms be clarified
>>>>> before the draft advances?
>>>>
>>>> Well, if it's not clear to you, it would seem to me that the simple
>>>> answer would be "yes".
>>>
>>> But if "insert" refers to the encapsulating node at the SR domain
>>> ingress, it's no problem, and if "pop" simply means doing normal
>>> routing header processing, it's no problem. It simply isn't clear in
>>> the text, at least not clear to me.
>>
>> The fact that a folk that has been deeply involved with IPv6 cannot
>> unequivocally tell what they talking about should be an indication with
>> respect to how ready the document is to be shipped.
>>
>> (pop when you are the destination but SL!=0 is essentially 'in the
>> network removal’)
> 
> It is not obvious to me why you think this is a violation of RFC8200
> though it is possible that I misread your comment. The relevant text I
> am looking at is
> 
> "  Extension headers (except for the Hop-by-Hop Options header) are not
>    processed, inserted, or deleted by any node along a packet's delivery
>    path, until the packet reaches the node (or each of the set of nodes,
>    in the case of multicast) identified in the Destination Address field
>    of the IPv6 header.”
> 
> which seems to permit it. Can you please clarify where there is a
> violation?

May I add:

1) For some reason, the mechanism is called Penultimate Segment Popping?
-- Does "penultimate segment" ring any bells?

2) A related question I have for you: Is IPv6 an end-to-end protocol?
(The answer to this question also serves as an answer for the rest).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492