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

[Martin Horneffer <[e-mail]>]

+1

In other words, I confirm from an operators point of view that Robert 
got good network desing goals quite right. I also perfectly agree with 
the observations concerning the use of RSVP in the past.

BR, Martin

Am 21.11.17 um 19:34 schrieb Robert Raszuk:
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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:[e-mail]
>     <mailto:[e-mail]>]
>     > Sent: 20 November 2017 23:36
>     > To: [e-mail] <mailto:[e-mail]>
>     > 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" <[e-mail]
>     <mailto:[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.
>     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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/spring
>     <https://www.ietf.org/mailman/listinfo/spring>
>
>
>
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring