RE: Component Link Recording for TE Link Bundles (draft-zamfir-ex plicit-resource-control-bundle-01.txt has been updated)

[Anca Zamfir <ancaz@cisco.com>]

Hi,

Based on our initial thoughts and the feedback received from you so far,
I am summarizing below the list of requirements that should be made clear
in this proposal and that will be included in the next version.

TE Link bundling is a mechanism proposed in draft-ietf-mpls-bundle-04.txt
with the purpose of reducing the amount of TE specific routing
information within an IGP-TE domain. With this mechanism, a number of
physical and/ or logical links are presented as a single TE-link to all
participant nodes and typically the decision and knowledge on which
resources (component links and labels) are used for a given LSP is left
as a local decision.

However, there are cases when more information or control over used
resources may be needed for a non-local node. The following cases require
the component link information to be propagated to a non-local/ head
node.
- As in the case of Labels, a network operator wishes to retrieve from a
head node information about the resources taken by an LSP and use this
for diagnostics or further network planning. One way to achieve this is
to perform component link route recording as in our proposal.
- Also, a network operator desires to enforce a given resource allocation
for a segment of an LSP or set of LSPs that span a bundled link. This
can be done by using the ERO proposal part of the draft.

Items that were brought up that are not covered by this proposal
are:
- Component Link failure notifications or PathErr -- feedback from John:
if some the requirement for this is clarified, a new ErrorCode may be
acceptable.
- Protection mechanisms within a bundle -- feedback from John: cover this
in span protection work item.

Other input we will incorporate in the next version (coming from
Adrian):
- rewrite the Introducation section to make it more readable and provide
clear scope of the problem the proposal is trying to solve.
- correct the 'Sub-IP Id Summary' to read "This draft is targeted at
CCAMP WG....."

Please let us know if you have any further comments or if anything was
missed.

Thanks,
the authors.

At 01:38 PM 10/23/2003 -0700, John Drake wrote:

"urn:schemas-microsoft-com:office:office">
Private note

-----Original Message-----

From: Vishal Sharma [mailto:v.sharma@ieee.org]

Sent: Wednesday, October 22, 2003 3:28 PM

To: zafar ali; ccamp@ops.ietf.org

Cc: ancaz@cisco.com; Dimitri.Papadimitriou@alcatel.be; 'Adrian Farrel'; 'Kireeti Kompella'

Subject: RE: Component Link Recording for TE Link Bundles (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated)

Hi Zafar,

 

Thanks for your note. Although I've not had an opportunity yet to look at the most

recent version of the document, I have read through the previous version, and think

the idea of recording component link information in the RRO is useful in several

contexts:

 

i) Disseminating the component link information to the edge nodes (and provider

NMSs) can be very useful for restoration. E.g. when a failure that affects only

a small subset of LSPs occurs (as opposed to a fiber cut or link failure that

affects all LSPs in the bundle), it would be valuable to send the component

link info. in the Notify (or equivalent) message and have the end node(s) recognize it

and take corrective action.

 

 

JD:  The whole point of bundled links is to hide infomation for scalability.  The end nodes

would not know what to do with component link information if they were to get it.  In the

absence of bundled links, an ingress node can exclude a failed node or link from its CSPF

using the information contained in Path Error or Notify in the interval before it receives the

LSA describing the failed node or link.  In the presence bundled links, a new error code

indicating 'component link failure' could be added to Path Error or Notify.  This would

allow an ingress node to NOT exclude the bundled link with the failed component link

in the interval before it receives the LSA describing the bundled link's reduced bandwidth.

Also, the nodes that experienced the component link failure will know exactly what is

going on and will be able to communicate directly with the NMS.  Putting component

link information in Path Error or Notify does not change this in any way.

 

 

ii) By extension, it would be useful for a provider to know that a partial failure

of the bundle has occurred, and to be able to identify which component has failed.

This could be useful in on-line/off-line path selection and CSPF.

 

 

JD:  See above.  Component link information is expressed in the link state database

as a given bundled link having more or less available bandwidth. 

 

 

iii) I also think that the semantics defined to identify the component link can be

useful in an of themselves, as they  may be usable by other mechanisms/methods that

rely on disseminating component link failure info. to various nodes in the network.

 

 

JD:  We don't want nodes in the network to know about component links!  Note that I

am in favor of adding component link information into the ERO to handle the case of

a neurotic network operator that wants complete control of their network - this is why

explicit label was added and component link information completes this.

 

 

BTW, I'm not sure if you've seen Nic Neate's post on MPLS and CCAMP yet, but

it seems some of what you've proposed is related to or may partially address

what he's proposing (but I need to think a bit more carefully about that).

 

-Vishal

-----Original Message-----

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of zafar ali

Sent: Monday, October 20, 2003 9:48 AM

To: ccamp@ops.ietf.org

Cc: 'zafar ali'; ancaz@cisco.com; Dimitri.Papadimitriou@alcatel.be; 'Adrian Farrel'; 'Kireeti Kompella'

Subject: Component Link Recording for TE Link Bundles (draft-zamfir-explicit-resource-control-bundle-01.txt has been updated)

Dear Ccamp'ers:

 

This is a follow-up on our AI from last ccamp WG meeting on the above-mentioned ID. We don't think the crux of this ID came across right, during the presentation and the follow-up questions and answers. As Zafar mentioned during the ccamp wg meeting discussions, this ID mainly addresses problem that exists in the RRO. Specifically, when TE links are bundled, identification of label resource in RRO is not enough for the administrative purpose. Network service providers would like to know the component link that is being used by a given the LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along the TE link identifier and Label.

 

In current specification, we cannot record component link selected by an intermediate node in the RRO, which posses an administrative deficiency. The ID mainly addresses this shortage by defining the extensions to RSVP-TE to specify component link identifiers for resource recording in a network containing TE link (a.k.a. link bundles).

 

This is true that the ID also defines the ERO counter-part. It seems from our last meeting discussions that one shall try to maintain as symmetry between the ERO and RRO definitions as much as possible. Nonetheless, the ERO definition also addresses a current deficiency in the standard definition. Specifically, explicit resource control for bi-directional LSP when forward and reverse legs of the LSP are to follow different component links within a TE bundle is not possible using current specification. But for the time being, this is not the main motivation behind this ID.

We think that during the CCAMP WG meeting, somehow everyone was commenting on the practically of the ERO counterpart. But as Zafar also mentioned in the question answer session that it is unfair to discuss merit and fate of this ID based on the ERO extensions contained herein.

In the light of the above, we would like the WG to discuss the ID based on its merit and applicably to resource recording in a network containing bundled TE link. Clearly, the proposed RRO extensions are a useful tool for administrative purpose.

 

N.B. We have also updated the ID, based on comments during last Ccamp WG meeting; An updated copy will be available at IETF Web site in a couple of days. In the mean time, a mirror version of the ID can be viewed at, http://psg.com/~dpapadimitriou/draft-zamfir-explicit-resource-control-bundle-02.txt.

 

Comments on usefulness on Component Link Recording for TE Link Bundles will be very much appreciated.

 

Thanks

 

Regards... Anca, Zafar and Dimitri.

 

=====================================================================

Zafar Ali, Ph. D.       100 South Main St. #200,

Technical Leader,       Ann Arbor, MI 48104, USA.

Cisco Systems.       (734) 276-2459.

=====================================================================