Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

[Fernando Gont <[e-mail]>]

On 11/12/19 13:37, [e-mail] wrote:
[....]
>>>>>
>>>>> Please read this document if you haven't read the most recent version,
>>>>> and send your comments to the SPRING WG list, no later than December 20.
>>>>>
>>>>>  
>>>>>
>>>>> You may copy the 6MAN WG for IPv6 related comment, but consider not
>>>>> duplicating emails on the 6MAN mailing list for the comments which are
>>>>> only spring specifics.
>>>>>
>>>>>  
>>>>>
>>>>> If you are raising a point which you expect will be specifically debated
>>>>> on the mailing list, consider using a specific email/thread for this point.
>>>>>
>>>>> This may help avoiding that the thread become specific to this point and
>>>>> that other points get forgotten (or that the thread get converted into
>>>>> parallel independent discussions)
>>>>
>>>> Penultimate Segment Popping describes/specifies the removal of a SRH at
>>>> a place other than the final destination of the packet.
>>>>
>>>> Such behavior violates RFC8200, which specifies:
>>>>
>>>    > 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.
>>>>
>>>> Note, of course, that the reference of "Destination Address" in RFC8200
>>>> is clearly the final destination of the packet -- for instance, RFC8200
>>>
>>> I hear and can understand your reading of RFC8200.
>>
>> Could you please check RFC8200, and tell me what other possible
>> interpretation of "Destination Address" you might have, in the context
>> of RFC8200.
> 
> Another interpretation is
> "the node [...] identified in the Destination Address field of the IPv6 header."
> https://tools.ietf.org/html/rfc8200#section-4
> 
>  Actually, that's verbatim the text from RFC 8200.

IN the context of RFC8200, that does not specify any routing header
type, what could be in the Destination Address other than the final
destination?



>> RFC8200 does not even specify any routing header types. SO...where's the
>> ambiguity?
> 
> - Read the mailing list and you will see that everyone do not share your opinion.

Yes, folks have also argued in the past that RFC2460 allowed EH insertion.


> So at least one person is wrong. I think that it would help if everyone, including you, could consider 
>that they/you _may_ be wrong, at least to better understand the
comments been made by others.  And possibly the text from RFC 8200 is
not clear, but this is what we have. And this is the text to use to
support the claim that this text is violated.
> - Why have _you_ filled an errata against RFC 8200, in order to change the technical content of this section, if you don't agree that one may red " Destination Address field of the IPv6 header" as the IPv6 address present in the Destination Address field of the IPv6 header been received by the End node (or even sent by the source node)
> https://www.rfc-editor.org/errata/eid5933

For the very same reason that the wg agreed including myself) to try to
clarify that EH insertion wasn't allowed: because folks were making
claims that they could.

FWIW, the errata does not change the technical meaning, but is provided
a clarification.

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