Hi Zafar, "overloading existing special label"? AFAIK, MPLS WG created Extended Special Label exactly for cases like we're discussing. Of course, alternative proposal for SR-MPLS use case will be most helpful. As description of GAL-ACH based proposal. Stay tuned.
Regards, Greg On Mon, Nov 20, 2017 at 7:06 PM, Zafar Ali (zali) <[email protected]> wrote: > Hi Greg, > > > > Overloading existing special label, optimizing stack overheads in > draft-hegde, etc. will not change the architectural direction of the > proposal. > > > > I feel additional discussion on this thread will be non-productive. Martin > Horneffer, Robert Raszuk, Stephane Litkowski and others have shared from > their operation experiences; their input cannot be ignored by the vendors. > They and others have outlined some alternatives. We need to follow-up on > additional documentation (on the alternatives including existing counters) > to help us converge. Please stay tuned. > > > > Thanks > > > > Regards … Zafar > > > > > > *From: *Greg Mirsky <[email protected]> > *Date: *Monday, November 20, 2017 at 7:03 PM > *To: *"Zafar Ali (zali)" <[email protected]> > *Cc: *"[email protected]" <[email protected]>, "[email protected]" < > [email protected]>, spring <[email protected]> > *Subject: *Re: [mpls] [spring] Special purpose labels in > draft-hegde-spring-traffic-accounting-for-sr-paths > > > > Hi Zafar, > > I don't see how managing, using passive OAM, i.e. counting fly-by packets, > at transient SR-MPLS nodes can be equated to breaking "no-forwarding state > at transient LSR" model.I believe that practical is as important as > aesthetic and that network cannot be operated without comprehensive OAM > tool box. Of course, every tool in the box is optional and will not be > deployed unless the need arises. If we agree on that, perhaps we can > discuss new requirement to be added to the SR OAM Requirements document. > And then, then consider how to address such requirement. I believe that two > options were mentioned in the thread: > > - described in draft-hegde-spring-traffic-accounting-for-sr-paths > special purpose label (actually it may end up be extended special purpose > label) and up to two labels; > - use GAL and ACH (perhaps somewhat similar to approach used in RFC > 8169). > > Regards, > > Greg > > > > > > On Mon, Nov 20, 2017 at 3:36 PM, Zafar Ali (zali) <[email protected]> wrote: > > 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" <[email protected]> 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. > > “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> > > > > > _______________________________________________ > mpls mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mpls > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
