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
Please see inline. Vikram. -----Original Message----- From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com] Sent: Friday, August 30, 2002 4:40 AM To: 'Loa Andersson'; ospf wg; isis-wg Cc: MPLS wg Subject: RE: 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 think the section above talks of the property of the component link itself. When you say "all the links along the path", you are probably referring to FA LSPs advertised as component links. In this case, the draft says that all the component links bundled must have the same link type, i.e All the FA LSPs bundled must be point-to-point LSPs (with same LERs) or all of them must be point to multipoint LSPs (with same LERs). It should not matter if the individual links in the LSP are all the same 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. The Link Type restriction is not because of the ability or lack thereof of to advertise in a particular TLV. It has more to do with the practical applicability and in the realization in the physical layer of multiplexing and demultiplexing. For example, It is not possible to multiplex as SONET/SDH and demultiplex it as packets or wavelenghts. Therefore there is the requirement that both ends of the link must be of the same type. *** 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? IMO, there is no need for a router to do this. The reason for Link Bundling is to reduce redundant information getting into and flooding the TE database. But we have to aggregate only to such a level that the properties of the individual links are not lost in the aggregation. In the example you gave above, the router should not aggregate component links having different TE metrics in the same bundle. *** 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? Again, same reason as above. We should not aggregate component links having different protection types into a single Bundled Link. 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. |
|