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 <[email protected]>
Sent: Wednesday, January 1, 2020 4:07 PM
To: Ron Bonica <[email protected]>
Cc: SPRING WG <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
Cc: SPRING WG <[email protected]<mailto:[email protected]>>
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 <[email protected]<mailto:[email protected]>>
Sent: Monday, December 30, 2019 8:41 AM
To: Ron Bonica <[email protected]<mailto:[email protected]>>
Cc: SPRING WG <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> wrote:
Robert,
We should probably let the authors decide if that is part of the answer to my
question.
Ron
Juniper Business Use Only
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
