Link Bundling comments:

-> This is to initiate a last call for the
->
-> <draft-ietf-mpls-bundle-04.txt>

   All component links in a bundle must begin and end on the same pair
   of LSRs, have the same Link Type (i.e., point-to-point or multi-
   access), the same Traffic Engineering metric, and the same set of
   resource classes at each end of the links.

   A Forwarding Adjacency may be a component link; in fact, a bundle can
   consist of a mix of point-to-point links and FAs.

Link Types Restriction
----------------------
*** Only beginning & ending of the link types are restricted or
*** all the links along the path (from beginning router to end router)
*** are restricted to the same link type?

*** I didn't not understand why we need same link type at the
*** beginning and at the end of the link? Link Type TLV will cover
*** whatever link type at the advertising router side of the link.
*** I didn't see any issue if we have different link types at each
*** side of the link.

*** I request to elaborate these restriction a little bit with
*** a single appropriate diagram (if possible).

*** The use of bundling has very large scope. For example, one can
*** bundle all the VCs in a VP (where each VC is viewed as a different
*** link with its own resources). All such VPs can be bundled/unbundled
*** (depending on the requirements). Still all those VPs will have
*** a same risk-factor (i.e. SRLG). I think, it will be
*** better to mention few example of such uses of link bundling.

Metric Restriction
------------------
*** Why is the same metric restriction? Can a router have
*** the flexibility to decide a different metric for the bundled
*** link (may be independent of all the component links)?

*** For example, a router chooses the largest metric of all
*** component links (just like OSPF area aggregation). Just a
*** a matter of flexibility. If the metrics are different and
*** if we bundle those links did you see any problem?

*** Let is explain an example scenario, where router starts
*** advertising the largest of all links metric as bundled
*** link metric. One the largest component link resources (bw)
*** are completely consumed (crossed some threshold ) then
*** bundled link metric will become the next highest component
*** link metric.

Link Protection consideration
-----------------------------
*** There is no mention about link protection type of the bundled
*** link when component links are of different type?

SRLG consideration
------------------
*** There is no mention about SRLGs of bundled link w.r.t component
*** links. In some situations, failure of one component link may or
*** may not affect other component links. I think, it will be better
*** to mention something about SRLG - that is, all component links
*** in bundled link must have same SRLG (in order to benefit most
*** from bundling). Even if the component links risk factor is independent
*** from each other (ie. different SRLGs) still we can use bundling.
*** Please mention something like that...

Switching Capability consideration
----------------------------------
*** I think the switching capability should be same for all component
*** links in order to use bundling?! Please mention.

DiffServ consideration
----------------------
*** There is no mention about BCs and TE Classes applicability
*** to Link bundling? Do you see any issues w.r.t to the recent
*** diffserv draft (esp interpretation of unserverved bws etc)?

  Thank You.

--
Venkata.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]