The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

Alex Zinin wrote:

> Bora, Eric, group.
>
> 1. I think it is not quite appropriate to speak about L2 vs L3
>    link bundling. Approaches can be different, both have their
>    pros and cons, but both have a right to live. So, I don't think
>    this should be a driving factor.

IMHO, bundling at L2 level and representing a single abstraction to L3 protocols
is a cleaner approach. 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). 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? These are some of the questions that would be (are) answered by a
good L2 bundling abstraction.

>
> 2. Link bundling, in the context it is presented in the document,
>    seems to be MPLS-specific to me.
>

Yes, but there is no reason for it to be MPLS specific.

>
> 3. MPLS-specific contents vs routing-protocol-specific contents.
>    It should be noted that TE attributes introduced to OSPF and ISIS
>    are transmitted by respective protocols as opaque data, not
>    taken into consideration by the protocol itself (other than
>    flooding), so, strictly speaking, as soon as we have specified
>    a standard way to carry such data, and this data does not affect
>    operations of the protocol itself, changes in the actual data
>    being propagated is no more a business of that protocol.
>

OK.

>
> I think the document is purely MPLS-specific, covering several
> areas of MPLS-related functions. OSPF & ISIS are used just as transport
> protocols and that makes perfect sense to me.
> I don't see much sense in braking the document into 3 separate
> parts and presenting them at OSPF, ISIS, and RSVP WGs, especially
> taking into consideration that the changes are MPLS-specific...
>

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).

Regards

Bora Akyol

>
> My vote: accept.
>
> --
> Alex Zinin
>
> Friday, July 07, 2000, 12:23 PM, Bora Akyol <akyol@pluris.com> wrote:
>
> > Eric
>
> > As I mentioned in my previous email, I would be happy to write an ID that
> > describes our approach and work with the community to make it an open
> > standard.
>
> > I believe that the bonding of L1 links into one bonded (bundled) L2 link is
> > something that should be protocol-neutral and should work with all L3
> > protocols. I believe that such an abstraction is possible and is actually
> > fairly straightforward to implement and provides a coherent framework that
> > one can use to ask questions like if protocol X were to run over a bonded
> > link, how would it run; and then actually answer it in an easy manner.
>
> > Thanks for the comments,
>
> > Bora
>
> > Eric Gray wrote:
>
> >> Bora,
> >>
> >>         I essentially agree with the observation that
> >> link bundling is not inherently an MPLS issue and I
> >> also feel that this draft - at least as is - should
> >> not be adopted by the MPLS working group.  However,
> >> my reasoning is slightly different than yours.
> >>
> >>         While the draft does include a lot of stuff
> >> that is specific to MPLS, it also includes a ton of
> >> IS-IS and OSPF specific stuff as well.  My sense is
> >> that it actually has significantly more non-MPLS
> >> related stuff in it than MPLS related stuff.  Other
> >> people may disagree but, at the very least, this
> >> work should be done in a forum that is less focused
> >> on label switching and more focused on routing.
> >>
> >>         I do not think it is very useful to provide
> >> examples of proprietary approaches to solving the
> >> problem.  It takes two to bundle links.  But, if
> >> your point is that it may be a good idea to back
> >> away from a link-bundling scheme that is particular
> >> to MPLS LSP based links, I think it is a good point.
> >>
> >> --
> >> Eric Gray
> >>
> >> > -----Original Message-----
> >> > From: Bora Akyol [mailto:akyol@pluris.com]
> >> > Sent: Friday, July 07, 2000 11:39 AM
> >> > To: George Swallow; mpls@UU.NET
> >> > Subject: Re: Link Bundling
> >> >
> >> >
> >> > George, Yakov, et al.,
> >> >
> >> > I do not think that this internet draft should be adopted as an MPLS
> >> > working group document. My primary objection to this document
> >> > is the fact
> >> > that bundling of L1/L2 interfaces has nothing specific to do
> >> > with MPLS.
> >> > In fact, this is an L2 abstraction that should be completely
> >> > transparent
> >> > to MPLS, IP or ISIS. I feel that this particular draft is
> >> > very focused on
> >> > MPLS-specific concerns and does not provide a good
> >> > abstraction of the L2
> >> > bundling aspects and also places significant restrictions on
> >> > what can be
> >> > done with a bundled link and what kind of members it can have.
> >> >
> >> > I personally know of at least one implementation (ours) of
> >> > bundled links
> >> > that forms such an abstraction to all upper layer protocols. In this
> >> > implementation, a heterogeneous group of L1/L2 interfaces are bonded
> >> > together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP
> >> > treats the
> >> > bundled (bonded) interface as just another type of interface.
> >> > When MPLS
> >> > RSVP messages are passed over the bundled interface, the
> >> > labels that are
> >> > assigned are programmed into all members of the bundled links
> >> > even though
> >> > in reality a hash is used so that only one of the members are used (to
> >> > prevent reordering). Bandwidth management is handled by means of the
> >> > apriori knowledge of the hash. Also note that this particular
> >> > implementation is not MLPPP since no additional headers are
> >> > added to the
> >> > packets.
> >> > For MPLS specific concerns, the methods that are used in this approach
> >> > can be expanded. For IP, this particular approach works very well.
> >> >
> >> > If there is interest from the MPLS WG, we (myself and another
> >> > colleague)
> >> > would be perfectly willing to author an Internet Draft on
> >> > this particular
> >> > bond implementation. The question that I have is what is the
> >> > proper forum
> >> > to submit a generalized layer 2 bundling draft in the IETF. It is
> >> > certainly relevant to MPLS, but it is just as relevant to IP,
> >> > ISIS, etc.
> >> >
> >> > Regards
> >> >
> >> > Bora Akyol
> >> >
> >> >
> >> > George Swallow wrote:
> >> >
> >> > > > Folks,
> >> > > >
> >> > > > Kireeti and myself would like to ask the MPLS WG to
> >> > > > accept draft-kompella-mpls-bundle-01.txt as an
> >> > > > MPLS WG document.
> >> > > >
> >> > > > Yakov.
> >> > >
> >> > > Consensus on this will be assessed on 7/12.  Opinions
> >> > should be aired
> >> > > by then.
> >> > >
> >> > > ...George
> >> > >
> >> > > ==================================================================
> >> > > George Swallow       Cisco Systems                   (978) 244-8143
> >> > >                      250 Apollo Drive
> >> > >                      Chelmsford, Ma 01824
> >> >
> >> >
> >> >