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

Hi Robert,

Please see in-line.

> -----Original Message-----
> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert
> Raszuk
> Sent: Thursday, June 05, 2014 9:43 AM
> To: Nobo Akiya (nobo)
> Cc: Xuxiaohu; 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 Nobo,
> 
> Well the range size would be as big as most ECMP paths you have. Say
> 32 or 64 as example.
> 

Number of ECMP paths doesn't necessary equal to number of hash buckets in implementations. In addition, SID advertising node would need to be aware of upper bound ECMP paths (and hash buckets) from all [potential] ingresses to itself in order to advertise the right number of SIDs ... or always advertise _max_ number of SIDs for ECMP.

> As to the forwarding table size in the core it is rather implementation
> dependent .. you really do not need to do exact match for all labels in a
> range (unlike with atomic 20 bit wide MPLS label) it is still much less then
> you have entries on the ingress and egress .. as those are in millions.

Still, in an SR network consisting of 100 nodes ... each network node used to have 100 node SID forwarding entries (assuming one SID advertised per node) but now each network node will have 3200 or 6400 or 12800 node SID forwarding entries. That's a huge increase. Sure the forwarding table can do some aggregation but number of "resources" reserved, consumed, advertised and OAM requires to support them are still enlarged significantly.

I still see tackling EL to be appealing :)

Thanks!

-Nobo

> 
> Cheers,
> R.
> 
> 
> On Thu, Jun 5, 2014 at 3:15 PM, Nobo Akiya (nobo) <nobo@cisco.com>
> wrote:
> > Hi Robert, Xu,
> >
> >> 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.
> >
> > That's an interesting idea, but I'd like to highlight one down side. "wider
> range of SIDs" will likely have to be fairly large/wide to have good
> probability of good ECMP distribution throughout the network, and that will
> likely result in a significant increase in forwarding table in every network
> nodes. Obvious side effects include increased SRGB, increased memory
> usage, debugging difficulty, increased number in in-band-OAM to test all
> forwarding entries.
> >
> > Considering above, perhaps fitting in EL to MPLS based SR is still a
> reasonable option to discuss. It's not a trivial topic, but I think this is an
> important topic that has lacked attention.
> >
> > Xu, I think draft-xu-isis-mpls-elc should have a reference to draft-kini-
> mpls-spring-entropy-label. And I agree with Stephane, there's minimal
> benefit in progressing draft-xu-isis-mpls-elc before draft-kini-mpls-spring-
> entropy-label.
> >
> > Thanks.
> >
> > -Nobo
> >
> >> -----Original Message-----
> >> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Robert
> >> Raszuk
> >> Sent: Thursday, June 05, 2014 8:25 AM
> >> 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