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 <rob...@raszuk.net>
Sent: Tuesday, September 3, 2019 11:00 AM
To: Ron Bonica <rbon...@juniper.net>
Cc: Shraddha Hegde <shrad...@juniper.net>; Rob Shakir <ro...@google.com>;
SPRING WG List <spring@ietf.org>; 6...@ietf.org
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
<rbon...@juniper.net<mailto:rbon...@juniper.net>> 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.
Could we explore that option together? If you generate some bullet points, I
can craft some text.
Ron
From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Sent: Tuesday, September 3, 2019 8:13 AM
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Cc: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>; Rob Shakir
<ro...@google.com<mailto:ro...@google.com>>; SPRING WG List
<spring@ietf.org<mailto:spring@ietf.org>>; 6...@ietf.org<mailto:6...@ietf.org>
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.
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=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>>
wrote:
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
Juniper Business Use Only
Juniper Business Use Only
From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On
Behalf Of Ron Bonica
Sent: Monday, September 2, 2019 6:53 PM
To: Rob Shakir
<robjs=40google....@dmarc.ietf.org<mailto:40google....@dmarc.ietf..org>>;
SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>;
6...@ietf.org<mailto:6...@ietf.org>
Subject: Re: [spring] Beyond SRv6.
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 <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<mailto:spring@ietf.org>
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=>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
