headers
Matt Squire | 1 Dec 2003 02:08
Picon
Favicon

Re: ASON RSVP-TE draft to WG doc

Kireeti Kompella wrote:
> Hi,
> 
> Please indicate whether you think that "Generalized MPLS (GMPLS)
> RSVP-TE Signalling in support of Automatically Switched Optical
> Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is
> ready to be a CCAMP WG document.  This call ends Dec 7, 2003 at
> midnight PST.
> 
> A simple 'yes' or 'no' will be sufficient.
> 

Yes.

- Matt
Permalink | Reply | 0 comments |
headers
Stephen J Trowbridge | 1 Dec 2003 18:31
Picon
Favicon

Re: ASON RSVP-TE draft to WG doc

Hi Kireeti,
No.

Some rationale (very high level):
It seems premature, and it is not a good idea to have parallel track
documents in ITU-T and IETF to do the same thing.

In terms of whether it is in Scope, ASON is inherently beyond IETF
scope. It applies to networks where the transport (data) plane is
not necessarily IP. It applies to networks where addresses are not
necessarily IP addresses. It applies to networks where demarcation
and separation are needed in a manner that is not part of how all-IP
networks are built. The requirements inherently come from, or belong
to, ITU-T.

On the other hand, nobody wants to invent a new protocol from scratch
when there are existing protocols that meet many of the requirements.
So we end up with an inherently collaborative activity between ITU-T
and the protocol experts in ccamp to try to design the best way to
apply or extend the protocol to meet the additional ITU-T requirements.
Not only has there been a lot of (not always successful) communication
between the two organizations to do this, but a lot of the same
individuals have been involved in the work in both places (which has
been somewhat more successful).

What we have existing is ASON requirements and architecture in G.807 and
G.8080.
We have in IETF RFC 3471 and 3473 to cover GMPLS signaling (generic and
RSVP-TE specific).
We have in ITU-T G.7713 and G.7713.2 to cover ASON signaling (protocol-
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg Bernstein | 1 Dec 2003 19:41
Picon
Favicon

RE: spc connections

Hmm, sorry not to have been following closely lately.
Given the importance of SPCs in practice, clear
interoperable procedures are of prime interest. I'm
not terribly concerned whether they originate in IETF
or ITU or a combination (though the later is
preffered).

Greg B.

Grotto-networking.com

--- "Ong, Lyndon" <LyOng <at> Ciena.com> wrote:
> Hi John,
> 
> -----Original Message-----
> From: John Drake [mailto:jdrake <at> calient.net]
> Sent: Monday, November 17, 2003 1:06 PM
> To: Ong, Lyndon; 'Kireeti Kompella'
> Cc: ccamp <at> ops.ietf.org
> Subject: RE: spc connections
> > I understand that you have many aspects to weigh,
> and 7713.2 is
> > only one of them.  However, the SPC Label
> procedure is one where
> > there have been no technical issues, and it has
> been implemented
> > and tested.  Other people on the list have
> concluded that there
> > is a reasonable case for separating this from the
> ERO, and it is
(Continue reading)

Permalink | Reply | 557 comments |
headers
Lou Berger | 1 Dec 2003 19:50

Fwd: I-D ACTION:draft-berger-gmpls-egress-control-00.txt

FYI -
         Please send comments to me (and/or the list).

Thanks,
Lou

>To: IETF-Announce: ;
>From: Internet-Drafts <at> ietf.org
>Reply-To: Internet-Drafts <at> ietf.org
>Subject: I-D ACTION:draft-berger-gmpls-egress-control-00.txt
>Date: Mon, 24 Nov 2003 15:32:17 -0500
>Sender: owner-ietf-announce <at> ietf.org
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : GMPLS Signaling Procedure For Egress Control
>         Author(s)       : L. Berger
>         Filename        : draft-berger-gmpls-egress-control-00.txt
>         Pages           : 4
>         Date            : 2003-11-24
>
>This note clarifies the procedures for the control of a label used on
>an egress output/downstream interface.  Such control is also know and
>'Egress Control'.  Support for Egress Control is implicit in
>Generalized Multi-Protocol Label Switching (GMPLS) Signaling
>[RFC3471] and [RFC3473].  This note does not modify GMPLS signaling
>mechanisms and procedures and should be viewed as an informative
>clarification of [RFC3473].
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Dec 2003 21:27
Picon
Favicon

I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-05.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		: Requirements for Generalized MPLS (GMPLS) Signaling 
			  Usage and Extensions for Automatically Switched 
			  Optical Network (ASON)
	Author(s)	: D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-ason-reqts-05.txt
	Pages		: 13
	Date		: 2003-12-1
	
The Generalized MPLS (GMPLS) suite of protocol has been defined to
control different switching technologies as well as different
applications. These include support for requesting TDM connections
including SONET/SDH and Optical Transport Networks (OTNs).
This document concentrates on the signaling aspects of the GMPLS
suite of protocols. It identifies the features to be covered by the
GMPLS signalling protocol to support the capabilities of an
Automatically Switched Optical Network (ASON). This document
provides a problem statement and additional requirements on the
GMPLS signaling protocol to support the ASON functionality.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adrian Farrel | 1 Dec 2003 21:45
Picon

Re: ASON RSVP-TE draft to WG doc

Steve,
Thanks for a considered and rational email.

Can I comment on a couple of points?

> No.
>
> Some rationale (very high level):
> It seems premature, and it is not a good idea to have parallel track
> documents in ITU-T and IETF to do the same thing.
>
> In terms of whether it is in Scope, ASON is inherently beyond IETF
> scope. It applies to networks where the transport (data) plane is
> not necessarily IP. It applies to networks where addresses are not
> necessarily IP addresses. It applies to networks where demarcation
> and separation are needed in a manner that is not part of how all-IP
> networks are built. The requirements inherently come from, or belong
> to, ITU-T.

Yet, at the same time, it uses an IP-based signling protocol developed by, and still under
development by the IETF. Those things make it in scope. More precisely, it is explicitly
in scope of the CCAMP WG because it is in the charter.
The charter was reviewed and discussed and I certainly didn't see anyone object.

But, I agree with you that the requirements belong to ITU-T. That is why the current
requirements draft is only an attempt to restate the requirements in terms of GMPLS
signaling and in terms and fortmat that are easy for IETF-heads to parse.

> On the other hand, nobody wants to invent a new protocol from scratch
> when there are existing protocols that meet many of the requirements.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen J Trowbridge | 1 Dec 2003 23:42
Picon
Favicon

Re: ASON RSVP-TE draft to WG doc

Adrian,
On 12/1/2003 1:45 PM, Adrian Farrel wrote:
(snip)
> But, I agree with you that the requirements belong to ITU-T. That is why the current
> requirements draft is only an attempt to restate the requirements in terms of GMPLS
> signaling and in terms and fortmat that are easy for IETF-heads to parse.
Hard as it is to believe, I have met smart people in all kinds of places -
not just ITU-T. I have met plenty of folks in IETF who are perfectly
capable of comprehending ITU-T architecture and terminology. I have even
met people with computers so powerful that they can manage to read a
document that isn't in ASCII with stick figure diagrams :-)

But seriously, if the intent of the current requirements draft
(draft-ietf-ccamp-gmpls-ason-reqts-05.txt) is to present the ITU-T requirements
in terms and format that is easier for IETF-heads to parse, it surely seems
that the next step would be to send this in a liaison statement to ITU-T
to make sure that the requirements are captured correctly, rather than
moving along to a solution document in
draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt that seems to prejudge that
there is some mistake in the existing solution.

> I'm not sure how many individuals have been actively involved in both processes. This is
> clearly something from which both bodies would benefit. I know and understand how
> individuals can become involved in the IETF process. How can individuals participate in
> the ITU-T process?
Actually quite a few of us have been involved both places.

For those who haven't been actively involved on the ITU-T side, there are
about 5 avenues to participate (probably more, but these are from the
top of my head):
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adrian Farrel | 1 Dec 2003 23:48
Picon

Minneapolis minutes

All,
Hoping that our American cousins had a good Thanksgiving.
Could you please review and comment on the draft minutes that I posted.
Silence will be taken as agreement, and I will publish them soon.

Thanks,
Adrian
Permalink | Reply | 0 comments |
headers
Kullberg Alan-G19424 | 2 Dec 2003 03:46

RE: I-D ACTION:draft-berger-gmpls-egress-control-00.txt

Hi Lou,

I have a few typo fixes below as well as this comment.
In section 2.1 ERO Procedures, it says "the label is copied
into a new Label_Set object."

I understand the intent of this statement, but this may mislead
people into thinking that the signaling of the LSP continues
beyond the current (egress) node.

Perhaps that sentence and the one following it could be reworded
as follows:
   If the U-bit of the
   subobject being examined is clear (0), then the value of the label is
   used for downstream traffic associated with the LSP.  This label value
   MUST be used for transmitting traffic associated
   with the LSP on the indicated outgoing/downstream interface.

And to make the next paragraph consistent, I would add the word
MUST as follows:
   Specifically, the label value MUST be used for

Now for typos:

In the Abstract change "know and" to "known as":
   Such control is also known as "Egress Control".

In 2. Egress Control Procedures, change "that section" to "those sections":
   The procedures described in those sections...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ong, Lyndon | 2 Dec 2003 19:10

RE: I-D ACTION:draft-berger-gmpls-egress-control-00.txt

Hi Alan,

I support this proposal, otherwise the wording is still
confusing as you say.

Cheers,

Lyndon

-----Original Message-----
From: Kullberg Alan-G19424 [mailto:alan.kullberg <at> motorola.com]
Sent: Monday, December 01, 2003 6:46 PM
To: 'Lou Berger'; ccamp <at> ops.ietf.org
Subject: RE: I-D ACTION:draft-berger-gmpls-egress-control-00.txt

Hi Lou,

I have a few typo fixes below as well as this comment.
In section 2.1 ERO Procedures, it says "the label is copied
into a new Label_Set object."

I understand the intent of this statement, but this may mislead
people into thinking that the signaling of the LSP continues
beyond the current (egress) node.

Perhaps that sentence and the one following it could be reworded
as follows:
   If the U-bit of the
   subobject being examined is clear (0), then the value of the label is
   used for downstream traffic associated with the LSP.  This label value
(Continue reading)

Permalink | Reply | 0 comments |

Gmane