The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Sep> msg00310



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

bundling

  • From: Bala Rajagopalan <braja@tellium.com>
  • Date: Fri, 22 Sep 2000 11:48:55 -0400
  • CC: mpls@UU.NET



Kireeti Kompella wrote:

> Hi,
>
> > > >   draft-rs-optical-bundling-00
> > >
> > > Question posed to the MPLS WG last IETF: do we need this, in view
> > > of draft-kompella-mpls-bundle-02 and the unnumbered TE draft?  As
> > > yet unresolved.
> >
> > I think it will be a good idea to merge all of them into a single
> > draft.
>
> My question at the last IETF MPLS WG was, what does the notion of
> link group add that cannot be accomplished with plain vanilla link
> bundles?  If there are N links that are to be bundled into m link
> groups, what is the advantage of that over just creating m link
> bundles in the first place?  In fact, the latter is cleaner: If
> one has m link bundles, one can specifically address (in an ERO)
> the particular link bundle that one desires; if one has one big
> bundle with m link groups, one can only address the entire bundle,
> and the choice of the link group is up to the node containing the
> bundle.
>
>

I think we should consider the entire solution in both cases,
rather than just the bundling structure. From Yakov's mail, it
seems like the solution you propose requires:

1. draft-kompella-mpls-bundling-02.txt  for bundling description
2. draft-zinin-flood-opt-00.txt for ospf flooding optimization when
there are multiple bundles between the same pair of nodes.
3. draft-kompella-mpls-unnum-01.txt for specifying component
links in ERO

Now, our bundling proposal (draft-rs-optical-bundling-00.txt),
is clearly different in structure, but also based on different supporting

mechanisms. First, with our proposal (2) above is not required.
Instead, we would use a link management protocol to transparently
choose a physical link for control traffic (e.g., OSPF flooding).
OSPF, under our proposal, will see a single
logical interface to the next node. As far ERO specification,
I don't think there is a significant difference one way or other.
With (2) and (3),  you require the specification of a link ID,
whereas under our proposal, we require a link group
ID. We also indicate a path establishment approach which
doesn't require any link group  information in ERO. Finally,
we consider  SRLG-based grouping in addition to other link
characteristics. You don't explicitly mention
SRLGs in (1), but it's not difficult to see how to do this with (1).

In the end, I see the choice of a bundling scheme as a matter of
preference, but the surrounding protocol mechanisms are different.
I would like to leave the choice to the working group as a whole.
Our individual preferences, of course, are clear :-).

Regards,

Bala


--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com



  • Follow-Ups:
    • bundling
      • From: Tony Przygienda <prz@redback.com>
    • bundling
      • From: Curtis Villamizar <curtis@workhorse.fictitious.org>