The MPLS WG Archive

[Alex Zinin <azinin@cisco.com>]

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