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

[Robert Raszuk <[e-mail]>]

Hi Mark,

I am the last one who would recommend you more state and more intelligence
or even new mapping into the network. Networks should just be dumb and
should be just able to forward IPv4 and IPv6 with proper QoS treatment.

All "extra functionality" is about the edges and service processing nodes.
Hint: take a look at Terastream architecture.

/* Disclaimer: Yes there is overlap of SRv6 in that respect with NSH - but
allow me not to get into this battle field here. I think both will continue
for a while fwd. */

For use case - There is a lot of them which I can see very useful. And
since some of them can be commercial value naturally are not to be
discussed in public. But I will illustrate just one ... Imagine today a
network connecting to some services it offers customers. Those can be IPv4
RFC1918 or IPv6 customers. Well if you do not want to turn each IPv4
customer into separate VPN you need to NAT (some of them may be coming with
the same address space to you). NAT has its own set of issues .. so one
alternative would be to encapsulate all of them into SRv6 and add into SRH
sufficient info about customer ID, function required, etc ... such that
your service can be accomplished. I can not see how to do that with
SR-MPLS.

I think your statement about fit into IPv6 architecture is coming from a
completely different perspective. Pls keep in mind that I am using IPv6 as
an encapsulation so my edge is the actual v6 host just taking a v6 payload.
Not also that those fancy service processing mentioned above Terastream
dpes are also all (at least originally) done by x86 IPv6 service nodes. In
IPv6 terminology those are real v6 hosts.

Ron started this thread trying to prove that SRv6 services can all be done
with SR-MPLS so why do we need SRv6 in the first place. While I am sure
bashing MPLS transport would be fun let's move it to some other forum and
form.

For networks already running MPLS transport and are really happy with it
SR-MPLS can provide few real benefits - one getting rid of LDP. By all
means great move. For those who in addition to some VPN support would also
like to enable some SR-MPLS for TE .. again very simple and incremental
change. Those folks should not hesitate and go for it.

But those who like to enable more services on their networks, those who
have extra spare capacity to accommodate SRv6 encap overhead, and those who
can think outside of their vendor manual - will likely see a benefit to
consider SRv6.

Btw I do think that EH addition to IPv4 is a good thing and SRv4 should be
defined and also progressed in SPRING.

Yes I just barely scratched the surface of the questions you posted. But
again I would like to highlight that the main decision of choice of SR-MPLS
vs SRv6 or maybe even SRv4 (one day) would be mainly dependent on given
network's transport protocol and service needs.

Best regards,
Robert.



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