Subject: [spring] Beyond SRv6.

From: Rob Shakir <[email-masked]>
Date: Sun, 4 Aug 2019 14:03:49 -0700

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
   -

   uSID --
   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-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 [email-masked] and
ADs via [email-masked].

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.

---

From: Rob Shakir <[email-masked]>
Date: Mon, 5 Aug 2019 17:41:59 -0700

Hi SPRING,

Just to address a couple of questions raised to me:

> would improve the deployments .

We encourage input on the software/hardware limitations particularly from
those responsible for silicon, or system implementation, of course, such
feedback is very welcome from operators too :-)

Thanks!
r.

---

From: Andrew Alston <[email-masked]>
Date: Wed, 7 Aug 2019 04:15:44 +0000

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 <[email-masked]> On Behalf Of Rob Shakir
Sent: Monday, 5 August 2019 00:04
To: SPRING WG List <[email-masked]>
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.

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>

  *   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 [email-masked]<mailto:[email-masked]> and ADs via [email-masked]<mailto:[email-masked]>.

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.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 07 Aug 2019 15:26:19 +0800

Hi Andrew,

Thanks a lot for sharing your valuable opinions regarding SRv6 and SR-MPLS. 

You said "...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..." 

It seems that the only scenario where you MAY need SRv6 is to connect two SR-MPLS islands over IPv6 networks. If so, I wonder whether the approach as described in (https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07) is good enough for your scenario.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Andrew Alston <[email-masked]>
Send Time:2019年8月7日(星期三) 12:16
To:Rob Shakir <robjs=[email-masked]>; SPRING WG List <[email-masked]>
Subject:Re: [spring] Beyond SRv6.

Thanks Rob,

 
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
It solved the problem of overhead we saw on SRv6
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.

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

Thanks

Andrew

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
uSID --  https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01

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.

This call for information will run for four weeks, up to 2019/09/03. As a reminder, you can reach the SPRING chairs via [email-masked] and ADs via [email-masked]. 

Thank you,
-- Rob & Bruno

---

From: Andrew Alston <[email-masked]>
Date: Wed, 7 Aug 2019 08:34:00 +0000

Yes and no – because that assumption assumes that we will not see a growth of in the requirement where I have a need to actually working with steering inside those islands – as the temp solution you are correct.  As a long term solution – with the abandonment of SR-MPLS by certain vendors in the context of IPv6 I see a situation where I’m going to be forced into some form of SRv6 on those intermediate nodes.

At that point it still leaves me in a case of needing SRv6 in some form on the intermediate sections – and SRv6 is still not an option – my proposal to stitch is a temp solution – SRv6 in whatever form I see as becoming a mandatory part of life – now – if I had both USID and CRH as options and the stitching as an intermediate – once that becomes reality – I can then simply purchase based on the choice I’m making to handle what I need.  The alternative is to accept the fact that because of the entrenchment issues I have referred to – we end in a scenario where the drafts both stall – the vendors continue their development – and I believe that will happen – and I end up making a decision to use what effectively becomes proprietary non-standardized protocols from the vendor that supports that which I choose.  Then – I stitch back and forth between that proprietary protocol at the edges.  This is doable – but its far from desirable – because I’d rather be stitching between standardized protocols in this case than what is proprietary.

Basically – what I am saying here is – I see a scenario where we find common ground – we accept both things on the track towards standardization – and then let the operators decide which to use – and we work towards an inter-op draft between the two - because the alternative is that both stall within the framework of the IETF – and because of customer demand – both end up getting implemented in proprietary form – and we end up with some kinda weird inter-op between proprietary protocols – that doesn’t work for anyone, and it actually creates a situation where I have to consider limiting vendors in use on the network to that which works for me because I don’t have standardized methods of inter-op – because one or both of the protocols aren’t standardized.

That’s my take on it anyway – and it’s not unprecedented – in MOST technologies we have multiple alternatives – and we find a way to inter-operate between them – two IGP’s (OSPF and ISIS), Multiple methods of signaling (LDP vs RSVP as an example), etc etc etc.  This is good for consumer choice – and good for the operators.

Andrew

From: spring <[email-masked]> On Behalf Of ???(??)
Sent: Wednesday, 7 August 2019 10:26
To: spring <[email-masked]>; Rob Shakir <robjs=[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

It seems that the only scenario where you MAY need SRv6 is to connect two SR-MPLS islands over IPv6 networks. If so, I wonder whether the approach as described in (https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07<https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07>) is good enough for your scenario.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Andrew Alston <[email-masked]<mailto:[email-masked]>>
Send Time:2019年8月7日(星期三) 12:16
To:Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject:Re: [spring] Beyond SRv6.

Thanks Rob,

  1.  It solved the problem of overhead we saw on SRv6

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

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

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

Thanks

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Rob Shakir
Sent: Monday, 5 August 2019 00:04
To: SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Beyond SRv6.

Hi SPRING WG,

·

Thank you,

-- Rob & Bruno

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 07 Aug 2019 17:50:31 +0800

IMHO, the situation of SR-MPLS for IPv6 is much similar with that of LDP for IPv6. As long as there is a strong market demand of upgrading the WAN to IPv6, IPv6 LDP will be widely supported by vendors in the end. However, 6PE is still a practical and long-life solution.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Andrew Alston <[email-masked]>
Send Time:2019年8月7日(星期三) 16:36
To:徐小虎(义先) <[email-masked]>; spring <[email-masked]>; Rob Shakir <robjs=[email-masked]>; SPRING WG List <[email-masked]>
Subject:RE: [spring] Beyond SRv6.

Andrew

Best regards,
Xiaohu

Thanks Rob,

Thanks

Andrew

Hi SPRING WG,

 

 

 

 

 
Thank you,
-- Rob & Bruno

---

From: Yuji Kamite <[email-masked]>
Date: Wed, 7 Aug 2019 10:29:00 +0000

Hi folks,

Let me post the feedback of requirement as an operator.

Best regards,
-Yuji

---
Use Cases:
 1. Explicit Routing(TE) – replacement/successor to the existing MPLS.
  2. TI LFA / FastReroute -- same as above.  link and node protection
  3. VPN service --  same as above. EVPN and/or IP-VPN.
  4. NW Slicing   -- separate network logically, depending on traffic characteristics, with more fine-grained manner.
  5. Service Function Chaining -- multiple VNF/CNFs are provisioned and dynamically connected, mostly in NFV infrastructure
  6. Migration from SR-MPLS to SRv6
  We already have deployment using 1 to 3.  4 to 6 are also planned things.  In my view, SRv6 large-scale deployment is still limited today.

Requirements:
 1. Number of nodes / SIDs required:
    Existing production network:   < 5 hops in Datacenters,  < 10 hops average in WAN networks
As long as we use simple VPN and TI-LFA only by SRv6,  supporting a few number of SID stack is still fine; however, it is obvious that other use cases cannot be realized.
    From now on with SR:  at least 10 segments support required,.10-15 is desired, .(I think it would not be longer than 20 soon though), when considering:
    - Connecting various metro MEC/5G backhauling network to the center network
    - Connecting IPSec/SD-WAN overlay access
    - Service function chaining across multiple locations
    - Traffic metering based on different slices
    - With several steering hops added (for example, monitoring traffic with steering)

 2. Forwarding and Performance
      We have two major concern about current SRv6:
   (a) Bandwidth consumption overhead (issue in the existing SRv6 with 128bit SID)
   (b) Performance of forwarding equipment (typically the limitation of chip )
  (Note: (b) depends on each vendor's implementation.  I cannot mention each vendor's limitation information here, but I think it is important for community to share the understanding about today’s achievable level of number of SIDs/ performance limit in the industry.)

3. Length of SIDs needed
      - 16bits or 32bits (note: 32bit can be considered almost the same level as MPLS-SR)

4. Network design (e.g., physical MTU design) flexibility
      - Operators do not want complex design of topology and MTU considering the increase of SIDs in the future.

5. Multi domain network support
      - Multi-Area. Multi-AS support

6. Addressing flexibility
      - For providers who have the existing IPv6 deployment, a solution should avoid their drastic change of their current addressing.

7. Route information scalability
      - Additional propagation of IGP routes should be minimized as much as possible.

8. OAM functionality
     - Should provide OAM such as Ping/Traceroute for troubleshooting and failure detection/isolation.
     - It is desired that a solution can use ordinary ICMP mechanism (partially or fully) because it is a natural scenario that non-SR capable v6 domains are included in SRv6 end-end path.
----

From: spring <[email-masked]> On Behalf Of Rob Shakir
Sent: Monday, August 5, 2019 6:04 AM
To: SPRING WG List <[email-masked]>
Subject: [spring] Beyond SRv6.

Hi SPRING WG,

  *   SRv6+ / CRH -- 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-li-spring-compressed-srv6-np-00
  *   https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03

Thank you,

-- Rob & Bruno

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 31 Aug 2019 04:05:15 +0000

Dear Chairs and the WG:

The SRv6 network programming solution and its SRH encapsulation is implemented on 12 hardware platforms including Merchant Silicon.
Multiple providers have deployed the SRv6 network programming solution and its SRH encapsulation with line-rate performance carrying a significant amount of commercial traffic.
Several independent interoperability reports documenting successful interoperability of implementation from multiple vendors exist.
Implementation, deployment, and interoperability status is publicly documented in https://www.ietf.org/id/draft-matsushima-spring-srv6-deployment-status-01.txt.

Most use-cases are expected to use very few SRv6 segments.

In some specific use-cases, one may desire to optimize the MTU usage further.
The SRv6 network programming solution and its SRH encapsulation also support for this Optimization, through the uSID network instruction.

I do not see the need for any new encapsulation work.

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of Rob Shakir <robjs=[email-masked]>
Date: Sunday, August 4, 2019 at 5:04 PM
To: SPRING WG List <[email-masked]>
Subject: [spring] Beyond SRv6.

Hi SPRING WG,

  *
  *   SRv6+ / CRH --
  *   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
  *

  *
  *
  *
  *

  *
  *
  *
  *

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

Thank you,

-- Rob & Bruno

---

From: Mark Smith <[email-masked]>
Date: Sat, 31 Aug 2019 18:44:49 +1000

> The SRv6 network programming solution and its SRH encapsulation also support for this Optimization, through the uSID network instruction.

If I understand it correctly, the idea is that uSIDs are encoded in
the remaining bits of an IPv6 destination addresses, below a single
high order aggregate prefix?

If that is the case, then I think there are a number of issues with
this proposal.

Firstly, there are defined fields below the upper aggregate prefix for
all IPv6 address formats. They are not available for arbitrary use.

For the Link-Local Address, the bits between /10 and /64 are specified
to be set to zero.

The ULA prefix defines a fields up until /64. The most important one
is the 40 bit Global ID field, between /8 and /48,  which is required
to be pseudo-random to attempt to avoid address space collision when
two ULA domains are merged. A shorter than /48 ULA prefix impacts this
important property.

For both Global Unicast Addresses and ULA addresses, the bits between
/48 and /64 are designated the Subnet ID field.

Below that, for GUA, ULA and LLA, the following and lower 64 bits of
an IPv6 address is the 64 bit Interface Identifier (IID) field.

RFC 7136, "Significance of IPv6 Interface Identifiers", removed
requirement for the IID field to have a modified EUI-64 value,
allowing that field to be treated as an opaque 64 bit quantity
generally, and to allow end-hosts or protocols to place significance
on bits within the IID field if they chose to.

So I think uSIDs could only be legitimately placed in the lower 64 bit
IID field.

There are however reserved IID values, so any combination of uSID
values would not be able to result in any of these reserved IID
values.

"Reserved IPv6 Interface Identifiers"
https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml

For all these above IPv6 address format details, and others, see RFCs
4291 (GUA, LL) and 4193 (ULA).

Regards,
Mark.

> 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.
>
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Satoru Matsushima <[email-masked]>
Date: Sat, 31 Aug 2019 15:41:43 +0200

Hi,

As part of the 5G rollout, Softbank have deployed a nationwide SRv6 network carrying commercial traffic with the linerate performance using Merchant Silicon.

https://www.softbank.jp/corp/news/press/sbkk/2019/20190424_03/

# You can read it in your language through some translation service, e.g, google translation.

draft-matsushima-spring-srv6-deployment-status captured that use case.

Best regards,
--satoru

> 2019/08/31 6:05、Zafar Ali (zali) <[email-masked]>のメール:
> 
> Dear Chairs and the WG: 
>  
> Implementation, deployment, and interoperability status is publicly documented inhttps://www.ietf.org/id/draft-matsushima-spring-srv6-deployment-status-01.txt.
>  
> 	•  
> 	• SRv6+ / CRH --
> 	• 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-li-spring-compressed-srv6-np-00 
> 	•  
> 	•  
> 	• https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03 
> 	•  
>  
> 	•  
> 	• 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.
> 	•  
>  
> This call for information will run for four weeks, up to 2019/09/03. As a reminder, you can reach the SPRING chairs [email-masked] and ADs via [email-masked]. 
>  
> Thank you,
> -- Rob & Bruno
>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 31 Aug 2019 20:33:32 +0000

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 <[email-masked]> On Behalf Of Rob Shakir
Sent: Sunday, August 4, 2019 5:04 PM
To: SPRING WG List <[email-masked]>
Subject: [spring] Beyond SRv6.

Hi SPRING WG,

  *   SRv6+ / CRH -- https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D04&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=KUhAfjVsx_wK645uJk0FHzs2vxiAVr-CskMPAaEhEQQ&e=>
  *   uSID -- https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D01&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=Aq1DK7fu73axZ1PXLIE8xnHE2AhTtNZy9LTHgWqx4CQ&e=>

  *   https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Dspring-2Dcompressed-2Dsrv6-2Dnp-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=XWUDAD2FMhWLfeT5sgUb1lgthJhugcyT98GJ2N-CrKs&e=>
  *   https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmirsky-2D6man-2Dunified-2Did-2Dsr-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=gcbkHYxXm7FU7vblOB1vI58SDaaWf62pa7YvLmsP4nI&e=>

Thank you,

-- Rob & Bruno

Juniper Business Use Only

---

From: Fernando Gont <[email-masked]>
Date: Sat, 31 Aug 2019 23:53:00 +0300

Hi, Ron,

For those 6man-ers that have not been following the sprin work, could
you please clarify what do you mean by "stretching the interpretation of
RFC8200 or RFC4291"?

In the past we have seen outright violation of RFC8200 (formerly
RFC2460), so I'm curious if there are any documents trying to do the
same, or what.

Thanks!

Cheers,
Fernando

On 31/8/19 23:33, Ron Bonica wrote:
> 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.
> 
>  
> 
> 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 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.
> 
>  
> 
>   * 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+  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 <[email-masked]> *On Behalf Of *Rob Shakir
> *Sent:* Sunday, August 4, 2019 5:04 PM
> *To:* SPRING WG List <[email-masked]>
> *Subject:* [spring] Beyond SRv6.
> 
>  
> 
> Hi SPRING WG,
> 
>  
> 
> IPv6 (SRv6) data planes. SR-MPLS may also be transported over IP in UDP
> or GRE.
> 
>  
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D04&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=KUhAfjVsx_wK645uJk0FHzs2vxiAVr-CskMPAaEhEQQ&e=>
>   * uSID --
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D01&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=Aq1DK7fu73axZ1PXLIE8xnHE2AhTtNZy9LTHgWqx4CQ&e=> 
> 
>  
> 
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Dspring-2Dcompressed-2Dsrv6-2Dnp-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=XWUDAD2FMhWLfeT5sgUb1lgthJhugcyT98GJ2N-CrKs&e=> 
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmirsky-2D6man-2Dunified-2Did-2Dsr-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=gcbkHYxXm7FU7vblOB1vI58SDaaWf62pa7YvLmsP4nI&e=> 
> 
>  
> 
> 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:
> 
>       o 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.
> 
>  
> 
> 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 .
> 
>  
> 
> This call for information will run for four weeks, up to 2019/09/03. As
> a reminder, you can reach the SPRING chairs via [email-masked]
> <mailto:[email-masked]>and ADs via [email-masked]
> <mailto:[email-masked]>. 
> 
>  
> 
> Thank you,
> 
> -- Rob & Bruno
> 
>  
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Smith <[email-masked]>
Date: Sun, 1 Sep 2019 10:32:01 +1000

+1

The value in using a commodity protocol like RFC 8200 compliant IPv6
for something like SR is that you're gaining from IPv6 being well
understood, widely implemented, widely deployed, widely interoperable,
widely tested, and the major bugs have very likely already been
discovered. It's cheaper to use something that it is already widely in
use.

However, if you then try to stretch or go beyond expected use and
semantics, and violate protocol definitions, you're decommodifying the
commodity. You've lost significant or all of the value of using the
commodity protocol in the first place.

On Sun, 1 Sep 2019 at 06:34, Ron Bonica
<rbonica=[email-masked]> wrote:
> Efficient forwarding with deep SID lists
> Operational Simplicity
> SRv6+ work may finish before SRv6
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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: Fernando Gont <[email-masked]>
Date: Sun, 1 Sep 2019 03:48:16 +0300

> commodity protocol in the first place.

I think it's simpler than that: it would be quite "interesting" to have
one wg specify protocol A, and another wg that specifies protocol B that
uses protocol A while violating the very spec of protocol A.

---

From: Mark Smith <[email-masked]>
Date: Sun, 1 Sep 2019 12:02:22 +1000

> uses protocol A while violating the very spec of protocol A.

Well what I've described is the fundamental reason why that shouldn't
happen and why everybody should agree that it shouldn't happen.

At the point where an apparent limitation or constraint in one WG's
protocol is discovered by another WG, the latter WG should then consult
with the first WG on how to solve the problem that would be consistent with
the first WG's protocol and architecture.

If the behaviour doesn't comply with RFC 8200, it isn't IPv6 anymore.
Instead it is a proprietary and unofficial variant of it.

There's an RFC about this sort of thing. It also applies to different IETF
WGs.

Uncoordinated Protocol Development Considered Harmful

https://tools.ietf.org/html/rfc5704

Regards,
Mark.