Subject: New WG draft [Was: Fw: I-D ACTION:draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt]

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Jan 2005 12:52:02 -0000

Hi,

After discussions on the list, Arthi and JP have split the interdomain
signaling draft into two. The first (this draft) describes the options for
interdomain signaling. The second (coming any moment) is specific to
stitching.

I think we had agreement on the content of the original draft, and
agreement to make WG drafts once the work was split.

This email is to give you a brief chance to object. Comments before 7th
February please.

Cheers,
Adrian

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 27, 2005 8:53 PM
Subject: I-D ACTION:draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : Inter domain MPLS Traffic Engineering - RSVP-TE extensions
> Author(s) : A. Ayyangar, J. Vasseur
> Filename : draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt
> Pages : 17
> Date : 2005-1-27
>
> 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-ayyangar-ccamp-inter-domain-rsvp-te-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] 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-ayyangar-ccamp-inter-domain-rsvp-te-02.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:
> [email-masked].
> In the body type:
> "FILE
/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-te-02.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.
>

--------------------------------------------------------------------------
------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

---

From: [email-masked]
Date: Fri, 28 Jan 2005 18:26:36 +0100

adrian,

o) the sentence "The signaling procedures described in this document are applicable to both packet LSPs (RSVP-TE) and non-packet LSPs that use RSVP-TE GMPLS extensions as described in [RSVP-GMPLS]" is ambiguous, GMPLS RSVP-TE covers packet LSPs

o) section 6 is a bit difficult to parse as i read it FRR wholy taken into account for multi-domain LSP signaling however paragraph 6.2 introduces a requirement on a mechanism it does not cover (i.e. it imposes a constraint on GMPLS LSP recovery mechanisms) - so is it the right place to introduce such requirement ? - now the more basic issue is why these two modes have different precedence level in the context of this document ? - i would like also to recap that the CCAMP WG is developing a method referred to as segment recovery which is also applicable in the present context (why is this not taken into account) ?

o) a third point concerns the relevance in re-detailing part of the base LSP re-optimization as part of this document (as it is already part of the re-optimization document - that should tackle the issue of non-disruptive re-optimizations for circuit LSPs such as TDM and LSC) and not focus on the multi-domain specifics - example tackling multiple domain re-optimizations at a time -

imho - addressing these points should not block progress of this document

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
01/28/2005 12:52 GMT
Please respond to "Adrian Farrel"

To: <[email-masked]>
cc:
bcc:
Subject: New WG draft [Was: Fw: I-D ACTION:draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt]

Hi,

Cheers,
Adrian

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 27, 2005 8:53 PM
Subject: I-D ACTION:draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt

directories.
the message.
username