The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

Alex

Just to make sure that I did not misrepresent the approach I was advocating, I am going to go
into more details here:

In this approach, a group of heterogeneous links are bundled such that, to L3 protocols and
above this group of links appears as a single "interface" This in nature is similar to
802.3ad link aggregation but is a superset of that since it works with POS interfaces as
well.

Such an approach also reduces routing protocol processing load, and also simplifies link
management as well.

Thanks for your comments,

I have just downloaded the LMP document and will review it tomorrow and see if it covers
relevant aspects of bonding.

Bora



Alex Zinin wrote:

> Bora,
>
> I still think *both* approaches are feasible.
> We have seen both of them used in traditional IP networks.
>
> L3 bundling seems to be attractive to me exactly because
> it does not require a special L2 protocol on the component
> links, which is really good from the customer and deployment
> perspective. From the implementation perspective, it may also
> be simpler to introduce a change in the topo abstraction logic
> of a network control layer protocol, rather then trying to
> completely solve the problem at the link-control layer.
> I'm not saying, however, that L2 bundling should never be
> used.
>
> With that being said, I personally think it makes sense
> to accept the document as a WG item. If you think your approach
> is better and the industry should use it, why don't you document
> it in a draft (as a separate effort or as an extension to LMP)
> and then ask for the feedback. This does not mean, however, that
> other approaches will not be used. Different opinions can
> co-exist and this is absolutely fine.
>
> --
> Alex Zinin
>
> Sunday, July 09, 2000, 7:48 PM, Bora Akyol <akyol@pluris.com> wrote:
>
> > Kireeti Kompella wrote:
>
> >> Bora,
> >>
> >> > IMHO, bundling at L2 level and representing a single abstraction to L3 protocols
> >> > is a cleaner approach.
> >>
> >> Would you likewise say that MPLS protection is redundant because L2
> >> protection is "cleaner"?
> >>
>
> > I fail to see the relation of MPLS protection to L2 bundling. There are quite a few
> > people in this WG and in the community that know my opinions on MPLS protection.
>
> >>
> >> Let me repeat the primary intent of the bundling document: to reduce
> >> TE state in ISIS/OSPF.  Forcing bundling at L2 just to improve TE
> >> scaling seems an overkill.  There are other issues:
> >>
> >> 1) L2 "bundling" changes the topology of the network.  Those who are
> >>    satisfied with their topology for IP but would like better scaling
> >>    for MPLS/TE may not want L2 bundling.
> >>
>
> > Yes, L2 bundling actually simplifies the total topology of the network, as opposed to
> > saving a few CPU cycles here or there for MPLS, ISIS-TE, etc which I think is a major
> > advantage.
>
> >> 2) Can L2 bundling deal with disparate L1/L2 media?
>
> > Yes, it can. Really not that difficult if you get the initial abstraction right, which
> > is the reason of my objection to this draft becoming a WG document. It does not get the
> > abstraction of a bundle right and is solving a very small problem instead of addressing
> > the root of the problem: Next gen routers will have lots and lots of interfaces and
> > this coupled with OXCs etc. will cause a lot of links between neighboring routers.
> > Admittedly, this is less of a problem for smaller non-scalable routers.
>
> >>
> >> 3) How does L2 bundling solve the problem of hundreds of lambdas in a
> >>    fiber (or multiple fibers) connecting two LSRs?
> >>
>
> > Again, I thought this would be kind of obvious, but I guess not. If you get the
> > abstraction of an L2 aggregate right (let us call that a "bond"), then you can support
> > thousands of phsyical ports aggregated to a bond with dynamically varying membership
> > and represented as a single entity to the upper layers. Not only this, but this
> > particular L2 aggregate (BOND) also supports N+K protection with rapid healing.
>
> >>
> >> > For example, in this draft, even though the links are
> >> > bundled, when you request a label, there is the notion of requesting a label on a
> >> > particular link (essentially unbundling things).
> >>
> >> Again, the intent to reduce ISIS/OSPF TE state.  "Unbundling" locally
> >> between two neighbors is perfectly fine, even necessary.
> >>
>
> > You think it is necessary because of the model that you are using. It really isn't
> > necessary.
>
> >>
> >> > When ISIS/OSPF run over a
> >> > bundled link, the text mentions the fact that they can indeed run over only a
> >> > single member of the link. But which member? What happens if that particular
> >> > member fails?
> >>
> >> Running ISIS/OSPF over a single member is a small but useful
> >> optimization, and quite orthogonal to the issue of bundling.  Is this
> >> the extent of your issues with MPLS/TE bundling?
> >>
> >> [...]
> >>
> >> > My suggestion was not to split the document but to come up with a better
> >> > abstraction than what is presented in this document. We will be submitting an
> >> > internet draft on such an implementation soon (but probably not before the
> >> > deadline for Pittsburgh).
> >>
> >> I'm sure your document is an excellent one.  However, having L2 bonding
> >> doesn't preclude having MPLS/TE bundling.  You have yet to convince me
> >> that L2 bonding is better than MPLS/TE bundling, and more importantly,
> >> that L2 bonding is even as good as MPLS/TE bundling in the MPL(ambda)S
> >> context.
> >>
> >> Kireeti.
>
> > Kireeti,
>
> > I don't have a document, I have an implementation that is well-advanced and works;
> > which I thought was one of the guiding principles of IETF: "Working code." I am not in
> > the document producing business.
>
> > Again, if your document had gotten the abstraction of an aggregate of multiple links
> > right and then dove into the details of MPLS, I would have had no problems with it. But
> > this is not the case right now, hence my objection.
>
> > Regards
>
> > Bora