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?)
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:spring-boun...@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Friday, February 28, 2020 4:55 AM
> *To:* Pablo Camarillo (pcamaril) <pcama...@cisco.com>
> *Cc:* spring@ietf.org; 6...@ietf.org
> *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) <pcama...@cisco.com
> <mailto:pcama...@cisco.com>> 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?
>
>
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
