On Mon., 2 Sep. 2019, 07:30 Andrew Alston, <andrew.als...@liquidtelecom.com> 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 <rob...@raszuk.net> > *Date: *Sunday, 1 September 2019 at 22:28 > *To: *Andrew Alston <andrew.als...@liquidtelecom.com> > *Cc: *Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>, Rob Shakir < > ro...@google.com>, SPRING WG List <spring@ietf.org>, "6...@ietf.org" < > 6...@ietf.org> > *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 < > andrew.als...@liquidtelecom.com> 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 <spring-boun...@ietf.org> on behalf of Ron Bonica <rbonica= > 40juniper....@dmarc.ietf.org> > *Date: *Sunday, 1 September 2019 at 21:00 > *To: *Robert Raszuk <rob...@raszuk.net> > *Cc: *Rob Shakir <ro...@google.com>, SPRING WG List <spring@ietf.org>, " > 6...@ietf.org" <6...@ietf.org> > *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 <rob...@raszuk.net> > *Sent:* Sunday, September 1, 2019 11:03 AM > *To:* Ron Bonica <rbon...@juniper.net> > *Cc:* Rob Shakir <ro...@google.com>; SPRING WG List <spring@ietf.org>; > 6...@ietf.org > *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= > 40juniper....@dmarc.ietf.org> 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 <spring-boun...@ietf.org> *On Behalf Of *Rob Shakir > *Sent:* Sunday, August 4, 2019 5:04 PM > *To:* SPRING WG List <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 and > ADs via 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 > <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 > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
