Subject: Re: Link Bundling

From: Kireeti Kompella <[email-masked]>
Date: Wed, 5 Jul 2000 09:47:57 -0700 (PDT)

Hi Debanjan,

Here are some of the clarifications you requested:

1) Component link addresses: we've loosened the wording on this
   slightly; the new text follows.

  Component links may be unnumbered, or the various component links
  may be numbered differently, or all components links may be numbered
  identically.  In the first two cases, the bundled link is unnumbered
  by default; in the last case, the bundled link is numbered the same
  as the component links by default.  In all cases, the bundled link's
  addresses may be overridden by configuration with IP addresses
  assigned to some "virtual" interfaces on an LSR (it is assumed that
  an LSR may have multiple virtual interfaces).

   "Numbered identically" means that local addresses are the same AND
   remote addresses are the same.

2) Bundling SRLG and other resource information should be covered in
   the routing drafts for "optical" MPLS, as bundling as described in
   this document is a generic MPLS construct.

Hope that helps,
Kireeti.

---

From: John Drake <[email-masked]>
Date: Sun, 9 Jul 2000 13:58:15 -0700

This note saves me some typing.  I think it makes perfect sense.

John

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Saturday, July 08, 2000 1:04 AM
To: Bora Akyol
Cc: Eric Gray; George Swallow; [email-masked]
Subject: Re: Link Bundling

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.

2. Link bundling, in the context it is presented in the document,
   seems to be MPLS-specific to me.
   
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.

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 vote: accept.

-- 
Alex Zinin

Friday, July 07, 2000, 12:23 PM, Bora Akyol <[email-masked]> 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:[email-masked]]
>> > Sent: Friday, July 07, 2000 11:39 AM
>> > To: George Swallow; [email-masked]
>> > 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
>> >
>> >
>> >

---

From: Irwin Lazar <[email-masked]>
Date: Mon, 10 Jul 2000 08:19:43 -0600

See: http://www.ietf.org/internet-drafts/draft-lang-mpls-lmp-00.txt

Please note that we keep a fairly complete list of MPLS related drafts at
http://www.mplsrc.com/drafts.shtml

Irwin

-----Original Message-----
From: Bora Akyol [mailto:[email-masked]]
Sent: Sunday, July 09, 2000 10:52 PM
To: John Drake; [email-masked]
Subject: Re: Link Bundling

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
>
> Sent: Saturday, July 08, 2000 8:29 AM
> To: Alex Zinin
> Alex Zinin wrote:
> 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.
>
> >
> Yes, but there is no reason for it to be MPLS specific.
>
> >
> OK.
> 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
> >

---

From: Eric Gray <[email-masked]>
Date: Mon, 10 Jul 2000 16:39:00 -0700

Lou,

	I seem to recall that someone had made a proposal 
some (real long) time back to include link information 
in MPLS signaling.  I can't see to recall whatever 
happened to the idea though.  :-)

--
Eric Gray

> ---
      ... <snip> ...
> 
>    4. Have MPLS signaling just provide the link information.
>       This is what's documented in the draft.  It does mean 
>       that signaling needs to convey link information, but it 
        allows greater flexibility than an algorithmic approach 
        and doesn't require the use of yet another signaling 
        protocol to setup each LSP.
      ... <snip> ...

---

From: John Drake <[email-masked]>
Date: Tue, 11 Jul 2000 11:46:44 -0700

exactly

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Tuesday, July 11, 2000 11:29 AM
To: Lou Berger
Cc: Greg Waters; Bora Akyol; George Swallow; [email-masked]
Subject: Re: Link Bundling 

Lou,

> At 08:35 AM 7/11/00 -0400, Greg Waters wrote:
> >At 07:48 PM 7/10/00 -0400, Lou Berger wrote:
> >>Greg,
> >>         You are correct, spreading a single LSP over multiple component

> >> links is not supported in the bundle draft.  I agree this could have 
> >> some value for best-effort LSPs.  (The draft was concerned with TE 
> >> LSPs.)  We could support such "spreading" by adding a special link
value 
> >> or bit to indicated that the label should be made available on all PSC 
> >> (packet) links of a bundle/bond.  (The spreading algorithm need not be 
> >> standardized for this case.)
> >>Lou
> >
> >I was talking about TE LSPs--in particular, TE LSPs whose capacity is 
> >greater than the fastest physical link.  Having that kind of LSP greatly 
> >simplifies the scaling and resiliency of TE.  You can widen the bundle at

> >any hop without having to thread new LSPs to use it.  You can, for 
> >example, increase the capacity of an existing LSP without regard to the 
> >elements of bundles that it traverses.
> 
> I may be wrong (since I of course can't speak for anyone else) but, I
don't 
> think any of us would argue that allowing LSPs to span multiple links is 
> worth investigating.  That said, I do feel that we should get the simple,
1 
> link/LSP, solution out there without having it wait for the harder to 
> standardize, n-links/LSP, solution.

For some types of links (e.g., links between OXCs) n-links/LSP solution
is just not feasible (due to the nature of the links). And we certainly
need to have a solution for such links.

Yakov.

---

From: Fong Liaw <[email-masked]>
Date: Thu, 27 Jul 2000 17:16:33 -0700

Hi, Kireeti

On the topic of addresses. I can not figure out
how to advertise different addresses for the case of 
"various components may be numbered differently". 
Do component numbers need to be advertised ? if no, 
what's the purpose of numbering, if yes, how to advertise. 
Can you elaborate ?

Regards,
-Fong

>  From: Kireeti Kompella [mailto:[email-masked]]
>  Sent: Wednesday, July 05, 2000 9:48 AM
>  To: [email-masked]; [email-masked]
>  Cc: [email-masked]; [email-masked]; [email-masked]

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 27 Jul 2000 18:13:26 -0700 (PDT)

Hi Fong,

> "various components may be numbered differently". 

The draft says:

   Component links may be unnumbered, or the various component links
   may be numbered differently, or all components links may be
   numbered identically.  In the first two cases, the bundled link
   is unnumbered by default;

So, if the *components* are numbered differently, the *bundle* is
unnumbered.  This can of course be overridden by configuration.

> what's the purpose of numbering, if yes, how to advertise. 

Component addresses will not be advertised for *TE* -- that's what
the bundle is for.

How could this situation occur?  Perhaps it is desired for IP
forwarding and regular SPF that each component link is numbered
differently from other components; but for TE, a single bundle
is desired to reduce link state.

> Can you elaborate ?

I tried :-)  Let me know if it helped ....

Kireeti.

---

From: Fong Liaw <[email-masked]>
Date: Thu, 27 Jul 2000 18:40:47 -0700

Yap. It helped.  I assume there is real life
situation that needs it :-) Thanks.

Regards,
-Fong

>  Sent: Thursday, July 27, 2000 6:13 PM
>  To: [email-masked]; [email-masked]; [email-masked];
>  [email-masked]
>  Cc: [email-masked]
>  Subject: RE: Link Bundling
>  
>  
>  Hi Fong,
>