[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Looks good.
Please look at the crankback draft (iwata-mpls-crankback) to see if this already meets your needs for reporting component links on PathErr.
 
Thanks,
Adrian
----- Original Message -----
Sent: Tuesday, October 28, 2003 8:30 PM
Subject: RE: Component Link Recording for TE Link Bundles (draft-zamfir-ex plicit-resource-control-bundle-01.txt has been updated)

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.
=====================================================================