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

["Xiejingrong (Jingrong)" <[e-mail]>]

Got it.
So the gap may be the 'protocol spec' and the 'code/implementation reality'.
"a non-SRV6 capable router receives SRV6 with segments-left == 0" may have many reasons not implemented this well ---- If Segments Left is zero, the node must ignore the Routing header with an unrecognized Routing Type value.
It may just drop any packet with Next Header value other than 4/41/47/etc. 
It may send such packet with any routing header to its slow-path for the compliance but lose the necessary performance.
I guess the proposal of PSP is only to solve that kind of engineering problems for deployment, and that's why I think once that is not necessary it should not be recommended.

Thanks
Jingrong

-----Original Message-----
From: Bob Hinden [mailto:[e-mail]] 
Sent: Saturday, February 29, 2020 6:52 AM
To: Brian Carpenter <[e-mail]>
Cc: Bob Hinden <[e-mail]>; Xiejingrong (Jingrong) <[e-mail]>; Ted Lemon <[e-mail]>; Pablo Camarillo (pcamaril) <[e-mail]>; 神明達哉 <[e-mail]>; Joel M. Halpern <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Brian,

> On Feb 28, 2020, at 2:46 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> Hi Jingrong,
> 
> Thanks for your suggestion.
> 
>> so that the tunnel endpoint
>> router (C) doesn't have to deal with SRH.
> 
> Actually, why does this matter? RFC8200 already handles this case:
> 
>   If, while processing a received packet, a node encounters a Routing
>   header with an unrecognized Routing Type value, the required behavior
>   of the node depends on the value of the Segments Left field, as
>   follows:
> 
>      If Segments Left is zero, the node must ignore the Routing header
>      and proceed to process the next header in the packet, whose type
>      is identified by the Next Header field in the Routing header.
> 
> If a non-SRV6 capable router receives SRV6 with segments-left == 0, it 
> must ignore it. (So why is PSP needed at all?)

Good point and question.   This is why there is a common base format for all IPv6 routing headers, it allows for this case.

Bob


> 
> Regards
>   Brian
> 
> On 28-Feb-20 20:54, Xiejingrong (Jingrong) wrote:
>> Hi
>> 
>> 
>> 
>> Thanks Ted for the constructive suggestions, which remind me to try to understand the questions. Here are the questions I think give the clear suggestions for LC.
>> 
>> 
>> 
>> Brian: So could the draft make this explicit, because I guarantee you it is not in the least obvious to the non-expert reader?
>> 
>> 
>> 
>> Jinmei: it should say it updates this part of RFC8200 and explain why it's justified.
>> 
>> 
>> 
>> Joel: it would seem that there ought to be a good reason for including PSP, rather than claiming that objectors need to motivate removing it.
>> 
>> 
>> 
>> Bob: There seems to be questions about its relationship with RFC8200.  I am not seeing this as being resolved.
>> 
>> 
>> 
>> As far as I understand the concern and the draft, I may have the following proposed text, though I don’t know if that will help to close or narrow the gap:
>> 
>> 
>> 
>> ****Proposed text to explicitly explain the PSP at the end of 4.16.1 
>> of rev-10****
>> 
>> 
>> 
>> Note that, the SRH is used in an X-in-IP6 tunnel end point case, that 
>> is, router (A)
>> 
>> imposes an SRH, and a Penultimate Segment router (B) removes the SRH 
>> before
>> 
>> this packet goes to the tunnel end point router (C), so that the 
>> tunnel endpoint
>> 
>> router (C) doesn't have to deal with SRH.
>> 
>> 
>> 
>> This has some very important benefits for deployment in some networks 
>> when the
>> 
>> final tunnel end point is a lower-end node which is not capable of 
>> processing
>> 
>> the SRH for reasons like the hardware is overloaded or unable to 
>> upgraded to
>> 
>> process well with SRH.
>> 
>> 
>> 
>> The use of SRH with AH by an SR source node, and processing at a SR 
>> Penultimate
>> 
>> segment endpoint node is not defined in 
>> <draft-ietf-6man-segment-routing-header>
>> 
>> or in this document.
>> 
>> 
>> 
>> The use of PSP does not impact the MTU Considerations defined in 
>> section 5.3 of
>> 
>> <draft-ietf-6man-segment-routing-header>.
>> 
>> 
>> 
>> The design of PSP for the benefits of deployment is based on the 
>> understanding
>> 
>> that it does not violate section 4 of RFC8200. In case the RFC8200 
>> text may be
>> 
>> modified in the future, the PSP may also need to change accordingly.
>> 
>> 
>> 
>> In case the final tunnel endpoint router is fully capable of the 
>> functionality
>> 
>> of SRH and the SRv6-NP defined in this document, it is recommended 
>> not to use
>> 
>> the PSP.
>> 
>> 
>> 
>> ***End****
>> 
>> 
>> 
>> Thanks
>> 
>> Jingrong
>> 
>> 
>> 
>> 
>> 
>> *From:*spring [mailto:[e-mail]] *On Behalf Of *Ted 
>> Lemon
>> *Sent:* Friday, February 28, 2020 4:55 AM
>> *To:* Pablo Camarillo (pcamaril) <[e-mail]>
>> *Cc:* [e-mail]; [e-mail]
>> *Subject:* Re: [spring] Request to close the LC and move forward//RE: 
>> WGLC - draft-ietf-spring-srv6-network-programming
>> 
>> 
>> 
>> On Feb 27, 2020, at 3:38 PM, Pablo Camarillo (pcamaril) <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>    The discussion that we are having is about PSP which has nothing to do with that.
>> 
>> 
>> 
>> So, there is text in the document that addresses Brian’s question?
>> 
>> 
>> 
>