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

[Ron Bonica <[e-mail]>]

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
From: Ron Bonica
Sent: Monday, December 30, 2019 11:35 AM
To: Robert Raszuk <[e-mail]>
Cc: SPRING WG <[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