Re: [spring] Beyond SRv6.

[Mark Smith <[e-mail]>]

On Mon., 2 Sep. 2019, 07:30 Andrew Alston, <[e-mail]>
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 <[e-mail]>
> *Date: *Sunday, 1 September 2019 at 22:28
> *To: *Andrew Alston <[e-mail]>
> *Cc: *Ron Bonica <rbonica=[e-mail]>, Rob Shakir <
> [e-mail]>, SPRING WG List <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *Re: [spring] Beyond SRv6.
>
>
>
> 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 <
> [e-mail]> 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 <[e-mail]> on behalf of Ron Bonica <rbonica=
> [e-mail]>
> *Date: *Sunday, 1 September 2019 at 21:00
> *To: *Robert Raszuk <[e-mail]>
> *Cc: *Rob Shakir <[e-mail]>, SPRING WG List <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *Subject: *Re: [spring] Beyond SRv6.
>
>
>
> 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 <[e-mail]>
> *Sent:* Sunday, September 1, 2019 11:03 AM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* Rob Shakir <[e-mail]>; SPRING WG List <[e-mail]>;
> [e-mail]
> *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=
> [e-mail]> 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 <[e-mail]> *On Behalf Of *Rob Shakir
> *Sent:* Sunday, August 4, 2019 5:04 PM
> *To:* SPRING WG List <[e-mail]>
> *Subject:* [spring] Beyond SRv6.
>
>
>
> Hi SPRING WG,
>
>
>
> Over the last 5+ years, the IETF has developed Source Packet Routing in
> NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and
> IPv6 (SRv6) data planes. SR-MPLS may also be transported over IP in UDP or
> GRE.
>
>
>
> These encapsulations are past WG last call (in IESG or RFC Editor).
>
>
>
> During the SPRING WG meeting at IETF 105, two presentations were related
> to the reduction of the size of the SID for IPv6 dataplane:
>
>    - SRv6+ / CRH --
>    https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04
>    <https://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 [e-mail] and
> ADs via [e-mail].
>
>
>
> Thank you,
>
> -- Rob & Bruno
>
>
>
> (*) As expressed on the mailing list, a 128 bit SID can encode two
> instructions a node SID and an adjacency SID hence less SID may be required.
>
>
>
>
>
> Juniper Business Use Only
>
> _______________________________________________
> spring mailing list
> [e-mail]
> 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=>
>
>
>
> Juniper Business Use Only
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>