Completely agree with Ron.
SRv6+ is much more simpler , minimum config required and easy to implement..
Regards
Parag
Juniper Business Use Only
From: spring <spring-boun...@ietf.org> On Behalf Of Ron Bonica
Sent: Sunday, September 1, 2019 2:04 AM
To: Rob Shakir <robjs=40google....@dmarc.ietf.org>; SPRING WG List
<spring@ietf.org>; 6...@ietf.org
Subject: Re: [spring] Beyond SRv6.
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 <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On
Behalf Of Rob Shakir
Sent: Sunday, August 4, 2019 5:04 PM
To: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>
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
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> and ADs via
spring-...@ietf.org<mailto:spring-...@ietf.org>.
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
