Subject: LAst Call: draft-ietf-mpls-bundle-04.txt

From: Loa Andersson <[email-masked]>
Date: Thu, 29 Aug 2002 08:31:26 +0200

OSPF and IS-IS working groups, (mpls wg for info)

the iesg has started the review of the mpls working group draft
draft-ietf-mpls-bundle-04.txt. The immediate response from the iesg
is that the draft contains OSPF and ISIS related details (see
the included mail). After discussing with the wg chairs for ospf
and is-is working groups, there is a feeling that the two weeks
the iesg allocated for this last call might not be enough, since the
draft has not been widely circulated in the routing working groups.

Therefore:

This is to initiate a last call for the

<draft-ietf-mpls-bundle-04.txt>

by the ospf and is-is working groups.
The last call ends September 22nd at 12PM CET

Please include the mpls mailing list ([email-masked]) in your responses.

/Loa (co-chair of the mpls wg)

-------- Original Message --------
Subject: draft-ietf-mpls-bundle-04.txt
Date: Tue, 27 Aug 2002 15:06:48 -0400 (EDT)
From: Scott Bradner
To: [email-masked], [email-masked]

The IESG discussed this ID last week during its teleconference
one issue was raised during the discussion

"the draft contains OSPF & ISIS
related details and I don't remember it being LC'ed or reviewed
in the corresponding WGs."

can you start a 2 week last call on the IS-IS and OSPF mailing
lists for this document?

Scott

-- 
     Loa Andersson
     Chief Architect,
     Utfors Research, Architecture and Future Lab (URAX)
     Utfors AB
     Råsundavägen 12
     Box 525, 169 29 Solna
     Office          +46 8 5270 2000
     Office direct   +46 8 5270 5038
     Mobile          +46 70 848 5038
     Email           [email-masked]
     WWW             www.utfors.se

---

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 29 Aug 2002 19:10:18 -0400

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.

---

From: "Reddy, Vikram" <[email-masked]>
Date: Fri, 30 Aug 2002 05:41:43 -0400

Please see inline.

Vikram.

-----Original Message-----
From: Naidu, Venkata [mailto:[email-masked]]
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:

Link Types Restriction
----------------------

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.

Metric Restriction
------------------

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.

Again, same reason as above. We  should not aggregate component links having
different protection types into a single Bundled Link.

SRLG consideration
------------------

DiffServ consideration
----------------------

  Thank You.

--
Venkata.