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:bob.hin...@gmail.com] Sent: Saturday, February 29, 2020 6:52 AM To: Brian Carpenter <brian.e.carpen...@gmail.com> Cc: Bob Hinden <bob.hin...@gmail.com>; Xiejingrong (Jingrong) <xiejingr...@huawei.com>; Ted Lemon <mel...@fugue.com>; Pablo Camarillo (pcamaril) <pcama...@cisco.com>; 神明達哉 <jin...@wide.ad.jp>; Joel M. Halpern <j...@joelhalpern.com>; spring@ietf.org; 6...@ietf.org 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 <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? >> >> >> > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
