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
