Subject: RE: Draft Minutes from Pittsburgh

From: John Drake <[email-masked]>
Date: Thu, 5 Oct 2000 15:24:23 -0700

Debanjan,

I remember George making this statement as his assessment of the
presentations and subsequent discussion, and I don't remember anyone
challenging George on it.

Thanks,

John

-----Original Message-----
From: Debanjan Saha [mailto:[email-masked]]
Sent: Thursday, October 05, 2000 4:10 PM
To: George Swallow
Cc: [email-masked]
Subject: Re: Draft Minutes from Pittsburgh

> 3.  Bundling

  < stuff deleted>

> Kompella    kompella-mpls-bundle-02
> Saha        rs-optical-bundling-00
> 
   < stuff deleted >

> After a brief discussion, it was agreed that there was general
> consensus on using the approach outlined in the kompella draft without
> adding sub-bundles.  New drafts for the appropriate work groups will
> be drafted.
> 

I don't remember any such consensus on using the approach outlined
in the kompella draft.

Regards,
Debanjan

-- 
Debanjan Saha                         Phone: 732-923-4264
Senior Network Architect              Fax:   732-923-9804
Tellium Optical Systems               http://www.tellium.com

---

From: Bala Rajagopalan <[email-masked]>
Date: Thu, 05 Oct 2000 19:40:59 -0400

Hello,

It's hard to recall what exactly happened, but we do believe
that this topic deserves further discussion. Especially since
previously unstated support for OSPF flooding optimization
are now part of the overall picture of bundling proposed
by draft-kompella. I hope we can do this in the upcoming
meeting.

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: George Swallow <[email-masked]>
Date: Wed, 11 Oct 2000 18:09:42 -0400

Bala -

> It's hard to recall what exactly happened, 

My own recollection agrees exactly with what Francois captured in the
minutes and John Drake stated on the list.  So consensus was reached.

> but we do believe

We're always open to further discussion.  I would suggest that you not
wait until December for it.  The list is a fine place for such a
discussion.  

In the mean time we also need to make progress.  So the consensus we
reached is the consensus.  It can be revisited of course.  But as far
as progessing drafts, I'm expecting the authors of the kompella draft
to issue a draft with just the signalling aspects as a WG draft or
drafts depending on whether they decide to have a single document or
one for each of RSVP and LDP.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Bala Rajagopalan <[email-masked]>
Date: Thu, 12 Oct 2000 10:10:33 -0400

Hello,

> wait until December for it.  The list is a fine place for such a

I agree.

> one for each of RSVP and LDP.

This statement is contradictory. If we're going to revisit, why issue a
working group draft before finishing the discussion?

W.r.t consensus, I don't believe enough information was available
at the last meeting to make a decision on proceeding with the Kompella
draft as a WG draft, specifically, the need for flooding optitimization
with the propsoed bundling approach. I don't mind if a decision on this
is made after another round of discussions on the mailing list prior to
the next meeting.

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: Mon, 16 Oct 2000 12:05:49 -0400

> is made after another round of discussions on the mailing list prior to

Bala,

I remember there being consensus at Pittsburgh on making the Kompella
bundles draft a WG item.

Use of the flooding optitimization is one means of improving the
efficiency of the IGP and is a separate issue.

Both the bundles and the flooding optitimization can stand alone.
Neither one depends on the other.  If used together they may
complement each other but use of either one separately is possible and
useful.

I don't see that any changes are required to the bundles draft to
accommodate the flooding optitimization.  If changes are required,
please point them out.

Curtis

---

From: Alex Zinin <[email-masked]>
Date: Mon, 16 Oct 2000 10:30:08 -0700

Agree 100%.

We have 3 techniques that are somewhat related, but yet orthogonal:

1. Link bundling
2. Control channel[s] for link bundles (LMP)
3. IGP flooding optimizations

Link bundling allows to summarize the TE information.
LMP allows to minimize the number of adjacencies per bundle
(note that LMP will not have to be implemented on each type
of links), and flooding optimizations minimize overhead traffic
over parallel adjacencies.

Alex.

---

From: Bala Rajagopalan <[email-masked]>
Date: Mon, 16 Oct 2000 15:58:42 -0400

Hello,

I agree that bundling and flooding optimization are separate
mechanisms. But if a particular bundling scheme necessarily results in multiple
adjacencies, then flooding optimization would be adviced. Of course,
a claim can always be made that flooding opt. is optional and
orthogonal, but if it is not used in this case, I don't see its utility.
Thus, IMO, draft-kompella-mpls-bundle... creates a neccesity
for flooding opt.Furthermore, this bundling approach
requires the support for multiple unnumbered links (bundles),
(i.e., draft-kompella-mpls-unnumbered-xx.txt.)

Now, the bundling scheme proposed in our draft addresses
SRLG-based bundling, and it results in a single adjacency.
For optical network applications, this obviates a need for
any type of flooding optimization. And, there is no need to
support extensions for multiple unnumbered links. In esssence,
the simple device of link groups eliminates the need for two
other extensions, one in routing, another in signaling.

Other than this, the parameter descriptions in our draft are
pretty straightforward, link type descriptions that suit SONET
link types.

Our bundling proposal doesn't preclude the use of separate
bundle for each link group (along with support for
flooding opt., and multiple unnumbered bundles). In this sense, our
proposal is more flexible. I really don't
see why there should be an objection to it.

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: Yakov Rekhter <[email-masked]>
Date: Mon, 16 Oct 2000 14:07:22 -0700

Bala,

> mechanisms. But if a particular bundling scheme necessarily results in 
> multiple adjacencies, then flooding optimization would be adviced. Of 
> course, a claim can always be made that flooding opt. is optional and

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.

> SRLG-based bundling, and it results in a single adjacency.

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.

> see why there should be an objection to it.

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.

For more details see below:

1. Your proposal doesn't have the needed information.
   For example, it doesn't have Max LSP b/w per priority.  Another
   example, your proposal doesn't say how signalling could pick up a
   component link within a particular link group.

2. Your proposal introduces duplication information (information 
   already present elsewhere, like Link Encoding Type, min reservable b/w, 
   max reservable b/w (already present in draft-isis-gmpls-extensions-00.txt)

3. Your proposal results in flooding of information that doesn't change
   (as when change occurs within just one link group, the whole bundled
   link that includes all the link groups is flooded), thus creating
   (for no good reasons) an additional load on the routing system.

4. Your proposal doesn't eliminate the need to implement reducing 
   flooding (via flood optimization), as we need to allow for 
   multiple bundled links between a pair of LSRs. 

5. Your proposal doesn't support bundling of non-optical links.

Yakov.

---

From: Alex Zinin <[email-masked]>
Date: Mon, 16 Oct 2000 14:26:14 -0700

Bala,

In addition to what Yakov said, I wanted to emphasize that
draft-kompella-mpls-unnum introduces a generic mechanism
(not specific to link bundles) to perform announcement of
and LSP signaling across unnumbered links, which is
necessary regardless of whether you bundle or not.

-- 
Alex Zinin

---

From: Bala Rajagopalan <[email-masked]>
Date: Mon, 16 Oct 2000 17:51:34 -0400

Hello,

I'm glad we're getting into some substantive debate on this.
Sorry if there is any repetetion below.

> 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.

> would have to have multiple adjacencies.

Or multiple link groups within a bundle, thus maintaining a single
adjacency.

> 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.

>    component link within a particular link group.

I agree. The priority feature hasn't been a priority for us so far. But
this is just a matter of adding a field in link groups (our need will
be to distinguish between working and "extra" traffic only, not
a range of priorities). Anyway, this doesn't argue against
having link groups. As far signaling, yes, the draft omits to mention that
the ERO must carry the advertised link group id for each hop.

>    max reservable b/w (already present in draft-isis-gmpls-extensions-00.txt)

I don't understand this point. Link encoding has  been defined elsewhere
(source referenced), and max and min are also described  by the encoding type
(i.e., values such as oc-48, etc) in our draft. Anyway, we're defining the
usage of these parameters in bundling.

>    (for no good reasons) an additional load on the routing system.

As we note, the frequency of flooding doesn't change, whether you
bundle a link group as a separate bundle or include it as part of a
larger bundle. The size of announced information increases, but
it doesn't seem to be a practical concern with optical link types
(which are few).

>    multiple bundled links between a pair of LSRs.

If you do maintain multiple bundles (by not capturing all the information
in link groups), yes, flooding must be reduced. But you don't have to
have multiple bundles.

> 5. Your proposal doesn't support bundling of non-optical links.

This may be the case for some features, but our draft's
title is indeed  "Link bundling in optical networks".

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.

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: Bala Rajagopalan <[email-masked]>
Date: Mon, 16 Oct 2000 17:54:54 -0400

Hi,

As with flooding opt., I agree that draft-kompella-mpls-unnum
introduces a useful mechanism independent of bundling.
My point was that it may become a necessity when multiple
bundles are formed between neighbors and several of them
are unnumbered. From the point of view of installing only
the minimum set of capabilities, I don't want to implement
another mechanism in my OXCs to support  bundling.

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]