Brian, > On Feb 28, 2020, at 2:46 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> > 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: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? >> >> >> >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
