Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00

I really do not see anything stateful in the network with the model described.

Cheers,
R.

On Thu, Jun 5, 2014 at 3:25 PM,  <stephane.litkowski@orange.com> wrote:
> Robert,
>
> I would tend to disagree with you.
> With your model, loadbalancing becomes "stateful" so you need to create new forwarding states on your nodes to achieve the granularity you want and you will never be able to the same level of granularity that you have today with hop by hop hashing approach. I agree that hop by hop approach may also have some drawbacks like polarization.
> IMHO, loadbalancing must be kept "stateless" as much as possible.
>
> But nothing says that one model must kill the other (ingress lb vs hop by hop lb) and both may be used in the same network for different reason.
>
> Stephane
>
> -----Original Message-----
> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Robert Raszuk
> Sent: Thursday, June 05, 2014 14:25
> To: Xuxiaohu
> Cc: isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org
> Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
>
> Hi Xu,
>
> Actually let me express an opinion that while for other MPLS signalling protocols the concept of entropy label as describe in RFC
> 6790 may be useful I would rather question if the same applies to segment routing architecture.
>
> Fundamental difference here is that other MPLS signalling protocols bind labels to FECs. SR on the other hand binds SIDs (which one of the special case of can be label) to nodes or links. That means that number of such bindings will naturally be orders of magnitude less in the SR concept.
>
> That means that perhaps one could really analyze if the tuple ELI + EL (one or many) is that much needed as opposed to advertise wider range of SIDs and simply use those in flat layer for loadbalancing reasons ?
> Just mapping different flows on ingress to different label from said range.
>
> Also that not only can accomplish egress node loadbalancing, but also all via nodes will have no problem with such input to a hash function regardless if they are SR capable or not ?
>
> Maybe rather then copying all fixes of MPLS original architecture to SR its better to adjust SR architecture to at least not repeat the same mistakes we have already made in the past ?
>
> Comments ?
>
> Cheers,
> R.
>
>
>
> On Sat, May 31, 2014 at 10:05 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
>> Hi WG co-chairs,
>>
>> This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) describes how to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in SPRING networks. Since (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-00) has been adopted as a WG draft, as co-authors of draft-xu-isis-mpls-elc-00, we hope you could consider the WG adoption for this draft as well.
>>
>> Best regards,
>> Xiaohu (on behalf of all-authors)
>>
>> _______________________________________________
>> Isis-wg mailing list
>> Isis-wg@ietf.org
>> https://www.ietf.org/mailman/listinfo/isis-wg
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg