Subject: Re: Draft Minutes from Pittsburgh

From: Kireeti Kompella <[email-masked]>
Date: Mon, 16 Oct 2000 19:26:30 -0700 (PDT)

Hi Bala,

> Yakov Rekhter wrote:
> 
> > Bala,
> >
> >
> > draft-kompella-mpls-bundle does *not* require multiple adjacencies.
> > With draft-kompella-mpls-bundle one *may* create multiple adjacencies
> > if one doesn't want to aggregate information about SRLGs and/or
> > administrative constraints (affinities), or different TE metric.
> 
> I submit that you have to create multiple adjacencies if you want
> to bundle according to link type, SRLGs etc. If you're saying that
> you can ignore these and create a single bundle, I'm afraid you're
> completely ignoring our needs.

Let's take this in two steps: draft-kompella- does not *require*
multiple adjacencies.  It's a choice the user makes.  If they want
a single bundle with mixed link types and SRLGs, they can.  Otherwise
they can create a bundle for each link type and SRLG set.

If the user decides to create multiple bundles, they may choose to do
flooding optimization also.  This is recommended, not required.  In
fact, depending on how you implement bundling and control channels,
flood optimization might not even be necessary.

With your proposal:
1) a user *must* have multiple link groups, even if they don't care
   about separate link types or SRLGs.
2) if a single link group changes, the entire bundle must be
   readvertised.  This is as bad as flooding all the multiple bundles.
   However, the design of link groups offers no scope for optimization 
   analogous to flooding optimization.

> > Your proposal does *not* guarantees only a single adjacency, as if
> > different component links have different administrative constraints
> > (affinities) and/or different TE metric, and aggregation of the
> > administrative constraints is undesirable, then with your proposal one
> > would have to have multiple adjacencies.
> 
> Or multiple link groups within a bundle, thus maintaining a single
> adjacency.

You missed Yakov's point: if ports 1-10 have metric 12, ports 11-20
have metric 15, ports 21-30 have metric 18, you need three bundles.
These cannot be link groups within a bundle, as link groups share the
metric of the bundle.  Same with affinities.

> > In one sentence, because draft-kompella- can do everything that your
> > proposal can do and more. On the other hand, your proposal can do only
> > a subset of what draft-kompella- can do.
> 
> If the first sentence is really the case, we'd be glad to go with your
> proposal. But I'm not convinced this is true.

However, in all of the following, the only thing that you say that
your draft has that ours doesn't is:

> In the end, I see the real need from our part as the ability to
> be more detailed in SRLG specification, plus a grouping of links
> according to link types within a bundle. If your bundling proposal can
> include these features, we'd be happy to endorse it.

There is nothing in draft-kompella- that precludes bundling just
the links that share SRLG sets or link types or whatever.  So, this
draft is clearly a superset of draft-rs-.  The only (non)issue is
flooding.

On the other hand, draft-rs- introduces a new mechanism that adds no
value, has the downside that the flooded information is potentially
much greater (without recourse to optimization), and in the end does
not remove the need for multiple parallel bundles between a pair of
LSRs (OXCs).

Furthermore, draft-rs- is specific to optical links, whereas
draft-kompella- is more general purpose; and while this may be your
stated goal, a more general solution is clearly preferable to a more
specific one.

Kireeti.

---

From: Yangguang Xu <[email-masked]>
Date: Tue, 17 Oct 2000 10:05:07 -0400

Folks,

Our definition for bundle (it's been there for years without being exposed,
sorry for the delay):

"A logical link or bundle is defined as a collection of physical links (link
connections) that share the same attributes (physical attributes and logical
attributes) between two adjacent network elements. Link connections with a
bundle are equivalent for routing purposes. However, the notion of equivalence
is not fixed. The purpose is to balance network operation performance and
control plane scalability. The granularity of bundling can range from physical
tributary to node and even to AS."

Two key purposes for bundling: 1)flooding optimization 2)path selection (the
result of path selection is in bundle level)

Neighbors may need multiple adjacencies (not necessary). For example, two OXCs
have 20 OC48 links and 30 OC192 links between. They may be assigned as two
bundles. Explicit routing should decide which bundle to choose. 

Again, bundle has granularity issue. The control of the granularity is up to
service provider.

Thanks,

Yangguang

---

From: Debanjan Saha <[email-masked]>
Date: Tue, 17 Oct 2000 09:48:24 -0400

Hi Kireeti,

> they can create a bundle for each link type and SRLG set.

The problem is that if the users create a single bundle with mixed link
type and SRLGs as per draft-komplella, all information regarding the
SRLGs and link types are lost. That's clearly not acceptable in our
operating environment. So, it's not  really a matter of choice.

> flooding optimization also.  This is recommended, not required.

draft-rs .. allows you to have the same effect even without flooding
optimization.

> In fact, depending on how you implement bundling and control channels,

Is this going to be yet another draft :-)

>    about separate link types or SRLGs.

Don't know about your application, but it is really important to capture
link type and SRLG information in optical networks.

>    analogous to flooding optimization.

draft-rs.. allows you to create multiple bundles, each containing one (or
more)
link groups. So, this statement is not accurate.

> stated goal, a more general solution is clearly preferable to a more

I will be happy to call draft-kompella a "general purpose" solution when
it can adequately address the requirements for bundling optical links. If
we are really seeking a more general purpose solution, what is your objection
to merging the two drafts and allow for multiple link groups within a bundle.
The users will still have the option to create multiple adjacencies the way
dratf-kompella suggests. They will also have the option to create a single
adjacency the way we prefer.

Regards,
Debanjan

---

From: Bala Rajagopalan <[email-masked]>
Date: Tue, 17 Oct 2000 12:03:50 -0400

Hello,

> they can create a bundle for each link type and SRLG set.

If you read our draft carefully, the requirement is NOT to mix link types
and SRLG information.  I don't want to create multiple bundles
(and hence adjacencies) doing this. The bottom line is,  your
proposal does not support this. The only way to do this under your
proposal is to necessarily create multiple bundles, and then incur
the added complexity of flooding opt. This is the point I'm trying
to communicate.

>    analogous to flooding optimization.

Our proposal addresses specific requirements as outlined in the
draft. So, your point (1) is of no relevance. Furthermore, (2) is
a weak point. Advertising an entire bundle vs just a link group
that's bundled separately doesn't change the frequency, but the
size of LSAs.  And, the whole idea is that I don't want to
implement an OSPF flooding opt. just to support bundling.

> metric of the bundle.  Same with affinities.

You're generalizing too much here, beyond our requirements. In any case, if
such metrics are needed, then link groups can be formed based on the
metric.

> > include these features, we'd be happy to endorse it.

But this is the point of our draft!

> draft is clearly a superset of draft-rs-.  The only (non)issue is

At the risk of being repetetious, we're not denying that you could
bundle based on any criterion using draft-kompella. All we're saying is
that we don't want to create  multiple adjacencies doing this. It's a
simple matter of adding link groups to your bundling proposal and
we'll be happy.

> not remove the need for multiple parallel bundles between a pair of

draft-rs addresses a specific set of requirements. Whether that adds
"value" is subjective, depending on what the application is. To us, your
draft (+ flooding opt, multiple unnumbered link support)
doesn't give the value for the amount of work involved in implementing
it in the specific environment we're interested in. Your last statement about
multiple bundles is not true at all in the environment described in our
draft.

> stated goal, a more general solution is clearly preferable to a more

Preferrable to who? A solution that addresses the problem in
our specific environment in a circuitous way is not very exciting
for us, just because it addresses bundling in the genereal MPLS
environment also. The essential idea of our draft is to describe
the specific requirements in optical networks. In fact, some of
the requirements you have incorporated in your draft are not
important to us, and the way bandwidth is described in your
proposal is not natural for our application. We're willing to
put up with all this if you can add link groups as a feature.
I think this is a reasonable compromise.

regards,
--

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]