Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Stefano Salsano <[e-mail]>]

Fernando,

Il 2020-02-27 10:07, Fernando Gont ha scritto:
> Bruno,
> 
> On 27/2/20 05:41, [e-mail] wrote:
>> Fernando,
>>
>>> -----Original Message-----
>>> From: ipv6 [mailto:[e-mail]] On Behalf Of Fernando Gont
>>> Sent: Thursday, February 27, 2020 12:45 AM
>>>
>>> Hello, Eric,
>>>
>>> On 26/2/20 20: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.
>>>
>>> Here's the proof part:
>>>
>>> 1) Isn't IPv6 end to end?
>>>
>>> 2) How do core components of IPv6, such as AH and PMTUD work in the
>>> present of intermediate nodes that can add and/or remove arbitrary
>>> extension headers?
>>>
>>> It should be clear from the above that EH insertion/deletion is 
>>> forbidden.
>>
>> This draft does not propose that intermediate node add extension header.
>>   - If this is not clear to you, please read the draft.
> 
> What is this:????
> 
> 4.16.1.  PSP: Penultimate Segment Pop of the SRH
> 
>     The SRH processing of the End, End.X and End.T behaviors are
>     modified: after the instruction "S14.  Update IPv6 DA with Segment
>     List[Segments Left]" is executed, the following instructions must be
>     executed as well:
> 
>   S14.1.   If (Segments Left == 0) {
>   S14.2.      Update the Next Header field in the preceding header to the
>                  Next Header value of the SRH
>   S14.3.      Decrease the IPv6 header Payload Length by the Hdr Ext Len
>                  value of the SRH
>   S14.4.      Remove the SRH from the IPv6 extension header chain
>   S14.5.   }
> 
> 
> Isn't this having the penultimate segment fo a packet removing an 
> extension header for a packet whose Destination Address is not even it's 
> own?

no, this is a wrong interpretation
the penultimate segment is removing the extension header for a packet 
whose Destination Address *is its own address*
> 
> Doesn't this read a bit as "the router was the DA of the packet, after 
> you change the DA to that of the next waypoint, if you realize Segments 
> Left == 0, remove the SRH"?
> 
> (which does not even comply with the now infamous "interpretation" of 
> RFC8200 that if you are the DA, you can add/remove EHs.

during the processing, as described in the pseudo code, there is an 
intermediate step in which the packet *processed inside the router* has 
the destination address of the last segment and the router removes the SRH

it is never suggested/allowed in the draft that a router can remove the 
SRH from a received packet that does not have a router address as DA

Stefano

> 
> 
> 
>>   - If it's clear, please let's stick to technical comment on _this_ 
>> draft. Bringing irrelevant points to the discussion is really not 
>> helping (both the discussion  and the argument).
>>
>> This draft does not propose that intermediate node add/or remove 
>> arbitrary  extension header.
>>
>> This draft, and more specifically the PSP flavor [1], is about 
>> removing the SRH header by an SR EndPoint.
> 
> Seriously?
> 
> 
>> - with regards to PMTUD, can you clarify how reducing the size of the 
>> packet break PMTUD? And if there is an impact, let's remember that 
>> this is the source of the packet which instruct the SR EndPoint to 
>> remove the SRH.
>> - with regards to AH, the SRH specification explicitly states that the 
>> use of SRH with AH by an SR source node is _not_ defined [2]. 
> 
> Do you understand that AH should be usable for all IPv6 traffic?
> 
> 
> [....]
>>> (that's what Errata's are for, after all... and it should be clear that
>>> the EH processing part, overall, needs improvements).
>>
>> Again, thank you for that, I believe this is useful.
>> But while this errata is not reviewed and accepted, RFC 8200 stands as 
>> is.
> 
> The errata is a clarification, not a change. Of course RFC8200 stands: 
> EHs are not deleted or added en route to destination.
> 
> 
> Thanks,


-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [e-mail]
Cell.   : [phone]
Office  : (Tel.) [phone] (Fax.) [phone]
*******************************************************************