Subject: Re: [spring] Beyond SRv6.

From: Robert Raszuk <[email-masked]>
Date: Sun, 1 Sep 2019 17:03:20 +0200

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=
[email-masked]> 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 <[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,
>
>
>
> 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://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=>
>
>
>
>
> During the IETF week, two additional drafts have been proposed:
>
>    - 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=>
>
>
>
>
> 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.
>
>
>
>
>
> Juniper Business Use Only
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Tom Herbert <[email-masked]>
Date: Sun, 1 Sep 2019 13:21:03 -0400

> Efficient forwarding with deep SID Lists

Hi Ron,

It's hard to say whether or not SRH satisfies the requirements without
first having quantified requirements. For instance, how much header
overhead does it take before it's considered prohibitive?

The 128 byte SRH would be one quantified requirement. Is this rooted in
some inherent implementation constraint? My understanding is that many
devices have a parsing buffer of some fixed size for processing packet
headers. If a packet's headers of interest don't fit into buffer that's a
problem. 128 and 256 bytes seem to be common sizes. But, this padding
buffer is for all headers (e.g. Ethernet, IPv6, SRH, etc.). So an SRH with
just 5 SIDs would overflow a 128 byte parsing buffer.

Tom

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ron Bonica <[email-masked]>
Date: Sun, 1 Sep 2019 18:59:16 +0000

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 <[email-masked]>
Sent: Sunday, September 1, 2019 11:03 AM
To: Ron Bonica <[email-masked]>
Cc: Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
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=[email-masked]<mailto:[email-masked]>> wrote:
Rob,

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

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.

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]<mailto:[email-masked]>> On Behalf Of Rob Shakir
Sent: Sunday, August 4, 2019 5:04 PM
To: SPRING WG List <[email-masked]<mailto:[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://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=>

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.

Juniper Business Use Only
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=CPqEXzKACLlLESk67mlmQv3ve6i6_Y5l7xESAiNA1Go&s=_k8da1IaBrm80LML0tO-Er3RL2Wn6nLIMFRTbWTtUTQ&e=>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 1 Sep 2019 21:18:13 +0200

Hi Ron,

The SR architecture is common to SR-MPLS and SRv6 as far as path
engineering is concerned ie. number of SIDs to impose.

I explained one pretty common misconception of how some people treat SR as
1:1 replacement of RSVP-TE. In fact there may even float around some slides
or white papers stating so - but if anything they are fundamentally
incorrect.

So here in SPRING you either present valid and convincing to WG technical
explanation why in specific network you see a need for 8-12+ SIDs or that
point simply can not be used as "push" argument for CRH ;). .

On the other hand you know that the most difficult to introduce any new
technology is not even respining an ASIC .. it is education and assistance
to your customers to make sure new technology is really deployed in the
right way.

Cheers,
Robert.

PS. Talking in the context of SRv6 architecture to one of the most common
of the shelf forwarding vendor I was told their hardware reads 256 bytes of
the packet header for flexible processing. So with that I am even more
assured that the bottleneck in line rate packet processing even with your
stated size of SRH is rather limited to legacy hardware which will happen
all the time and is normal when someone defines new data plane
enhancements. After all no one obsoletes SR-MPLS - it can be used as smooth
transition path to SRv6.

On Sun, Sep 1, 2019 at 8:59 PM Ron Bonica <[email-masked]> wrote:

> 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 <[email-masked]>
> *Sent:* Sunday, September 1, 2019 11:03 AM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>;
> [email-masked]
> *Subject:* Re: [spring] Beyond SRv6.
>
>
>
> Dear Ron,
>
>
>
> With that let's also notice that proposed SRv6 (or for that matter
> SR-MPLS) is applicable to networks under same administrative control.
>
>
>
>    - https://tools.ietf..org/html/draft-li-spring-compressed-srv6-np-00
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=CPqEXzKACLlLESk67mlmQv3ve6i6_Y5l7xESAiNA1Go&s=_k8da1IaBrm80LML0tO-Er3RL2Wn6nLIMFRTbWTtUTQ&e=>
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 1 Sep 2019 22:28:03 +0200

Hi Andrew,

Looking at your network topology
https://www.liquidtelecom.com/about-us/network-map.html 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 <
[email-masked]> 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 <[email-masked]> on behalf of Ron Bonica <rbonica=
> [email-masked]>
> *Date: *Sunday, 1 September 2019 at 21:00
> *To: *Robert Raszuk <[email-masked]>
> *Cc: *Rob Shakir <[email-masked]>, SPRING WG List <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [spring] Beyond SRv6.
>
>
>
> Robert,
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Sun, 1 Sep 2019 21:10:33 +0000

Hi Fernando,

6man participants should look at the following:

- https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01 (In particular, Sections 4 and 5)
- https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02

                                                                                             Ron

-----Original Message-----
From: Fernando Gont <[email-masked]> 
Sent: Saturday, August 31, 2019 4:53 PM
To: Ron Bonica <[email-masked]>; Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [spring] Beyond SRv6.

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:
> 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.
> 
>  
> 
> 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
>   * 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.
> 
>  
> 
> 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.
> 
>  
> 
> 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
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D04&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZASTQL-zus0nxutimTLAQl7WlS4Dqso6C1dMTkxeio0&s=BN2DF-66SUZSxAadboFqg1MP1Drk_9bHoYZhGq8jZXE&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=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZASTQL-zus0nxutimTLAQl7WlS4Dqso6C1dMTkxeio0&s=uAESJj-OvK22RpEy_P4-T9kubYyJm55Q4ba3mX4KDhY&e= 
>     
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_h
> tml_draft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D
> 01&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82si
> r-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieI
> C4dD_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=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZASTQL-zus0nxutimTLAQl7WlS4Dqso6C1dMTkxeio0&s=8cKoeToYaFKfdgCZAYjwm4PItthfOAV0YkfhL46p4e8&e= 
>   * https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmirsky-2D6man-2Dunified-2Did-2Dsr-2D03&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZASTQL-zus0nxutimTLAQl7WlS4Dqso6C1dMTkxeio0&s=MAEp0tdnu5Q7Cs7V5XNblNjEKByN7mucnnDwiwKEqS0&e= 
>     
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_h
> tml_draft-2Dmirsky-2D6man-2Dunified-2Did-2Dsr-2D03&d=DwMFaQ&c=HAkYuh63
> rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2Efp
> HcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=gcbkHYxXm7
> FU7vblOB1vI58SDaaWf62pa7YvLmsP4nI&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.
> 
>  
> 
>       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
>     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
> 
>  
> 
> Administrative Requests: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_ipv6&d=DwID-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzo
> CI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZASTQL-zus0nxutimTL
> AQl7WlS4Dqso6C1dMTkxeio0&s=HzZWo8ryJvwtuP_GEiM0Hy52ogBtiaiDML21sxVzf1k
> &e=

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

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 1 Sep 2019 22:32:19 +0100

Ron Bonica wrote on 01/09/2019 22:10:
> -https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02

Ron,

if this draft proposes using up to /32 per router in a SRv6 domain, or 
even /40 to /48, it may be appropriate to solicit input from RIR address 
policy groups about the impact this may have on ipv6 assignment / 
allocation policies.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 1 Sep 2019 23:39:21 +0200

Nick,

How about using ULAs as defined in RFC4193 ?

After all isn't local IPv6 FC00::/7 address block defined precisely for
such private use cases like the one which uSID requires?

Clearly RIRs will not allocate /22 blocks left and right and that v6 prefix
would be required if I have 1000 node network and my uSID is /32.

Thx,
R.

On Sun, Sep 1, 2019 at 11:33 PM Nick Hilliard <[email-masked]> wrote:

> > -
> https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02
>
> Ron,
>

---

From: Ron Bonica <[email-masked]>
Date: Sun, 1 Sep 2019 21:46:39 +0000

Robert,

Please see https://mailarchive.ietf.org/arch/browse/spring/?gbt=1&index=BPXFbv5drFqv7k7nPIN3SDuifo0.

                        Ron

From: Robert Raszuk <[email-masked]>
Sent: Sunday, September 1, 2019 5:39 PM
To: Nick Hilliard <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Rob Shakir <[email-masked]>; Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [spring] Beyond SRv6.

Nick,

After all isn't local IPv6 FC00::/7 address block defined precisely for such private use cases like the one which uSID requires?

Clearly RIRs will not allocate /22 blocks left and right and that v6 prefix would be required if I have 1000 node network and my uSID is /32.

Thx,
R.

On Sun, Sep 1, 2019 at 11:33 PM Nick Hilliard <[email-masked]<mailto:[email-masked]>> wrote:
Ron Bonica wrote on 01/09/2019 22:10:
> -https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D02&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=7I4t7LyLvwwPPgSsY1oWMfea5dTE2YbuJyBi-ITbgp0&s=HaZUtfUO-zFP__49jfNHxb_YdFd2EZVxbt9q3Jbztuc&e=>

Ron,

Nick

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=7I4t7LyLvwwPPgSsY1oWMfea5dTE2YbuJyBi-ITbgp0&s=2wTKvWueDyZNNHloNNHK66vNruLD2Drj5FJDisgUQlE&e=>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 1 Sep 2019 23:56:12 +0200

Yes Ron I saw this message from Bob and as you see from the mailer I
responded with clarification on why this is not 2^112.

While I do not understand why ULAs blocks must be globally unique (to me
this is analogy of RFC1918 :) there are few more options on the table on
what blocks to use for uSIDs addressing.

Thx,
R.

On Sun, Sep 1, 2019 at 11:48 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Robert,
>
>
>
> Please see
> https://mailarchive.ietf.org/arch/browse/spring/?gbt=1&index=BPXFbv5drFqv7k7nPIN3SDuifo0
> .
>
>
>
>                         Ron
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 2 Sep 2019 10:17:22 +1000

> How about using ULAs as defined in RFC4193 ?

I've analysed uSID in the context of all current IPv6 unicast address
formats in this email.

https://mailarchive.ietf.org/arch/msg/spring/Gsr-nJqzhyYIrj8mG6p3KZ_HZ5E

Short answer is you can only put uSIDs in the IID portion of any of those
address formats, and must also ensure that the resulting IID value formed
from the set of uSID values don't also match the reserved IID values.

The uSID proposal is taking the position that all the bits after the high
order prefix are available for any purpose. This is not correct, and would
violate a number of standards track RFCs, including the IPv6 Addressing
Architecture RFC (RFC 4291) and the ULA RFC (RFC 4193).

In particular, 40 bits of a ULA prefix, between /8 and /48, the Gobal ID,
must be pseudo random. This is the most critical property of ULA addresses
and prefixes, as it is the solution to the problem ULAs are designed to
solve.

3.2 <https://tools.ietf.org/html/rfc4193#section-3.2>.  Global ID

   The allocation of Global IDs is pseudo-random [RANDOM
<https://tools.ietf.org/html/rfc4193#ref-RANDOM>].  They MUST
   NOT be assigned sequentially or with well-known numbers.  This is to
   ensure that there is not any relationship between allocations and to
   help clarify that these prefixes are not intended to be routed
   globally.  Specifically, these prefixes are not designed to
   aggregate.

> Clearly RIRs will not allocate /22 blocks left and right and that v6
> prefix would be required if I have 1000 node network and my uSID is /32.
>
> Thx,
> R.
>
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 2 Sep 2019 10:25:32 +1000

On Mon., 2 Sep. 2019, 07:30 Andrew Alston, <[email-masked]>
wrote:

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

Too much choice is a bad thing, because there is then too greater risk of
making a wrong choice. The least risky choice becomes make no choice.

– 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 –
>
These are the sorts of problems you'll see with no clear consensus in a
single solution to a problem.

RFC 1958, "Architectural Principles of the Internet",

"3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements."

and I may well still get around to doing this – time has just been a little
> hectic of late.
>
>
>
> Andrew
>
> *From: *Robert Raszuk <[email-masked]>
> *Date: *Sunday, 1 September 2019 at 22:28
> *To: *Andrew Alston <[email-masked]>
> *Cc: *Ron Bonica <rbonica=[email-masked]>, Rob Shakir <
> [email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <
> [email-masked]>
> https://www.liquidtelecom.com/about-us/network-map.html yes indeed you
> need to pass via number of countries, but keep in mind that SR is not a
> routing protocol.
>
>
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 2 Sep 2019 11:25:31 +1000

On Mon., 2 Sep. 2019, 07:56 Robert Raszuk, <[email-masked]> wrote:

> this is analogy of RFC1918 :)
>

RFC 3879, "Deprecating Site Local Addresses"

there are few more options on the table on what blocks to use for uSIDs
> addressing.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 2 Sep 2019 09:58:09 +0200

Hi Mark,

> and prefixes, as it is the solution to the problem ULAs are designed to

RFC 4193 says about Global_ID allocation:

   The local assignments are self-generated and do not need any central
   coordination or assignment, but have an extremely high probability of
   being unique.

So in some the case operator may choose to make such "local assignment" of
Global ID to be per router not per network. And that is all what is needed
for uSID. uSID address blocks does not need to be continues.

It also does not contradict with any RFC does it ? What breaks if I use
more then one self generated Global ID in my network ?

Note that the above question goes way beyond any SR related discussion so
perhaps deserves a separate 6man thread.

Best,
R.

---

From: Mark Smith <[email-masked]>
Date: Mon, 2 Sep 2019 20:24:22 +1000

>    coordination or assignment, but have an extremely high probability of
Are uSID values going to be entirely pseudo-random?

"

3.2.1 <https://tools.ietf.org/html/rfc4193#section-3.2.1>.  Locally
Assigned Global IDs

   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM
<https://tools.ietf.org/html/rfc4193#ref-RANDOM>]."

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 2 Sep 2019 13:09:36 +0200

> Are uSID values going to be entirely pseudo-random?

I see no reason why not ...

Networks are managed by some form of NMS. NMS can generate such values and
abstract it with a "node_name_usid" string for any additional processing
and human abstraction.

If that is the only concern I think we are done then. The only issue is
that if you happen to have hierarchical IGP you will not be able to
summarize them - but I don't think that this would be a showstopper to any
deployment.

Best,
R.

On Mon, Sep 2, 2019 at 12:24 PM Mark Smith <[email-masked]> wrote:

>>> The uSID proposal is taking the position that all the bits after the
>>> high order prefix are available for any purpose. This is not correct, and
>>> would violate a number of standards track RFCs, including the IPv6
>>> Addressing Architecture RFC (RFC 4291) and the ULA RFC (RFC 4193).
>>>
>>> In particular, 40 bits of a ULA prefix, between /8 and /48, the Gobal
>>> ID, must be pseudo random. This is the most critical property of ULA
>>> addresses and prefixes, as it is the solution to the problem ULAs are
>>> designed to solve.
>>>
>>
> 3.2.1 <https://tools.ietf.org/html/rfc4193#section-3.2.1>.  Locally Assigned Global IDs
>
>    algorithm consistent with [RANDOM <https://tools.ietf.org/html/rfc4193#ref-RANDOM>]."
>
>
>
>> So in some the case operator may choose to make such "local assignment"
>> of Global ID to be per router not per network. And that is all what is
>> needed for uSID. uSID address blocks does not need to be continues.
>>

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 2 Sep 2019 12:31:23 +0100

Robert Raszuk wrote on 02/09/2019 12:09:
> summarize them - but I don't think that this would be a showstopper to 
> any deployment.

Robert,

please correct me if I'm wrong but uSIDs would need to be injected into 
the provider's routing tables, so your suggestion that ULAs would be 
appropriate for the srv6-usid draft would be contingent on SRv6 
providers being ok about the idea of injecting ULAs into their core.

I'm not sure that this would necessarily be the case.

Nick

---

From: Mark Smith <[email-masked]>
Date: Mon, 2 Sep 2019 21:36:35 +1000

On Mon., 2 Sep. 2019, 21:09 Robert Raszuk, <[email-masked]> wrote:

> If that is the only concern I think we are done then.
>

No. You haven't dealt with the other issues I've highlighted in the email
link I provided earlier. As I pointed out there, I think the only place you
can put uSIDs is in the IID field, and I went to the effort of providing
RFC references.

I'm getting off this merry go round. When SPRING comes up with an out of
the ordinary idea, the first thing to do is check the IPv6 RFCs to see if
they will accommodate the idea.

This draft and the EH insertion draft show that this isn't and hasn't
happened.

The only issue is that if you happen to have hierarchical IGP you will not
> be able to summarize them - but I don't think that this would be a
> showstopper to any deployment.
>
> Best,
> R.
>
>
>
>
>
>>> Note that the above question goes way beyond any SR related discussion
>>> so perhaps deserves a separate 6man thread.
>>>
>>> Best,
>>> R.
>>>
>>>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 2 Sep 2019 13:49:25 +0200

Hi Nick,

Yes you are 100% correct.

The decision to inject any prefix into someone's IGP (or BGP) is a local
operator's decision.

Btw let me also self correct last note - It is actually pretty trivial to
pseudo-random generate ULAs such that blocks of it can actually be
aggregatable across areas or levels. It is just that such one time run
generation perl or python script will run a little bit longer :)

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 2 Sep 2019 14:09:00 +0200

Hey Mark,

 I think the only place you can put uSIDs is in the IID field, and I went
> to the effort of providing RFC references.
>

I only tend to follow the rules which make sense or which violation even if
they do not make sense goes against best practices, common rules or could
endanger anyone or anything. RFCs you quote do not limit numer of ULAs to
be one per network or even one per person - so I am not breaking any RFC if
I use bunch of ULAs as it seems fit.

When SPRING comes up with an out of the ordinary idea

This is far beyond SPRING topic. Operators and end users use RFC1918
everywhere as it gives them freedom and flexibility to construct
their networks the way they like it. Sufficiently flexible min /8 private
range must be made available for anyone's use if you want to see wider IPv6
adoption. And /8 as proven is not about need for 2^112 addresses - it's
about constructing your network applications with well though addressing
structure and hierarchy.

> happened.

I am not going to comment on the insertion part beyond the observation that
when you apply new IPv6 header you are free to insert whatever you like
into it. Likewise per RFC8200 when I see myself in destination address
field of the outer IPv6 header I can process, insert or delete EHs as it
seems fit.

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) *identified in the Destination Address field
   of the IPv6 header.*

I do not see any stretch of it in any SPRING related document.

Best,
R.

---

From: Ron Bonica <[email-masked]>
Date: Mon, 2 Sep 2019 13:22:58 +0000

Rob,

There may be an elephant in the room that needs addressing....

Over the years, the IPv6 community has specified a very tight architecture that encodes some information in IPv6 addresses, other information in Routing headers, and still other information in Destination Options headers. SRv6+ adheres strictly to this architecture. Because it reuses IPv6 machinery, its specification promises it be painless and its deployment promises to be safe. To date, there has been no significant technical criticism of SRv6+. Only a claim that SRv6 is nearly complete and good enough. (Both of those claims may require scrutiny).

By contrast, SRv6 varies from the spirit, if not the letter of the IPv6 architecture. It encodes things in IPv6 address that have never been encoded in IPv6 addresses before. It attempts to encode everything else in the Routing header, as if the other IPv6 extension headers didn't exist. It frequently tests the limits of RFC 8200 compliance.

This creates a situation in which each variance from IPv6 orthodoxy requires another. For example, because SRv6 encodes instructions in IPv6 addresses, draft-ali-6man-spring-srv6-oam is required. And now, draft-ali-6man-spring-srv6-oam creates its own variances from the IPv6 orthodoxy. OAM information is encoded in the Routing header and the Routing header must be examined, even when Segment Left is equal to zero.

I invite everyone to consider how TI-LFA an uSID will interact.

So, why would the IETF would want to prevent work on the more conservative, SRv6+ approach?  This brings us to the back to the elephant in the room.....

Until very recently, relatively few router vendors have supported IPv6 extension headers in ASICs. If an IPv6 packet contained any extension headers at all, it was sent to the slow path.

SRv6+ encourages router vendors to support both the Routing and Destination Options header in ASICs. This sets vendors on a path on a path towards more complete implementation of the architecture that the IPv6 community has developed so carefully over the years. It encourages vendors to commit more and more of RFC 8200 to ASICs.

SRv6 encourages router vendors to support the Routing header in ASICs, while doing everything possible to mitigate the need to support Destination Options in ASICs. This may be a necessary expedient for many platforms. However, it should not be the only approach, or even the long-term approach for the IETF.

                                                                                                                                   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,

  *   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

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 2 Sep 2019 15:14:33 +0100

> The decision to inject any prefix into someone's IGP (or BGP) is a local 

It is, and most operators take pains to avoid injecting shared 
addressing resources into their routing domains.  These days it usually 
relates to policy, but that policy is rooted in the painful reality that 
building infrastructure intended for second or third party tenancy on 
the basis of overlapping number resources is something that can and will 
cause catastrophic architectural problems once clashes occur.

So again, I suggest that if it's the intention for the draft to proceed, 
the authors will need to reach out to RIR policy working groups because 
the additional number resource requirements required do not fit in with 
the current ipv6 resource assignment and allocation policies currently 
in place.

Nick

---

From: Andrew Alston <[email-masked]>
Date: Mon, 2 Sep 2019 16:02:45 +0000

Just another note on clashes – any company that deals with constant and frequent merges and acquisitions will know – uniqueness is paramount – unless you want integration headaches that will cause you weeks of sleepness nights.

And when you’re doing 3 or 4 M&A’s a year – this is very very very important

Andrew

From: spring <[email-masked]> on behalf of Nick Hilliard <[email-masked]>
Date: Monday, 2 September 2019 at 16:28
To: Robert Raszuk <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>, Mark Smith <[email-masked]>, Rob Shakir <[email-masked]>, Fernando Gont <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Nick

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

---

From: Parag Kaneriya <[email-masked]>
Date: Tue, 3 Sep 2019 04:35:43 +0000

Completely agree with Ron.

SRv6+ is much more simpler ,  minimum config required and easy to implement.

Regards
Parag

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Ron Bonica
Sent: Sunday, September 1, 2019 2:04 AM
To: Rob Shakir <robjs=[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [spring] Beyond SRv6.

Rob,

Operational Simplicity

                                                                                                      Thanks,
                                                                                                          Ron

Hi SPRING WG,

Thank you,

-- Rob & Bruno

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 3 Sep 2019 10:43:21 +0000

SPRING WG,

SRv6+ is definitely a better proposal in terms
   1.Adherence to IPv6 Architecture
   2.Efficient encoding
   3.Operational simplicity

   There hasn't been a single mail denying the above advantages of SRv6+
   The only argument has been the SRv6 in its present form has been
   deployed by a couple of operators and a handful interested in it.

   u-sid tries to solve point 2 above but the addressing architecture
   isn't very clear. Deploying this solution in a running network
   hasn't been explained.

   There is clearly interest in the operator community for a better solution and
   I support SPRING WG to continue work on SRv6+.

Rgds
Shraddha

From: spring <[email-masked]> On Behalf Of Ron Bonica
Sent: Monday, September 2, 2019 6:53 PM
To: Rob Shakir <robjs=[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [spring] Beyond SRv6.

Rob,

                                                                                                                                   Ron

Hi SPRING WG,

Thank you,

-- Rob & Bruno

---

From: Fernando Gont <[email-masked]>
Date: Tue, 3 Sep 2019 14:26:29 +0300

> - https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02

The short version of the question would be:
Does any of these I-Ds, and in particular,
draft-ietf-spring-srv6-network-programming (a wg item) propose or
suggest to insert EHs in the network?

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Sep 2019 14:12:49 +0200

Hi Shraddha,

The proposed architecture in CRH based drafts is a significant departure
from Segment Routing Architecture as standardized in IETF.

The compression advantages the set of drafts propose are all based on the
mapping of 16 or 32 bit bitstrings to IPv6 addresses and their flooding in
IGPs and BGP via proposed extensions. Such mapping is not part of SR
Architecture.

As you know I personally have no objections to support any control plane
solution. Specifically if you would honestly admit that proposed
architecture is not in line with Segment Routing Architecture as described
in RFC8402, but solves some customer needs I am sure the acceptance barrier
could be much different.

Taking your scheme - please kindly explain how can you provide the notion
of Global Adj SIDs ref section 3.4 of RFC 8402 ?

With your scheme to operate IPv6 to SID mapping must be flooded in IGP
domain wide so even if nodes do not need to participate in any IPv6 Segment
Routing they will need to store in their control plane such additional
state. Without mapping such additional state in SRv6 operation by non SR
nodes is optional - meaning that SRv6 can operate just fine without any IGP
extensions required.

Quote from "draft-ietf-lsr-isis-srv6-extensions-02":

   Segment Routing can be directly instantiated on the IPv6 data plane
   through the use of the Segment Routing Header defined in
   [I-D.ietf-6man-segment-routing-header].

Can you kindly explain how SRv6+ proposal can be directly instantiated on
the IPv6 data plane without any protocol extensions ?

Kind regards,
Robert

On Tue, Sep 3, 2019 at 12:44 PM Shraddha Hegde <shraddha=
[email-masked]> wrote:

> *From:* spring <[email-masked]> *On Behalf Of *Ron Bonica
> *Sent:* Monday, September 2, 2019 6:53 PM
> *To:* Rob Shakir <robjs=[email-masked]>; SPRING WG List <
> [email-masked]>; [email-masked]
> There may be an elephant in the room that needs addressing….
>
>
>
> Over the years, the IPv6 community has specified a very tight architecture
> that encodes some information in IPv6 addresses, other information in
> Routing headers, and still other information in Destination Options
> headers. SRv6+ adheres strictly to this architecture. Because it reuses
> IPv6 machinery, its specification promises it be painless and its
> deployment promises to be safe. To date, there has been no significant
> technical criticism of SRv6+. Only a claim that SRv6 is nearly complete and
> good enough. (Both of those claims may require scrutiny).
>
>
>
> By contrast, SRv6 varies from the spirit, if not the letter of the IPv6
> architecture. It encodes things in IPv6 address that have never been
> encoded in IPv6 addresses before. It attempts to encode everything else in
> the Routing header, as if the other IPv6 extension headers didn’t exist. It
> frequently tests the limits of RFC 8200 compliance.
>
>
>
> This creates a situation in which each variance from IPv6 orthodoxy
> requires another. For example, because SRv6 encodes instructions in IPv6
> addresses, draft-ali-6man-spring-srv6-oam is required. And now,
> draft-ali-6man-spring-srv6-oam creates its own variances from the IPv6
> orthodoxy. OAM information is encoded in the Routing header and the Routing
> header must be examined, even when Segment Left is equal to zero.
>
>
>
> So, why would the IETF would want to prevent work on the more
> conservative, SRv6+ approach?  This brings us to the back to the elephant
> in the room…..
>
>
>
> Until very recently, relatively few router vendors have supported IPv6
> extension headers in ASICs. If an IPv6 packet contained any extension
> headers at all, it was sent to the slow path.
>
>
>
> SRv6+ encourages router vendors to support both the Routing and
> Destination Options header in ASICs. This sets vendors on a path on a path
> towards more complete implementation of the architecture that the IPv6
> community has developed so carefully over the years. It encourages vendors
> to commit more and more of RFC 8200 to ASICs.
>
>
>
> SRv6 encourages router vendors to support the Routing header in ASICs,
> while doing everything possible to mitigate the need to support Destination
> Options in ASICs. This may be a necessary expedient for many platforms.
> However, it should not be the only approach, or even the long-term approach
> for the IETF.
>
>
>
>
>                                                                                                                             Ron
>
>
>
>
>
>
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Tue, 3 Sep 2019 14:30:59 +0000

Robert,

In SRv6+, global SIDs work in a manner that is very similar SR-MPLS. If you compare the two relevant IS-IS drafts, you will see a striking similarity. This is why SRv6+ uses the term "global SID" as opposed to END SID.

In your message, below, you suggest that if we document the differences between the proposed architecture and that which is documented in RFC 8402, the barrier to acceptance could be much different.

Could we explore that option together? If you generate some bullet points, I can craft some text.

                                                                      Ron

From: Robert Raszuk <[email-masked]>
Sent: Tuesday, September 3, 2019 8:13 AM
To: Shraddha Hegde <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [spring] Beyond SRv6.

Hi Shraddha,

The proposed architecture in CRH based drafts is a significant departure from Segment Routing Architecture as standardized in IETF.

The compression advantages the set of drafts propose are all based on the mapping of 16 or 32 bit bitstrings to IPv6 addresses and their flooding in IGPs and BGP via proposed extensions. Such mapping is not part of SR Architecture.

As you know I personally have no objections to support any control plane solution. Specifically if you would honestly admit that proposed architecture is not in line with Segment Routing Architecture as described in RFC8402, but solves some customer needs I am sure the acceptance barrier could be much different.

Taking your scheme - please kindly explain how can you provide the notion of Global Adj SIDs ref section 3.4 of RFC 8402 ?

With your scheme to operate IPv6 to SID mapping must be flooded in IGP domain wide so even if nodes do not need to participate in any IPv6 Segment Routing they will need to store in their control plane such additional state. Without mapping such additional state in SRv6 operation by non SR nodes is optional - meaning that SRv6 can operate just fine without any IGP extensions required.

Can you kindly explain how SRv6+ proposal can be directly instantiated on the IPv6 data plane without any protocol extensions ?

Kind regards,
Robert

On Tue, Sep 3, 2019 at 12:44 PM Shraddha Hegde <shraddha=[email-masked]<mailto:[email-masked]>> wrote:
SPRING WG,

Rgds
Shraddha

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Ron Bonica
Sent: Monday, September 2, 2019 6:53 PM
To: Rob Shakir <robjs=[email-masked]<mailto:[email-masked]..org>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Rob,

                                                                                                                                   Ron

Hi SPRING WG,

Thank you,

-- Rob & Bruno

Juniper Business Use Only
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=MGvP1t88p5nxvsHQjh7gyztrr0ZFi85Lp6jrR1BDuAA&s=7pfJwdVBFU1PNW3Kj_mogR44p4VwqFdjyW8PjHelXvg&e=>

---

From: Ron Bonica <[email-masked]>
Date: Tue, 3 Sep 2019 14:56:57 +0000

Fernando,

Please search for the work "insert" in Section 4 of https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01. You will see several examples.

You will also see an example where a second Routing header is  inserted.

                                                                       Ron

-----Original Message-----
From: Fernando Gont <[email-masked]> 
Sent: Tuesday, September 3, 2019 7:26 AM
To: Ron Bonica <[email-masked]>; Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [spring] Beyond SRv6.

The short version of the question would be:
Does any of these I-Ds, and in particular, draft-ietf-spring-srv6-network-programming (a wg item) propose or suggest to insert EHs in the network?

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Sep 2019 16:59:45 +0200

Hi Ron,

You are spot on that SRv6+ conceptually and operationally is very similar
to SR-MPLS. That is why calling it SRv6+ to me is not right.

Instead of producing comparisons with existing RFCs or trying to push new
Routing Header type in 6man, new IGP extensions, new BGP extensions etc
...  how about we do something else ?

We drop CRH and we take SR-MPLS as it is now - shipped and interoperable
and we add IP forwarding to it. It could by using some elements from Vector
Routing proposal (
https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-07) or by
verbatim using https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07
 proposal.

That way you get all beauty and power of SR architecture, no impact/change
to data plane and yet you get IP forwarding between SR nodes (either IPv4
or IPv6) to allow minimal data plane overhead deployments for networks
which do not want to use LDP, MPLS as transport or get into RSVP-TE
challanges ?

SRv6 can continue to progress as it offers much broader set of
functionality. It also offers true direct IPv6 solution in that space.

Note that even in SR-MPLS some labels may embed pointers to local
processing functions.

So the bottom line key question stands: Is there anything functionally and
practically missing if we use SR-MPLS-over-IP as compared with SRv6+/CRH
proposal ?

Best,
R.

On Tue, Sep 3, 2019 at 4:31 PM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> In SRv6+, global SIDs work in a manner that is very similar SR-MPLS. If
> you compare the two relevant IS-IS drafts, you will see a striking
> similarity. This is why SRv6+ uses the term “global SID” as opposed to END
> SID.
>
>
>
> In your message, below, you suggest that if we document the differences
> between the proposed architecture and that which is documented in RFC 8402,
> the barrier to acceptance could be much different.
>
>
>
> *Sent:* Tuesday, September 3, 2019 8:13 AM
> *To:* Shraddha Hegde <[email-masked]>
> *Cc:* Ron Bonica <[email-masked]>; Rob Shakir <[email-masked]>;
> SPRING WG List <[email-masked]>; [email-masked]
> *To:* Rob Shakir <robjs=[email-masked]
> <[email-masked]..org>>; SPRING WG List <[email-masked]>;
> [email-masked]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=MGvP1t88p5nxvsHQjh7gyztrr0ZFi85Lp6jrR1BDuAA&s=7pfJwdVBFU1PNW3Kj_mogR44p4VwqFdjyW8PjHelXvg&e=>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Tue, 3 Sep 2019 15:56:28 +0000

Robert,

I am afraid that won't fulfill customer requirements.

The customer is looking for an SR solution that whose efficiency and performance is comparable to SR-MPLS, but operates in an MPLS-free, IPv6 environment.  It should abide, in both spirit and letter, to the requirements of RFC 4291 and RFC 8200.

Returning to your initial offer, is there some architectural statement that could be added to the SRv6+ overview document that would reduce the barrier to acceptance? If so, I would be happy to collaborate with you on that.

                                                                                 Ron

From: Robert Raszuk <[email-masked]>
Sent: Tuesday, September 3, 2019 11:00 AM
To: Ron Bonica <[email-masked]>
Cc: Shraddha Hegde <[email-masked]>; Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [spring] Beyond SRv6.

Hi Ron,

You are spot on that SRv6+ conceptually and operationally is very similar to SR-MPLS. That is why calling it SRv6+ to me is not right.

Instead of producing comparisons with existing RFCs or trying to push new Routing Header type in 6man, new IGP extensions, new BGP extensions etc ...  how about we do something else ?

We drop CRH and we take SR-MPLS as it is now - shipped and interoperable and we add IP forwarding to it. It could by using some elements from Vector Routing proposal (https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-07<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dpatel-2Draszuk-2Dbgp-2Dvector-2Drouting-2D07&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=zDo9AVnTkuCi4IHti-9EhZLUSvGeS-TkbCp3O8pNhVM&s=0P-4AxiQFqdUMdhUADvLEtSweCzPg4UBuxYd--JYWP8&e=>) or by verbatim using https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dmpls-2Dsr-2Dover-2Dip-2D07&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=zDo9AVnTkuCi4IHti-9EhZLUSvGeS-TkbCp3O8pNhVM&s=yHbbMsnrtm_yaU9zVkeITY1ZY0iTzx60SukxXad9Yy8&e=> proposal.

That way you get all beauty and power of SR architecture, no impact/change to data plane and yet you get IP forwarding between SR nodes (either IPv4 or IPv6) to allow minimal data plane overhead deployments for networks which do not want to use LDP, MPLS as transport or get into RSVP-TE challanges ?

SRv6 can continue to progress as it offers much broader set of functionality. It also offers true direct IPv6 solution in that space.

Note that even in SR-MPLS some labels may embed pointers to local processing functions.

So the bottom line key question stands: Is there anything functionally and practically missing if we use SR-MPLS-over-IP as compared with SRv6+/CRH proposal ?

Best,
R.

On Tue, Sep 3, 2019 at 4:31 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                                      Ron

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 3, 2019 8:13 AM
To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Rob Shakir <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Hi Shraddha,

Kind regards,
Robert

Rgds
Shraddha

Rob,

                                                                                                                                   Ron

Hi SPRING WG,

Thank you,

-- Rob & Bruno

---

From: Tarek Saad <[email-masked]>
Date: Tue, 3 Sep 2019 16:52:33 +0000

Hi WG,

RFC8200 (section 4.4) defines the Routing Header as merely means to steer packets across topological elements. My understanding of the SRv6+’s proposal is that it strictly adheres to this and leaves any service or function instructions to be carried in other parts of IPv6 header. This (among other advantages) provides a clean delineation of the different layers of the network (underlay transport from overlay/services) and allows for possibility of different overlay technologies to be seamlessly carried over SRv6+.

This is in contrast to exposing overlays to a specific underlay technology and forcing it to understand and encode the required bits of information it requires within it. Feel free to correct me if I got it wrong.

Regards,
Tarek

From: spring <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Monday, September 2, 2019 at 9:23 AM
To: Rob Shakir <robjs=[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Rob,

By contrast, SRv6 varies from the spirit, if not the letter of the IPv6 architecture. It encodes things in IPv6 address that have never been encoded in IPv6 addresses before. It attempts to encode everything else in the Routing header, as if the other IPv6 extension headers didn’t exist. It frequently tests the limits of RFC 8200 compliance.

So, why would the IETF would want to prevent work on the more conservative, SRv6+ approach?  This brings us to the back to the elephant in the room…..

                                                                                                                                   Ron

Hi SPRING WG,

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://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=>

During the IETF week, two additional drafts have been proposed:
·         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=>

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

Thank you,

-- Rob & Bruno

---

From: Srihari Sangli <[email-masked]>
Date: Tue, 3 Sep 2019 17:48:29 +0000

Hi, WG Folks:

The segment routing solution leveraging the RFC8200 and the IPv6 architecture is better expressed in SRv6+. I support SRv6+.

The Destination Options header as defined in RFC8200 (section 4.6) is to inform the processing needed on the Destination device. The SRv6+ proposal (among other things) builds upon this and I think it is cleaner and clearer as compared to SRv6.

The issues I see with SRv6 proposals (uSID draft: draft-filsfils-spring-net-pgm-extension-srv6-usid-02 and the BGP extension draft: draft-dawra-bess-srv6-services-02) are the following.

  *   DA manipulation along the hop (shifting as the draft proposes) on each router and reconstructing the DA - can make it harder to debug when there is problem.
  *   To avoid prefix packing problem the BGP draft proposes to split the SID across different sections in the protocol PDU.

The above proposals for SRv6 seems like force-fit. My opinion is simpler encoding, proposal built upon well-defined architecture is good in longer run.
Thanks.

srihari…

On 03/09/19, 10:22 PM spring on behalf of Tarek Saad from [email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]> said >

Hi WG,

This is in contrast to exposing overlays to a specific underlay technology and forcing it to understand and encode the required bits of information it requires within it.. Feel free to correct me if I got it wrong.

Regards,
Tarek

Rob,

                                                                                                                                   Ron

Hi SPRING WG,

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

Thank you,

-- Rob & Bruno

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 3 Sep 2019 19:21:49 +0100

Rob,

Clarifying what I wrote previously, I don't think it would be 
appropriate for draft-filsfils-spring-net-pgm-extension-srv6-usid to 
progress further unless the authors can demonstrate that the volume of 
IPv6 addressing required can be satisfied in a way that works within the 
constraints that the operational community operates within.

If there is an expectation that this address space will be assigned from 
the global unicast address block via standard RIR allocation policies, 
then the authors will need to demonstrate that the RIRs are going to be 
comfortable changing their allocation policies to accommodate this.

Nick
> Ron Bonica <mailto:rbonica=[email-masked]>
> 1 September 2019 at 22:10
> Hi Fernando,
>
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01 
> (In particular, Sections 4 and 5)
> - 
> To: Ron Bonica <[email-masked]>; Rob Shakir <[email-masked]>; 
> 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
>
>
>
>
>
> --
> Fernando Gont
> SI6 Networks
> Fernando Gont <mailto:[email-masked]>
> 31 August 2019 at 21:53
> 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
>
>
>
>
>
> Ron Bonica <mailto:rbonica=[email-masked]>
> 31 August 2019 at 21:33
>
> Rob,
>
>   * 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.
>
> 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.
>
> working group, they won’t need to overcome the objections that are 
> and IPv6 (SRv6) data planes. SR-MPLS may also be transported over IP 
> in UDP or GRE.
>
>   * https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00
>   * https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03
>       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 (*).
>
>     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.
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 6 Sep 2019 04:53:08 +0000

<snip>
>   There hasn't been a single mail denying the above advantages of SRv6+

This is absolutely false!

Have you forgotten the very strong arguments against it at the Spring session in Montreal and the various emails on the list that echoed them 😉
Not to mention comments from Robert R (https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo).

Yes, indeed Ron presented the proposal to every workgroup possible in Montreal, only to find no interest from anyone.
I would advise you to read that silence differently. 😉

<snip>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Sep 2019 05:34:21 +0000

Zafar,

Your memory is selective. In the SPRING session, many people argued that “SRv6 was nearly complete and we didn’t need another solution”. But I don’t remember anybody arguing against the technical merits of SRv6+.

If you can make a technical argument against SRv6+, I encourage you to do so. I look forward to a gentlemanly exchange.

                                                                                                         Ron

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]>
Sent: Friday, September 6, 2019 12:53 AM
To: Shraddha Hegde <[email-masked]>; Ron Bonica <[email-masked]>; Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Cc: Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

<snip>

<snip>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 6 Sep 2019 05:42:25 +0000

<snip>

Hi Srihari,

> DA manipulation along the hop (shifting as the draft proposes) on each router and reconstructing the DA - can make it harder to debug when
              > there is problem.

It has been clarified during the Spring WG session in Montreal. Repeating the same –

  *   The original segment list is maintained by using the non-Reduced flavor (in which case the SID list is fully preserved in the SRH).

In reality, debugability is a huge issue in CRH proposal.

For example,
the CRH requires an IPv6 address to the “labels” mapping table (Yuck!).
An operator cannot determine the path packet will take by looking at CRH.
Have you realized how painful it will be for the operator to:

  *   Walk the CRH,
  *   Map each per-node "local labels" to its associated IPv6 address,
  *   Repeat the process for the entire label chain encoded in CRH.
Not to mention, this requires the operators to get the "mapping table" from each node in the network.

Thanks

Regards … Zafar

<snip>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Sep 2019 05:57:44 +0000

Inline.....

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]>
Sent: Friday, September 6, 2019 1:42 AM
To: Srihari Sangli <[email-masked]>; Tarek Saad <[email-masked]>; Ron Bonica <[email-masked]>; Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Cc: Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

<snip>

Hi Srihari,

> DA manipulation along the hop (shifting as the draft proposes) on each router and reconstructing the DA - can make it harder to debug when

It has been clarified during the Spring WG session in Montreal. Repeating the same -

[RB] At the cost of encoding efficiency. 50% decrease !!

[RB] In reality, the debuggability characteristics of SRv6+ are very similar to those of SR-MPLS. We have the same mapping from a short identifier (SRv6+ SID or SR-MPLS Label) to an IPv6 address.

[RB] So, would you like to argue that debuggability is a huge issue in SR-MPLS?

                                                              Ron

For example,
the CRH requires an IPv6 address to the "labels" mapping table (Yuck!).
An operator cannot determine the path packet will take by looking at CRH.
Have you realized how painful it will be for the operator to:

  *   Walk the CRH,

Thanks

Regards ... Zafar

<snip>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 6 Sep 2019 06:13:03 +0000

Hi Ron,

<snip>

> For example, there is no need for an SRv6+ OAM document. It’s just IPv6 and IPv6 OAM just works.

Really?
How can you perform all OAM functions on a system that is based on a “label mapping table” using standard IPv6 OAM?
If service provider has an issue with a (remote) mapping table, how would the provider debug it using the standard IPv6 OAM?
Recall, IPv6 never had such “label mapping table” and hence never had to worry about debugging issues with the “label mapping table”

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 6 Sep 2019 06:17:42 +0000

Hi Ron,

Please see in-line.

Thanks

Regards … Zafar

From: Ron Bonica <[email-masked]>
Date: Friday, September 6, 2019 at 1:57 AM
To: "Zafar Ali (zali)" <[email-masked]>, Srihari Sangli <[email-masked]>, Tarek Saad <[email-masked]>, Rob Shakir <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] Beyond SRv6.

Inline…..

<snip>

Hi Srihari,

[ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in https://tools.ietf.org/html/rfc8029.
[ZA] Are you suggesting you will introduce something similar to RFC8029?

                                                              Ron

For example,

  *   Walk the CRH,

Thanks

Regards … Zafar

<snip>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Sep 2019 06:20:01 +0000

Consider what a simple TRACEROUTE over the SR path would reveal. If you wanted to get really fancy, consider traceroute with RFC 5837 extensions.

                                                          Ron

Sent: Friday, September 6, 2019 2:13 AM

Hi Ron,

<snip>

> For example, there is no need for an SRv6+ OAM document. It's just IPv6 and IPv6 OAM just works.

Really?
How can you perform all OAM functions on a system that is based on a "label mapping table" using standard IPv6 OAM?
If service provider has an issue with a (remote) mapping table, how would the provider debug it using the standard IPv6 OAM?
Recall, IPv6 never had such "label mapping table" and hence never had to worry about debugging issues with the "label mapping table"

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Sep 2019 06:22:57 +0000

Ali,

Nothing so complicated is required. At most, PING and TRACEROUTE with RFC 5837 extensions.

                                                                 Ron

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]>
Sent: Friday, September 6, 2019 2:18 AM
To: Ron Bonica <[email-masked]>; Srihari Sangli <[email-masked]>; Tarek Saad <[email-masked]>; Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Cc: Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Hi Ron,

Please see in-line.

Thanks

Regards ... Zafar

From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 6, 2019 at 1:57 AM
To: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, Srihari Sangli <[email-masked]<mailto:[email-masked]>>, Tarek Saad <[email-masked]<mailto:[email-masked]>>, Rob Shakir <[email-masked]<mailto:[email-masked]>>, SPRING WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] Beyond SRv6.

Inline.....

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 6, 2019 1:42 AM
To: Srihari Sangli <[email-masked]<mailto:[email-masked]>>; Tarek Saad <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Rob Shakir <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Beyond SRv6.

<snip>

Hi Srihari,

[ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in https://tools.ietf.org/html/rfc8029<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8029__;!8WoA6RjC81c!TkBkBFPiX8_HzpxayXHu3zPmLXGXoQv2JitOPuzsxDMSS0wZKsKN68a_insHhyXn$>.
[ZA] Are you suggesting you will introduce something similar to RFC8029?

                                                              Ron

For example,

  *   Walk the CRH,

Thanks

Regards ... Zafar

<snip>

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Sep 2019 06:26:05 +0000

<snip>

> Not to mention comments from Robert R (https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo). 

Arguments against a proposal in the IETF are meant to be judged on technical merit. Yes - I heard arguments in Montreal about previous work done on alternatives and about srv6+ supposedly being late to the party - but the technical arguments - those I didn’t hear, maybe I missed them, so, if I did, I apologize, and perhaps you can assist us it in telling us what they were.  

As I have said to others - if there are technical problems with the stuff we are working on here - put those issues on the table - and where possible speaking for myself here - every effort will be made to accommodate - but - you are late to the party - is not a valid argument.

> I would advise you to read that silence differently. 😉  

I would advise taking a close read on RFC7282 - specifically section 2.

And as a final thought:

One of the things that was being said - was that network programming took years to develop etc - well - in this industry years - is a lifetime - and sometimes if something takes years - an alternative will arise during that development cycle - that either addresses needs in a different manner that is more efficient, or addresses additional needs beyond those addresses by the original still in progress ideas.  That I would argue is the sign of a healthy developing industry that is getting contributions from people who have perspectives beyond that of the proposer of the original idea.  That - is called progress

Andrew

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 6 Sep 2019 06:34:14 +0000

Hi Ron,

MPLS tool kit was created as IP tool kit (ICMP) was not sufficient to debug an MPLS subsystem.

By bringing in the “label mapping table” in IPv6 network, you have inherited the same problem industry has solved for MPLS OAM during the last ~20 years.

Thanks

Regards … Zafar

From: Ron Bonica <[email-masked]>
Date: Friday, September 6, 2019 at 2:23 AM
To: "Zafar Ali (zali)" <[email-masked]>, Srihari Sangli <[email-masked]>, Tarek Saad <[email-masked]>, Rob Shakir <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] Beyond SRv6.

Ali,

                                                                 Ron

Hi Ron,

Please see in-line.

Thanks

Regards … Zafar

Inline…..

<snip>

Hi Srihari,

                                                              Ron

For example,

  *   Walk the CRH,

Thanks

Regards … Zafar

<snip>

---

From: [email-masked]
Date: Fri, 06 Sep 2019 08:41:32 +0200 (CEST)

> Nothing so complicated is required. At most, PING and TRACEROUTE with RFC 5837 extensions.

Are there any vendors actually implementing RFC 5837? Ivan Pepelnjak
commented "However, it looks like nobody implemented it in almost five
years since it was published." at

   https://blog.ipspace.net/2016/01/are-unnumbered-interfaces-harmful.html

Has the situation changed?

Steinar Haug, AS2116

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 6 Sep 2019 06:51:10 +0000

Hi Steinar,

I am glad you asked.

I am not aware of any implementation of RFC 5837.

Even if it is implemented, it never talks about providing information from a distributed “local label mapping table”, as defined by the CRH.

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Friday, September 6, 2019 at 2:42 AM
To: "rbonica=[email-masked]" <rbonica=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Steinar Haug, AS2116

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Sep 2019 07:04:19 +0000

Zafar,

One of the things I keep seeing below is you referring to the operators perspective.  So - as someone who actually is from an operator - and has done substantial testing of the proposed solution let me give you the perspective of an operator.

Firstly - as an operator - on the table mapping - I've seen absolutely no problem with this - particularly if I add bgp crh signaling which lets me build a mapping table that can be understood in multiple systems which do not necessarily need to know about the rest of the network (this is particularly useful on inline DPI systems and other such things)
Secondly - as an operator - the segregation between what is an address and how said address is directed - rather than a constant change in the address to us seems far safer.  In the uSID draft, a leak of a more specific prefix in the network because of finger trouble - can fundamentally break routing - and well, that could be rather interesting to start debugging.
Thirdly - as an operator - without retaining the uncompressed list of SID's in the header, I have a debugging nightmare - and zero ability to figure out packet pathing through the network at intermediary points - and you keep saying that this is addressed by retaining the full SID list - but - if I do that - can you explain to me what the point of the micro sid is - since - I was under the impression that the point was to remove the overhead - the moment I take this approach - how am I not back at square one with the same overhead?
Forth - as an operator - I am deeply uncomfortable with the fact that the proposal fundamentally redefines the semantics of the address with potential unintended consequences - and despite the fact that multiple times I have raised the redefinition of the semantics of the address when compared against RFC4291 - I have yet to see this addressed
Fifth - as an operator - I have concerns about the inflation of the IGP, and this was raised in Montreal.  I was told that this could be addressed by renumbering my network - sorry - I hardly view this as viable
Sixth - as an operator that has to apply for space from the RIR's - and has concerns about address space utilization - a request was made in Montreal for an evaluation of actual address space required by this solution - which as of yet has not been forthcoming.  However, when looking closely, I'm pretty sure we can figure out how much space this is.  To this end, as per Nick Hilliards suggestion, perhaps we should approach the RIR's about allocation policies to seek the viewpoints from them as the allocators of space.  I am even willing to take this on, and prepared to put a global policy into the RIR system through all 5 RIR's to change the allocation policies to cater for this once I have a firmer grasp on h ow much address space will be utilized.  At that point we can see what the appetite is from that perspective. (In fact some prelim work on such a policy proposal has already begun)

Thanks

Andrew

From: ipv6 <[email-masked]> On Behalf Of Zafar Ali (zali)
Sent: Friday, 6 September 2019 09:18
To: Ron Bonica <[email-masked]>; Srihari Sangli <[email-masked]>; Tarek Saad <[email-masked]>; Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [spring] Beyond SRv6.

Hi Ron, 

Please see in-line. 

Thanks

Regards … Zafar 

From: Ron Bonica <mailto:[email-masked]>
Date: Friday, September 6, 2019 at 1:57 AM
To: "Zafar Ali (zali)" <mailto:[email-masked]>, Srihari Sangli <mailto:[email-masked]>, Tarek Saad <mailto:[email-masked]>, Rob Shakir <mailto:[email-masked]>, SPRING WG List <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>
Subject: RE: [spring] Beyond SRv6.

Inline…..

Juniper Business Use Only
From: Zafar Ali (zali) <mailto:[email-masked]> 
Sent: Friday, September 6, 2019 1:42 AM
To: Srihari Sangli <mailto:[email-masked]>; Tarek Saad <mailto:[email-masked]>; Ron Bonica <mailto:[email-masked]>; Rob Shakir <mailto:[email-masked]>; SPRING WG List <mailto:[email-masked]>; mailto:[email-masked]
Cc: Zafar Ali (zali) <mailto:[email-masked]>
Subject: Re: [spring] Beyond SRv6.
 
<snip>
 
Hi Srihari, 
 
> DA manipulation along the hop (shifting as the draft proposes) on each router and reconstructing the DA - can make it harder to debug when 
              > there is problem.

• The original segment list is maintained by using the non-Reduced flavor (in which case the SID list is fully preserved in the SRH).  

 

 
                                                              Ron

For example, 
the CRH requires an IPv6 address to the “labels” mapping table (Yuck!). 
An operator cannot determine the path packet will take by looking at CRH. 
Have you realized how painful it will be for the operator to: 
• Walk the CRH, 
• Map each per-node "local labels" to its associated IPv6 address,  
• Repeat the process for the entire label chain encoded in CRH.
Not to mention, this requires the operators to get the "mapping table" from each node in the network. 
 
Thanks
 
Regards … Zafar 
 
<snip>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 10:01:05 +0200

Hi Andrew,

I can say that I may even agree with some of your points. But one question
I asked which no one responded still stands ...

SRv6+ is almost identical to SR-MPLS with IP transport between segment
nodes. Both require mapping, both require changes to OAM, both require IGP
extensions, both can use the same forwarding hardware and logic, both
require almost identical operation etc .... As you know even main author of
SRv6+ agrees with all of this in the notes sent to the list.

So please help me to understand why entire industry who wants to be good
IETF citizen and Industry player should now invest a lot of resources in
development, testing, shipping and support of a solution which is just a
poor mirror of something which is already available ?

Yes some folks were allergic to MPLS in the past and some are still
allergic to MPLS. But as someone who have worked since Tag Switching early
days on that piece of technology let me tell you that vast majority of
those folks do not even understand the difference between MPLS used for
transport and MPLS used as forwarding demux for the applications. They just
treat it the very same way like an evil or devil protocol which does
nothing else other then demonstrate their complete ignorance of the
subject.

Yes MPLS to be used as a transport is a mistake. It was not a mistake in
the past as when we rolled out services which required encapsulation most
platforms in the field just could not do line rate IP encapsulation. But
those days are gone. If in 1998 time frame routers could do IPv4 in IPv4
encap MPLS as a transport would have never succeeded.

Then of course there was more mistakes TDP later by IETF collaboration
became LDP was a mapping protocol - yes another mistake instead of making
up front domain wide labels and extended IGPs and BGP for that. Well the
thought was that working on single protocol will be easier then extending
ISIS, OSPFv2 (and v3 on the radar), RIPv2, EIGRP.

But this is MPLS transport which in spite of little group of folks still
selling it around believe it or not it is going away.

But nothing is wrong about using 20 bit labels as demux for applications
and services. Packet carry bits. Nowhere in the packet even if you decode
it carefully it says "I am MPLS" ... forwarding on the boxes also uses bit
lookup and if you ask your vendor they can paint it and abstract all the
MPLS legacy in the CLI for you so you never see it.

Bottom line is that I see no reason at all to adopt a solution which walks
like a duck, quacks like a duck and only carries a label "I am not a duck"

Best,
R.

On Fri, Sep 6, 2019 at 9:04 AM Andrew Alston <
[email-masked]> wrote:

> Zafar,
>
> One of the things I keep seeing below is you referring to the operators
> perspective.  So - as someone who actually is from an operator - and has
> done substantial testing of the proposed solution let me give you the
> perspective of an operator.
>
> Firstly - as an operator - on the table mapping - I've seen absolutely no
> problem with this - particularly if I add bgp crh signaling which lets me
> build a mapping table that can be understood in multiple systems which do
> not necessarily need to know about the rest of the network (this is
> particularly useful on inline DPI systems and other such things)
> Secondly - as an operator - the segregation between what is an address and
> how said address is directed - rather than a constant change in the address
> to us seems far safer.  In the uSID draft, a leak of a more specific prefix
> in the network because of finger trouble - can fundamentally break routing
> - and well, that could be rather interesting to start debugging.
> Thirdly - as an operator - without retaining the uncompressed list of
> SID's in the header, I have a debugging nightmare - and zero ability to
> figure out packet pathing through the network at intermediary points - and
> you keep saying that this is addressed by retaining the full SID list - but
> - if I do that - can you explain to me what the point of the micro sid is -
> since - I was under the impression that the point was to remove the
> overhead - the moment I take this approach - how am I not back at square
> one with the same overhead?
> Forth - as an operator - I am deeply uncomfortable with the fact that the
> proposal fundamentally redefines the semantics of the address with
> potential unintended consequences - and despite the fact that multiple
> times I have raised the redefinition of the semantics of the address when
> compared against RFC4291 - I have yet to see this addressed
> Fifth - as an operator - I have concerns about the inflation of the IGP,
> and this was raised in Montreal.  I was told that this could be addressed
> by renumbering my network - sorry - I hardly view this as viable
> Sixth - as an operator that has to apply for space from the RIR's - and
> has concerns about address space utilization - a request was made in
> Montreal for an evaluation of actual address space required by this
> solution - which as of yet has not been forthcoming.  However, when looking
> closely, I'm pretty sure we can figure out how much space this is.  To this
> end, as per Nick Hilliards suggestion, perhaps we should approach the RIR's
> about allocation policies to seek the viewpoints from them as the
> allocators of space.  I am even willing to take this on, and prepared to
> put a global policy into the RIR system through all 5 RIR's to change the
> allocation policies to cater for this once I have a firmer grasp on h ow
> much address space will be utilized.  At that point we can see what the
> appetite is from that perspective. (In fact some prelim work on such a
> policy proposal has already begun)
>
> Thanks
> Andrew
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 6 Sep 2019 08:28:27 +0000

Hi Andrew,

I agree with Robert.
CRH is nothing else than IPv6 over SR-MPLS.
In the vast majority of the deployments (single SP domain), one can deploy MPLS.
In a minority of cases where some MPLS discontinuity in the domain could exist, SR-MPLS over IP/UDP is an adopted and deployed solution.

As you stated in your original response”
“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.”

I can see why you liked CRH.

Thanks

Regards … Zafar

From: Robert Raszuk <[email-masked]>
Date: Friday, September 6, 2019 at 4:01 AM
To: Andrew Alston <[email-masked]>
Cc: "Zafar Ali (zali)" <[email-masked]>, Ron Bonica <[email-masked]>, Srihari Sangli <[email-masked]>, Tarek Saad <[email-masked]>, Rob Shakir <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

I can say that I may even agree with some of your points. But one question I asked which no one responded still stands ...

SRv6+ is almost identical to SR-MPLS with IP transport between segment nodes. Both require mapping, both require changes to OAM, both require IGP extensions, both can use the same forwarding hardware and logic, both require almost identical operation etc .... As you know even main author of SRv6+ agrees with all of this in the notes sent to the list.

So please help me to understand why entire industry who wants to be good IETF citizen and Industry player should now invest a lot of resources in development, testing, shipping and support of a solution which is just a poor mirror of something which is already available ?

Yes some folks were allergic to MPLS in the past and some are still allergic to MPLS. But as someone who have worked since Tag Switching early days on that piece of technology let me tell you that vast majority of those folks do not even understand the difference between MPLS used for transport and MPLS used as forwarding demux for the applications. They just treat it the very same way like an evil or devil protocol which does nothing else other then demonstrate their complete ignorance of the subject.

Yes MPLS to be used as a transport is a mistake. It was not a mistake in the past as when we rolled out services which required encapsulation most platforms in the field just could not do line rate IP encapsulation. But those days are gone. If in 1998 time frame routers could do IPv4 in IPv4 encap MPLS as a transport would have never succeeded.

Then of course there was more mistakes TDP later by IETF collaboration became LDP was a mapping protocol - yes another mistake instead of making up front domain wide labels and extended IGPs and BGP for that. Well the thought was that working on single protocol will be easier then extending ISIS, OSPFv2 (and v3 on the radar), RIPv2, EIGRP.

But this is MPLS transport which in spite of little group of folks still selling it around believe it or not it is going away.

But nothing is wrong about using 20 bit labels as demux for applications and services. Packet carry bits. Nowhere in the packet even if you decode it carefully it says "I am MPLS" ... forwarding on the boxes also uses bit lookup and if you ask your vendor they can paint it and abstract all the MPLS legacy in the CLI for you so you never see it.

Bottom line is that I see no reason at all to adopt a solution which walks like a duck, quacks like a duck and only carries a label "I am not a duck"

Best,
R.

<snip>

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Sep 2019 08:40:05 +0000

An Zafar – I told by those words – I am pragmatic though as an operator.  I know that srv6 in some form or another is coming – I stated as much on various blogs. I am not fool enough to believe that I am not going to be forced into a situation where I am going to be made to run some variant of this – because I  have been told very bluntly by certain vendors that mpls style development for v6 will cease at a control plane level – and we are already seeing situations where despite sr-mpls working just fine – certain vendors have actively chosen to not support this with IPv6.

That has put me in a position where I have to be pragmatic – because – as an operator with a massive network – I have to be able to continue to well, operate.  That leaves me needing something that finds a common ground between those who want MPLS to die – and the MPLS usage which is present, real and necessary in the world in which I operate.  That leaves me with needing a version of SRv6 which is usable, does not impose insane overhead, and does not fundamentally rewrite the IPv6 protocol.

I have been extremely open and honest about this – I will however say – that the added functionality through the network programmability – all of which is catered for in CRH without the need to rewrite the IPv6 specification to do it – does have other use cases – and hence – CRH actually works for us – very very well – because it retains that which I need – while adding some really nice advantages on top of it.  But again – we have asked – multiple times – for the technical problems behind CRH – and the ringing in my ears is deafening from the silence.

Andrew

From: Zafar Ali (zali) <[email-masked]>
Sent: Friday, 6 September 2019 11:28
To: Robert Raszuk <[email-masked]>; Andrew Alston <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Srihari Sangli <[email-masked]>; Tarek Saad <[email-masked]>; Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

I agree with Robert.

Thanks

Regards … Zafar

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 6, 2019 at 4:01 AM
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, Ron Bonica <[email-masked]<mailto:[email-masked]>>, Srihari Sangli <[email-masked]<mailto:[email-masked]>>, Tarek Saad <[email-masked]<mailto:[email-masked]>>, Rob Shakir <[email-masked]<mailto:[email-masked]>>, SPRING WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

Best,
R.

<snip>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 10:51:40 +0200

> between those who want MPLS to die

Again you are putting an equal sign between MPLS used for transport and
MPLS used for application and services. While I know and agree that MPLS
for transport should die - I have not met anyone who says MPLS for
applications is a bad demux encoding.

> for the technical problems behind CRH

I pointed the need for mapping as architectural deficiency.

But this is not the point.

If next week there will be three more proposals of data plane encoding
(XRH, ZRH & YRH) and each asking for new IGP & BGP control plane extensions
for Segment Routing over v6 should IETF adopt all of them and should all
vendors work and deliver all of them ? Is this what you think is in best
interest of the industry ?

Many thx,
R,

On Fri, Sep 6, 2019 at 10:40 AM Andrew Alston <
[email-masked]> wrote:

> An Zafar – I told by those words – I am pragmatic though as an operator.
> I know that srv6 in some form or another is coming – I stated as much on
> various blogs. I am not fool enough to believe that I am not going to be
> forced into a situation where I am going to be made to run some variant of
> this – because I  have been told very bluntly by certain vendors that mpls
> style development for v6 will cease at a control plane level – and we are
> already seeing situations where despite sr-mpls working just fine – certain
> vendors have actively chosen to not support this with IPv6.
>
>
>
> That has put me in a position where I have to be pragmatic – because – as
> an operator with a massive network – I have to be able to continue to well,
> operate.  That leaves me needing something that finds a common ground
> between those who want MPLS to die – and the MPLS usage which is present,
> real and necessary in the world in which I operate.  That leaves me with
> needing a version of SRv6 which is usable, does not impose insane overhead,
> and does not fundamentally rewrite the IPv6 protocol.
>
>
>
> I have been extremely open and honest about this – I will however say –
> that the added functionality through the network programmability – all of
> which is catered for in CRH without the need to rewrite the IPv6
> specification to do it – does have other use cases – and hence – CRH
> actually works for us – very very well – because it retains that which I
> need – while adding some really nice advantages on top of it.  But again –
> we have asked – multiple times – for the technical problems behind CRH –
> and the ringing in my ears is deafening from the silence.
>
>
>
> Andrew
>
>
>
>
>
> *From:* Zafar Ali (zali) <[email-masked]>
> *Sent:* Friday, 6 September 2019 11:28
> *To:* Robert Raszuk <[email-masked]>; Andrew Alston <
> [email-masked]>
> *Cc:* Ron Bonica <[email-masked]>; Srihari Sangli <
> [email-masked]>; Tarek Saad <[email-masked]>; Rob Shakir <
> [email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; Zafar
> Ali (zali) <[email-masked]>
> In a minority of cases where some MPLS discontinuity in the domain could
> exist, SR-MPLS over IP/UDP is an adopted and deployed solution.
>
>
>
> “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.”
>
>
>
> *Date: *Friday, September 6, 2019 at 4:01 AM
> *Cc: *"Zafar Ali (zali)" <[email-masked]>, Ron Bonica <[email-masked]>,
> Srihari Sangli <[email-masked]>, Tarek Saad <[email-masked]>,
> Rob Shakir <[email-masked]>, SPRING WG List <[email-masked]>, "

---

From: Srihari Sangli <[email-masked]>
Date: Fri, 6 Sep 2019 09:40:22 +0000

Zafar,

·         The original segment list is maintained by using the non-Reduced flavor (in which case the SID list is fully preserved in the SRH).

If I understand it right, the IPv6 packet carrying uSIDs will also have full set SID carried in the SRH. The full SID list in SRH is to provide additional information ? Pls let me know if I got it right. Thanks.

srhari…

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 13:01:27 +0200

Not really. Only SR OAM packets may need it. Is that a real problem ?

Best
R

On Fri, Sep 6, 2019, 11:41 Srihari Sangli <ssangli=
[email-masked]> wrote:

> Zafar,
>
>
>
> ·         The original segment list is maintained by using the
> non-Reduced flavor (in which case the SID list is fully preserved in the
> SRH).
>
>
>
> If I understand it right, the IPv6 packet carrying uSIDs will also have
> full set SID carried in the SRH. The full SID list in SRH is to provide
> additional information ? Pls let me know if I got it right. Thanks.
>
>
>
> srhari…
>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Sep 2019 12:54:54 +0000

Steinar,

Vanilla TRACEROUTE reveals all of the mapping information. RFC 5837 offers some nice extras, but isn't strictly required.

                                                                            Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Friday, September 6, 2019 2:42 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] Beyond SRv6.

> Nothing so complicated is required. At most, PING and TRACEROUTE with RFC 5837 extensions.

Are there any vendors actually implementing RFC 5837? Ivan Pepelnjak commented "However, it looks like nobody implemented it in almost five years since it was published." at

   https://urldefense.com/v3/__https://blog.ipspace.net/2016/01/are-unnumbered-interfaces-harmful.html__;!8WoA6RjC81c!RpF3DZprPGFaTqO0XZL8SzokiqeBSyo_ldL6rRhpOyJxiSJ0rtHM15msZ5hD9Fga$ 

Steinar Haug, AS2116

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 15:02:25 +0200

>
> Vanilla TRACEROUTE reveals all of the mapping information. RFC 5837 offers
> some nice extras, but isn't strictly required.
>

Really ?

If your traffic policy steers some TCP traffic for ports 4000-5000 to take
segment A-B-C-D and for ports 6000-7000 to take segment A-E-F-G-D how your
vanilla traceroute is going to discover it when running the traceroute from
outside of the network ?

Thx,
R.

---

From: Tarek Saad <[email-masked]>
Date: Fri, 6 Sep 2019 14:07:00 +0000

Hi Zafar,

>> In a minority of cases where some MPLS discontinuity in the domain could exist, SR-MPLS over IP/UDP is an adopted and deployed solution.
For an operator who has used MPLS, don’t you think SRv6+ will appeal more to them in this case? Given all the arguments that are being made that it does resemble MPLS in its mapping prefixes to short labels?

Regards,
Tarek

From: "Zafar Ali (zali)" <[email-masked]>
Date: Friday, September 6, 2019 at 4:28 AM
To: Robert Raszuk <[email-masked]>, Andrew Alston <[email-masked]>
Cc: Ron Bonica <[email-masked]>, Srihari Sangli <[email-masked]>, Tarek Saad <[email-masked]>, Rob Shakir <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

I agree with Robert.

Thanks

Regards … Zafar

Hi Andrew,

Best,
R.

<snip>

---

From: Srihari Sangli <[email-masked]>
Date: Fri, 6 Sep 2019 14:14:49 +0000

On 06/09/19, 4:32 PM Robert Raszuk from [email-masked]<mailto:[email-masked]> said >

Thanks for clarification. Like Ron pointed out before, its inefficient encoding.

srihari…

---

From: Ca By <[email-masked]>
Date: Fri, 6 Sep 2019 07:16:00 -0700

> vendors have actively chosen to not support this with IPv6.
Eh, i am also an operator of a non-trivial size network.  The above
statements make me concerned about your business.

1.   I consider SR to be a bit of flashy marketing push by vendors to do
things with no unique merit. One looks at a 1/2 page author list of these
SR draft and must note something here is fishy. Folks from my company who
have no idea what SRv6 is have been asked to add their names to the author
list of SPRING drafts.  It is a mirage, and poor form by the SR pushers to
engage in this fake grass roots movement.

2. IMO, SR is like lisp and nsh. Overly complicated protocols driven by
vendors, with plenty of astro turf, to make networks more complicated and
expensive.  Oh, and it is so simple ans great, but only runs on the newest
kit ...

3.  You are very confused. You give vendors requirements and they comply.
You pay them, they do stuff. They will even put your name on an I-D you
have not read.

4. SR is not coming to anyone who does not have the religion of SR. SR is
no more of a solid bet than LISP or OpenFlow or NSH or “SDN” or PCF ....

My bet is MPLS will not die, it is 20 years mature and not going anywhere.
Let’s see a vendor launch a serious carrier router without MPLS....

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 16:17:55 +0200

I don't think so.

In OAM packets are on purpose made huge - even up to MTU to make sure real
customer packets can go through or to detect and diagnose MTU issues. So
adding SRH to it is nothing one can call inefficient.

Wrong tree :)

Cheers,
R.

On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli <[email-masked]> wrote:

>
>
> On 06/09/19, 4:32 PM Robert Raszuk from [email-masked] said >
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Sep 2019 03:19:30 -0400

As an operator of a Tier 1 provider with massive mpls networks I think our traditional bread and butter “mpls” will be around for a very very long time as is IPv4 if not longer.

Most all service provider cores run greater then or equal to MTU 9000 mpls cores to account for mpls overhead shims being tacked on plus edge overhead from possible GRE tunneling or IPSEC so in general making  the core the maximum Jumbo MTU supported by most vendors at 9216 is what is generally done out in the field.

So for SRv6 support of multiple or many EH insertions is really a non issue for 
most operators.

From reading through all the discussion threads the SR insertion is two fold one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up requiring double EH insertions on the Ingress PE tunnel head end SRv6 source node and then second scenario being a possible EH insertions occurrence on intermediate nodes.  I have not read through the drafts or RFC regarding Ti-LFA with SR but since that is an IGP extension I am guessing an opaque LSA and is not the traditional MPLS FRR link/node/path protection that adds an additional mpls shim so not sure why an EH insertion needs to occur for Ti-LFA.  Can someone clarify that use case for me.  Also the EH insertion on intermediate node what is the use case or reason for that.  My guess is it’s for special use case of stitching SRv6 domains together.  Please clarify.

I do agree with some of the other operators on the marketing hype and push for SR-MPLS and SRv6 is not for every service provider as goes the mantra ..”if it’s not broken..don’t try to fix it..leave it alone” and I think you can definitely say that for MPLS as it has had a SOLID run for service providers since the 90’s ever since ATM and frame relay were put to rest so I don’t think that it’s going away any time soon.

I think it would be a serious mistake and sad state of affairs for vendors to push SR-MPLS and SRv6 and stop development and support of MPLS as that would really pigeon hole all operators into one technology which does not fit the bill for every use case out there.

The mention of SR-MPLS pulling support for IPv6 and forcing operators to go with SRv6 is a wrong move for vendors and would really limit operators with flexibility to chose based on their use case to stay with traditional mpls or go with with SR-MPLS or SRv6 only if necessary with their unique use case warrants.

I think SR-MPLS and SRv6 should be marketed by vendors and the industry as yet another tool in our operator “design toolbox” to use as we see fit or not use but not be forced into it.

There are particular use cases for SR-MPLS for migration from existing LDP and the downside of having state maintained in the core is not a downside as the P and PE nodes have to be provisioned anyway so their is no savings in pulling mpls LDP/mLDP with SR-MPLS “Sr-prefer” and ditching LDP.   

I think the major use case for SR-MPLS and SRv6 is coloring per-vrf TE feature for L3 VPNs steering without adding complexity of adding ibgp loopback egress PE FEC next hop to traffic engineer L3 VPN traffic.  That is a unique use case and not every major service provider has that requirement so if you don’t their really is no need to jump on the SR band wagon and you can stay put with the tried and true mpls that has been around for decades and is not going away any time soon.

SRv6 has a more ubiquitous all encompassing use case that could serve for MPLS core replacement or on the public internet or for enterprise network traffic engineering of flows between data centers or access to data center and an alternative to SD WAN application based routing solutions.  But here as well the use case benefit has to exist.  Nobody wants to be forced into it if it’s unnecessary added complexity.

My 2 1/2 cents 

Regards,

Gyan Mishra
Verizon Communications 
Cell- 301 502-1347

Sent from my iPhone

> On Sep 6, 2019, at 10:17 AM, Robert Raszuk <[email-masked]> wrote:
> 
> I don't think so. 
> 
> In OAM packets are on purpose made huge - even up to MTU to make sure real customer packets can go through or to detect and diagnose MTU issues. So adding SRH to it is nothing one can call inefficient. 
> 
> Wrong tree :) 
> 
> Cheers,
> R.
>

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 9 Sep 2019 11:44:27 +0800

Hi, Folks:

We should think first what we want do via these technologies.

>From my perspective, the main aim of the SR(Segment Routing) is to assure the E2E performance of key application, which is lacked via the traditional distributed protocol (although RSVP-TE has tried to accomplish this aim, but it is not widely deployed for the dynamic adjustment).

With the help of SDN controller in the network, it is possible for the operator to fulfill the overall adjustments for their network, for the following scenarios:

1) E2E performance assurance for the key applications.

2) Maximize the links efficiency within the network.

3) Eliminate the temporary congestion within the network.

4) Consider not only MPLS, but also Native IP network (IPv4/IPv6 or their coexistence)

SR technologies solely can’t fulfill the above requirements. Considering that SR should also depend on the SDN Controller/PCE to get the overall situation of network, calculate the optimal path end to end, we think there are some other simple way to accomplish the above goals.

We call the solution to meet the above requirements as CCDR(Centrally Control Dynamic Routing). The key steps of this solution are the followings:

1) Build multi-BGP sessions for the key application traffic and the normal traffic.

2) Populate the different prefixes via the different BGP sessions.

3) Manipulate the path to the different BGP nexthop dynamically(via PCEP protocol).

Based on the above procedures, we can get the following effects:

1. Adjust the path for different traffic on demand.

2. Eliminate the needs to keep the complex states as RSVP-TE

3. Does not carry the path information on every packet of the assured application as done in SR.

4. Same solution for the IPv4, IPv6, even the coexistence of them

5. Same solution for the intra domain and inter domain traffic.

6. Do not change the forward behavior of devices. Large amounts of deployed routers can be reused/Only the control plane needs to be updated.

7. Can even apply to the MPLS network in future, based on the same philosophy.

The detail solution can be found at the following documents:

draft- <https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/> ietf <https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/> -teas-native- <https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/> ip <https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/> -scenarios <https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/>  (Scenario and Simulation Results)
 <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> draft-ietf <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> -teas- <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> pce <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> -native- <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> ip <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/>  (Solution document)
 <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> draft-ietf <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> - <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> pce <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> - <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> pcep <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> -extension-native- <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> ip <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/>  (PCEP extension)

More comments and thoughts are welcome.

If necessary, I can make one summary presentation on the coming IETF meeting in SPRING wg.

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Gyan Mishra
发送时间: 2019年9月8日 15:20
收件人: Robert Raszuk
抄送: SPRING WG List; [email-masked]; Ron Bonica; Srihari Sangli; Rob Shakir; Zafar Ali (zali); Tarek Saad
主题: Re: [spring] Beyond SRv6.

most operators.

>From reading through all the discussion threads the SR insertion is two fold one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up requiring double EH insertions on the Ingress PE tunnel head end SRv6 source node and then second scenario being a possible EH insertions occurrence on intermediate nodes.  I have not read through the drafts or RFC regarding Ti-LFA with SR but since that is an IGP extension I am guessing an opaque LSA and is not the traditional MPLS FRR link/node/path protection that adds an additional mpls shim so not sure why an EH insertion needs to occur for Ti-LFA.  Can someone clarify that use case for me.  Also the EH insertion on intermediate node what is the use case or reason for that.  My guess is it’s for special use case of stitching SRv6 domains together.  Please clarify..

My 2 1/2 cents 

Regards,

Gyan Mishra

Verizon Communications 

Cell- 301 502-1347

Sent from my iPhone

I don't think so. 

Wrong tree :) 

Cheers,

R.

srihari…

---

From: 松嶋聡 <[email-masked]>
Date: Sun, 8 Sep 2019 23:52:01 -0400

As an operator of running a nation wide network in non-trivial size with
SRv6, I agree on that multiple or many SRv6 SIDs support in terms of MTU
size limit is not an issue.

And solutions already exist that enable us to deploy TE with minimum number
of SID (e.g, flex-algo) not only for SRv6, but also for SR-MPLS. Additional
solution to reduce size of SIDs seems beneficial. However, requiring
another type of EH just for reduce the size of SIDs sounds no make sense to
me.

Therefore I see no benefits on CRH for our deployments. SRH has been
developed and specified through legitimate IETF process with non-trivial
time and efforts. Adding extra header for the same purpose would waste all
our precious efforts so far and require much unnecessary time and efforts
down the load which is no make sense for all of us.

We have to stick SRH to be used and be compatible with the existing SID
definition in SRH if we need solution to reduce SIDs.

Cheers,
--satoru

2019/09/08 16:19、Gyan Mishra <[email-masked]>のメール:

As an operator of a Tier 1 provider with massive mpls networks I think our
traditional bread and butter “mpls” will be around for a very very long
time as is IPv4 if not longer.

Most all service provider cores run greater then or equal to MTU 9000 mpls
cores to account for mpls overhead shims being tacked on plus edge overhead
from possible GRE tunneling or IPSEC so in general making  the core the
maximum Jumbo MTU supported by most vendors at 9216 is what is generally
done out in the field.

So for SRv6 support of multiple or many EH insertions is really a non issue
for
most operators.

>From reading through all the discussion threads the SR insertion is two
fold one being for FRR capabilities using Ti-LFA or remote LFA tunnel so
end up requiring double EH insertions on the Ingress PE tunnel head end
SRv6 source node and then second scenario being a possible EH insertions
occurrence on intermediate nodes.  I have not read through the drafts or
RFC regarding Ti-LFA with SR but since that is an IGP extension I am
guessing an opaque LSA and is not the traditional MPLS FRR link/node/path
protection that adds an additional mpls shim so not sure why an EH
insertion needs to occur for Ti-LFA.  Can someone clarify that use case for
me.  Also the EH insertion on intermediate node what is the use case or
reason for that.  My guess is it’s for special use case of stitching SRv6
domains together.  Please clarify..

I do agree with some of the other operators on the marketing hype and push
for SR-MPLS and SRv6 is not for every service provider as goes the mantra
..”if it’s not broken..don’t try to fix it..leave it alone” and I think you
can definitely say that for MPLS as it has had a SOLID run for service
providers since the 90’s ever since ATM and frame relay were put to rest so
I don’t think that it’s going away any time soon.

I think it would be a serious mistake and sad state of affairs for vendors
to push SR-MPLS and SRv6 and stop development and support of MPLS as that
would really pigeon hole all operators into one technology which does not
fit the bill for every use case out there.

The mention of SR-MPLS pulling support for IPv6 and forcing operators to go
with SRv6 is a wrong move for vendors and would really limit operators with
flexibility to chose based on their use case to stay with traditional mpls
or go with with SR-MPLS or SRv6 only if necessary with their unique use
case warrants.

I think SR-MPLS and SRv6 should be marketed by vendors and the industry as
yet another tool in our operator “design toolbox” to use as we see fit or
not use but not be forced into it.

There are particular use cases for SR-MPLS for migration from existing LDP
and the downside of having state maintained in the core is not a downside
as the P and PE nodes have to be provisioned anyway so their is no savings
in pulling mpls LDP/mLDP with SR-MPLS “Sr-prefer” and ditching LDP.

I think the major use case for SR-MPLS and SRv6 is coloring per-vrf TE
feature for L3 VPNs steering without adding complexity of adding ibgp
loopback egress PE FEC next hop to traffic engineer L3 VPN traffic.  That
is a unique use case and not every major service provider has that
requirement so if you don’t their really is no need to jump on the SR band
wagon and you can stay put with the tried and true mpls that has been
around for decades and is not going away any time soon.

SRv6 has a more ubiquitous all encompassing use case that could serve for
MPLS core replacement or on the public internet or for enterprise network
traffic engineering of flows between data centers or access to data center
and an alternative to SD WAN application based routing solutions.  But here
as well the use case benefit has to exist.  Nobody wants to be forced into
it if it’s unnecessary added complexity.

My 2 1/2 cents

Regards,

Gyan Mishra
Verizon Communications
Cell- 301 502-1347

Sent from my iPhone

I don't think so.

Wrong tree :)

Cheers,
R.

spring mailing list
[email-masked]

---

From: Dirk Steinberg <[email-masked]>
Date: Mon, 9 Sep 2019 15:31:49 +0200

There seems to be some confusion regarding TI-LFA.
A couple of comments:

- Remote LFA tunnel is not used with SR, only TI-LFA which 
  only operates on the node that is the PLR (point of local repair).

- Any encapsulation on the ingress PE with or without EH has nothing 
  to do with TI-LFA except for the special case where the ingress PE
  itself is the PLR.

- TI-LFA is not an IGP extension and does not require one. 
  It is a purely local computation based on IGP topology.

- The PLR for TI-LFA may need to insert some SIDs into the SID
  list to steer the packet around the failure. For the LFA base case
  no SIDs are needed at all. If SID insertion is needed, the PLR 
  will push the required number of labels in the MPLS case. 

  For SRv6, the equivalent operation to the label push is to 
  insert an EH with the required SID list. The packet will already 
  have been encapsulated on the ingress PE and in the most 
  common Internet or VPN base use case it will not even have 
  an EH so that this EH insertion will result only in a single EH.

  Alternatively, the PLR could also be configured to perform
  encapsulation with a new IPv6 header using the repair SID
  as IPv6 destination address, without needing any EH.
  This will work for the vast majority of cases. 
  Remember that one 128-bit SID in SRv6 is in most cases
  equivalent to 2 MPLS labels, i.e. a node label plus an
  adjacency SID can be encoded in a single SRv6 SID.

  Only in extreme cases would the PLR need to add an 
  EH to the new IPv6 header with more SIDs.

- EH insertion for TI-LFA has nothing to do with stitching SRv6 domains.

Hope it helps.

Cheers
Dirk

> Am 08.09.2019 um 09:19 schrieb Gyan Mishra <[email-masked]>:
>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Sep 2019 16:21:52 +0000

Hello Gyan,

Amplifying what you have said.....

There is no reason why SR-MPLS shouldn't work over an IPv6 only infrastructure. So long as every node is MPLS capable, SR-MPLS should not require IPv4 to be enabled.

                                                                               Ron

Juniper Business Use Only
From: Gyan Mishra <[email-masked]>
Sent: Sunday, September 8, 2019 3:20 AM
To: Robert Raszuk <[email-masked]>
Cc: Srihari Sangli <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; Zafar Ali (zali) <[email-masked]>; Rob Shakir <[email-masked]>; Ron Bonica <[email-masked]>; Tarek Saad <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

As an operator of a Tier 1 provider with massive mpls networks I think our traditional bread and butter "mpls" will be around for a very very long time as is IPv4 if not longer.

>From reading through all the discussion threads the SR insertion is two fold one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up requiring double EH insertions on the Ingress PE tunnel head end SRv6 source node and then second scenario being a possible EH insertions occurrence on intermediate nodes.  I have not read through the drafts or RFC regarding Ti-LFA with SR but since that is an IGP extension I am guessing an opaque LSA and is not the traditional MPLS FRR link/node/path protection that adds an additional mpls shim so not sure why an EH insertion needs to occur for Ti-LFA.  Can someone clarify that use case for me.  Also the EH insertion on intermediate node what is the use case or reason for that.  My guess is it's for special use case of stitching SRv6 domains together.  Please clarify.

I do agree with some of the other operators on the marketing hype and push for SR-MPLS and SRv6 is not for every service provider as goes the mantra .."if it's not broken..don't try to fix it..leave it alone" and I think you can definitely say that for MPLS as it has had a SOLID run for service providers since the 90's ever since ATM and frame relay were put to rest so I don't think that it's going away any time soon.

I think SR-MPLS and SRv6 should be marketed by vendors and the industry as yet another tool in our operator "design toolbox" to use as we see fit or not use but not be forced into it.

There are particular use cases for SR-MPLS for migration from existing LDP and the downside of having state maintained in the core is not a downside as the P and PE nodes have to be provisioned anyway so their is no savings in pulling mpls LDP/mLDP with SR-MPLS "Sr-prefer" and ditching LDP.

I think the major use case for SR-MPLS and SRv6 is coloring per-vrf TE feature for L3 VPNs steering without adding complexity of adding ibgp loopback egress PE FEC next hop to traffic engineer L3 VPN traffic.  That is a unique use case and not every major service provider has that requirement so if you don't their really is no need to jump on the SR band wagon and you can stay put with the tried and true mpls that has been around for decades and is not going away any time soon.

SRv6 has a more ubiquitous all encompassing use case that could serve for MPLS core replacement or on the public internet or for enterprise network traffic engineering of flows between data centers or access to data center and an alternative to SD WAN application based routing solutions.  But here as well the use case benefit has to exist.  Nobody wants to be forced into it if it's unnecessary added complexity.

My 2 1/2 cents

Regards,

Gyan Mishra
Verizon Communications
Cell- 301 502-1347

Sent from my iPhone

On Sep 6, 2019, at 10:17 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
I don't think so.

Wrong tree :)

Cheers,
R.

On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli <[email-masked]<mailto:[email-masked]>> wrote:

srihari...
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!QmUWmBSwMeAovLUIjU_O2tFmWCZOPQmNOWvSTsaRgHjWkA0is1xv2wNVKz9IevQp$>

---

From: "Andy Smith (andsmit)" <[email-masked]>
Date: Mon, 9 Sep 2019 16:36:50 +0000

Ron,

Doesn't ISIS require a quad octet / 32 bit / IPv4 address for it's router ID?

So you can't really build an ipv4 'free' network.   Not 100% anyway.

Andy

> On Sep 9, 2019, at 12:21 PM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Hello Gyan,
>  
> Amplifying what you have said…..
>  
> There is no reason why SR-MPLS shouldn’t work over an IPv6 only infrastructure. So long as every node is MPLS capable, SR-MPLS should not require IPv4 to be enabled.
>  
>                                                                                Ron
>  
>  
>  
> From: Gyan Mishra <[email-masked] <mailto:[email-masked]>> 
> To: Robert Raszuk <[email-masked] <mailto:[email-masked]>>
> Cc: Srihari Sangli <[email-masked] <mailto:[email-masked]>>; SPRING WG List <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Zafar Ali (zali) <[email-masked] <mailto:[email-masked]>>; Rob Shakir <[email-masked] <mailto:[email-masked]>>; Ron Bonica <[email-masked] <mailto:[email-masked]>>; Tarek Saad <[email-masked] <mailto:[email-masked]>>
> The mention of SR-MPLS pulling support for IPv6 and forcing operators to go with SRv6 is a wrong move for vendors and would really limit operators with flexibility to chose based on their use case to stay with traditional mpls or go with with SR-MPLS or SRv6 only if necessary with their unique use case warrants..
>  
> On Sep 6, 2019, at 10:17 AM, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I don't think so. 
>  
> On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli <[email-masked] <mailto:[email-masked]>> wrote:
>  
> On 06/09/19, 4:32 PM Robert Raszuk from [email-masked] <mailto:[email-masked]> said >
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!QmUWmBSwMeAovLUIjU_O2tFmWCZOPQmNOWvSTsaRgHjWkA0is1xv2wNVKz9IevQp$>--------------------------------------------------------------------
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 9 Sep 2019 17:51:48 +0000

Andy,

RFC 6119 defines ipv6 router-id .
It is not mandatory to advertise IPv4 router-id in ISIS.

Rgds
Shraddha

From: spring <[email-masked]> On Behalf Of Andy Smith (andsmit)
Sent: Monday, September 9, 2019 10:07 PM
To: Ron Bonica <rbonica=[email-masked]>
Cc: SPRING WG List <[email-masked]>; [email-masked]; Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>; Rob Shakir <[email-masked]>; Tarek Saad <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Ron,

Andy

On Sep 9, 2019, at 12:21 PM, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Hello Gyan,

                                                                               Ron

Juniper Business Use Only
From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, September 8, 2019 3:20 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Srihari Sangli <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; Rob Shakir <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Beyond SRv6.

My 2 1/2 cents

Regards,

Gyan Mishra
Verizon Communications
Cell- 301 502-1347

Sent from my iPhone

Wrong tree :)

Cheers,
R.

srihari…

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Sep 2019 14:05:21 +0200

Hi,

I want to understand whether Segment Routing Header is a technology
considered for GTP in cellular networks that connect smartphones and IoT
devices.

As far as I know, the IPv6 deployments for such cellular networks use
GTP, which runs on IPv4. That needs to evolve to IPv6. When moving to
IPv6 that would change to IPv6-in-IPv6. Further in time, that
IPv6-in-IPv6 would become just IPv6.

Is SRH considered there?

Alex

Le 09/09/2019 à 05:52, 松嶋聡 a écrit :
> And solutions already exist that enable us to deploy TE with minimum 
> number of SID (e.g, flex-algo) not only for SRv6, but also for SR-MPLS. 
> Additional solution to reduce size of SIDs seems beneficial. However, 
> requiring another type of EH just for reduce the size of SIDs sounds no 
> make sense to me.
> 
> time and efforts. Adding extra header for the same purpose would waste 
> all our precious efforts so far and require much unnecessary time and 
> efforts down the load which is no make sense for all of us.
> 
> 2019/09/08 16:19、Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>>のメール:
> 
>> As an operator of a Tier 1 provider with massive mpls networks I think 
>> our traditional bread and butter “mpls” will be around for a very very 
>> long time as is IPv4 if not longer.
>>
>> Most all service provider cores run greater then or equal to MTU 9000 
>> mpls cores to account for mpls overhead shims being tacked on plus 
>> edge overhead from possible GRE tunneling or IPSEC so in general 
>> making  the core the maximum Jumbo MTU supported by most vendors at 
>> 9216 is what is generally done out in the field.
>>
>> From reading through all the discussion threads the SR insertion is 
>> two fold one being for FRR capabilities using Ti-LFA or remote LFA 
>> tunnel so end up requiring double EH insertions on the Ingress PE 
>> tunnel head end SRv6 source node and then second scenario being a 
>> possible EH insertions occurrence on intermediate nodes.  I have not 
>> read through the drafts or RFC regarding Ti-LFA with SR but since that 
>> is an IGP extension I am guessing an opaque LSA and is not the 
>> traditional MPLS FRR link/node/path protection that adds an additional 
>> mpls shim so not sure why an EH insertion needs to occur for Ti-LFA.  
>> Can someone clarify that use case for me.  Also the EH insertion on 
>> intermediate node what is the use case or reason for that.  My guess 
>> is it’s for special use case of stitching SRv6 domains together.  
>> Please clarify..
>>
>> I do agree with some of the other operators on the marketing hype and 
>> push for SR-MPLS and SRv6 is not for every service provider as goes 
>> the mantra ..”if it’s not broken..don’t try to fix it..leave it alone” 
>> and I think you can definitely say that for MPLS as it has had a SOLID 
>> run for service providers since the 90’s ever since ATM and frame 
>> relay were put to rest so I don’t think that it’s going away any time 
>> soon.
>>
>> I think it would be a serious mistake and sad state of affairs for 
>> vendors to push SR-MPLS and SRv6 and stop development and support of 
>> MPLS as that would really pigeon hole all operators into one 
>> technology which does not fit the bill for every use case out there.
>>
>> The mention of SR-MPLS pulling support for IPv6 and forcing operators 
>> to go with SRv6 is a wrong move for vendors and would really limit 
>> operators with flexibility to chose based on their use case to stay 
>> with traditional mpls or go with with SR-MPLS or SRv6 only if 
>> necessary with their unique use case warrants.
>>
>> I think SR-MPLS and SRv6 should be marketed by vendors and the 
>> industry as yet another tool in our operator “design toolbox” to use 
>> as we see fit or not use but not be forced into it.
>>
>> There are particular use cases for SR-MPLS for migration from existing 
>> LDP and the downside of having state maintained in the core is not a 
>> downside as the P and PE nodes have to be provisioned anyway so their 
>> is no savings in pulling mpls LDP/mLDP with SR-MPLS “Sr-prefer” and 
>> ditching LDP.
>>
>> loopback egress PE FEC next hop to traffic engineer L3 VPN traffic.  
>> That is a unique use case and not every major service provider has 
>> that requirement so if you don’t their really is no need to jump on 
>> the SR band wagon and you can stay put with the tried and true mpls 
>> that has been around for decades and is not going away any time soon.
>>
>> SRv6 has a more ubiquitous all encompassing use case that could serve 
>> for MPLS core replacement or on the public internet or for enterprise 
>> network traffic engineering of flows between data centers or access to 
>> data center and an alternative to SD WAN application based routing 
>> solutions.  But here as well the use case benefit has to exist.  
>> Nobody wants to be forced into it if it’s unnecessary added complexity.
>>
>> My 2 1/2 cents
>>
>> Regards,
>>
>> Gyan Mishra
>> Verizon Communications
>> Cell- 301 502-1347
>>
>> Sent from my iPhone
>>
>>> In OAM packets are on purpose made huge - even up to MTU to make sure 
>>> real customer packets can go through or to detect and diagnose MTU 
>>> issues. So adding SRH to it is nothing one can call inefficient.
>>>
>>> Wrong tree :)
>>>
>>> Cheers,
>>> R.
>>>
>>>     __ __
>>>     On 06/09/19, 4:32 PM Robert Raszuk from [email-masked]
>>>     <mailto:[email-masked]> said >____
>>>
>>>     __ __
>>>
>>>     Not really. Only SR OAM packets may need it. Is that a real
>>>     problem ? ____
>>>
>>>     __ __
>>>
>>>         Thanks for clarification. Like Ron pointed out before, its
>>>         inefficient encoding.____
>>>
>>>         __ __
>>>
>>>         srihari…____
>>>

---

From: Ron Bonica <[email-masked]>
Date: Tue, 10 Sep 2019 13:09:32 +0000

Alexander,

I don't participate in 3GPP, but I hear that the following question was put to a vote during CT4#93 (August 26-30, 2019):

- Do you want to standardize SRv6 user plane protocol (w/o GTP-U) as described in clause 6.2.2 of TR 29.892?

Maybe someone who participates can report the results.

                                                                                              Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Tuesday, September 10, 2019 8:05 AM
To: [email-masked]
Subject: Re: [spring] Beyond SRv6

Hi,

I want to understand whether Segment Routing Header is a technology considered for GTP in cellular networks that connect smartphones and IoT devices.

As far as I know, the IPv6 deployments for such cellular networks use GTP, which runs on IPv4. That needs to evolve to IPv6. When moving to
IPv6 that would change to IPv6-in-IPv6. Further in time, that
IPv6-in-IPv6 would become just IPv6.

Is SRH considered there?

Alex

Le 09/09/2019 à 05:52, 松嶋聡 a écrit :
> As an operator of running a nation wide network in non-trivial size 
> with SRv6, I agree on that multiple or many SRv6 SIDs support in terms 
> of MTU size limit is not an issue.
> 
> requiring another type of EH just for reduce the size of SIDs sounds 
> no make sense to me.
> 
> developed and specified through legitimate IETF process with 
> non-trivial time and efforts. Adding extra header for the same purpose 
> would waste all our precious efforts so far and require much 
> unnecessary time and efforts down the load which is no make sense for all of us.
> 
> We have to stick SRH to be used and be compatible with the existing 
> SID definition in SRH if we need solution to reduce SIDs.
> 
> Cheers,
> --satoru
> 
>> As an operator of a Tier 1 provider with massive mpls networks I 
>> think our traditional bread and butter “mpls” will be around for a 
>> very very long time as is IPv4 if not longer.
>>
>> So for SRv6 support of multiple or many EH insertions is really a non 
>> issue for most operators.
>>
>> read through the drafts or RFC regarding Ti-LFA with SR but since 
>> that is an IGP extension I am guessing an opaque LSA and is not the 
>> traditional MPLS FRR link/node/path protection that adds an 
>> additional mpls shim so not sure why an EH insertion needs to occur for Ti-LFA.
>> and I think you can definitely say that for MPLS as it has had a 
>> SOLID run for service providers since the 90’s ever since ATM and 
>> frame relay were put to rest so I don’t think that it’s going away 
>> any time soon.
>>
>> There are particular use cases for SR-MPLS for migration from 
>> existing LDP and the downside of having state maintained in the core 
>> is not a downside as the P and PE nodes have to be provisioned anyway 
>> so their is no savings in pulling mpls LDP/mLDP with SR-MPLS 
>> “Sr-prefer” and ditching LDP.
>>
>> I think the major use case for SR-MPLS and SRv6 is coloring per-vrf 
>> TE feature for L3 VPNs steering without adding complexity of adding 
>> ibgp loopback egress PE FEC next hop to traffic engineer L3 VPN traffic.
>> network traffic engineering of flows between data centers or access 
>> to data center and an alternative to SD WAN application based routing 
>>> In OAM packets are on purpose made huge - even up to MTU to make 
>>> sure real customer packets can go through or to detect and diagnose 
>>> MTU issues. So adding SRH to it is nothing one can call inefficient.
>>>
>>> Wrong tree :)
>>>
>>> Cheers,
>>> R.
>>>
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
>>> ring__;!8WoA6RjC81c!QuuGxfYaKY18JJXyoD_Oe8_Uw4NMuUrz4oZdXfTr4r5oPvR1
>>> CREd8sPdsxuYOWGb$
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spr
>> ing__;!8WoA6RjC81c!QuuGxfYaKY18JJXyoD_Oe8_Uw4NMuUrz4oZdXfTr4r5oPvR1CR
>> Ed8sPdsxuYOWGb$
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!8WoA6RjC81c!QuuGxfYaKY18JJXyoD_Oe8_Uw4NMuUrz4oZdXfTr4r5oPvR1CREd8s
> Pds3jENCH2$

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!QuuGxfYaKY18JJXyoD_Oe8_Uw4NMuUrz4oZdXfTr4r5oPvR1CREd8sPds3jENCH2$
--------------------------------------------------------------------

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 10 Sep 2019 23:01:48 +0900

Hi Alex, Ron,

Thanks for your interest in the mobile side of SRv6. :-) 

SRv6 is considered as user plane protocol in DMM WG. And yes, 3GPP also considered it as an user plane protocol in 3GPP CT WG4. 

Thank to 128-bits length SID in SRH, the proposed SRv6 user plane solution fulfills almost 3GPP requirements. The vote result unfortunately shows that not to standardize it as an alternative of GTP within the scope of Rel-16. But it doesn’t matter here in IETF.

So now it might be the chance for you Ron, if you want to introduce your solution to 3GPP.

Good luck.
--satoru

---

From: Hirofumi Ichihara<[email-masked]>
Date: Wed, 11 Sep 2019 09:55:12 +0900

Hi folks,
​
Let me mention my opinion as an operator.
​
Our company already has deployed and used SRv6 Network in our DC. Our use case is L3VPN to isolate network for each multi-tenant and we decided to use T.Encaps and End.DX4. Currently, we deployed hypervisors and gateway nodes which are aware of SRv6. Although there are many routers not supported SRv6 between HVs and GW nodes, it works fine because of current SRH mechanism. We actually use one SID only between HV and HV, HV and GW so we don't face the issue like many SIDs now although we have a plan to use multiple SIDs for our SFC use case.
​
We don't have specific opinion to shorter SIDs. However, we operator hope strongly that new thing must configure backward compatibility or reasonable migration plan.
​
Thanks,
Hirofumi

-----Original Message-----
From: "Shraddha Hegde"<shraddha=[email-masked]>
To: "Andy Smith (andsmit)"<[email-masked]>; "Ron Bonica"<rbonica=[email-masked]>;
Cc: "SPRING WG List"<[email-masked]>; "[email-masked]"<[email-masked]>; "Gyan Mishra"<[email-masked]>; "Robert Raszuk"<[email-masked]>; "Rob Shakir"<[email-masked]>; "Tarek Saad"<[email-masked]>;
Sent: 2019-09-10 (火) 02:51:48 (GMT+09:00)
Subject: Re: [spring] Beyond SRv6.
 
Andy,

Rgds
Shraddha

Ron,

 
Andy

Hello Gyan,

 
                                                                               Ron

 

 

 

 

My 2 1/2 cents 
 
Regards,
 
Gyan Mishra
Verizon Communications 
Cell- 301 502-1347
 
Sent from my iPhone

I don't think so. 

Wrong tree :) 
 
Cheers,
R.

 

srihari…

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 11 Sep 2019 10:31:12 +0900

Excellent news.

I’d capture your case in the SRv6 deployment draft, in case you’d be okay.

Cheers,
--satoru

---

From: Hirofumi Ichihara<[email-masked]>
Date: Wed, 11 Sep 2019 11:54:03 +0900

Hi Satoru,
​
Of course, okay. That sounds good.
​
Thanks,
Hirofumi

-----Original Message-----
From: "Satoru Matsushima"<[email-masked]>
To: "Hirofumi Ichihara"<[email-masked]>; "SPRING WG List"<[email-masked]>;
Cc: "Ron Bonica"<rbonica=[email-masked]>; <[email-masked]>; "Robert Raszuk"<[email-masked]>; "Rob Shakir"<[email-masked]>; "Tarek Saad"<[email-masked]>;
Sent: 2019-09-11 (水) 10:31:12 (GMT+09:00)
Subject: Re: [spring] Beyond SRv6.
 
Excellent news.

Cheers,
--satoru

Hi folks,
​

-----Original Message-----
From: "Shraddha Hegde"<shraddha=[email-masked]>
To: "Andy Smith (andsmit)"<[email-masked]>; "Ron Bonica"<rbonica=[email-masked]>;
Cc: "SPRING WG List"<[email-masked]>; "[email-masked]"<[email-masked]>; "Gyan Mishra"<[email-masked]>; "Robert Raszuk"<[email-masked]>; "Rob Shakir"<[email-masked]>; "Tarek Saad"<[email-masked]>;
Sent: 2019-09-10 (火) 02:51:48 (GMT+09:00)
Subject: Re: [spring] Beyond SRv6.
 
Andy,

Rgds
Shraddha

Ron,

 
Andy

Hello Gyan,

 
                                                                               Ron

 

 

 

 

My 2 1/2 cents 
 
Regards,
 
Gyan Mishra
Verizon Communications 
Cell- 301 502-1347
 
Sent from my iPhone

I don't think so. 

Wrong tree :) 
 
Cheers,
R.

 

srihari…

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 12 Sep 2019 08:57:39 +0800

Hi, folks,
Last year China Telecom begun to implement SRv6 trial in Sichun province for the bearing and interconnection of video platforms which are  located in different cities, service agilities,secure sepertion, traffic steering and other features of SRv6 have been demonstrated in this trial. Based on this, SRv6 will be implementated in larger-scale in CT.
No technologies is 100% perfect,I agree that compression mechanism is needed to reduce the the overhead of long SID in the long term, but it is better to be compatible withe SRH, instead of designing a complete new one. CRH is a complete new design, it move the complexities from SRH to DOH. 
Moreover, I hope more efforts of SRv6 should be given on how to support new services,for instance, Application-aware network (APN). Meanwhile, we should consider more on how to implmement smooth transition and protect the network assetof carriers.

Best regards
Chongfeng

From: Dirk Steinberg
Date: 2019-09-09 21:31
To: Gyan Mishra
CC: SPRING WG List; [email-masked]; Robert Raszuk; Rob Shakir; Tarek Saad
Subject: Re: [spring] Beyond SRv6.
There seems to be some confusion regarding TI-LFA.
A couple of comments:

Hope it helps.

Cheers
Dirk

---

From: Tom Herbert <[email-masked]>
Date: Wed, 11 Sep 2019 19:04:26 -0700

> Moreover, I hope more efforts of SRv6 should be given on how to support new services,for instance, Application-aware network (APN). Meanwhile, we should consider more on how to implmement smooth tr…
Chongfeng,

That presumes that SRv6 is a least common denominator in networks and
indispensable core functionality. It's not. As already pointed there
are existing alternatives that might be operative for adding services
like APN. SRv6 is one manifestation, but not the only one-- there's
NSH, SR-MPLS, other encapsulations, etc. From this POV, SRv6+, and
even SRv6, is just another mechanism. Naturally, we want solutions
that work across the broadest number of cases possible. So the
question is: what are the common functionalities that could work
across these different methods. In IPv6, it's DOH and HBH options that
are common across all forms of routing header and packets. So, IMO,
those should be considered first before investing in narrower
solutions (i.e. TLVs is the routing header). There is a similar
argument in security that AH should have been considered before
creating a point solution in the HMAC of SRv6.

Tom

---

From: "Bernier, Daniel" <[email-masked]>
Date: Thu, 12 Sep 2019 03:41:05 +0000

+1

The ability of using a single SRH to convey behaviour information wether they are per-segment or per-path has proven to be very simple and quick to define in various data plane targets.

At first analysis, trying to replicate with CRH + DOH variants, the logic required for service programs is more com​plex.

What happens if I need TLVs mid-point in a path but not at its end (e.g. referring to the Ole's ACME analogy) ? Would they now be defined in a seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested midpoint devices will have to lookup beyond the TLVs to get to CRH for next segment ?

Similar question would be on how would we implement proxy behaviours either dynamic or static ? If I read https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04 correctly, we then need NSH for richer service chains constructs (think Gi-LAN). This means I need CRH, some variants of DOH + NSH​.

I fail to see the simplicity there.

Dan B

________________________________
From: spring <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Wednesday, September 11, 2019 8:57 PM
To: List
Cc: Rob Shakir; 6man; Tarek Saad; Robert Raszuk
Subject: [EXT]Re: [spring] Beyond SRv6.

Hi, folks,

Best regards
Chongfeng

From: Dirk Steinberg<mailto:[email-masked]>
Date: 2019-09-09 21:31
To: Gyan Mishra<mailto:[email-masked]>
CC: SPRING WG List<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Raszuk<mailto:[email-masked]>; Rob Shakir<mailto:[email-masked]>; Tarek Saad<mailto:[email-masked]>
Subject: Re: [spring] Beyond SRv6.
There seems to be some confusion regarding TI-LFA.
A couple of comments:

Hope it helps.

Cheers
Dirk

Am 08.09.2019 um 09:19 schrieb Gyan Mishra <[email-masked]<mailto:[email-masked]>>:

---

From: Xiejingrong <[email-masked]>
Date: Thu, 12 Sep 2019 05:19:22 +0000

+1
I think the need to ‘walk through the EH chain’ in fast-path is difficult, for the last 2 decades, and will for the near future I guess.
The SRv6 is very careful not to ‘walk through the EH chain’.
Instead it just ‘handle the least leading header(s)’, with a preceding ‘FIB lookup’ indication, and ‘FIB lookup’ is a step that will need to do in chip anyway for any packet.
This makes SRv6 deployable in chips for the first time of EH invention by ISO and later by IPv6.
This makes SRv6 the paradigm of handling any EH in chips In my opinion.

One can check my understand on page 11 to 14 of the slides I prepared in ietf105 (though got no time slot to present):
https://datatracker.ietf.org/meeting/105/materials/slides-105-bier-bier-ipv6-encapsulation-00.pdf

DOH has it benefits, and is recommended in 8200, but the mix of many different EHs and different Option TLVs for a solution is obviously complex in data-plane.
Using a single EH to the best, with the appropriate preceding indication, is simple, ordered, friendly to chip, direct, perfect.
https://mailarchive.ietf.org/arch/msg/ipv6/SgkSGtSBmB4G51ajnBp3UbjJl8I

Thanks
Jingrong

From: spring [mailto:[email-masked]] On Behalf Of Bernier, Daniel
Sent: Thursday, September 12, 2019 11:41 AM
To: [email-masked]; List <[email-masked]>
Cc: Rob Shakir <[email-masked]>; 6man <[email-masked]>; Tarek Saad <[email-masked]>; Robert Raszuk <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

+1

Dan B

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Hi, folks,

Best regards
Chongfeng

Hope it helps.

Cheers
Dirk

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Sep 2019 15:30:16 +1000

It's simple because IPv6 doesn't look past the fixed IPv6 header to perform
its forwarding, and matches on the Destination Address to determine if to
perform deeper packet host processing.

You're building much more complicated forwarding services if you're going
to be marching on TLVs etc. past the IPv6 fixed header.

However vendors and carrier engineering groups like selling and deploying
new gear, so I suppose that's ok. They don't have to operate it or fix it
when it breaks.

On Thu, 12 Sep 2019, 13:41 Bernier, Daniel, <[email-masked]> wrote:

> +1
>
>
> The ability of using a single SRH to convey behaviour information wether
> they are per-segment or per-path has proven to be very simple and quick to
> define in various data plane targets.
>
>
> At first analysis, trying to replicate with CRH + DOH variants, the logic
> required for service programs is more com​plex.
>
>
> What happens if I need TLVs mid-point in a path but not at its end (e.g.
> referring to the Ole's ACME analogy) ? Would they now be defined in a
> seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested
> midpoint devices will have to lookup beyond the TLVs to get to CRH for next
> segment ?
>
>
> Similar question would be on how would we implement proxy behaviours
> either dynamic or static ? If I read
> https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04 correctly,
> we then need NSH for richer service chains constructs (think Gi-LAN). This
> means I need CRH, some variants of DOH + NSH​.
>
>
> ------------------------------
> *From:* spring <[email-masked]> on behalf of
> [email-masked] <[email-masked]>
> *Sent:* Wednesday, September 11, 2019 8:57 PM
> *To:* List
> *Cc:* Rob Shakir; 6man; Tarek Saad; Robert Raszuk
> *Subject:* [EXT]Re: [spring] Beyond SRv6.
>
>
> Hi, folks,
>
> Moreover, I hope more efforts of SRv6 should be given on how to support new services,for instance, Application-aware network
> (APN). Meanwhile, we should consider more on
> how to implmement smooth transition and protect the network assetof carriers.
>
> Best regards
> Chongfeng
>
>
> *From:* Dirk Steinberg <[email-masked]>
> *Date:* 2019-09-09 21:31
> *To:* Gyan Mishra <[email-masked]>
> *CC:* SPRING WG List <[email-masked]>; [email-masked]; Robert Raszuk
> <[email-masked]>; Rob Shakir <[email-masked]>; Tarek Saad
> <[email-masked]>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 12 Sep 2019 07:22:23 -0700

> Instead it just ‘handle the least leading header(s)’, with a preceding ‘FIB lookup’ indication, and ‘FIB lookup’ is a step that will need to do in chip anyway for any packet.
Jingrong,

You seem to be ignoring the fact that SRH includes its own TLV
mechanism. There is no reason to believe that TLVs in the segment
header can somehow be more efficiently processed than TLVs in
Destination Options or Hop-by-Hop Options. Considering that there
seems to be almost no implementation of segment routing TLVs (so far
only Linux is reported to support it and even then the implementation
is not conformant), I'm dubious of any claims that SRv6 is chip
friendly or works in fast-path. If the idea is that TLVs in SRH really
aren't needed and will never actually be used, then it would appear
that the considerable effort in 6man WG trying to fix them was wasted
on a mere academic exercise.

Tom

> At first analysis, trying to replicate with CRH + DOH variants, the logic required for service programs is more complex.
>
>
>
> Similar question would be on how would we implement proxy behaviours either dynamic or static ? If I read https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04 correctly, we then need NSH for richer service chains constructs (think Gi-LAN). This means I need CRH, some variants of DOH + NSH.
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 12 Sep 2019 14:57:34 +0000

Dan,

Both good questions !!!

In Ole’s example, a segment endpoint that is not the SR egress node executes a service instruction. In SRv6+, this kind of service instruction is called a Per Segment Service Instruction (PSSI). It is encoded in a Destination Options header that precedes the Routing header. Because IPv6 processes extension header in the order that they appear in the packet, this Destination Options header is processed by each segment endpoint, including the SR Path egress node.

The Destination Options header includes one or more options. Options are processed in the order that they appear in the header. Each option has a unique type and the first two bits of the type identifier determine how the processing node will behave if it does not recognize the option.

SRv6+ defines a new IPv6 Option, called the PSSI option. The first two bits of its type identifier are 00. So, if the processing node does not recognize the option, or is not configured to process the option, it skips over the option and continues to process the packet. Typically, core routers won’t execute Per Segment Service Instructions. So, by default, they will be configured to skip over the PSSI option. However, devices that provide per segment services (e.g., firewall services , DPI services) will process the PSSI.

The PSSI by no means attempts to replace the NSH.

In SRv6+, service instructions that are executed by the SR path egress node only are called Per Path Service Instructions (PPSI). These instructions are encoded in another Destination Options header that precedes the upper layer header. This Destination Options header is processed by the SR path egress node only.

SRv6+ defines another new IPv6 Option, called the PSSI option. The first two bits of its type identifier are 10. So, if the processing node does not recognize the option, it discards the packet and sends an ICMP message to the packet source.

The benefit of separating the Routing Header from the PPSI are as follows:

  *   An AH or ESP header can be interposed between the Routing Header and the Destination Options header.  The AH or ESP can be used to protect PPSI.
  *   The Routing header isn’t bloated with PPSI information. Therefore, ASIC based intermediate nodes don’t have to load PPSI information into on chip memory
  *   That there is no need to define a myriad of SID’s, some of which are valid only when SL is equal to 0 and others that are valid when SL > 0. If an instruction is valid only when SL = 0, it isn’t a SID. It is a PPSI.

                                                                                 Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Bernier, Daniel
Sent: Wednesday, September 11, 2019 11:41 PM
To: [email-masked]; List <[email-masked]>
Cc: Rob Shakir <[email-masked]>; 6man <[email-masked]>; Tarek Saad <[email-masked]>; Robert Raszuk <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

+1

Similar question would be on how would we implement proxy behaviours either dynamic or static ? If I read https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04__;!8WoA6RjC81c!X44n64pmIbfHbV6M9TDLFFeeQIEn4zROUOebJ7V5MYncIU31g1sgm7aA1kXfbfNt$> correctly, we then need NSH for richer service chains constructs (think Gi-LAN). This means I need CRH, some variants of DOH + NSH​.

Dan B

Hi, folks,

Best regards
Chongfeng

Hope it helps.

Cheers
Dirk

---

From: Ron Bonica <[email-masked]>
Date: Thu, 12 Sep 2019 16:34:17 +0000

Mark,

I think that you may have exposed yet another elephant in the room……

IPv6 defines a robust extensibility architecture, that includes multiple extension headers. Initially, IPv6 adoption was slow and router vendors were not highly motivated commit extension headers to ASICs. Also, in those days, ASICs were not so capable as they are today.

From the above-mentioned data points, we should not infer that it is beyond the capability of a modern vendor to develop an ASIC that supports a more complete set of extension headers. Two things have changed. As IPv6 adoption progresses, vendors are becoming more committed to IPv6. Beyond that, ASICs have become more capable over the decades.

We shouldn’t abandon the IPv6 extensibility architecture based on a claim that ASICs cannot and will never be able to  process multiple extension headers.

                                                                                                  Ron

From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: Thursday, September 12, 2019 1:30 AM
To: EXT - [email-masked] <[email-masked]>
Cc: Rob Shakir <[email-masked]>; SPRING WG <[email-masked]>; 6man <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]; Tarek Saad <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

It's simple because IPv6 doesn't look past the fixed IPv6 header to perform its forwarding, and matches on the Destination Address to determine if to perform deeper packet host processing.

You're building much more complicated forwarding services if you're going to be marching on TLVs etc. past the IPv6 fixed header.

However vendors and carrier engineering groups like selling and deploying new gear, so I suppose that's ok. They don't have to operate it or fix it when it breaks.
On Thu, 12 Sep 2019, 13:41 Bernier, Daniel, <[email-masked]<mailto:[email-masked]>> wrote:

+1

Similar question would be on how would we implement proxy behaviours either dynamic or static ? If I read https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJjCZB0f5dp14y8L$> correctly, we then need NSH for richer service chains constructs (think Gi-LAN). This means I need CRH, some variants of DOH + NSH​.

Dan B

Hi, folks,

Best regards
Chongfeng

  an EH so that this EH insertion will result only in a single EH..

Hope it helps.

Cheers
Dirk

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJjCZB0f5aWDOXgb$>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 16 Sep 2019 20:37:45 +0000

Hi Ron, I agree ASICs are always improving, indeed this is evident in the number of successful SRv6 deployments and multiple vendor implementations at line rate on merchant silicon, and multiple vendor ASICs.

Is “SRv6+” (PSSI+CRH+PPSI) implemented and deployed at line rate?
You’ve been asked this several times.  Since you’re the only implementor(?) and one operator is claiming deployment or testing, I am curious.

Regardless of ASIC capabilities there are two performance penalties you will not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups.

Requiring all segments in a CRH segment list to process an arbitrary length DOH+set of PSSI’s and other options is always very expensive.
- It is expensive in SRAM as previously discussed in these threads.
- It is expensive in parsing logic to know and process a set of TLVs in any ASIC or NP.

Spreading PSSI, CRH, PPSI operations in multiple headers and multiple identifiers you now have multiple lookups at a node.
1 - lookup destination address
2 - lookup one or more PSSI and future destination options.
3 - lookup the CRH label or PPSI label.
4 - lookup new destination address

Compare this with SRv6.
1 - lookup destination address
2 - lookup new destination address

While ASICs are more capable and will continue to be more capable, these technical performance problems you introduce with PSSI+CRH+PPSI will not go away.

Darren

On Sep 12, 2019, at 12:34 PM, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Mark,

                                                                                                  Ron

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Mark Smith
Sent: Thursday, September 12, 2019 1:30 AM
To: EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: Rob Shakir <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Beyond SRv6.

+1

Dan B

Hi, folks,

Best regards
Chongfeng

Hope it helps.

Cheers
Dirk

---

From: Ron Bonica <[email-masked]>
Date: Tue, 17 Sep 2019 01:59:14 +0000

Hi Darren,

I think that your argument can be summarized as follows:

  *   SRv6 requires only two FIB searches
  *   SRv6+ requires 4 or more FIB searches
  *   Therefore, SRv6+ cannot possibly forward at line speed

Have I summarized your argument correctly? If not, please set me straight. If so, please read on.

First, SRv6+ never requires more than 4 FIB searches. The DOH that precedes the CRH contains, at most, one PSSI. Therefore SRv6+ requires four FIB searches, at most.

Second, SRv6+ only requires 4 FIB searches the following case:

  *   The packet contains two instances of the DOH. (Most use-cases require only one.)
  *   The processing node is configured to process the PSSI. (Many ASIC-based devices, because of their role in the network, won’t support any per segment service instructions. This nodes will be configured to ignore the PSSI. That is why it is optional.)

So, in most use-cases, SRv6+ requires only 3 FIB searches.

So, you might now argue that:

  *   SRv6 requires only two FIB searches
  *   SRv6+ requires three and sometimes four FIB searches
  *   Therefore, SRv6+ cannot possibly forward at line speed

Here, some slightly deeper thought might be required. A platform has two relevant resources:

  *   A route lookup ASIC, that can process some number of packets per second
  *   Some number of interfaces, that can forward some number of bits per second

So long as the ASIC can process enough packets per second to saturate the line cards, we are forwarding at full line rate. So long as a platform has a sufficiently capable ASIC, it will be able to forward at line speed. But it’s a matter of how the platform is designed. If the ASIC is not sufficiently capable, of course, it will not forward at line speed.

In your email, you say that I have been asked several times to report on the state of Juniper’s SRv6+ implementation. While I cannot provide details, you can assume that we wouldn’t be working on this if we thought that performance was going to be sub-optimal.

You also suggest that Juniper’s is the only implementation. Are you sure that this is correct?

                                                                                                                     Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]>
Sent: Monday, September 16, 2019 4:38 PM
To: Ron Bonica <[email-masked]>
Cc: Mark Smith <[email-masked]>; EXT - [email-masked] <[email-masked]>; [email-masked]; SPRING WG <[email-masked]>; 6man <[email-masked]>; Robert Raszuk <[email-masked]>; Rob Shakir <[email-masked]>; Tarek Saad <[email-masked]>
Subject: “SRV6+” complexity in forwarding

Compare this with SRv6.

Darren

---

From: Andrew Alston <[email-masked]>
Date: Tue, 17 Sep 2019 17:42:56 +0000

<snip>

  *   You also suggest that Juniper’s is the only implementation. Are you sure that this is correct?

There is a packet capture of CRH for anyone who is interested taken from our DPDK implementation – in this case – this is from the source node of traffic – steering through nodes 3 -> 2 -> 5 -> 5 -> 1 in our lab setup.

https://www.gont.com.ar/packets/CRH.cap<https://www.gont.com.ar/packets/CRH.cap?fbclid=IwAR3gycrlv44jeEWQtRDifa189WdNG9fJ0uNpHer4hu7i_zGQfoyByObectY>

So – there is certainly more than just Juniper working on this.

Thanks

Andrew

Cc: Mark Smith <[email-masked]>; EXT - [email-masked] <[email-masked]>; [email-masked]; SPRING WG <[email-masked]>; 6man <[email-masked]>; Robert Raszuk <[email-masked]>; Rob Shakir <[email-masked]>; Tarek Saad <[email-masked]>

Compare this with SRv6.

Darren

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 18 Sep 2019 13:41:39 +0000

Hi Ron.

I summarized my argument as follows:
"Regardless of ASIC capabilities there are two performance penalties you will not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups.”

You’ve confirmed this additional overhead for "SRv6+".  Thanks.

You then say "So long as the ASIC can process enough packets per second to saturate the line cards, we are forwarding at full line rate."

Yes this is true, but we can conclude: The complexity of "SRv6+" requires ASICs do much more work per packet vs SRv6.

Thanks
  Darren

On Sep 16, 2019, at 9:59 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Hi Darren,

                                                                                                                     Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, September 16, 2019 4:38 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Mark Smith <[email-masked]<mailto:[email-masked]>>; EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; SPRING WG <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Rob Shakir <[email-masked]<mailto:[email-masked]>>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
Subject: “SRV6+” complexity in forwarding

Compare this with SRv6.

Darren

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Sep 2019 08:56:57 -0700

> You’ve confirmed this additional overhead for "SRv6+".  Thanks.

Darren,

How does one escape the performance penalty of TLV processing in SRV6?

Tom

> On Sep 16, 2019, at 9:59 PM, Ron Bonica <[email-masked]> wrote:
>
> Hi Darren,
>
> SRv6 requires only two FIB searches
> SRv6+ requires 4 or more FIB searches
> Therefore, SRv6+ cannot possibly forward at line speed
>
>
> The packet contains two instances of the DOH. (Most use-cases require only one.)
> The processing node is configured to process the PSSI. (Many ASIC-based devices, because of their role in the network, won’t support any per segment service instructions. This nodes will be configured to ignore the PSSI. That is why it is optional.)
>
>
> SRv6 requires only two FIB searches
> SRv6+ requires three and sometimes four FIB searches
> Therefore, SRv6+ cannot possibly forward at line speed
>
>
> A route lookup ASIC, that can process some number of packets per second
> Some number of interfaces, that can forward some number of bits per second
>
>
> On Sep 12, 2019, at 12:34 PM, Ron Bonica <rbonica=[email-masked]> wrote:
>
>

---

From: Dirk Steinberg <[email-masked]>
Date: Thu, 19 Sep 2019 01:40:22 +0200

SRv6 does not require TLV processing for normal forwarding (use case: SP
core).

- Dirk

On Wed, Sep 18, 2019 at 5:57 PM Tom Herbert <[email-masked]> wrote:

> > "Regardless of ASIC capabilities there are two performance penalties you
> will not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups.”
> >
> > You then say "So long as the ASIC can process enough packets per second
> to saturate the line cards, we are forwarding at full line rate."
> >
> > Yes this is true, but we can conclude: The complexity of "SRv6+"
> requires ASICs do much more work per packet vs SRv6.
> >
> > Thanks
> >   Darren
> >
> >
> > First, SRv6+ never requires more than 4 FIB searches. The DOH that
> precedes the CRH contains, at most, one PSSI. Therefore SRv6+ requires four
> FIB searches, at most.
> >
> > The processing node is configured to process the PSSI. (Many ASIC-based
> devices, because of their role in the network, won’t support any per
> segment service instructions. This nodes will be configured to ignore the
> PSSI. That is why it is optional.)
> >
> >
> > So long as the ASIC can process enough packets per second to saturate
> the line cards, we are forwarding at full line rate. So long as a platform
> has a sufficiently capable ASIC, it will be able to forward at line speed.
> But it’s a matter of how the platform is designed. If the ASIC is not
> sufficiently capable, of course, it will not forward at line speed.
> >
> > In your email, you say that I have been asked several times to report on
> the state of Juniper’s SRv6+ implementation. While I cannot provide
> details, you can assume that we wouldn’t be working on this if we thought
> that performance was going to be sub-optimal.
> >
> > Cc: Mark Smith <[email-masked]>; EXT - [email-masked] <
> [email-masked]>; [email-masked]; SPRING WG <
> [email-masked]>; 6man <[email-masked]>; Robert Raszuk <[email-masked]>;
> Rob Shakir <[email-masked]>; Tarek Saad <[email-masked]>
> > Hi Ron, I agree ASICs are always improving, indeed this is evident in
> the number of successful SRv6 deployments and multiple vendor
> implementations at line rate on merchant silicon, and multiple vendor ASICs.
> >
> > You’ve been asked this several times.  Since you’re the only
> implementor(?) and one operator is claiming deployment or testing, I am
> curious.
> >
> > Regardless of ASIC capabilities there are two performance penalties you
> will not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups.
> >
> > Requiring all segments in a CRH segment list to process an arbitrary
> length DOH+set of PSSI’s and other options is always very expensive.
> > Spreading PSSI, CRH, PPSI operations in multiple headers and multiple
> identifiers you now have multiple lookups at a node.
> > While ASICs are more capable and will continue to be more capable, these
> technical performance problems you introduce with PSSI+CRH+PPSI will not go
> away.
> >
> > Darren
> >
> >
> >

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 18 Sep 2019 19:56:11 -0400

Daren

This is from 2019 CISCO Live presentation 

https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKMPL-2132.pdf

IETF Standardization
• The work started by Cisco in 2014
• Significant industry collaboration
• There are over SRv6 50 IETF documents
• The work spans over 13 working groups
• SRv6 header has been last called
• Network Programming is a Working Group document • Multivendor Consensus
 #CLUS © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
  
Cisco Deployments
• Softbank
• Cisco Supports SoftBank on First SRv6 Deployment in Prep for 5G • Nationwide SRv6 network carrying live traffic
• Iliad
• Nationwide SRv6 network to provide a new mobile offering in Italy • The SRv6 backbone is based on Cisco ASR 9000 and NCS 5500 • All the cell site routers are SRv6 capable Iliad's NodeBox
• China Telecom
• Multi-city SRv6 network

Gyan

Sent from my iPhone

> On Sep 18, 2019, at 9:41 AM, Darren Dukes (ddukes) <[email-masked]> wrote:
> 
> Hi Ron.  
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 18 Sep 2019 20:01:40 -0400

This CISCO LIVE dives deeper into Cisco’s SRv6 implementation.

https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKSPG-3001.pdf

They go through all the SRV6 programmability End SID and SR insertion.

I have to read through to see if Cisco’s Ti-LFA implementation requires so many EH’s

Gyan

Sent from my iPhone

> On Sep 18, 2019, at 7:56 PM, Gyan Mishra <[email-masked]> wrote:
> 
> Daren
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Sep 2019 10:32:54 +1000

+1

The Internet scales because complexity is pushed towards the edges.

>> > "Regardless of ASIC capabilities there are two performance penalties
>> you will not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups.”
>> >
>> > In your email, you say that I have been asked several times to report
>> on the state of Juniper’s SRv6+ implementation. While I cannot provide
>> > While ASICs are more capable and will continue to be more capable,
>> these technical performance problems you introduce with PSSI+CRH+PPSI will
>> not go away.
>> >
>> > Darren
>> >
>> >
>> >
>> > On Sep 12, 2019, at 12:34 PM, Ron Bonica <rbonica=
>> [email-masked]..org <[email-masked]>> wrote:
>> >
>> >

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Sep 2019 10:44:16 +1000

None of that means there isn't room for improvement, or that lessons that
can be learned and applied a second time around (just need to watch out for
second system syndrome). The first version isn't always if ever the best
version.

On Thu, 19 Sep 2019, 09:57 Gyan Mishra, <[email-masked]> wrote:

> • Cisco Supports SoftBank on First SRv6 Deployment in Prep for 5G •
> Nationwide SRv6 network carrying live traffic
> • Iliad
> • Nationwide SRv6 network to provide a new mobile offering in Italy • The
> SRv6 backbone is based on Cisco ASR 9000 and NCS 5500 • All the cell site
> routers are SRv6 capable Iliad's NodeBox
> • China Telecom
> You then say "So long as the ASIC can process enough packets per second to
> saturate the line cards, we are forwarding at full line rate."
>
> Yes this is true, but we can conclude: *The complexity of "SRv6+"
> requires ASICs do much more work per packet vs SRv6.*
>
> Thanks
>   Darren
>
>
>    - SRv6 requires only two FIB searches
>    - SRv6+ requires 4 or more FIB searches
>    - Therefore, SRv6+ cannot possibly forward at line speed
>
>
>    - The packet contains two instances of the DOH. (Most use-cases
>    require only one.)
>    - The processing node is configured to process the PSSI. (Many
>    ASIC-based devices, because of their role in the network, won’t support any
>    per segment service instructions. This nodes will be configured to ignore
>    the PSSI. That is why it is optional.)
>
>
>    - SRv6 requires only two FIB searches
>    - SRv6+ requires three and sometimes four FIB searches
>    - Therefore, SRv6+ cannot possibly forward at line speed
>
>
>    - A route lookup ASIC, that can process some number of packets per
>    second
>    - Some number of interfaces, that can forward some number of bits per
>    second
>
>
> So long as the ASIC can process enough packets per second to saturate the
> line cards, we are forwarding at full line rate. So long as a platform has
> a sufficiently capable ASIC, it will be able to forward at line speed. But
> it’s a matter of how the platform is designed. If the ASIC is not
> *From:* Darren Dukes (ddukes) <[email-masked]>
> *Sent:* Monday, September 16, 2019 4:38 PM
> *Cc:* Mark Smith <[email-masked]>; EXT - [email-masked] <
> *Subject:* “SRV6+” complexity in forwarding
>
> Hi Ron, I agree ASICs are always improving, indeed this is evident in the
> number of successful SRv6 deployments and multiple vendor implementations
> at line rate on merchant silicon, and multiple vendor ASICs.
>
> On Sep 12, 2019, at 12:34 PM, Ron Bonica <
> rbonica=[email-masked]> wrote:
>
>

---

From: Gaurav Dawra <[email-masked]>
Date: Wed, 18 Sep 2019 17:44:54 -0700

+1 
Agree.

Sent from my iPhone

> On Sep 18, 2019, at 5:32 PM, Mark Smith <[email-masked]> wrote:
> 
> 
> 
>> SRv6 does not require TLV processing for normal forwarding (use case: SP core).
> 
> 
> +1
> 
>>> > On Sep 12, 2019, at 12:34 PM, Ron Bonica <rbonica=[email-masked]..org> wrote:
>>> >
>>> >

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Sep 2019 18:15:52 -0700

Mark,

I agree, but that begs the question as to why SRV6 contains its own
TLVs and authentication as opposed to using edge mechanisms like
destination options after the routing header or AH. The obvious intent
of putting TLVs in the routing header is that some intermediate
destinations will process them. So then these "some" intermediate
nodes will sustain the performance hit of TLV processing. If this is
so bad as expected that TLVs are relegated to the slow path, then
nobody turns them on because of the performance hit and the mechanism
likely becomes yet another extensibility mechanism with the same
demise as IPv4 options. History shows again and again that
extensibility mechanisms are "use it or lose it". Requiring an
extensibility mechanism is a good force function and motivation for
implementers to make the mechanism work and be feasible.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Thu, 19 Sep 2019 02:03:18 +0000

If you want to push complexity to the edge, put it in a destination option that is processed at the edge.

Ron
Sent from my phone

On Sep 18, 2019, at 8:33 PM, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, 19 Sep 2019, 09:40 Dirk Steinberg, <[email-masked]<mailto:[email-masked]>> wrote:
SRv6 does not require TLV processing for normal forwarding (use case: SP core).

+1

- Dirk

On Wed, Sep 18, 2019 at 5:57 PM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

Darren,

Tom

> On Sep 12, 2019, at 12:34 PM, Ron Bonica <rbonica=[email-masked]..org<mailto:[email-masked]>> wrote:
>
>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!X-RHqCoZCZWTzB70xws4pVNGLoV7EPYG3-F9MWDANjuba3eZop9nlFRTfNamKFBw$>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!X-RHqCoZCZWTzB70xws4pVNGLoV7EPYG3-F9MWDANjuba3eZop9nlFRTfPui4KSq$>
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!X-RHqCoZCZWTzB70xws4pVNGLoV7EPYG3-F9MWDANjuba3eZop9nlFRTfPui4KSq$>

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Sep 2019 14:05:15 +1000

> If you want to push complexity to the edge, put it in a destination option that is processed at the edge.

Yes!

It might seem like "forwarding" is taking a packet in on one
interface, doing something to it, and then sending it out another.

RFC 8200's / IPv6's definition for forwarding or "routing" is much more strict:

" router       a node that forwards IPv6 packets not explicitly
                addressed to itself.  (See Note below.)

   host         any node that is not a router.  (See Note below.)

   node         a device that implements IPv6."

(Note at end for completeness; it doesn't contradict these definitions)

So when a packet reaches a device, which could be "in the network",
where the device has the address that matches the DA in the packet,
the packet is being host processed.

The processing to occur at that device with the packet's DA is
determined by a Destination Option and/or the upper transport layer
protocol headers in the packet's payload.

These RFC 8200 definitions are functional. That means that the device
we all probably imagine if we think of the term "router" is actually
performing both the above router function (forwarding plane) and the
host function (control plane).

ASICs could also perform some of these these host functions when the
packet arrives at the device with the packet's DA to get higher
performance than a general purpose CPU could provide.

Regards,
Mark.

"   Note: it is possible for a device with multiple interfaces to be
   configured to forward non-self-destined packets arriving from some
   set (fewer than all) of its interfaces and to discard non-self-
   destined packets arriving from its other interfaces.  Such a device
   must obey the protocol requirements for routers when receiving
   packets from, and interacting with neighbors over, the former
   (forwarding) interfaces.  It must obey the protocol requirements for
   hosts when receiving packets from, and interacting with neighbors
   over, the latter (non-forwarding) interfaces.")

> Ron
> Sent from my phone
>
>
> On Sep 18, 2019, at 8:33 PM, Mark Smith <[email-masked]> wrote:
>
>
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Sep 2019 14:50:32 +1000

On Thu, 19 Sep 2019 at 11:16, Tom Herbert <[email-masked]> wrote:
> destination options after the routing header or AH.

Yes, agree entirely.

I think it might be a mindset thing.

If hosts and routers are imagined as devices, then it might seem
necessary to invent new mechanisms to perform e.g. authentication when
a packet crosses a router.

Once your mindset changes to hosts and routers being functions, and
you use the RFC 8200 definitions of those terms, it then becomes much
clearer that host mechanisms like AH and Dest Options can be used "in
the network", because a router as a device is performing both RFC 8200
routing and host functions.

It's a bit of mental hurdle to cross, however X-in-IPv6 tunnel
end-points are hosts, because they originate new packets (the outer
header), they're the ultimate destination of those packets, and the SA
and DA in the outer packet header are those of the devices at the ends
of the tunnel.

Once a tunnel end-point is viewed as a host, then all of the host
options become available to use e.g. AH/ESP EHs, Destination Options,
UDP/TCP etc.

> The obvious intent

I think the thing that has happened in fairly recent times is that the
"slow path" has become much faster, and by the sounds of it can be
made faster using ASICs for specific processing. So it's now possible
to "slow path" process packets at a fast enough rate and in enough of
a volume that it becomes feasible to do so.

I guess that HbH processing wasn't supported or enabled in the past
for a few reasons - customers didn't ask vendors to provide it,
because customers didn't have a use for it, and there was the
potential for a DoS on a control plane as past control planes were
fairly resource limited.

Regards,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Thu, 19 Sep 2019 11:56:37 +0300

> On Sep 18, 2019, at 4:41 PM, Darren Dukes (ddukes) <[email-masked]> wrote:
> 
> The complexity of "SRv6+" requires ASICs do much more work per packet vs SRv6.

Duh. More processing is more processing, whether done in hardware, software, or firmware. I'm not a fan of segment routing for several reasons, but this fact isn't inherently one of them.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 19 Sep 2019 11:34:10 +0200

Hi Ron,

If you want to push complexity to the edge, put it in a destination option
> that is processed at the edge.
>
> Ron
>

Just curious what is your definition of the "edge" ? If destination address
matches local address that is the "edge" for the packet. So each TE
midpoint is the "edge".

The only difference I observed is if you put something before or after RH
is how to handle it when that something is unknown to the node. Here as
each router can be an edge this unknown is not likely to occur.

There is no difference in how IPv6 processing of those DOH will attempt to
take place.

That is also why IMHO split of PSSI from PPSI is a bit wired as the only
reason for it seems to be to avoid dropping packets at mid points if PPSI
is unknown to it.

Thx,
R.

---

From: Srihari Sangli <[email-masked]>
Date: Thu, 19 Sep 2019 11:13:39 +0000

Robert,

That is also why IMHO split of PSSI from PPSI is a bit wired as the only reason for it seems to be to avoid dropping packets at mid points if PPSI is unknown to it.

I disagree. PPSI and PSSI leverages the DOHs in IPv6 architecture better. The SRv6+ drafts explain the usecases better FYI.

srihari…

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 19 Sep 2019 17:30:11 +0200

> I disagree. PPSI and PSSI leverages the DOHs in IPv6 architecture better.
> The SRv6+ drafts explain the usecases better FYI.
>

Well the crux of the matter is that you still need to process all EHs at
each IPv6 destination which here means each transit node per RFC8200. That
is regardless what any other spec says ... unfortunately.

Best,
R.

---

From: Reji Thomas <[email-masked]>
Date: Thu, 19 Sep 2019 21:46:59 +0530

Hi Robert,

>>Well the crux of the matter is that you still need to process all EHs at each IPv6 destination which here means each transit node per RFC8200

 From RFC 8200 that doesn't seem to be the case or at least as I
understand. See  Section 4.1 note 1 and note 3. Am I missing
something?

IPv6 header
      Hop-by-Hop Options header
      Destination Options header (note 1)
      Routing header
      Fragment header
      Authentication header (note 2)
      Encapsulating Security Payload header (note 2)
      Destination Options header (note 3)
      Upper-Layer header

      note 1: for options to be processed by the first destination that
              appears in the IPv6 Destination Address field plus
              subsequent destinations listed in the Routing header.

      note 2: additional recommendations regarding the relative order of
              the Authentication and Encapsulating Security Payload
              headers are given in [RFC4303
<https://tools.ietf.org/html/rfc4303>].

      note 3: for options to be processed only by the final destination
              of the packet.

Regards
Reji

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 19 Sep 2019 18:56:24 +0200

IPv6 fixed header has only one destination address. So TE midpoint is
either a packet's destination or not. It can not be both.

I do not know what is the difference between IPv6 Destination Address in
the fixed header and "final destination". Where do you carry "final
destination" address ?

Many  thx,
R.

On Thu, Sep 19, 2019 at 6:17 PM Reji Thomas <[email-masked]> wrote:

>  From RFC 8200 that doesn't seem to be the case or at least as I understand. See  Section 4.1 note 1 and note 3. Am I missing something?
>
>
>
> IPv6 header
>               headers are given in [RFC4303 <https://tools.ietf.org/html/rfc4303>].
>

---

From: Reji Thomas <[email-masked]>
Date: Fri, 20 Sep 2019 00:44:35 +0530

Hi Robert,

See Section 4.4 in RFC 8200.  Hope its clear what's the final destination
and the context in which it is used.

      Segments Left       8-bit unsigned integer.  Number of route
                          segments remaining, i.e., number of explicitly
                          listed intermediate nodes still to be visited
                          before reaching the final destination.

Regards

Reji

On Thu, Sep 19, 2019 at 10:26 PM Robert Raszuk <[email-masked]> wrote:

>>> I disagree. PPSI and PSSI leverages the DOHs in IPv6 architecture
>>>> better. The SRv6+ drafts explain the usecases better FYI.
>>>>
>>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 19 Sep 2019 21:50:08 +0200

Hi Reji,

Notice what it says: *" ... explicitly listed intermediate nodes ... "*

CRH which is used in SRv6+ does not explicitly list intermediate nodes so I
do not think the procedures in IPv6 spec apply as the way you interpret
them.

But I am i no way authoritative ... still learning IPv6 and this thread
become great education.

An real example where those procedure apply is documented in RFC6554 which
does put the addresses explicitly.

Many thx,
Robert.

On Thu, Sep 19, 2019 at 9:14 PM Reji Thomas <[email-masked]> wrote:

>>>> Well the crux of the matter is that you still need to process all EHs
>>>> at each IPv6 destination which here means each transit node per RFC8200.
>>>> That is regardless what any other spec says ... unfortunately.
>>>>
>>>> Best,
>>>> R.
>>>>
>>>>
>>>>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 19 Sep 2019 21:06:45 -0400

Hi Robert 

I know we have gone through many many lengthy discussions adnosium and I know the question has come up a few times and I know you replied back a few times related to the service provider use case where we end up with the multiple violations of RFC 8200 related to intermediate nodes EH insertion as well as many EH insertions occurring and what was mentioned was Ti-LFA.  So since LFA and Remote LFA are extensions of the IGP providing the 50ms failover similar to traditional mpls Fast Reroute capabilities NH & NNH link/node/path protection in the legacy TE FRR pce the head end PE LSR adds and additional mpls shim for FRR.

With IP LFA and remote LFA used with LDP there are IGP extensions opaque LSA’s that provide the pre programmed backup path provided by LFA loop free backup path.  In that scenario with LDP there is not any additional label with LFA but with remote LFA is added for the Remote LFA backup path with LDP session protection enabled with targeted LDP session tunnled through the RLFA node.

So now talking SRv6 with Ti LFA why is there an EH insertion as we are not using mpls LDP and not doing remote LFA and this is not the traditional mpls TE FRR.

I am not getting it from a network engineering technical standpoint what the use case is and why EH insertion would occur on any intermediate node as that even in the legacy mpls TE world its on the ingress LSR PE and for that matter in this case the benefit of SRv6 is “native TE” source routing via SRH pssi instructions and not maintaining state on the intermediate nodes which just do the PSSI and copy the SRH destination rewrite of IPv6 destination for the traffic engineered path and then do PSP or USP on the egress node of the service provider core.

I designed and manage a fairly large mpls core for Verizon and if their is a asic processing penalty hit due to intermediate node EH insertion we don’t want it and will stay course with LDP and stick with our path targeting SR-MPLS and ditch any ideas of ever going to SRv6.

Thanks in advance for help in clarification of this topic and I think understanding the use case would help 6man overall understand the justification of the RFC 8200 violations.

Thank you

Gyan Mishra
Verizon Communications 
Cell 301 502-1347

Sent from my iPhone

> On Sep 19, 2019, at 3:50 PM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Reji,
> 
> Notice what it says: " ... explicitly listed intermediate nodes ... "
> 
> CRH which is used in SRv6+ does not explicitly list intermediate nodes so I do not think the procedures in IPv6 spec apply as the way you interpret them. 
> 
> But I am i no way authoritative ... still learning IPv6 and this thread become great education. 
> 
> An real example where those procedure apply is documented in RFC6554 which does put the addresses explicitly. 
> 
> Many thx,
> Robert.
> 
> 
> 
> 
> 
> 
> 
> 
>> >>I do not know what is the difference between IPv6 Destination Address in the fixed header and "final destination". Where do you carry "final destination" address ? 
>> 
>> See Section 4.4 in RFC 8200.  Hope its clear what's the final destination and the context in which it is used.
>> 
>>> IPv6 fixed header has only one destination address. So TE midpoint is either a packet's destination or not. It can not be both. 
>>> 
>>> I do not know what is the difference between IPv6 Destination Address in the fixed header and "final destination". Where do you carry "final destination" address ? 
>>> 
>>> Many  thx,
>>> R.
>>> 
>>>>               headers are given in [RFC4303].
>>>> 
>>>>> Well the crux of the matter is that you still need to process all EHs at each IPv6 destination which here means each transit node per RFC8200. That is regardless what any other spec says .... unfortunately. 
>>>>> 
>>>>> Best,
>>>>> R.
>>>>> 
>>>>> 
>>>>>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 20 Sep 2019 02:23:40 +0000

Regarding RFC6554, I think it is a good example for us to discuss compression.

C-SID follows the similar thought of RFC6554, which reduces the same part of SRv6 SID while only carries the different part.

This mechanism does not introduce new type of SID function, but only enhances the encoding efficiency of SRH. https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00

Welcome to review our document, and we will update it very soon.

Best regards,
Cheng

From: ipv6 [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, September 20, 2019 3:50 AM
To: Reji Thomas <[email-masked]>
Cc: [email-masked]; SPRING WG <[email-masked]>; 6man <[email-masked]>; Dirk Steinberg <[email-masked]>; Rob Shakir <[email-masked]>; Tarek Saad <[email-masked]>; Srihari Sangli <ssangli=[email-masked]>
Subject: Re: [spring] “SRV6+” complexity in forwarding

Hi Reji,

Many thx,
Robert.

On Thu, Sep 19, 2019 at 9:14 PM Reji Thomas <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Regards

Reji

On Thu, Sep 19, 2019 at 10:26 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
IPv6 fixed header has only one destination address. So TE midpoint is either a packet's destination or not. It can not be both.

Many  thx,
R.

On Thu, Sep 19, 2019 at 6:17 PM Reji Thomas <[email-masked]<mailto:[email-masked]>> wrote:

Hi Robert,

IPv6 header

      Routing header

      Fragment header

      Upper-Layer header

              headers are given in [RFC4303<https://tools.ietf.org/html/rfc4303>].

              of the packet.

Regards
Reji

On Thu, Sep 19, 2019 at 9:00 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Best,
R.

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 19 Sep 2019 19:43:52 -0700

Gyan,

IPFRR doesn’t use/need any IGP extensions and is local to the device computing LFA.
As RTGWG chair - I welcome you to read a number of rather well written RFCs on the topic we have published in RTGWG over the last 7 years. 
Pay attention on how LFAs are computed, this would clarify your question as to why there’s no need for additional imposition as well as why LFA provides partial coverage.
There’s also TI-LFA draft that explains how TI-LFA is computed and why it relies on additional imposition if LFA is unavailable.

Regards,
Jeff

> On Sep 19, 2019, at 18:06, Gyan Mishra <[email-masked]> wrote:
> 
> Hi Robert 
> 
>>>>>  From RFC 8200 that doesn't seem to be the case or at least as I understand. See  Section 4..1 note 1 and note 3. Am I missing something?
>>>>>  
>>>>> IPv6 header

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Sep 2019 10:44:59 +0200

Hi Gyan,

> So now talking SRv6 with Ti LFA why is there an EH insertion as we are
> not using mpls LDP and not doing remote LFA and this is not the
traditional
> mpls TE FRR.

TI - stands for Topology Independent ... all other LFA modes rely on
topologies to be able to compute or not the backup path.

So why insertion/EH modification is needed ... well as I stated before
there are  few aspects of this and all must be taken into consideration.

A) In most cases of topologies it may not be required - only in some
special cases you may need to engineer your backup flows and then you
either insert new EH or add another IP encap with such SRH in current SRv6
architecture.

B) When you are doing node protection and PLR is adjucent to segment end
node you should fixup such SRH (so modify it on PLR which is not packet
destination) such that the packet will not try to return when LFA routed to
N+1 segment end.

Why A is option B clearly needs to be fixed or LFA style node protection of
any segment end declared as not supported.

Of course in bigger picture there any more protection methods to consider
and only specific operator of transit or enterprise is in position to
decide what works best for him.

Many thx,
R.

On Fri, Sep 20, 2019 at 3:06 AM Gyan Mishra <[email-masked]> wrote:

> Hi Robert
>
> I know we have gone through many many lengthy discussions adnosium and I
> know the question has come up a few times and I know you replied back a few
> times related to the service provider use case where we end up with the
> multiple violations of RFC 8200 related to intermediate nodes EH insertion
> as well as many EH insertions occurring and what was mentioned was Ti-LFA.
> So since LFA and Remote LFA are extensions of the IGP providing the 50ms
> failover similar to traditional mpls Fast Reroute capabilities NH & NNH
> link/node/path protection in the legacy TE FRR pce the head end PE LSR adds
> and additional mpls shim for FRR.
>
> With IP LFA and remote LFA used with LDP there are IGP extensions opaque
> LSA’s that provide the pre programmed backup path provided by LFA loop free
> backup path.  In that scenario with LDP there is not any additional label
> with LFA but with remote LFA is added for the Remote LFA backup path with
> LDP session protection enabled with targeted LDP session tunnled through
> the RLFA node.
>
> So now talking SRv6 with Ti LFA why is there an EH insertion as we are not
> using mpls LDP and not doing remote LFA and this is not the traditional
> mpls TE FRR.
>
> I am not getting it from a network engineering technical standpoint what
> the use case is and why EH insertion would occur on any intermediate node
> as that even in the legacy mpls TE world its on the ingress LSR PE and for
> that matter in this case the benefit of SRv6 is “native TE” source routing
> via SRH pssi instructions and not maintaining state on the intermediate
> nodes which just do the PSSI and copy the SRH destination rewrite of IPv6
> destination for the traffic engineered path and then do PSP or USP on the
> egress node of the service provider core.
>
> I designed and manage a fairly large mpls core for Verizon and if their is
> a asic processing penalty hit due to intermediate node EH insertion we
> don’t want it and will stay course with LDP and stick with our path
> targeting SR-MPLS and ditch any ideas of ever going to SRv6.
>
> Thanks in advance for help in clarification of this topic and I think
> understanding the use case would help 6man overall understand the
> justification of the RFC 8200 violations.
>
> Thank you
>
> Gyan Mishra
> Verizon Communications
> Cell 301 502-1347
>
> Sent from my iPhone
>
> CRH which is used in SRv6+ does not explicitly list intermediate nodes so
> I do not think the procedures in IPv6 spec apply as the way you interpret
> them.
>
>> >>I do not know what is the difference between IPv6 Destination Address
>> in the fixed header and "final destination". Where do you carry "final
>> destination" address ?
>>
>>>>> That is regardless what any other spec says .... unfortunately.
>>>>>
>>>>> Best,
>>>>> R.
>>>>>
>>>>>
>>>>>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 20 Sep 2019 15:16:42 +0100

> topologies to be able to compute or not the backup path.

Well so does TI-LFA.

At some level you have to know the topology to calculate *any* path in 
SR, else how do you know what links and SIDs to use. When you use loose 
source routing that is even more the case.

Moreover since TI-LFA specifies the need to align the repair path with 
the post convergence path you have to know the post convergence path to 
do that, and to do that someone must know the topology.

I think a better description for the technology is that it is not 
constrained by topology, i.e. that you can create the repair path 
regardless of the topology, although the more perverse the topology the 
more SIDs are required.

TI-LFA is only independent of the topology it that it can find a path 
regardless of the topology, not without knowledge of the topology.

- Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Sep 2019 16:18:57 +0200

Hi Stewart,

Yes this is exactly what I was trying to say. Your definition of TI-LFA as
expressed below is spot on:

"I think a better description for the technology is that it is not
constrained by topology, i.e. that you can create the repair path
regardless of the topology, although the more perverse the topology the
more SIDs are required. "

Thx,
R.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 20 Sep 2019 17:08:48 +0000

Likewise, SP core routers would ignore the PSSI and wouldn’t even see the PPSI.

                                                      Ron

From: Dirk Steinberg <[email-masked]>
Sent: Wednesday, September 18, 2019 7:40 PM
To: Tom Herbert <[email-masked]>
Cc: Darren Dukes (ddukes) <[email-masked]>; [email-masked]; SPRING WG <[email-masked]>; 6man <[email-masked]>; Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>; Rob Shakir <[email-masked]>; Tarek Saad <[email-masked]>
Subject: Re: [spring] “SRV6+” complexity in forwarding

- Dirk

Darren,

Tom

> On Sep 12, 2019, at 12:34 PM, Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
>
>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!WrHuFvaysLbs0yJ61FHJgdG3Gs5uwrUZm7LBOvafWNAVhbtJL5grVfoU-RGWVqzi$>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!WrHuFvaysLbs0yJ61FHJgdG3Gs5uwrUZm7LBOvafWNAVhbtJL5grVfoU-Z5e9NFo$>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 20 Sep 2019 13:20:31 -0400

Sent from my iPhone

> On Sep 19, 2019, at 10:43 PM, Jeff Tantsura <[email-masked]> wrote:
> 
> Gyan,
> 

Thanks you Jeff!

I am part of the RTGWG and will definitely read through all the RFCs as well as Ti-LFA draft I detail.

I read through RFC 5286 IP LFA the LFA algorithm uses the underlying IGP to for alternative loop free next hop for link and node protection but since it’s the algorithm runs locally to build the “backup” path pre programmed it does not require IGP extensions.  
IP LFA is similar algorithm to the CISCO proprietary EIGRP topology loopfree feasible successor backup paths.  Am I stating that correctly reason why LFA does not rely on IGP extensions.

RFLA RFC 7490 - so I had a question - always wondered about - so RLFA is used when a LFA path does not exist so a ldp tunnel is built to the PQ node for backup RLFA pre programmed path to get built.  So when that LDP tunnel is build an extra mpls shim is added to the label stack.  Is that correct for RLFA backup paths. Is it just a single shim or multiple to do the RLFA LDP tunneling.

I read through the Ti-LFA draft 

https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-ti-lfa/

So Ti-LFA uses loop free uses a traffic engineered IGP independent topology independent path that is desired with SR-MPLS or with SRv6 uses the EH SRH SID list for the pre programmed backup path.  So an additional EH insertion has to occur on the ingress PE to the SR or SRV6 domain.  I have to read through more carefully but I am not seeing how an intermediate node would require EH insertion since that function is always on the source node head end of the traffic engineered path.

Regards,

Gyan

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Sep 2019 19:21:30 +0200

Hi Ron,

No one is questioning that. If packet's destination is not a local address
of a router all options can be ignored.

Fun however starts when destination address in the packet *is* a local
address on the router ie. the router is acting as Segment Endpoint.

Thx,
R.

> *Sent:* Wednesday, September 18, 2019 7:40 PM
> *To:* Tom Herbert <[email-masked]>
> *Cc:* Darren Dukes (ddukes) <[email-masked]>; [email-masked];
> SPRING WG <[email-masked]>; 6man <[email-masked]>; Robert Raszuk <
> [email-masked]>; Ron Bonica <[email-masked]>; Rob Shakir <
> [email-masked]>; Tarek Saad <[email-masked]>
> *Subject:* Re: [spring] “SRV6+” complexity in forwarding
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 20 Sep 2019 17:33:02 +0000

Robert,

Even then, the core SP router may ignore the PSSI.

Recall that the first two bits of the PSSI option are 00. This means that if the processing node doesn’t recognize the PSSI, or is configured to ignore the PSSI, it will simple skip over the PSSI.

In most cases, core SP routers will be configured to ignore the PSSI.

                                                                             Ron

From: Robert Raszuk <[email-masked]>
Sent: Friday, September 20, 2019 1:22 PM
To: Ron Bonica <[email-masked]>
Cc: Dirk Steinberg <[email-masked]>; Tom Herbert <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; [email-masked]; SPRING WG <[email-masked]>; 6man <[email-masked]>; Rob Shakir <[email-masked]>; Tarek Saad <[email-masked]>
Subject: Re: [spring] “SRV6+” complexity in forwarding

Hi Ron,

No one is questioning that. If packet's destination is not a local address of a router all options can be ignored.

Fun however starts when destination address in the packet *is* a local address on the router ie. the router is acting as Segment Endpoint.

Thx,
R.

On Fri, Sep 20, 2019 at 7:09 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Likewise, SP core routers would ignore the PSSI and wouldn’t even see the PPSI.

                                                      Ron

From: Dirk Steinberg <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 18, 2019 7:40 PM
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; SPRING WG <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Rob Shakir <[email-masked]<mailto:[email-masked]>>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] “SRV6+” complexity in forwarding

- Dirk

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 20 Sep 2019 11:30:28 -0700

Hi Gyan,

Always a pleasure!
See inline, please  let me know if you have got any other questions.

Cheers,
Jeff
> IP LFA is similar algorithm to the CISCO proprietary EIGRP topology loopfree feasible successor backup paths.  Am I stating that correctly reason why LFA does not rely on IGP extensions.
[jeff] IP LFA relies on the fact that in LS routing protocols, all routers in area/level share same LSDB, hence LFA's can be computed, DUAL (EIGRP) has some similarities, you could further read RFC7868 (Feasibility Condition)
>
> RFLA RFC 7490 - so I had a question - always wondered about - so RLFA is used when a LFA path does not exist so a ldp tunnel is built to the PQ node for backup RLFA pre programmed path to get built.
[jeff] it is a local policy matter, in the implementation I worked on, this was the default behavior.

>   So when that LDP tunnel is build an extra mpls shim is added to the label stack.  Is that correct for RLFA backup paths. Is it just a single shim or multiple to do the RLFA LDP tunneling.
[jeff] this is a single MPLS(transport) label
> I read through the Ti-LFA draft
[jeff] we have adopted the draft as wg document, it has been updated, please read draft-ietf-rtgwg-segment-routing-ti-lfa-01
> So Ti-LFA uses loop free uses a traffic engineered IGP independent topology independent path that is desired with SR-MPLS or with SRv6 uses the EH SRH SID list for the pre programmed backup path.  So an additional EH insertion has to occur on the ingress PE to the SR or SRV6 domain.
[jeff] No, the insertion is happening at the PLR (point of local repair) and is local to the PLR, if a backup path is instantiated at head-end/ingress PE, we are talking about “path protection”, e.g. - when head-end desired to switch over to a backup path it does so without help of any intermediate nodes.
>  I have to read through more carefully but I am not seeing how an intermediate node would require EH insertion since that function is always on the source node head end of the traffic engineered path.
[jeff] see my previous comment, it is indeed the intermediate node (PLR) that computes LFA and if PQ node is not available thru shortest path (think ring topology) it has to impose additional piece of data-plane information (MPLS labels/EHs) that would be used by intermediated nodes to get to the PQ node.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 20 Sep 2019 15:58:11 -0400

> [Gyan]  Thanks Jeff for the detailed responses!
>

   I am with Verizon Communications and SME of Verizon's Network
Engineering & Technology org and head up their Planning, Engineering &
Design & Proof of concept lab so represent Verizon at the IETF from an
"operators" perspective for real world use cases as well as industry needs
standpoint and so to be on top of new and upcoming technologies  have been
part of the IETF Working Groups below related to Routing & Internet of
which as we can see on this thread has  a lot of overlap between many
working groups.

6MAN (IPv6 Maintenance) WG

MPLS (Multi Protocol Label Switching) WG

LSR (Link State Routing) WG

RTG-BFD (Routing Group - Bi Directional Forwarding) WG

SPRING  (Source Packet Routing in Network) WG

NFVCON (Network Function Virtualization) WG

PALS (Pseudowire And LDP-enabled Services) WG

RTGWG (Routing Area Working Group) WG

TEAs (Traffic Engineering Architecture and Signaling) WG

QUIC (QUIC UDP Internet Connections) WG

PIM (Protocol Independent Multicasting) WG

BESS (BGP Enabled Services) WG

[comments in-line]

Cheers,

Gyan

> As RTGWG chair - I welcome you to read a number of rather well written
> RFCs on the topic we have published in RTGWG over the last 7 years.
> Pay attention on how LFAs are computed, this would clarify your question
> as to why there’s no need for additional imposition as well as why LFA
> provides partial coverage.
> There’s also TI-LFA draft that explains how TI-LFA is computed and why it
> relies on additional imposition if LFA is unavailable.
>
> Regards,
> Jeff
>
>
> Thanks you Jeff!
>
> I read through RFC 5286 IP LFA the LFA algorithm uses the underlying IGP
> to for alternative loop free next hop for link and node protection but
> since it’s the algorithm runs locally to build the “backup” path pre
> programmed it does not require IGP extensions.
> IP LFA is similar algorithm to the CISCO proprietary EIGRP topology
> loopfree feasible successor backup paths.  Am I stating that correctly
> reason why LFA does not rely on IGP extensions.
>
> [jeff] IP LFA relies on the fact that in LS routing protocols, all routers
> in area/level share same LSDB, hence LFA's can be computed, DUAL (EIGRP)
> has some similarities, you could further read RFC7868 (Feasibility
> Condition)
>
>
> RFLA RFC 7490 - so I had a question - always wondered about - so RLFA is
> used when a LFA path does not exist so a ldp tunnel is built to the PQ node
> for backup RLFA pre programmed path to get built.
>
>   So when that LDP tunnel is build an extra mpls shim is added to the
> label stack.  Is that correct for RLFA backup paths. Is it just a single
> shim or multiple to do the RLFA LDP tunneling.
>
> [jeff] we have adopted the draft as wg document, it has been updated,
> please read draft-ietf-rtgwg-segment-routing-ti-lfa-01
>
>
>
> So Ti-LFA uses loop free uses a traffic engineered IGP independent
> topology independent path that is desired with SR-MPLS or with SRv6 uses
> the EH SRH SID list for the pre programmed backup path.  So an additional
> EH insertion has to occur on the ingress PE to the SR or SRV6 domain.
>
> [jeff] No, the insertion is happening at the PLR (point of local repair)
> and is local to the PLR, if a backup path is instantiated at
> head-end/ingress PE, we are talking about “path protection”, e.g. - when
> head-end desired to switch over to a backup path it does so without help of
> any intermediate nodes.
>
>  I have to read through more carefully but I am not seeing how an
> intermediate node would require EH insertion since that function is always
> on the source node head end of the traffic engineered path.
>
> [jeff] see my previous comment, it is indeed the intermediate node (PLR)
> that computes LFA and if PQ node is not available thru shortest path (think
> ring topology) it has to impose additional piece of data-plane information
> (MPLS labels/EHs) that would be used by intermediated nodes to get to the
> PQ node.
>
> [Gyan]  So that makes sense now why the intermediate node EH insertion is
> required at the (PLR) intermediate node that computes LFA and if LFA is not
> available through the IGP SPF local topology database a single EH SRH
> header needs be inserted  at the PLR node for the PSSI segment SR source
> route list to source route traffic engineer along the protected path to the
> egress PQ node.
>
>         In some of the discussion I heard rumblings about TLVs processing
on the intermediate node and performance hit with EH insertion & TLV
processing hit impacting asic line rate performance. How do we get around
that issue with intermediate node EH insertion impacting performance for
Ti-LFA.

Also is Ti-LFA the only use case that requires EH insertion?

-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 21 Sep 2019 20:17:33 -0400

Robert

Responses in-line

Sent from my iPhone

> On Sep 20, 2019, at 4:44 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Gyan,
> 
> > not using mpls LDP and not doing remote LFA and this is not the traditional 
> > mpls TE FRR. 
> 
> TI - stands for Topology Independent ... all other LFA modes rely on topologies to be able to compute or not the backup path. 

[Gyan] A few others mentioned this as well the concept of Ti= topology independent feature which seems like a sales pitch buzz word as you always have an underlying IGP so that Ti-LFA “post convergence loop free” using a traffic engineered path bypassing the normal IGP path and LFA alternative next hop backup path next best lowest cost where Ti-LFA is really referring to not necessarily a path that is different from the alternate next hop as it could be any other traffic engineered path which includes the alternative next hop which is the LFA path so then you cannot say then that it’s topology independent.  I think how it should be marketed is as since SRV6 and SR-MPLS have the inherent source route capability without having to maintain state in the intermediate nodes it really is a “traffic engineered” TE-LFA is a more accurate marketing buzz word of the LFA used by SR & SRv6.  One of the major benefits of SRv6 inherent traffic engineering capabilities is the ability to color traffic engineering each L3 vpn flow natively onto different paths which cannot be easily done with traditional mpls and is a major use case for both enterprises and SPs to move towards SRv6.
> 
> So why insertion/EH modification is needed ... well as I stated before there are  few assets of this and all must be taken into consideration. 
> 
> A) In most cases of topologies it may not be required - only in some special cases you may need to engineer your backup flows and then you either insert new EH or add another IP encap with such SRH in current SRv6 architecture. 
> 
> B) When you are doing node protection and PLR is adjucent to segment end node you should fixup such SRH (so modify it on PLR which is not packet destination) such that the packet will not try to return when LFA routed to N+1 segment end. 
> 
> Why A is option B clearly needs to be fixed or LFA style node protection of any segment end declared as not supported. 
> 
> Of course in bigger picture there any more protection methods to consider and only specific operator of transit or enterprise is in position to decide what works best for him.
> 
[Gyan] As an operator with Verizon a Tier 1 SP as well as having a very large internal enterprise SP core - traffic engineering is critical component of our network design and fast reroute path protection alternative next hop capabilities provided by IP LFA and Remote LFA with LDP tunneling from PLR to PQ node is critical to have that line rate optimal throughout hitless make before break pre programmed  backup path is a MUST and is really the main business driver justification for any SP or Enterprise to migrate to SRv6 is for that inherent SRv6 traffic engineering 50ms failover to the pre programmed Ti-LFA backup path.  Sorry for the long run on sentence 😀

I think we should change the confusing inaccurate name of Ti-LFA to TE-LFA.

We definitely need to get this figured out and a solution for intermediate node EH insertion at the PLR node use case for Ti-LFA.

Daren 

You mentioned in one of your threads on this topic that there is some miscommunication or something missing in the spec and that you are working on rectifying with an update.  Can you explain how we can fix the issue with intermediate node EH insertion for Ti-LFA use case even though not used in every implementation even though IP LFA is much more widely used then traditional TE FRR where Ti-LFA is providing both capabilities in one feature Ti-LFA with SRv6 so we definitely have to get this figured out with the RFC 8200 violation from a 6MAN perspective.

Regards,

Gyan