[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
Hi Arthi, JP
A few comments on this draft:
-In section 5.2, I'm not sure that path p3 is a valid one:
"RO-X1-ASBR1(loose)-ASBR4(strict)-ASBR7(strict)-ASBR9(loose)-R6.
What does ERO sub-objects for ASBR4 and ASBR5 represent?
Actually this cannot be an interface or router id, because the ERO would be invalid (cannot be strict as ASBR4 and ASBR7 ar not directly connected). The only way to proceed in this way is to include ERO-sub-objects corresponding to FA-LSP or LSP-Segment TE-links (numbered or unnumbered tunnel interface id).
One could assume that RO would obtain such ERO including FA-LSP or LSP-segment as a result of a PCE based compuation...
On receip of a Path message the ERO subobject would allow to directly determine the underlying FA-LSP or LSP-Segment...
By the way it would also be good to ilusrate the case of abstract nodes, e.g. a path made of AS number ERO subobjects...
-It would be good to add some text related to failure detection, at the end of 6.1.3. In case of stitching or nesting, the PLR could rely on BFD-MPLS so as to rapidliy detect FA-LSP/LSP-Segment tail-end failure. This would help ensuring fast recovery...
-In section 6.2 the FRR considerations described in 6.1.3 for stiching and nesting, actually also apply to GMPLS Segment Recovery.
-Section 7 would benefif from some words on global reoptimization (ie with change of border routers)
Even if this is more a path computation issue this may have some impact on signaling...
-And two minor edits
Section 5.1.1: issue with B3 path, in the figure ASBR6 and ASBR7 are not connnected.
Section 8: [INTER-AS-TE-REQ] instead of [INTER-AREA-TE-REQS]
Hope this helps,
Best Regards
JL
> -----Message d'origine-----
> De : owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] De la part de
> Internet-Drafts@ietf.org
> Envoyé : mardi 19 juillet 2005 21:50
> À : i-d-announce@ietf.org
> Cc : ccamp@ops.ietf.org
> Objet : I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Common Control and
> Measurement Plane Working Group of the IETF.
>
> Title : Inter domain GMPLS Traffic
> Engineering - RSVP-TE extensions
> Author(s) : A. Ayyangar, J. Vasseur
> Filename : draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
> Pages : 17
> Date : 2005-7-19
>
> This document describes extensions to Generalized
> Multi-Protocol Label Switching (GMPLS) Resource ReserVation
> Protocol - Traffic Engineering
> (RSVP-TE) signaling required to support mechanisms for the
> establishment and maintenance of GMPLS Traffic Engineering
> (TE) Label Switched Paths (LSPs), both packet and non-packet,
> that traverse multiple domains. For the purpose of this
> document, a domain is considered to be any collection of
> network elements within a common realm of address space or
> path computation responsibility. Examples of such domains
> include Autonomous Systems, IGP areas and GMPLS overlay networks.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-dom
> ain-rsvp-te-01.txt
>
> To remove yourself from the I-D Announcement list, send a
> message to i-d-announce-request@ietf.org with the word
> unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login
> with the username "anonymous" and a password of your e-mail
> address. After logging in, type "cd internet-drafts" and then
> "get draft-ietf-ccamp-inter-domain-rsvp-te-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE
> /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant
> mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>