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

On Thu, 2 Jan 2020, 08:07 Robert Raszuk, <robert@raszuk.net> wrote:

> 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.
>

Can you elaborate on this further, or provide some links to descriptions of
these use cases?

This sounds a bit like an "intelligent network" vision.

That doesn't fit IPv6's architecture, prohibits encryption, and makes
scaling harder. There's a reason that the smart and complex functions are
done in hosts at the edge, and the network does dumb forwarding, and that
is it's much easier to scale.

Does it also mean that SR-MPLS shouldn't be used, or at least its possibly
severe SR limitations should be called out in SR-MPLS specs?

> 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 <rbonica@juniper.net> 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
>>
>> *From:* Ron Bonica
>> *Sent:* Monday, December 30, 2019 11:35 AM
>> *To:* Robert Raszuk <robert@raszuk.net>
>> *Cc:* SPRING WG <spring@ietf.org>
>> *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 <robert@raszuk.net>
>> *Sent:* Monday, December 30, 2019 8:41 AM
>> *To:* Ron Bonica <rbonica@juniper.net>
>> *Cc:* SPRING WG <spring@ietf.org>
>> *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 <rbonica@juniper.net> 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
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>