The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] LAst Call: draft-ietf-mpls-bundle-04.txt
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. |
|