Re: [spring] Beyond SRv6.

[Andrew Alston <[e-mail]>]

Thanks Rob,

So – Firstly let’s start with the use cases.  Our biggest requirement for any of this is about traffic steering and about removal of V4 from the network in the long term.  Our entire motivation for getting involved in SR in the first place initially revolved around the fact that in our view LDPv6 was pretty much still born – and the lack of MPLS feature parity with IPv6 was causing us significant problems.  We hoped that SR would eventually resolve much of this.  Now – in that case SR-MPLS would have been just fine and frankly speaking – we were entirely happy with pure SR-MPLS and I’m on record saying that I didn’t see much of a use case for SRv6 at all.

We then got to a situation however, where we hit an implementation problem.  At least one vendor categorically stated to us that they would not support SR-MPLS as relates to V6 – and if we wanted SR with V6 – SRv6 was what we were going to have to have.  Since then I’ve had another vendor send me a very similar message.  This left us with a problem – and so on to SRv6 we came.  In looking at SRv6 though and the traffic patterns on our network and based on various factors – the overhead imposed by SRv6 in its original form is simply untenable.  We did some analysis on the actual traffic patterns on our network, and dependent on depth of the SID stack and the particular segment of the network and the types of traffic – we calculated an increase in utilization of between 5% on the low end and 19% on the upper end.  That – simply doesn’t work for us.

Secondly – We have fairly major concerns about using V6 addresses in an “overloaded manner”  Effectively, we prefer V6 addresses to be exactly that – addresses used to address nodes.  We have a concern that attempting to pack more and more functionality into the address space could result in unknown and unintended consequences.  It also from an operational perspective in our view creates more complexity.   The merging of programmability and routing and other such things directly into the address creates a wider failure domain where hitting a bug on one thing could impact a lot more than just routing etc.

So – moving on to the two proposed drafts.  We got involved in CRH because it solved three major problems we were facing.


  1.  It gave us a form of SR that allowed us to do traffic steering and meet our use cases when it became clear that SR-MPLS probably wasn’t going to work for us because of resistance from certain vendors and their clearly stated positions
  2.  It solved the problem of overhead we saw on SRv6
  3.  It left the address space de-coupled from routing and programmability – which we believe creates additional issues as stated above.  It also allows relatively easy expansion to support inter-domain SR using BGP signaling – and because of the immutability of the extension header allowed full end to end path visibility at any point in the network.

Now – if I have to compare what is proposed with CRH with what is proposed by USID from our perspective.  Firstly – I’m at a loss as to how USID and programmability of intermediate nodes are actually going to work.  In CRH – you have a destination option that contains both either per segment service instructions or per service instructions or both.

So now – on to looking at USID.


  1.  Firstly – we believe that USID actually compromises network programmability.  In USID – if you’re compressing the routing header and avoiding carrying the entire 128bit SID across the network – you’re tying enough of the address to the steering that there is precious little left for programmability instructions outside of the final end node. While we can carry the full SID in USID and shift only the address itself to maintain path visibility – that is needless overhead.
  2.  USID will result in an inflation of the IGP tables.  It requires me to have addresses on the devices that are inside the block used for steering – and since its entirely impractical to renumber in such a way that it would work with the current address assignments – this means running two addresses on each loopback – which from an IGP perspective are treated as standard addresses.  As a result – I’m seeing an increase in my V6 IGP – and an increase in my V6 FIB.  This is problematic on the smaller end point devices.
  3.  Thirdly – as discussed in the WG meeting in Montreal – we believe that the current draft could result in a pretty excessive wastage of IPv6 space, and we’re yet to see any real answers to this.

Now – on to the other questions posed.  With regards to scalability.  We need to be able to steer at least 6 SID’s deep – 10 would be preferable to deal with certain corner cases.  We need to be able to do this at line rate and get the same network performance using the mechanisms we use from this that we would get from normal SR-MPLS.

The current SRv6 solution as stated above is not deployable – the overhead is to high and the concerns run deep about the other issues mentioned.  Our solution we’re working towards where we need SRv6 in the absence of SR-MPLS is stitch SR-MPLS to SRv6 through packet encapsulation – effectively use an SR-MPLS binding label to trigger a packet encapsulation to V6 with CRH – route across the segments that do not support SR-MPLS using standard V6 routing – and use a destination option to trigger decapsulation as it hits the next SR-MPLS supporting network segment.  The advantage of this approach is that while it doesn’t allow granular steering through the intermediate network segment – it does preserve the SR-MPLS label stack end to end and in effect creates a form of lose routing over that segment while preserving the SR-MPLS label stack.   Effectively this is similar to using SR-MPLS over UDP or GRE – we’re just working on coming up with a defined way to stitch between native SR-MPLS and UDP/GRE/Whatever – and we hope to have a proposal about this stitching mechanism in the next couple of days, we’ve been working on some code to test theories related to it prior to releasing a draft about this.   Ideally – because of the stance expressed by vendors where we see a situation where both CRH and USID end up stalling – we would like a situation where stitching from SR-MPLS to either format is possible – and ideally stitching between USID and CRH is also possible – creating inter-op while avoiding stalling progress.

From an operator perspective – we simply do not see native SRv6 as workable – and we also see an entrenchment by the vendors in their positions regarding the CRH  and USID proposals – while having a need that is not being met.  Hence – our perspective is that allowing both standards to move forward while having a defined inter-op mechanism gives us the fastest resolution and meets the needs we face today.  Basically as an operator – we need our problems solved – and if inter-op between the proposals speeds this up – then lets create such an inter-op.  This is far preferable in our eyes to being in a situation where what currently exists doesn’t work – and where entrenchment of positions stalls progress on either option – leaving us as an operator caught in the middle with an active issue without resolution.

I hope that addresses many of the questions – and I’d welcome discussion with the proposers of the various drafts and both the chairs and the AD’s if necessary.

Thanks

Andrew

From: spring <[e-mail]> On Behalf Of Rob Shakir
Sent: Monday, 5 August 2019 00:04
To: SPRING WG List <[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://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04>
  *   uSID -- https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01<https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01>


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

  *   https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00<https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00>
  *   https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03<https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03>


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.