Re: [spring] Beyond SRv6.

[James Guichard <[e-mail]>]

There are a number of techniques that could be used to reduce the depth without having to resort to a new encapsulation beyond SRv6; uSID is one of course, but there is also https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00 and we could probably find others if those do not suffice.

Jim

From: spring <[e-mail]> On Behalf Of Andrew Alston
Sent: Sunday, September 01, 2019 5:30 PM
To: Robert Raszuk <[e-mail]>
Cc: Ron Bonica <rbonica=[e-mail]>; Rob Shakir <[e-mail]>; SPRING WG List <[e-mail]>; [e-mail]
Subject: Re: [spring] Beyond SRv6.

Robert,

CRH works just fine with the deep label depth in our testing of it.  As I stated in my previous emails – There are a number of issues with uSID that I can see – and I won’t repeat all of those here again.  There are a whole number of aspects going through that network map that do not give a full picture – multiple paths of unequal sizes – multiple circuits between locations that aren’t clearly shown there for diversity sake – and a whole heap of other issues.  You need to realize that steering in our case is not just about diversity – there are many reasons why we steer and why our customers wish us to steer – and glancing at a network map like that will not give you close to a full picture.  Those reasons can range from everything from latency to geopolitical issues.

Then again – as an operator – I have always believed in having the choice – and as I stated in previous emails – in the networking world we have many alternatives to many things – and I went as far as to propose writing an inter-op draft so that both CRH and uSID could move forward rather than both ending up stalled, or worse will, one or the other ending up as proprietary – and I may well still get around to doing this – time has just been a little hectic of late.

Andrew

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Sunday, 1 September 2019 at 22:28
To: Andrew Alston <[e-mail]<mailto:[e-mail]>>
Cc: Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>, Rob Shakir <[e-mail]<mailto:[e-mail]>>, SPRING WG List <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

Looking at your network topology https://www.liquidtelecom.com/about-us/network-map.html<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.liquidtelecom.com%2Fabout-us%2Fnetwork-map.html&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf0a022c330834a1e566608d72f239a10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637029702293736173&sdata=hYeOsxSIOnzzty%2FxD3XK%2FanUUKvPzu7UyP%2F3VWM1Kl0%3D&reserved=0> yes indeed you need to pass via number of countries, but keep in mind that SR is not a routing protocol.

Even focusing on your longest data paths say from Cairo to Cape Town I really see no use for more then optimally chosen 3 or 4 SIDs to well diversify the flows to traverse different end to end paths then your routed default.

Now if your desire is to provide for all the possible data flows per each ECMP link group forwarding control then I see counting adj SIDs you can get to 10 SIDs or more. But is SRv6 then optimal tool in the toolkit to accomplish that ?

But assume it is how about use of uSID combination with SRH such that you can have your requirements well satisfied in the current network regardless if alternative design or alternate network architecture exists or not ?

Thx,
Robert.


On Sun, Sep 1, 2019 at 9:47 PM Andrew Alston <[e-mail]<mailto:[e-mail]>> wrote:
I can state categorically that we have a solid case to use 8 to 12 SID’s –

Let me put it this way – If I cross my own network – To get to certain countries I have to pass through no less than 5 separate countries in certain scenarios – and it’s not practically possible to avoid this.  When I add the various paths we need to steer across and the numbers of devices to do this in a granular way – with the amount of meshing we have to do to achieve redundancy – yes – it gets complex – and yes – the node depth gets deep.

Our case of needing granular steering here – without necessarily going lose – is ironclad – and I can say that right now, 10 node steering for certain cases is 100% a reality for what we need.

Andrew


From: spring <[e-mail]<mailto:[e-mail]>> on behalf of Ron Bonica <rbonica=[e-mail]<mailto:[e-mail]>>
Date: Sunday, 1 September 2019 at 21:00
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: Rob Shakir <[e-mail]<mailto:[e-mail]>>, SPRING WG List <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] Beyond SRv6.

Robert,

I can only repeat what my customers’ requirements. They have asked for 8-12 SIDs in SR-MPLS and SRv6 and SRv6+.

We didn’t question that requirement for SR-MPLS. Why should things be any different for SRv6 or SRv6+?

                                                                      Ron




From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, September 1, 2019 11:03 AM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>
Cc: Rob Shakir <[e-mail]<mailto:[e-mail]>>; SPRING WG List <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [spring] Beyond SRv6.

Dear Ron,

> SR customers have stated a firm requirement to support SR paths that contain 8 to 12 segments.

Let me make an observation that with 8 to 12 router hops I can reach most of my often visited destinations in the open Internet anywhere in the world.

With that let's also notice that proposed SRv6 (or for that matter SR-MPLS) is applicable to networks under same administrative control.

Therefor I do question the necessity to have such deep/long list of segments for any practical network application.

Perhaps some customers (or vendors) are treating SRv6 verbatim as an analogy to RSVP-TE strict or loose ERO objects - but that is completely wrong way to think about it in light of segment routing architecture and its abilities.

In RSVP-TE you nail down the path with hop by hop RESV-PATH msg signalling such that forwarding is using locally upstream assigned labels distributed by return RSVP-RESV msg.

I would never suggest to do same with SR. The biggest advantage of SR (outside of its network programmability concept) is in the ability to encode very selected anchor node or nodes to which forwarding just flows natively using IPv6 address or domain wide MPLS label.

So proper use of SR does require wise selection of such anchor points in the network. I am afraid CSPF is not the best tool for it. Much smarter algorithm is required to engineer your traffic using SR technology in any network especially in cases where the IGP topology is very dense and complex.

Based on my personal experience with MPLS-TE deployments across biggest global networks I  can state that vast majority of true path steering can be easily accomplished with 1, 2 or max 3 properly selected anchor nodes across their domain(s). Add to that room for two SFC processing clusters and you get max 5.

So even if some individual operators would like to use 8, 12 or maybe 16 segments in their packets I do not see this as fundamentally sufficient justification to proceed with yet one more SRv6 encoding proposal.

As both Rob & Bruno asked I will be looking for real technical justifications for such deep segment stacks. Note that we are at the end of 4 week pool window and there was none sent to the list so far.

Kind regards,
Robert.


On Sat, Aug 31, 2019 at 10:34 PM Ron Bonica <rbonica=[e-mail]<mailto:[e-mail]>> wrote:
Rob,

The following are arguments for proceeding with SRv6+:


  *   Efficient forwarding with deep SID lists
  *   Operational Simplicity
  *   SRv6+ work may finish before SRv6

Efficient forwarding with deep SID Lists
----------------------------------------------------

SR customers have stated a firm requirement to support SR paths that contain 8 to 12 segments. They have also stated a requirement for implementations to forward at line speed  and without consuming excessive overhead bandwidth.

SRv6, as defined in draft-ietf-6man-segment-routing-header, cannot satisfy these requirements. In order to support an SR path with 8 segments, SRv6 would require a 128-byte SRH. Even if ASICs could process such a long SRH at line speed, the bandwidth overhead would be prohibitive.

Therefore, one of the four solutions  that you mention below is required to make SRv6 deployable. While draft-ietf-6man-segment-routing-header is close to maturity, the four competing solutions mentioned below are equally mature and should be given equal consideration.


The four solutions are SRv6+, uSID, draft-li and draft-mirsky.

Operational Simplicity
-----------------------------
Network operators strive for operational simplicity. By loosely interpreting (and sometimes bending) the requirements of RFCs 4291 and RFC 8200, SRv6 introduces architectural quirks that introduce operational complexity. The following are architectural quirks of  draft-ietf-6man-segment-routing-header:


  *   The Segment Routing Header (SRH) serves purposes other than routing. Therefore, the SRH is sometimes required for packets that traverse the least-cost path from source to destination
  *   The SRH and the IPv6 Authentication Header are incompatible.
  *   The IPv6 destination address determines whether an SRH is valid and how it is processed. For example, if the IPv6 destination address contains one locally instantiated value, the SRH might be processed in one particular way, while if the IPv6 destination address contains another locally instantiated value, the SRH might be totally invalid.

Draft-ietf-spring-srv6-network-programming  promises more architectural quirks. For example:


  *   Segment endpoints can insert and/or delete IPv6 extension headers
  *   An IPv6 packet can contain two Segment Routing headers
  *   IPv6 packets are no longer self-describing. For example, the Next Header Field in the SRH can carry a value of No Next Header, even though the SRH is followed by Ethernet payload.

Other emerging drafts promise still more architectural quirks. For example, in draft-ali-6man-spring-srv6-oam, implementations need to examine the SRH even when Segment Left equals zero. This is because the SRH has been overloaded to carry OAM as well as routing information.

Furthermore, draft-filsfils-spring-net-pgm-extension-srv6-usid requires network operators to obtain address space and number their networks in a particular way to make routing work.

SRv6+ Work May Finish Before SRv6 work
--------------------------------------------------------
SRv6+  has been implemented on LINUX and is being implemented on JUNOS. Implementation experience demonstrates that specification is fairly complete. For example, there is no need for an SRv6+ OAM document. It’s just IPv6 and IPv6 OAM just works.

Furthermore, the SRv6+ specifications adhere to a strict interpretation of RFC 8200. Therefore, as they progress through the working group, they won’t need to overcome the objections that are inevitably encountered when stretching the interpretation of a specification that is so fundamental as RFC 8200.

                                                                                                      Thanks,
                                                                                                          Ron








From: spring <[e-mail]<mailto:[e-mail]>> On Behalf Of Rob Shakir
Sent: Sunday, August 4, 2019 5:04 PM
To: SPRING WG List <[e-mail]<mailto:[e-mail]>>
Subject: [spring] Beyond SRv6.


Hi SPRING WG,


Over the last 5+ years, the IETF has developed Source Packet Routing in NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 (SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.


These encapsulations are past WG last call (in IESG or RFC Editor).


During the SPRING WG meeting at IETF 105, two presentations were related to the reduction of the size of the SID for IPv6 dataplane:

  *   SRv6+ / CRH -- https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bonica-spring-srv6-plus-04&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf0a022c330834a1e566608d72f239a10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637029702293746165&sdata=D3BvWY5yR8r4TYthXzPiPLQcMVYU5QUmr3gbF%2Fon298%3D&reserved=0>
  *   uSID -- https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-filsfils-spring-net-pgm-extension-srv6-usid-01&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf0a022c330834a1e566608d72f239a10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637029702293746165&sdata=oU8zEFF9ZZawqrrb7%2BvgNweNrCu2X3hTaxtrksD0GYM%3D&reserved=0>


During the IETF week, two additional drafts have been proposed:

  *   https://tools.ietf..org/html/draft-li-spring-compressed-srv6-np-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-spring-compressed-srv6-np-00&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf0a022c330834a1e566608d72f239a10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637029702293756157&sdata=%2BN5676nqaYHGutiQaRE%2BTG3WPCyZxutDqeAeoeGV%2Baw%3D&reserved=0>
  *   https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mirsky-6man-unified-id-sr-03&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf0a022c330834a1e566608d72f239a10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637029702293756157&sdata=c5lZpjh0KJaeVS0SN8bgJ0Ys8VEfi9dbnEqC7%2Feytdo%3D&reserved=0>


As we expressed during the meeting, it is important for the WG to understand what the aims of additional encapsulations are. Thus, we think it is important that the WG should first get to a common understanding on the requirements for a new IPv6 data plane with a smaller SID - both from the perspective of operators that are looking to deploy these technologies, and from that of the software/hardware implementation.


Therefore, we would like to solicit network operators interested in SR over the IPv6 data plane to briefly introduce their:

  *   use case (e.g. Fast Reroute, explicit routing/TE)
  *   forwarding performance and scaling requirements

     *   e.g., (number of nodes, network diameter, number of SID required in max and average). For the latter, if possible using both SRv6 128-bit SIDs and shorter (e.g. 32-bit) SIDs as the number would typically be different (*).

  *   if the existing SRv6 approach is not deployable in their circumstances, details of the requirement of a different solution is required and whether this solution is needed for the short term only or for the long term.


As well as deployment limitations, we would like the SPRING community to briefly describe the platform limitations that they are seeing which limit the deployment of SRv6  In particular limitations related to the number of SIDs which can be pushed and forwarded and how much the use of shorter SIDs would improve the deployments .


For both of these sets of feedback if possible, please post this to the SPRING WG. If the information cannot be shared publicly, please send it directly to the chairs & AD (Martin).


This call for information will run for four weeks, up to 2019/09/03. As a reminder, you can reach the SPRING chairs via [e-mail]<mailto:[e-mail]> and ADs via [e-mail]<mailto:[e-mail]>.


Thank you,

-- Rob & Bruno


(*) As expressed on the mailing list, a 128 bit SID can encode two instructions a node SID and an adjacency SID hence less SID may be required.



Juniper Business Use Only
_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf0a022c330834a1e566608d72f239a10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637029702293766151&sdata=4W3ymr63O5e00oN5nO9MFXF0XFOoGn83R9LyUG04ZZY%3D&reserved=0>


Juniper Business Use Only