Subject: Re: draft-gray-mpls-rsvp-oif-uni-ext

From: Kireeti Kompella <[email-masked]>
Date: Wed, 20 Sep 2000 12:20:11 -0700 (PDT)

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.

> An even better idea would be to have a single draft that 
> covers all (read most) TE issues.

I disagree entirely.  Small, focused drafts are much easier to
handle and update, especially if they are standards track.  An
informational RFC that covers TE and depicts the grand picture,
saying how the various pieces fit together, is a fine idea.

Kireeti.

---

From: Debanjan Saha <[email-masked]>
Date: Wed, 20 Sep 2000 16:35:31 -0400

Hi Kireeti,

> and the choice of the link group is up to the node containing the

How do you define a bundle? Is there an (virtual) interface (control
channel)
associated with a bundle? If yes, then your approach would mean that
there will be m times
more (control) traffic between the nodes since each LSA will be
advertised m times
on m different interfaces/control channels.

Our draft pre-dates the unnumbered TE draft and one our objectives was to

save IP addresses by having a single bundle containing all links between
a pair
a of nodes and having link groups to capture link type and SRLG
information. Note that
we don't preclude multiple bundles between a node-pair, but  in our
approach you don't
need to create multiple bundles even if you have different link types
and/or SRLGs between
a node-pair. I agree that with the unnumbered TE draft it may be less of
an issue.

> saying how the various pieces fit together, is a fine idea.

That would be fine with me too. My point is that without  a "grand
picture draft"
it is difficult  to make sense out of various pieces.

Regards,
Debanjan

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 20 Sep 2000 14:51:08 -0700

Debanjan,

> on m different interfaces/control channels.

Advertising the same LSA over each control channel would be
fairly unwise thing to do (to say the least). Please look
at draft-zinin-flood-opt-00.txt on how to avoid doing this.

> a node-pair. I agree that with the unnumbered TE draft it may be less of

So, how about if we consider the issue closed.

Yakov.

---

From: Debanjan Saha <[email-masked]>
Date: Wed, 20 Sep 2000 17:45:27 -0400

Yakov,

> at draft-zinin-flood-opt-00.txt on how to avoid doing this.

I know that it is unwise and that is the point I am trying to make.
I am aware of the draft you mention, I was not sure that it was
also a part of the "bundling drafts" bundle :-)

> So, how about if we consider the issue closed.

How do you propose to close it?
Debanjan

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 20 Sep 2000 15:24:36 -0700

Debanjan,
 
> also a part of the "bundling drafts" bundle :-)

I guess you are aware of this now :-)

> How do you propose to close it?

By considering it closed :-) In other words, there is no need for
draft-rs-optical-bundling-00, since the *practical tecnical* concerns
that motivated this draft have been already addressed.

Yakov.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 20 Sep 2000 19:50:24 -0400

> a node-pair. I agree that with the unnumbered TE draft it may be less of

One thing that your draft offers that may be an advantage is the
ability to specify groups with differnet SRLG sets within a bundle.  I
say "may" for two reasons.  First the bundle already inherently shares
an SRLG in that the bundle passes through the same switch (unless
switches are believed to be sufficiently reliable that we don't
configure SRLGs for them).  Second, is that it may be a while before
the use of SRLGs gets that sophisticated that it matters.  The second
isn't a very good reason, but might be very true anyway.

I think we should consider the draft-rs-optical-bundling-00 to no
longer be of use.  The two ideas it brings are the above and separate
groups of differing bandwidth within the bundle.  The latter is not
needed since you can just advertise the largest single LSP that can
currently be made (given the links that remain available).

> it is difficult  to make sense out of various pieces.

That's why we're having some of these discussions on the list and some
off.  I just had a very useful (for me) discussion off list with Yakov
on this sort of grand picture topic.  I've included some highlights
below.

> Debanjan

Curtis

ps - Summary of conversation end state with Yakov (and some of the LMP
authors).  This is just the condensed outcome of a long thread (unless
I got something wrong or Yakov has any further clarifications).

Here is how LMP, bundles, generic IGP signaling, generic RSVP
signaling, fit together in a small example.

 1.  The routers and PXCs figure out what adjacencies they have using
     LMP including information about port mapping on adjacent devices.

     They advertise all adjacencies to a given peer as a bundle with
     link mux LSC ala draft-kompella-mpls-bundle-02.txt.  (Note: A
     link from PXC to PXC is LSC. A link from PXC to a router is LSC.
     A link from a router to PXC is SONET or whatever.)

 2.  If a router needs capacity to a given router and a set of LSC
     bundles (where each link may, or may not be a bundled link) are
     available, an ERO can be set up with the hops specified as links
     (or even a loose hop if it is thought better to let the switch
     make path selections through the optical domain).  As many LSP as
     are needed are set up this way.  The router can advertise a link
     (where the link may or may not be a bundled link) of type PSC-1.

     The request for a path through a set of LSCs is covered in
     draft-ashwood-generalized-mpls-signaling-00.txt.  The hops in the
     ERO would have Encoding Type 9235, Photonic Lambda except the
     last hop which would have some other type.  The last hop is most
     likely to be SONET or GigE.
     
 3.  LSR that are beyond the optical domain can use the PSC-1 tunnels
     that cross the optical domain as if they were unidirectional IGP
     links.

I think the only thing we were not too clear on was how the bundles
were advertised.  I think it makes sense for the router to advertise a
bundle that points to the switch and is of type SONET and the switch
to advertise a bundle that points to the router of type LSC.  The
switch after all can't terminate SONET it just deals with lambdas.  In
the IGP there would be an adjacency of type LSC on one side and SONET
on the other.  The path setup could occur if the egress bundle type
was the same as the ingress and the bundles in the middle were
compatible (all LSC in this example).

Note: If the switch has TDM capability substitute TDM for LSC on the
bundle type and T1 or whatever for SONET in the ERO or RRO.

This is a short example rather than an internet-draft but I found it
useful.

---

From: Bala Rajagopalan <[email-masked]>
Date: Fri, 22 Sep 2000 11:48:55 -0400

> and the choice of the link group is up to the node containing the

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: [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 22 Sep 2000 13:59:58 -0400

> 3. draft-kompella-mpls-unnum-01.txt for specifying component

IMHO 2 is not required therefore your more complex bundling scheme
adds litte or no value.

A single bundle can be applied.  Under what conditions do you see a
disadvantage to appying a single bundle?

Curtis

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 22 Sep 2000 10:54:51 -0700

> there are multiple bundles between the same pair of nodes.

Just a factual observation here: this draft has couple of protocol breaking
procedures in it in rev 00 ( I commented to Alex & Mike ) and will need at least another
major rev before being sane. However, conceptually it works and proof of viability
exists as well for it (PNNI did that optimization).

    thanks

    -- tony

---

From: Bala Rajagopalan <[email-masked]>
Date: Fri, 22 Sep 2000 14:27:04 -0400

Curtis:

This is what Yakov said:

> (yakov) Advertising the same LSA over each control channel would be
> (Debanjan) I know that it is unwise and that is the point I am trying
to make.

>(yakov) I guess you are aware of this now :-)

And, I don't see why our proposal is any more "complex". It's different,
I agree. It's not something you prefer, that's also clear (although you
don't
explain the reason very clearly).

> disadvantage to appying a single bundle?

If I can use a link mgmt. protocl for my control channel management and
let the routing protocol see a single interface to the neighbor,
why should there be more than one bundle between neighbors?

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: [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 22 Sep 2000 15:01:09 -0400

> > at draft-zinin-flood-opt-00.txt on how to avoid doing this.

Bala,

I keep forgetting that our system allows multiple OC48 or OC192
interfaces to be concatonated together and treated as a single
interface (Composite Link TM in Avici marketing-speak) and others
don't do this.  Therefore we do not have this a problem wrt multiple
IGP adjacencies over the components of a bundle.  We just do SONET and
PPP over the components and provide the appearance of a single
interface to higher layers.

I think others are doing something similar (Pluris, maybe others).

Curtis

---

From: Bora Akyol <[email-masked]>
Date: Wed, 27 Sep 2000 11:47:35 -0700

I had discussed a similar point to Curtis's over the mailing list (see
archives) with Kireeti a while back. For routers that are capable of link
aggregation (IP Bond TM, Pluris marketing) some of the complex solutions are
really not required. I know that Avici does something similar as well.

If one subscribes to the UNI model, then the concept of "bonding" works very
well with the UNI model for signaling and bandwidth can be added and
subtracted successfully.

Bora