The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

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