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

[Gyan Mishra <[e-mail]>]

Along those same lines of thought.

If you upgrade all your source SR node ingress PEs to be SRv6 capable you
have in fact upgraded all your final destination egress PE nodes to be SRv6
capable.

Gyan

On Fri, Feb 28, 2020 at 9:37 PM Gyan Mishra <[e-mail]> wrote:

> 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) <
> [e-mail]> wrote:
>
>> Got it.
>> Thanks for your clarification of your point.
>>
>> Jingrong
>>
>> -----Original Message-----
>> From: 神明達哉 [mailto:[e-mail]]
>> Sent: Saturday, February 29, 2020 9:28 AM
>> To: Xiejingrong (Jingrong) <[e-mail]>
>> Cc: Ted Lemon <[e-mail]>; Pablo Camarillo (pcamaril) <
>> [e-mail]>; Brian E Carpenter <[e-mail]>;
>> Bob Hinden <[e-mail]>; Joel M. Halpern <[e-mail]>;
>> [e-mail]; [e-mail]
>> 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)" <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]