Greg, On Nov 27, 2017, at 5:54 PM, Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote:
Hi Carlos. you've stated: "Because it piggy-backs on data without altering the data plane realization. IPFIX for the rest." Do you believe that this combination, iOAM and IPFIX, addresses all SR requirements towards OAM? That there's no need for any other tool in the SR OAM toolbox? I believe there’s need for other OAM tools, such as LSP Ping/Trace (approved draft-ietf-mpls-spring-lsp-ping in the RFC Editor queue), and S-BFD, to name a couple key ones. There are clearly operational needs closer to trace route than to mid-point strict accounting. The sentence you quote above is in the context of this. Best, — Carlos. Regards, Greg On Sun, Nov 26, 2017 at 8:11 PM, Carlos Pignataro (cpignata) <cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote: [Sorry for jumping late to this thread! A couple of quick observations.] On Nov 21, 2017, at 1:34 PM, Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: . I clearly see folks thinking of SR-MPLS like a RSVP-TE analogy with EROs [and] On Nov 16, 2017, at 5:48 AM, stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> wrote: Robert mentioned correctly that SR-TE (especially with MPLS dataplane) has limited TE features (we cannot mimic all what RSVP does in SRTE without adding too much complexity). I think this is the key, let’s not ATM-ify the OAM uses for SR (MPLS or IPv6). On Nov 21, 2017, at 1:34 PM, Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: Especially iOAM is very useful. Yes! Because it piggy-backs on data without altering the data plane realization. IPFIX for the rest. On Nov 16, 2017, at 3:33 AM, Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote: Hi Zafar, et.al<http://et.al/>, as I'm the one who have started the thread I'd like to clarify and reiterate my point Performance measurements are required not only e2e but on a span, i.e. SPME, using MPLS-TO lingo. If we agree on that, then we are ready to discuss how to support these measurements in SR-MPLS. I believe trying to RSVP-TE-ify the path characteristics, or inventing SR-MPLS-TP is not a good idea. Thanks, — Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com> On Nov 21, 2017, at 1:34 PM, Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: Hi Adrian, I am not going to defend beauty of any architecture. I think there is much bigger fundamental misunderstanding how in practice someone will use SR-MPLS and I think this is the root cause for this little thread and different perspectives of its participants. So SR-MPLS is not RSVP-TE and there is no EROs. The set of SIDs are no more then hints on how to steer the packets within connection less paradigm (same as IP tunnel so to say with less encap overhead) via one or more of IGP segments. The less SIDs you add to the packet the better ! Yes that requires to be smart (or to have smart central controller) to add only a very few labels/SIDs to accomplish the network traffic distribution objectives. I clearly see folks thinking of SR-MPLS like a RSVP-TE analogy with EROs, but this is IMO fundamentally wrong. Only that you can do it (to build SR-MPLS paths all the way via your domain) does not make it a good idea. No where in SR architecture I see any pre-asssumption that last IGP segment will be connected to domain egress node (with the exception of EPE but this is different app). In fact as some may recall we are 17 years after RSVP-TE shipping code and only very few networks ever deployed it for all unicast traffic end to end for many reasons. Most folks used it for FRR or for hot spot bypass. Now as far as OAM sure it is great to have it both for IP networks and MPLS-LDP networks and SR-MPLS networks. Especially iOAM is very useful. But this is not really related to SR-MPLS architecture. With that I think the draft makes set of assumptions which are far from how SR-MPLS should be deployed and this does make it rather problematic. It is just like draft describing use of BGP for data centers ... now everyone is using BGP for all data centers or even other types of networks regardless if this is even applicable or best choice for a given cluster scale they are building :). Counters are great, more counters are even better, but I fail to see the value for yet again counting traffic arriving via specific IGP segments when we are already counting packets arriving via given IGP topology. My recommendation would be to solve it for MPLS-LDP in MPLS WG first (which after all is one example where flooding domain wide labels in IGP replaces) and then SR-MPLS will inherit the same solution. Cheers, Robert. On Tue, Nov 21, 2017 at 6:56 PM, Adrian Farrel <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote: Hi, I understand that you doubt that this thread will yield anything productive, but there are a couple of things you're raising that need to be nailed down. Probably the most important of these is the concern that you express that maintaining counters in the network goes against the beauty of the SR architecture because it means holding state at transit nodes. This seems to be a debate about the perfection of an architecture versus the manageability of the network. Don't get me wrong, I love a beautiful architecture, but only if the network can be operated successfully. So, we should start at the top of the document and work our way down. I assume that you don't have any issues with Section 1: it seems to say what you are saying about the statelessness of SR. Section 2 is probably where you start to be unhappy: it sets an objective (to be able to count packets per flow) and sets some requirements on any solution. That is, I think you believe that it is not necessary (or not desirable?) to count packets in an SR network and assign those counts to the SR paths that generated those packet flows. So the challenge for you is to say whether the problem described in Figure 1 is: - not a concern in network management - can be solved by other means without counting traffic at transit nodes (Note Well that other ways of counting traffic at transit nodes are still counting traffic at transit nodes). But one other point I want to pick up on is your claim that "the draft also talks about needs to break an SR Path into sub-paths". Sub-paths that are achieved through an expansion of a Binding SID are just part of the landscape and (of course) thy have to be coped with. The draft doesn't introduce sub-paths, it just observes that they exist. Lastly, the conversation on the number of labels as a multiplier seems to have gotten out of hand. Why not just agree that you original statement of "increased by up to 3x" was an exaggeration? Cheers, Adrian > -----Original Message----- > From: Zafar Ali (zali) [mailto:z...@cisco.com<mailto:z...@cisco.com>] > Sent: 20 November 2017 23:36 > To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk> > Cc: 'spring'; 'mpls' > Subject: Re: [mpls] [spring] Special purpose labels in > draft-hegde-spring-traffic- > accounting-for-sr-paths > > Hi Adrian, > > Some comments are provided in-line. > > Please note that, we all want to let this lingering tread die and follow-up > on the > next steps noted during this email exchange. I will be happy to have a webEx > call > and discuss it further, offline. > > Thanks > > Regards … Zafar > > On 11/18/17, 9:08 AM, "Adrian Farrel" > <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote: > > <snip> > > >>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that > breaks SR > >>> Architecture, highly unscalable and complicated to implement. > >> > >> [JD] Do you have any evidence to justify any of your assertions, > above? > > > > Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths: > > > > • The transit node needs to be able to recognize the special label, > read > > the SR Path Identification label and update the counter against > such > > “states”. > > > Possibly worth noting that existing devices are capable of maintaining > > many > counters and updating them at line speed. > > > Several people have noted that ipfix is a process used for accounting in > networks. That approach may have to find the bottom of stack and then match > the packet that follows. > > > Other approaches (e.g., to ECMP) involve finding the bottom of stack and > hashing on the header of the payload. > > > Some hardware cannot perform either mechanism. This usually results from > > a > trade between low cost, high performance, and features. Generally you can't > have all three. > > The question is not about if the hardware is able to perform such operations > but > regarding breaking the very beauty of SR – no states at the transit/ egress > nodes. > In the context of label stack size explosion, the draft also talks about > needs to > break an SR Path into sub-paths – thereby creating yet additional states in > the > network for accounting reasons (see more detail on this in the following). > Furthermore, SR-MPLS is designed for SDN – the architecture calls for > simplification of the network not adding complexity in the network fabric. > Please > also note that a network may have a large number of SR Path, thereby creating > another dimension for scaling limitations. > > The proposed procedure also does not work for node protection in the network. > The draft essentially calls for ALL nodes to implement procedure proposed in > the > document; I am quoting from the draft. > > “When using extensions > described in this document for traffic accounting and with node- > protection enabled in the network, it is RECOMMENDED to make sure all > the nodes in the network support the extension.” > > <snip> > > > • The draft proposes to push (up to) 3 Labels for each segment in > the SR > > Path. That means that label stack is increased up to 3x times! > This is a > > serious a scaling issue. > > > John asked for evidence and you provided a misunderstanding or misreading > of our draft. > > The document proposes adding 2 or 3 labels per SR Path (noting as John > > did, > that this is our own term). > > That is not what you say, so perhaps you could retract or provide a > > pointer to > the text. > > > Thus, "increased up to 3x times" applies only with the single case where > > the > imposed label stack has exactly one label *and* the three label option is > applied. > So, while what you say is true, it is clearly (and wilfully?) exaggerating > the > severity of impact, and it is doubtful that 4-label stack is actually a > problem. > > There are many scenarios that will require SR-Path-Stats Labels (up to 3 > labels) to > be present multiple times in the label stack. These scenarios are not > uncommon. > The following scenarios as noted in the draft. x`x> > “The head-end node SHOULD insert the SR- > Path-Stats Labels at a depth in the label stack such that the nodes > in the SR path can access the SR-Path-Identifier for accounting. The > SR-Path-Stats Labels may be present multiple times in the label stack > of a packet.” > > “It is possible to partially deploy this feature when not all the > nodes in the network support the extensions defined in this document. > In such scenarios, the special labels MUST NOT get exposed on the top > of the label stack at a node that does not support the extensions > defined in this document. This may require multiple blocks of SR- > Path-Stats Labels to be inserted in the packet header.” > > > • The controller needs to keep track of transit node capability and > > push the additional per-path labels, accordingly. I.e., the > controller > > also needs to maintain such information for the transit nodes. > > > In most cases, the controller/ingress only needs to care about the > > capabilities > of the egress nodes. That is, if the special purpose label reaches the top of > the > stack it has to be able to handle it. > > > The only time when the transit node issue arises is when there is a > > small RLD. > That information may need to be known by the controller to enable correct ECMP > behavior, and it is distributed in the IGP. > > If there is a desire to enable accounting at transit nodes with a small > > RLD then > the Path ID can be inserted higher up the stack and *that* means that the > controller has to be sensitive as to where in the network the special purpose > label will rise to the top of the stack. > > > It seems to me that: > > - Controllers are not particularly resource constrained: adding a flag > > per node > > (or even per link!) would not break any scaling behavior. > > - Adding another flag to the IGP alongside the RLD is not significant > > scaling > issue. > > The comment here was not so much related to scaling but was for adding > complexity to the controller/ ingress node. As you noted above and in the > draft, > controller/ Ingress node needs to worry about the following cases every time a > path needs to be computed (quoting some of the cases from the draft). > > “When the head-end node > inserts the SR-Path-Stats labels in the label stack, the place in the > stack is decided based on whether the node where the special label > gets exposed is capable of popping those labels.” > > > “While inserting the SR-Path-Stats labels, the head-end router MUST > ensure that the labels are not exposed to the nodes that do not > support them. “ > > “Because it is necessary that the SR-Path-Stats labels are removed > when they are found at the top of the label stack, the node imposing > the label stack (the ingress) must know which nodes are capable of > stripping the labels.” > > In RLDC limitation cases, “To support traffic > accounting in such cases it is necessary to insert the SR-Path-Stats > Labels within the Readable Label Stack Depth Capability (RLDC) of the > nodes in the SR path.” > > “The head-end node SHOULD insert the SR- > Path-Stats Labels at a depth in the label stack such that the nodes > in the SR path can access the SR-Path-Identifier for accounting.” > > “The special labels MUST NOT get exposed on the top > of the label stack at a node that does not support the extensions > defined in this document.” > > “If the egress has not indicated that it is capable of removing the > SR-Path-Stats Labels, then they MUST NOT be placed at the bottom of > the label stack. In this case the SR-Path-Stats Labels SHOULD be > placed at a point in the label stack such that they will be found at > the top of stack by the latest node in the SR path that is capable of > removing them. “ > > “SR paths may require large label stacks. Some hardware platforms do > not support creating such large label stacks (i.e., imposing a large > number of labels at once). To overcome this limitation sub-paths are > created within the network, and Binding-SIDs are allocated to these > sub-paths.” … which means controller/ ingress software need to also create/ > install sub-paths. > > <snip> > > _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ mpls mailing list m...@ietf.org<mailto:m...@ietf.org> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
