The MPLS WG Archive

[Yakov Rekhter <yakov@cisco.com>]

Bala,

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

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.

> Now, the bundling scheme proposed in our draft addresses
> 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.

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

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.