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