Re: [spring] SPRING MPLS and Entropy Label

IMHO,
> 1) is ECMP needed with MPLS SPRING (in particular, Adj-SID)?
Yes it is ... SPRING brings more flexibility in ECMP for TE tunnels than RSVP-TE does. And ECMP with Bundle-Adj-SID is something really useful when a Service Provider is using parallel ECMP links rather than LAGs.

>2) is EL the way to achieve ECMP with MPLS SPRING?
I would also agree that having two mechanism would be bad from an operational point of view.
Entropy label is not new at IETF, but new in deployment (feature availability is something really recent). If SP that have deployed Entropy for loadbalancing flows needs to move to something else for their SR-TE tunnels, well ... sounds a bad thing ...
Moreover entropy label has the magic of keeping loadbalancing stateless which is a pretty good advantage compared to adding more states at Ingress just for loadbalancing.

Stephane

-----Original Message-----
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rob Shakir
Sent: Wednesday, July 23, 2014 17:56
To: Kireeti Kompella
Cc: mpls@ietf.org; spring@ietf.org; draft-kini-mpls-spring-entropy-label@tools.ietf.org
Subject: Re: [spring] SPRING MPLS and Entropy Label

Hi Kireeti,

(Responding on-list for completeness - and a reminder to myself.)

On 23 Jul 2014, at 12:54, Kireeti Kompella <kireeti@juniper.net> wrote:

>> - I feel that it would be useful to provide some clarification as to 
>> where we expect entropy to be required for load-sharing in the draft.
> 
> There are three questions hiding here:
> 1) is ECMP needed with MPLS SPRING (in particular, Adj-SID)?
> Valid question, as ECMP wasn't seen at first as necessary with RSVP-TE, which shares intent with Adj-SID. I'd say the answer is Yes.  You give an example of why; analogies from the multi path RSVP draft can also be used. 
> 
> 2) is EL the way to achieve ECMP with MPLS SPRING?
> I sincerely hope so; having two mechanisms in MPLS to enable ECMP wouldn't be ideal. But I won't rule out other ways. 
> 
> [Your point is taken: laying out (1) and (2) more clearly would help 
> the draft.]

rjs> I agree with both points. Let me work to contribute some material to expand on the couple of points I raised following the meeting this week.

> 
> 3) Given Yeses to (1) and (2), how?
> That's the current focus of the draft. This part is for now an exploration. I agree that at some point, we have to narrow the options down to a few (ideally one). This would be an action for vendors, knowing their chips, and providers, knowing their requirements to sit together and work it out. 
> 
> There is an aspect of the draft that hasn't come out, which is along the lines of the MPLS forwarding draft, soon to be an RFC: what is the best way in the future, given the requirements of SPRING and EL? I.e., if you built new chips today, knowing what we know, which option would you choose?  Getting a sense of that would help the community to come to a common choice for the future -- as someone mentioned, today's choices/compromises may end up varying widely vendor-to-vendor. 

rjs> Agreed - if we can determine whether we think that the list of options is complete following the exercise of solving (1) and (2), then perhaps we can start to address these questions and try to conclude the discussions at the next meeting.

Cheers,
r.

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.