Re: [spring] Regaining Focus on SRv6 and SRv6+

[Mark Smith <[e-mail]>]

Hi,

On Sat, 7 Sep 2019 at 18:08, Huzhibo <[e-mail]> wrote:
>
> Hi Mark:
> I don't think it's a good idea to implement SR with IPv4.
> 1: Sid must be globally unique within a large range to achieve unobstructed routing capabilities,

20 bit MPLS label values are not globally unique. Why is this not a
problem for SR over MPLS?

I'm not sure what you mean by "global" because I've seen in passing
that "global" in SR means "global" to the local network. We in the
IPv6 world consider "global" to mean the global Internet - RFC 2374,
"An IPv6 Aggregatable Global Unicast Address Format".

If you mean actual global, then surely MPLS 20 bit labels would be
creating even more problems for SR?

 >so we need at least 16 Bit to identify the node.

In closed network you could have the entire IPv4 unicast address space
to identify nodes.

> It also needs to mark the device's Function, which also requires 12~16 Bit. So I think Sid needs at least 32 Bits. Considering that for aggregation, we need to make some planning for the node ID designation, which will waste some Bit. In addition, the implementation of the Function may require some additional parameters, so it is likely to exceed 32 Bit.

Again, SR over MPLS and 20 bits for SIDs?

More broadly, where is the analysis of the size of the SID space
required for SR functions that is independent of the underlying
carriage protocol identifiers?

How do we know how many underlying protocol identifier bits are too
small, too big or good enough?

MPLS 20 bit labels are sounding too small for SIDs from what you've
said above, where as IPv6 128 bit addresses are too big because of the
overhead they incur when using them as SIDs.

What is the minimum and maximum number of bits acceptable for a SID?

> 2: IPv4 does not have an extension header definition, which actually introduces some factors that are not compatible with normal IPv4.

That's not entirely correct. IPv4 has options. IPv6 EHs are a more
generalised version of them.

Tom Herbert is proposing IPv6 equivalent IPv4 EH's here:

"IPv4 Extension Headers and Flow Label"
https://tools.ietf.org/html/draft-herbert-ipv4-eh-01


> 3: The evolution of IPv4 to IPv6 is a big trend, and we must prepare for the future.
>

I think reusing IPv4 for SR is entirely valid if it provides enough
significant advantages over IPv6 over SR.

I do believe it that fundamentally it would be better to have a single
layer 3 protocol in a network, however give me a choice of EH
insertion or using IPv4 for SR, and I'll take SR over IPv4 every day
of the week.

The SR over IPv4 packets would have source addresses in them that
identify the device that performed the SR functions as IPv6-in-IPv4
encapsulation would be used.

EH insertion is entirely anonymous. If something breaks, you have no
idea of which device inserted the EH. That's a potential
troubleshooting nightmare, in particular if the packet transited a
number of ASes over the Internet, and you have to contact each one to
determine if they're inserting EHs or not. That's potentially weeks of
troubleshooting, and weeks of angry customers, and likely much lost
business.

If the future of network automation involves automated troubleshooting
and fault rectification, then I'd guess resolving faults involving
anonymous EH insertion would make automating troubleshooting quite
hard if not impossible in some scenarios. On the other hand, if
actions have attribution through identifying source addresses, I think
automating troubleshooting would be far easier. Troubleshooting is
much easier if you're able to start with already knowing who did what.

EH insertion sounds to me like it is breaking a fundamental principle
of trying to avoid sending something unexpected and that the receiver
will be confused by.

"Be conservative in what you send, ..."

Regards,
Mark.


> Thank you
> Zhibo
> -----Original Message-----
> From: Mark Smith [mailto:[e-mail]]
> Sent: Saturday, September 07, 2019 2:04 PM
> To: Huzhibo <[e-mail]>
> Cc: Robert Raszuk <[e-mail]>; Ron Bonica <rbonica=[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
>
> On Sat, 7 Sep 2019 at 14:58, Huzhibo <[e-mail]> wrote:
> >
> > Hi Robert:
> >
> >
> >
> > Agree with you.
> >
> > SRv6 is a completely different technology from SR MPLS. The biggest difference is that SRv6's Sid itself has routing capabilities. For example, it is aggregatable, it is programmable, it is globally unique over a larger scope. of. Sid's routing capabilities bring many benefits to the network. For example: network scalability, reliability, and simplified Overlay programming. So, I think that any optimization we do for SRv6 should not sacrifice Sid's own routing capabilities. If we just want to solve the interoperability problem between MPLS network and IP network, we can solve this problem in the field of SR MPLS.
> >
> >
>
> Does any network need a SID space that is literally bigger than the combination of both the current and and any possible future IPv6 unicast address space?
>
> It's tempting to write up SR over IPv4, because IPv4 is currently a far more commodity technology than both MPLS and IPv6, probably on some metrics in the order of one or more magnitudes, well known, well proven, well understood, would leverage existing IPv4 implementations of which there are many, and would have only have 32 bit SIDs, so the tunnelling overhead cost would be much lower than 128 bit SIDs as a result of using IPv6 addresses for SIDs.
>
>
> >
> > Thank you,
> >
> > Zhibo
> >
> >
> >
> > From: spring [mailto:[e-mail]] On Behalf Of Robert
> > Raszuk
> > Sent: Friday, September 06, 2019 9:33 PM
> > To: Ron Bonica <rbonica=[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
> >
> >
> >
> > Dear Ron,
> >
> >
> >
> > I think you forgot few main points in the summary:
> >
> >
> >
> > * Many operators use SR-MPLS successfully and it has been both
> > standardized and successfully deployed in the network with
> > interoperable implementations
> >
> >
> >
> > * The overhead on the data plane of SRv6+ is very comparable to
> > overhead of SR-MPLS
> >
> >
> >
> > * The control plane extensions BGP, IGP are available for SR-MPLS and
> > non are available for SRv6+
> >
> >
> >
> > * SRv6+ requires a new mapping of SIDs to prefixes to be distributed
> > by control plane
> >
> >
> >
> > * If operators choose not to use MPLS transport SR-MPLS can be easily
> > transported over IPv4 or IPv6 vanilla data plane
> >
> >
> >
> > * Extensions for additional applications like L3VPNs or L2VPNs will require another set of protocol and implementation changes.
> >
> >
> >
> > * If there are vendors who do not want to provide SR-MPLS SID mapping to IPv6 addresses in their control planes let's focus standardization and industry work in this direction.
> >
> >
> >
> > With all of the above I think it would be a serious mistake - at this point of time - to continue work on SRv6+ in the IETF.
> >
> >
> >
> > Thank you,
> >
> > Robert.
> >
> >
> >
> >
> >
> > On Fri, Sep 6, 2019 at 3:08 PM Ron Bonica <rbonica=[e-mail]> wrote:
> >
> > Folks,
> >
> >
> >
> > We have explored many facets of SRv6 and SRv6, sometime passionately. I think that this exploration is a good thing. In the words of Tolkien, “All who wander are not lost.”
> >
> >
> >
> > But it may be time to refocus on the following:
> >
> >
> >
> > For many operators, SRv6 is not deployable unless the problem of
> > header length is addressed Many objections the uSID proposal remain
> > unanswered
> > SRv6+ offers an alternative solution
> >
> >
> >
> > Given these three facts, I think that it would be a mistake to discontinue work on SRv6+.
> >
> >
> >
> >
> > Ron
> >
> >
> >
> >
> >
> > Juniper Business Use Only
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------