The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] bundling
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
|
|