Hi Sri!
Thanks for the feedback.
On 23 Jul 2014, at 02:40, Sri <sriganeshk...@gmail.com> wrote:
> Sri> You are correct. If a SID identifies multiple physical paths as in the
> case of Adj-SID identifying a bundle, then load balancing on that segment
> would be useful. When there is no information that every SID of a LSP maps to
> a single physical path, a load-balancing mechanism should be used for that
> LSP. I agree that today there is no mechanism to give such information about
> the mapping, so load balancing on every segment is useful. Whether that is
> achieved by using an EL per segment as described in sec 3.2 thereby resulting
> in a label stack of 3*#SIDs is something to be discussed. The draft lists the
> downsides of choosing that option.
>
>
> I think that the above means that the current draft under-estimates the
> depth
> of the stack when considering an EL per tunnel (§3.2), which might amplify
> some of the concerns raised for this option.
>
>
> Sri> The draft does not estimate stack depth (without EL) since the depth is
> dependent on the degree of strict-hop traffic-engineering desired by the
> application. If you meant to say that the label stack is deep due to the
> application trying to make it as close to the desired physical path but you
> end up using the EL per segment anyways since there isn't information to
> determine for sure whether the mapping is to a single physical path, then yes
> the label stack will be very deep.
rjs> Absolutely. The point that I think is important here is that in the case
that we have:
src->[ A ] -- [ B ] -- [ C ] -- [ D ] -- [ E ]->sink
\ | /
--------------[ F ] -----
And we have a strict requirement for A-B-C-D-E, then whilst it might
immediately look like we could specify:
<SA{B},SB{C},SC{D},SD{E},SE{sink}> [5 labels]
then actually, the requirement for EL per tunnel is now:
<SA{B},ELI,EL,SB{C},ELI,EL,SC{D},ELI,EL,SD{E},ELI,EL,SE{sink},ELI,EL> [15
labels]
The example that you have in the document makes the case look somewhat better
than this. As you say, this is because the application that is chosen in the
example is somewhat less strict with its path placement requirements, and a
number of the labels in the stack are associated with services. A reader could
easily conclude that since the strict src->A->B->C->D->E->sink path that is
chosen has affinity to individual adjacencies, this concern does not apply, but
to deal with the fact that things are bundles/LAGs, then I think it does.
It’d be great if we could patch the wording (happy to help contribute) to
provide some wording that says that applications that already produce deep
label stacks would produce even deeper label stacks with this option AND we
know that there are limitations with the number of labels that can be pushed by
real h/w today.
> Sri> This is correct. In case of re-routing from ingress, the algorithm to
> compute EL depths have to be re-computed. If the re-route is like FRR via a
> bypass LSP, the PLR may want to insert ELs if load-balancing is desired along
> the bypass.
>
>
> In terms of discovery of the capabilities of a mid-point -- do we need to
> consider how, in a multi-area network, we discover the capabilities of a
> mid-point which might not have information about it leaked between areas?
>
> Sri> Option in 3.4 runs into such complications in case of multi-area. All
> such cases have not been addressed yet for the option in 3.4
rjs> Sure — it would potentially be good to note this as a downside. Especially
if there’s no clear solution other than leaking information between areas,
since this has impact on operator’s network designs today.
> - Finally, it'd be good to determine what the intention of the authors for
> this
> document is. Do we expect that we make a recommendation as to what equipment
> vendors who are going to support SR-MPLS should optimise for? At the moment,
> the document is good at classifying the different approaches that _could_ be
> taken, but potentially requires an operator/vendor to consider optimisation
> for both a) reading very deep into the stack when acting as an LSR, b)
> pushing
> very deep stacks when acting as iLER, c) potentially implementing more
> complex
> swap() operations, whereby some reshuffling of the EL is required.
>
> My feeling is that it would be very useful for this document to be able to
> make a clear recommendation as to which of these approaches should be
> optimised for, and hence we should debate their technical efficacy. It'd be
> good to understand whether the authors are intending to do this, or rather
> classify the approaches.
>
> Sri> The first goal of the draft was to list the various approaches. But the
> final goal is to come up with recommendations through the discussions on the
> various approaches.
rjs> Great — aligned with this, I think there would be some utility to adding
another option, which is that where there are ECMPs that can be differentiated
in terms of use of different SIDs (e.g., load-balancing across two core
planes), then a head-end based option (as per the approach that we would take
today with RSVP-TE LSPs) is possible.
rjs> Addressing the final goal - as per Stephane’s comments - I would like to
recommend that we specify §3.1 as the target option (such that we have a single
ELI/EL deeper in the stack) as the “ideal” option. It then seems to me that a
debate as to whether the forwarding behaviour in §3.3 is possible with most h/w
today (both mean that either we change the number of operations that are
required on a forwarding device when popping/swapping labels as far as I can
see), or whether the approach in §3.4 (with the caveats noted above) is the
best way forward.
Thanks for your consideration.
r.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
