Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

[Ron Bonica <[e-mail]>]

Hi Robert,

Three responses:

A)

What prevents SR-MPLS from evolving along the same path as SRv6?

B)

The uSID proposal introduces its own set of deployment issues, which have been discussed in depth on this list as well as on 6man.

C)

Could you be a little more specific about the failure scenario? In your model, who advertises SR-MPLS anycast SIDs to whom?

                                                                  Happy New Year,
                                                                           Ron


From: Robert Raszuk <[e-mail]>
Sent: Wednesday, January 1, 2020 4:07 PM
To: Ron Bonica <[e-mail]>
Cc: SPRING WG <[e-mail]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Hi Ron,

Three observations:

A)

I am afraid feature or capability parity between SRv6 and SR-MPLS is far from equal. Sure if you consider just TE or VPN applications one could draw such a conclusion. However where I see SRv6 evolving is actually into very flexible operator defined embedded functions with dynamic arguments.

Yes many legacy hardware will have issues to handle such processing, but one can hope that this will be smooth evolution where new hardware will replace incapable units. Those customers who will see a need to deploy such functionality will likely choose proper devices.

While P routers usually will not need such capabilities edge routers may do ... really soon :).

B)

Your claim and calculations that just say for TE over 8 segments with SRv6 you will need to burn 120 bytes does not consider uSID proposal. I would call it a bit unfair.

C)

> Only those of ABRs and ASBRs. Am I missing something?

Yes you are. Think that I want to simply remove LDP and happen to use option C across N ASes. Today with LDP and option C I need to handle 1000s of PEs FECs as top label in my VPN packets is remote PE. So with SR-MPLS I need all of those 1000s of PEs to be seen flat all over my domains or areas.

I realize that you may recommend to add SR stack to closest ABR/ASBR ... then another label to an other ABR/ASBR while looks cool on ppt in reality this is operationally broken idea.

When such ABR/ASBR fails I need to fall over to a backup one with local repair at its PHP. When each such label is different this does not work any more ... I need to go to src PE to adjust the packets.

Then you may say I may use anycast MPLS SID ... well that also looks nice on ppt only. Hint: not all ABRs/ASBRs lead to the same end networks.

So now please imagine the burden and amount of OPEX required only to keep MPLS transport on its life support ... for no good reason as compared with IP transport and basic IP longest match routing.

Best,
R.


On Wed, Jan 1, 2020 at 9:01 PM Ron Bonica <[e-mail]<mailto:[e-mail]>> wrote:
Robert,

A first attempt to answer the question follows.....

Generally speaking there is feature parity between SR-MPLS and SRv6. For example:


  *   Both can steer a packet through an SR path
  *   Both support flexalgo
  *   Both support fast reroute using TI-LFA
  *   Both can support service instructions

In terms of feature functionality, I can see only one difference between SR-MPLS and SRv6. That is, in SR-MPLS, the SR path is encoded in an MPLS label stack and the MPLS label stack is popped away at each segment endpoint. By contrast, in SRv6, the SR path is encoded in an SRH and the SRH is retained until it reaches the SR egress node. So, the SR egress node, in some case, can construct a reverse path from information contained in the SRH.

The difference between SR-MPLS and SRv6 isn't so much about feature functionality as it is about where each can be deployed. For example:


  *   SR-MPLS is applicable only in MPLS-capable networks
  *   SRv6 is applicable only in IPv6-capable networks
  *   SR-MPLS is applicable in networks where some SR paths contain a large number of segments. For example, if an SR-path contains 8 segments, it could be represented by an MPLS label stack that contains eight entries (i.e., 32-bytes, total).
  *   SRv6 is not applicable in networks where some SR paths contain a large number of segments. For example, if an SR-path contains 8 segments, it would be unreasonable to represent it with an SRH that contains 7 SIDS (i.e., 120 bytes, total).


Note......

Robert, in your previous email, you suggest SRv6 has a scaling advantage over SR-MPLS in networks where the SR domain spans any of the following:


  *   Two ISIS levels
  *   Two OSPF area
  *   Two Autonomous systems

Can you help with this section? In SR-MPLS, I am not sure that every node SID needs to be leak across boundaries. Only those of ABRs and ASBRs. Am I missing something?

                                                                            Ron








Juniper Business Use Only


Juniper Business Use Only
From: Ron Bonica
Sent: Monday, December 30, 2019 11:35 AM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Robert,

I just realized that you are a contributor. So, I will take that as an invitation to contribute my two cents.

Please stand by. It will take an hour or two to craft a well-considered response and it may not be ready before I shut down for the holiday.

                                                                                Happy New Year,
                                                                                   Ron

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Monday, December 30, 2019 8:41 AM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Ron,

I beg your pardon, but what are you trying to say?

Isn't this a WG document now and *any* WG member is fully entitled to comment on any question asked or point being raised ? Leave alone formal document contributor.

Are you saying that answers from those listed on top of the draft carries more weight ? Is this some new IETF process you are trying to define here ?

Once document transitions to WG doc status authors who own src are becoming just editors with the obligation to incorporate WG suggested changes which got approved via rough consensus as judged by chairs. Are you questioning that too ?

Thx,
R.

On Mon, Dec 30, 2019 at 1:19 PM Ron Bonica <[e-mail]<mailto:[e-mail]>> wrote:
Robert,

We should probably let the authors decide if that is part of the answer to my question.

                                                                             Ron


Juniper Business Use Only