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

Jingrong & Bruno

Here is another point for consideration related to PSP.

Drawing an analogy here between MPLS and SRv6 as SRv6 would be the Next Gen
replacement of MPLS.

Topology

A - B - C

An LSP is uni directional where the path to  FEC destination egress PE  can
be in either direction where the LSP is built from A to C with PHP node B
-and an LSP is built in the reverse direction from C to A with PHP node B.

This same philosophy applies to SR both SRv6 and SR-MPLS.

So the thought that the final destination egress PE node has legacy
hardware with SRH processing limitations would apply to all PEs, both the
SR source node which would be acting as a destination node for an LSP as
well  in the reverse direction.

So the idea that PSP is beneficial for the final destination egress PE
legacy node old hardware does not make sense.

As I mentioned to Pablo all the heavy lifting routing protocols heavy
processing is done on the PEs and not the P routers.  However due to the
scenario described above you can get away with not upgrading the P transit
nodes in being SRv6 capable but you really have no choice and have to
upgrade all your PEs to be SRv6 capable.

Kind regards

Gyan

On Fri, Feb 28, 2020 at 9:14 PM Xiejingrong (Jingrong) <
xiejingrong@huawei.com> wrote:

> Got it.
> Thanks for your clarification of your point.
>
> Jingrong
>
> -----Original Message-----
> From: 神明達哉 [mailto:jinmei@wide.ad.jp]
> Sent: Saturday, February 29, 2020 9:28 AM
> To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>
> Cc: Ted Lemon <mellon@fugue.com>; Pablo Camarillo (pcamaril) <
> pcamaril@cisco.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>; Bob
> Hinden <bob.hinden@gmail.com>; Joel M. Halpern <jmh@joelhalpern.com>;
> spring@ietf.org; 6man@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
>
> At Fri, 28 Feb 2020 07:54:28 +0000,
> "Xiejingrong (Jingrong)" <xiejingrong@huawei.com> wrote:
>
> > 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.
>
> No, it violates Section 4 of RFC8200.  It's a pity that we have to discuss
> it at this level due to the poor editorial work then (I was also
> responsible for that as one of those reviewing the bis draft), but anyone
> who involved the discussion should know the intent of this text intended to
> say (borrowing from Ron's text) "Extension headers cannot be added to a
> packet after it has left the its source node and extension headers cannot
> be removed from a packet until it has arrived at its ultimate
> destination".  It might look "an attempt of blocking an innovation by a
> small group of vocal fundamentalists", but if you see the responses without
> a bias, you'd notice that even some of those who seem neutral about the
> underlying SRv6 matter interpret the text that way.
>
> I'd also note that simply because PSP violates RFC8200 doesn't immediately
> mean it (PSP) "needs to change".  It can update RFC8200 with explaining why
> it's necessary and justified.  That's what I requested as you summarized:
>
> > Jinmei: it should say it updates this part of RFC8200 and explain why
> it's justified.
>
> And, since PSP at least wouldn't break PMTUD, I guess the update proposal
> will have much more chance to be accepted than a proposal including EH
> insertion.  On the other hand, pretending there's no violation will
> certainly trigger many appeals and objections at the IETF last call (I'll
> certainly object to it).  In the end, it can easily take much longer, or
> even fail, than formally claiming an update to RFC8200.
>
> --
> JINMEI, Tatuya
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com