The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

John

Can you please point me to this document? I do not see a document listed with
this title at www.ietf.org under MPLS WG documents.

Thanks

Bora


John Drake wrote:

> Bora,
>
> A lot of your questions are addressed by Link Management Protocol (LMP),
> which is explicitly part of the MPLS working group charter.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Bora Akyol [mailto:akyol@pluris.com]
> Sent: Saturday, July 08, 2000 8:29 AM
> To: Alex Zinin
> Cc: Eric Gray; George Swallow; mpls@UU.NET
> Subject: Re: Link Bundling
>
> 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
> > >> >
> > >> >
> > >> >