On 28-Feb-20 15:06, Stefano Salsano wrote:
> Brian,
>
> Il 2020-02-28 02:47, Brian E Carpenter ha scritto:
>> Stefano,
>>
>> The problem is that the draft simply doesn't explain (or refer to an
>> explanation) of what this "penultimate segment" is. There are at least three
>> hypotheses which I suspect different people are using, leading to this
>> endless dialogue:
>>
>> 1) It's a forwarding node, a.k.a. a router, that blindly follows the PSP
>> instructions by removing an IPv6 header before forwarding the packet,
>> completely against the text of RFC 8200.
>
> it is a forwarding node, a.k.a. a router, which follows the PSP
> instructions and removes the SRH before forwarding the packet
So could the draft make this explicit, because I guarantee you it is not in the
least obvious to the non-expert reader?
> let me disagree with you on the part "completely against the text of RFC
> 8200" :-)
You are trying to squeeze through a very small hole in the relevant paragraph
of RFC8200. Either the draft should not do that, or it should explain precisely
what this hole is, so that the IETF & IESG can decide whether they agree.
Let's be clear, we're talking about a routing header which in some unclear
circumstances instructs a certain router to delete the header en route. It's
unclear because the draft doesn't really explain the "flavors" such as PSP or
how a router knows algorithmically when to apply the PSP flavor. I don't see
how that can be left as an implementation issue.
Regards
Brian
>
> Stefano
>
>>
>> 2) It's a node that receives and terminates the packet, and then makes a new
>> one with its own address as source and a new (ultimate) destination address,
>> which doesn't happen to contain an SRH header at all.
>>
>> 3) It's an offload processor in the destination node, that removes some crud
>> (the SRH header) before passing the packet up to the IPv6 stack in the host.
>>
>> At the moment, a reader of the draft who is not familiar with the details of
>> at least one SRH implmentation cannot decide which of these hypotheses is
>> correct.
>>
>> Despite numerous requests, and several new versions, the draft still leaves
>> this mystery intact, and is therefore simply not ready for the IESG.
>>
>> So I repeat my request for the draft to explain what it means by "pop" and
>> by "penultimate segment". If it turns out that we are in case 2) or 3)
>> above, problem solved.
>>
>> Regards
>> Brian Carpenter
>>
>> On 28-Feb-20 00:42, Stefano Salsano wrote:
>>> Brian,
>>>
>>> Il 2020-02-27 03:29, Brian E Carpenter ha scritto:
>>>> Stefano,
>>>> On 27-Feb-20 14:42, Stefano Salsano wrote:
>>>>> Il 2020-02-27 02:14, Brian E Carpenter ha scritto:
>>>>>> Eric,
>>>>>>
>>>>>> On 27-Feb-20 12:18, Eric Vyncke (evyncke) wrote:
>>>>>>> Writing this without any hat,
>>>>>>>
>>>>>>> Please note that on the logical side, it still have to be "proven" that
>>>>>>> this idea is strictly forbidden by RFC 8200.
>>>>>>
>>>>>> The draft uses an undefined term ("pop") but it does *explicitly* state
>>>>>> in a section called "Penultimate Segment Pop of the SRH":
>>>>>>
>>>>>>>> S14.4. Remove the SRH from the IPv6 extension header chain
>>>>>>
>>>>>> If the word "penultimate" means what it means in every dictionary, this
>>>>>> is in-flight removal of a header, and that is explicitly against RFC
>>>>>> 8200, section 4, first paragraph below the diagram.
>>>>>
>>>>> Brian,
>>>>>
>>>>> "penultimate segment" means what it means in every dictionary, but this
>>>>> is not in-fligth removal of a header.
>>>>>
>>>>> When the packet has reached the "penultimate segment", it has reached a
>>>>> node "identified in the Destination Address field of the IPv6 header" as
>>>>> stated in RFC 8200, section 4, first paragraph below the diagram
>>>>
>>>> So in what sense is it penultimate (i.e. next to last)? If it has reached
>>>> the destination address,
>>>
>>> if the segment list is [S1, S2, S3] (where S1 is the first segment and
>>> S3 the final destination)
>>>
>>> S2 is the penultimate segment and the packet is received by S2 with
>>> Destination Address = S2, I repeat that at the very end of section 3 of
>>> RFC 8200 the "Destination address" is defined as "address of the
>>> intended recipient of the packet (possibly not the ultimate recipient,
>>> if a Routing header is present)"
>>>
>>>> what happens next?
>>>
>>> next the packet needs to be forwarded to S3
>>>
>>>> I understand this for the following case, Ultimate Segment Pop, where the
>>>> text refers to processing the packet inside the receiving node. But the
>>>> text is completely lacking an explanation of the "penultimate" case,
>>>> and I found nothing about it in other SRH documents either.
>>>>
>>>> If I was writing code for this, I would have no idea how to generate a
>>>> test case.
>>>>
>>>> It's also obscure in the text how the node receiving a packet knows
>>>> which of "PSP, USP and USD flavors" applies. They don't seem to be marked
>>>> in the packet in any way.
>>>
>>> it is not marked in the packet, likewise it is not marked in the packet
>>> which SRv6 behavior is associated with a SID
>>>
>>> Stefano
>>>
>>>>
>>>> It seems to me that there is something blindingly obvious to SRH
>>>> specialists
>>>> that is not stated at all in the draft, so the rest of us simply can't make
>>>> sense of it. It may or may not be a gap in the protocol, but there is
>>>> definitely a gap in the description.
>>>>
>>>> Brian
>>>>
>>>>>
>>>>> Please note that at the very end of section 3 the "Destination address"
>>>>> is defined as "address of the intended recipient of the packet (possibly
>>>>> not the ultimate recipient, if a Routing header is present)"
>>>>>
>>>>> Stefano
>>>>>
>>>>>>
>>>>>> It's possible that "penultimate" means something else, e.g. "ultimate".
>>>>>> I don't know. I've been puzzling over this language for months and it
>>>>>> doesn't change. Maybe someone can finally post an explanation, but until
>>>>>> they do, I don't see how any WG Chair could assert rough consensus. An
>>>>>> obviously organised +1+1+1+1 campaign is not consensus. I don't know
>>>>>> about you, but when I see a message whose only content is "+1" I just
>>>>>> delete it.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>> Moreover, this 'proof' can technically wait until the IETF last call or
>>>>>>> even until the IESG ballot. I see little point in postponing the
>>>>>>> closing of the WGLC and advancing the document (of course, the document
>>>>>>> shepherd will need to carefully write the section about the rough WG
>>>>>>> consensus).
>>>>>>>
>>>>>>> Finally, as far as I know, at the IETF we have no religion... else we
>>>>>>> would still be running NCP or IPv4 :-)
>>>>>>>
>>>>>>> -éric
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: ipv6 <ipv6-boun...@ietf.org> on behalf of Warren Kumari
>>>>>>> <war...@kumari.net>
>>>>>>>
>>>>>>> ...%<...%<....
>>>>>>>
>>>>>>> It doesn't really matter how many people say +1 for moving it
>>>>>>> forwards
>>>>>>> -- if there are valid technical objections these have to be
>>>>>>> dealt with
>>>>>>> - and I think that the relationship with RFC8200 falling into
>>>>>>> this
>>>>>>> category...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>> IETF IPv6 working group mailing list
>>>>>>> i...@ietf.org
>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>> --------------------------------------------------------------------
>>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> i...@ietf.org
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
