[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 JL,

Thanks for the comments.

>
> -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...
AA----------> The intention was actually to show a case where ERO contains
FA-LSP or LSP segment TE link address (as you have described above) in
which case, contiguous LSP would not be setup. Looks like the part
stating this got edited out somewhere along the line. :-(
            Also, I agree with you that in that case the ERO would either
contain numbered or unnumbered TE link address corresponding to FA-LSP or
LSP segment. So we will fix the ERO in the above case to explain this
scenario. Thanks for pointing this out.

> 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...
AA-----> You mean in the ERO processing discussion, right ? Will do.


> -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...
AA--------> Makes sense.


> -In section 6.2 the FRR considerations described in 6.1.3 for stiching
> and nesting, actually also apply to GMPLS Segment Recovery.
AA-------> Okay...but mechanisms are different.

> -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...
AA------> Since, as you said it is a path computation issue and it doesn't
directly cover any signaling extension, it was deliberately left out of
this ID. It is mentioned in the pd-path-comp ID.

> -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]
AA----> Okay. Will fix.

thanks,
-arthi

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