Re: [mpls] [spring] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

[Greg Mirsky <[e-mail]>]

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) <[e-mail]> 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 <[e-mail]>
> *Date: *Monday, November 20, 2017 at 7:03 PM
> *To: *"Zafar Ali (zali)" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, spring <[e-mail]>
> *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) <[e-mail]> 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" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>