Re: Final draft of response to the OIF

[dimitri papadimitriou <[e-mail]>]

ben,

the purpose of the sentence you were initially pointing out addresses as 
generic rule more than the specific case under discussion (reason why i 
pointed to this note 2) from the initial clarification asked by the OIF 
- ditto

"Clarification is requested from IETF CCAMP as to which setting is 
considered correct, or if both settings should be accepted (this 
procedure was used during testing at Supercomm)."

hence, any further discussion is involving much more than the requested 
clarification since questioning the logic behind the settings specified 
in this RFC; as these are pure conventions we may debated them forever, 
however, it suffice that one logic gets consensus (with all what it 
implies), which is the case otherwise this would have not become an RFC

---


Mack-Crane, T. Benjamin wrote:

> Dimitri,
> 
> Note 2 on page 6 refers to transparent mode, which is a
> different thing altogether.  I think this encoding is
> poorly chosen as well (and may not allow for the full
> flexibility of equipment that provides various levels
> of transparent STS-N/STM-N switching), but that is not
> currently under discussion.
> 
> Regards,
> Ben 
> 
> 
>>-----Original Message-----
>>From: dimitri papadimitriou [mailto:[e-mail]] 
>>Sent: Wednesday, August 31, 2005 2:38 PM
>>To: Mack-Crane, T. Benjamin
>>Cc: Adrian Farrel; Richard Rabbat; Huub van Helvoort; 
>>[e-mail]
>>Subject: Re: Final draft of response to the OIF
>>
>>
>>to clarify:
>>
>>
>>>The example did not adhere to the rule RCC=1 implies NCC>1
>>>which was stated in the RFC (and is technically sound) thus
>>>one could reasonable presume the example was in error.
>>
>>actually your interpretation is not correct - see note 2 of RFC 3946 
>>(page 6) where the settings RCC=1 can imply NCC=1 is 
>>explicitly stated -
>>
>>this said, one of the reason for this setting wrt the specific point 
>>raised by the OIF is due to the logic that has been used in 
>>making use 
>>of RCC and NCC value when the signal spelling include a "c" i.e. 
>>STS-(3xN)c SPE so for STS-3c SPE the setting is a logical 
>>consequence of 
>>N = 1
>>
>>however, editors have been using a wording for the generic rule which 
>>has not been understood as expected hence the clarification 
>>stated last 
>>march on this list - and reproduced in the bis version -
>>
>>in brief, all this doesn't deserve this flurry of e-mails wrt to the 
>>specific point to be addressed
>>
>>
>>
>>
> 
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the reader
> of this message is not the intended recipient, or an employee
> or agent responsible for delivering this message to the
> intended recipient, you are hereby notified that any reproduction,
> dissemination or distribution of this communication is strictly
> prohibited. If you have received this communication in error,
> please notify us immediately by replying to the message and
> deleting it from your computer. Thank you. Tellabs
> ============================================================
> 
> 
> .
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 31 Aug 2005 20:31:41 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 Aug 2005 22:30:47 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: "Mack-Crane, T. Benjamin" <[e-mail]>
CC:  [e-mail],  Adrian Farrel <[e-mail]>, Richard Rabbat <[e-mail]>,  Huub van Helvoort <[e-mail]>, [e-mail]
Subject: Re: Final draft of response to the OIF
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

ben,

the purpose of the sentence you were initially pointing out addresses as 
generic rule more than the specific case under discussion (reason why i 
pointed to this note 2) from the initial clarification asked by the OIF 
- ditto

"Clarification is requested from IETF CCAMP as to which setting is 
considered correct, or if both settings should be accepted (this 
procedure was used during testing at Supercomm)."

hence, any further discussion is involving much more than the requested 
clarification since questioning the logic behind the settings specified 
in this RFC; as these are pure conventions we may debated them forever, 
however, it suffice that one logic gets consensus (with all what it 
implies), which is the case otherwise this would have not become an RFC

---


Mack-Crane, T. Benjamin wrote:

> Dimitri,
> 
> Note 2 on page 6 refers to transparent mode, which is a
> different thing altogether.  I think this encoding is
> poorly chosen as well (and may not allow for the full
> flexibility of equipment that provides various levels
> of transparent STS-N/STM-N switching), but that is not
> currently under discussion.
> 
> Regards,
> Ben 
> 
> 
>>-----Original Message-----
>>From: dimitri papadimitriou [mailto:[e-mail]] 
>>Sent: Wednesday, August 31, 2005 2:38 PM
>>To: Mack-Crane, T. Benjamin
>>Cc: Adrian Farrel; Richard Rabbat; Huub van Helvoort; 
>>[e-mail]
>>Subject: Re: Final draft of response to the OIF
>>
>>
>>to clarify:
>>
>>
>>>The example did not adhere to the rule RCC=1 implies NCC>1
>>>which was stated in the RFC (and is technically sound) thus
>>>one could reasonable presume the example was in error.
>>
>>actually your interpretation is not correct - see note 2 of RFC 3946 
>>(page 6) where the settings RCC=1 can imply NCC=1 is 
>>explicitly stated -
>>
>>this said, one of the reason for this setting wrt the specific point 
>>raised by the OIF is due to the logic that has been used in 
>>making use 
>>of RCC and NCC value when the signal spelling include a "c" i.e. 
>>STS-(3xN)c SPE so for STS-3c SPE the setting is a logical 
>>consequence of 
>>N = 1
>>
>>however, editors have been using a wording for the generic rule which 
>>has not been understood as expected hence the clarification 
>>stated last 
>>march on this list - and reproduced in the bis version -
>>
>>in brief, all this doesn't deserve this flurry of e-mails wrt to the 
>>specific point to be addressed
>>
>>
>>
>>
> 
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the reader
> of this message is not the intended recipient, or an employee
> or agent responsible for delivering this message to the
> intended recipient, you are hereby notified that any reproduction,
> dissemination or distribution of this communication is strictly
> prohibited. If you have received this communication in error,
> please notify us immediately by replying to the message and
> deleting it from your computer. Thank you. Tellabs
> ============================================================
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 31 Aug 2005 19:58:40 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Final draft of response to the OIF
Date: Wed, 31 Aug 2005 14:55:48 -0500
Message-ID: <[e-mail]>
Thread-Topic: Final draft of response to the OIF
Thread-Index: AcWuY3E1uV77LrzDTwKpcI+RgCvsnwAAYkdw
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Richard Rabbat" <[e-mail]>, "Huub van Helvoort" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

Dimitri,

Note 2 on page 6 refers to transparent mode, which is a
different thing altogether.  I think this encoding is
poorly chosen as well (and may not allow for the full
flexibility of equipment that provides various levels
of transparent STS-N/STM-N switching), but that is not
currently under discussion.

Regards,
Ben 

> -----Original Message-----
> From: dimitri papadimitriou [mailto:[e-mail]] 
> Sent: Wednesday, August 31, 2005 2:38 PM
> To: Mack-Crane, T. Benjamin
> Cc: Adrian Farrel; Richard Rabbat; Huub van Helvoort; 
> [e-mail]
> Subject: Re: Final draft of response to the OIF
> 
> 
> to clarify:
> 
> > The example did not adhere to the rule RCC=1 implies NCC>1
> > which was stated in the RFC (and is technically sound) thus
> > one could reasonable presume the example was in error.
> 
> actually your interpretation is not correct - see note 2 of RFC 3946 
> (page 6) where the settings RCC=1 can imply NCC=1 is 
> explicitly stated -
> 
> this said, one of the reason for this setting wrt the specific point 
> raised by the OIF is due to the logic that has been used in 
> making use 
> of RCC and NCC value when the signal spelling include a "c" i.e. 
> STS-(3xN)c SPE so for STS-3c SPE the setting is a logical 
> consequence of 
> N = 1
> 
> however, editors have been using a wording for the generic rule which 
> has not been understood as expected hence the clarification 
> stated last 
> march on this list - and reproduced in the bis version -
> 
> in brief, all this doesn't deserve this flurry of e-mails wrt to the 
> specific point to be addressed
> 
> 
> 
> 
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================



Envelope-to: [e-mail]
Delivery-date: Wed, 31 Aug 2005 19:37:50 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 Aug 2005 21:37:40 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: "Mack-Crane, T. Benjamin" <[e-mail]>
CC: Adrian Farrel <[e-mail]>,  Richard Rabbat <[e-mail]>, Huub van Helvoort <[e-mail]>,  [e-mail]
Subject: Re: Final draft of response to the OIF
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

to clarify:

> The example did not adhere to the rule RCC=1 implies NCC>1
> which was stated in the RFC (and is technically sound) thus
> one could reasonable presume the example was in error.

actually your interpretation is not correct - see note 2 of RFC 3946 
(page 6) where the settings RCC=1 can imply NCC=1 is explicitly stated -

this said, one of the reason for this setting wrt the specific point 
raised by the OIF is due to the logic that has been used in making use 
of RCC and NCC value when the signal spelling include a "c" i.e. 
STS-(3xN)c SPE so for STS-3c SPE the setting is a logical consequence of 
N = 1

however, editors have been using a wording for the generic rule which 
has not been understood as expected hence the clarification stated last 
march on this list - and reproduced in the bis version -

in brief, all this doesn't deserve this flurry of e-mails wrt to the 
specific point to be addressed







Envelope-to: [e-mail]
Delivery-date: Wed, 31 Aug 2005 19:00:02 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Final draft of response to the OIF
Date: Wed, 31 Aug 2005 13:55:21 -0500
Message-ID: <[e-mail]>
Thread-Topic: Final draft of response to the OIF
Thread-Index: AcWtt+nRqt2VKERdSkWGpR8I1f1/oQAosaQg
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Richard Rabbat" <[e-mail]>
Cc: "Huub van Helvoort" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

Hi Adrian, 

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Tuesday, August 30, 2005 6:12 PM
> To: Mack-Crane, T. Benjamin; Richard Rabbat
> Cc: Huub van Helvoort; [e-mail]
> Subject: Re: Final draft of response to the OIF
> 
> Hi Ben,
> 
> > A long time ago an agreement was reached to unify
> > the SDH and SONET encodings, since carriers did not
> > want to manage unnecessary differences.
> 
> Good motivation.
> 
> Presume that here you are not really talking about the SDH and SONET
> encoding, but rather the control plane encodings.

Yup.

> 
> > What implementations have done as a result of the
> > bad example in RFC 3946 is unfortunate, and leads to
> > interop problems -- and thus the item from the OIF.
> 
> Whether the example is bad or not clearly depends on the 
> encoding rules
> specified in the RFC.
> With the clarification from the Editors, it would appear that 
> the example
> is good. Now, you can object to the encoding rules, but that 
> doesn't mean
> that the example is bad.

The example did not adhere to the rule RCC=1 implies NCC>1
which was stated in the RFC (and is technically sound) thus
one could reasonable presume the example was in error.

> 
> I have not heard of any interop problems. Centrainly the 
> message from the
> OIF did not report any such problems. My understanding is 
> that there were
> no interope problems, merely a question about intended 
> encodings. With the
> rule of "liberal in what you receive" I would not expect any interop
> problems.

The problem was that both encodings were in use and some
were not liberal in what they received.  That was easily fixed.
If only one encoding was specified, there would have been
no problem.

> 
>  > This is our opportunity to fix the example and
> > removed the problem (and then folks can simplify
> > their implementations).  If the difference remains,
> > there will be opportunity for creating more interop
> > problems (if implementations behave differently for
> > the different encodings).
> 
> I'd like to clarify the extent of the simplification that you are
> proposing in people's implementations. You are suggesting 
> replacing a line
> of code that says:
> 
>     if ( (rcc==1) && (ncc == 0 || ncc == 1) )
> 
> with a line of code that says
> 
>     if ( (rcc==1) && (ncc == 1) )
> 
> Why is this a big deal?

Your first line of code is incorrect (uh-oh, more interop problems...;-)

But, what I am concerned about is the possibility of code
like this:

if (rcc==1 && ncc==1) {do behavior A}

if (rcc==0 && ncc==0) {do behavior B}

Which has the potential for creating diversity in behavior
where it should not exist.  Having only one encoding
greatly reduces the chances of this...

> 
> > So, rather than make things more complicated by
> > modifying an accepted rule (RCC=1 requires NCC>1),
> > retaining two encodings for the same signal, and
> > adding notes to attempt to explain the interworking
> > options, it is much easier to correct the example.
> 
> Again, I think you are misrepresenting what the authors are doing. In
> their view they are not changing the rules, but correcting an 
> editorial
> mistake. In their opinion the example is already correct.

Changing the encoding in the example could be considered
editorial, as it's just an example in an annex.
Changing the rule RCC=1 implies NCC>1 to RCC=1 implies NCC>0
is a semantic change (which in my view doesn't make sense,
unless, as Huub suggested, we consider all elementary signals
to be contiguous concatenations of 1 element and then RCC=1
always...:-o)

> 
> Now, I don't want to start any voting here, but I see several 
> people who
> are expressing support for the ideas in
> draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one 
> person saying
> make the change the other way. If I was to judge consensus 
> today, it is
> pretty clear how I would call it.
> 
> Let's hear some opinions from other people who have an 
> interest in this
> work.
> 
> Thanks,
> Adrian
> 
> 
> >
> > This is good engineering practice, in my view.
> >
> > Regards,
> > Ben
> >
> > > -----Original Message-----
> > > From: Richard Rabbat [mailto:[e-mail]]
> > > Sent: Tuesday, August 30, 2005 3:58 PM
> > > To: Mack-Crane, T. Benjamin
> > > Cc: Huub van Helvoort; Adrian Farrel; [e-mail]
> > > Subject: Re: Final draft of response to the OIF
> > >
> > > Ben,
> > > Adrian's final draft of the response is most inclusive. 
> From what you
> > > said earlier, it seems that you've already coded it in one way
> > > (whichever) but are accepting both sets of values for NCC &
> > > RCC (both 1 or 0).
> > > Is there an engineering problem with the text of the 
> response besides
> > > that you would be able to remove those couple of lines of
> > > code? if so,
> > > we should solve it.
> > > Richard.
> > >
> > >
> > > Mack-Crane, T. Benjamin wrote:
> > >
> > > >Hi Huub,
> > > >
> > > >See in-line below.
> > > >
> > > >Regards,
> > > >Ben
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: Huub van Helvoort [mailto:[e-mail]]
> > > >>Sent: Friday, August 26, 2005 10:56 AM
> > > >>To: Mack-Crane, T. Benjamin
> > > >>Cc: Adrian Farrel; [e-mail]
> > > >>Subject: Re: Final draft of response to the OIF
> > > >>
> > > >>Hello Ben,
> > > >>
> > > >>You wrote:
> > > >>
> > > >>
> > > >>
> > > >>>I proposed a simple (and I think technically sound) solution to
> > > >>>item #1 and saw no objections, however the answer has 
> not changed.
> > > >>>
> > > >>>I do not understand the reason for different encodings for
> > > >>>VC-4 and STS-3c SPE.  I think they should be the same, unless
> > > >>>there is a technical need to distinguish them.
> > > >>>
> > > >>>
> > > >>If there is agreement that they should be the same, we should
> > > >>also look at higher order contiguous concatenated signals:
> > > >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c 
> == VC-4-64c
> > > >>STS-768c == VC-4-256c
> > > >>
> > > >>
> > > >
> > > >These signals are already encoded the same way (for instance see
> > > >examples 3 and 9 in RFC 3946).
> > > >
> > > >
> > > >
> > > >>>I also do not understand the RCC=1 NCC=1 encoding, 
> since the rule
> > > >>>contained in the current RFC actually makes more sense.
> > > >>>
> > > >>>
> > > >>However indicating the number of signals concatenated in NCC
> > > >>makes your first objective impossible: STS-3Xc == VC-4-Xc
> > > >>so there will always be a difference of a factor 3 between
> > > >>STS and VC-4 encoding
> > > >>
> > > >>
> > > >
> > > >All the encodings of contiguous concatenated signals use VC-4
> > > >(STS-3c SPE) as the base, so the NCC values are the same.  This
> > > >was done to align SONET and SDH encodings.
> > > >
> > > >
> > > >
> > > >>>If there is
> > > >>>only
> > > >>>one signal element, there is no contiguous concatenation,
> > > >>>
> > > >>>
> > > >>by definition.
> > > >>
> > > >>In fact a single signal is always contiguous concatenated  ;-)
> > > >>
> > > >>
> > > >>
> > > >>>So I fail to see the usefulness of these encodings.
> > > >>>
> > > >>>
> > > >>NCC = 1 would normally not occur, so it could be used for
> > > >>this specific case of SONET signals transported in an
> > > >>SDH world, or SDH signals transported in SONET land.
> > > >>And if these signals would not cross borders the value
> > > >>NCC > 1 can be used.
> > > >>
> > > >>
> > > >
> > > >The SDH and SONET encodings have been aligned in all cases
> > > >except this one (VC-4, STS-3c SPE).  So these should also
> > > >be aligned.
> > > >
> > > >
> > > >
> > > >>>Regards,
> > > >>>Ben
> > > >>>
> > > >>>
> > > >>Cheers, Huub.
> > > >>
> > > >>-- 
> > > >>================================================================
> > > >>              http://members.chello.nl/hhelvoort/
> > > >>================================================================
> > > >>Always remember that you are unique...just like everyone else...
> > > >>
> > > >>
> > > >>
> > > >============================================================
> > > >The information contained in this message may be privileged
> > > >and confidential and protected from disclosure. If the reader
> > > >of this message is not the intended recipient, or an employee
> > > >or agent responsible for delivering this message to the
> > > >intended recipient, you are hereby notified that any 
> reproduction,
> > > >dissemination or distribution of this communication is strictly
> > > >prohibited. If you have received this communication in error,
> > > >please notify us immediately by replying to the message and
> > > >deleting it from your computer. Thank you. Tellabs
> > > >============================================================
> > > >
> > > >
> > > >
> > >
> > ============================================================
> > The information contained in this message may be privileged
> > and confidential and protected from disclosure. If the reader
> > of this message is not the intended recipient, or an employee
> > or agent responsible for delivering this message to the
> > intended recipient, you are hereby notified that any reproduction,
> > dissemination or distribution of this communication is strictly
> > prohibited. If you have received this communication in error,
> > please notify us immediately by replying to the message and
> > deleting it from your computer. Thank you. Tellabs
> > ============================================================
> >
> >
> 
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================



Envelope-to: [e-mail]
Delivery-date: Wed, 31 Aug 2005 17:44:18 +0000
Message-ID: <007a01c5ae53$a3141c90$48849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: ID Tracker State Update Notice: draft-ietf-ccamp-gmpls-alarm-spec
Date: Wed, 31 Aug 2005 18:39:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

The AD has looked at this draft and made some suggestions. I will work
with the Editor to get a new version out quickly.

Please look at the AD's comments:
- to check that you agree
- to learn what you should be doing in your I-Ds.

Cheers,
Adrian
----- Original Message ----- 
From: "The IESG" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Wednesday, August 31, 2005 2:35 AM
Subject: ID Tracker State Update Notice: draft-ietf-ccamp-gmpls-alarm-spec


> 'State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by
Alex Zinin'
> ID Tracker URL:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11679&rfc_flag=0
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 31 Aug 2005 15:35:01 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Final draft of response to the OIF
Date: Wed, 31 Aug 2005 11:32:00 -0400
Message-ID: <[e-mail]>
Thread-Topic: Final draft of response to the OIF
Thread-Index: AcWtuJvkIbjLmQP6T8S0ra1KYZUpkQAhzlpw
From: "Stephen Shew" <[e-mail]>
To: <[e-mail]>

I prefer Ben's solution of having one encoding for STS-3c and VC-4.

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, August 30, 2005 19:12
> To: Mack-Crane, T. Benjamin; Richard Rabbat
> Cc: Huub van Helvoort; [e-mail]
> Subject: Re: Final draft of response to the OIF
>=20
>=20
> Hi Ben,
>=20
> > A long time ago an agreement was reached to unify
> > the SDH and SONET encodings, since carriers did not
> > want to manage unnecessary differences.
>=20
> Good motivation.
>=20
> Presume that here you are not really talking about the SDH=20
> and SONET encoding, but rather the control plane encodings.
>=20
> > What implementations have done as a result of the
> > bad example in RFC 3946 is unfortunate, and leads to
> > interop problems -- and thus the item from the OIF.
>=20
> Whether the example is bad or not clearly depends on the=20
> encoding rules specified in the RFC. With the clarification=20
> from the Editors, it would appear that the example is good.=20
> Now, you can object to the encoding rules, but that doesn't=20
> mean that the example is bad.
>=20
> I have not heard of any interop problems. Centrainly the=20
> message from the OIF did not report any such problems. My=20
> understanding is that there were no interope problems, merely=20
> a question about intended encodings. With the rule of=20
> "liberal in what you receive" I would not expect any interop problems.
>=20
>  > This is our opportunity to fix the example and
> > removed the problem (and then folks can simplify
> > their implementations).  If the difference remains,
> > there will be opportunity for creating more interop
> > problems (if implementations behave differently for
> > the different encodings).
>=20
> I'd like to clarify the extent of the simplification that you=20
> are proposing in people's implementations. You are suggesting=20
> replacing a line of code that says:
>=20
>     if ( (rcc=3D=3D1) && (ncc =3D=3D 0 || ncc =3D=3D 1) )
>=20
> with a line of code that says
>=20
>     if ( (rcc=3D=3D1) && (ncc =3D=3D 1) )
>=20
> Why is this a big deal?
>=20
> > So, rather than make things more complicated by
> > modifying an accepted rule (RCC=3D1 requires NCC>1),
> > retaining two encodings for the same signal, and
> > adding notes to attempt to explain the interworking
> > options, it is much easier to correct the example.
>=20
> Again, I think you are misrepresenting what the authors are=20
> doing. In their view they are not changing the rules, but=20
> correcting an editorial mistake. In their opinion the example=20
> is already correct.
>=20
> Now, I don't want to start any voting here, but I see several=20
> people who are expressing support for the ideas in=20
> draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one=20
> person saying make the change the other way. If I was to=20
> judge consensus today, it is pretty clear how I would call it.
>=20
> Let's hear some opinions from other people who have an=20
> interest in this work.
>=20
> Thanks,
> Adrian
<snip>



Envelope-to: [e-mail]
Delivery-date: Wed, 31 Aug 2005 12:08:36 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 Aug 2005 14:04:02 +0200
From: WALTER ROTHKEGEL <[e-mail]>
Organization: Lucent Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: "Mack-Crane, T. Benjamin" <[e-mail]>, [e-mail]
Subject: Re: Final draft of response to the OIF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Adrian,

I support Ben's arguments. I do not see any reason which
would require the two different encodings.

Regards

Walter

On 31.08.2005 01:11, Adrian Farrel wrote:
> Hi Ben,
> 
> 
>>A long time ago an agreement was reached to unify
>>the SDH and SONET encodings, since carriers did not
>>want to manage unnecessary differences.
> 
> 
> Good motivation.
> 
> Presume that here you are not really talking about the SDH and SONET
> encoding, but rather the control plane encodings.
> 
> 
>>What implementations have done as a result of the
>>bad example in RFC 3946 is unfortunate, and leads to
>>interop problems -- and thus the item from the OIF.
> 
> 
> Whether the example is bad or not clearly depends on the encoding rules
> specified in the RFC.
> With the clarification from the Editors, it would appear that the example
> is good. Now, you can object to the encoding rules, but that doesn't mean
> that the example is bad.
> 
> I have not heard of any interop problems. Centrainly the message from the
> OIF did not report any such problems. My understanding is that there were
> no interope problems, merely a question about intended encodings. With the
> rule of "liberal in what you receive" I would not expect any interop
> problems.
> 
>  > This is our opportunity to fix the example and
> 
>>removed the problem (and then folks can simplify
>>their implementations).  If the difference remains,
>>there will be opportunity for creating more interop
>>problems (if implementations behave differently for
>>the different encodings).
> 
> 
> I'd like to clarify the extent of the simplification that you are
> proposing in people's implementations. You are suggesting replacing a line
> of code that says:
> 
>     if ( (rcc==1) && (ncc == 0 || ncc == 1) )
> 
> with a line of code that says
> 
>     if ( (rcc==1) && (ncc == 1) )
> 
> Why is this a big deal?
> 
> 
>>So, rather than make things more complicated by
>>modifying an accepted rule (RCC=1 requires NCC>1),
>>retaining two encodings for the same signal, and
>>adding notes to attempt to explain the interworking
>>options, it is much easier to correct the example.
> 
> 
> Again, I think you are misrepresenting what the authors are doing. In
> their view they are not changing the rules, but correcting an editorial
> mistake. In their opinion the example is already correct.
> 
> Now, I don't want to start any voting here, but I see several people who
> are expressing support for the ideas in
> draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying
> make the change the other way. If I was to judge consensus today, it is
> pretty clear how I would call it.
> 
> Let's hear some opinions from other people who have an interest in this
> work.
> 
> Thanks,
> Adrian
> 
> 
> 
>>This is good engineering practice, in my view.
>>
>>Regards,
>>Ben
>>
>>
>>>-----Original Message-----
>>>From: Richard Rabbat [mailto:[e-mail]]
>>>Sent: Tuesday, August 30, 2005 3:58 PM
>>>To: Mack-Crane, T. Benjamin
>>>Cc: Huub van Helvoort; Adrian Farrel; [e-mail]
>>>Subject: Re: Final draft of response to the OIF
>>>
>>>Ben,
>>>Adrian's final draft of the response is most inclusive. From what you
>>>said earlier, it seems that you've already coded it in one way
>>>(whichever) but are accepting both sets of values for NCC &
>>>RCC (both 1 or 0).
>>>Is there an engineering problem with the text of the response besides
>>>that you would be able to remove those couple of lines of
>>>code? if so,
>>>we should solve it.
>>>Richard.
>>>
>>>
>>>Mack-Crane, T. Benjamin wrote:
>>>
>>>
>>>>Hi Huub,
>>>>
>>>>See in-line below.
>>>>
>>>>Regards,
>>>>Ben
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Huub van Helvoort [mailto:[e-mail]]
>>>>>Sent: Friday, August 26, 2005 10:56 AM
>>>>>To: Mack-Crane, T. Benjamin
>>>>>Cc: Adrian Farrel; [e-mail]
>>>>>Subject: Re: Final draft of response to the OIF
>>>>>
>>>>>Hello Ben,
>>>>>
>>>>>You wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I proposed a simple (and I think technically sound) solution to
>>>>>>item #1 and saw no objections, however the answer has not changed.
>>>>>>
>>>>>>I do not understand the reason for different encodings for
>>>>>>VC-4 and STS-3c SPE.  I think they should be the same, unless
>>>>>>there is a technical need to distinguish them.
>>>>>>
>>>>>>
>>>>>
>>>>>If there is agreement that they should be the same, we should
>>>>>also look at higher order contiguous concatenated signals:
>>>>>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c
>>>>>STS-768c == VC-4-256c
>>>>>
>>>>>
>>>>
>>>>These signals are already encoded the same way (for instance see
>>>>examples 3 and 9 in RFC 3946).
>>>>
>>>>
>>>>
>>>>
>>>>>>I also do not understand the RCC=1 NCC=1 encoding, since the rule
>>>>>>contained in the current RFC actually makes more sense.
>>>>>>
>>>>>>
>>>>>
>>>>>However indicating the number of signals concatenated in NCC
>>>>>makes your first objective impossible: STS-3Xc == VC-4-Xc
>>>>>so there will always be a difference of a factor 3 between
>>>>>STS and VC-4 encoding
>>>>>
>>>>>
>>>>
>>>>All the encodings of contiguous concatenated signals use VC-4
>>>>(STS-3c SPE) as the base, so the NCC values are the same.  This
>>>>was done to align SONET and SDH encodings.
>>>>
>>>>
>>>>
>>>>
>>>>>>If there is
>>>>>>only
>>>>>>one signal element, there is no contiguous concatenation,
>>>>>>
>>>>>>
>>>>>
>>>>>by definition.
>>>>>
>>>>>In fact a single signal is always contiguous concatenated  ;-)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>So I fail to see the usefulness of these encodings.
>>>>>>
>>>>>>
>>>>>
>>>>>NCC = 1 would normally not occur, so it could be used for
>>>>>this specific case of SONET signals transported in an
>>>>>SDH world, or SDH signals transported in SONET land.
>>>>>And if these signals would not cross borders the value
>>>>>NCC > 1 can be used.
>>>>>
>>>>>
>>>>
>>>>The SDH and SONET encodings have been aligned in all cases
>>>>except this one (VC-4, STS-3c SPE).  So these should also
>>>>be aligned.
>>>>
>>>>
>>>>
>>>>
>>>>>>Regards,
>>>>>>Ben
>>>>>>
>>>>>>
>>>>>
>>>>>Cheers, Huub.
>>>>>
>>>>>-- 
>>>>>================================================================
>>>>>             http://members.chello.nl/hhelvoort/
>>>>>================================================================
>>>>>Always remember that you are unique...just like everyone else...
>>>>>
>>>>>
>>>>>
>>>>
>>>>============================================================
>>>>The information contained in this message may be privileged
>>>>and confidential and protected from disclosure. If the reader
>>>>of this message is not the intended recipient, or an employee
>>>>or agent responsible for delivering this message to the
>>>>intended recipient, you are hereby notified that any reproduction,
>>>>dissemination or distribution of this communication is strictly
>>>>prohibited. If you have received this communication in error,
>>>>please notify us immediately by replying to the message and
>>>>deleting it from your computer. Thank you. Tellabs
>>>>============================================================
>>>>
>>>>
>>>>
>>>
>>============================================================
>>The information contained in this message may be privileged
>>and confidential and protected from disclosure. If the reader
>>of this message is not the intended recipient, or an employee
>>or agent responsible for delivering this message to the
>>intended recipient, you are hereby notified that any reproduction,
>>dissemination or distribution of this communication is strictly
>>prohibited. If you have received this communication in error,
>>please notify us immediately by replying to the message and
>>deleting it from your computer. Thank you. Tellabs
>>============================================================
>>
>>
> 
> 
> 


-- 
________________________________________________________________________
Walter Rothkegel, Lucent Technologies Network Systems GmbH, Dept. O-SE
Thurn-und-Taxis-Str. 10-14, 90411 Nuernberg, Germany
Phone: [phone]      Fax:   [phone]
mailto:[e-mail]




Envelope-to: [e-mail]
Delivery-date: Wed, 31 Aug 2005 04:51:15 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Final draft of response to the OIF
Date: Wed, 31 Aug 2005 00:47:40 -0400
Message-ID: <[e-mail]>
Thread-Topic: Final draft of response to the OIF
thread-index: AcWtuClga8yGbSLuR6uk3RqoONxALAAK8TFw
From: "Ong, Lyndon" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, "Richard Rabbat" <[e-mail]>
Cc: "Huub van Helvoort" <[e-mail]>, <[e-mail]>

Hi Adrian,

I have some sympathy with Ben's comments, it seems like a single
value would simplify configuration the most.  We were able to work
around the problem at the OIF test, but the number of vendors was
limited and it did cause some initial headaches.

Short of a single value, maybe a slight rewording of your text would
make
a stronger recommendation that implementations be able to accept
both, e.g.:

  " Note 3: Following these rules, when requesting a VC-4 signal, the
      RCC and the NCC values must be set to 0 whereas for an STS-3c SPE
      signal, the RCC and the NCC values must be set 1. However, if
      local conditions allow (e.g., no differentiation of VC-4 vs.
STS-3c
      format is required), then the requesting upstream node MAY set
      the RCC and NCC values to either SDH or SONET settings without
      impacting the function, and the downstream node SHOULD accept
      either of the requested values. If the received value cannot
      be supported, the receiver downstream node MUST generate
      a PathErr/NOTIFICATION message (see Sections 2.2 and
      2.3, respectively). "

Cheers,

Lyndon

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Tuesday, August 30, 2005 4:12 PM
To: Mack-Crane, T. Benjamin; Richard Rabbat
Cc: Huub van Helvoort; [e-mail]
Subject: Re: Final draft of response to the OIF

Hi Ben,

> A long time ago an agreement was reached to unify the SDH and SONET=20
> encodings, since carriers did not want to manage unnecessary=20
> differences.

Good motivation.

Presume that here you are not really talking about the SDH and SONET
encoding, but rather the control plane encodings.

> What implementations have done as a result of the bad example in RFC=20
> 3946 is unfortunate, and leads to interop problems -- and thus the=20
> item from the OIF.

Whether the example is bad or not clearly depends on the encoding rules
specified in the RFC.
With the clarification from the Editors, it would appear that the
example is good. Now, you can object to the encoding rules, but that
doesn't mean that the example is bad.

I have not heard of any interop problems. Centrainly the message from
the OIF did not report any such problems. My understanding is that there
were no interope problems, merely a question about intended encodings.
With the rule of "liberal in what you receive" I would not expect any
interop problems.

 > This is our opportunity to fix the example and
> removed the problem (and then folks can simplify their=20
> implementations).  If the difference remains, there will be=20
> opportunity for creating more interop problems (if implementations=20
> behave differently for the different encodings).

I'd like to clarify the extent of the simplification that you are
proposing in people's implementations. You are suggesting replacing a
line of code that says:

    if ( (rcc=3D=3D1) && (ncc =3D=3D 0 || ncc =3D=3D 1) )

with a line of code that says

    if ( (rcc=3D=3D1) && (ncc =3D=3D 1) )

Why is this a big deal?

> So, rather than make things more complicated by modifying an accepted=20
> rule (RCC=3D1 requires NCC>1), retaining two encodings for the same=20
> signal, and adding notes to attempt to explain the interworking=20
> options, it is much easier to correct the example.

Again, I think you are misrepresenting what the authors are doing. In
their view they are not changing the rules, but correcting an editorial
mistake. In their opinion the example is already correct.

Now, I don't want to start any voting here, but I see several people who
are expressing support for the ideas in
draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying
make the change the other way. If I was to judge consensus today, it is
pretty clear how I would call it.

Let's hear some opinions from other people who have an interest in this
work.

Thanks,
Adrian


>
> This is good engineering practice, in my view.
>
> Regards,
> Ben
>
> > -----Original Message-----
> > From: Richard Rabbat [mailto:[e-mail]]
> > Sent: Tuesday, August 30, 2005 3:58 PM
> > To: Mack-Crane, T. Benjamin
> > Cc: Huub van Helvoort; Adrian Farrel; [e-mail]
> > Subject: Re: Final draft of response to the OIF
> >
> > Ben,
> > Adrian's final draft of the response is most inclusive. From what=20
> > you said earlier, it seems that you've already coded it in one way
> > (whichever) but are accepting both sets of values for NCC & RCC=20
> > (both 1 or 0).
> > Is there an engineering problem with the text of the response=20
> > besides that you would be able to remove those couple of lines of=20
> > code? if so, we should solve it.
> > Richard.
> >
> >
> > Mack-Crane, T. Benjamin wrote:
> >
> > >Hi Huub,
> > >
> > >See in-line below.
> > >
> > >Regards,
> > >Ben
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Huub van Helvoort [mailto:[e-mail]]
> > >>Sent: Friday, August 26, 2005 10:56 AM
> > >>To: Mack-Crane, T. Benjamin
> > >>Cc: Adrian Farrel; [e-mail]
> > >>Subject: Re: Final draft of response to the OIF
> > >>
> > >>Hello Ben,
> > >>
> > >>You wrote:
> > >>
> > >>
> > >>
> > >>>I proposed a simple (and I think technically sound) solution to=20
> > >>>item #1 and saw no objections, however the answer has not
changed.
> > >>>
> > >>>I do not understand the reason for different encodings for
> > >>>VC-4 and STS-3c SPE.  I think they should be the same, unless=20
> > >>>there is a technical need to distinguish them.
> > >>>
> > >>>
> > >>If there is agreement that they should be the same, we should also

> > >>look at higher order contiguous concatenated signals:
> > >>i.e. STS-12c =3D=3D VC-4-4c, STS-48c =3D=3D VC-4-16c, STS-192c =
=3D=3D VC-4-64c

> > >>STS-768c =3D=3D VC-4-256c
> > >>
> > >>
> > >
> > >These signals are already encoded the same way (for instance see=20
> > >examples 3 and 9 in RFC 3946).
> > >
> > >
> > >
> > >>>I also do not understand the RCC=3D1 NCC=3D1 encoding, since the =
rule

> > >>>contained in the current RFC actually makes more sense.
> > >>>
> > >>>
> > >>However indicating the number of signals concatenated in NCC makes

> > >>your first objective impossible: STS-3Xc =3D=3D VC-4-Xc so there =
will=20
> > >>always be a difference of a factor 3 between STS and VC-4 encoding
> > >>
> > >>
> > >
> > >All the encodings of contiguous concatenated signals use VC-4=20
> > >(STS-3c SPE) as the base, so the NCC values are the same.  This was

> > >done to align SONET and SDH encodings.
> > >
> > >
> > >
> > >>>If there is
> > >>>only
> > >>>one signal element, there is no contiguous concatenation,
> > >>>
> > >>>
> > >>by definition.
> > >>
> > >>In fact a single signal is always contiguous concatenated  ;-)
> > >>
> > >>
> > >>
> > >>>So I fail to see the usefulness of these encodings.
> > >>>
> > >>>
> > >>NCC =3D 1 would normally not occur, so it could be used for this=20
> > >>specific case of SONET signals transported in an SDH world, or SDH

> > >>signals transported in SONET land.
> > >>And if these signals would not cross borders the value NCC > 1 can

> > >>be used.
> > >>
> > >>
> > >
> > >The SDH and SONET encodings have been aligned in all cases except=20
> > >this one (VC-4, STS-3c SPE).  So these should also be aligned.
> > >
> > >
> > >
> > >>>Regards,
> > >>>Ben
> > >>>
> > >>>
> > >>Cheers, Huub.
> > >>
> > >>--
> > =
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >>              http://members.chello.nl/hhelvoort/
> > =
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >>Always remember that you are unique...just like everyone else...
> > >>
> > >>
> > >>
> > =
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >The information contained in this message may be privileged and=20
> > >confidential and protected from disclosure. If the reader of this=20
> > >message is not the intended recipient, or an employee or agent=20
> > >responsible for delivering this message to the intended recipient,=20
> > >you are hereby notified that any reproduction, dissemination or=20
> > >distribution of this communication is strictly prohibited. If you=20
> > >have received this communication in error, please notify us=20
> > >immediately by replying to the message and deleting it from your=20
> > >computer. Thank you. Tellabs=20
> > =
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> > >
> > >
> >
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The information contained in this message may be privileged and=20
> confidential and protected from disclosure. If the reader of this=20
> message is not the intended recipient, or an employee or agent=20
> responsible for delivering this message to the intended recipient, you

> are hereby notified that any reproduction, dissemination or=20
> distribution of this communication is strictly prohibited. If you have

> received this communication in error, please notify us immediately by=20
> replying to the message and deleting it from your computer. Thank you.

> Tellabs =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>





Envelope-to: [e-mail]
Delivery-date: Wed, 31 Aug 2005 00:49:54 +0000
Message-ID: <[e-mail]>
Date: Tue, 30 Aug 2005 17:48:22 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: "Mack-Crane, T. Benjamin" <[e-mail]>, Richard Rabbat <[e-mail]>, Huub van Helvoort <[e-mail]>, [e-mail]
Subject: Re: Final draft of response to the OIF
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi folks, a bit of history.  At the time the ID was originally written a 
number of manufacturers had (and still offer) more flexible forms of 
concatenation rather than the standard SONET/SDH contiguous 
concatenation.  This and the usual standards related compromises lead to 
the rather general and possibly confusing  rules that appear in RFC 3946. 

Unknown to us at the time was that none of these proprietary schemes 
would become standardized.   This is mostly due to the greater abilities 
of Virtual Concatenation (VCAT) which was standardized and since 
extended beyond SONET/SDH to OTN and PDH.

Hence though RFC3946 encoding seems a bit obtuse the intentions were 
aimed at future proofing (but part of that future didn't happen).  I've 
tried to make ammends by working with Richard and others to clear things 
up while minimizing the impact to implementations. 

At this point in time is there any other option since this is already a 
standards track RFC?

Greg B.
Adrian Farrel wrote:

>Hi Ben,
>
>  
>
>>A long time ago an agreement was reached to unify
>>the SDH and SONET encodings, since carriers did not
>>want to manage unnecessary differences.
>>    
>>
>
>Good motivation.
>
>Presume that here you are not really talking about the SDH and SONET
>encoding, but rather the control plane encodings.
>
>  
>
>>What implementations have done as a result of the
>>bad example in RFC 3946 is unfortunate, and leads to
>>interop problems -- and thus the item from the OIF.
>>    
>>
>
>Whether the example is bad or not clearly depends on the encoding rules
>specified in the RFC.
>With the clarification from the Editors, it would appear that the example
>is good. Now, you can object to the encoding rules, but that doesn't mean
>that the example is bad.
>
>I have not heard of any interop problems. Centrainly the message from the
>OIF did not report any such problems. My understanding is that there were
>no interope problems, merely a question about intended encodings. With the
>rule of "liberal in what you receive" I would not expect any interop
>problems.
>
> > This is our opportunity to fix the example and
>  
>
>>removed the problem (and then folks can simplify
>>their implementations).  If the difference remains,
>>there will be opportunity for creating more interop
>>problems (if implementations behave differently for
>>the different encodings).
>>    
>>
>
>I'd like to clarify the extent of the simplification that you are
>proposing in people's implementations. You are suggesting replacing a line
>of code that says:
>
>    if ( (rcc==1) && (ncc == 0 || ncc == 1) )
>
>with a line of code that says
>
>    if ( (rcc==1) && (ncc == 1) )
>
>Why is this a big deal?
>
>  
>
>>So, rather than make things more complicated by
>>modifying an accepted rule (RCC=1 requires NCC>1),
>>retaining two encodings for the same signal, and
>>adding notes to attempt to explain the interworking
>>options, it is much easier to correct the example.
>>    
>>
>
>Again, I think you are misrepresenting what the authors are doing. In
>their view they are not changing the rules, but correcting an editorial
>mistake. In their opinion the example is already correct.
>
>Now, I don't want to start any voting here, but I see several people who
>are expressing support for the ideas in
>draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying
>make the change the other way. If I was to judge consensus today, it is
>pretty clear how I would call it.
>
>Let's hear some opinions from other people who have an interest in this
>work.
>
>Thanks,
>Adrian
>
>
>  
>
>>This is good engineering practice, in my view.
>>
>>Regards,
>>Ben
>>
>>    
>>
>>>-----Original Message-----
>>>From: Richard Rabbat [mailto:[e-mail]]
>>>Sent: Tuesday, August 30, 2005 3:58 PM
>>>To: Mack-Crane, T. Benjamin
>>>Cc: Huub van Helvoort; Adrian Farrel; [e-mail]
>>>Subject: Re: Final draft of response to the OIF
>>>
>>>Ben,
>>>Adrian's final draft of the response is most inclusive. From what you
>>>said earlier, it seems that you've already coded it in one way
>>>(whichever) but are accepting both sets of values for NCC &
>>>RCC (both 1 or 0).
>>>Is there an engineering problem with the text of the response besides
>>>that you would be able to remove those couple of lines of
>>>code? if so,
>>>we should solve it.
>>>Richard.
>>>
>>>
>>>Mack-Crane, T. Benjamin wrote:
>>>
>>>      
>>>
>>>>Hi Huub,
>>>>
>>>>See in-line below.
>>>>
>>>>Regards,
>>>>Ben
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>-----Original Message-----
>>>>>From: Huub van Helvoort [mailto:[e-mail]]
>>>>>Sent: Friday, August 26, 2005 10:56 AM
>>>>>To: Mack-Crane, T. Benjamin
>>>>>Cc: Adrian Farrel; [e-mail]
>>>>>Subject: Re: Final draft of response to the OIF
>>>>>
>>>>>Hello Ben,
>>>>>
>>>>>You wrote:
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>I proposed a simple (and I think technically sound) solution to
>>>>>>item #1 and saw no objections, however the answer has not changed.
>>>>>>
>>>>>>I do not understand the reason for different encodings for
>>>>>>VC-4 and STS-3c SPE.  I think they should be the same, unless
>>>>>>there is a technical need to distinguish them.
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>If there is agreement that they should be the same, we should
>>>>>also look at higher order contiguous concatenated signals:
>>>>>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c
>>>>>STS-768c == VC-4-256c
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>These signals are already encoded the same way (for instance see
>>>>examples 3 and 9 in RFC 3946).
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>>I also do not understand the RCC=1 NCC=1 encoding, since the rule
>>>>>>contained in the current RFC actually makes more sense.
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>However indicating the number of signals concatenated in NCC
>>>>>makes your first objective impossible: STS-3Xc == VC-4-Xc
>>>>>so there will always be a difference of a factor 3 between
>>>>>STS and VC-4 encoding
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>All the encodings of contiguous concatenated signals use VC-4
>>>>(STS-3c SPE) as the base, so the NCC values are the same.  This
>>>>was done to align SONET and SDH encodings.
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>>If there is
>>>>>>only
>>>>>>one signal element, there is no contiguous concatenation,
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>by definition.
>>>>>
>>>>>In fact a single signal is always contiguous concatenated  ;-)
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>So I fail to see the usefulness of these encodings.
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>NCC = 1 would normally not occur, so it could be used for
>>>>>this specific case of SONET signals transported in an
>>>>>SDH world, or SDH signals transported in SONET land.
>>>>>And if these signals would not cross borders the value
>>>>>NCC > 1 can be used.
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>The SDH and SONET encodings have been aligned in all cases
>>>>except this one (VC-4, STS-3c SPE).  So these should also
>>>>be aligned.
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>>Regards,
>>>>>>Ben
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>Cheers, Huub.
>>>>>
>>>>>-- 
>>>>>================================================================
>>>>>             http://members.chello.nl/hhelvoort/
>>>>>================================================================
>>>>>Always remember that you are unique...just like everyone else...
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>============================================================
>>>>The information contained in this message may be privileged
>>>>and confidential and protected from disclosure. If the reader
>>>>of this message is not the intended recipient, or an employee
>>>>or agent responsible for delivering this message to the
>>>>intended recipient, you are hereby notified that any reproduction,
>>>>dissemination or distribution of this communication is strictly
>>>>prohibited. If you have received this communication in error,
>>>>please notify us immediately by replying to the message and
>>>>deleting it from your computer. Thank you. Tellabs
>>>>============================================================
>>>>
>>>>
>>>>
>>>>        
>>>>
>>============================================================
>>The information contained in this message may be privileged
>>and confidential and protected from disclosure. If the reader
>>of this message is not the intended recipient, or an employee
>>or agent responsible for delivering this message to the
>>intended recipient, you are hereby notified that any reproduction,
>>dissemination or distribution of this communication is strictly
>>prohibited. If you have received this communication in error,
>>please notify us immediately by replying to the message and
>>deleting it from your computer. Thank you. Tellabs
>>============================================================
>>
>>
>>    
>>
>
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Tue, 30 Aug 2005 23:10:09 +0000
Message-ID: <0f6601c5adb8$3967d160$c5919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Mack-Crane, T. Benjamin" <[e-mail]>, "Richard Rabbat" <[e-mail]>
Cc: "Huub van Helvoort" <[e-mail]>, <[e-mail]>
Subject: Re: Final draft of response to the OIF
Date: Wed, 31 Aug 2005 00:11:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Ben,

> A long time ago an agreement was reached to unify
> the SDH and SONET encodings, since carriers did not
> want to manage unnecessary differences.

Good motivation.

Presume that here you are not really talking about the SDH and SONET
encoding, but rather the control plane encodings.

> What implementations have done as a result of the
> bad example in RFC 3946 is unfortunate, and leads to
> interop problems -- and thus the item from the OIF.

Whether the example is bad or not clearly depends on the encoding rules
specified in the RFC.
With the clarification from the Editors, it would appear that the example
is good. Now, you can object to the encoding rules, but that doesn't mean
that the example is bad.

I have not heard of any interop problems. Centrainly the message from the
OIF did not report any such problems. My understanding is that there were
no interope problems, merely a question about intended encodings. With the
rule of "liberal in what you receive" I would not expect any interop
problems.

 > This is our opportunity to fix the example and
> removed the problem (and then folks can simplify
> their implementations).  If the difference remains,
> there will be opportunity for creating more interop
> problems (if implementations behave differently for
> the different encodings).

I'd like to clarify the extent of the simplification that you are
proposing in people's implementations. You are suggesting replacing a line
of code that says:

    if ( (rcc==1) && (ncc == 0 || ncc == 1) )

with a line of code that says

    if ( (rcc==1) && (ncc == 1) )

Why is this a big deal?

> So, rather than make things more complicated by
> modifying an accepted rule (RCC=1 requires NCC>1),
> retaining two encodings for the same signal, and
> adding notes to attempt to explain the interworking
> options, it is much easier to correct the example.

Again, I think you are misrepresenting what the authors are doing. In
their view they are not changing the rules, but correcting an editorial
mistake. In their opinion the example is already correct.

Now, I don't want to start any voting here, but I see several people who
are expressing support for the ideas in
draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying
make the change the other way. If I was to judge consensus today, it is
pretty clear how I would call it.

Let's hear some opinions from other people who have an interest in this
work.

Thanks,
Adrian


>
> This is good engineering practice, in my view.
>
> Regards,
> Ben
>
> > -----Original Message-----
> > From: Richard Rabbat [mailto:[e-mail]]
> > Sent: Tuesday, August 30, 2005 3:58 PM
> > To: Mack-Crane, T. Benjamin
> > Cc: Huub van Helvoort; Adrian Farrel; [e-mail]
> > Subject: Re: Final draft of response to the OIF
> >
> > Ben,
> > Adrian's final draft of the response is most inclusive. From what you
> > said earlier, it seems that you've already coded it in one way
> > (whichever) but are accepting both sets of values for NCC &
> > RCC (both 1 or 0).
> > Is there an engineering problem with the text of the response besides
> > that you would be able to remove those couple of lines of
> > code? if so,
> > we should solve it.
> > Richard.
> >
> >
> > Mack-Crane, T. Benjamin wrote:
> >
> > >Hi Huub,
> > >
> > >See in-line below.
> > >
> > >Regards,
> > >Ben
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Huub van Helvoort [mailto:[e-mail]]
> > >>Sent: Friday, August 26, 2005 10:56 AM
> > >>To: Mack-Crane, T. Benjamin
> > >>Cc: Adrian Farrel; [e-mail]
> > >>Subject: Re: Final draft of response to the OIF
> > >>
> > >>Hello Ben,
> > >>
> > >>You wrote:
> > >>
> > >>
> > >>
> > >>>I proposed a simple (and I think technically sound) solution to
> > >>>item #1 and saw no objections, however the answer has not changed.
> > >>>
> > >>>I do not understand the reason for different encodings for
> > >>>VC-4 and STS-3c SPE.  I think they should be the same, unless
> > >>>there is a technical need to distinguish them.
> > >>>
> > >>>
> > >>If there is agreement that they should be the same, we should
> > >>also look at higher order contiguous concatenated signals:
> > >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c
> > >>STS-768c == VC-4-256c
> > >>
> > >>
> > >
> > >These signals are already encoded the same way (for instance see
> > >examples 3 and 9 in RFC 3946).
> > >
> > >
> > >
> > >>>I also do not understand the RCC=1 NCC=1 encoding, since the rule
> > >>>contained in the current RFC actually makes more sense.
> > >>>
> > >>>
> > >>However indicating the number of signals concatenated in NCC
> > >>makes your first objective impossible: STS-3Xc == VC-4-Xc
> > >>so there will always be a difference of a factor 3 between
> > >>STS and VC-4 encoding
> > >>
> > >>
> > >
> > >All the encodings of contiguous concatenated signals use VC-4
> > >(STS-3c SPE) as the base, so the NCC values are the same.  This
> > >was done to align SONET and SDH encodings.
> > >
> > >
> > >
> > >>>If there is
> > >>>only
> > >>>one signal element, there is no contiguous concatenation,
> > >>>
> > >>>
> > >>by definition.
> > >>
> > >>In fact a single signal is always contiguous concatenated  ;-)
> > >>
> > >>
> > >>
> > >>>So I fail to see the usefulness of these encodings.
> > >>>
> > >>>
> > >>NCC = 1 would normally not occur, so it could be used for
> > >>this specific case of SONET signals transported in an
> > >>SDH world, or SDH signals transported in SONET land.
> > >>And if these signals would not cross borders the value
> > >>NCC > 1 can be used.
> > >>
> > >>
> > >
> > >The SDH and SONET encodings have been aligned in all cases
> > >except this one (VC-4, STS-3c SPE).  So these should also
> > >be aligned.
> > >
> > >
> > >
> > >>>Regards,
> > >>>Ben
> > >>>
> > >>>
> > >>Cheers, Huub.
> > >>
> > >>-- 
> > >>================================================================
> > >>              http://members.chello.nl/hhelvoort/
> > >>================================================================
> > >>Always remember that you are unique...just like everyone else...
> > >>
> > >>
> > >>
> > >============================================================
> > >The information contained in this message may be privileged
> > >and confidential and protected from disclosure. If the reader
> > >of this message is not the intended recipient, or an employee
> > >or agent responsible for delivering this message to the
> > >intended recipient, you are hereby notified that any reproduction,
> > >dissemination or distribution of this communication is strictly
> > >prohibited. If you have received this communication in error,
> > >please notify us immediately by replying to the message and
> > >deleting it from your computer. Thank you. Tellabs
> > >============================================================
> > >
> > >
> > >
> >
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the reader
> of this message is not the intended recipient, or an employee
> or agent responsible for delivering this message to the
> intended recipient, you are hereby notified that any reproduction,
> dissemination or distribution of this communication is strictly
> prohibited. If you have received this communication in error,
> please notify us immediately by replying to the message and
> deleting it from your computer. Thank you. Tellabs
> ============================================================
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 30 Aug 2005 22:35:26 +0000
Message-ID: <0ee701c5ad88$e1c18200$c5919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Clarifying the basis for new work in CCAMP
Date: Tue, 30 Aug 2005 18:15:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I have had some email seeking clarification of the basis upon which we
will construct new CCAMP drafts if/when we have new milestones within our
charter.

The text accompanying the milestones was intended to fuel the discussion
and is not proposed as part of the charter. It included the words...

>    Existing drafts
>    are referenced to indicate that work is already in progress -
>    this is not intended to provide a complete list of existing
>    drafts.

My covering email said...

> - Why isn't my I-D also cited as input material?
>   No insult intended. The current list is simply there to
>   show the ADs that work is already in progress. All I-Ds
>   will be used as input.

To clarify this still further:

The CCAMP WG drafts will be refined and submitted to the IESG by the WG.

The milestones are:
a. To have a WG draft on the subject
b. To submit that draft to the IESG

This doesn't prohibit other WG drafts near the subject, but I would assume
that we only have one draft that is precisely on target.

We will obviously need to select drafts to use as the foundations of the
WG drafts. This choice will be made on a case by case basis. In some cases
an existing draft will be used; in others we will need to start a new
draft because no pre-existing work exists, or because we need to combine
two or more existing drafts.

The point, however, is to build a WG draft out of the working group, and
then refine the draft until it is submitted.

All material is taken as input and filtered through WG consensus.

I hope this clarifies.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 30 Aug 2005 22:34:01 +0000
Message-ID: <0dde01c5ad62$8c1dca50$c5919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-05.txt 
Date: Tue, 30 Aug 2005 13:43:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Revision 04 of this document was made by the authors to include updates
after WG last call.

Revision 05 was made by me to handle purely editorial issues (formatting,
section numbering, typos) and includes no technical changes.

I will now pass this to the ADs for IESG review.

Thanks,
Adrian

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, August 29, 2005 11:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-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 : Exclude Routes - Extension to RSVP-TE
> Author(s) : A. Farrel, et al.
> Filename : draft-ietf-ccamp-rsvp-te-exclude-route-05.txt
> Pages : 26
> Date : 2005-8-29
>
> The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
>    Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
>    Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
>    Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
>    abstract nodes and resources to be explicitly included in a path
>    setup, but not to be explicitly excluded.
>
>    In some networks where precise explicit paths are not computed at the
>    head end it may be useful to specify and signal abstract nodes and
>    resources that are to be explicitly excluded from routes. These
>    exclusions may apply to the whole path, or to parts of a path between
>    two abstract nodes specified in an explicit path. How Shared Risk
>    Link Groups (SLRGs) can be excluded is also specified in this
>    document.
>
>    This document specifies ways to communicate route exclusions during
>    path setup using RSVP-TE.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] 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-rsvp-te-exclude-route-05.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:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.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.
>




Envelope-to: [e-mail]
Delivery-date: Tue, 30 Aug 2005 22:13:55 +0000
Message-ID: <0eb701c5ad81$fe3f87d0$c5919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: RFC 3946 bis
Date: Tue, 30 Aug 2005 17:43:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

In view of the issues raised on the list in March and more recently by the
OIF in their questions, I have asked the editors of RFC 3946 to prepare an
I-D that is a bis on the RFC to document what they intended to write. That
is, to document the consensus of the WG at the time the I-D was submitted
to be an RFC,

As such, this I-D is not a change to the procedures that were agreed, and
does not reflect any change in the implementation. it is simply a
clarification of what was written. In particular, it fixes a typo where
"greater than" was written and "greater than or equal to" was meant.

I note that Ben has been raising an issue that proposes a change to the
procedures documented in RFC 3946. I have not seen any support for this so
far, and I do not propose that we should make such a change to RFC 3946 in
this I-D.

Thanks to Dimitri for moving forward with these editorial changes. If you
look through the draft you will see that Dimitri has inserted notes to
highlight the changes (to make it easy for you to review and to explain
the changes).

I would like to move this I-D through the process PDQ so I will give you a
short time to read, digest and send mail. Barring any major upsets, we
will make this a WG I-D on 7th September, and then look for any other
editorial clarifications we should make at the same time, before moving
rapidly on to WG last call.

Thanks,
Adrian

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Monday, August 29, 2005 11:50 PM
Subject: I-D ACTION:draft-papadimitriou-ccamp-rfc3946bis-00.txt


> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : Generalized Multi-Protocol Label Switching
>                           (GMPLS) Extensions for Synchronous Optical
>                           Network (SONET) and Synchronous Digital
>                           Hierarchy (SDH) Control
> Author(s) : E. Mannie, D. Papadimitriou
> Filename : draft-papadimitriou-ccamp-rfc3946bis-00.txt
> Pages : 24
> Date : 2005-8-29
>
>    This document provides minor clarification to RFC 3946.
>
>    This document is a companion to the Generalized Multi-Protocol
>    Label Switching (GMPLS) signaling. It defines the Synchronous
>    Optical Network (SONET)/Synchronous Digital Hierarchy (SDH)
>    technology specific information needed when using GMPLS signaling.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-rfc3946bis-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] 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-papadimitriou-ccamp-rfc3946bis-00.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:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-papadimitriou-ccamp-rfc3946bis-00.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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>




Envelope-to: [e-mail]
Delivery-date: Tue, 30 Aug 2005 21:51:21 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Final draft of response to the OIF
Date: Tue, 30 Aug 2005 16:48:39 -0500
Message-ID: <[e-mail]>
Thread-Topic: Final draft of response to the OIF
Thread-Index: AcWtpbcSdsIcyKOURZS82NqCXAxtoQABMWHQ
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Richard Rabbat" <[e-mail]>
Cc: "Huub van Helvoort" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

Hi Richard,

A long time ago an agreement was reached to unify
the SDH and SONET encodings, since carriers did not
want to manage unnecessary differences.

What implementations have done as a result of the
bad example in RFC 3946 is unfortunate, and leads to
interop problems -- and thus the item from the OIF.

This is our opportunity to fix the example and
removed the problem (and then folks can simplify
their implementations).  If the difference remains,
there will be opportunity for creating more interop
problems (if implementations behave differently for
the different encodings).

So, rather than make things more complicated by
modifying an accepted rule (RCC=1 requires NCC>1),
retaining two encodings for the same signal, and
adding notes to attempt to explain the interworking
options, it is much easier to correct the example.

This is good engineering practice, in my view.

Regards,
Ben

> -----Original Message-----
> From: Richard Rabbat [mailto:[e-mail]] 
> Sent: Tuesday, August 30, 2005 3:58 PM
> To: Mack-Crane, T. Benjamin
> Cc: Huub van Helvoort; Adrian Farrel; [e-mail]
> Subject: Re: Final draft of response to the OIF
> 
> Ben,
> Adrian's final draft of the response is most inclusive. From what you 
> said earlier, it seems that you've already coded it in one way 
> (whichever) but are accepting both sets of values for NCC & 
> RCC (both 1 
> or 0).
> Is there an engineering problem with the text of the response besides 
> that you would be able to remove those couple of lines of 
> code? if so, 
> we should solve it.
> Richard.
> 
> 
> Mack-Crane, T. Benjamin wrote:
> 
> >Hi Huub,
> >
> >See in-line below.
> >
> >Regards,
> >Ben
> >
> >  
> >
> >>-----Original Message-----
> >>From: Huub van Helvoort [mailto:[e-mail]] 
> >>Sent: Friday, August 26, 2005 10:56 AM
> >>To: Mack-Crane, T. Benjamin
> >>Cc: Adrian Farrel; [e-mail]
> >>Subject: Re: Final draft of response to the OIF
> >>
> >>Hello Ben,
> >>
> >>You wrote:
> >>
> >>    
> >>
> >>>I proposed a simple (and I think technically sound) solution to
> >>>item #1 and saw no objections, however the answer has not changed.
> >>>
> >>>I do not understand the reason for different encodings for
> >>>VC-4 and STS-3c SPE.  I think they should be the same, unless
> >>>there is a technical need to distinguish them.
> >>>      
> >>>
> >>If there is agreement that they should be the same, we should
> >>also look at higher order contiguous concatenated signals:
> >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c
> >>STS-768c == VC-4-256c
> >>    
> >>
> >
> >These signals are already encoded the same way (for instance see
> >examples 3 and 9 in RFC 3946).
> >
> >  
> >
> >>>I also do not understand the RCC=1 NCC=1 encoding, since the rule
> >>>contained in the current RFC actually makes more sense. 
> >>>      
> >>>
> >>However indicating the number of signals concatenated in NCC
> >>makes your first objective impossible: STS-3Xc == VC-4-Xc
> >>so there will always be a difference of a factor 3 between
> >>STS and VC-4 encoding
> >>    
> >>
> >
> >All the encodings of contiguous concatenated signals use VC-4
> >(STS-3c SPE) as the base, so the NCC values are the same.  This
> >was done to align SONET and SDH encodings.
> >
> >  
> >
> >>>If there is
> >>>only
> >>>one signal element, there is no contiguous concatenation, 
> >>>      
> >>>
> >>by definition.
> >>
> >>In fact a single signal is always contiguous concatenated  ;-)
> >>
> >>    
> >>
> >>>So I fail to see the usefulness of these encodings.
> >>>      
> >>>
> >>NCC = 1 would normally not occur, so it could be used for
> >>this specific case of SONET signals transported in an
> >>SDH world, or SDH signals transported in SONET land.
> >>And if these signals would not cross borders the value
> >>NCC > 1 can be used.
> >>    
> >>
> >
> >The SDH and SONET encodings have been aligned in all cases
> >except this one (VC-4, STS-3c SPE).  So these should also
> >be aligned.
> >
> >  
> >
> >>>Regards,
> >>>Ben
> >>>      
> >>>
> >>Cheers, Huub.
> >>
> >>-- 
> >>================================================================
> >>              http://members.chello.nl/hhelvoort/
> >>================================================================
> >>Always remember that you are unique...just like everyone else...
> >>
> >>    
> >>
> >============================================================
> >The information contained in this message may be privileged
> >and confidential and protected from disclosure. If the reader
> >of this message is not the intended recipient, or an employee
> >or agent responsible for delivering this message to the
> >intended recipient, you are hereby notified that any reproduction,
> >dissemination or distribution of this communication is strictly
> >prohibited. If you have received this communication in error,
> >please notify us immediately by replying to the message and
> >deleting it from your computer. Thank you. Tellabs
> >============================================================
> >
> >  
> >
> 
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================



Envelope-to: [e-mail]
Delivery-date: Tue, 30 Aug 2005 21:00:34 +0000
Message-ID: <[e-mail]>
Date: Tue, 30 Aug 2005 13:57:59 -0700
From: Richard Rabbat <[e-mail]>
Organization: Fujitsu Labs of America
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: "Mack-Crane, T. Benjamin" <[e-mail]>
CC: Huub van Helvoort <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: Final draft of response to the OIF
Content-Type: multipart/mixed; boundary="------------010407070100000003070807"

This is a multi-part message in MIME format.
--------------010407070100000003070807
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ben,
Adrian's final draft of the response is most inclusive. From what you 
said earlier, it seems that you've already coded it in one way 
(whichever) but are accepting both sets of values for NCC & RCC (both 1 
or 0).
Is there an engineering problem with the text of the response besides 
that you would be able to remove those couple of lines of code? if so, 
we should solve it.
Richard.


Mack-Crane, T. Benjamin wrote:

>Hi Huub,
>
>See in-line below.
>
>Regards,
>Ben
>
>  
>
>>-----Original Message-----
>>From: Huub van Helvoort [mailto:[e-mail]] 
>>Sent: Friday, August 26, 2005 10:56 AM
>>To: Mack-Crane, T. Benjamin
>>Cc: Adrian Farrel; [e-mail]
>>Subject: Re: Final draft of response to the OIF
>>
>>Hello Ben,
>>
>>You wrote:
>>
>>    
>>
>>>I proposed a simple (and I think technically sound) solution to
>>>item #1 and saw no objections, however the answer has not changed.
>>>
>>>I do not understand the reason for different encodings for
>>>VC-4 and STS-3c SPE.  I think they should be the same, unless
>>>there is a technical need to distinguish them.
>>>      
>>>
>>If there is agreement that they should be the same, we should
>>also look at higher order contiguous concatenated signals:
>>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c
>>STS-768c == VC-4-256c
>>    
>>
>
>These signals are already encoded the same way (for instance see
>examples 3 and 9 in RFC 3946).
>
>  
>
>>>I also do not understand the RCC=1 NCC=1 encoding, since the rule
>>>contained in the current RFC actually makes more sense. 
>>>      
>>>
>>However indicating the number of signals concatenated in NCC
>>makes your first objective impossible: STS-3Xc == VC-4-Xc
>>so there will always be a difference of a factor 3 between
>>STS and VC-4 encoding
>>    
>>
>
>All the encodings of contiguous concatenated signals use VC-4
>(STS-3c SPE) as the base, so the NCC values are the same.  This
>was done to align SONET and SDH encodings.
>
>  
>
>>>If there is
>>>only
>>>one signal element, there is no contiguous concatenation, 
>>>      
>>>
>>by definition.
>>
>>In fact a single signal is always contiguous concatenated  ;-)
>>
>>    
>>
>>>So I fail to see the usefulness of these encodings.
>>>      
>>>
>>NCC = 1 would normally not occur, so it could be used for
>>this specific case of SONET signals transported in an
>>SDH world, or SDH signals transported in SONET land.
>>And if these signals would not cross borders the value
>>NCC > 1 can be used.
>>    
>>
>
>The SDH and SONET encodings have been aligned in all cases
>except this one (VC-4, STS-3c SPE).  So these should also
>be aligned.
>
>  
>
>>>Regards,
>>>Ben
>>>      
>>>
>>Cheers, Huub.
>>
>>-- 
>>================================================================
>>              http://members.chello.nl/hhelvoort/
>>================================================================
>>Always remember that you are unique...just like everyone else...
>>
>>    
>>
>============================================================
>The information contained in this message may be privileged
>and confidential and protected from disclosure. If the reader
>of this message is not the intended recipient, or an employee
>or agent responsible for delivering this message to the
>intended recipient, you are hereby notified that any reproduction,
>dissemination or distribution of this communication is strictly
>prohibited. If you have received this communication in error,
>please notify us immediately by replying to the message and
>deleting it from your computer. Thank you. Tellabs
>============================================================
>
>  
>

--------------010407070100000003070807
Content-Type: text/x-vcard; charset=utf-8;
 name="richard.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="richard.vcf"

begin:vcard
fn:Richard Rabbat
n:Rabbat;Richard
org:Fujitsu Labs of America;IP Networking Research
adr:MS 345;;1240 East Arques Ave;Sunnyvale;CA;94085;USA
email;internet:[e-mail]
title:Senior Project Manager
tel;work:1-408-530-4537
tel;fax:[phone]
tel;cell:1-650-714-7618
x-mozilla-html:TRUE
version:2.1
end:vcard


--------------010407070100000003070807--



Envelope-to: [e-mail]
Delivery-date: Mon, 29 Aug 2005 22:51:51 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-05.txt 
Message-Id: <[e-mail]>
Date: Mon, 29 Aug 2005 18:50:01 -0400

--NextPart

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		: Exclude Routes - Extension to RSVP-TE
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-rsvp-te-exclude-route-05.txt
	Pages		: 26
	Date		: 2005-8-29
	
The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
   Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
   Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
   abstract nodes and resources to be explicitly included in a path
   setup, but not to be explicitly excluded.

   In some networks where precise explicit paths are not computed at the
   head end it may be useful to specify and signal abstract nodes and
   resources that are to be explicitly excluded from routes. These
   exclusions may apply to the whole path, or to parts of a path between
   two abstract nodes specified in an explicit path. How Shared Risk
   Link Groups (SLRGs) can be excluded is also specified in this
   document.

   This document specifies ways to communicate route exclusions during
   path setup using RSVP-TE.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-rsvp-te-exclude-route-05.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rsvp-te-exclude-route-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Mon, 29 Aug 2005 14:17:17 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Final draft of response to the OIF
Date: Mon, 29 Aug 2005 09:11:32 -0500
Message-ID: <[e-mail]>
Thread-Topic: Final draft of response to the OIF
Thread-Index: AcWqV26XP5LabOwhTMKk34aYghybOwCSkKug
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Huub van Helvoort" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

Hi Huub,

See in-line below.

Regards,
Ben

> -----Original Message-----
> From: Huub van Helvoort [mailto:[e-mail]] 
> Sent: Friday, August 26, 2005 10:56 AM
> To: Mack-Crane, T. Benjamin
> Cc: Adrian Farrel; [e-mail]
> Subject: Re: Final draft of response to the OIF
> 
> Hello Ben,
> 
> You wrote:
> 
> > I proposed a simple (and I think technically sound) solution to
> > item #1 and saw no objections, however the answer has not changed.
> > 
> > I do not understand the reason for different encodings for
> > VC-4 and STS-3c SPE.  I think they should be the same, unless
> > there is a technical need to distinguish them.
> 
> If there is agreement that they should be the same, we should
> also look at higher order contiguous concatenated signals:
> i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c
> STS-768c == VC-4-256c

These signals are already encoded the same way (for instance see
examples 3 and 9 in RFC 3946).

> 
> > I also do not understand the RCC=1 NCC=1 encoding, since the rule
> > contained in the current RFC actually makes more sense. 
> 
> However indicating the number of signals concatenated in NCC
> makes your first objective impossible: STS-3Xc == VC-4-Xc
> so there will always be a difference of a factor 3 between
> STS and VC-4 encoding

All the encodings of contiguous concatenated signals use VC-4
(STS-3c SPE) as the base, so the NCC values are the same.  This
was done to align SONET and SDH encodings.

> 
> > If there is
> > only
> > one signal element, there is no contiguous concatenation, 
> by definition.
> 
> In fact a single signal is always contiguous concatenated  ;-)
> 
> > So I fail to see the usefulness of these encodings.
> 
> NCC = 1 would normally not occur, so it could be used for
> this specific case of SONET signals transported in an
> SDH world, or SDH signals transported in SONET land.
> And if these signals would not cross borders the value
> NCC > 1 can be used.

The SDH and SONET encodings have been aligned in all cases
except this one (VC-4, STS-3c SPE).  So these should also
be aligned.

> 
> > Regards,
> > Ben
> 
> Cheers, Huub.
> 
> -- 
> ================================================================
>               http://members.chello.nl/hhelvoort/
> ================================================================
> Always remember that you are unique...just like everyone else...
> 
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================



Envelope-to: [e-mail]
Delivery-date: Fri, 26 Aug 2005 23:41:28 +0000
Message-ID: <[e-mail]>
Date: Fri, 26 Aug 2005 19:54:07 +0200
From: Huub van Helvoort <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: ccamp <[e-mail]>
Subject: Re: Final draft of response to the OIF
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Ben,

You wrote:

> I proposed a simple (and I think technically sound) solution to
> item #1 and saw no objections, however the answer has not changed.
> 
> I do not understand the reason for different encodings for
> VC-4 and STS-3c SPE.  I think they should be the same, unless
> there is a technical need to distinguish them.

If there is agreement that they should be the same, we should
also look at higher order contiguous concatenated signals:
i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c
STS-768c == VC-4-256c

> I also do not understand the RCC=1 NCC=1 encoding, since the rule
> contained in the current RFC actually makes more sense. 

However indicating the number of signals concatenated in NCC
makes your first objective impossible: STS-3Xc == VC-4-Xc
so there will always be a difference of a factor 3 between
STS and VC-4 encoding

> If there is
> only
> one signal element, there is no contiguous concatenation, by definition.

In fact a single signal is always contiguous concatenated  ;-)

> So I fail to see the usefulness of these encodings.

NCC = 1 would normally not occur, so it could be used for
this specific case of SONET signals transported in an
SDH world, or SDH signals transported in SONET land.
And if these signals would not cross borders the value
NCC > 1 can be used.

> Regards,
> Ben

Cheers, Huub.

-- 
================================================================
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...



Envelope-to: [e-mail]
Delivery-date: Fri, 26 Aug 2005 17:42:53 +0000
Message-ID: <0c2201c5aa65$e0b4c7d0$c5919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>, "'Jean Philippe Vasseur'" <[e-mail]>
Cc: <[e-mail]>
Subject: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
Date: Fri, 26 Aug 2005 18:42:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

In Paris you said that you hoped for comments on this revision soon so
that you could do a quick re-spin and request last call.

So here are my comments.

Cheers,
Adrian

===

Section 2.1
   Contiguous - A contiguous TE LSP is a single end-to-end TE LSP that
   is setup across multiple domains using RSVP-TE signaling procedures
   described in [RSVP-TE]and [RSVP-GMPLS]. No additional TE LSPs are
   required to signal a contiguous TE LSP and the same RSVP-TE
   information for the TE LSP is maintained along the entire LSP path.
s/[RSVP-TE]and/[RSVP-TE] and/

====

Section 2.1
   Nesting - Nesting one or more TE LSPs into another TE LSP is
   described in [LSP-HIERARCHY]. This technique can also be used to nest
   one or more inter-domain TE LSPs into an intra-domain FA-LSP. While
   similar to stitching in the control plane, in the data plane, nesting
   allows for one or more inter-domain LSPs to be transported over a
   single intra-domain FA-LSP using the label stacking construct.
s/technique can also be used/technique can be used/

Not sure that I like you saying "FA-LSP" here. The intra-domain LSP may be
an FA-LSP or it may be a TE LSP advertised as a TE link into the other
domain.

It's a bit odd to compare with stitching which you haven't described yet.
Suggest you re-write the paragraph as...
   Nesting - Nesting one or more TE LSPs into another TE LSP is
   described in [LSP-HIERARCHY]. This technique can be used to nest
   one or more inter-domain TE LSPs into an intra-domain TE LSP
   using the label stacking construct.

====

Section 2.1
   Stitching - The concept of LSP stitching as well as the required
   signaling procedures are described in [LSP-STITCHING]. This technique
   can be used to stitch an inter-domain TE LSP to an intra-domain LSP
   segment. A inter-domain stitched TE LSP is a TE LSP made up of
   different TE LSP segments within each domain which are "stitched"
   together in the data plane so that an end-to-end LSP is achieved in
   the data plane. In the control plane, however, the different LSP
   segments are signaled as distinct RSVP sessions which are independent
   from the RSVP session for the inter-domain LSP.
s/signaling procedures are described/signaling procedures is described/
(yes, really)

You could add the comparison with hierarchies here. For example...
   While stitching is similar to nesting in the control plane, in the data
plane
   stitching allows for only one inter-domain LSPs to be associated with
   any one intra-domain LSP, but does not require the use of label stacks.

====

Section 2.1

I think this section should say that later in the document you will define
signaling extensions that allow the initiator of an inter-domain LSP to
request the type of signaling technique used. This will help the flow of
section 3.

====

Section 3 and 3.1
Could you format the bullet paragraphs better, please.

====

Section 3

   Whether an inter-domain TE LSP is contiguous, nested or stitched is
   determined mostly by the signaling method supported by or configured
   on the intermediate nodes, usually the domain boundary nodes that the
   inter-domain TE LSP traverses through. It may also depend on certain
s/traverses through/traverses/

====

Section 3

   inter-domain TE LSP traverses through. It may also depend on certain
   parameters signaled by the head-end node for the inter-domain TE LSP.

s/may also depend/also depends/
s/parameters signaled by/parameters that may be signaled by/

====

Section 3, second bullet.

Is it possible that the policies or capabilities at the boundary node
prohibit the support of the mechanism that is signaled?
If yes, you should add a note describing rejection.
If no, you should add "MUST use the mechanism requested in the signaling
message"

===

Section 3, 4th and 7th bullets

"Determine the next hop node" seems to be in conflict with "perform any
path computation".
I guess that when you say "determine the next hop node" you mean find the
next sub-object in the ERO, or determine the destination or next boundary
node.

====

Section 3.1
I would prefer you to say hierarchical LSP rather than FA-LSP.

====

Section 3.1
Please avoid using the word "appropriate".
For example...
   then a PathErr with the appropriate error code should be sent back
Please supply the actual error code that should be used. (Also use
"SHOULD".)

====

Section 3.1
Should you also describe the case where there is no ERO?

====

Section 3.2

   The propagation of Path Error
   upstream may be limited to within the domain or it may be sent all
   the way upstream to the head-end node of the inter-domain TE LSP.

This sounds as though a domain boundary is allowed to silently swallow the
PathErr message. I understand that you mean that a domain boundary may
attempt re-routing, but that is not what you have said.

====

Section 3.2

Your discussion of crankback is limited to attempting to select another
egress boundary node. This would certainly apply when a failure from a
downstream domain is reported to the ingress boundary node of an upstream
domain. However, you should also cover the case where the failure is
within the domain and the ingress boundary node attempts to re-route
within the domain.

====

Section 3.2

When a PathErr crosses a domain boundary it may be subject to policy and
aggregation of information. I think you should describe this.

====

Section 4.1 (also section 9.1)
   0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end
   node that originates the inter-domain TE LSP if it desires a
   contiguous end-to-end TE LSP (in the control & data plane). When set,
   this indicates that a boundary node MUST not perform any stitching or
   nesting on the TE LSP and the TE LSP MUST be routed as any other TE
   LSP (it must be contiguous end to end). When this bit is cleared, a
   boundary node may decide to perform stitching or nesting. A mid-point
   node not supporting contiguous TE LSP MUST send a Path Error message

a. s/MUST not/MUST NOT/
b. I have allocated bit number 4 (0x08) in the temporary registry of
LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp-attrib.txt as
a place holder until the IANA takes over this work. (I think we've
discussed this before -  the point of the temporary registry is to save
you having to change your code too often.)

====

Section 4.1 (and section 9.1)
Given that you have chosen to place you LSP Attributes bit in the optional
(transparent) version of the object, you may want to consider how you will
police its use. For example, what would happen if a domain boundary
ignored this flag?
The LSP Attributes draft suggests the use of the flag in the RRO in order
to record whether it has been acted on (if not recorded, then not acted on
and it is possible that nesting has been used). You might want to adopt
this procedure, too.

====

Section 5.1

        <-- AS-1 --->      <--- AS-2 --->        <-- AS-3 --> c

Spurious letter "c"

====

Section 5.1

You figure shows R7 connected to the egress CE, but your example says...
   - A protected inter-AS TE LSP T1 originated at R0 in AS1 and
   terminating at R6 in AS3 with following possible paths:

====

Section 5.1

Your example starts to talk about building a protected inter-AS LSP. But
it transpires that you propose using FRR to provide protection for the
resources used by a single unprotected LSP. I think you need to be careful
with your terminology.

====

Section 5.1

   - A protected inter-AS TE LSP T1 originated at R0 in AS1 and
   terminating at R6 in AS3 with following possible paths:

   LSP hops: R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6

   o p1 - a set of loose node hops crossing AS-2
     R0-X1-ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R6

   o p2 - a set of strict interface hops crossing AS-2
     R0-X1-ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict)
     -link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R6

You need to be careful. What do you mean by "LSP hops"? Is this the path
of the LSP? In which case why are be bothering with the example?

On the other hand, what are p1 and p2? Are they possible paths? In which
case how can they have loose or strict hops? They must actually be
explicit routes (i.e. EROs). So why have you chosen this set of two EROs
when there are so many others possible?

====

Section 5.1

If you must use FRR in an example (although I can't see the value at all)
you need to get the example right.
B3 as quoted (ASBR1-ASBR2-ASBR3-ASBR6-ASBR7) is impossible on your
topology.
You probably mean ASBR1-ASBR2-ASBR3-ASBR6-R4-ASBR8-ASBR7


Similarly, B5 is not possible. You probably mean
ASBR4-ASBR5-ASBR6-R4-ASBR8-ASBR10-ASBR9

====

Section 5.2
   Let us consider an inter-AS TE LSP setup from R0 to R6, with example
   paths p1, p2 each.
Delete "each"

====

Section 5.2

What was the point of the discussion of the FRR bypass tunnels? They
didn't feature in the example at all, and only served to add confusion.
It would seem that you should move the discussion of FRR into section 6.

====

Section 6.1.3

   For each protected inter-domain TE LSP traversing the boundary node
   to be protected, a NNHOP backup must be selected by the PLR. This
   requires the PLR to setup a bypass tunnel terminating at the NNHOP.
   Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be
   achieved by analyzing the content of the RRO object received in the
   RSVP Resv message of both the bypass tunnel and the protected TE
   LSP(s) (see [NODE-ID]).

You need to be clear (as you are for tunneled and stitched cases) that for
inter-domain LSPs the RRO may well be masked. That is, in your example,
the RRO reaching the PLR ASBR1 will only contain hops ASBR4 and ASBR7 (R3
having been masked as confidential). The AS number may have been inserted.
So your tunnel B2 will not do the job and B3 will be needed (even though
B2 is functional, you can't use it because you don't know whether it is
functional).

Further, as you pointed out earlier in the document, local policy may
prevent the setup of TE LSPs that terminate within the domain. So B2 might
not exist.

Same comments do not apply to the use of B4 because it starts within the
upstream domain.

====

Section 6.2

This section looks to be a bit pointless. What are you trying to say?

Certainly you have not covered the need for disjoint paths (which is out
of scope) but doesn't just work without some effort.
You also haven't mentioned segment protection that applies signaling
control to the positioning of one-to-one protection tunnels.

====

Section 7
   The above mechanisms SHOULD be used for a contiguous inter-domain TE
   LSP to allow the head-end node of the inter-domain TE LSP to initiate
   make-before-break procedures.
You may want to relax this "SHOULD" in the light of [LOOSE-REOPT] being
informational, and describe the alternative procedures for reoptimization
of contiguous LSPs.

====

Notify messages.
You haven't described how Notify messages may be handled with respect to
domain boundaries.

====

Section 11.2
I don't think you need to reference RSVP-UNNUM or BUNDLING.






Envelope-to: [e-mail]
Delivery-date: Fri, 26 Aug 2005 17:24:59 +0000
Date: Fri, 26 Aug 2005 10:23:44 -0700
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
Message-ID: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
CC: "Bill Fenner" <[e-mail]>, [e-mail]
Subject: Re: CCAMP Requests to add new milestones to its charter
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Adrian,

  Ack. Will review and discuss with the WG chairs.

-- 
Alex
http://www.psg.com/~zinin

Wednesday, August 24, 2005, 4:50:52 AM, Adrian Farrel wrote:
> Hi Alex and Bill,

> The CCAMP working group has had further discussions about the potential
> work it could do over the next 1.5 to 2 years. This has led us to produce
> the following set of milestones with which there appears to be
> overwhelming consensual support within the working group.

> Therefore, we would like to ask you to arrange for us to have these
> milestones added to our charter.

> You will notice that the proposed milestones are unusually detailed. At
> the moment we feel that this is important to help focus the working group
> into the right activities and to ensure that we deliver. We could (of
> course) drop the interim milestones from the charter if this would make
> people more comfortable - we can still run the detailed milestones for our
> own benefit.

> At this stage we feel that it is not essential to modify the text of our
> charter. Although we could take this opportunity to tidy it up and improve
> the focus, we feel that all of the proposed milestones fall within the
> existing charter work.

> Please let us know your thoughts and what the next steps should be.

> Thanks,
> Adrian and Kireeti
> ====
> Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS
> and OSPF
> Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh
> membership
> Nov 05 Submit ASON Routing evaluation I-D for IESG review
> Nov 05 First version of WG I-D on path computation implementation advice
> Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS
> and OSPF
> Nov 05 First version WG I-D MPLS to GMPLS migration strategies
> Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS
> Nov 05 First version WG I-D Change of LSP ownership between management and
> control planes
> Dec 05 First version of WG I-D for ASON Routing solutions
> Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG
> review
> Dec 05 Submit Per-domain path computation signaling I-D for IESG review
> Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region
> Networks
> Dec 05 First version WG I-D for Evaluation of existing protocols for
> MLN/MRN
> Dec 05 First version WG I-D for Protocol solutions for MLN/MRN
> Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG
> review
> Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review
> Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module
> Jan 06 First version WG Informational I-D for Analysis of inter-domain
> issues for disjoint and protected paths
> Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF
> for IESG review
> Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and
> solutions
> Jan 06 First version WG I-D GMPLS OAM Requirements
> Jan 06 First version WG I-D Routing and signaling for link viability
> constraints
> Feb 06 Submit LSP Stitching I-D for IESG review
> Mar 06 First version of WG informational I-D Aligning GMPLS protocols
> across the standards bodies
> Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for
> IESG review
> Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module
> Mar 06 First version of WG I-D for additional MIB module to cover RSVP-TE
> signaling extensions
> Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for
> IESG review
> Jun 06 Submit Informational I-D for Analysis of inter-domain issues for
> disjoint and protected paths for IESG review
> Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review
> Jun 06 Submit Change of LSP ownership between management and control
> planes I-D for IESG review
> Aug 06 Submit path computation implementation advice I-D for IESG review
> Oct 06 Submit ASON Routing solutions I-D for IESG review
> Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D
> for IESG review
> Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG review
> Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for
> IESG review
> Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review
> Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
> Dec 06 Submit GMPLS OAM Requirements I-D for IESG review
> Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review
> Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review
> Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor
> and IESG review
> Oct 07 Submit Routing and signaling for link viability constraints I-D for
> IESG review
> Oct 07 Recharter or close Working Group





Envelope-to: [e-mail]
Delivery-date: Fri, 26 Aug 2005 15:01:18 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Final draft of response to the OIF
Date: Fri, 26 Aug 2005 09:57:07 -0500
Message-ID: <[e-mail]>
Thread-Topic: Final draft of response to the OIF
Thread-Index: AcWqMXrRFH6Zn8PbTZ+MdFV9yog1bAAHBWYQ
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

Hi Adrian,

I proposed a simple (and I think technically sound) solution to
item #1 and saw no objections, however the answer has not changed.

I do not understand the reason for different encodings for
VC-4 and STS-3c SPE.  I think they should be the same, unless
there is a technical need to distinguish them.

I also do not understand the RCC=1 NCC=1 encoding, since the rule
contained in the current RFC actually makes more sense.  If there is
only
one signal element, there is no contiguous concatenation, by definition.
So I fail to see the usefulness of these encodings.

Regards,
Ben

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Friday, August 26, 2005 6:27 AM
> To: [e-mail]
> Subject: Final draft of response to the OIF
> 
> Thanks to all who have commented so far.
> 
> Here is an updated draft. I plan to send by the end of 
> August, so furhter
> comments should be made quickly.
> 
> Thanks,
> Adrian
> 
> ======
> 
> To: Jim Jones, OIF Technical Committee Chair
> From: Adrian Farrel and Kireeti Kompella,
>           WG Co-Chairs for IETF CCAMP
> Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors
> Subject: Response to your questions about GMPLS parameters.
> 
> Dear Jim,
> 
> Thanks for your correspondence about the questions with 
> respect to GMPLS
> parameters that arose before and during your interoperability testing.
> CCAMP is pleased to receive such questions and is glad to have the
> opportunity to explain the intended operation of the GMPLS protocols.
> 
> Much of the material supplied below can be simply extracted from the
> relevant RFCs.
> 
> > 1. Use of the NCC and RCC fields for STS-3c/VC-4 connections
> >
> > During OIF testing it was noted that some ambiguity exists in the
> > specification of encoding of NCC, RCC and NVC for certain types of
> > connections: NCC and RCC for an STS-3c/VC-4 connection can 
> be set to 0
> or
> > to 1 depending on which example of RFC 3946 is followed.
> >
> > Clarification is requested from IETF CCAMP as to which setting is
> > considered correct, or if both settings should be accepted (this
> procedure
> > was used during testing at Supercomm).
> 
> This question about RFC 3946 was raised informally on the 
> CCAMP mailing
> list at the start of March this year.
> 
> Even when the signal Type value is the same (i.e. value 6) 
> the NCC, RCC
> and NVC values depend on the specific signal being requested.
> 
> From the examples in the annex we have...
> 
>    A VC-4 signal is formed by applying the following
>    settings to a VC-4 Elementary Signal.
>       RCC = 0
>       NCC = 0
>       NVC = 0
>       MT  = 1
>       T   = 0
> 
>    An STS-3c SPE signal is formed by applying the following
>    settings to an STS-3c SPE Elementary Signal.
>       RCC = 1 (standard contiguous concatenation)
>       NCC = 1
>       NVC = 0
>       MT  = 1
>       T   = 0
> 
> Your question probably arises from the two notes and 
> subsequent paragraph
> in section 2.1 or RFC 3946. Here it says...
> 
>    Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the
>       Elementary Signal to use must always be an STS-3c_SPE 
> signal type
>       and the value of NCC must always be equal to X.  This 
> allows also
>       facilitating the interworking between SONET and SDH.  In
>       particular, it means that the contiguous concatenation of three
>       STS-1 SPEs can not be requested because according to this
>       specification, this type of signal must be coded using 
> the STS-3c
>       SPE signal type.
> 
>    Note 2: when requesting a transparent STS-N/STM-N signal
>       limited to a single contiguously concatenated 
> STS-Nc_SPE/VC-4-Nc,
>       the signal type must be STS-N/STM-N, RCC with flag 1 and NCC set
>       to 1.
> 
>    The NCC value must be consistent with the type of contiguous
>    concatenation being requested in the RCC field.  In 
> particular, this
>    field is irrelevant if no contiguous concatenation is 
> requested (RCC
>    = 0), in that case it must be set to zero when sent, and should be
>    ignored when received.  A RCC value different from 0 must imply a
>    number of contiguous components greater than 1.
> 
> We believe that this final sentence should read "greater than 
> or equal to
> 1," and that this interpretation resolves all of your issues 
> and makes the
> text consistent with the examples.
> 
> We plan to issue a revision to RFC 3946 to make this 
> clarification. The
> text of this clarification still needs to be agreed by the 
> CCAMP working
> group, but the draft revision contains the nodes as updated 
> below with the
> addition of a third note as shown.
> 
>    Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the
>       Elementary Signal to use must always be an STS-3c_SPE 
> signal type
>       and the value of NCC must always be equal to X. This allows also
>       facilitating the interworking between SONET and SDH. In
>       particular, it means that the contiguous concatenation of three
>       STS-1 SPEs can not be requested because according to this
>       specification, this type of signal must be coded using 
> the STS-3c
>       SPE signal type.
> 
>    Note 2: when requesting a transparent STS-N/STM-N signal limited to
>       a single contiguously concatenated STS-Nc_SPE/VC-4-Nc, 
> the signal
>       type must be STS-N/STM-N, RCC with flag 1 and NCC set to 1.
> 
>       The NCC value must be consistent with the type of contiguous
>       concatenation being requested in the RCC field. In particular,
>       this field is irrelevant if no contiguous concatenation is
>       requested (RCC = 0), in that case it must be set to zero when
>       sent, and should be ignored when received. A RCC value different
>       from 0 implies a number of contiguous components greater than or
>       equal to 1.
> 
>    Note 3: Following these rules, when requesting a VC-4 signal, the
>       RCC and the NCC values must be set to 0 whereas for an 
> STS-3c SPE
>       signal, the RCC and the NCC values must be set 1. However, if
>       local conditions allow and since the setting of the RCC and NCC
>       values is locally driven, the requesting upstream node MAY set
>       the RCC and NCC values to either SDH or SONET settings without
>       impacting the function. Moreover, the downstream node SHOULD
>       accept the requested values if local conditions allow. If these
>       values can not be supported, the receiver downstream node MUST
>       generate a PathErr/NOTIFICATION message (see Sections 2.2 and
>       2.3, respectively).
> 
> > 2. Setting of NVC for VCAT connections
> >
> > It was also noted that the setting of NVC may be somewhat 
> ambiguous for
> > the case where diverse connections are used within a single 
> VCAT group.
> > Each individual RSVP session controls a single connection, but the
> > connection is part of a larger VCAT group and carries VCAT 
> encoding of
> the
> > H4 byte. Clarification is requested from IETF CCAMP and 
> ITU-T Q.14/15 as
> > to the correct setting of NVC for this case (0 or 1?). It should be
> noted
> > that this case may occur with a VCAT group with only a 
> single initial
> > member, and that the NVC may provide an indication that 
> VCAT encoding of
> > the H4 byte is in use for the connection.
> 
> A VCn-Xv group split into X components requires each of its 
> component to
> be signaled with the NVC value set to 1. This setting is 
> regardless of how
> the components are established.
> 
> > 3. Length of the Interface Switching Capability TLV
> >
> > Although the Interface Switching Capability TLV defined by CCAMP for
> > SONET/SDH connections was not used for the testing, it was 
> noted that
> the
> > text describing the length of the Interface Switching Capability TLV
> > defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt 
> may be slightly
> > ambiguous due to the use of padding bytes.
> >
> > RFC 3630 states that "The TLV is padded to four-octet 
> alignment; padding
> > is not included in the length field (so a three octet value 
> would have a
> > length of three, but the total size of the TLV would be 
> eight octets)."
> 
> Yes. Section 2.3.2 of RFC3630 gives a definitive statement of 
> the meaning
> of the length field and the use of padding, and provides an example.
> 
> > Reading of the encoding in 
> draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
> > specifies that the length of the TLV for TDM is 41 bytes 
> plus 3 bytes of
> > padding, and should be given in the length field as 41 
> bytes rather than
> > 44. OIF requests verification of this interpretation from 
> the experts in
> > IETF CCAMP group.
> 
> Note that the Interface Switching Capability Descriptor defined in
> draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link
> TLV. Sub-TLVs and TLVs follow the same encoding rules.
> 
> The ISCD TLV for TDM contains the following fields...
>   type       2 bytes
>   length     2 bytes
>   ---
>   switch cap 1 byte
>   encoding   1 byte
>   reserve    2 bytes
>   LSP b/w 0  4 bytes
>   LSP b/w 1  4 bytes
>   LSP b/w 2  4 bytes
>   LSP b/w 3  4 bytes
>   LSP b/w 4  4 bytes
>   LSP b/w 5  4 bytes
>   LSP b/w 6  4 bytes
>   LSP b/w 7  4 bytes
>   min b/w    4 bytes
>   indication 1 byte
>             ==
>             41 bytes
> 
> We presume that your question relates to whether the 3-byte 
> field shown as
> "padding" in the TDM-specific figure on page 6 of
> draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an
> explicit field.
> 
> It is an implicit field, and should not be included in the 
> length of the
> TLV.
> 
> Nevertheless, we take this opportunity to remind the OIF that
> implementations of GMPLS protocols should be conservative in what they
> send and liberal in what they receive. Thus, an implementation that
> receives a TDM ISCD TLV with length 44 should not reject the 
> TLV for this
> reason. It should parse the TLV according to the defined 
> fields and skip
> the final three bytes. Thus, it should not affect a receiving
> implementation if the sending implementation has treated the "padding"
> field as implicit or explicit. In the event that a receiving
> implementation rejected such a TLV on grounds of the value 
> contained in
> the length field being too large, the fault would lie with 
> the receiving
> implementation not the sending implementation.
> 
> > 4. Use of ADMIN_STATUS in an initial PATH message
> >
> > Some implementations sent an ADMIN_STATUS object with no 
> flags set in
> the
> > initial PATH message, i.e., when no status change was being 
> requested.
> > Although this did not serve any particular function, it was believed
> that
> > this could be accepted as RFC3473, sect. 7.2 (page 18) states:
> >
> > "The absence of the object is equivalent to receiving an object
> containing
> > values all set to zero (0)."
> >
> > It was our interpretation based on this text that a node 
> should accept
> an
> > ADMIN_STATUS object with no flags set in the same way as if 
> the object
> was
> > missing. Comment on this interpretation is welcome.
> 
> The effect of the meaning is as you state, but the intention of the
> meaning is reversed. That is, an implementation should accept 
> the absence
> of the ADMIN_STATUS object in the same way as if the object 
> was present
> with no flags set. That is, the default behavior is to consider the
> ADMIN_STATUS object as a standard part of the processing.
> 
> We note from your first paragraph that you assume that the 
> ADMIN_STATUS
> object is used to change the status of the LSP. This is a
> misinterpretation - it is used to control the status of the 
> LSP. Thus, if
> there is no change to the status of an LSP, refresh messages 
> must continue
> to carry the ADMIN_STATUS object with the same bit setting.
> 
> In this way, it is not possible to "drop" the ADMIN_STATUS 
> object without
> having the same meaning as transmitting the object with all 
> bits cleared.
> 
> > 5. Handling of multiple received ResvConf Request objects
> >
> > When a connection desires a confirmation that the service (i.e.
> > connection) requested is in place, a RESV_CONF_REQ object 
> is included in
> > the RESV message. As this object is received by the remote 
> end of the
> > reservation, it will send a RESV_CONF message back to the requester.
> >
> > However, it is unclear whether it is necessary to send a RESV_CONF
> message
> > when the RSVP connection state is refreshed by subsequent RESV. This
> > becomes potentially burdensome, especially when the 
> reservation is being
> > rapidly refreshed. Therefore we ask: should the remote end send a
> > RESV_CONF message for subsequent RESV messages that still 
> include the
> > RESV_CONF_REQ object? Or is it required that the requestor of the
> > reservation remove the RESV_CONF_REQ object to prevent the 
> generation of
> > further RESV_CONF messages? Comment on this issue from IETF CCAMP is
> > requested.
> 
> It is fundamental to the implementation of RSVP-TE that there 
> is a good
> understanding of the distinction between a trigger message 
> and a refresh
> message. This can be achieved by reading section 1.1 of RFC2961.
> 
> Following this understanding, you will note that a refresh 
> message does
> not cause any processing to be performed at the LSR that 
> receives it (in
> this case the ingress). You will also note that refresh 
> processing is not
> end-to-end as implied in your text, but is hop-by-hop.
> 
> Thus, a downstream LSR that wishes to trigger a new ResvConf 
> message must
> make a specific change to the content of the Resv message 
> that it sends in
> order to cause a trigger message to be propagated through the 
> network to
> the ingress LSR. Such processing is implementation specific but might
> include the toggling of the presence of the RESV_CONFIRM object on the
> Resv message.
> 
> Note that a ResvConf message is not necessarily reliably delivered
> end-to-end. Relying on the receipt of a ResvConf message before doing
> something (e.g. turning on the laser) might be a poor idea. 
> GMPLS uses the
> Administrative Status object and in particular the R-bit in order to
> reliably achieve this function.
> 
> > 6. Symmetry of Refresh Reduction usage
> >
> > During interop testing, we ran into a conflict caused by varying
> > interpretations of RFC2961, regarding the use of SRefresh 
> messages and
> the
> > Refresh Reduction capabilities of the two ends of a given link. One
> > interpretation of RFC2961 indicates that setting the 
> Refresh Reduction
> > Capability flag in the RSVP header indicates that that 
> interface shall
> be
> > capable of receiving messages related to Refresh Reduction 
> - including
> the
> > SRefresh message. This would be true even if the other end 
> of the link
> for
> > that interface were NOT indicating Refresh Reduction 
> Capability, since
> the
> > RFC makes no statement about symmetry in this matter.
> >
> > Another interpretation is that both ends of an interface 
> must indicate
> > Refresh Reduction Capability before either end can use such 
> messages,
> i.e,
> > use of Refresh Reduction on a link is symmetric.
> >
> > Comment from CCAMP WG on the correct interpretation is requested.
> 
> We are confused by your question.
> You correctly state that the use of the refresh-reduction-capable bit
> indicates the ability of an LSR to support the receipt of refresh
> reduction options and messages. To quote from section 2 of RFC2961...
>            When set, indicates that this node is willing and 
> capable of
>            receiving all the messages and objects described in this
>            document.  This includes the Bundle message described in
>            Section 3, the MESSAGE_ID objects and Ack messages 
> described
>            in Section 4, and the MESSAGE_ID LIST objects and Srefresh
>            message described in Section 5.  This bit is 
> meaningful only
>            between RSVP neighbors.
> This makes no statement about whether the LSR intends to use 
> these options
> when communicating with another LSR.
> 
> However, you will note that some refresh reduction procedures 
> require that
> a message is sent and response returned. In order to make use of the
> response, the receiver must be capable of receiving and processing the
> response. Thus, it would be usual for an LSR that is capable 
> of sending
> refresh reduction options and messages to also set the
> refresh-reduction-capable bit.
> 
> In summary:
> - An LSR must not send refresh reduction options or messages
>   to an LSR that is not setting the refresh-reduction-capable
>   bit.
> - An LSR may send refresh reduction options or messages
>   to an LSR that is setting the refresh-reduction-capable bit.
> - An LSR that wishes to successfully use responded refresh
>   reduction options or messages should set the refresh-
>   reduction-capable bit.
> 
> Note, finally, that section 2 of RFC 2961 states that "When it is not
> known if a next hop supports the extension, standard Path and 
> Resv message
> based refreshes MUST be used."
> 
> > 7. Sending of ACKs bundled with the RSVP HELLO
> >
> > During interop testing, it was observed that Message Acks were
> piggybacked
> > onto RSVP Hello messages, when the receiving end was not 
> using the Hello
> > protocol. In this situation, the incoming Hello's were 
> discarded and the
> > Acks were lost.
> >
> > We believe that Message Acks should only be piggybacked 
> onto mandatory
> > messages, and not on Hello messages because of this 
> problem. Comment on
> > this interpretation is requested.
> 
> You use of the terms "bundled" and "piggybacked" are contradictory.
> 
> "Bundled" implies the use of the Bundle message.
> RFC 2961 states...
>    A sub-message MAY be any message type except for another
>    Bundle message.
> Thus, Ack messages may be bundled with other messages. 
> (Although one might
> consider this perverse since the Ack message is only 
> introduced to handle
> the case when the Ac/Nack objects have no other message on 
> which they can
> be carried.)
> 
> Further, RFC 3209 states...
>    A Hello message may be included
>    as a sub-message within a bundle message.
> 
> Therefore, it acceptable for a Ack and Hello messages to be bundled
> together.
> The processing rules (RFC 29610 for Bundled messages are such 
> that each
> sub-message is processed in its own right, and the 
> non-support/non-use of
> Hello messages should not impact the processing of other messages.
> 
> On the other hand, "piggybacked" implies the use of the 
> Ack/Nack objects
> within a Hello message.
> 
> Section 4.1 of RFC2961 states that Ack/Nack objects may be 
> included in the
> "standard" RSVP messages, and shows where they are placed. 
> However, RFC
> 3209 defines the Hello message as not including the Ack/Nack 
> objects...
> 
>    <Hello Message> ::= <Common Header> [ <INTEGRITY> ]
>                               <HELLO>
> 
> Since RFC 3209 post-dates RFC 2961, this definition is 
> definitive and the
> Ack/Nack objects should not be present on the Hello message.
> 
> Give that section 5.3 of RFC 3209 states...
>    The Hello Message is completely OPTIONAL.  All messages may be
>    ignored by nodes which do not wish to participate in Hello message
>    processing.
> ...it is not particularly important what the message format 
> rules are. An
> implementation that chooses to place an Ack/Nack object in a 
> Hello message
> knows that the object might be discarded unprocessed.
> 
> > 8. TSPEC format to be used for Ethernet connections
> 
> The CCAMP working group is currently discussing the use of GMPLS for
> control of Ethernet devices. We will respond to this point in 
> a separate
> email.
> 
> Best regards,
> Adrian Farrel
> Kireeti Kompella
> 
> 
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================



Envelope-to: [e-mail]
Delivery-date: Fri, 26 Aug 2005 11:29:10 +0000
Message-ID: <0be801c5aa31$73753df0$c5919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Final draft of response to the OIF
Date: Fri, 26 Aug 2005 12:27:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks to all who have commented so far.

Here is an updated draft. I plan to send by the end of August, so furhter
comments should be made quickly.

Thanks,
Adrian

======

To: Jim Jones, OIF Technical Committee Chair
From: Adrian Farrel and Kireeti Kompella,
          WG Co-Chairs for IETF CCAMP
Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors
Subject: Response to your questions about GMPLS parameters.

Dear Jim,

Thanks for your correspondence about the questions with respect to GMPLS
parameters that arose before and during your interoperability testing.
CCAMP is pleased to receive such questions and is glad to have the
opportunity to explain the intended operation of the GMPLS protocols.

Much of the material supplied below can be simply extracted from the
relevant RFCs.

> 1. Use of the NCC and RCC fields for STS-3c/VC-4 connections
>
> During OIF testing it was noted that some ambiguity exists in the
> specification of encoding of NCC, RCC and NVC for certain types of
> connections: NCC and RCC for an STS-3c/VC-4 connection can be set to 0
or
> to 1 depending on which example of RFC 3946 is followed.
>
> Clarification is requested from IETF CCAMP as to which setting is
> considered correct, or if both settings should be accepted (this
procedure
> was used during testing at Supercomm).

This question about RFC 3946 was raised informally on the CCAMP mailing
list at the start of March this year.

Even when the signal Type value is the same (i.e. value 6) the NCC, RCC
and NVC values depend on the specific signal being requested.

>From the examples in the annex we have...

   A VC-4 signal is formed by applying the following
   settings to a VC-4 Elementary Signal.
      RCC = 0
      NCC = 0
      NVC = 0
      MT  = 1
      T   = 0

   An STS-3c SPE signal is formed by applying the following
   settings to an STS-3c SPE Elementary Signal.
      RCC = 1 (standard contiguous concatenation)
      NCC = 1
      NVC = 0
      MT  = 1
      T   = 0

Your question probably arises from the two notes and subsequent paragraph
in section 2.1 or RFC 3946. Here it says...

   Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the
      Elementary Signal to use must always be an STS-3c_SPE signal type
      and the value of NCC must always be equal to X.  This allows also
      facilitating the interworking between SONET and SDH.  In
      particular, it means that the contiguous concatenation of three
      STS-1 SPEs can not be requested because according to this
      specification, this type of signal must be coded using the STS-3c
      SPE signal type.

   Note 2: when requesting a transparent STS-N/STM-N signal
      limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc,
      the signal type must be STS-N/STM-N, RCC with flag 1 and NCC set
      to 1.

   The NCC value must be consistent with the type of contiguous
   concatenation being requested in the RCC field.  In particular, this
   field is irrelevant if no contiguous concatenation is requested (RCC
   = 0), in that case it must be set to zero when sent, and should be
   ignored when received.  A RCC value different from 0 must imply a
   number of contiguous components greater than 1.

We believe that this final sentence should read "greater than or equal to
1," and that this interpretation resolves all of your issues and makes the
text consistent with the examples.

We plan to issue a revision to RFC 3946 to make this clarification. The
text of this clarification still needs to be agreed by the CCAMP working
group, but the draft revision contains the nodes as updated below with the
addition of a third note as shown.

   Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the
      Elementary Signal to use must always be an STS-3c_SPE signal type
      and the value of NCC must always be equal to X. This allows also
      facilitating the interworking between SONET and SDH. In
      particular, it means that the contiguous concatenation of three
      STS-1 SPEs can not be requested because according to this
      specification, this type of signal must be coded using the STS-3c
      SPE signal type.

   Note 2: when requesting a transparent STS-N/STM-N signal limited to
      a single contiguously concatenated STS-Nc_SPE/VC-4-Nc, the signal
      type must be STS-N/STM-N, RCC with flag 1 and NCC set to 1.

      The NCC value must be consistent with the type of contiguous
      concatenation being requested in the RCC field. In particular,
      this field is irrelevant if no contiguous concatenation is
      requested (RCC = 0), in that case it must be set to zero when
      sent, and should be ignored when received. A RCC value different
      from 0 implies a number of contiguous components greater than or
      equal to 1.

   Note 3: Following these rules, when requesting a VC-4 signal, the
      RCC and the NCC values must be set to 0 whereas for an STS-3c SPE
      signal, the RCC and the NCC values must be set 1. However, if
      local conditions allow and since the setting of the RCC and NCC
      values is locally driven, the requesting upstream node MAY set
      the RCC and NCC values to either SDH or SONET settings without
      impacting the function. Moreover, the downstream node SHOULD
      accept the requested values if local conditions allow. If these
      values can not be supported, the receiver downstream node MUST
      generate a PathErr/NOTIFICATION message (see Sections 2.2 and
      2.3, respectively).

> 2. Setting of NVC for VCAT connections
>
> It was also noted that the setting of NVC may be somewhat ambiguous for
> the case where diverse connections are used within a single VCAT group.
> Each individual RSVP session controls a single connection, but the
> connection is part of a larger VCAT group and carries VCAT encoding of
the
> H4 byte. Clarification is requested from IETF CCAMP and ITU-T Q.14/15 as
> to the correct setting of NVC for this case (0 or 1?). It should be
noted
> that this case may occur with a VCAT group with only a single initial
> member, and that the NVC may provide an indication that VCAT encoding of
> the H4 byte is in use for the connection.

A VCn-Xv group split into X components requires each of its component to
be signaled with the NVC value set to 1. This setting is regardless of how
the components are established.

> 3. Length of the Interface Switching Capability TLV
>
> Although the Interface Switching Capability TLV defined by CCAMP for
> SONET/SDH connections was not used for the testing, it was noted that
the
> text describing the length of the Interface Switching Capability TLV
> defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly
> ambiguous due to the use of padding bytes.
>
> RFC 3630 states that "The TLV is padded to four-octet alignment; padding
> is not included in the length field (so a three octet value would have a
> length of three, but the total size of the TLV would be eight octets)."

Yes. Section 2.3.2 of RFC3630 gives a definitive statement of the meaning
of the length field and the use of padding, and provides an example.

> Reading of the encoding in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
> specifies that the length of the TLV for TDM is 41 bytes plus 3 bytes of
> padding, and should be given in the length field as 41 bytes rather than
> 44. OIF requests verification of this interpretation from the experts in
> IETF CCAMP group.

Note that the Interface Switching Capability Descriptor defined in
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link
TLV. Sub-TLVs and TLVs follow the same encoding rules.

The ISCD TLV for TDM contains the following fields...
  type       2 bytes
  length     2 bytes
  ---
  switch cap 1 byte
  encoding   1 byte
  reserve    2 bytes
  LSP b/w 0  4 bytes
  LSP b/w 1  4 bytes
  LSP b/w 2  4 bytes
  LSP b/w 3  4 bytes
  LSP b/w 4  4 bytes
  LSP b/w 5  4 bytes
  LSP b/w 6  4 bytes
  LSP b/w 7  4 bytes
  min b/w    4 bytes
  indication 1 byte
            ==
            41 bytes

We presume that your question relates to whether the 3-byte field shown as
"padding" in the TDM-specific figure on page 6 of
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an
explicit field.

It is an implicit field, and should not be included in the length of the
TLV.

Nevertheless, we take this opportunity to remind the OIF that
implementations of GMPLS protocols should be conservative in what they
send and liberal in what they receive. Thus, an implementation that
receives a TDM ISCD TLV with length 44 should not reject the TLV for this
reason. It should parse the TLV according to the defined fields and skip
the final three bytes. Thus, it should not affect a receiving
implementation if the sending implementation has treated the "padding"
field as implicit or explicit. In the event that a receiving
implementation rejected such a TLV on grounds of the value contained in
the length field being too large, the fault would lie with the receiving
implementation not the sending implementation.

> 4. Use of ADMIN_STATUS in an initial PATH message
>
> Some implementations sent an ADMIN_STATUS object with no flags set in
the
> initial PATH message, i.e., when no status change was being requested.
> Although this did not serve any particular function, it was believed
that
> this could be accepted as RFC3473, sect. 7.2 (page 18) states:
>
> "The absence of the object is equivalent to receiving an object
containing
> values all set to zero (0)."
>
> It was our interpretation based on this text that a node should accept
an
> ADMIN_STATUS object with no flags set in the same way as if the object
was
> missing. Comment on this interpretation is welcome.

The effect of the meaning is as you state, but the intention of the
meaning is reversed. That is, an implementation should accept the absence
of the ADMIN_STATUS object in the same way as if the object was present
with no flags set. That is, the default behavior is to consider the
ADMIN_STATUS object as a standard part of the processing.

We note from your first paragraph that you assume that the ADMIN_STATUS
object is used to change the status of the LSP. This is a
misinterpretation - it is used to control the status of the LSP. Thus, if
there is no change to the status of an LSP, refresh messages must continue
to carry the ADMIN_STATUS object with the same bit setting.

In this way, it is not possible to "drop" the ADMIN_STATUS object without
having the same meaning as transmitting the object with all bits cleared.

> 5. Handling of multiple received ResvConf Request objects
>
> When a connection desires a confirmation that the service (i.e.
> connection) requested is in place, a RESV_CONF_REQ object is included in
> the RESV message. As this object is received by the remote end of the
> reservation, it will send a RESV_CONF message back to the requester.
>
> However, it is unclear whether it is necessary to send a RESV_CONF
message
> when the RSVP connection state is refreshed by subsequent RESV. This
> becomes potentially burdensome, especially when the reservation is being
> rapidly refreshed. Therefore we ask: should the remote end send a
> RESV_CONF message for subsequent RESV messages that still include the
> RESV_CONF_REQ object? Or is it required that the requestor of the
> reservation remove the RESV_CONF_REQ object to prevent the generation of
> further RESV_CONF messages? Comment on this issue from IETF CCAMP is
> requested.

It is fundamental to the implementation of RSVP-TE that there is a good
understanding of the distinction between a trigger message and a refresh
message. This can be achieved by reading section 1.1 of RFC2961.

Following this understanding, you will note that a refresh message does
not cause any processing to be performed at the LSR that receives it (in
this case the ingress). You will also note that refresh processing is not
end-to-end as implied in your text, but is hop-by-hop.

Thus, a downstream LSR that wishes to trigger a new ResvConf message must
make a specific change to the content of the Resv message that it sends in
order to cause a trigger message to be propagated through the network to
the ingress LSR. Such processing is implementation specific but might
include the toggling of the presence of the RESV_CONFIRM object on the
Resv message.

Note that a ResvConf message is not necessarily reliably delivered
end-to-end. Relying on the receipt of a ResvConf message before doing
something (e.g. turning on the laser) might be a poor idea. GMPLS uses the
Administrative Status object and in particular the R-bit in order to
reliably achieve this function.

> 6. Symmetry of Refresh Reduction usage
>
> During interop testing, we ran into a conflict caused by varying
> interpretations of RFC2961, regarding the use of SRefresh messages and
the
> Refresh Reduction capabilities of the two ends of a given link. One
> interpretation of RFC2961 indicates that setting the Refresh Reduction
> Capability flag in the RSVP header indicates that that interface shall
be
> capable of receiving messages related to Refresh Reduction - including
the
> SRefresh message. This would be true even if the other end of the link
for
> that interface were NOT indicating Refresh Reduction Capability, since
the
> RFC makes no statement about symmetry in this matter.
>
> Another interpretation is that both ends of an interface must indicate
> Refresh Reduction Capability before either end can use such messages,
i.e,
> use of Refresh Reduction on a link is symmetric.
>
> Comment from CCAMP WG on the correct interpretation is requested.

We are confused by your question.
You correctly state that the use of the refresh-reduction-capable bit
indicates the ability of an LSR to support the receipt of refresh
reduction options and messages. To quote from section 2 of RFC2961...
           When set, indicates that this node is willing and capable of
           receiving all the messages and objects described in this
           document.  This includes the Bundle message described in
           Section 3, the MESSAGE_ID objects and Ack messages described
           in Section 4, and the MESSAGE_ID LIST objects and Srefresh
           message described in Section 5.  This bit is meaningful only
           between RSVP neighbors.
This makes no statement about whether the LSR intends to use these options
when communicating with another LSR.

However, you will note that some refresh reduction procedures require that
a message is sent and response returned. In order to make use of the
response, the receiver must be capable of receiving and processing the
response. Thus, it would be usual for an LSR that is capable of sending
refresh reduction options and messages to also set the
refresh-reduction-capable bit.

In summary:
- An LSR must not send refresh reduction options or messages
  to an LSR that is not setting the refresh-reduction-capable
  bit.
- An LSR may send refresh reduction options or messages
  to an LSR that is setting the refresh-reduction-capable bit.
- An LSR that wishes to successfully use responded refresh
  reduction options or messages should set the refresh-
  reduction-capable bit.

Note, finally, that section 2 of RFC 2961 states that "When it is not
known if a next hop supports the extension, standard Path and Resv message
based refreshes MUST be used."

> 7. Sending of ACKs bundled with the RSVP HELLO
>
> During interop testing, it was observed that Message Acks were
piggybacked
> onto RSVP Hello messages, when the receiving end was not using the Hello
> protocol. In this situation, the incoming Hello's were discarded and the
> Acks were lost.
>
> We believe that Message Acks should only be piggybacked onto mandatory
> messages, and not on Hello messages because of this problem. Comment on
> this interpretation is requested.

You use of the terms "bundled" and "piggybacked" are contradictory.

"Bundled" implies the use of the Bundle message.
RFC 2961 states...
   A sub-message MAY be any message type except for another
   Bundle message.
Thus, Ack messages may be bundled with other messages. (Although one might
consider this perverse since the Ack message is only introduced to handle
the case when the Ac/Nack objects have no other message on which they can
be carried.)

Further, RFC 3209 states...
   A Hello message may be included
   as a sub-message within a bundle message.

Therefore, it acceptable for a Ack and Hello messages to be bundled
together.
The processing rules (RFC 29610 for Bundled messages are such that each
sub-message is processed in its own right, and the non-support/non-use of
Hello messages should not impact the processing of other messages.

On the other hand, "piggybacked" implies the use of the Ack/Nack objects
within a Hello message.

Section 4.1 of RFC2961 states that Ack/Nack objects may be included in the
"standard" RSVP messages, and shows where they are placed. However, RFC
3209 defines the Hello message as not including the Ack/Nack objects...

   <Hello Message> ::= <Common Header> [ <INTEGRITY> ]
                              <HELLO>

Since RFC 3209 post-dates RFC 2961, this definition is definitive and the
Ack/Nack objects should not be present on the Hello message.

Give that section 5.3 of RFC 3209 states...
   The Hello Message is completely OPTIONAL.  All messages may be
   ignored by nodes which do not wish to participate in Hello message
   processing.
...it is not particularly important what the message format rules are. An
implementation that chooses to place an Ack/Nack object in a Hello message
knows that the object might be discarded unprocessed.

> 8. TSPEC format to be used for Ethernet connections

The CCAMP working group is currently discussing the use of GMPLS for
control of Ethernet devices. We will respond to this point in a separate
email.

Best regards,
Adrian Farrel
Kireeti Kompella




Envelope-to: [e-mail]
Delivery-date: Thu, 25 Aug 2005 00:29:10 +0000
Message-ID: <[e-mail]>
Date: Thu, 25 Aug 2005 09:27:56 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
Cc: [e-mail]
Subject: Re: Not voting on the charter milestones
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello everyone,

I agree with the proposed new milestones.

Regards,

tomo


Adrian Farrel wrote:

>Hi,
>
>Of course we don't vote, but Kireeti and I do need evidence of rough
>consensus. We have a had a good number of emails picking up on small
>points, but nothing of any substance said against the proposed milestones.
>We have some evidence of general support.
>
>Can you please speak up.
>Do you broadly support the proposed new CCAMP milestones?
>
>Thanks,
>Adrian
>
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Wed, 24 Aug 2005 19:40:08 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: Not voting on the charter milestones
Date: Wed, 24 Aug 2005 12:37:39 -0700
Organization: Metanoia, Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcWmbuPlOguWax5UTvebX8Nf64ZezwCdDp4A
Message-Id: <[e-mail]>

Adrian, 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Sunday, August 21, 2005 9:39 AM
> To: [e-mail]
> Subject: Not voting on the charter milestones
> 
> Hi,
> 
> Of course we don't vote, but Kireeti and I do need evidence 
> of rough consensus. We have a had a good number of emails 
> picking up on small points, but nothing of any substance said 
> against the proposed milestones.
> We have some evidence of general support.
> 
> Can you please speak up.
> Do you broadly support the proposed new CCAMP milestones?

Yes. 

(Perhaps a few things will need to be refined as the discussion
proceeds further, but I think broadly it is a good set of milestones 
-- and kudos on taking the time to get them down to such detail.)

-Vishal





Envelope-to: [e-mail]
Delivery-date: Wed, 24 Aug 2005 11:50:53 +0000
Message-ID: <045301c5a8a2$46bb8570$c5919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Bill Fenner" <[e-mail]>
Cc: <[e-mail]>
Subject: CCAMP Requests to add new milestones to its charter
Date: Wed, 24 Aug 2005 12:50:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Alex and Bill,

The CCAMP working group has had further discussions about the potential
work it could do over the next 1.5 to 2 years. This has led us to produce
the following set of milestones with which there appears to be
overwhelming consensual support within the working group.

Therefore, we would like to ask you to arrange for us to have these
milestones added to our charter.

You will notice that the proposed milestones are unusually detailed. At
the moment we feel that this is important to help focus the working group
into the right activities and to ensure that we deliver. We could (of
course) drop the interim milestones from the charter if this would make
people more comfortable - we can still run the detailed milestones for our
own benefit.

At this stage we feel that it is not essential to modify the text of our
charter. Although we could take this opportunity to tidy it up and improve
the focus, we feel that all of the proposed milestones fall within the
existing charter work.

Please let us know your thoughts and what the next steps should be.

Thanks,
Adrian and Kireeti
====
Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS
and OSPF
Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh
membership
Nov 05 Submit ASON Routing evaluation I-D for IESG review
Nov 05 First version of WG I-D on path computation implementation advice
Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS
and OSPF
Nov 05 First version WG I-D MPLS to GMPLS migration strategies
Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS
Nov 05 First version WG I-D Change of LSP ownership between management and
control planes
Dec 05 First version of WG I-D for ASON Routing solutions
Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG
review
Dec 05 Submit Per-domain path computation signaling I-D for IESG review
Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region
Networks
Dec 05 First version WG I-D for Evaluation of existing protocols for
MLN/MRN
Dec 05 First version WG I-D for Protocol solutions for MLN/MRN
Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG
review
Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review
Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module
Jan 06 First version WG Informational I-D for Analysis of inter-domain
issues for disjoint and protected paths
Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF
for IESG review
Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and
solutions
Jan 06 First version WG I-D GMPLS OAM Requirements
Jan 06 First version WG I-D Routing and signaling for link viability
constraints
Feb 06 Submit LSP Stitching I-D for IESG review
Mar 06 First version of WG informational I-D Aligning GMPLS protocols
across the standards bodies
Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for
IESG review
Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module
Mar 06 First version of WG I-D for additional MIB module to cover RSVP-TE
signaling extensions
Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for
IESG review
Jun 06 Submit Informational I-D for Analysis of inter-domain issues for
disjoint and protected paths for IESG review
Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review
Jun 06 Submit Change of LSP ownership between management and control
planes I-D for IESG review
Aug 06 Submit path computation implementation advice I-D for IESG review
Oct 06 Submit ASON Routing solutions I-D for IESG review
Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D
for IESG review
Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG review
Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for
IESG review
Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review
Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
Dec 06 Submit GMPLS OAM Requirements I-D for IESG review
Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review
Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review
Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor
and IESG review
Oct 07 Submit Routing and signaling for link viability constraints I-D for
IESG review
Oct 07 Recharter or close Working Group




Envelope-to: [e-mail]
Delivery-date: Wed, 24 Aug 2005 09:16:11 +0000
Thread-Topic: L2SC [Was: Moving forward with the CCAMP charter]
thread-index: AcWojHscJFB6MppNR0qz2reOZpx7VQ==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: 
Bcc: 
Subject: RE: L2SC [Was: Moving forward with the CCAMP charter]
Date: Wed, 24 Aug 2005 18:16:16 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Message-ID: <a8f801c5a88c$7b1f3de0$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Class: urn:content-classes:message

 
A bit late in this response, but.....
 
I do support the proposed CCAMP milestone,
 
and, just in case if L2SC work is considered as new WG/BoF,
I'd most welcome such idea, and will support the new WG.
 
thanks
 

Dr. Jaihyung Cho
ETRI, Korea
phone :       [phone]
oversea: [phone]
fax:         [phone] 




-----?? ???----- 
From: "Adrian Farrel" <[e-mail]> 
>From Date: 2005-08-17 ?? 6:20:04 
To: "CHO, JAI HYUNG" <[e-mail]>, "[e-mail]" <[e-mail]> 
Cc: 
Subject: L2SC [Was: Moving forward with the CCAMP charter] 



Hi Jaihyung, 

The Ethernet GMPLS work has certainly not been forgotten! 

The work of the design team is very important and we need more people to 
read and digest draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt. 
it is particularly important that folk read this draft rather than relying 
on scare stories or email threads. Many of the common concerns and issues 
have been carefully answered by the DT, and many of the other are not 
actually raised in this draft. 

For the moment, the CCAMP list remains the correct place to discuss these 
issues, but it would seem that the work involved is both larger than the 
scope of the CCAMP charter and larger than can be easily swallowed by the 
existing working group (you will have noticed that there are plenty of 
other things to occupy the WG's time). 

For this reason (and see the CCAMP draft minutes) we are currently 
investigating whether there could be a better home for this work. The most 
obvious solution is to create a new WG, but this would obviously require 
careful scoping and also would need support from the community. More 
information on this as it becomes available. 

Thanks, 
Adrian 
----- Original Message ----- 
From: "CHO, JAI HYUNG" <[e-mail]> 
To: "Adrian Farrel" <[e-mail]>; <[e-mail]> 
Sent: Wednesday, August 17, 2005 9:10 AM 
Subject: RE: Moving forward with the CCAMP charter 


> 
> Hi, Adrian 
> 
> Thank you for your milestone work. 
> However, I can not find L2SC work in your document. 
> Where does it belong to ? 
> I believe there's some number of people supporting thie work 
> and also we see clear industry need for this work. 
> I think it would be good if we have L2SC milestone 
> at least for framework and solution document. 
> 
> thanks 
> 
> Jaihyung 
> 
> 
> Dr. Jaihyung Cho 
> ETRI, Korea 
> phone :       [phone] 
> oversea: [phone] 
> fax:         [phone] 
> 
> 
> 
> 
> -----?? ???----- 
> From: "Adrian Farrel" <[e-mail]> 
> From Date: 2005-08-16 ?? 8:28:11 
> To: "[e-mail]" <[e-mail]> 
> Cc: "[e-mail]" <[e-mail]>, "'Kireeti Kompella'" 
<[e-mail]> 
> Subject: Moving forward with the CCAMP charter 
> 
> Hi, 
> 
> Please find attached a file that contains: 
> 
> - a set of proposed *draft* milestones 
> - a discussion of why there are so many milestones 
> - a high-level explanation of the work items. 
> 
> Note that this looks like a lot of milestones, but please read the text 
on this issue in the attached file. The bottom line is that this is a 
product of micro management where I have tried to identify all of the I-Ds 
that we might produce to cover the referenced work, and where I have 
placed two (sometimes three) milestones for each I-D. 
> 
> This micro-management may be over the top, and represents a full 
pendulum swing from the previous style of CCAMP milestones, but in the 
light of the hiatus of the last 12 months, i think this may be beneficial 
and might achieve rapid forwards movement. 
> 
> I would welcome your (constructive!) comments. 
> 
> Notes: 
> - Why isn't my I-D also cited as input material? 
>  No insult intended. The current list is simply there to 
>  show the ADs that work is already in progress. All I-Ds 
>  will be used as input. 
> - Why isn't my pet topic included? 
>   Are you sure it is not there between the lines? This 
>   list of milestones isn't completely proscriptive. 
> 
> The objective is to have the WG agreed on the milestones that it wants 
to commit to by the end of August. 
> 
> Thanks, 
> Adrian 
> 
> 
> 
> 
> 
> 







Envelope-to: [e-mail]
Delivery-date: Wed, 24 Aug 2005 07:12:26 +0000
Thread-Topic: Not voting on the charter milestones
thread-index: AcWoe1Z9+tofRS/4THmCwlpAVSe9/Q==
Content-Transfer-Encoding: 7bit
Reply-To: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
From: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: 
Bcc: 
Subject: RE: Not voting on the charter milestones
Date: Wed, 24 Aug 2005 16:13:33 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBPQU2x4rz6xsAsILTjtOc=?=
Message-ID: <851501c5a87b$5681d440$8310fe81@email1>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_8510_01C5A8C6.C6673250"
Content-Class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_8510_01C5A8C6.C6673250
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64


------=_NextPart_000_8510_01C5A8C6.C6673250
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy
Ij4NCjxESVY+PEJSPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+Jmd0OyA8U1RS
T05HPkZyb206PC9TVFJPTkc+ICJBZHJpYW4gRmFycmVsIiAmbHQ7YWRyaWFuQG9sZGRvZy5jby51
ayZndDs8QlI+Jmd0OyA8U1RST05HPkZyb20gRGF0ZTo8L1NUUk9ORz4gMjAwNS0wOC0yMiC/wMD8
IDE6Mzk6MDg8QlI+Jmd0OyA8U1RST05HPlRvOjwvU1RST05HPiAiY2NhbXBAb3BzLmlldGYub3Jn
IiAmbHQ7Y2NhbXBAb3BzLmlldGYub3JnJmd0OzxCUj4mZ3Q7IDxTVFJPTkc+Q2M6PC9TVFJPTkc+
IDxCUj4mZ3Q7IDxTVFJPTkc+U3ViamVjdDo8L1NUUk9ORz4gTm90IHZvdGluZyBvbiB0aGUgY2hh
cnRlciBtaWxlc3RvbmVzPEJSPiZndDsgPEJSPg0KPERJVj48IS0tIENvbnZlcnRlZCBmcm9tIHRl
eHQvcGxhaW4gZm9ybWF0IC0tPiZndDsgPEJSPg0KPFA+PEZPTlQgc2l6ZT0yPiZndDsgSGksPEJS
PiZndDsgPEJSPiZndDsgT2YgY291cnNlIHdlIGRvbid0IHZvdGUsIGJ1dCBLaXJlZXRpIGFuZCBJ
IGRvIG5lZWQgZXZpZGVuY2Ugb2Ygcm91Z2g8QlI+Jmd0OyBjb25zZW5zdXMuIFdlIGhhdmUgYSBo
YWQgYSBnb29kIG51bWJlciBvZiBlbWFpbHMgcGlja2luZyB1cCBvbiBzbWFsbDxCUj4mZ3Q7IHBv
aW50cywgYnV0IG5vdGhpbmcgb2YgYW55IHN1YnN0YW5jZSBzYWlkIGFnYWluc3QgdGhlIHByb3Bv
c2VkIG1pbGVzdG9uZXMuPEJSPiZndDsgV2UgaGF2ZSBzb21lIGV2aWRlbmNlIG9mIGdlbmVyYWwg
c3VwcG9ydC48QlI+Jmd0OyA8QlI+Jmd0OyBDYW4geW91IHBsZWFzZSBzcGVhayB1cC48QlI+Jmd0
OyBEbyB5b3UgYnJvYWRseSBzdXBwb3J0IHRoZSBwcm9wb3NlZCBuZXcgQ0NBTVAgbWlsZXN0b25l
cz88QlI+PC9GT05UPjwvUD4NCjxQPjxGT05UIHNpemU9Mj5ZZXMsPEJSPjxCUj5UaGFua3M8QlI+
PEJSPlJlZ2FyZHMuLi4gWW91bmc8QlI+PEJSPiZndDsgVGhhbmtzLDxCUj4mZ3Q7IEFkcmlhbjxC
Uj4mZ3Q7PEJSPjwvUD48L0ZPTlQ+PC9ESVY+PC9ESVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxh
eTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0iaHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0
ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9Y2NhbXBAb3BzLmlldGYub3JnJm5hbWU9Y2NhbXAl
NDBvcHMuaWV0Zi5vcmcmZnJvbWVtYWlsPXlod2tpbUBldHJpLnJlLmtyJm1lc3NhZ2VpZD0lM0My
ZDJlYWQ3Ni02YjFjLTRhY2EtOTZkZS1jNzFiZjg5OGFkM2FAZXRyaS5yZS5rciUzRSI+

------=_NextPart_000_8510_01C5A8C6.C6673250--



Envelope-to: [e-mail]
Delivery-date: Wed, 24 Aug 2005 06:27:00 +0000
Message-Id: <[e-mail]>
Date: Wed, 24 Aug 2005 15:25:29 +0900
To: <[e-mail]>
From: "[e-mail]" <[e-mail]>
Subject: RE: Not voting on the charter milestones
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Yes, I support.

Ichiro Inoue

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Sunday, August 21, 2005 12:39 PM
To: [e-mail]
Subject: Not voting on the charter milestones

Hi,

Of course we don't vote, but Kireeti and I do need evidence of rough
consensus. We have a had a good number of emails picking up on small
points, but nothing of any substance said against the proposed
milestones.
We have some evidence of general support.

Can you please speak up.
Do you broadly support the proposed new CCAMP milestones?

Thanks,
Adrian 




Envelope-to: [e-mail]
Delivery-date: Wed, 24 Aug 2005 05:13:40 +0000
Message-ID: <[e-mail]>
Date: Wed, 24 Aug 2005 07:11:35 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Arun Satyanarayana <[e-mail]>
CC: Adrian Farrel <[e-mail]>, Lou Berger <[e-mail]>,  Dimitri Papadimitriou <[e-mail]>, Reshad Rahman <[e-mail]>, Anca Zamfir <[e-mail]>,  Junaid Israr <[e-mail]>, [e-mail]
Subject: Re: Nit in draft-ietf-ccamp-rsvp-restart-ext-03.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi arun, would it be possible to have a small record of the changes to 
post on the mailing list -

thanks,
- dimitri.

Arun Satyanarayana wrote:

> Hi Adrian,
> 
> Thanks for catching the typo.
> 
> There was also another minor comment during last call (addressed to Lou 
> privately, I believe). We'll re-spin by the end of the week.
> 
> Thanks,
> Arun
> ==============================================================
> Adrian Farrel wrote:
> 
>> Hi,
>>
>> Looks like the extra last call on this I-D completed without further
>> comment.
>>
>> Unfortunately, scanning through the draft I found a nit.
>> So you need to do a quick re-spin. I think this should take you less than
>> an hour. Please let me know if you can't do it by the end of the week and
>> I will do it myself.
>>
>> Thanks,
>> Adrian
>> ===
>> Section 2
>> Spurious text relating to cross-references
>>    The reader is assumed to be familiar with the terminology defined in
>>    xref target="RFC3209" /> and [RFC3473].
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 23 Aug 2005 19:38:59 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Not voting on the charter milestones
Date: Tue, 23 Aug 2005 14:38:47 -0500
Message-ID: <[e-mail]>
Thread-Topic: Not voting on the charter milestones
Thread-Index: AcWmbt6g16FomRzfTzOiffPJjVl96QBq07nw
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Yes-
Deborah=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Sunday, August 21, 2005 12:39 PM
To: [e-mail]
Subject: Not voting on the charter milestones

Hi,

Of course we don't vote, but Kireeti and I do need evidence of rough
consensus. We have a had a good number of emails picking up on small
points, but nothing of any substance said against the proposed
milestones.
We have some evidence of general support.

Can you please speak up.
Do you broadly support the proposed new CCAMP milestones?

Thanks,
Adrian





Envelope-to: [e-mail]
Delivery-date: Tue, 23 Aug 2005 19:35:32 +0000
Message-ID: <03a601c5a819$f3448550$c5919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: ASON Routing evaluation ready for WG last call?
Date: Tue, 23 Aug 2005 20:34:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Just a reminder.

Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, August 11, 2005 4:31 PM
Subject: ASON Routing evaluation ready for WG last call?


> Hi,
>
> draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt
>
> The DT said in Paris that this I-D is cooked apart from "some minor
> editing".
>
> I asked the room if anyone would object to a WG last call now, and Alex
> (as AD) suggested that more people should read the I-D before we decided
> whether it was ready for last call.
>
> This gives me the odd position of having a last call for a last call :-)
>
> This email gives notice that you need to read this I-D and make comments
> before 11th September 2005.
>
> Barring unresolved comments we will have a WG last call starting then.
>
> Thanks,
> Adrian
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 23 Aug 2005 10:23:51 +0000
Message-ID: <[e-mail]>
Date: Tue, 23 Aug 2005 03:21:56 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: Not voting on the charter milestones
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Yes.

Greg B.

Adrian Farrel wrote:

>Hi,
>
>Of course we don't vote, but Kireeti and I do need evidence of rough
>consensus. We have a had a good number of emails picking up on small
>points, but nothing of any substance said against the proposed milestones.
>We have some evidence of general support.
>
>Can you please speak up.
>Do you broadly support the proposed new CCAMP milestones?
>
>Thanks,
>Adrian
>
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Mon, 22 Aug 2005 17:10:06 +0000
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 10:08:21 -0700
From: Arun Satyanarayana <[e-mail]>
Organization: Cisco Systems
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: Lou Berger <[e-mail]>, Dimitri Papadimitriou <[e-mail]>, Reshad Rahman <[e-mail]>, Anca Zamfir <[e-mail]>, Junaid Israr <[e-mail]>, [e-mail], "Arun Satyanarayana (asatyana)" <[e-mail]>
Subject: Re: Nit in draft-ietf-ccamp-rsvp-restart-ext-03.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Adrian,

Thanks for catching the typo.

There was also another minor comment during last call (addressed to Lou 
privately, I believe). We'll re-spin by the end of the week.

Thanks,
Arun
==============================================================
Adrian Farrel wrote:

> Hi,
> 
> Looks like the extra last call on this I-D completed without further
> comment.
> 
> Unfortunately, scanning through the draft I found a nit.
> So you need to do a quick re-spin. I think this should take you less than
> an hour. Please let me know if you can't do it by the end of the week and
> I will do it myself.
> 
> Thanks,
> Adrian
> ===
> Section 2
> Spurious text relating to cross-references
>    The reader is assumed to be familiar with the terminology defined in
>    xref target="RFC3209" /> and [RFC3473].



Envelope-to: [e-mail]
Delivery-date: Mon, 22 Aug 2005 12:27:53 +0000
Subject: Re: Not voting on the charter milestones
Sensitivity: 
To: [e-mail]
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 22 Aug 2005 14:27:46 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Yes

Regards

Diego


"Adrian Farrel" <[e-mail]>@ops.ietf.org on 21/08/2005 18.39.08

Please respond to "Adrian Farrel" <[e-mail]>

Sent by:    [e-mail]


To:    <[e-mail]>
cc:

Subject:    Not voting on the charter milestones

Hi,

Of course we don't vote, but Kireeti and I do need evidence of rough
consensus. We have a had a good number of emails picking up on small
points, but nothing of any substance said against the proposed milestones.
We have some evidence of general support.

Can you please speak up.
Do you broadly support the proposed new CCAMP milestones?

Thanks,
Adrian












Envelope-to: [e-mail]
Delivery-date: Mon, 22 Aug 2005 12:03:51 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Not voting on the charter milestones
Date: Mon, 22 Aug 2005 07:03:22 -0500
Message-ID: <[e-mail]>
Thread-Topic: Not voting on the charter milestones
Thread-Index: AcWmbt71a7K6t/X4Th2dtw6VLK2jPQAol0cQ
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>

Hi Adrian,

> Do you broadly support the proposed new CCAMP milestones?

Looks good, I like the detail.=20

Thanks,
Jerry





Envelope-to: [e-mail]
Delivery-date: Mon, 22 Aug 2005 11:49:36 +0000
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: "Thomas D. Nadeau" <[e-mail]>
Subject: Re: Not voting on the charter milestones
Date: Mon, 22 Aug 2005 07:47:41 -0400
To: "Adrian Farrel" <[e-mail]>

     They look okay to me.

     --Tom

> Hi,
>
> Of course we don't vote, but Kireeti and I do need evidence of rough
> consensus. We have a had a good number of emails picking up on small
> points, but nothing of any substance said against the proposed  
> milestones.
> We have some evidence of general support.
>
> Can you please speak up.
> Do you broadly support the proposed new CCAMP milestones?
>
> Thanks,
> Adrian
>



Envelope-to: [e-mail]
Delivery-date: Mon, 22 Aug 2005 08:26:46 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Not voting on the charter milestones
Date: Mon, 22 Aug 2005 10:26:42 +0200
Message-ID: <[e-mail]>
Thread-Topic: Not voting on the charter milestones
Thread-Index: AcWmbzUyLYWoln7dQ6yju4/6iFZnkgAg/OSw
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, <[e-mail]>

Hi Adrian, all

The proposed milestones sound good to me

Regards

JL=20

> -----Message d'origine-----
> De : [e-mail]=20
> [mailto:[e-mail]] De la part de Adrian Farrel
> Envoy=E9 : dimanche 21 ao=FBt 2005 18:39
> =C0 : [e-mail]
> Objet : Not voting on the charter milestones
>=20
> Hi,
>=20
> Of course we don't vote, but Kireeti and I do need evidence=20
> of rough consensus. We have a had a good number of emails=20
> picking up on small points, but nothing of any substance said=20
> against the proposed milestones.
> We have some evidence of general support.
>=20
> Can you please speak up.
> Do you broadly support the proposed new CCAMP milestones?
>=20
> Thanks,
> Adrian
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 22 Aug 2005 08:04:29 +0000
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: AW: Not voting on the charter milestones
Date: Mon, 22 Aug 2005 10:00:41 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I support the list of CCAMP milestones.

Michael=20




-----Urspr=FCngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im =
Auftrag von Adrian Farrel
Gesendet: Sonntag, 21. August 2005 18:39
An: [e-mail]
Betreff: Not voting on the charter milestones


Hi,

Of course we don't vote, but Kireeti and I do need evidence of rough =
consensus. We have a had a good number of emails picking up on small =
points, but nothing of any substance said against the proposed =
milestones. We have some evidence of general support.

Can you please speak up.
Do you broadly support the proposed new CCAMP milestones?

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sun, 21 Aug 2005 23:26:13 +0000
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 08:25:10 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
Cc: JP Vasseur <[e-mail]>, [e-mail], [e-mail], 'Kireeti Kompella' <[e-mail]>
Subject: Re: Inter-AS GMPLS [Was: Moving forward with the CCAMP charter]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Adrian,

Thank you for your e-mail message clarifying my comments.
I agree with your proposed milestone.

One point is that as you mentioned, our draft covers;
1. TE reachability information exchange
2. Exchange of aggregated TE information for a domain
In addition to these, in our draft, I also assume that GMPLS
inter-domain routing is required to exchange reachability information.
The draft should be short enough to clarify whether we
rely on the same (existing) protocol mechanism as IP/MPLS.

Regards,

tomo





Adrian Farrel wrote:

>Hi Tomo,
>
>> Being related with your text and JP's messages, I would ask you
>> to touch upon the draft: draft-otani-ccamp-interas-gmpls-te-03.txt.
>> Is this related with a kind of baseline for (1) Analysis of inter-domain
>> issues ?
>>
>> So far, there is a proposed draft of GMPLS inter-domain signaling
>> as we discussed in Paris, but there is no draft of GMPLS inter-domain
>> routing definition whether it is with TE extension or not.
>> (your framework draft covers these points)
>
>Good point.
>
>It seems that your draft is discussing two things:
>1. TE reachability information exchange
>2. Exchange of aggregated TE information for a domain
>
>As you point out in section 4.2, the issue of scalability and policy needs
>to be carefully considered before we pursue this too much further.
>
>I think your work, especially the aggregation issues, meshes nicely with
>the recent draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt. Therefore, I
>propose the following changes to the draft I sent out before...
>
>1. Delete
>   Jan 06 First version WG I-D Routing and signaling for complex optical
>constraints
>   Oct 07 Submit Routing and signaling for complex optical constraints I-D
>for IESG review
>2. Insert
>   Jan 06 First version WG I-D Routing and signaling for link viability
>constraints
>   Oct 07 Submit Routing and signaling for link viability constraints I-D
>for IESG review
>3. Delete
>    More forward-looking
>    ====================
>      Routing and signaling for complex constraints and inter-domain
>        * first version of WG draft
>          - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
>        * submit for IESG review
>4. Add to Inter-domain section
>    - Analysis and protocol changes for routing and signaling for link
>viability constraints
>      * first version of WG draft
>        - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
>        - material from draft-otani-ccamp-interas-gmpls-te-03.txt
>      * submit for IESG review
>
>Cheers,
>Adrian
>
>
>
>
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Sun, 21 Aug 2005 20:48:59 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Not voting on the charter milestones
Date: Sun, 21 Aug 2005 16:48:31 -0400
Message-ID: <[e-mail]>
Thread-Topic: Not voting on the charter milestones
Thread-Index: AcWmbud8OjthYAmWQImq+VkWpxd/FwAIiSrw
From: "Zafar Ali \(zali\)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Sunday, August 21, 2005 12:39 PM
> To: [e-mail]
> Subject: Not voting on the charter milestones
>=20
> Hi,
>=20
> Of course we don't vote, but Kireeti and I do need evidence=20
> of rough consensus. We have a had a good number of emails=20
> picking up on small points, but nothing of any substance said=20
> against the proposed milestones.
> We have some evidence of general support.
>=20
> Can you please speak up.
> Do you broadly support the proposed new CCAMP milestones?

Yes,=20

Thanks

Regards... Zafar=20

>=20
> Thanks,
> Adrian
>=20



Envelope-to: [e-mail]
Delivery-date: Sun, 21 Aug 2005 19:53:27 +0000
Message-ID: <[e-mail]>
Date: Sun, 21 Aug 2005 21:51:42 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail]
Subject: Re: Not voting on the charter milestones
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Adrian Farrel wrote:

> Hi,
> 
> Of course we don't vote, but Kireeti and I do need evidence of rough
> consensus. We have a had a good number of emails picking up on small
> points, but nothing of any substance said against the proposed milestones.
> We have some evidence of general support.
> 
> Can you please speak up.
> Do you broadly support the proposed new CCAMP milestones?

yes -

-d.

> Thanks,
> Adrian
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Sun, 21 Aug 2005 17:35:31 +0000
Message-ID: <[e-mail]>
Date: Sun, 21 Aug 2005 19:34:57 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail]
Subject: Re: Not voting on the charter milestones
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

yes

/Loa

Adrian Farrel wrote:
> Hi,
> 
> Of course we don't vote, but Kireeti and I do need evidence of rough
> consensus. We have a had a good number of emails picking up on small
> points, but nothing of any substance said against the proposed milestones.
> We have some evidence of general support.
> 
> Can you please speak up.
> Do you broadly support the proposed new CCAMP milestones?
> 
> Thanks,
> Adrian
> 
> 
> 


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Sun, 21 Aug 2005 17:17:42 +0000
Message-ID: <[e-mail]>
Date: Sun, 21 Aug 2005 10:17:10 -0700
From: Richard Rabbat <[e-mail]>
Organization: Fujitsu Labs of America
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: Not voting on the charter milestones
Content-Type: multipart/mixed; boundary="------------080106010802050204020304"

This is a multi-part message in MIME format.
--------------080106010802050204020304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

yes

Adrian Farrel wrote:

>Hi,
>
>Of course we don't vote, but Kireeti and I do need evidence of rough
>consensus. We have a had a good number of emails picking up on small
>points, but nothing of any substance said against the proposed milestones.
>We have some evidence of general support.
>
>Can you please speak up.
>Do you broadly support the proposed new CCAMP milestones?
>
>Thanks,
>Adrian
>
>
>  
>

--------------080106010802050204020304
Content-Type: text/x-vcard; charset=utf-8;
 name="richard.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="richard.vcf"

begin:vcard
fn:Richard Rabbat
n:Rabbat;Richard
org:Fujitsu Labs of America;IP Networking Research
adr:MS 345;;1240 East Arques Ave;Sunnyvale;CA;94085;USA
email;internet:[e-mail]
title:Senior Project Manager
tel;work:1-408-530-4537
tel;fax:[phone]
tel;cell:1-650-714-7618
x-mozilla-html:TRUE
version:2.1
end:vcard


--------------080106010802050204020304--



Envelope-to: [e-mail]
Delivery-date: Sun, 21 Aug 2005 16:44:20 +0000
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: JP Vasseur <[e-mail]>
Subject: Re: Not voting on the charter milestones
Date: Sun, 21 Aug 2005 12:44:34 -0400
To: "Adrian Farrel" <[e-mail]>

On Aug 21, 2005, at 12:39 PM, Adrian Farrel wrote:

> Hi,
>
> Of course we don't vote, but Kireeti and I do need evidence of rough
> consensus. We have a had a good number of emails picking up on small
> points, but nothing of any substance said against the proposed  
> milestones.
> We have some evidence of general support.
>
> Can you please speak up.
> Do you broadly support the proposed new CCAMP milestones?
>

Yes,

JP.

> Thanks,
> Adrian
>



Envelope-to: [e-mail]
Delivery-date: Sun, 21 Aug 2005 16:39:01 +0000
Message-ID: <012c01c5a66f$1672a540$20849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Not voting on the charter milestones
Date: Sun, 21 Aug 2005 17:39:08 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Of course we don't vote, but Kireeti and I do need evidence of rough
consensus. We have a had a good number of emails picking up on small
points, but nothing of any substance said against the proposed milestones.
We have some evidence of general support.

Can you please speak up.
Do you broadly support the proposed new CCAMP milestones?

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sun, 21 Aug 2005 15:10:39 +0000
Message-ID: <00e301c5a662$9baba390$20849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Lou Berger" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>, "Reshad Rahman" <[e-mail]>, "Anca Zamfir" <[e-mail]>, "Junaid Israr" <[e-mail]>, "Arun Satyanarayana \(asatyana\)" <[e-mail]>
Cc: <[e-mail]>
Subject: Nit in draft-ietf-ccamp-rsvp-restart-ext-03.txt
Date: Sun, 21 Aug 2005 16:11:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Looks like the extra last call on this I-D completed without further
comment.

Unfortunately, scanning through the draft I found a nit.
So you need to do a quick re-spin. I think this should take you less than
an hour. Please let me know if you can't do it by the end of the week and
I will do it myself.

Thanks,
Adrian
===
Section 2
Spurious text relating to cross-references
   The reader is assumed to be familiar with the terminology defined in
   xref target="RFC3209" /> and [RFC3473].




Envelope-to: [e-mail]
Delivery-date: Sun, 21 Aug 2005 10:00:19 +0000
Message-ID: <[e-mail]>
Date: Sun, 21 Aug 2005 11:59:01 +0200
From: Huub van Helvoort <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To:  [e-mail],  [e-mail]
CC: ccamp <[e-mail]>
Subject: Re: MS-SPring
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dimitri,

I agree with you on both points.

- no restriction of the scope: linear + ring protection
- the fundamentals in Diego's document with references to
   relevant (standard) documents and articles.

Cheers, Huub.

> Huub,
> 
> [snip]
> 
>>> ok, btw, is there a reason to restrict to MS/line protection ring ?
>>
>>
>> If you refer to the APS protocol, this can be used in ring
>> protection and linear protection, because it operates between
>> source and sink of a trail or LSP.
>> In its most simple form it provides 1:1 protection, and more
>> general N:M protection
> 
> 
> i was referring to the scope of the document - should it be restricted 
> to MS/line shared protection ring or include other types (e.g. path 
> protection ring) - note: in my view not
> 
>>>> The reconfiguration of the ring after this first switch is controlplane
>>>> driven and concerns all nodes in the ring.
>>>
>>>
>>> ok with this - like for other linear protection schemes the control 
>>> plane would be involved in the provisioning
>>>
>>> also, what about the (informational) notification to maintain the 
>>> control plane aware about the data plane status after failure 
>>> detection and/or after the APS operation
>>
>>
>> Maybe it is a good idea to include a description in the document
>> Diego is preparing (in the book on functional modeling I need
>> six pages to describe this protection mechanism).
> 
> 
> imho, an overview should be enough to skim the ring protection scheme 
> and the APS operation (no need to include full details that can be found 
> elsewhere)
> 
>> Have a nice weekend, Huub.
>>
> 

-- 
================================================================
              http://www.gironet.nl/home/idefiks/
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...



Envelope-to: [e-mail]
Delivery-date: Sun, 21 Aug 2005 09:32:44 +0000
Message-ID: <[e-mail]>
Date: Sun, 21 Aug 2005 11:30:48 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Huub van Helvoort <[e-mail]>
CC:  [e-mail], ccamp <[e-mail]>
Subject: Re: MS-SPring
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Huub,

[snip]

>> ok, btw, is there a reason to restrict to MS/line protection ring ?
>
> If you refer to the APS protocol, this can be used in ring
> protection and linear protection, because it operates between
> source and sink of a trail or LSP.
> In its most simple form it provides 1:1 protection, and more
> general N:M protection

i was referring to the scope of the document - should it be restricted 
to MS/line shared protection ring or include other types (e.g. path 
protection ring) - note: in my view not

>>> The reconfiguration of the ring after this first switch is controlplane
>>> driven and concerns all nodes in the ring.
>>
>> ok with this - like for other linear protection schemes the control 
>> plane would be involved in the provisioning
>>
>> also, what about the (informational) notification to maintain the 
>> control plane aware about the data plane status after failure 
>> detection and/or after the APS operation
> 
> Maybe it is a good idea to include a description in the document
> Diego is preparing (in the book on functional modeling I need
> six pages to describe this protection mechanism).

imho, an overview should be enough to skim the ring protection scheme 
and the APS operation (no need to include full details that can be found 
elsewhere)

> Have a nice weekend, Huub.
> 



Envelope-to: [e-mail]
Delivery-date: Sat, 20 Aug 2005 18:00:49 +0000
Message-Id: <[e-mail]>
Date: Sun, 21 Aug 2005 02:59:12 +0900
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Adrian

  Thanks.
  I'd like to do so.

Best Regards
Wataru

>Hi,
>
>Thanks for your comments.
>
>Do you think it may be premature to apply 803.2ad techniques before we
>have done any work to control Ethernet networks with GMPLS?
>
>You are right that IEEE link aggregation is conceptually very close to
>bundling.
>
>I suggest that you need to separate TDM and Ethernet concepts in your I-D.
>Take the TDM issues to Diego, Richard, Greg et alia for inclusion in the
>VCAT/LCAS work. Take your LAGR issues to Dimitri and Loa for inclusion in
>the "GMPLS control of Ethernet switching" work that they are doing.
>
>Thanks,
>Adrian
>
>----- Original Message -----
>From: "Wataru Imajuku" <[e-mail]>
>To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
>Sent: Thursday, August 18, 2005 9:59 PM
>Subject: Re: Moving forward with the CCAMP charter
>
>
> > Hi, Adrian
> >
> >   Thank you for giving your time interim your hard work.
> >
> > >With regard to your section 5, I note that you consider the VCAT group
> > >analogous with a link bundle. I don't think this is correct because the
> > >members of a link bundle must be selected and used individually. A
>payload
> > >data stream cannot be distributed across multiple component links of
>the
> > >bundle...
> > >    An LSP with a bandwidth requirement b and
> > >    setup priority p fits in a bundled link if at least one component
> > >    link has maximum LSP bandwidth >= b at priority p.
> > >However, the whole point of a VCAT group is to produce a single entity
> > >(pipe) with maximum LSP bandwidth greater than the capacity of any
> > >individual component. A VCAT group, therefore, is not a bundle.
> > >
> > >Following on from this, I think that the remainder of your section 5.1
> > >will have some value, but needs to be corrected to properly reflect the
> > >meaning of a VCAT group.
> > >
> > >In general, I think your section 5 should generalize from the specific
> > >case of the FA to include any TE link that is based on a VCAT group.
> > >
> > >Section 5.2 seems to confuse "FA" with "FA LSP".
> >
> >   Regarding to VCAT, I agree to your comment.
> >   But, this draft also covers LAGR (link aggregation) which has some
>limitations
> > to transmit data-flow exceeding the bandwidth of each comopnent LSP.
> >
> >   This is one of reason why the description wirtten in Section 5 exists,
>although
> > some terminologies are not proper as you noted.
> >

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone] 




Envelope-to: [e-mail]
Delivery-date: Sat, 20 Aug 2005 14:40:08 +0000
Message-ID: <[e-mail]>
Date: Sat, 20 Aug 2005 16:39:21 +0200
From: Huub van Helvoort <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To:  [e-mail],  [e-mail]
CC: ccamp <[e-mail]>
Subject: Re: MS-SPring
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Dimitri,

You asked:

> hi huub,
> 
> Huub van Helvoort wrote:
> 
>> Hallo Dimitri,
>>
>> You responded to Diego:
>>
>>> Diego Caviglia wrote:
>>>
>>>> Hi Dimitri,
>>>>             given the high number of MS-SPRing protected transport 
>>>> network
>>>> already deployed seems reasonable to me, from a Network Operator 
>>>> point of
>>>> view, to use at the same time MS-SPRing protection with GMPLS 
>>>> restoration.
>>>
>>>
>>> there are already two questions here 1. is there an operational need 
>>> to control such rings using GMPLS (? for instance is it effective 
>>> knowing that ring based protection is mainly data plane driven ?) and 
>>> 2. how to position the ring protection wrt to the LSP recovery 
>>> segment/end-to-end recovery
>>
>>
>> The first step in MS-Spring is indeed dataplane driven (using APS)
>> but that involves only nodes adjacent to the fault.
> 
> 
> ok, btw, is there a reason to restrict to MS/line protection ring ?

If you refer to the APS protocol, this can be used in ring
protection and linear protection, because it operates between
source and sink of a trail or LSP.
In its most simple form it provides 1:1 protection, and more
general N:M protection

>> The reconfiguration of the ring after this first switch is controlplane
>> driven and concerns all nodes in the ring.
> 
> ok with this - like for other linear protection schemes the control 
> plane would be involved in the provisioning
> 
> also, what about the (informational) notification to maintain the 
> control plane aware about the data plane status after failure detection 
> and/or after the APS operation

Maybe it is a good idea to include a description in the document
Diego is preparing (in the book on functional modeling I need
six pages to describe this protection mechanism).

Have a nice weekend, Huub.

-- 
================================================================
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...



Envelope-to: [e-mail]
Delivery-date: Sat, 20 Aug 2005 13:51:41 +0000
Message-ID: <[e-mail]>
Date: Sat, 20 Aug 2005 15:49:28 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: =?UTF-8?B?6rmA7JiB7ZmU?= <[e-mail]>,  [e-mail],  [e-mail], 'Kireeti Kompella' <[e-mail]>
Subject: Re: Control Plane Robustness [Was: Moving forward with the CCAMP charter]
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

adrian,

Adrian Farrel wrote:
[snip]
> Thus my feeling at the moment is that Control Plane Robustness should be
> an area that CCAMP looks at, but we should not set any specific
> milestones.

if you mean explicitly listed as part of the wg scope without explicit 
milestone i would agree,

also, a way to avoid having to modify the charter each time a specific 
work item related to this area would need to be produced by the working 
group

thanks,
- dimitri.

>>Of course, I think it's possible under the condition that the topic of
>>control plane resilience could be handled in the CCAMP charter.
> 
> 
> -----¢¯©ª¨¬¡í ¢¬¨­¨öAAo-----
> From: "Adrian Farrel" <[e-mail]>
>>From Date: 2005-08-16 ¢¯AEA 8:28:11
> To: "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "'Kireeti Kompella'"
> <[e-mail]>
> Subject: Moving forward with the CCAMP charter
> 
> 
> Hi,
> 
> Please find attached a file that contains:
> 
> - a set of proposed *draft* milestones
> - a discussion of why there are so many milestones
> - a high-level explanation of the work items.
> 
> Note that this looks like a lot of milestones, but please read the text on
> this issue in the attached file. The bottom line is that this is a product
> of micro management where I have tried to identify all of the I-Ds that we
> might produce to cover the referenced work, and where I have placed two
> (sometimes three) milestones for each I-D.
> 
> This micro-management may be over the top, and represents a full pendulum
> swing from the previous style of CCAMP milestones, but in the light of the
> hiatus of the last 12 months, i think this may be beneficial and might
> achieve rapid forwards movement.
> 
> I would welcome your (constructive!) comments.
> 
> Notes:
> - Why isn't my I-D also cited as input material?
>   No insult intended. The current list is simply there to
>   show the ADs that work is already in progress. All I-Ds
>   will be used as input.
> - Why isn't my pet topic included?
>   Are you sure it is not there between the lines? This
>   list of milestones isn't completely proscriptive.
> 
> The objective is to have the WG agreed on the milestones that it wants to
> commit to by the end of August.
> 
> Thanks,
> Adrian
> 
> ----- Original Message ----- 
> From: "±è¿µÈ­" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; "'Kireeti Kompella'" <[e-mail]>
> Sent: Friday, August 19, 2005 10:32 AM
> Subject: RE: Moving forward with the CCAMP charter
> 
> 
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Sat, 20 Aug 2005 09:39:39 +0000
Message-ID: <001101c5a56b$025202e0$3b849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: Stability in the proposed CCAMP milestones
Date: Sat, 20 Aug 2005 10:38:46 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_000D_01C5A573.57FD0930"

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01C5A573.57FD0930
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Still entertaining more input at this stage.

Fairly soon we will need to take this to the ADs for their opinions.

Thanks,
Adrian
------=_NextPart_000_000D_01C5A573.57FD0930
Content-Type: text/plain;
	name="ccamp-milestones.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="ccamp-milestones.txt"

CCAMP Working Group - Rechartering Effort

Below you will find
- a list of proposed milestones
- an explanation of why this is a long list
- overview of proposed drafts and work items

In reviewing this we should look for:
- topics that are irrelevant or unwanted by the WG
- topics that have been left out but are wanted by the WG
- topics that have been assigned the wrong priority or urgency
- topics or collections or topics that are sufficiently large
  to potentially warrant their own working group.

Proposed New milestones
-----------------------

Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS =
and OSPF
Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh =
membership
Nov 05 Submit ASON Routing evaluation I-D for IESG review
Nov 05 First version of WG I-D on path computation implmentation advice
Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in =
ISIS and OSPF
Nov 05 First version WG I-D MPLS to GMPLS migration strategies
Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS
Nov 05 First version WG I-D Change of LSP ownership between management =
and control planes
Dec 05 First version of WG I-D for ASON Routing solutions
Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG =
review
Dec 05 Submit Per-domain path computation signaling I-D for IESG review
Dec 05 First version WG I-D Requirements for Multi-Layer and =
Multi-Region Networks
Dec 05 First version WG I-D for Evaluation of existing protocols for =
MLN/MRN
Dec 05 First version WG I-D for Protocol solutions for MLN/MRN
Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG =
review
Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review
Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module
Jan 06 First version WG Informational I-D for Analysis of inter-domain =
issues for disjoint and protected paths
Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF =
for IESG review
Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and =
solutions
Jan 06 First version WG I-D GMPLS OAM Requirements
Jan 06 First version WG I-D Routing and signaling for link viability =
constraints
Feb 06 Submit LSP Stitching I-D for IESG review
Mar 06 First version of WG informational I-D Aligning GMPLS protocols =
across the standards bodies
Mar 06 Submit GMPLS routing and signaling interoperability advice I-D =
for IESG review
Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module
Mar 06 First version of WG I-D for additional MIB module to cover =
RSVP-TE signaling extensions
Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for =
IESG review
Jun 06 Submit Informational I-D for Analysis of inter-domain issues for =
disjoint and protected paths for IESG review
Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review
Jun 06 Submit Change of LSP ownership between management and control =
planes I-D for IESG review
Aug 06 Submit path computation implmentation advice I-D for IESG review
Oct 06 Submit ASON Routing solutions I-D for IESG review
Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D =
for IESG review
Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG =
review
Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for =
IESG review
Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review
Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
Dec 06 Submit GMPLS OAM Requirements I-D for IESG review
Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review
Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review
Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor =
and IESG review
Oct 07 Submit Routing and signaling for link viability constraints I-D =
for IESG review
Oct 07 Recharter or close Working Group


Why so many milestons?
----------------------
The number of milestones shown in this proposed list far exceeds
anything I have ever seen in a working group charter. This is
intentional and while it does indicate a heavy work-load it also
indicates a higher level of micro-management than is usual within
working groups. Thus two milestones are presented for each I-D
(adoption as a WG I-D, and passing to the IESG post-WG-last-call).

This can be compared with the "normal" charter milestones which
include a single work-related item that may span several I-Ds and
refers vaguely only to the "submission" of I-Ds.

In other words, reviewers of this list should not panic because
of its length, but should see this as beneficial.


Explanation of I-Ds and work items
----------------------------------

The following text briefly introduces the work items that are
represented by the milestones listed above. In this text an
astrix (*) indicates a milestone to be set.

The work is divided into several categories according to how
core it is and how it should be prioritized. Existing drafts
are referenced to indicate that work is already in progress -
this is not intended to provide a complete list of existing
drafts.

  Completing existing work
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    ASON
    - ASON Routing evaluation
      - already have draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt
      * submit for IESG review
    - ASON Routing solutions
      * first version of WG draft
      * submit for IESG review
    - GMPLS signaling in support of Call Management
      - already have draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt
      * submit for IESG review
    - GMPLS/ASON lexicography
      - already have draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
      * submit for IESG review
    - Aligning GMPLS protocols across the standards bodies
      - Information I-D not intended for publication as an RFC
      * first version of WG draft

    Interoperability reports and advice
    - signaling and routing
      - already have draft-ietf-ccamp-gmpls-addressing-01.txt
      * submit for IESG review
    - path computation
      * first version of WG draft
        - based on draft-otani-ccamp-gmpls-cspf-constraints-01.txt
      * submit for IESG review

    Additional MIB modules
    - OSPF-TE
      * first version of WG draft
        - based on draft-otani-ccamp-gmpls-ospf-mib-00.txt
      * submit for IESG review
    - ISIS-TE
      * first version of WG draft
      * submit for IESG review
    - Signaling
      - Need "living" MIB module under development to catch
        the minor protocol extensions that have been made
        * first version of WG draft
        * submit for IESG review

    Inter-domain
    - LSP Stitching
      - already have draft-ietf-ccamp-lsp-stitching-01.txt
      * submit for IESG review
    - RSVP-TE extensions for interdomain
      - already have draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
      * submit for IESG review
    - Per-domain path computation signaling
      - already have draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
      * submit for IESG review
    - Analysis of inter-domain issues for disjoint and protected paths
      - Informational I-D to close off the topic and devolve to PCE
      * first version of WG draft
      * submit for IESG review
    - Analysis and protocol changes for routing and signaling for link =
viability constraints
      * first version of WG draft
        - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
        - material from draft-otani-ccamp-interas-gmpls-te-03.txt
      * submit for IESG review

  New items already started and within existing charter
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

    Advertising TE Node Capabilities
    - ISIS and OSPF in the same I-D
      * first version of WG draft
        - based on draft-vasseur-ccamp-te-node-cap-00.txt
      * review by IGP working groups
      * submit for IESG review

    Automatic discovery of MPLS-TE mesh membership
    - depends on TE Node capabilities I-D
      * first version of WG draft
        - based on draft-vasseur-ccamp-automesh-00.txt
      * submit for IESG review

    Multi-layer networks (also multi-region networks)
    - Requirements
      * first version of WG draft
        - based on draft-shiomoto-ccamp-gmpls-mrn-reqs-02.txt
      * submit for IESG review
    - Evaluation of existing protocols
      * first version of WG draft
        - based on draft-leroux-ccamp-gmpls-mrn-eval-01.txt
      * submit for IESG review
    - Solutions
      * first version of WG draft
        - based on draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt
      * submit for IESG review

    MPLS-GMPLS interworking requirements and solutions
      * first version of WG draft
        - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt
        - material from =
draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt
      * submit for IESG review

    MPLS to GMPLS migration strategies
      * Informational I-D first version of WG draft
        - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt
        - material from =
draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt
      * submit Informational I-D for IESG review

  Minor items just starting but close to heart of WG
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


    GMPLS OAM Requirements
    - Interesting and worthwhile
      * first version of WG draft
        - based on immature =
draft-nadeau-ccamp-gmpls-oam-requirements-00.txt
      * submit for IESG review

  Minor items just starting and important becuase of inter-SDO =
interactions
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    GMPLS coordination of VCAT and LCAS
    - single requirements and solutions draft almost an applicablity =
statement
      * first version of WG draft
        - based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt
      * submit for IESG review

    Change of LSP ownership between management and control planes
    - single requirements and solutions draft defines one bit and a =
procedure
      * first version of WG draft
        - based on draft-caviglia-mp2cpcp2mp-02.txt
      * submit for IESG review

  Other work items with no specific milestones identified yet
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D

    Control Plane Robustness
    - draft-ali-ccamp-mpls-graceful-shutdown-xx.txt  Graceful shutdown.
    - draft-leroux-ccamp-ctrl-saturation-01.txt      Control Plane =
Saturation
    - draft-kim-ccamp-cpr-reqts-00.txt               Control Plane =
Resilience
    - draft-kim-ccamp-cc-protection-04.txt           Control Channel =
Protection

------=_NextPart_000_000D_01C5A573.57FD0930--




Envelope-to: [e-mail]
Delivery-date: Fri, 19 Aug 2005 11:40:18 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Requesting a LSC LSP across a PCS interface
Date: Fri, 19 Aug 2005 13:39:54 +0200
Message-ID: <[e-mail]>
Thread-Topic: Requesting a LSC LSP across a PCS interface
Thread-Index: AcWkQsg0/RO6ZiiGSbSHPuZYQSJDeQAboLbg
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

=20

>=20
> hi,
>=20
> > Consider the following situation:
> >=20
> >        Domain A <=3D | =3D>         Domain B         <=3D | =3D> =
Domain C
> >                    |                                |
> >  [A1]--PSC--[A2]--PSC--[B1]--LSC--[B2]--LSC--[B4]--PSC--[C1]
> >                    |     |                    |     |
> >                          |---PSC--[B3]--PSC---|
> >=20
> >=20
> > Suppose I want to setup an (PSC) LSP from [A1] to [C1]. In domain B
> > there are two options, the PSC route, or the LSC route. Is=20
> there a way
> > to request (or hint for) a LSC LSP in domain B for the=20
> A1-C1 LSP? For
> > example because the quality of the PSC path is deemed=20
> insufficient from
> > the point of view of domains A and C (e.g. A and C are vey=20
> high bw LAN
> > enviroments, B a WAN environment).
>=20
> base on your diagram and assuming symmetric links both nodes=20
> B1 and B4=20
> must have a PSC and LSC switching capability so here and as=20
> provided in=20
> the diagram i assume the boundary is on the node; however, if=20
> you mean=20
> [B1,B4] and [B2,B4] being [PSC,LSC] and [LSC,PSC] resp. then=20
> B1 and B4=20
> are simple PSC nodes with LSC interfaces and then the=20
> boundary would be=20
> on the interface
>=20

I envisioned the boundary on the node indeed. But on the interface could
be an option as well.

> now, if all domains are in the same routing area
> - have strict path all along
> - B4 loose hop with explicit indication of incoming interface
>=20

Okay.

> if all domains not in the same routing area
> - make use of constaint passing by including (or excluding) specific=20
> switching capability such as to indicate which resource type to=20
> select/preclude in order to reach the destination B4 (loose hop)
>

So if I understand correctly, the LSP would be something like this:
A1 to C1 via: A2 (strict), B1 (strict), B4 (loose, LSC), C1 (loose)
=20
> hope this helps,

Yes, thanks.

Eduard

> - dimitri.
>=20
> > Thanks!
> >=20
> > cheers,
> > 	Eduard
> >=20
> >=20
> >=20
> > .
> >=20
>=20



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Aug 2005 11:25:50 +0000
Message-ID: <061201c5a4b1$10d13580$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Wataru Imajuku" <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Date: Fri, 19 Aug 2005 12:20:36 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

Hi,

Thanks for your comments.

Do you think it may be premature to apply 803.2ad techniques before we
have done any work to control Ethernet networks with GMPLS?

You are right that IEEE link aggregation is conceptually very close to
bundling.

I suggest that you need to separate TDM and Ethernet concepts in your I-D.
Take the TDM issues to Diego, Richard, Greg et alia for inclusion in the
VCAT/LCAS work. Take your LAGR issues to Dimitri and Loa for inclusion in
the "GMPLS control of Ethernet switching" work that they are doing.

Thanks,
Adrian

----- Original Message ----- 
From: "Wataru Imajuku" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Sent: Thursday, August 18, 2005 9:59 PM
Subject: Re: Moving forward with the CCAMP charter


> Hi, Adrian
>
>   Thank you for giving your time interim your hard work.
>
> >With regard to your section 5, I note that you consider the VCAT group
> >analogous with a link bundle. I don't think this is correct because the
> >members of a link bundle must be selected and used individually. A
payload
> >data stream cannot be distributed across multiple component links of
the
> >bundle...
> >    An LSP with a bandwidth requirement b and
> >    setup priority p fits in a bundled link if at least one component
> >    link has maximum LSP bandwidth >= b at priority p.
> >However, the whole point of a VCAT group is to produce a single entity
> >(pipe) with maximum LSP bandwidth greater than the capacity of any
> >individual component. A VCAT group, therefore, is not a bundle.
> >
> >Following on from this, I think that the remainder of your section 5.1
> >will have some value, but needs to be corrected to properly reflect the
> >meaning of a VCAT group.
> >
> >In general, I think your section 5 should generalize from the specific
> >case of the FA to include any TE link that is based on a VCAT group.
> >
> >Section 5.2 seems to confuse "FA" with "FA LSP".
>
>   Regarding to VCAT, I agree to your comment.
>   But, this draft also covers LAGR (link aggregation) which has some
limitations
> to transmit data-flow exceeding the bandwidth of each comopnent LSP.
>
>   This is one of reason why the description wirtten in Section 5 exists,
although
> some terminologies are not proper as you noted.
>
> Thanks
> Wataru
>
> ---------------------------------
> Wataru Imajuku
> Senior Research Engineer
> @NTT Network Innovation Labs.
> TEL [phone]
> FAX [phone]
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 19 Aug 2005 11:25:42 +0000
Message-ID: <061101c5a4b1$0f829570$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Kireeti Kompella" <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Date: Fri, 19 Aug 2005 12:15:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Lyndon,

> As with everyone else, I appreciate all of the work that
> you put in to create a very detailed workplan for the group.

Thanks.

> Some follow up questions and suggestions:
>
> -- On the "aligning GMPLS across standards bodies" item:
>
> First of all, what standards bodies do you see included under
> this effort?

Any and every that is or plans to use GMPLS or derive a variant of GMPLS.

> Also, are you intending this to be a unilateral document on ccamp's
> part?

Yes.

> If it is, I'm not sure I see what it would say besides "use the RFCs or
> bring the requirements back to us", which is what this group has said in
> the past.  If on the other hand you see this as the basis for joint
> discussion with other bodies, it might be a very helpful activity.

First, I refuse to be hamstrung by history.
Note that alignment requires that we start from where we are now (with
non-interoperable variations of the protocols) and try to resolve the
problem.

Second, doing this work does not preclude discussing with other bodies.
In fact, the draft is likely to lead specifically to discussions with
other bodies.
However, it is not pragmatic or wise to discuss with other bodies the
actions which CCAMP thinks it should take. These are CCAMP actions.

> -- On the ""routing and signaling for complex optical constraints" item:
>
> The ashwood draft seems to me to have two components, one being
> requirements and considerations of routing across a purely photonic
> domain and the second being a particular solution (the matrix
> representation), to which there are alternatives such as the virtual
link
> approach that Igor has identified.
>
> I think these two should probably be separated, as the solution may be
> more widely applied to any situation of advertising a virtualized
> topology, such as in enhanced l1vpn.

You'll notice that the work item is stated as "Analysis and protocol
changes for routing and signaling for link viability constraints" whether
this turns into one, two or a hundred I-Ds cannot possibly be determined
at this point. I suspect that the issue of routing across a photonic
domain as described in the Ashwood I-D is only a special case of a generic
multi-domain TE issue. Hence this item appears under the Inter-Domain
heading and is described much more generally.

You are correct that some of this would feed into (overlap with) the L1VPN
enhanced mode.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 19 Aug 2005 11:13:43 +0000
Date: Fri, 19 Aug 2005 20:13:35 +0900
From: Akira NAGATA <[e-mail]>
To: [e-mail]
Subject: Question on Administratively down bit
Cc: Akira_NAGATA <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Mr. Lou Berger and editors of RFC3471 and RFC3473,

This is my first time to send e-mail to ccamp.
Thanks in advance.

I'd like to ask one question about the handling of Administratively down bit
in GMPLS RSVP-TE's Admin_Status object.

RFC3471 introduces "inhibiting alarm reporting" as an example application 
of local action to "down" state (that is, A-bit=1) in Section 8.
But I can't find any other explicit descriptions about this procedure
in RFC3471 or 3473.

I understand that actions to be taken by each node receiving Admin_Status
object shall be based on local policy.

With regard to inhibition of alarm reporting, however, in order to achieve it
through end-to-end, I believe that we had better take a unified action
as a response to A-bit ("down" or "up").
Operator will expect this feature.

(Here I mean alarm report is not reporting via RSVP messages as described
in ID-alarm-spec, but one from NE to external system such as network
management system.)

Are there any considerations, drafts or RFCs to define it?

Thanks,
---
Akira NAGATA <[e-mail]>




Envelope-to: [e-mail]
Delivery-date: Fri, 19 Aug 2005 10:07:09 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Aug 2005 12:06:47 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Huub van Helvoort <[e-mail]>
CC: ccamp <[e-mail]>, adrian <[e-mail]>
Subject: Re: MS-SPring
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi huub,

Huub van Helvoort wrote:

> Hallo Dimitri,
> 
> You responded to Diego:
> 
>> Diego Caviglia wrote:
>>
>>> Hi Dimitri,
>>>             given the high number of MS-SPRing protected transport 
>>> network
>>> already deployed seems reasonable to me, from a Network Operator 
>>> point of
>>> view, to use at the same time MS-SPRing protection with GMPLS 
>>> restoration.
>>
>> there are already two questions here 1. is there an operational need 
>> to control such rings using GMPLS (? for instance is it effective 
>> knowing that ring based protection is mainly data plane driven ?) and 
>> 2. how to position the ring protection wrt to the LSP recovery 
>> segment/end-to-end recovery
> 
> The first step in MS-Spring is indeed dataplane driven (using APS)
> but that involves only nodes adjacent to the fault.

ok, btw, is there a reason to restrict to MS/line protection ring ?

> The reconfiguration of the ring after this first switch is controlplane
> driven and concerns all nodes in the ring.

ok with this - like for other linear protection schemes the control 
plane would be involved in the provisioning

also, what about the (informational) notification to maintain the 
control plane aware about the data plane status after failure detection 
and/or after the APS operation

thanks,
- dimitri.

> Cheers, Huub.
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Aug 2005 10:05:07 +0000
Message-ID: <05c701c5a4a5$c17274f0$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Subject: Control Plane Robustness [Was: Moving forward with the CCAMP charter]
Date: Fri, 19 Aug 2005 11:05:45 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
Content-Transfer-Encoding: 8bit

Hi,

I think you are Young Hwa Kim.

> I propose that we handle control plane resilience in our CCAMP
> charter.

Since two other drafts in the same sort of area have also been mentioned
(draft-ali-ccamp-mpls-graceful-shutdown and
draft-leroux-ccamp-ctrl-saturation) I think we are seeing some support for
a work item on control plane robustness.

> I think that the CCAMP WG is focussing on the data and control
> planes for GMPLS.
> Until now we have handled the data plane part for resilience, but
> we have no results of control plane resilience.
> I had presented my contribution for requirements of control plane
> resilience through draft-kim-ccamp-cpr-reqts-00.txt last year.
> On the November meeting this year, I will present an updated
> document of requirements for control plane resilience , and a
> new or extended protocol specification document for control
> plane resilience.

I hope you will not wait for the November meeting. The intention of the
meetings is to meet and discuss technical issues, not to act as a
submission deadline for new versions of drafts. It is always helpful to
publish drafts in good time and as soon as they are ready so that they can
be reviewed and discussed.

I am surprised that you do not also mention
draft-kim-ccamp-cc-protection-04.txt

It would be helpful if the WG could look at your two drafts and comment.
As yet there has not been wide support expressed for what you are
suggesting, and I need to see a greater degree of consensus before I can
bring this into the WG.

Thus my feeling at the moment is that Control Plane Robustness should be
an area that CCAMP looks at, but we should not set any specific
milestones.

Regards,
Adrian

> Of course, I think it's possible under the condition that the topic of
control plane
> resilience could be handled in the CCAMP charter.

-----¢¯©ª¨¬¡í ¢¬¨­¨öAAo-----
From: "Adrian Farrel" <[e-mail]>
>From Date: 2005-08-16 ¢¯AEA 8:28:11
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "'Kireeti Kompella'"
<[e-mail]>
Subject: Moving forward with the CCAMP charter


Hi,

Please find attached a file that contains:

- a set of proposed *draft* milestones
- a discussion of why there are so many milestones
- a high-level explanation of the work items.

Note that this looks like a lot of milestones, but please read the text on
this issue in the attached file. The bottom line is that this is a product
of micro management where I have tried to identify all of the I-Ds that we
might produce to cover the referenced work, and where I have placed two
(sometimes three) milestones for each I-D.

This micro-management may be over the top, and represents a full pendulum
swing from the previous style of CCAMP milestones, but in the light of the
hiatus of the last 12 months, i think this may be beneficial and might
achieve rapid forwards movement.

I would welcome your (constructive!) comments.

Notes:
- Why isn't my I-D also cited as input material?
  No insult intended. The current list is simply there to
  show the ADs that work is already in progress. All I-Ds
  will be used as input.
- Why isn't my pet topic included?
  Are you sure it is not there between the lines? This
  list of milestones isn't completely proscriptive.

The objective is to have the WG agreed on the milestones that it wants to
commit to by the end of August.

Thanks,
Adrian

----- Original Message ----- 
From: "±è¿µÈ­" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; "'Kireeti Kompella'" <[e-mail]>
Sent: Friday, August 19, 2005 10:32 AM
Subject: RE: Moving forward with the CCAMP charter


>




Envelope-to: [e-mail]
Delivery-date: Fri, 19 Aug 2005 09:31:55 +0000
Thread-Topic: Moving forward with the CCAMP charter
thread-index: AcWkoP0mQI0llS9oRE2pPqaplaS5cg==
Content-Transfer-Encoding: 7bit
Reply-To: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
From: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Bcc: 
Subject: RE: Moving forward with the CCAMP charter
Date: Fri, 19 Aug 2005 18:32:59 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBPQU2x4rz6xsAsILTjtOc=?=
Message-ID: <99e101c5a4a0$fd2b4080$8310fe81@email1>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_99DC_01C5A4EC.6D0E0680"
Content-Class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_99DC_01C5A4EC.6D0E0680
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64


------=_NextPart_000_99DC_01C5A4EC.6D0E0680
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy
Ij4NCjxESVY+SGksIDxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDA4MD5BZHJpYW4gYW5kIGNj
YW1wZXJzIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDgw
PkkgcHJvcG9zZSB0aGF0IHdlIGhhbmRsZSBjb250cm9sIHBsYW5lIHJlc2lsaWVuY2UgaW4gb3Vy
IENDQU1QIGNoYXJ0ZXIuPC9GT05UPjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh
bCBjb2xvcj0jMDAwMDgwPkkgdGhpbmsgdGhhdCB0aGUgQ0NBTVAgV0cgaXMgZm9jdXNzaW5nIG9u
IHRoZSBkYXRhIGFuZCBjb250cm9sIHBsYW5lcyBmb3IgR01QTFMuPC9GT05UPjwvRElWPjwvRElW
Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwODA+VW50aWwgbm93IHdlIGhhdmUg
aGFuZGxlZCB0aGUgZGF0YSBwbGFuZSBwYXJ0IGZvciByZXNpbGllbmNlLCBidXQgd2UgaGF2ZSBu
byByZXN1bHRzIG9mIGNvbnRyb2wgcGxhbmUgcmVzaWxpZW5jZS48L0ZPTlQ+PC9ESVY+DQo8RElW
PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDA4MD5JIGhhZCBwcmVzZW50ZWQgbXkgY29udHJp
YnV0aW9uIGZvciByZXF1aXJlbWVudHMgb2YgY29udHJvbCBwbGFuZSByZXNpbGllbmNlIHRocm91
Z2ggZHJhZnQta2ltLWNjYW1wLWNwci1yZXF0cy0wMC50eHQgbGFzdCB5ZWFyLjwvRk9OVD48L0RJ
Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDgwPk9uIHRoZSBOb3ZlbWJlciBt
ZWV0aW5nIHRoaXMgeWVhciwgSSB3aWxsIHByZXNlbnQgYW4gdXBkYXRlZCBkb2N1bWVudCBvZiBy
ZXF1aXJlbWVudHMgZm9yIGNvbnRyb2wgcGxhbmUgcmVzaWxpZW5jZSAsIGFuZCBhIG5ldyBvciBl
eHRlbmRlZCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGRvY3VtZW50IGZvciBjb250cm9sIHBsYW5l
IHJlc2lsaWVuY2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw
MDAwODA+T2YgY291cnNlLCBJIHRoaW5rIGl0J3MgcG9zc2libGUgdW5kZXIgdGhlIGNvbmRpdGlv
biB0aGF0IHRoZSB0b3BpYyBvZiBjb250cm9sIHBsYW5lIHJlc2lsaWVuY2UgY291bGQgYmUgaGFu
ZGxlZCBpbiB0aGUgQ0NBTVAgY2hhcnRlci48L0ZPTlQ+PC9ESVY+DQo8RElWPjxCUj4tLS0tLb/4
ursguN69w8H2LS0tLS08QlI+PEI+RnJvbTo8L0I+ICJBZHJpYW4gRmFycmVsIiAmbHQ7YWRyaWFu
QG9sZGRvZy5jby51ayZndDs8QlI+PEI+RnJvbSBEYXRlOjwvQj4gMjAwNS0wOC0xNiC/wMjEIDg6
Mjg6MTE8QlI+PEI+VG86PC9CPiAiY2NhbXBAb3BzLmlldGYub3JnIiAmbHQ7Y2NhbXBAb3BzLmll
dGYub3JnJmd0OzxCUj48Qj5DYzo8L0I+ICJ6aW5pbkBwc2cuY29tIiAmbHQ7emluaW5AcHNnLmNv
bSZndDssICInS2lyZWV0aSBLb21wZWxsYSciICZsdDtraXJlZXRpQGp1bmlwZXIubmV0Jmd0OzxC
Uj48Qj5TdWJqZWN0OjwvQj4gTW92aW5nIGZvcndhcmQgd2l0aCB0aGUgQ0NBTVAgY2hhcnRlcjxC
Uj48QlI+PC9ESVY+PCEtLSBzdHlsZT48L3N0eWxlIC0tPg0KPERJViBiZ0NvbG9yPSIjZmZmZmZm
IiBiYWNrZ3JvdW5kPSIiPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPkhpLDxCUj48
QlI+UGxlYXNlIGZpbmQgYXR0YWNoZWQgYSBmaWxlIHRoYXQgY29udGFpbnM6PEJSPjxCUj4tIGEg
c2V0IG9mIHByb3Bvc2VkICpkcmFmdCogbWlsZXN0b25lczxCUj4tIGEgZGlzY3Vzc2lvbiBvZiB3
aHkgdGhlcmUgYXJlIHNvIG1hbnkgbWlsZXN0b25lczxCUj4tIGEgaGlnaC1sZXZlbCBleHBsYW5h
dGlvbiBvZiB0aGUgd29yayBpdGVtcy48QlI+PEJSPk5vdGUgdGhhdCB0aGlzIGxvb2tzIGxpa2Ug
YSBsb3Qgb2YgbWlsZXN0b25lcywgYnV0IHBsZWFzZSByZWFkIHRoZSB0ZXh0IG9uIHRoaXMgaXNz
dWUgaW4gdGhlIGF0dGFjaGVkIGZpbGUuIFRoZSBib3R0b20gbGluZSBpcyB0aGF0IHRoaXMgaXMg
YSBwcm9kdWN0IG9mIG1pY3JvIG1hbmFnZW1lbnQgd2hlcmUgSSBoYXZlIHRyaWVkIHRvIGlkZW50
aWZ5IGFsbCBvZiB0aGUgSS1EcyB0aGF0IHdlIG1pZ2h0IHByb2R1Y2UgdG8gY292ZXIgdGhlIHJl
ZmVyZW5jZWQgd29yaywgYW5kIHdoZXJlIEkgaGF2ZSBwbGFjZWQgdHdvIChzb21ldGltZXMgdGhy
ZWUpIG1pbGVzdG9uZXMgZm9yIGVhY2ggSS1ELjxCUj48QlI+VGhpcyBtaWNyby1tYW5hZ2VtZW50
IG1heSBiZSBvdmVyIHRoZSB0b3AsIGFuZCByZXByZXNlbnRzIGEgZnVsbCBwZW5kdWx1bSBzd2lu
ZyBmcm9tIHRoZSBwcmV2aW91cyBzdHlsZSBvZiBDQ0FNUCBtaWxlc3RvbmVzLCBidXQgaW4gdGhl
IGxpZ2h0IG9mIHRoZSBoaWF0dXMgb2YgdGhlIGxhc3QgMTIgbW9udGhzLCBpIHRoaW5rIHRoaXMg
bWF5IGJlIGJlbmVmaWNpYWwgYW5kIG1pZ2h0IGFjaGlldmUgcmFwaWQgZm9yd2FyZHMgbW92ZW1l
bnQuPEJSPjxCUj5JIHdvdWxkIHdlbGNvbWUgeW91ciAoY29uc3RydWN0aXZlISkgY29tbWVudHMu
PEJSPjxCUj5Ob3Rlczo8QlI+LSBXaHkgaXNuJ3QgbXkgSS1EIGFsc28gY2l0ZWQgYXMgaW5wdXQg
bWF0ZXJpYWw/PEJSPiZuYnNwOyBObyBpbnN1bHQgaW50ZW5kZWQuIFRoZSBjdXJyZW50IGxpc3Qg
aXMgc2ltcGx5IHRoZXJlIHRvPEJSPiZuYnNwOyBzaG93IHRoZSBBRHMgdGhhdCB3b3JrIGlzIGFs
cmVhZHkgaW4gcHJvZ3Jlc3MuIEFsbCBJLURzPEJSPiZuYnNwOyB3aWxsIGJlIHVzZWQgYXMgaW5w
dXQuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxCUj4tIFdoeSBpc24ndCBteSBwZXQg
dG9waWMgaW5jbHVkZWQ/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6
ZT0yPiZuYnNwOyZuYnNwO0FyZSB5b3Ugc3VyZSBpdCBpcyBub3QgdGhlcmUgYmV0d2VlbiB0aGUg
bGluZXM/IFRoaXMgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0y
PiZuYnNwOyBsaXN0IG9mIG1pbGVzdG9uZXMgaXNuJ3QgY29tcGxldGVseSBwcm9zY3JpcHRpdmUu
PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPiZuYnNwOyA8L0ZP
TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllciBzaXplPTI+VGhlIG9iamVjdGl2ZSBp
cyB0byBoYXZlIHRoZSBXRyBhZ3JlZWQgb24gdGhlIG1pbGVzdG9uZXMgdGhhdCBpdCB3YW50cyB0
byBjb21taXQgdG8gYnkgdGhlIGVuZCBvZiBBdWd1c3QuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O
VCBmYWNlPUNvdXJpZXIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj
ZT1Db3VyaWVyIHNpemU9Mj5UaGFua3MsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNv
dXJpZXIgc2l6ZT0yPkFkcmlhbjwvRk9OVD48L0RJVj48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJk
aXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5r
ci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFpbD1jY2FtcEBvcHMuaWV0Zi5vcmcmbmFtZT1j
Y2FtcCU0MG9wcy5pZXRmLm9yZyZmcm9tZW1haWw9eWh3a2ltQGV0cmkucmUua3ImbWVzc2FnZWlk
PSUzQ2FiOGIzMjQzLTQ5ZGEtNGM4Zi1iZGNhLTBlNGIwNWM5YTNlZEBldHJpLnJlLmtyJTNFIj4=

------=_NextPart_000_99DC_01C5A4EC.6D0E0680--



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Aug 2005 08:41:59 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Aug 2005 10:40:16 +0200
From: Huub van Helvoort <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: ccamp <[e-mail]>
CC: adrian <[e-mail]>
Subject: Re: MS-SPring 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hallo Dimitri,

You responded to Diego:

> Diego Caviglia wrote:
> 
>> Hi Dimitri,
>>             given the high number of MS-SPRing protected transport 
>> network
>> already deployed seems reasonable to me, from a Network Operator point of
>> view, to use at the same time MS-SPRing protection with GMPLS 
>> restoration.
> 
> there are already two questions here 1. is there an operational need to 
> control such rings using GMPLS (? for instance is it effective knowing 
> that ring based protection is mainly data plane driven ?) and 2. how to 
> position the ring protection wrt to the LSP recovery segment/end-to-end 
> recovery

The first step in MS-Spring is indeed dataplane driven (using APS)
but that involves only nodes adjacent to the fault.

The reconfiguration of the ring after this first switch is controlplane
driven and concerns all nodes in the ring.

Cheers, Huub.

-- 
================================================================
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2005 23:10:03 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Moving forward with the CCAMP charter
Date: Thu, 18 Aug 2005 19:08:55 -0400
Message-ID: <[e-mail]>
Thread-Topic: Moving forward with the CCAMP charter
Thread-Index: AcWilg75TdCjxl3eTNOrTkDcUO9BPQBsYjFg
From: "Ong, Lyndon" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Kireeti Kompella" <[e-mail]>

Hi Adrian,

As with everyone else, I appreciate all of the work that
you put in to create a very detailed workplan for the group.

Some follow up questions and suggestions:=20

-- On the "aligning GMPLS across standards bodies" item:

First of all, what standards bodies do you see included under
this effort?
 =20
Also, are you intending this to be a unilateral document on ccamp's
part?
If it is, I'm not sure I see what it would say besides "use the RFCs or
bring the requirements back to us", which is what this group has said in

the past.  If on the other hand you see this as the basis for joint
discussion with
other bodies, it might be a very helpful activity.

-- On the ""routing and signaling for complex optical constraints" item:

The ashwood draft seems to me to have two components, one being=20
requirements and considerations of routing across a purely photonic
domain
and the second being a particular solution (the matrix representation),
to
which there are alternatives such as the virtual link approach that Igor
has identified. =20

I think these two should probably be separated, as the solution may be=20
more widely applied to any situation of advertising a virtualized=20
topology, such as in enhanced l1vpn.

Cheers,

Lyndon



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2005 22:41:29 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Aug 2005 00:40:50 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: Evelyne Roch <[e-mail]>,  [e-mail]
Subject: Re: Responding to the OIF
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Adrian Farrel wrote:
> Hi Evelyne,
> 
> 
>>1. From the examples below, STS3c and VC4 have different
>> RCC/NCC values. Clarifications on which values should be
>>used for SONET/SDH interworking would be useful.
>  
> I have a couple of folks looking at this for me because I can't tell the
> difference between a timeslice and a cakeslice.
> 
> Hopefully they will generate a response soon.

this may help -

    "A dedicated signal type is assigned to a SONET STS-3c SPE instead of
    coding it as a contiguous concatenation of three STS-1 SPEs. This is
    done in order to provide easy interworking between SONET and SDH
    signaling."

also the RFC explains how the negotiation occurs (RCC/NCC selection is a 
local decision process depending on the supported capabilities) - not a 
big deal here, there are 4 cases possible:

- symmetric fixed case either SDH or SONET on both sides, there is no 
interworking issue possible

- symmetric configurable case (assumption taken by OIF) where selection 
is not impacting establishment, there is no interworking issue possible

- asymmetric fixed-configurable case: the upstream node drives the 
selection by indicating the selected values, there is no interworking 
issue possible

- asymmetric configurable-fixed case: an error is generated if the 
config supported by the fixed side is not selected by the upstream node 
but signaling just follows result of the selection - however, GMPLS 
signaling can not correct this in any case -

>>5. Is a change in the presence/absence of ResvConf considered a
>>trigger message?
> 
> 
> Yes, it would be a trigger message (that is, it would not be treated as a
> simple refresh). But a "trigger message" does not necessarily cause any
> action.
> 
> 
>>My interpretation of the text below is that a refresh resv
>>message containing a RESV_CONF object would not
>>result in the generation of a RESV_CONF message,
>>RESV_CONF messages only being sent on trigger
>>resv message. Is that correct?
> 
> 
> Seems reasonable to me.
> That way the ResvConf confirms the receipt of the changed Resv.
> 
> I guess I should have added a note that a ResvConf message is not
> necessarily reliably delivered. Relying on the receipt of a ResvConf
> message before doing something (e.g. turning on the laser) might be a poor
> idea. GMPLS uses the Administrative Status object and in particular the
> R-bit in order to reliably achieve this function.
> 
> Adrian
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2005 22:19:13 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Aug 2005 00:18:19 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To:  [e-mail]
CC:  [e-mail]
Subject: Re: Requesting a LSC LSP across a PCS interface
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi,

> Consider the following situation:
> 
>        Domain A <= | =>         Domain B         <= | => Domain C
>                    |                                |
>  [A1]--PSC--[A2]--PSC--[B1]--LSC--[B2]--LSC--[B4]--PSC--[C1]
>                    |     |                    |     |
>                          |---PSC--[B3]--PSC---|
> 
> 
> Suppose I want to setup an (PSC) LSP from [A1] to [C1]. In domain B
> there are two options, the PSC route, or the LSC route. Is there a way
> to request (or hint for) a LSC LSP in domain B for the A1-C1 LSP? For
> example because the quality of the PSC path is deemed insufficient from
> the point of view of domains A and C (e.g. A and C are vey high bw LAN
> enviroments, B a WAN environment).

base on your diagram and assuming symmetric links both nodes B1 and B4 
must have a PSC and LSC switching capability so here and as provided in 
the diagram i assume the boundary is on the node; however, if you mean 
[B1,B4] and [B2,B4] being [PSC,LSC] and [LSC,PSC] resp. then B1 and B4 
are simple PSC nodes with LSC interfaces and then the boundary would be 
on the interface

now, if all domains are in the same routing area
- have strict path all along
- B4 loose hop with explicit indication of incoming interface

if all domains not in the same routing area
- make use of constaint passing by including (or excluding) specific 
switching capability such as to indicate which resource type to 
select/preclude in order to reach the destination B4 (loose hop)

hope this helps,
- dimitri.

> Thanks!
> 
> cheers,
> 	Eduard
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2005 21:44:25 +0000
Message-ID: <055c01c5a43e$43aa2980$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Evelyne Roch" <[e-mail]>, <[e-mail]>
Subject: Re: Responding to the OIF
Date: Thu, 18 Aug 2005 22:43:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Evelyne,

> 1. From the examples below, STS3c and VC4 have different
>  RCC/NCC values. Clarifications on which values should be
> used for SONET/SDH interworking would be useful.

I have a couple of folks looking at this for me because I can't tell the
difference between a timeslice and a cakeslice.

Hopefully they will generate a response soon.

> 5. Is a change in the presence/absence of ResvConf considered a
> trigger message?

Yes, it would be a trigger message (that is, it would not be treated as a
simple refresh). But a "trigger message" does not necessarily cause any
action.

> My interpretation of the text below is that a refresh resv
> message containing a RESV_CONF object would not
> result in the generation of a RESV_CONF message,
> RESV_CONF messages only being sent on trigger
> resv message. Is that correct?

Seems reasonable to me.
That way the ResvConf confirms the receipt of the changed Resv.

I guess I should have added a note that a ResvConf message is not
necessarily reliably delivered. Relying on the receipt of a ResvConf
message before doing something (e.g. turning on the laser) might be a poor
idea. GMPLS uses the Administrative Status object and in particular the
R-bit in order to reliably achieve this function.

Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2005 20:59:31 +0000
Message-Id: <[e-mail]>
Date: Fri, 19 Aug 2005 05:59:21 +0900
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Adrian

  Thank you for giving your time interim your hard work.

>With regard to your section 5, I note that you consider the VCAT group
>analogous with a link bundle. I don't think this is correct because the
>members of a link bundle must be selected and used individually. A payload
>data stream cannot be distributed across multiple component links of the
>bundle...
>    An LSP with a bandwidth requirement b and
>    setup priority p fits in a bundled link if at least one component
>    link has maximum LSP bandwidth >= b at priority p.
>However, the whole point of a VCAT group is to produce a single entity
>(pipe) with maximum LSP bandwidth greater than the capacity of any
>individual component. A VCAT group, therefore, is not a bundle.
>
>Following on from this, I think that the remainder of your section 5.1
>will have some value, but needs to be corrected to properly reflect the
>meaning of a VCAT group.
>
>In general, I think your section 5 should generalize from the specific
>case of the FA to include any TE link that is based on a VCAT group.
>
>Section 5.2 seems to confuse "FA" with "FA LSP".

  Regarding to VCAT, I agree to your comment.
  But, this draft also covers LAGR (link aggregation) which has some limitations
to transmit data-flow exceeding the bandwidth of each comopnent LSP.

  This is one of reason why the description wirtten in Section 5 exists, although
some terminologies are not proper as you noted.

Thanks
Wataru

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone] 




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2005 20:09:08 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A430.48FA5368"
Subject: RE: Responding to the OIF
Date: Thu, 18 Aug 2005 16:06:13 -0400
Message-ID: <[e-mail]>
Thread-Topic: Responding to the OIF
Thread-Index: AcWec2jLWKQ51KG2TrmueCxhk3p2/wFvNy9Q
From: "Evelyne Roch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5A430.48FA5368
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
Regarding the following points:
=20
1. From the examples below, STS3c and VC4 have different RCC/NCC values.
Clarifications on which values should be used for SONET/SDH interworking
would be useful.

5. Is a change in the presence/absence of ResvConf considered a trigger
message?  My interpretation of the text below is that a refresh resv
message containing a RESV_CONF object would not result in the generation
of a RESV_CONF message, RESV_CONF messages only being sent on trigger
resv message. Is that correct?
=20
=20
Regards,
Evelyne Roch=20
Control Plane Software=20
Nortel Networks=20
PO Box 3511 STN C Ottawa ON K1Y 4H7=20
* Phone: [phone] (esn 393)=20
* e-mail [mailto:[e-mail]]=20

	-----Original Message-----
	From: [e-mail] [mailto:[e-mail]]
On Behalf Of Adrian Farrel
	Sent: Thursday, August 11, 2005 8:43 AM
	To: [e-mail]
	Subject: Responding to the OIF
=09
=09
	Hi,
=09
	As Lyndon noted in Paris, the OIF has sent us a communication
requesting some guidance on a bunch of questions.
=09
	This is to start the business of constructing a reply. thanks to
Dimitri for supplying some of this text.
=09
	Please send comments and improvements.
=09
	Adrian
=09
	=3D=3D=3D=3D=3D=3D
=09
	To: Jim Jones, OIF Technical Committee Chair
	From: Adrian Farrel and Kireeti Kompella,=20
	          WG Co-Chairs for IETF CCAMP
	Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors
	Subject: Response to your questions about GMPLS parameters.
=09
	Dear Jim,
=09
	Thanks for your correspondence about the questions with respect
to GMPLS parameters that arose before and during your interoperability
testing. CCAMP is pleased to receive such questions and is glad to have
the opportunity to explain the intended operation of the GMPLS
protocols.
	=20
	Much of the material supplied below can be simply extracted from
the relevant RFCs.


	> 1. Use of the NCC and RCC fields for STS-3c/VC-4 connections
	>=20
	> During OIF testing it was noted that some ambiguity exists in
the
	> specification of encoding of NCC, RCC and NVC for certain
types of
	> connections: NCC and RCC for an STS-3c/VC-4 connection can be
set to 0 or
	> to 1 depending on which example of RFC 3946 is followed.
	>=20
	> Clarification is requested from IETF CCAMP as to which setting
is
	> considered correct, or if both settings should be accepted
(this procedure
	> was used during testing at Supercomm).
=09
	This question about RFC 3946 was raised informally on the CCAMP
mailing list at the start of March this year.=20
=09
	Even when the signal Type value is the same (i.e. value 6) the
NCC, RCC and NVC values depend on the specific signal being requested.
=09
	From the examples in the annex we have...
=09
	   A VC-4 signal is formed by applying the following
	   settings to a VC-4 Elementary Signal.
	      RCC =3D 0
	      NCC =3D 0
	      NVC =3D 0
	      MT  =3D 1
	      T   =3D 0
=09
	   An STS-3c SPE signal is formed by applying the following
	   settings to an STS-3c SPE Elementary Signal.
	      RCC =3D 1 (standard contiguous concatenation)
	      NCC =3D 1
	      NVC =3D 0
	      MT  =3D 1
	      T   =3D 0
=09
	Your question probably arises from the two notes and subsequent
paragraph in section 2.1 or RFC 3946. Here it says...
=09
	   Note 1: when requesting a SONET STS-Nc SPE with N=3D3*X, the
	      Elementary Signal to use must always be an STS-3c_SPE
signal type
	      and the value of NCC must always be equal to X.  This
allows also
	      facilitating the interworking between SONET and SDH.  In
	      particular, it means that the contiguous concatenation of
three
	      STS-1 SPEs can not be requested because according to this
	      specification, this type of signal must be coded using the
STS-3c
	      SPE signal type.
=09
	   Note 2: when requesting a transparent STS-N/STM-N signal
	      limited to a single contiguously concatenated
STS-Nc_SPE/VC-4-Nc,
	      the signal type must be STS-N/STM-N, RCC with flag 1 and
NCC set
	      to 1.
=09
	   The NCC value must be consistent with the type of contiguous
	   concatenation being requested in the RCC field.  In
particular, this
	   field is irrelevant if no contiguous concatenation is
requested (RCC
	   =3D 0), in that case it must be set to zero when sent, and
should be
	   ignored when received.  A RCC value different from 0 must
imply a
	   number of contiguous components greater than 1.
=09
	We believe that this final sentence should read "greater than or
equal to 1," and that this interpretation resolves all of your issues
and makes the text consistent with the examples.
=09
	> 2. Setting of NVC for VCAT connections
	>=20
	> It was also noted that the setting of NVC may be somewhat
ambiguous for
	> the case where diverse connections are used within a single
VCAT group.
	> Each individual RSVP session controls a single connection, but
the
	> connection is part of a larger VCAT group and carries VCAT
encoding of the
	> H4 byte. Clarification is requested from IETF CCAMP and ITU-T
Q.14/15 as
	> to the correct setting of NVC for this case (0 or 1?). It
should be noted
	> that this case may occur with a VCAT group with only a single
initial
	> member, and that the NVC may provide an indication that VCAT
encoding of
	> the H4 byte is in use for the connection.
=09
	A VCn-Xv group split into X components requires each of its
component to be signaled with the NVC value set to 1. This setting is
regardless of how the components are established.
=09
	> 3. Length of the Interface Switching Capability TLV
	>=20
	> Although the Interface Switching Capability TLV defined by
CCAMP for
	> SONET/SDH connections was not used for the testing, it was
noted that the
	> text describing the length of the Interface Switching
Capability TLV
	> defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may
be slightly
	> ambiguous due to the use of padding bytes.
	>=20
	> RFC 3630 states that "The TLV is padded to four-octet
alignment; padding
	> is not included in the length field (so a three octet value
would have a
	> length of three, but the total size of the TLV would be eight
octets)."
	=20
	Yes. Section 2.3.2 of RFC3630 gives a definitive statement of
the meaning of the length field and the use of padding, and provides an
example.
	=20
	> Reading of the encoding in
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
	> specifies that the length of the TLV for TDM is 41 bytes plus
3 bytes of
	> padding, and should be given in the length field as 41 bytes
rather than
	> 44. OIF requests verification of this interpretation from the
experts in
	> IETF CCAMP group.
	=20
	Note that the Interface Switching Capability Descriptor defined
in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the
Link TLV. Sub-TLVs and TLVs follow the same encoding rules.
	=20
	The ISCD TLV for TDM contains the following fields...
	  type       2 bytes
	  length     2 bytes
	  ---
	  switch cap 1 byte
	  encoding   1 byte
	  reserve    2 bytes
	  LSP b/w 0  4 bytes
	  LSP b/w 1  4 bytes=20
	  LSP b/w 2  4 bytes=20
	  LSP b/w 3  4 bytes=20
	  LSP b/w 4  4 bytes=20
	  LSP b/w 5  4 bytes=20
	  LSP b/w 6  4 bytes=20
	  LSP b/w 7  4 bytes
	  min b/w    4 bytes
	  indication 1 byte
	            =3D=3D
	            41 bytes
	=20
	We presume that your question relates to whether the 3-byte
field shown as "padding" in the TDM-specific figure on page 6 of
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an
explicit field.
	=20
	It is an implicit field, and should not be included in the
length of the TLV.
	=20
	Nevertheless, we take this opportunity to remind the OIF that
implementations of GMPLS protocols should be conservative in what they
send and liberal in what they receive. Thus, an implementation that
receives a TDM ISCD TLV with length 44 should not reject the TLV for
this reason. It should parse the TLV according to the defined fields and
skip the final three bytes. Thus, it should not affect a receiving
implementation if the sending implementation has treated the "padding"
field as implicit or explicit. In the event that a receiving
implementation rejected such a TLV on grounds of the value contained in
the length field being too large, the fault would lie with the receiving
implementation not the sending implementation.
	=20
	> 4. Use of ADMIN_STATUS in an initial PATH message
	>=20
	> Some implementations sent an ADMIN_STATUS object with no flags
set in the
	> initial PATH message, i.e., when no status change was being
requested.
	> Although this did not serve any particular function, it was
believed that
	> this could be accepted as RFC3473, sect. 7.2 (page 18) states:
	>=20
	> "The absence of the object is equivalent to receiving an
object containing
	> values all set to zero (0)."
	>=20
	> It was our interpretation based on this text that a node
should accept an
	> ADMIN_STATUS object with no flags set in the same way as if
the object was
	> missing. Comment on this interpretation is welcome.
	=20
	The effect of the meaning is as you state, but the intention of
the meaning is reversed. That is, an implementation should accept the
absence of the ADMIN_STATUS object in the same way as if the object was
present with no flags set. That is, the default behavior is to consider
the ADMIN_STATUS object as a standard part of the processing.
	=20
	We note from your first paragraph that you assume that the
ADMIN_STATUS object is used to change the status of the LSP. This is a
misinterpretation - it is used to control the status of the LSP. Thus,
if there is no change to the status of an LSP, refresh messages must
continue to carry the ADMIN_STATUS object with the same bit setting.
	=20
	In this way, it is not possible to "drop" the ADMIN_STATUS
object without having the same meaning as transmitting the object with
all bits cleared.
	=20
	> 5. Handling of multiple received ResvConf Request objects
	>=20
	> When a connection desires a confirmation that the service
(i.e.
	> connection) requested is in place, a RESV_CONF_REQ object is
included in
	> the RESV message. As this object is received by the remote end
of the
	> reservation, it will send a RESV_CONF message back to the
requester.
	>=20
	> However, it is unclear whether it is necessary to send a
RESV_CONF message
	> when the RSVP connection state is refreshed by subsequent
RESV. This
	> becomes potentially burdensome, especially when the
reservation is being
	> rapidly refreshed. Therefore we ask: should the remote end
send a
	> RESV_CONF message for subsequent RESV messages that still
include the
	> RESV_CONF_REQ object? Or is it required that the requestor of
the
	> reservation remove the RESV_CONF_REQ object to prevent the
generation of
	> further RESV_CONF messages? Comment on this issue from IETF
CCAMP is
	> requested.
	=20
	It is fundamental to the implementation of RSVP-TE that there is
a good understanding of the distinction between a trigger message and a
refresh message. This can be achieved by reading section 1.1 of RFC2961.
	=20
	Following this understanding, you will note that a refresh
message does not cause any processing to be performed at the LSR that
receives it (in this case the ingress). You will also note that refresh
processing is not end-to-end as implied in your text, but is hop-by-hop.
	=20
	Thus, an downstream LSR that wishes to trigger a new ResvConf
message must make a specific change to the content of the Resv message
that it sends in order to cause a trigger message to be propagated
through the network to the ingress LSR. Such processing is
implementation specific.

	> 6. Symmetry of Refresh Reduction usage
	>=20
	> During interop testing, we ran into a conflict caused by
varying
	> interpretations of RFC2961, regarding the use of SRefresh
messages and the
	> Refresh Reduction capabilities of the two ends of a given
link. One
	> interpretation of RFC2961 indicates that setting the Refresh
Reduction
	> Capability flag in the RSVP header indicates that that
interface shall be
	> capable of receiving messages related to Refresh Reduction -
including the
	> SRefresh message. This would be true even if the other end of
the link for
	> that interface were NOT indicating Refresh Reduction
Capability, since the
	> RFC makes no statement about symmetry in this matter.
	>=20
	> Another interpretation is that both ends of an interface must
indicate
	> Refresh Reduction Capability before either end can use such
messages, i.e,
	> use of Refresh Reduction on a link is symmetric.
	>=20
	> Comment from CCAMP WG on the correct interpretation is
requested.
	=20
	We are confused by your question.
	You correctly state that the use of the
refresh-reduction-capable bit indicates the ability of an LSR to support
the receipt of refresh reduction options and messages. To quote from
section 2 of RFC2961...
	           When set, indicates that this node is willing and
capable of
	           receiving all the messages and objects described in
this
	           document.  This includes the Bundle message described
in
	           Section 3, the MESSAGE_ID objects and Ack messages
described
	           in Section 4, and the MESSAGE_ID LIST objects and
Srefresh
	           message described in Section 5.  This bit is
meaningful only
	           between RSVP neighbors.
	This makes no statement about whether the LSR intends to use
these options when communicating with another LSR.=20
	=20
	However, you will note that some refresh reduction procedures
require that a message is sent and response returned. In order to make
use of the response, the receiver must be capable of receiving and
processing the response. Thus, it would be usual for an LSR that is
capable of sending refresh reduction options and messages to also set
the refresh-reduction-capable bit.
	=20
	In summary:
	- An LSR must not send refresh reduction options or messages=20
	  to an LSR that is not setting the refresh-reduction-capable=20
	  bit.
	- An LSR may send refresh reduction options or messages =20
	  to an LSR that is setting the refresh-reduction-capable bit.
	- An LSR that wishes to successfully use responded refresh=20
	  reduction options or messages should set the refresh-
	  reduction-capable bit.
	=20
	Note, finally, that section 2 of RFC 2961 states that "When it
is not known if a next hop supports the extension, standard Path and
Resv message based refreshes MUST be used."
=09
	> 7. Sending of ACKs bundled with the RSVP HELLO
	>=20
	> During interop testing, it was observed that Message Acks were
piggybacked
	> onto RSVP Hello messages, when the receiving end was not using
the Hello
	> protocol. In this situation, the incoming Hello's were
discarded and the
	> Acks were lost.
	>=20
	> We believe that Message Acks should only be piggybacked onto
mandatory
	> messages, and not on Hello messages because of this problem.
Comment on
	> this interpretation is requested.
	=20
	You use of the terms "bundled" and "piggybacked" are
contradictory.
	=20
	"Bundled" implies the use of the Bundle message.
	RFC 2961 states...
	   A sub-message MAY be any message type except for another=20
	   Bundle message.
	Thus, Ack messages may be bundled with other messages. (Although
one might consider this perverse since the Ack message is only
introduced to handle the case when the Ac/Nack objects have no other
message on which they can be carried.)
	=20
	Further, RFC 3209 states...
	   A Hello message may be included
	   as a sub-message within a bundle message.
	=20
	Therefore, it acceptable for a Ack and Hello messages to be
bundled together.
	The processing rules (RFC 29610 for Bundled messages are such
that each sub-message is processed in its own right, and the
non-support/non-use of Hello messages should not impact the processing
of other messages.
	=20
	On the other hand, "piggybacked" implies the use of the Ack/Nack
objects within a Hello message.
	=20
	Section 4.1 of RFC2961 states that Ack/Nack objects may be
included in the "standard" RSVP messages, and shows where they are
placed. However, RFC 3209 defines the Hello message as not including the
Ack/Nack objects...
	=20
	   <Hello Message> ::=3D <Common Header> [ <INTEGRITY> ]
	                              <HELLO>
	=20
	Since RFC 3209 post-dates RFC 2961, this definition is
definitive and the Ack/Nack objects should not be present on the Hello
message.
	=20
	Give that section 5.3 of RFC 3209 states...
	   The Hello Message is completely OPTIONAL.  All messages may
be
	   ignored by nodes which do not wish to participate in Hello
message
	   processing.
	...it is not particularly important what the message format
rules are. An implementation that chooses to place an Ack/Nack object in
a Hello message knows that the object might be discarded unprocessed.
	=20
	> 8. TSPEC format to be used for Ethernet connections
	=20
	The CCAMP working group is currently discussing the use of GMPLS
for control of Ethernet devices. We will respond to this point in a
separate email.

	Best regards,
	Adrian Farrel
	Kireeti Kompella


------_=_NextPart_001_01C5A430.48FA5368
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1515" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV>
<DIV><SPAN class=3D889413718-17082005><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN=20
class=3D215080620-18082005>Hi,</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D889413718-17082005><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN=20
class=3D215080620-18082005></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
>
<DIV><SPAN class=3D889413718-17082005><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN class=3D215080620-18082005></SPAN>Regarding the following =

points:</FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D889413718-17082005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D889413718-17082005><FONT face=3DArial color=3D#0000ff =

size=3D2>1.&nbsp;From the examples below, STS3c and VC4 have different =
RCC/NCC=20
values. Clarifications on which values should be used for&nbsp;SONET/SDH =

interworking would be useful.</FONT></SPAN><SPAN =
class=3D889413718-17082005><FONT=20
face=3DArial color=3D#0000ff size=3D2><BR></DIV></FONT></SPAN>
<DIV><SPAN class=3D889413718-17082005><FONT face=3DArial color=3D#0000ff =
size=3D2>5. Is=20
a change in the presence/absence of ResvConf considered a=20
trigger&nbsp;message?&nbsp; My interpretation of the text below is that =
a=20
refresh resv message containing a RESV_CONF object would not result in =
the=20
generation of a RESV_CONF message, RESV_CONF&nbsp;messages only being =
sent=20
on&nbsp;trigger resv message. Is that correct?</FONT></SPAN></DIV>
<DIV><SPAN class=3D889413718-17082005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D889413718-17082005></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D889413718-17082005><SPAN =
class=3D215080620-18082005><FONT=20
face=3DArial color=3D#0000ff =
size=3D2>Regards,</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D889413718-17082005><FONT face=3DArial color=3D#0000ff =
size=3D2><!-- Converted from text/rtf format -->
<P><SPAN lang=3Den-us><B><I><FONT color=3D#800080>Evelyne =
Roch</FONT></I></B></SPAN>=20
<BR><SPAN lang=3Den-us><FONT face=3D"Arial Narrow" =
color=3D#808080>Control Plane=20
Software</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3D"Arial =
Narrow"=20
color=3D#808080>Nortel Networks</FONT></SPAN> <BR><SPAN =
lang=3Den-us><FONT=20
face=3D"Arial Narrow" color=3D#808080>PO Box 3511 STN C Ottawa ON K1Y=20
4H7</FONT><FONT face=3DTahoma> </FONT></SPAN><BR><SPAN =
lang=3Den-us><FONT=20
face=3DWingdings color=3D#000000>(<FONT face=3D"Courier =
New"></FONT></FONT> <FONT=20
face=3D"Arial Narrow" color=3D#000000 size=3D1>Phone: [phone] =
(esn=20
393)</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3DWingdings =
color=3D#000000=20
size=3D2>,<FONT face=3D"Courier New"></FONT></FONT> <FONT face=3D"Arial =
Narrow"=20
color=3D#000000 size=3D1>e-mail</FONT> <FONT face=3DArial size=3D1>[<A=20
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT></SPA=
N>=20
</P></DIV></FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] <B>On =
Behalf Of=20
  </B>Adrian Farrel<BR><B>Sent:</B> Thursday, August 11, 2005 8:43=20
  AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Responding to =
the=20
  OIF<BR><BR></FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Hi,<BR><BR>As Lyndon noted in =
Paris, the OIF=20
  has sent us a communication requesting some guidance on a bunch of=20
  questions.<BR><BR>This is to start the business of constructing a =
reply.=20
  thanks to Dimitri for supplying some of this text.<BR><BR>Please send =
comments=20
  and improvements.<BR><BR>Adrian<BR><BR>=3D=3D=3D=3D=3D=3D<BR><BR>To: =
Jim Jones, OIF=20
  Technical Committee Chair<BR>From: Adrian Farrel and Kireeti Kompella, =

  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WG =
Co-Chairs for=20
  IETF CCAMP<BR>Copy: Alex Zinin and Bill Fenner, IETF Routing Area=20
  Directors<BR>Subject: Response to your questions about GMPLS=20
  parameters.<BR><BR>Dear Jim,<BR><BR>Thanks for your correspondence =
about the=20
  questions with respect to GMPLS parameters that arose before and =
during your=20
  interoperability testing. CCAMP is pleased to receive such questions =
and is=20
  glad to have the opportunity to explain the intended operation of the =
GMPLS=20
  protocols.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Much of the material supplied below =
can be=20
  simply extracted from the relevant RFCs.</DIV>
  <DIV><BR><BR>&gt; 1. Use of the NCC and RCC fields for STS-3c/VC-4=20
  connections<BR>&gt; <BR>&gt; During OIF testing it was noted that some =

  ambiguity exists in the<BR>&gt; specification of encoding of NCC, RCC =
and NVC=20
  for certain types of<BR>&gt; connections: NCC and RCC for an =
STS-3c/VC-4=20
  connection can be set to 0 or<BR>&gt; to 1 depending on which example =
of RFC=20
  3946 is followed.<BR>&gt; <BR>&gt; Clarification is requested from =
IETF CCAMP=20
  as to which setting is<BR>&gt; considered correct, or if both settings =
should=20
  be accepted (this procedure<BR>&gt; was used during testing at=20
  Supercomm).<BR><BR>This question about RFC 3946 was raised informally =
on the=20
  CCAMP mailing list at the start of March this year. <BR><BR>Even when =
the=20
  signal Type value is the same (i.e. value 6) the NCC, RCC and NVC =
values=20
  depend on the specific signal being requested.<BR><BR>From the =
examples in the=20
  annex we have...<BR><BR>&nbsp;&nbsp; A VC-4 signal is formed by =
applying the=20
  following<BR>&nbsp;&nbsp; settings to a VC-4 Elementary=20
  Signal.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RCC =3D=20
  0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NCC =3D =
0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  NVC =3D 0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MT&nbsp; =3D=20
  1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T&nbsp;&nbsp; =3D =
0<BR><BR>&nbsp;&nbsp; An=20
  STS-3c SPE signal is formed by applying the following<BR>&nbsp;&nbsp; =
settings=20
  to an STS-3c SPE Elementary Signal.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RCC =3D 1=20
  (standard contiguous concatenation)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
NCC =3D=20
  1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NVC =3D =
0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  MT&nbsp; =3D 1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T&nbsp;&nbsp; =3D =
0<BR><BR>Your=20
  question probably arises from the two notes and subsequent paragraph =
in=20
  section 2.1 or RFC 3946. Here it says...<BR><BR>&nbsp;&nbsp; Note 1: =
when=20
  requesting a SONET STS-Nc SPE with N=3D3*X,=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Elementary Signal to use must =
always be=20
  an STS-3c_SPE signal type<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and the =
value of=20
  NCC must always be equal to X.&nbsp; This allows=20
  also<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; facilitating the interworking =
between=20
  SONET and SDH.&nbsp; In<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; particular, =
it means=20
  that the contiguous concatenation of =
three<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  STS-1 SPEs can not be requested because according to=20
  this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specification, this type of =
signal must=20
  be coded using the STS-3c<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SPE signal =

  type.<BR><BR>&nbsp;&nbsp; Note 2: when requesting a transparent =
STS-N/STM-N=20
  signal<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; limited to a single =
contiguously=20
  concatenated STS-Nc_SPE/VC-4-Nc,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
signal=20
  type must be STS-N/STM-N, RCC with flag 1 and NCC=20
  set<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to 1.<BR><BR>&nbsp;&nbsp; The =
NCC value=20
  must be consistent with the type of contiguous<BR>&nbsp;&nbsp; =
concatenation=20
  being requested in the RCC field.&nbsp; In particular, =
this<BR>&nbsp;&nbsp;=20
  field is irrelevant if no contiguous concatenation is requested=20
  (RCC<BR>&nbsp;&nbsp; =3D 0), in that case it must be set to zero when =
sent, and=20
  should be<BR>&nbsp;&nbsp; ignored when received.&nbsp; A RCC value =
different=20
  from 0 must imply a<BR>&nbsp;&nbsp; number of contiguous components =
greater=20
  than 1.<BR><BR>We believe that this final sentence should read =
"greater than=20
  or equal to 1," and that this interpretation resolves all of your =
issues and=20
  makes the text consistent with the examples.<BR><BR>&gt; 2. Setting of =
NVC for=20
  VCAT connections<BR>&gt; <BR>&gt; It was also noted that the setting =
of NVC=20
  may be somewhat ambiguous for<BR>&gt; the case where diverse =
connections are=20
  used within a single VCAT group.<BR>&gt; Each individual RSVP session =
controls=20
  a single connection, but the<BR>&gt; connection is part of a larger =
VCAT group=20
  and carries VCAT encoding of the<BR>&gt; H4 byte. Clarification is =
requested=20
  from IETF CCAMP and ITU-T Q.14/15 as<BR>&gt; to the correct setting of =
NVC for=20
  this case (0 or 1?). It should be noted<BR>&gt; that this case may =
occur with=20
  a VCAT group with only a single initial<BR>&gt; member, and that the =
NVC may=20
  provide an indication that VCAT encoding of<BR>&gt; the H4 byte is in =
use for=20
  the connection.<BR><BR>A VCn-Xv group split into X components requires =
each of=20
  its component to be signaled with the NVC value set to 1. This setting =
is=20
  regardless of how the components are established.<BR><BR>&gt; 3. =
Length of the=20
  Interface Switching Capability TLV<BR>&gt; <BR>&gt; Although the =
Interface=20
  Switching Capability TLV defined by CCAMP for<BR>&gt; SONET/SDH =
connections=20
  was not used for the testing, it was noted that the<BR>&gt; text =
describing=20
  the length of the Interface Switching Capability TLV<BR>&gt; defined =
in=20
  draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly<BR>&gt;=20
  ambiguous due to the use of padding bytes.<BR>&gt; <BR>&gt; RFC 3630 =
states=20
  that "The TLV is padded to four-octet alignment; padding<BR>&gt; is =
not=20
  included in the length field (so a three octet value would have =
a<BR>&gt;=20
  length of three, but the total size of the TLV would be eight=20
  octets)."</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Yes. Section 2.3.2 of RFC3630 gives =
a=20
  definitive statement of the meaning of the length field and the use of =

  padding, and provides an example.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV>
  <DIV>&gt; Reading of the encoding in=20
  draft-ietf-ccamp-ospf-gmpls-extensions-12.txt<BR>&gt; specifies that =
the=20
  length of the TLV for TDM is 41 bytes plus 3 bytes of<BR>&gt; padding, =
and=20
  should be given in the length field as 41 bytes rather than<BR>&gt; =
44. OIF=20
  requests verification of this interpretation from the experts =
in<BR>&gt; IETF=20
  CCAMP group.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Note that the Interface Switching Capability Descriptor defined =
in=20
  draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link =
TLV.=20
  Sub-TLVs and TLVs follow the same encoding rules.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>The ISCD TLV for TDM contains the following fields...</DIV>
  <DIV>&nbsp; type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2 bytes</DIV>
  <DIV>&nbsp; length&nbsp;&nbsp;&nbsp;&nbsp; 2 bytes</DIV>
  <DIV>&nbsp;&nbsp;---</DIV>
  <DIV>&nbsp;&nbsp;switch cap 1 byte</DIV>
  <DIV>&nbsp;&nbsp;encoding&nbsp;&nbsp;&nbsp;1 byte</DIV>
  <DIV>&nbsp; reserve&nbsp;&nbsp;&nbsp; 2 bytes</DIV>
  <DIV>&nbsp;&nbsp;LSP b/w 0&nbsp; 4 bytes</DIV>
  <DIV>
  <DIV>&nbsp;&nbsp;LSP b/w 1&nbsp; 4 bytes=20
  <DIV>&nbsp;&nbsp;LSP b/w 2&nbsp; 4 bytes=20
  <DIV>&nbsp;&nbsp;LSP b/w 3&nbsp; 4 bytes=20
  <DIV>&nbsp;&nbsp;LSP b/w 4&nbsp; 4 bytes=20
  <DIV>&nbsp;&nbsp;LSP b/w 5&nbsp; 4 bytes=20
  <DIV>&nbsp;&nbsp;LSP b/w 6&nbsp; 4 bytes=20
  <DIV>&nbsp;&nbsp;LSP b/w 7&nbsp; 4=20
  bytes</DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV>
  <DIV>&nbsp;&nbsp;min&nbsp;b/w&nbsp;&nbsp;&nbsp;&nbsp;4 bytes</DIV>
  <DIV>&nbsp;&nbsp;indication&nbsp;1=20
  =
byte<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=3D=3D</DIV>
  =
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;41=20
  bytes</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>We presume that your question relates to whether the 3-byte field =
shown=20
  as "padding" in the TDM-specific figure on page 6 of=20
  draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an =
explicit=20
  field.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>It is an implicit field, and should not be included in the length =
of the=20
  TLV.</DIV></FONT>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Nevertheless, we take this =
opportunity to=20
  remind the OIF that implementations of GMPLS protocols should be =
conservative=20
  in what they send and liberal in what they receive. Thus, an =
implementation=20
  that receives a TDM ISCD TLV with length 44 should not reject the TLV =
for this=20
  reason. It should parse the TLV according to the defined fields and =
skip the=20
  final three bytes. Thus, it should not affect a receiving =
implementation if=20
  the sending implementation has treated the "padding" field as implicit =
or=20
  explicit. In the event that a receiving implementation rejected such a =
TLV on=20
  grounds of the value contained in the length field being too large, =
the fault=20
  would lie with the receiving implementation not the sending=20
  implementation.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; 4. Use of ADMIN_STATUS in an =
initial PATH=20
  message<BR>&gt; <BR>&gt; Some implementations sent an ADMIN_STATUS =
object with=20
  no flags set in the<BR>&gt; initial PATH message, i.e., when no status =
change=20
  was being requested.<BR>&gt; Although this did not serve any =
particular=20
  function, it was believed that<BR>&gt; this could be accepted as =
RFC3473,=20
  sect. 7.2 (page 18) states:<BR>&gt; <BR>&gt; "The absence of the =
object is=20
  equivalent to receiving an object containing<BR>&gt; values all set to =
zero=20
  (0)."<BR>&gt; <BR>&gt; It was our interpretation based on this text =
that a=20
  node should accept an<BR>&gt; ADMIN_STATUS object with no flags set in =
the=20
  same way as if the object was<BR>&gt; missing. Comment on this =
interpretation=20
  is welcome.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>The effect of the meaning is as you =
state, but=20
  the intention of the meaning is reversed. That is, an implementation =
should=20
  accept the absence of the ADMIN_STATUS object in the same way as if =
the object=20
  was present with no flags set. That is, the default behavior is to =
consider=20
  the ADMIN_STATUS object as a standard part of the =
processing.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>We note from your first paragraph =
that you=20
  assume that the ADMIN_STATUS object is used to change the status of =
the LSP.=20
  This is a misinterpretation - it is used to control the status of the =
LSP.=20
  Thus, if there is no change to the status of an LSP, refresh messages =
must=20
  continue to carry the ADMIN_STATUS object with the same bit=20
  setting.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>In this way, it is not possible to =
"drop" the=20
  ADMIN_STATUS object without having the same meaning as transmitting =
the object=20
  with all bits cleared.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; 5. Handling of multiple =
received ResvConf=20
  Request objects<BR>&gt; <BR>&gt; When a connection desires a =
confirmation that=20
  the service (i.e.<BR>&gt; connection) requested is in place, a =
RESV_CONF_REQ=20
  object is included in<BR>&gt; the RESV message. As this object is =
received by=20
  the remote end of the<BR>&gt; reservation, it will send a RESV_CONF =
message=20
  back to the requester.<BR>&gt; <BR>&gt; However, it is unclear whether =
it is=20
  necessary to send a RESV_CONF message<BR>&gt; when the RSVP connection =
state=20
  is refreshed by subsequent RESV. This<BR>&gt; becomes potentially =
burdensome,=20
  especially when the reservation is being<BR>&gt; rapidly refreshed. =
Therefore=20
  we ask: should the remote end send a<BR>&gt; RESV_CONF message for =
subsequent=20
  RESV messages that still include the<BR>&gt; RESV_CONF_REQ object? Or =
is it=20
  required that the requestor of the<BR>&gt; reservation remove the=20
  RESV_CONF_REQ object to prevent the generation of<BR>&gt; further =
RESV_CONF=20
  messages? Comment on this issue from IETF CCAMP is<BR>&gt;=20
  requested.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>It is fundamental to =
the&nbsp;implementation of=20
  RSVP-TE that there is a good understanding of the distinction between =
a=20
  trigger message and a refresh message. This can be achieved by reading =
section=20
  1.1 of RFC2961.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Following this understanding, you =
will note=20
  that a refresh message does not cause any processing to be performed =
at the=20
  LSR that receives it (in this case the ingress). You will also note =
that=20
  refresh processing is not end-to-end as implied in your text, but is=20
  hop-by-hop.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Thus, an downstream LSR that wishes =
to trigger=20
  a new ResvConf message must make a specific change to the content of =
the Resv=20
  message that it sends in order to cause a trigger message to be =
propagated=20
  through the network to the ingress LSR. Such processing is =
implementation=20
  specific.</DIV>
  <DIV><BR>&gt; 6. Symmetry of Refresh Reduction usage<BR>&gt; <BR>&gt; =
During=20
  interop testing, we ran into a conflict caused by varying<BR>&gt;=20
  interpretations of RFC2961, regarding the use of SRefresh messages and =

  the<BR>&gt; Refresh Reduction capabilities of the two ends of a given =
link.=20
  One<BR>&gt; interpretation of RFC2961 indicates that setting the =
Refresh=20
  Reduction<BR>&gt; Capability flag in the RSVP header indicates that =
that=20
  interface shall be<BR>&gt; capable of receiving messages related to =
Refresh=20
  Reduction - including the<BR>&gt; SRefresh message. This would be true =
even if=20
  the other end of the link for<BR>&gt; that interface were NOT =
indicating=20
  Refresh Reduction Capability, since the<BR>&gt; RFC makes no statement =
about=20
  symmetry in this matter.<BR>&gt; <BR>&gt; Another interpretation is =
that both=20
  ends of an interface must indicate<BR>&gt; Refresh Reduction =
Capability before=20
  either end can use such messages, i.e,<BR>&gt; use of Refresh =
Reduction on a=20
  link is symmetric.<BR>&gt; <BR>&gt; Comment from CCAMP WG on the =
correct=20
  interpretation is requested.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>We are confused by your question.</DIV>
  <DIV>You correctly state that the use of the refresh-reduction-capable =
bit=20
  indicates the ability of an LSR to support the receipt of refresh =
reduction=20
  options and messages. To quote from section 2 of RFC2961...</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When =
set,=20
  indicates that this node is willing and capable=20
  of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
receiving=20
  all the messages and objects described in=20
  this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  document.&nbsp; This includes the Bundle message described=20
  in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Section 3,=20
  the MESSAGE_ID objects and Ack messages=20
  =
described<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 in=20
  Section 4, and the MESSAGE_ID LIST objects and=20
  =
Srefresh<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  message described in Section 5.&nbsp; This bit is meaningful=20
  only<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
between=20
  RSVP neighbors.<BR>This makes no statement about whether the LSR =
intends to=20
  use these options when communicating with another LSR. </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>However, you will note that some refresh reduction procedures =
require=20
  that a message is sent and response returned. In order to make use of =
the=20
  response, the receiver must be capable of receiving and processing the =

  response. Thus, it would be usual for an LSR that is capable of =
sending=20
  refresh reduction options and messages to also set the=20
  refresh-reduction-capable bit.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>In summary:</DIV>
  <DIV>- An LSR must not&nbsp;send refresh reduction options or=20
  messages&nbsp;</DIV>
  <DIV>&nbsp; to an LSR that is not setting the =
refresh-reduction-capable </DIV>
  <DIV>&nbsp; bit.</DIV>
  <DIV>- An LSR may send refresh reduction options or messages&nbsp;=20
  <DIV>&nbsp; to an LSR that is&nbsp;setting the =
refresh-reduction-capable=20
  bit.</DIV>
  <DIV>- An LSR that wishes to successfully use responded refresh </DIV>
  <DIV>&nbsp; reduction options&nbsp;or messages should set the =
refresh-</DIV>
  <DIV>&nbsp; reduction-capable bit.</DIV></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Note, finally, that section 2 of RFC 2961&nbsp;states that "When =
it is=20
  not known if a next hop supports the extension, standard Path and Resv =
message=20
  based refreshes MUST be used."<BR></DIV>
  <DIV>&gt; 7. Sending of ACKs bundled with the RSVP HELLO<BR>&gt; =
<BR>&gt;=20
  During interop testing, it was observed that Message Acks were=20
  piggybacked<BR>&gt; onto RSVP Hello messages, when the receiving end =
was not=20
  using the Hello<BR>&gt; protocol. In this situation, the incoming =
Hello's were=20
  discarded and the<BR>&gt; Acks were lost.<BR>&gt; <BR>&gt; We believe =
that=20
  Message Acks should only be piggybacked onto mandatory<BR>&gt; =
messages, and=20
  not on Hello messages because of this problem. Comment on<BR>&gt; this =

  interpretation is requested.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>You use of the terms "bundled" and "piggybacked" are =
contradictory.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>"Bundled" implies the use of the Bundle message.</DIV>
  <DIV>RFC 2961 states...</DIV>
  <DIV>&nbsp;&nbsp; A&nbsp;sub-message MAY be any message type except =
for=20
  another </DIV>
  <DIV>&nbsp;&nbsp; Bundle&nbsp;message.</DIV>
  <DIV>Thus, Ack messages may be bundled with other messages. (Although =
one=20
  might consider this perverse since the Ack message is only introduced =
to=20
  handle the case when the Ac/Nack objects have no other message on =
which they=20
  can be carried.)</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Further, RFC 3209 states...</DIV>
  <DIV>&nbsp;&nbsp; A Hello message may be included<BR>&nbsp;&nbsp; as a =

  sub-message within a bundle message.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Therefore, it acceptable for a Ack and Hello messages to be =
bundled=20
  together.</DIV>
  <DIV>The processing rules (RFC 29610 for Bundled messages are such =
that each=20
  sub-message is processed in its own right, and the non-support/non-use =
of=20
  Hello messages should not impact the processing of other =
messages.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>On the other hand, "piggybacked" implies the use of the Ack/Nack =
objects=20
  within a Hello message.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Section 4.1 of RFC2961 states that Ack/Nack objects may be =
included in=20
  the "standard" RSVP messages, and shows where they are placed. =
However, RFC=20
  3209 defines the Hello message as not including the Ack/Nack =
objects...</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;&nbsp; &lt;Hello Message&gt; ::=3D &lt;Common Header&gt; [=20
  &lt;INTEGRITY&gt;=20
  =
]<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &lt;HELLO&gt;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Since RFC 3209 post-dates RFC 2961, this definition is definitive =
and the=20
  Ack/Nack objects should not be present on the Hello message.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Give that section 5.3 of RFC 3209 states...</DIV>
  <DIV>&nbsp;&nbsp; The Hello Message is completely OPTIONAL.&nbsp; All =
messages=20
  may be<BR>&nbsp;&nbsp; ignored by nodes which do not wish to =
participate in=20
  Hello message<BR>&nbsp;&nbsp; processing.</DIV>
  <DIV>...it is not particularly important what the message format rules =
are. An=20
  implementation that chooses to place an Ack/Nack object in a Hello =
message=20
  knows that the object might be discarded unprocessed.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&gt; 8. TSPEC format to be used for Ethernet connections</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>The CCAMP working group is currently discussing the use of GMPLS =
for=20
  control of Ethernet devices. We will respond to this point in a =
separate=20
  email.</DIV>
  <DIV><BR>Best regards,</DIV>
  <DIV>Adrian Farrel</DIV>
  <DIV>Kireeti Kompella</FONT></DIV></BLOCKQUOTE></BODY></HTML>
=00
------_=_NextPart_001_01C5A430.48FA5368--



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2005 13:44:46 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Requesting a LSC LSP across a PCS interface 
Date: Thu, 18 Aug 2005 15:42:31 +0200
Message-ID: <[e-mail]>
Thread-Topic: Requesting a LSC LSP across a PCS interface 
Thread-Index: AcWj+q668kf02/19QsCNVkffgXoI2g==
From: <[e-mail]>
To: <[e-mail]>

Hi all,

Consider the following situation:

       Domain A <=3D | =3D>         Domain B         <=3D | =3D> Domain =
C
                   |                                |
 [A1]--PSC--[A2]--PSC--[B1]--LSC--[B2]--LSC--[B4]--PSC--[C1]
                   |     |                    |     |
                         |---PSC--[B3]--PSC---|


Suppose I want to setup an (PSC) LSP from [A1] to [C1]. In domain B
there are two options, the PSC route, or the LSC route. Is there a way
to request (or hint for) a LSC LSP in domain B for the A1-C1 LSP? For
example because the quality of the PSC path is deemed insufficient from
the point of view of domains A and C (e.g. A and C are vey high bw LAN
enviroments, B a WAN environment).

Thanks!

cheers,
	Eduard




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2005 11:23:28 +0000
Message-ID: <048301c5a3e7$74538290$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Wataru Imajuku" <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Date: Thu, 18 Aug 2005 10:42:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

Hi Wataru,

>   I believe that my draft includes some issues which have not addressed
in
>   bernsteins draft.
>   For example, the issue of section 5 in my draft.
>   This is important issue when LCAS&VCAT will be applied in MRN.
>
>   I understand your proposal is my requirement draft
>     draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt
>   will be merged with draft-bernstein-ccamp-....
>   or simply discard ?

As I said in my original email...
>>- Why isn't my I-D also cited as input material?
>>   No insult intended. The current list is simply there to
>>   show the ADs that work is already in progress. All I-Ds
>>   will be used as input.

Nothing of value will be thrown away.
All input to working group drafts is welcome whether it is supplied as
comments on the email list or as a separate I-D.

With regard to your section 5, I note that you consider the VCAT group
analogous with a link bundle. I don't think this is correct because the
members of a link bundle must be selected and used individually. A payload
data stream cannot be distributed across multiple component links of the
bundle...
   An LSP with a bandwidth requirement b and
   setup priority p fits in a bundled link if at least one component
   link has maximum LSP bandwidth >= b at priority p.
However, the whole point of a VCAT group is to produce a single entity
(pipe) with maximum LSP bandwidth greater than the capacity of any
individual component. A VCAT group, therefore, is not a bundle.

Following on from this, I think that the remainder of your section 5.1
will have some value, but needs to be corrected to properly reflect the
meaning of a VCAT group.

In general, I think your section 5 should generalize from the specific
case of the FA to include any TE link that is based on a VCAT group.

Section 5.2 seems to confuse "FA" with "FA LSP".

Regards,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2005 10:17:33 +0000
Message-ID: <[e-mail]>
Date: Thu, 18 Aug 2005 12:16:51 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Diego Caviglia <[e-mail]>
CC:  [e-mail],  " <richard.spencer" <[e-mail]>, "adrian <adrian" <[e-mail]>,  "ccamp <ccamp" <[e-mail]>
Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

diego

>>given the high number of MS-SPRing protected transport network
>>already deployed seems reasonable to me, from a Network Operator point of
>>view, to use at the same time MS-SPRing protection with GMPLS
>>restoration.
> 
> there are already two questions here 1. is there an operational need to
> control such rings using GMPLS (? for instance is it effective knowing
> that ring based protection is mainly data plane driven ?)
> [dc] I prefer to hear something from the Operator here even if my
> experience tell me that the answer is yes.

i don't have the full answer either - the question is to address such 
considerations and tradeoffs

> and 2. how to position the ring protection wrt to the LSP recovery
> segment/end-to-end
> recovery
> [dc] I'm sure I've got the point here sorry, what exatly do you mean with
> position?

some examples (not exhaustive):

will it be seen as link protection for some links used by the end-to-end 
LSP or LSP segment protection of end-to-end LSP or both ?

otoh would it be possible to assume SDH ring protection on top of nodes 
interconnected by recoverable Lambdas ?

>>Let's say the first failure is recovered via MS-SPRing in less than 50 ms
>>while subsequent failures can be recovered via GMPLS restoration with
>>lower performance.
>  
> is it because it is a "local" protection (i.e. wouldn't a segment
> recovery provide the same time efficiency) or because it is ring based
> [dc] It is because is performed at the SDH layer, all the SDH protection
> scheme I know have the same performance (e.g. SNCP, MSP)

so it is the former i.e. "local-(data-plane driven) protection"

by the way if you plan to start such document a terminology section 
inserted w/i an informative appendix would help the IETF reader

>>Basically that is the rationale behind my initial question.
>>
>>What is your view on that?
> 
> my view is that a problem statement should cover such base questions - i
> am in agreement with adrian stand here -
> [dc] I'm trying to put togheter a requirement doc that briefly illustrates
> how MS-SPRing works and what are the information that it needs in order to
> work corretly.

i don't think there is a need to step into the details of "how it works" 
in the first phase (an 1-page summary would be enough here, at the end 
good references are available) but "why/where it makes sense" and "what 
does it imply" the above discussion is a sample of  considerations that 
such document should address as i wouldn't step in without having an 
overall picture of the landscape

>>Regards
>>
>>Diego
>>
>>
>>
>>dimitri papadimitriou <[e-mail]> on 17/08/2005 14.43.17
>>
>>Please respond to [e-mail]; Please respond to
>>       [e-mail]
>>
>>To:    [e-mail]
>>cc:    [e-mail], [e-mail],
>>       [e-mail], [e-mail]
>>
>>Subject:    Re: MS-SPring [Was: Moving forward with the CCAMP charter]
>>
>>
>>
>>richard,
>>
>>
>>
>>>Dimitri,
>>>
>>>"why (and where) ring topologies are suitable" ?
>>>
>>>Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will
>>>continue to be, widely deployed based on (dual) ring topologies in
>>>the access/metro because they provide fast protection and reliability
>>>whilst making efficient use of fibre.
>>>
>>>I do not think this can be disputed so I don't understand where you
>>>are coming from with this question?
>>
>>
>>while i do not see why this can't be discussed (e.g. there are dozens of
>>studies available on this topic) and i can just point out that one can
>>deliver fast (time efficient), resource efficient and reliable
>>protection without using rings
>>
>>therefore, it would worth having some operational feedback and state
>>what are the real drivers and rationales if such topic is getting
>>started i.e. what is the real appealing rationale behind this mechanism
>>
>>note: these are just questions that i think where missing from most
>>documents produced on this topic since so far and that are important to
>>be addressed
>>
>>last point you are mentioning RPR so what would be the interaction with
>>the IPORPR WG ?
>>
>>
>>
>>>Regards, Richard
>>>
>>>
>>>
>>>
>>>.
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>.
>>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2005 09:28:24 +0000
Sensitivity: 
Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter]
To: [e-mail], [e-mail]
Cc: "dimitri.papadimitriou" <[e-mail]>, "\"\"richard.spencer\" <richard.spencer\"" <[e-mail]>, "adrian <adrian" <[e-mail]>, "ccamp <ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Thu, 18 Aug 2005 11:26:58 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Dimitri,
         in line.

Regards

Diego



dimitri papadimitriou <[e-mail]> on 17/08/2005 17.01.23

Please respond to [e-mail]; Please respond to
       [e-mail]

To:    Diego Caviglia <[e-mail]>
cc:    [e-mail], "richard.spencer"
       <[e-mail]>, adrian <[e-mail]>, ccamp
       <[e-mail]>

Subject:    Re: MS-SPring [Was: Moving forward with the CCAMP charter]

diego

Diego Caviglia wrote:
> Hi Dimitri,
>             given the high number of MS-SPRing protected transport
network
> already deployed seems reasonable to me, from a Network Operator point of
> view, to use at the same time MS-SPRing protection with GMPLS
restoration.

there are already two questions here 1. is there an operational need to
control such rings using GMPLS (? for instance is it effective knowing
that ring based protection is mainly data plane driven ?)
[dc] I prefer to hear something from the Operator here even if my
experience tell me that the answer is yes.

and 2. how to position the ring protection wrt to the LSP recovery
segment/end-to-end
recovery
[dc] I'm sure I've got the point here sorry, what exatly do you mean with
position?

> Let's say the first failure is recovered via MS-SPRing in less than 50 ms
> while subsequent failures can be recovered via GMPLS restoration with
lower
> performance.

is it because it is a "local" protection (i.e. wouldn't a segment
recovery provide the same time efficiency) or because it is ring based
[dc] It is because is performed at the SDH layer, all the SDH protection
scheme I know have the same
performance (e.g. SNCP, MSP)

> Basically that is the rationale behind my initial question.
>
> What is your view on that?

my view is that a problem statement should cover such base questions - i
am in agreement with adrian stand here -
[dc] I'm trying to put togheter a requirement doc that briefly illustrates
how MS-SPRing works and what are the information that it needs in order to
work corretly.

> Regards
>
> Diego
>
>
>
> dimitri papadimitriou <[e-mail]> on 17/08/2005 14.43.17
>
> Please respond to [e-mail]; Please respond to
>        [e-mail]
>
> To:    [e-mail]
> cc:    [e-mail], [e-mail],
>        [e-mail], [e-mail]
>
> Subject:    Re: MS-SPring [Was: Moving forward with the CCAMP charter]
>
>
>
> richard,
>
>
>>Dimitri,
>>
>>"why (and where) ring topologies are suitable" ?
>>
>>Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will
>>continue to be, widely deployed based on (dual) ring topologies in
>>the access/metro because they provide fast protection and reliability
>>whilst making efficient use of fibre.
>>
>>I do not think this can be disputed so I don't understand where you
>>are coming from with this question?
>
>
> while i do not see why this can't be discussed (e.g. there are dozens of
> studies available on this topic) and i can just point out that one can
> deliver fast (time efficient), resource efficient and reliable
> protection without using rings
>
> therefore, it would worth having some operational feedback and state
> what are the real drivers and rationales if such topic is getting
> started i.e. what is the real appealing rationale behind this mechanism
>
> note: these are just questions that i think where missing from most
> documents produced on this topic since so far and that are important to
> be addressed
>
> last point you are mentioning RPR so what would be the interaction with
> the IPORPR WG ?
>
>
>>Regards, Richard
>>
>>
>>
>>
>>.
>>
>
>
>
>
>
>
>
>
>
>
>
> .
>











Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2005 01:22:35 +0000
Message-Id: <[e-mail]>
Date: Thu, 18 Aug 2005 10:20:13 +0900
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Cc: <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Adrian

  Thank you for sending milestones.

  I noticed that the issue of coordination with lcas & vcat
will be based on
  draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt

  I understand that LCAS/VCAT control draft will be done in single draft
which have statements all of requirements, analysis, and solution.

  I believe that my draft includes some issues which have not addressed in
bernsteins draft.
  For example, the issue of section 5 in my draft.
  This is important issue when LCAS&VCAT will be applied in MRN.

  I understand your proposal is my requirement draft
    draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt
  will be merged with draft-bernstein-ccamp-....

  or simply discard ?

Best Regards,
Wataru

>Hi,
>
>Please find attached a file that contains:
>
>- a set of proposed *draft* milestones
>- a discussion of why there are so many milestones
>- a high-level explanation of the work items.
>
>Note that this looks like a lot of milestones, but please read the text on 
>this issue in the attached file. The bottom line is that this is a product 
>of micro management where I have tried to identify all of the I-Ds that we 
>might produce to cover the referenced work, and where I have placed two 
>(sometimes three) milestones for each I-D.
>
>This micro-management may be over the top, and represents a full pendulum 
>swing from the previous style of CCAMP milestones, but in the light of the 
>hiatus of the last 12 months, i think this may be beneficial and might 
>achieve rapid forwards movement.
>
>I would welcome your (constructive!) comments.
>
>Notes:
>- Why isn't my I-D also cited as input material?
>   No insult intended. The current list is simply there to
>   show the ADs that work is already in progress. All I-Ds
>   will be used as input.
>- Why isn't my pet topic included?
>   Are you sure it is not there between the lines? This
>   list of milestones isn't completely proscriptive.
>
>The objective is to have the WG agreed on the milestones that it wants to 
>commit to by the end of August.
>
>Thanks,
>Adrian

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone] 




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 20:02:01 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Aug 2005 13:00:29 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Diego Caviglia <[e-mail]>
CC: Adrian Farrel <[e-mail]>, "<ccamp" <[e-mail]>
Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Diego, there is interest on my part on working with other protection 
schemes.  In general I'm interested in the inter-operation and optimal 
selection of protection/restoration schemes at different layers. I'm 
busy this week but next week I expect to also get back to the VCAT draft 
and review the various notes and such from the other SDOs.

Greg B.

Diego Caviglia wrote:

>Adrian,
>        actually I have a draft on this matter under my pillow ;-)) it is
>quite rought but can be interestion to start the discussion.
>
>I'll post it ASAP, anyway it there any interest from the community on this
>subject?
>
>Regards
>
>Diego
>
>
>
>"Adrian Farrel" <[e-mail]> on 17/08/2005 11.44.03
>
>Please respond to "Adrian Farrel" <[e-mail]>
>
>To:    <[e-mail]>, "Diego Caviglia" <[e-mail]>
>cc:
>
>Subject:    MS-SPring [Was: Moving forward with the CCAMP charter]
>
>Hi Diego,
>
>I can well believe that this is something that should/could be of interest
>to CCAMP.
>
>It would be premature, however, to put explicit milestones on our charter
>without first seeing some work on the subject and support from the
>community.
>
>At the very least we would need to scope the problem and understand
>whether there is any work to be done. If anyone wants to write a draft on
>this so that we can all understand the problem space, I am sure it would
>be welcomed.
>
>Cheers,
>Adrian
>----- Original Message -----
>From: "Diego Caviglia" <[e-mail]>
>To: <[e-mail]>
>Sent: Wednesday, August 17, 2005 8:13 AM
>Subject: Re: Moving forward with the CCAMP charter
>
>
>  
>
>>Hi Adrian and all,
>>                  I've a question about GMPLS interworking with inherent
>>protection scheme.
>>
>>With inherent protection scheme I mean e.g. MS-SPRing in transport
>>    
>>
>network.
>  
>
>>MS-SPring is widely deployed and IMHO interworking between that
>>    
>>
>protection
>  
>
>>scheme and GMPLS should be foreseen.
>>Unfortunately there are some constraints to be satisfied (timeslot
>>interchange and squelching table) when an LSP is created on a MS-SPRing.
>>
>>And now the question is this kind of interworking something that should
>>    
>>
>be
>  
>
>>covered in CCAMP (I know that there are some Study Point in ITU-T to
>>    
>>
>cover
>  
>
>>this issues)?
>>
>>IMHO I think the answer is yes but I like to know the feeling of the
>>    
>>
>other
>  
>
>>guys here.
>>
>>Regards
>>
>>Diego
>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>
>
>
>
>
>
>
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 17:16:28 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A34E.EC43544D"
Subject: RE: Responding to the OIF
Date: Wed, 17 Aug 2005 12:11:05 -0500
Message-ID: <[e-mail]>
Thread-Topic: Responding to the OIF
Thread-Index: AcWecho8wbE0LxlVRcuVSb1RRGwsbgE2T2sg
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5A34E.EC43544D
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

Hi,
 
Regarding the first item, we should have only one TSPEC encoding for
STS-3c SPE/VC-4 since the intent is to unify signaling for SONET and
SDH. 
 
Furthermore, contiguous concatenation with one element doesn't make
sense.
 
Thus we should change example 8 to match example 1 (in the same way that
example 9 matches example 3) and leave the text that indicates RCC != 0
implies NCC>1.
 
Regards,
Ben


________________________________

	From: [e-mail] [mailto:[e-mail]]
On Behalf Of Adrian Farrel
	Sent: Thursday, August 11, 2005 7:43 AM
	To: [e-mail]
	Subject: Responding to the OIF
	
	
	Hi,
	
	As Lyndon noted in Paris, the OIF has sent us a communication
requesting some guidance on a bunch of questions.
	
	This is to start the business of constructing a reply. thanks to
Dimitri for supplying some of this text.
	
	Please send comments and improvements.
	
	Adrian
	
	======
	
	To: Jim Jones, OIF Technical Committee Chair
	From: Adrian Farrel and Kireeti Kompella, 
	          WG Co-Chairs for IETF CCAMP
	Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors
	Subject: Response to your questions about GMPLS parameters.
	
	Dear Jim,
	
	Thanks for your correspondence about the questions with respect
to GMPLS parameters that arose before and during your interoperability
testing. CCAMP is pleased to receive such questions and is glad to have
the opportunity to explain the intended operation of the GMPLS
protocols.
	 
	Much of the material supplied below can be simply extracted from
the relevant RFCs.


	> 1. Use of the NCC and RCC fields for STS-3c/VC-4 connections
	> 
	> During OIF testing it was noted that some ambiguity exists in
the
	> specification of encoding of NCC, RCC and NVC for certain
types of
	> connections: NCC and RCC for an STS-3c/VC-4 connection can be
set to 0 or
	> to 1 depending on which example of RFC 3946 is followed.
	> 
	> Clarification is requested from IETF CCAMP as to which setting
is
	> considered correct, or if both settings should be accepted
(this procedure
	> was used during testing at Supercomm).
	
	This question about RFC 3946 was raised informally on the CCAMP
mailing list at the start of March this year. 
	
	Even when the signal Type value is the same (i.e. value 6) the
NCC, RCC and NVC values depend on the specific signal being requested.
	
	From the examples in the annex we have...
	
	   A VC-4 signal is formed by applying the following
	   settings to a VC-4 Elementary Signal.
	      RCC = 0
	      NCC = 0
	      NVC = 0
	      MT  = 1
	      T   = 0
	
	   An STS-3c SPE signal is formed by applying the following
	   settings to an STS-3c SPE Elementary Signal.
	      RCC = 1 (standard contiguous concatenation)
	      NCC = 1
	      NVC = 0
	      MT  = 1
	      T   = 0
	
	Your question probably arises from the two notes and subsequent
paragraph in section 2.1 or RFC 3946. Here it says...
	
	   Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the
	      Elementary Signal to use must always be an STS-3c_SPE
signal type
	      and the value of NCC must always be equal to X.  This
allows also
	      facilitating the interworking between SONET and SDH.  In
	      particular, it means that the contiguous concatenation of
three
	      STS-1 SPEs can not be requested because according to this
	      specification, this type of signal must be coded using the
STS-3c
	      SPE signal type.
	
	   Note 2: when requesting a transparent STS-N/STM-N signal
	      limited to a single contiguously concatenated
STS-Nc_SPE/VC-4-Nc,
	      the signal type must be STS-N/STM-N, RCC with flag 1 and
NCC set
	      to 1.
	
	   The NCC value must be consistent with the type of contiguous
	   concatenation being requested in the RCC field.  In
particular, this
	   field is irrelevant if no contiguous concatenation is
requested (RCC
	   = 0), in that case it must be set to zero when sent, and
should be
	   ignored when received.  A RCC value different from 0 must
imply a
	   number of contiguous components greater than 1.
	
	We believe that this final sentence should read "greater than or
equal to 1," and that this interpretation resolves all of your issues
and makes the text consistent with the examples.
	
	> 2. Setting of NVC for VCAT connections
	> 
	> It was also noted that the setting of NVC may be somewhat
ambiguous for
	> the case where diverse connections are used within a single
VCAT group.
	> Each individual RSVP session controls a single connection, but
the
	> connection is part of a larger VCAT group and carries VCAT
encoding of the
	> H4 byte. Clarification is requested from IETF CCAMP and ITU-T
Q.14/15 as
	> to the correct setting of NVC for this case (0 or 1?). It
should be noted
	> that this case may occur with a VCAT group with only a single
initial
	> member, and that the NVC may provide an indication that VCAT
encoding of
	> the H4 byte is in use for the connection.
	
	A VCn-Xv group split into X components requires each of its
component to be signaled with the NVC value set to 1. This setting is
regardless of how the components are established.
	
	> 3. Length of the Interface Switching Capability TLV
	> 
	> Although the Interface Switching Capability TLV defined by
CCAMP for
	> SONET/SDH connections was not used for the testing, it was
noted that the
	> text describing the length of the Interface Switching
Capability TLV
	> defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may
be slightly
	> ambiguous due to the use of padding bytes.
	> 
	> RFC 3630 states that "The TLV is padded to four-octet
alignment; padding
	> is not included in the length field (so a three octet value
would have a
	> length of three, but the total size of the TLV would be eight
octets)."
	 
	Yes. Section 2.3.2 of RFC3630 gives a definitive statement of
the meaning of the length field and the use of padding, and provides an
example.
	 
	> Reading of the encoding in
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
	> specifies that the length of the TLV for TDM is 41 bytes plus
3 bytes of
	> padding, and should be given in the length field as 41 bytes
rather than
	> 44. OIF requests verification of this interpretation from the
experts in
	> IETF CCAMP group.
	 
	Note that the Interface Switching Capability Descriptor defined
in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the
Link TLV. Sub-TLVs and TLVs follow the same encoding rules.
	 
	The ISCD TLV for TDM contains the following fields...
	  type       2 bytes
	  length     2 bytes
	  ---
	  switch cap 1 byte
	  encoding   1 byte
	  reserve    2 bytes
	  LSP b/w 0  4 bytes
	  LSP b/w 1  4 bytes 
	  LSP b/w 2  4 bytes 
	  LSP b/w 3  4 bytes 
	  LSP b/w 4  4 bytes 
	  LSP b/w 5  4 bytes 
	  LSP b/w 6  4 bytes 
	  LSP b/w 7  4 bytes
	  min b/w    4 bytes
	  indication 1 byte
	            ==
	            41 bytes
	 
	We presume that your question relates to whether the 3-byte
field shown as "padding" in the TDM-specific figure on page 6 of
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an
explicit field.
	 
	It is an implicit field, and should not be included in the
length of the TLV.
	 
	Nevertheless, we take this opportunity to remind the OIF that
implementations of GMPLS protocols should be conservative in what they
send and liberal in what they receive. Thus, an implementation that
receives a TDM ISCD TLV with length 44 should not reject the TLV for
this reason. It should parse the TLV according to the defined fields and
skip the final three bytes. Thus, it should not affect a receiving
implementation if the sending implementation has treated the "padding"
field as implicit or explicit. In the event that a receiving
implementation rejected such a TLV on grounds of the value contained in
the length field being too large, the fault would lie with the receiving
implementation not the sending implementation.
	 
	> 4. Use of ADMIN_STATUS in an initial PATH message
	> 
	> Some implementations sent an ADMIN_STATUS object with no flags
set in the
	> initial PATH message, i.e., when no status change was being
requested.
	> Although this did not serve any particular function, it was
believed that
	> this could be accepted as RFC3473, sect. 7.2 (page 18) states:
	> 
	> "The absence of the object is equivalent to receiving an
object containing
	> values all set to zero (0)."
	> 
	> It was our interpretation based on this text that a node
should accept an
	> ADMIN_STATUS object with no flags set in the same way as if
the object was
	> missing. Comment on this interpretation is welcome.
	 
	The effect of the meaning is as you state, but the intention of
the meaning is reversed. That is, an implementation should accept the
absence of the ADMIN_STATUS object in the same way as if the object was
present with no flags set. That is, the default behavior is to consider
the ADMIN_STATUS object as a standard part of the processing.
	 
	We note from your first paragraph that you assume that the
ADMIN_STATUS object is used to change the status of the LSP. This is a
misinterpretation - it is used to control the status of the LSP. Thus,
if there is no change to the status of an LSP, refresh messages must
continue to carry the ADMIN_STATUS object with the same bit setting.
	 
	In this way, it is not possible to "drop" the ADMIN_STATUS
object without having the same meaning as transmitting the object with
all bits cleared.
	 
	> 5. Handling of multiple received ResvConf Request objects
	> 
	> When a connection desires a confirmation that the service
(i.e.
	> connection) requested is in place, a RESV_CONF_REQ object is
included in
	> the RESV message. As this object is received by the remote end
of the
	> reservation, it will send a RESV_CONF message back to the
requester.
	> 
	> However, it is unclear whether it is necessary to send a
RESV_CONF message
	> when the RSVP connection state is refreshed by subsequent
RESV. This
	> becomes potentially burdensome, especially when the
reservation is being
	> rapidly refreshed. Therefore we ask: should the remote end
send a
	> RESV_CONF message for subsequent RESV messages that still
include the
	> RESV_CONF_REQ object? Or is it required that the requestor of
the
	> reservation remove the RESV_CONF_REQ object to prevent the
generation of
	> further RESV_CONF messages? Comment on this issue from IETF
CCAMP is
	> requested.
	 
	It is fundamental to the implementation of RSVP-TE that there is
a good understanding of the distinction between a trigger message and a
refresh message. This can be achieved by reading section 1.1 of RFC2961.
	 
	Following this understanding, you will note that a refresh
message does not cause any processing to be performed at the LSR that
receives it (in this case the ingress). You will also note that refresh
processing is not end-to-end as implied in your text, but is hop-by-hop.
	 
	Thus, an downstream LSR that wishes to trigger a new ResvConf
message must make a specific change to the content of the Resv message
that it sends in order to cause a trigger message to be propagated
through the network to the ingress LSR. Such processing is
implementation specific.

	> 6. Symmetry of Refresh Reduction usage
	> 
	> During interop testing, we ran into a conflict caused by
varying
	> interpretations of RFC2961, regarding the use of SRefresh
messages and the
	> Refresh Reduction capabilities of the two ends of a given
link. One
	> interpretation of RFC2961 indicates that setting the Refresh
Reduction
	> Capability flag in the RSVP header indicates that that
interface shall be
	> capable of receiving messages related to Refresh Reduction -
including the
	> SRefresh message. This would be true even if the other end of
the link for
	> that interface were NOT indicating Refresh Reduction
Capability, since the
	> RFC makes no statement about symmetry in this matter.
	> 
	> Another interpretation is that both ends of an interface must
indicate
	> Refresh Reduction Capability before either end can use such
messages, i.e,
	> use of Refresh Reduction on a link is symmetric.
	> 
	> Comment from CCAMP WG on the correct interpretation is
requested.
	 
	We are confused by your question.
	You correctly state that the use of the
refresh-reduction-capable bit indicates the ability of an LSR to support
the receipt of refresh reduction options and messages. To quote from
section 2 of RFC2961...
	           When set, indicates that this node is willing and
capable of
	           receiving all the messages and objects described in
this
	           document.  This includes the Bundle message described
in
	           Section 3, the MESSAGE_ID objects and Ack messages
described
	           in Section 4, and the MESSAGE_ID LIST objects and
Srefresh
	           message described in Section 5.  This bit is
meaningful only
	           between RSVP neighbors.
	This makes no statement about whether the LSR intends to use
these options when communicating with another LSR. 
	 
	However, you will note that some refresh reduction procedures
require that a message is sent and response returned. In order to make
use of the response, the receiver must be capable of receiving and
processing the response. Thus, it would be usual for an LSR that is
capable of sending refresh reduction options and messages to also set
the refresh-reduction-capable bit.
	 
	In summary:
	- An LSR must not send refresh reduction options or messages 
	  to an LSR that is not setting the refresh-reduction-capable 
	  bit.
	- An LSR may send refresh reduction options or messages  
	  to an LSR that is setting the refresh-reduction-capable bit.
	- An LSR that wishes to successfully use responded refresh 
	  reduction options or messages should set the refresh-
	  reduction-capable bit.
	 
	Note, finally, that section 2 of RFC 2961 states that "When it
is not known if a next hop supports the extension, standard Path and
Resv message based refreshes MUST be used."
	
	> 7. Sending of ACKs bundled with the RSVP HELLO
	> 
	> During interop testing, it was observed that Message Acks were
piggybacked
	> onto RSVP Hello messages, when the receiving end was not using
the Hello
	> protocol. In this situation, the incoming Hello's were
discarded and the
	> Acks were lost.
	> 
	> We believe that Message Acks should only be piggybacked onto
mandatory
	> messages, and not on Hello messages because of this problem.
Comment on
	> this interpretation is requested.
	 
	You use of the terms "bundled" and "piggybacked" are
contradictory.
	 
	"Bundled" implies the use of the Bundle message.
	RFC 2961 states...
	   A sub-message MAY be any message type except for another 
	   Bundle message.
	Thus, Ack messages may be bundled with other messages. (Although
one might consider this perverse since the Ack message is only
introduced to handle the case when the Ac/Nack objects have no other
message on which they can be carried.)
	 
	Further, RFC 3209 states...
	   A Hello message may be included
	   as a sub-message within a bundle message.
	 
	Therefore, it acceptable for a Ack and Hello messages to be
bundled together.
	The processing rules (RFC 29610 for Bundled messages are such
that each sub-message is processed in its own right, and the
non-support/non-use of Hello messages should not impact the processing
of other messages.
	 
	On the other hand, "piggybacked" implies the use of the Ack/Nack
objects within a Hello message.
	 
	Section 4.1 of RFC2961 states that Ack/Nack objects may be
included in the "standard" RSVP messages, and shows where they are
placed. However, RFC 3209 defines the Hello message as not including the
Ack/Nack objects...
	 
	   <Hello Message> ::= <Common Header> [ <INTEGRITY> ]
	                              <HELLO>
	 
	Since RFC 3209 post-dates RFC 2961, this definition is
definitive and the Ack/Nack objects should not be present on the Hello
message.
	 
	Give that section 5.3 of RFC 3209 states...
	   The Hello Message is completely OPTIONAL.  All messages may
be
	   ignored by nodes which do not wish to participate in Hello
message
	   processing.
	...it is not particularly important what the message format
rules are. An implementation that chooses to place an Ack/Nack object in
a Hello message knows that the object might be discarded unprocessed.
	 
	> 8. TSPEC format to be used for Ethernet connections
	 
	The CCAMP working group is currently discussing the use of GMPLS
for control of Ethernet devices. We will respond to this point in a
separate email.

	Best regards,
	Adrian Farrel
	Kireeti Kompella

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

------_=_NextPart_001_01C5A34E.EC43544D
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="us-ascii"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1106" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff background="">
<DIV dir=ltr align=left><SPAN class=416244716-17082005><FONT face=Arial 
color=#0000ff size=2>Hi,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=416244716-17082005><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=416244716-17082005><FONT face=Arial 
color=#0000ff size=2>Regarding the first item,&nbsp;we should have only&nbsp;one 
TSPEC encoding for STS-3c SPE/VC-4 since the intent is to unify signaling for 
SONET and SDH.&nbsp;</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=416244716-17082005><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=416244716-17082005><FONT face=Arial 
color=#0000ff size=2>Furthermore, contiguous concatenation with one element 
doesn't make sense.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=416244716-17082005><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=416244716-17082005><FONT face=Arial 
color=#0000ff size=2>Thus we should change example 8 to match example 1 (in the 
same way that example 9 matches example 3) and leave the text that indicates RCC 
!= 0 implies NCC&gt;1.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=416244716-17082005><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=416244716-17082005><FONT face=Arial 
color=#0000ff size=2>Regards,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=416244716-17082005><FONT face=Arial 
color=#0000ff size=2>Ben</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> [e-mail] 
  [mailto:[e-mail]] <B>On Behalf Of </B>Adrian 
  Farrel<BR><B>Sent:</B> Thursday, August 11, 2005 7:43 AM<BR><B>To:</B> 
  [e-mail]<BR><B>Subject:</B> Responding to the 
  OIF<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=Courier size=2>Hi,<BR><BR>As Lyndon noted in Paris, the OIF 
  has sent us a communication requesting some guidance on a bunch of 
  questions.<BR><BR>This is to start the business of constructing a reply. 
  thanks to Dimitri for supplying some of this text.<BR><BR>Please send comments 
  and improvements.<BR><BR>Adrian<BR><BR>======<BR><BR>To: Jim Jones, OIF 
  Technical Committee Chair<BR>From: Adrian Farrel and Kireeti Kompella, 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WG Co-Chairs for 
  IETF CCAMP<BR>Copy: Alex Zinin and Bill Fenner, IETF Routing Area 
  Directors<BR>Subject: Response to your questions about GMPLS 
  parameters.<BR><BR>Dear Jim,<BR><BR>Thanks for your correspondence about the 
  questions with respect to GMPLS parameters that arose before and during your 
  interoperability testing. CCAMP is pleased to receive such questions and is 
  glad to have the opportunity to explain the intended operation of the GMPLS 
  protocols.</FONT></DIV>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>Much of the material supplied below can be 
  simply extracted from the relevant RFCs.</DIV>
  <DIV><BR><BR>&gt; 1. Use of the NCC and RCC fields for STS-3c/VC-4 
  connections<BR>&gt; <BR>&gt; During OIF testing it was noted that some 
  ambiguity exists in the<BR>&gt; specification of encoding of NCC, RCC and NVC 
  for certain types of<BR>&gt; connections: NCC and RCC for an STS-3c/VC-4 
  connection can be set to 0 or<BR>&gt; to 1 depending on which example of RFC 
  3946 is followed.<BR>&gt; <BR>&gt; Clarification is requested from IETF CCAMP 
  as to which setting is<BR>&gt; considered correct, or if both settings should 
  be accepted (this procedure<BR>&gt; was used during testing at 
  Supercomm).<BR><BR>This question about RFC 3946 was raised informally on the 
  CCAMP mailing list at the start of March this year. <BR><BR>Even when the 
  signal Type value is the same (i.e. value 6) the NCC, RCC and NVC values 
  depend on the specific signal being requested.<BR><BR>From the examples in the 
  annex we have...<BR><BR>&nbsp;&nbsp; A VC-4 signal is formed by applying the 
  following<BR>&nbsp;&nbsp; settings to a VC-4 Elementary 
  Signal.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RCC = 
  0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NCC = 0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  NVC = 0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MT&nbsp; = 
  1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T&nbsp;&nbsp; = 0<BR><BR>&nbsp;&nbsp; An 
  STS-3c SPE signal is formed by applying the following<BR>&nbsp;&nbsp; settings 
  to an STS-3c SPE Elementary Signal.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RCC = 1 
  (standard contiguous concatenation)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NCC = 
  1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NVC = 0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  MT&nbsp; = 1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T&nbsp;&nbsp; = 0<BR><BR>Your 
  question probably arises from the two notes and subsequent paragraph in 
  section 2.1 or RFC 3946. Here it says...<BR><BR>&nbsp;&nbsp; Note 1: when 
  requesting a SONET STS-Nc SPE with N=3*X, 
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Elementary Signal to use must always be 
  an STS-3c_SPE signal type<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and the value of 
  NCC must always be equal to X.&nbsp; This allows 
  also<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; facilitating the interworking between 
  SONET and SDH.&nbsp; In<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; particular, it means 
  that the contiguous concatenation of three<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  STS-1 SPEs can not be requested because according to 
  this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specification, this type of signal must 
  be coded using the STS-3c<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SPE signal 
  type.<BR><BR>&nbsp;&nbsp; Note 2: when requesting a transparent STS-N/STM-N 
  signal<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; limited to a single contiguously 
  concatenated STS-Nc_SPE/VC-4-Nc,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the signal 
  type must be STS-N/STM-N, RCC with flag 1 and NCC 
  set<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to 1.<BR><BR>&nbsp;&nbsp; The NCC value 
  must be consistent with the type of contiguous<BR>&nbsp;&nbsp; concatenation 
  being requested in the RCC field.&nbsp; In particular, this<BR>&nbsp;&nbsp; 
  field is irrelevant if no contiguous concatenation is requested 
  (RCC<BR>&nbsp;&nbsp; = 0), in that case it must be set to zero when sent, and 
  should be<BR>&nbsp;&nbsp; ignored when received.&nbsp; A RCC value different 
  from 0 must imply a<BR>&nbsp;&nbsp; number of contiguous components greater 
  than 1.<BR><BR>We believe that this final sentence should read "greater than 
  or equal to 1," and that this interpretation resolves all of your issues and 
  makes the text consistent with the examples.<BR><BR>&gt; 2. Setting of NVC for 
  VCAT connections<BR>&gt; <BR>&gt; It was also noted that the setting of NVC 
  may be somewhat ambiguous for<BR>&gt; the case where diverse connections are 
  used within a single VCAT group.<BR>&gt; Each individual RSVP session controls 
  a single connection, but the<BR>&gt; connection is part of a larger VCAT group 
  and carries VCAT encoding of the<BR>&gt; H4 byte. Clarification is requested 
  from IETF CCAMP and ITU-T Q.14/15 as<BR>&gt; to the correct setting of NVC for 
  this case (0 or 1?). It should be noted<BR>&gt; that this case may occur with 
  a VCAT group with only a single initial<BR>&gt; member, and that the NVC may 
  provide an indication that VCAT encoding of<BR>&gt; the H4 byte is in use for 
  the connection.<BR><BR>A VCn-Xv group split into X components requires each of 
  its component to be signaled with the NVC value set to 1. This setting is 
  regardless of how the components are established.<BR><BR>&gt; 3. Length of the 
  Interface Switching Capability TLV<BR>&gt; <BR>&gt; Although the Interface 
  Switching Capability TLV defined by CCAMP for<BR>&gt; SONET/SDH connections 
  was not used for the testing, it was noted that the<BR>&gt; text describing 
  the length of the Interface Switching Capability TLV<BR>&gt; defined in 
  draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly<BR>&gt; 
  ambiguous due to the use of padding bytes.<BR>&gt; <BR>&gt; RFC 3630 states 
  that "The TLV is padded to four-octet alignment; padding<BR>&gt; is not 
  included in the length field (so a three octet value would have a<BR>&gt; 
  length of three, but the total size of the TLV would be eight 
  octets)."</FONT></DIV>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>Yes. Section 2.3.2 of RFC3630 gives a 
  definitive statement of the meaning of the length field and the use of 
  padding, and provides an example.</FONT></DIV>
  <DIV><FONT face=Courier size=2>&nbsp;</DIV>
  <DIV>&gt; Reading of the encoding in 
  draft-ietf-ccamp-ospf-gmpls-extensions-12.txt<BR>&gt; specifies that the 
  length of the TLV for TDM is 41 bytes plus 3 bytes of<BR>&gt; padding, and 
  should be given in the length field as 41 bytes rather than<BR>&gt; 44. OIF 
  requests verification of this interpretation from the experts in<BR>&gt; IETF 
  CCAMP group.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Note that the Interface Switching Capability Descriptor defined in 
  draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link TLV. 
  Sub-TLVs and TLVs follow the same encoding rules.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>The ISCD TLV for TDM contains the following fields...</DIV>
  <DIV>&nbsp; type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2 bytes</DIV>
  <DIV>&nbsp; length&nbsp;&nbsp;&nbsp;&nbsp; 2 bytes</DIV>
  <DIV>&nbsp;&nbsp;---</DIV>
  <DIV>&nbsp;&nbsp;switch cap 1 byte</DIV>
  <DIV>&nbsp;&nbsp;encoding&nbsp;&nbsp;&nbsp;1 byte</DIV>
  <DIV>&nbsp; reserve&nbsp;&nbsp;&nbsp; 2 bytes</DIV>
  <DIV>&nbsp;&nbsp;LSP b/w 0&nbsp; 4 bytes</DIV>
  <DIV>
  <DIV>&nbsp;&nbsp;LSP b/w 1&nbsp; 4 bytes 
  <DIV>&nbsp;&nbsp;LSP b/w 2&nbsp; 4 bytes 
  <DIV>&nbsp;&nbsp;LSP b/w 3&nbsp; 4 bytes 
  <DIV>&nbsp;&nbsp;LSP b/w 4&nbsp; 4 bytes 
  <DIV>&nbsp;&nbsp;LSP b/w 5&nbsp; 4 bytes 
  <DIV>&nbsp;&nbsp;LSP b/w 6&nbsp; 4 bytes 
  <DIV>&nbsp;&nbsp;LSP b/w 7&nbsp; 4 
  bytes</DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV>
  <DIV>&nbsp;&nbsp;min&nbsp;b/w&nbsp;&nbsp;&nbsp;&nbsp;4 bytes</DIV>
  <DIV>&nbsp;&nbsp;indication&nbsp;1 
  byte<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;==</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;41 
  bytes</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>We presume that your question relates to whether the 3-byte field shown 
  as "padding" in the TDM-specific figure on page 6 of 
  draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an explicit 
  field.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>It is an implicit field, and should not be included in the length of the 
  TLV.</DIV></FONT>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>Nevertheless, we take this opportunity to 
  remind the OIF that implementations of GMPLS protocols should be conservative 
  in what they send and liberal in what they receive. Thus, an implementation 
  that receives a TDM ISCD TLV with length 44 should not reject the TLV for this 
  reason. It should parse the TLV according to the defined fields and skip the 
  final three bytes. Thus, it should not affect a receiving implementation if 
  the sending implementation has treated the "padding" field as implicit or 
  explicit. In the event that a receiving implementation rejected such a TLV on 
  grounds of the value contained in the length field being too large, the fault 
  would lie with the receiving implementation not the sending 
  implementation.</FONT></DIV>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>&gt; 4. Use of ADMIN_STATUS in an initial PATH 
  message<BR>&gt; <BR>&gt; Some implementations sent an ADMIN_STATUS object with 
  no flags set in the<BR>&gt; initial PATH message, i.e., when no status change 
  was being requested.<BR>&gt; Although this did not serve any particular 
  function, it was believed that<BR>&gt; this could be accepted as RFC3473, 
  sect. 7.2 (page 18) states:<BR>&gt; <BR>&gt; "The absence of the object is 
  equivalent to receiving an object containing<BR>&gt; values all set to zero 
  (0)."<BR>&gt; <BR>&gt; It was our interpretation based on this text that a 
  node should accept an<BR>&gt; ADMIN_STATUS object with no flags set in the 
  same way as if the object was<BR>&gt; missing. Comment on this interpretation 
  is welcome.</FONT></DIV>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>The effect of the meaning is as you state, but 
  the intention of the meaning is reversed. That is, an implementation should 
  accept the absence of the ADMIN_STATUS object in the same way as if the object 
  was present with no flags set. That is, the default behavior is to consider 
  the ADMIN_STATUS object as a standard part of the processing.</FONT></DIV>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>We note from your first paragraph that you 
  assume that the ADMIN_STATUS object is used to change the status of the LSP. 
  This is a misinterpretation - it is used to control the status of the LSP. 
  Thus, if there is no change to the status of an LSP, refresh messages must 
  continue to carry the ADMIN_STATUS object with the same bit 
  setting.</FONT></DIV>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>In this way, it is not possible to "drop" the 
  ADMIN_STATUS object without having the same meaning as transmitting the object 
  with all bits cleared.</FONT></DIV>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>&gt; 5. Handling of multiple received ResvConf 
  Request objects<BR>&gt; <BR>&gt; When a connection desires a confirmation that 
  the service (i.e.<BR>&gt; connection) requested is in place, a RESV_CONF_REQ 
  object is included in<BR>&gt; the RESV message. As this object is received by 
  the remote end of the<BR>&gt; reservation, it will send a RESV_CONF message 
  back to the requester.<BR>&gt; <BR>&gt; However, it is unclear whether it is 
  necessary to send a RESV_CONF message<BR>&gt; when the RSVP connection state 
  is refreshed by subsequent RESV. This<BR>&gt; becomes potentially burdensome, 
  especially when the reservation is being<BR>&gt; rapidly refreshed. Therefore 
  we ask: should the remote end send a<BR>&gt; RESV_CONF message for subsequent 
  RESV messages that still include the<BR>&gt; RESV_CONF_REQ object? Or is it 
  required that the requestor of the<BR>&gt; reservation remove the 
  RESV_CONF_REQ object to prevent the generation of<BR>&gt; further RESV_CONF 
  messages? Comment on this issue from IETF CCAMP is<BR>&gt; 
  requested.</FONT></DIV>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>It is fundamental to the&nbsp;implementation of 
  RSVP-TE that there is a good understanding of the distinction between a 
  trigger message and a refresh message. This can be achieved by reading section 
  1.1 of RFC2961.</FONT></DIV>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>Following this understanding, you will note 
  that a refresh message does not cause any processing to be performed at the 
  LSR that receives it (in this case the ingress). You will also note that 
  refresh processing is not end-to-end as implied in your text, but is 
  hop-by-hop.</FONT></DIV>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>Thus, an downstream LSR that wishes to trigger 
  a new ResvConf message must make a specific change to the content of the Resv 
  message that it sends in order to cause a trigger message to be propagated 
  through the network to the ingress LSR. Such processing is implementation 
  specific.</DIV>
  <DIV><BR>&gt; 6. Symmetry of Refresh Reduction usage<BR>&gt; <BR>&gt; During 
  interop testing, we ran into a conflict caused by varying<BR>&gt; 
  interpretations of RFC2961, regarding the use of SRefresh messages and 
  the<BR>&gt; Refresh Reduction capabilities of the two ends of a given link. 
  One<BR>&gt; interpretation of RFC2961 indicates that setting the Refresh 
  Reduction<BR>&gt; Capability flag in the RSVP header indicates that that 
  interface shall be<BR>&gt; capable of receiving messages related to Refresh 
  Reduction - including the<BR>&gt; SRefresh message. This would be true even if 
  the other end of the link for<BR>&gt; that interface were NOT indicating 
  Refresh Reduction Capability, since the<BR>&gt; RFC makes no statement about 
  symmetry in this matter.<BR>&gt; <BR>&gt; Another interpretation is that both 
  ends of an interface must indicate<BR>&gt; Refresh Reduction Capability before 
  either end can use such messages, i.e,<BR>&gt; use of Refresh Reduction on a 
  link is symmetric.<BR>&gt; <BR>&gt; Comment from CCAMP WG on the correct 
  interpretation is requested.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>We are confused by your question.</DIV>
  <DIV>You correctly state that the use of the refresh-reduction-capable bit 
  indicates the ability of an LSR to support the receipt of refresh reduction 
  options and messages. To quote from section 2 of RFC2961...</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When set, 
  indicates that this node is willing and capable 
  of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; receiving 
  all the messages and objects described in 
  this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  document.&nbsp; This includes the Bundle message described 
  in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 3, 
  the MESSAGE_ID objects and Ack messages 
  described<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in 
  Section 4, and the MESSAGE_ID LIST objects and 
  Srefresh<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  message described in Section 5.&nbsp; This bit is meaningful 
  only<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; between 
  RSVP neighbors.<BR>This makes no statement about whether the LSR intends to 
  use these options when communicating with another LSR. </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>However, you will note that some refresh reduction procedures require 
  that a message is sent and response returned. In order to make use of the 
  response, the receiver must be capable of receiving and processing the 
  response. Thus, it would be usual for an LSR that is capable of sending 
  refresh reduction options and messages to also set the 
  refresh-reduction-capable bit.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>In summary:</DIV>
  <DIV>- An LSR must not&nbsp;send refresh reduction options or 
  messages&nbsp;</DIV>
  <DIV>&nbsp; to an LSR that is not setting the refresh-reduction-capable </DIV>
  <DIV>&nbsp; bit.</DIV>
  <DIV>- An LSR may send refresh reduction options or messages&nbsp; 
  <DIV>&nbsp; to an LSR that is&nbsp;setting the refresh-reduction-capable 
  bit.</DIV>
  <DIV>- An LSR that wishes to successfully use responded refresh </DIV>
  <DIV>&nbsp; reduction options&nbsp;or messages should set the refresh-</DIV>
  <DIV>&nbsp; reduction-capable bit.</DIV></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Note, finally, that section 2 of RFC 2961&nbsp;states that "When it is 
  not known if a next hop supports the extension, standard Path and Resv message 
  based refreshes MUST be used."<BR></DIV>
  <DIV>&gt; 7. Sending of ACKs bundled with the RSVP HELLO<BR>&gt; <BR>&gt; 
  During interop testing, it was observed that Message Acks were 
  piggybacked<BR>&gt; onto RSVP Hello messages, when the receiving end was not 
  using the Hello<BR>&gt; protocol. In this situation, the incoming Hello's were 
  discarded and the<BR>&gt; Acks were lost.<BR>&gt; <BR>&gt; We believe that 
  Message Acks should only be piggybacked onto mandatory<BR>&gt; messages, and 
  not on Hello messages because of this problem. Comment on<BR>&gt; this 
  interpretation is requested.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>You use of the terms "bundled" and "piggybacked" are contradictory.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>"Bundled" implies the use of the Bundle message.</DIV>
  <DIV>RFC 2961 states...</DIV>
  <DIV>&nbsp;&nbsp; A&nbsp;sub-message MAY be any message type except for 
  another </DIV>
  <DIV>&nbsp;&nbsp; Bundle&nbsp;message.</DIV>
  <DIV>Thus, Ack messages may be bundled with other messages. (Although one 
  might consider this perverse since the Ack message is only introduced to 
  handle the case when the Ac/Nack objects have no other message on which they 
  can be carried.)</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Further, RFC 3209 states...</DIV>
  <DIV>&nbsp;&nbsp; A Hello message may be included<BR>&nbsp;&nbsp; as a 
  sub-message within a bundle message.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Therefore, it acceptable for a Ack and Hello messages to be bundled 
  together.</DIV>
  <DIV>The processing rules (RFC 29610 for Bundled messages are such that each 
  sub-message is processed in its own right, and the non-support/non-use of 
  Hello messages should not impact the processing of other messages.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>On the other hand, "piggybacked" implies the use of the Ack/Nack objects 
  within a Hello message.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Section 4.1 of RFC2961 states that Ack/Nack objects may be included in 
  the "standard" RSVP messages, and shows where they are placed. However, RFC 
  3209 defines the Hello message as not including the Ack/Nack objects...</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;&nbsp; &lt;Hello Message&gt; ::= &lt;Common Header&gt; [ 
  &lt;INTEGRITY&gt; 
  ]<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &lt;HELLO&gt;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Since RFC 3209 post-dates RFC 2961, this definition is definitive and the 
  Ack/Nack objects should not be present on the Hello message.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Give that section 5.3 of RFC 3209 states...</DIV>
  <DIV>&nbsp;&nbsp; The Hello Message is completely OPTIONAL.&nbsp; All messages 
  may be<BR>&nbsp;&nbsp; ignored by nodes which do not wish to participate in 
  Hello message<BR>&nbsp;&nbsp; processing.</DIV>
  <DIV>...it is not particularly important what the message format rules are. An 
  implementation that chooses to place an Ack/Nack object in a Hello message 
  knows that the object might be discarded unprocessed.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&gt; 8. TSPEC format to be used for Ethernet connections</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>The CCAMP working group is currently discussing the use of GMPLS for 
  control of Ethernet devices. We will respond to this point in a separate 
  email.</DIV>
  <DIV><BR>Best regards,</DIV>
  <DIV>Adrian Farrel</DIV>
  <DIV>Kireeti Kompella</FONT></DIV></BLOCKQUOTE><pre>============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
</pre></BODY></HTML>

------_=_NextPart_001_01C5A34E.EC43544D--



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 15:02:29 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Aug 2005 17:01:23 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Diego Caviglia <[e-mail]>
CC:  [e-mail],  "richard.spencer" <[e-mail]>, adrian <[e-mail]>, ccamp <[e-mail]>
Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

diego

Diego Caviglia wrote:
> Hi Dimitri,
>             given the high number of MS-SPRing protected transport network
> already deployed seems reasonable to me, from a Network Operator point of
> view, to use at the same time MS-SPRing protection with GMPLS restoration.

there are already two questions here 1. is there an operational need to 
control such rings using GMPLS (? for instance is it effective knowing 
that ring based protection is mainly data plane driven ?) and 2. how to 
position the ring protection wrt to the LSP recovery segment/end-to-end 
recovery

> Let's say the first failure is recovered via MS-SPRing in less than 50 ms
> while subsequent failures can be recovered via GMPLS restoration with lower
> performance.

is it because it is a "local" protection (i.e. wouldn't a segment 
recovery provide the same time efficiency) or because it is ring based

> Basically that is the rationale behind my initial question.
> 
> What is your view on that?

my view is that a problem statement should cover such base questions - i 
am in agreement with adrian stand here -

> Regards
> 
> Diego
> 
> 
> 
> dimitri papadimitriou <[e-mail]> on 17/08/2005 14.43.17
> 
> Please respond to [e-mail]; Please respond to
>        [e-mail]
> 
> To:    [e-mail]
> cc:    [e-mail], [e-mail],
>        [e-mail], [e-mail]
> 
> Subject:    Re: MS-SPring [Was: Moving forward with the CCAMP charter]
> 
> 
> 
> richard,
> 
> 
>>Dimitri,
>>
>>"why (and where) ring topologies are suitable" ?
>>
>>Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will
>>continue to be, widely deployed based on (dual) ring topologies in
>>the access/metro because they provide fast protection and reliability
>>whilst making efficient use of fibre.
>>
>>I do not think this can be disputed so I don't understand where you
>>are coming from with this question?
> 
> 
> while i do not see why this can't be discussed (e.g. there are dozens of
> studies available on this topic) and i can just point out that one can
> deliver fast (time efficient), resource efficient and reliable
> protection without using rings
> 
> therefore, it would worth having some operational feedback and state
> what are the real drivers and rationales if such topic is getting
> started i.e. what is the real appealing rationale behind this mechanism
> 
> note: these are just questions that i think where missing from most
> documents produced on this topic since so far and that are important to
> be addressed
> 
> last point you are mentioning RPR so what would be the interaction with
> the IPORPR WG ?
> 
> 
>>Regards, Richard
>>
>>
>>
>>
>>.
>>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 12:55:38 +0000
Sensitivity: 
Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter]
To: [e-mail], [e-mail]
Cc: "richard.spencer" <[e-mail]>, "adrian" <[e-mail]>, "ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 17 Aug 2005 14:55:09 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Dimitri,
            given the high number of MS-SPRing protected transport network
already deployed seems reasonable to me, from a Network Operator point of
view, to use at the same time MS-SPRing protection with GMPLS restoration.

Let's say the first failure is recovered via MS-SPRing in less than 50 ms
while subsequent failures can be recovered via GMPLS restoration with lower
performance.

Basically that is the rationale behind my initial question.

What is your view on that?

Regards

Diego



dimitri papadimitriou <[e-mail]> on 17/08/2005 14.43.17

Please respond to [e-mail]; Please respond to
       [e-mail]

To:    [e-mail]
cc:    [e-mail], [e-mail],
       [e-mail], [e-mail]

Subject:    Re: MS-SPring [Was: Moving forward with the CCAMP charter]



richard,

> Dimitri,
>
> "why (and where) ring topologies are suitable" ?
>
> Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will
> continue to be, widely deployed based on (dual) ring topologies in
> the access/metro because they provide fast protection and reliability
> whilst making efficient use of fibre.
>
> I do not think this can be disputed so I don't understand where you
> are coming from with this question?

while i do not see why this can't be discussed (e.g. there are dozens of
studies available on this topic) and i can just point out that one can
deliver fast (time efficient), resource efficient and reliable
protection without using rings

therefore, it would worth having some operational feedback and state
what are the real drivers and rationales if such topic is getting
started i.e. what is the real appealing rationale behind this mechanism

note: these are just questions that i think where missing from most
documents produced on this topic since so far and that are important to
be addressed

last point you are mentioning RPR so what would be the interaction with
the IPORPR WG ?

> Regards, Richard
>
>
>
>
> .
>











Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 12:44:19 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Aug 2005 14:43:17 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To:  [e-mail]
CC:  [e-mail],  [e-mail],  [e-mail],  [e-mail]
Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

richard,

> Dimitri,
> 
> "why (and where) ring topologies are suitable" ?
> 
> Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will
> continue to be, widely deployed based on (dual) ring topologies in
> the access/metro because they provide fast protection and reliability
> whilst making efficient use of fibre.
> 
> I do not think this can be disputed so I don't understand where you
> are coming from with this question?

while i do not see why this can't be discussed (e.g. there are dozens of 
studies available on this topic) and i can just point out that one can 
deliver fast (time efficient), resource efficient and reliable 
protection without using rings

therefore, it would worth having some operational feedback and state 
what are the real drivers and rationales if such topic is getting 
started i.e. what is the real appealing rationale behind this mechanism

note: these are just questions that i think where missing from most 
documents produced on this topic since so far and that are important to 
be addressed

last point you are mentioning RPR so what would be the interaction with 
the IPORPR WG ?

> Regards, Richard
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 12:05:14 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: MS-SPring [Was: Moving forward with the CCAMP charter]
Date: Wed, 17 Aug 2005 13:03:41 +0100
Message-ID: <[e-mail]>
Thread-Topic: MS-SPring [Was: Moving forward with the CCAMP charter]
Thread-Index: AcWjH2vMWzPf62cUTzqgbYx2IvS5IAAAaeKA
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

Dimitri,

"why (and where) ring topologies are suitable" ?

Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will =
continue to be, widely deployed based on (dual) ring topologies in the =
access/metro because they provide fast protection and reliability whilst =
making efficient use of fibre.

I do not think this can be disputed so I don't understand where you are =
coming from with this question?

Regards,
Richard

 =20



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 11:32:48 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Aug 2005 13:30:55 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Diego Caviglia <[e-mail]>
CC:  [e-mail],  "Adrian Farrel <adrian" <[e-mail]>, ccamp <[e-mail]>
Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi diego

Diego Caviglia wrote:

> Hi Dimitri,
>             of course you're right this is not the first in we discuss
> MS-SPRing in CCAMP, anyway given that we are discussing the new charter of
> the WG this could be a good moment to decide if interworking between
> MS-SPRing and GMPLS is something that we need to cover.
> 
> I'll try to answer to your questions.
> 
>>"why ring topologies"
> 
> Because there is a plenty of ring topology in the transport world.

i know but i will clarify the question because the question is to be put 
in perspective "why (and where) ring topologies are suitable" ?

>>and for which kind of switching technology ?
> 
> I was thinking about SDH.

and what does prevent a WG like CCAMP to restrict applicability to 
circuit ? reason for providing an answer to initial question

> Regards
> 
> Diego
> 
> 
> 
> 
> 
> dimitri papadimitriou <[e-mail]> on 17/08/2005 13.05.26
> 
> Please respond to [e-mail]; Please respond to
>        [e-mail]
> 
> To:    Adrian Farrel <[e-mail]>
> cc:    [e-mail], Diego Caviglia <[e-mail]>
> 
> Subject:    Re: MS-SPring [Was: Moving forward with the CCAMP charter]
> 
> hi adrian -
> 
> the "ring" topic is part of a set that comes out on a periodic yearly
> basis where one sees some interest popping up and then slowing down (it
> used also to be a topic of discussion at the former IPO WG)
> 
> however, the first question is "why ring topologies" ? and for which
> kind of switching technology ?
> 
> thanks,
> - dimitri.
> 
> Adrian Farrel wrote:
> 
> 
>>Hi Diego,
>>
>>I can well believe that this is something that should/could be of
> 
> interest
> 
>>to CCAMP.
>>
>>It would be premature, however, to put explicit milestones on our charter
>>without first seeing some work on the subject and support from the
>>community.
>>
>>At the very least we would need to scope the problem and understand
>>whether there is any work to be done. If anyone wants to write a draft on
>>this so that we can all understand the problem space, I am sure it would
>>be welcomed.
>>
>>Cheers,
>>Adrian
>>----- Original Message -----
>>From: "Diego Caviglia" <[e-mail]>
>>To: <[e-mail]>
>>Sent: Wednesday, August 17, 2005 8:13 AM
>>Subject: Re: Moving forward with the CCAMP charter
>>
>>
>>
>>
>>>Hi Adrian and all,
>>>                 I've a question about GMPLS interworking with inherent
>>>protection scheme.
>>>
>>>With inherent protection scheme I mean e.g. MS-SPRing in transport
>>
>>network.
>>
>>
>>>MS-SPring is widely deployed and IMHO interworking between that
>>
>>protection
>>
>>
>>>scheme and GMPLS should be foreseen.
>>>Unfortunately there are some constraints to be satisfied (timeslot
>>>interchange and squelching table) when an LSP is created on a MS-SPRing.
>>>
>>>And now the question is this kind of interworking something that should
>>
>>be
>>
>>
>>>covered in CCAMP (I know that there are some Study Point in ITU-T to
>>
>>cover
>>
>>
>>>this issues)?
>>>
>>>IMHO I think the answer is yes but I like to know the feeling of the
>>
>>other
>>
>>
>>>guys here.
>>>
>>>Regards
>>>
>>>Diego
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>.
>>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 11:12:36 +0000
Sensitivity: 
Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter]
To: [e-mail], [e-mail]
Cc: "Adrian Farrel <adrian" <[e-mail]>, "ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 17 Aug 2005 13:11:44 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Dimitri,
            of course you're right this is not the first in we discuss
MS-SPRing in CCAMP, anyway given that we are discussing the new charter of
the WG this could be a good moment to decide if interworking between
MS-SPRing and GMPLS is something that we need to cover.

I'll try to answer to your questions.

>"why ring topologies"
Because there is a plenty of ring topology in the transport world.

>and for which kind of switching technology ?
I was thinking about SDH.

Regards

Diego





dimitri papadimitriou <[e-mail]> on 17/08/2005 13.05.26

Please respond to [e-mail]; Please respond to
       [e-mail]

To:    Adrian Farrel <[e-mail]>
cc:    [e-mail], Diego Caviglia <[e-mail]>

Subject:    Re: MS-SPring [Was: Moving forward with the CCAMP charter]

hi adrian -

the "ring" topic is part of a set that comes out on a periodic yearly
basis where one sees some interest popping up and then slowing down (it
used also to be a topic of discussion at the former IPO WG)

however, the first question is "why ring topologies" ? and for which
kind of switching technology ?

thanks,
- dimitri.

Adrian Farrel wrote:

> Hi Diego,
>
> I can well believe that this is something that should/could be of
interest
> to CCAMP.
>
> It would be premature, however, to put explicit milestones on our charter
> without first seeing some work on the subject and support from the
> community.
>
> At the very least we would need to scope the problem and understand
> whether there is any work to be done. If anyone wants to write a draft on
> this so that we can all understand the problem space, I am sure it would
> be welcomed.
>
> Cheers,
> Adrian
> ----- Original Message -----
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, August 17, 2005 8:13 AM
> Subject: Re: Moving forward with the CCAMP charter
>
>
>
>>Hi Adrian and all,
>>                  I've a question about GMPLS interworking with inherent
>>protection scheme.
>>
>>With inherent protection scheme I mean e.g. MS-SPRing in transport
>
> network.
>
>>MS-SPring is widely deployed and IMHO interworking between that
>
> protection
>
>>scheme and GMPLS should be foreseen.
>>Unfortunately there are some constraints to be satisfied (timeslot
>>interchange and squelching table) when an LSP is created on a MS-SPRing.
>>
>>And now the question is this kind of interworking something that should
>
> be
>
>>covered in CCAMP (I know that there are some Study Point in ITU-T to
>
> cover
>
>>this issues)?
>>
>>IMHO I think the answer is yes but I like to know the feeling of the
>
> other
>
>>guys here.
>>
>>Regards
>>
>>Diego
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
> .
>











Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 11:06:32 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Aug 2005 13:05:26 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail], Diego Caviglia <[e-mail]>
Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian -

the "ring" topic is part of a set that comes out on a periodic yearly 
basis where one sees some interest popping up and then slowing down (it 
used also to be a topic of discussion at the former IPO WG)

however, the first question is "why ring topologies" ? and for which 
kind of switching technology ?

thanks,
- dimitri.

Adrian Farrel wrote:

> Hi Diego,
> 
> I can well believe that this is something that should/could be of interest
> to CCAMP.
> 
> It would be premature, however, to put explicit milestones on our charter
> without first seeing some work on the subject and support from the
> community.
> 
> At the very least we would need to scope the problem and understand
> whether there is any work to be done. If anyone wants to write a draft on
> this so that we can all understand the problem space, I am sure it would
> be welcomed.
> 
> Cheers,
> Adrian
> ----- Original Message ----- 
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, August 17, 2005 8:13 AM
> Subject: Re: Moving forward with the CCAMP charter
> 
> 
> 
>>Hi Adrian and all,
>>                  I've a question about GMPLS interworking with inherent
>>protection scheme.
>>
>>With inherent protection scheme I mean e.g. MS-SPRing in transport
> 
> network.
> 
>>MS-SPring is widely deployed and IMHO interworking between that
> 
> protection
> 
>>scheme and GMPLS should be foreseen.
>>Unfortunately there are some constraints to be satisfied (timeslot
>>interchange and squelching table) when an LSP is created on a MS-SPRing.
>>
>>And now the question is this kind of interworking something that should
> 
> be
> 
>>covered in CCAMP (I know that there are some Study Point in ITU-T to
> 
> cover
> 
>>this issues)?
>>
>>IMHO I think the answer is yes but I like to know the feeling of the
> 
> other
> 
>>guys here.
>>
>>Regards
>>
>>Diego
>>
>>
>>
>>
>>
>>
>>
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 10:24:44 +0000
Sensitivity: 
Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter]
To: "Adrian Farrel" <[e-mail]>
Cc: "<ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 17 Aug 2005 12:24:11 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Adrian,
        actually I have a draft on this matter under my pillow ;-)) it is
quite rought but can be interestion to start the discussion.

I'll post it ASAP, anyway it there any interest from the community on this
subject?

Regards

Diego



"Adrian Farrel" <[e-mail]> on 17/08/2005 11.44.03

Please respond to "Adrian Farrel" <[e-mail]>

To:    <[e-mail]>, "Diego Caviglia" <[e-mail]>
cc:

Subject:    MS-SPring [Was: Moving forward with the CCAMP charter]

Hi Diego,

I can well believe that this is something that should/could be of interest
to CCAMP.

It would be premature, however, to put explicit milestones on our charter
without first seeing some work on the subject and support from the
community.

At the very least we would need to scope the problem and understand
whether there is any work to be done. If anyone wants to write a draft on
this so that we can all understand the problem space, I am sure it would
be welcomed.

Cheers,
Adrian
----- Original Message -----
From: "Diego Caviglia" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, August 17, 2005 8:13 AM
Subject: Re: Moving forward with the CCAMP charter


> Hi Adrian and all,
>                   I've a question about GMPLS interworking with inherent
> protection scheme.
>
> With inherent protection scheme I mean e.g. MS-SPRing in transport
network.
>
> MS-SPring is widely deployed and IMHO interworking between that
protection
> scheme and GMPLS should be foreseen.
> Unfortunately there are some constraints to be satisfied (timeslot
> interchange and squelching table) when an LSP is created on a MS-SPRing.
>
> And now the question is this kind of interworking something that should
be
> covered in CCAMP (I know that there are some Study Point in ITU-T to
cover
> this issues)?
>
> IMHO I think the answer is yes but I like to know the feeling of the
other
> guys here.
>
> Regards
>
> Diego
>
>
>
>
>
>
>












Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 10:20:54 +0000
Message-ID: <02cd01c5a315$9f5389e0$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Diego Caviglia" <[e-mail]>
Subject: MS-SPring [Was: Moving forward with the CCAMP charter]
Date: Wed, 17 Aug 2005 10:44:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Diego,

I can well believe that this is something that should/could be of interest
to CCAMP.

It would be premature, however, to put explicit milestones on our charter
without first seeing some work on the subject and support from the
community.

At the very least we would need to scope the problem and understand
whether there is any work to be done. If anyone wants to write a draft on
this so that we can all understand the problem space, I am sure it would
be welcomed.

Cheers,
Adrian
----- Original Message ----- 
From: "Diego Caviglia" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, August 17, 2005 8:13 AM
Subject: Re: Moving forward with the CCAMP charter


> Hi Adrian and all,
>                   I've a question about GMPLS interworking with inherent
> protection scheme.
>
> With inherent protection scheme I mean e.g. MS-SPRing in transport
network.
>
> MS-SPring is widely deployed and IMHO interworking between that
protection
> scheme and GMPLS should be foreseen.
> Unfortunately there are some constraints to be satisfied (timeslot
> interchange and squelching table) when an LSP is created on a MS-SPRing.
>
> And now the question is this kind of interworking something that should
be
> covered in CCAMP (I know that there are some Study Point in ITU-T to
cover
> this issues)?
>
> IMHO I think the answer is yes but I like to know the feeling of the
other
> guys here.
>
> Regards
>
> Diego
>
>
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 10:20:47 +0000
Message-ID: <02cc01c5a315$9da4a160$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Tomohiro Otani" <[e-mail]>
Cc: "JP Vasseur" <[e-mail]>, <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Subject: Inter-AS GMPLS [Was: Moving forward with the CCAMP charter]
Date: Wed, 17 Aug 2005 10:41:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Tomo,

> Being related with your text and JP's messages, I would ask you
> to touch upon the draft: draft-otani-ccamp-interas-gmpls-te-03.txt.
> Is this related with a kind of baseline for (1) Analysis of inter-domain
> issues ?
>
> So far, there is a proposed draft of GMPLS inter-domain signaling
> as we discussed in Paris, but there is no draft of GMPLS inter-domain
> routing definition whether it is with TE extension or not.
> (your framework draft covers these points)

Good point.

It seems that your draft is discussing two things:
1. TE reachability information exchange
2. Exchange of aggregated TE information for a domain

As you point out in section 4.2, the issue of scalability and policy needs
to be carefully considered before we pursue this too much further.

I think your work, especially the aggregation issues, meshes nicely with
the recent draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt. Therefore, I
propose the following changes to the draft I sent out before...

1. Delete
   Jan 06 First version WG I-D Routing and signaling for complex optical
constraints
   Oct 07 Submit Routing and signaling for complex optical constraints I-D
for IESG review
2. Insert
   Jan 06 First version WG I-D Routing and signaling for link viability
constraints
   Oct 07 Submit Routing and signaling for link viability constraints I-D
for IESG review
3. Delete
    More forward-looking
    ====================
      Routing and signaling for complex constraints and inter-domain
        * first version of WG draft
          - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
        * submit for IESG review
4. Add to Inter-domain section
    - Analysis and protocol changes for routing and signaling for link
viability constraints
      * first version of WG draft
        - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
        - material from draft-otani-ccamp-interas-gmpls-te-03.txt
      * submit for IESG review

Cheers,
Adrian








Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 09:22:37 +0000
Message-ID: <02bd01c5a30d$4a573a20$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "CHO, JAI HYUNG" <[e-mail]>, <[e-mail]>
Subject: L2SC [Was: Moving forward with the CCAMP charter]
Date: Wed, 17 Aug 2005 10:20:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Jaihyung,

The Ethernet GMPLS work has certainly not been forgotten!

The work of the design team is very important and we need more people to
read and digest draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt.
it is particularly important that folk read this draft rather than relying
on scare stories or email threads. Many of the common concerns and issues
have been carefully answered by the DT, and many of the other are not
actually raised in this draft.

For the moment, the CCAMP list remains the correct place to discuss these
issues, but it would seem that the work involved is both larger than the
scope of the CCAMP charter and larger than can be easily swallowed by the
existing working group (you will have noticed that there are plenty of
other things to occupy the WG's time).

For this reason (and see the CCAMP draft minutes) we are currently
investigating whether there could be a better home for this work. The most
obvious solution is to create a new WG, but this would obviously require
careful scoping and also would need support from the community. More
information on this as it becomes available.

Thanks,
Adrian
----- Original Message ----- 
From: "CHO, JAI HYUNG" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Sent: Wednesday, August 17, 2005 9:10 AM
Subject: RE: Moving forward with the CCAMP charter


>
> Hi, Adrian
>
> Thank you for your milestone work.
> However, I can not find L2SC work in your document.
> Where does it belong to ?
> I believe there's some number of people supporting thie work
> and also we see clear industry need for this work.
> I think it would be good if we have L2SC milestone
> at least for framework and solution document.
>
> thanks
>
> Jaihyung
>
>
> Dr. Jaihyung Cho
> ETRI, Korea
> phone :       [phone]
> oversea: [phone]
> fax:         [phone]
>
>
>
>
> -----?? ???----- 
> From: "Adrian Farrel" <[e-mail]>
> From Date: 2005-08-16 ?? 8:28:11
> To: "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "'Kireeti Kompella'"
<[e-mail]>
> Subject: Moving forward with the CCAMP charter
>
> Hi,
>
> Please find attached a file that contains:
>
> - a set of proposed *draft* milestones
> - a discussion of why there are so many milestones
> - a high-level explanation of the work items.
>
> Note that this looks like a lot of milestones, but please read the text
on this issue in the attached file. The bottom line is that this is a
product of micro management where I have tried to identify all of the I-Ds
that we might produce to cover the referenced work, and where I have
placed two (sometimes three) milestones for each I-D.
>
> This micro-management may be over the top, and represents a full
pendulum swing from the previous style of CCAMP milestones, but in the
light of the hiatus of the last 12 months, i think this may be beneficial
and might achieve rapid forwards movement.
>
> I would welcome your (constructive!) comments.
>
> Notes:
> - Why isn't my I-D also cited as input material?
>  No insult intended. The current list is simply there to
>  show the ADs that work is already in progress. All I-Ds
>  will be used as input.
> - Why isn't my pet topic included?
>   Are you sure it is not there between the lines? This
>   list of milestones isn't completely proscriptive.
>
> The objective is to have the WG agreed on the milestones that it wants
to commit to by the end of August.
>
> Thanks,
> Adrian
>
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 09:22:29 +0000
Message-ID: <02be01c5a30d$4c0add90$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Kenji Kumaki" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Date: Wed, 17 Aug 2005 10:23:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Kenji,

> I have some comments on new items.
>
> >MPLS-GMPLS interworking requirements and solutions
> > * first version of WG draft
> >   - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt
> > * submit for IESG review
>
> draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt includes MPLS/GMPLS
> interworking requirements and soultions.
> So I think this draft should be put in the first version of WG draft.

As I said
> > - Why isn't my I-D also cited as input material?
> >   No insult intended. The current list is simply there to
> >   show the ADs that work is already in progress. All I-Ds
> >   will be used as input.

> >MPLS to GMPLS migration strategies
> > * Informational I-D first version of WG draft
> >   - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt
> >   - material from
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt
> > * submit Informational I-D for IESG review
>
> Zafar's draft is merged into
draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt.
> So I think you should replace Zafar's to mine.

Noted.

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 08:09:07 +0000
Thread-Topic: Moving forward with the CCAMP charter
thread-index: AcWjAzLQlIm8Cix3SeGqvAwPJttkLQ==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: 
Bcc: 
Subject: RE: Moving forward with the CCAMP charter
Date: Wed, 17 Aug 2005 17:10:58 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Message-ID: <6f1601c5a303$32da64d0$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Class: urn:content-classes:message

 
Hi, Adrian
 
Thank you for your milestone work.
However, I can not find L2SC work in your document.
Where does it belong to ?
I believe there's some number of people supporting thie work
and also we see clear industry need for this work.
I think it would be good if we have L2SC milestone
at least for framework and solution document.
 
thanks
 
Jaihyung
 

Dr. Jaihyung Cho
ETRI, Korea
phone :       [phone]
oversea: [phone]
fax:         [phone] 




-----?? ???----- 
From: "Adrian Farrel" <[e-mail]> 
>From Date: 2005-08-16 ?? 8:28:11 
To: "[e-mail]" <[e-mail]> 
Cc: "[e-mail]" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]> 
Subject: Moving forward with the CCAMP charter 

Hi, 

Please find attached a file that contains: 

- a set of proposed *draft* milestones 
- a discussion of why there are so many milestones 
- a high-level explanation of the work items. 

Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. 

This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. 

I would welcome your (constructive!) comments. 

Notes: 
- Why isn't my I-D also cited as input material? 
 No insult intended. The current list is simply there to 
 show the ADs that work is already in progress. All I-Ds 
 will be used as input.      
- Why isn't my pet topic included?
  Are you sure it is not there between the lines? This 
  list of milestones isn't completely proscriptive.
  
The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August.
 
Thanks,
Adrian






Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 07:14:41 +0000
Subject: Re: Moving forward with the CCAMP charter
Sensitivity: 
To: [e-mail]
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 17 Aug 2005 09:13:28 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Adrian and all,
                  I've a question about GMPLS interworking with inherent
protection scheme.

With inherent protection scheme I mean e.g. MS-SPRing in transport network.

MS-SPring is widely deployed and IMHO interworking between that protection
scheme and GMPLS should be foreseen.
Unfortunately there are some constraints to be satisfied (timeslot
interchange and squelching table) when an LSP is created on a MS-SPRing.

And now the question is this kind of interworking something that should be
covered in CCAMP (I know that there are some Study Point in ITU-T to cover
this issues)?

IMHO I think the answer is yes but I like to know the feeling of the other
guys here.

Regards

Diego







Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 02:20:00 +0000
Date: Wed, 17 Aug 2005 11:18:18 +0900
From: Kenji Kumaki <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Cc: <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Adrian,

I have some comments on new items.

>MPLS-GMPLS interworking requirements and solutions
> * first version of WG draft
>   - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt
> * submit for IESG review

draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt includes MPLS/GMPLS
interworking requirements and soultions.
So I think this draft should be put in the first version of WG draft.

>MPLS to GMPLS migration strategies
> * Informational I-D first version of WG draft
>   - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt
>   - material from draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt
> * submit Informational I-D for IESG review

Zafar's draft is merged into draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt.
So I think you should replace Zafar's to mine.

Thanks,
Kenji

On Tue, 16 Aug 2005 12:28:11 +0100
"Adrian Farrel" <[e-mail]> wrote:

> Hi,
> 
> Please find attached a file that contains:
> 
> - a set of proposed *draft* milestones
> - a discussion of why there are so many milestones
> - a high-level explanation of the work items.
> 
> Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D.
> 
> This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement.
> 
> I would welcome your (constructive!) comments.
> 
> Notes:
> - Why isn't my I-D also cited as input material?
>   No insult intended. The current list is simply there to
>   show the ADs that work is already in progress. All I-Ds
>   will be used as input.      
> - Why isn't my pet topic included?
>   Are you sure it is not there between the lines? This 
>   list of milestones isn't completely proscriptive.
>   
> The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August.
> 
> Thanks,
> Adrian

-- 
Kenji Kumaki <[e-mail]>





Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2005 01:05:15 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Aug 2005 10:03:07 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
Cc: JP Vasseur <[e-mail]>, [e-mail], [e-mail], 'Kireeti Kompella' <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Adrian,

Being related with your text and JP's messages, I would ask you
to touch upon the draft: draft-otani-ccamp-interas-gmpls-te-03.txt.
Is this related with a kind of baseline for (1) Analysis of inter-domain
issues ?

So far, there is a proposed draft of GMPLS inter-domain signaling
as we discussed in Paris, but there is no draft of GMPLS inter-domain
routing definition whether it is with TE extension or not.
(your framework draft covers these points)

Regards,

tomo




JP Vasseur wrote:

>Hi Adrian,
>
>On Aug 16, 2005, at 2:53 PM, Adrian Farrel wrote:
>
>>> (1) Analysis of inter-domain issues for disjoint and protected paths
>>>        - Informational I-D to close off the topic and devolve to PCE
>>>        * first version of WG draft
>>>        * submit for IESG review
>>>
>>> Could you briefly elaborate on this item ?
>>>
>>
>> I think we have the need for an informational I-D that is a bit  
>> like the
>> existing inter-domain framework I-D, but that examines the more  
>> complex
>> question of the provisioning of disjoint and protection paths across
>> domain boundaries. I am aware that there a lot of ideas out there  
>> and that
>> there has been a lot of research. I think we need to capture an  
>> overview.
>>
>
>ok fair enough ... I'll be happy to provide my input on the topic (as  
>you can imagine ;-))
>
>> It is my (personal - not WG chair) opinion that this I-D will point  
>> firmly
>> at the PCE WG. But just as for single paths we discovered that  
>> there are
>> some (limited) scenarios for single paths where signaling is  
>> suitable on
>> its own, we may find some solutions for diverse and protected paths.
>>
>>
>>> (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful-
>>> shutdown, you may want to add draft-leroux-ccamp-ctrl-
>>> saturation-01.txt ?
>>>
>>
>> Yes. I am inclined to add a work item for "control plane robustness".
>>
>
>Thanks.
>
>JP.
>
>> Adrian
>>
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2005 23:34:25 +0000
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Content-Transfer-Encoding: 7bit
From: JP Vasseur <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Date: Tue, 16 Aug 2005 19:33:13 -0400
To: "Adrian Farrel" <[e-mail]>

Hi Adrian,

On Aug 16, 2005, at 2:53 PM, Adrian Farrel wrote:

>> (1) Analysis of inter-domain issues for disjoint and protected paths
>>        - Informational I-D to close off the topic and devolve to PCE
>>        * first version of WG draft
>>        * submit for IESG review
>>
>> Could you briefly elaborate on this item ?
>>
>
> I think we have the need for an informational I-D that is a bit  
> like the
> existing inter-domain framework I-D, but that examines the more  
> complex
> question of the provisioning of disjoint and protection paths across
> domain boundaries. I am aware that there a lot of ideas out there  
> and that
> there has been a lot of research. I think we need to capture an  
> overview.
>

ok fair enough ... I'll be happy to provide my input on the topic (as  
you can imagine ;-))

> It is my (personal - not WG chair) opinion that this I-D will point  
> firmly
> at the PCE WG. But just as for single paths we discovered that  
> there are
> some (limited) scenarios for single paths where signaling is  
> suitable on
> its own, we may find some solutions for diverse and protected paths.
>
>
>> (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful-
>> shutdown, you may want to add draft-leroux-ccamp-ctrl-
>> saturation-01.txt ?
>>
>
> Yes. I am inclined to add a work item for "control plane robustness".
>

Thanks.

JP.

> Adrian
>



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2005 22:42:55 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Aug 2005 00:40:46 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail],  [e-mail],  [e-mail], 'Kireeti Kompella' <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Adrian Farrel wrote:

>>i would consider the saturarion document and probably cluster it with
>>the set of items on "deployment/advices/BCPs/etc."
> 
> Well, the control plane saturation I-D defines new protocol procedures and
> encodings so it needs to be standards track if we do it.
> 
> Thus my response to JP.

i am fine with a category "control plane robustness" separated from the 
one mentioned here below

note: however, i am not necessarily sure that the type outcome must be 
driver for classification e.g. the saturation document is an outcome of 
practicing RSVP-TE with mechanisms such as soft-provisioning

> If you are raising a new category of work (and I know you commented on
> this in Paris) for deployment/advices/BCPs/etc. I would appreciate it if
> you could:
> - compare what you want with "Interoperability reports and advice"
> - suggest some I-D titles that you might
>    - want to see
>    - be willing to work on (note, these two categories do not have to
> overlapping)

yes, for the time being i think that two major topics are falling in 
this category:
1) TE link operation(s) and processing practices (which is at the end 
what makes GMPLS) is a typical topic that would require further development
2) inter-domain relationship(s)/exchanges and admission control policies

>>there is an item on "OAM Requirements for GMPLS Networks" with a
>>lifetime of around 18 months, while it is difficult to have a detailed
>>view on them wouldn't be advisable to think upon starting an item mid of
>>next year where details (could be info) would be put together
> 
> I think there is some detail missing from your suggestion. I think you are
> saying that we should plan to start developing solutions to meet the OAM
> requirements that we will document. This sounds very good, but I am
> unwilling to insert a milestone without knowing what we are going to work
> on or whether anyone has any intention of doing the work or developing the
> software.

this is the reason why i did myself tried to position the requirement 
document (it is the same reasoning at the end) it is also clear that 
such a topic would benefit from more operational feedback on GMPLS 
network operation(s)

> I would suggest that this is an item that we should monitor and know that
> the chairs are likely to look favorably on solutions work that meets the
> requirements.

ok

> In the back of my mind, however, is the tunnel trace I-D which lies in a
> coffin with a stake through its heart. Not because there weren't
> requirements (we have an RFC documenting the requirements) and not because
> no-one wanted to write the I-D (we had several authors), but because
> no-one wanted to implement.

reason why it may be advisable to have a better view on the "toolset" 
that would be valuable for operating GMPLS networks (bottom-up)

>>several questions
>>
>> >     - ASON Routing solutions
>> >       * first version of WG draft
>> >       * submit for IESG review
>>
>>-> does this mean you envision a single document for IS-IS and OSPF
>>(note i hope these can be submitted to the IESG by 2Q'06 instead of
>>October 2006) also cross-WG review period should be considered
> 
> Not clear that a BGP draft isn't needed too!

a complete response to this question would deserve an I-D by itself ;-)

> These are generic milestones (I have already proposed too many
> milestones!).
> If the changes are tiny and use existing TLVs then a single I-D will
> probably do.
> Otherwise, one I-D per protocol.

ok

>> > Mar 06 First version of WG informational I-D Aligning GMPLS protocols
>>across the standards bodies
>>
>>and
>>
>> >     - Aligning GMPLS protocols across the standards bodies
>> >       - Information I-D not intended for publication as an RFC
>> >       * first version of WG draft
>>
>>-> what the first sub-bullet implies ? note that i do not see other
>>specific milestone(s) for this document while the second sub-bullet
>>refers to a WG I-D ?
> 
> Yes. We need to drive closer alignment between the various uses of GMPLS
> protocols across the standard bodies. In order to colate our thoughts and
> direct discussions in and out of CCAMP we will need to document our ideas
> in an I-D. Because we wish to demonstrate CCAMP community cohesion behind
> our thoughts, this will need to be a WG I-D (hence the milestone and
> starred bullet).

the objective is sensible and i also think valuable to have such common 
view been written down

> However, it is far from clear that the I-D will need to progress to RFC.
> After all, once we identify the actions that are needed, we will carry out
> the actions. We will then need to update the I-D for further actions etc.
> 
> If, on the other hand, the I-D turns out to document longer-term or
> ongoing procedures (like the GMPLS change process) we will certainly need
> to progress the I-D.

so, this document is meant to be a "process" I-D; therefore, its 
progress is indeed dependent on action lines that are to be documented

>> > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D
>>for IESG review
>>
>>-> do you have more details on this specific work item
> 
> Not completely sure. It seems to me that if we are doing stuff for
> signaling, we should also do it for routing. It is possible that this
> folds natrually into the existing signaling (addressing) I-D. Hence this
> milestone depends on the work item...

i see now to what you are referring to

note: i would also suggest focusing the below reference i-d on 
addressing space setting and processing practices (as the name indicates)

>     Interoperability reports and advice
>     - signaling and routing
>       - already have draft-ietf-ccamp-gmpls-addressing-01.txt
>       * submit for IESG review
> 
>>thanks for the hard work,
> 
> 
> You're welcome.
> Thanks for the support.
> 
> Adrian
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2005 19:08:15 +0000
Message-ID: <01ed01c5a296$1bde3a30$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Date: Tue, 16 Aug 2005 20:08:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> i would consider the saturarion document and probably cluster it with
> the set of items on "deployment/advices/BCPs/etc."

Well, the control plane saturation I-D defines new protocol procedures and
encodings so it needs to be standards track if we do it.

Thus my response to JP.

If you are raising a new category of work (and I know you commented on
this in Paris) for deployment/advices/BCPs/etc. I would appreciate it if
you could:
- compare what you want with "Interoperability reports and advice"
- suggest some I-D titles that you might
   - want to see
   - be willing to work on (note, these two categories do not have to
overlapping)

> there is an item on "OAM Requirements for GMPLS Networks" with a
> lifetime of around 18 months, while it is difficult to have a detailed
> view on them wouldn't be advisable to think upon starting an item mid of
> next year where details (could be info) would be put together

I think there is some detail missing from your suggestion. I think you are
saying that we should plan to start developing solutions to meet the OAM
requirements that we will document. This sounds very good, but I am
unwilling to insert a milestone without knowing what we are going to work
on or whether anyone has any intention of doing the work or developing the
software.

I would suggest that this is an item that we should monitor and know that
the chairs are likely to look favorably on solutions work that meets the
requirements.

In the back of my mind, however, is the tunnel trace I-D which lies in a
coffin with a stake through its heart. Not because there weren't
requirements (we have an RFC documenting the requirements) and not because
no-one wanted to write the I-D (we had several authors), but because
no-one wanted to implement.

> several questions
>
>  >     - ASON Routing solutions
>  >       * first version of WG draft
>  >       * submit for IESG review
>
> -> does this mean you envision a single document for IS-IS and OSPF
> (note i hope these can be submitted to the IESG by 2Q'06 instead of
> October 2006) also cross-WG review period should be considered

Not clear that a BGP draft isn't needed too!

These are generic milestones (I have already proposed too many
milestones!).
If the changes are tiny and use existing TLVs then a single I-D will
probably do.
Otherwise, one I-D per protocol.

>  > Mar 06 First version of WG informational I-D Aligning GMPLS protocols
> across the standards bodies
>
> and
>
>  >     - Aligning GMPLS protocols across the standards bodies
>  >       - Information I-D not intended for publication as an RFC
>  >       * first version of WG draft
>
> -> what the first sub-bullet implies ? note that i do not see other
> specific milestone(s) for this document while the second sub-bullet
> refers to a WG I-D ?

Yes. We need to drive closer alignment between the various uses of GMPLS
protocols across the standard bodies. In order to colate our thoughts and
direct discussions in and out of CCAMP we will need to document our ideas
in an I-D. Because we wish to demonstrate CCAMP community cohesion behind
our thoughts, this will need to be a WG I-D (hence the milestone and
starred bullet).

However, it is far from clear that the I-D will need to progress to RFC.
After all, once we identify the actions that are needed, we will carry out
the actions. We will then need to update the I-D for further actions etc.

If, on the other hand, the I-D turns out to document longer-term or
ongoing procedures (like the GMPLS change process) we will certainly need
to progress the I-D.

>  > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D
> for IESG review
>
> -> do you have more details on this specific work item

Not completely sure. It seems to me that if we are doing stuff for
signaling, we should also do it for routing. It is possible that this
folds natrually into the existing signaling (addressing) I-D. Hence this
milestone depends on the work item...

    Interoperability reports and advice
    - signaling and routing
      - already have draft-ietf-ccamp-gmpls-addressing-01.txt
      * submit for IESG review

> thanks for the hard work,

You're welcome.
Thanks for the support.

Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2005 18:56:01 +0000
Message-ID: <01d501c5a294$48b973a0$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Zafar Ali \(zali\)" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Kireeti Kompella" <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Date: Tue, 16 Aug 2005 19:54:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Zafar,

See my response to JP.

Adrian
----- Original Message ----- 
From: "Zafar Ali (zali)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; "Kireeti Kompella" <[e-mail]>
Sent: Tuesday, August 16, 2005 3:34 PM
Subject: RE: Moving forward with the CCAMP charter


Hi Adrian, 
 
Graceful shutdown, a method for explicitly notifying a set of nodes that
either a Link or an entire node will remove itself from the network or
the protocol is going to be disabled for a link or a node, had good
response when kireeti polled for charter updates some times back. We
have been waiting for a charter update to move with this ID
(draft-ali-ccamp-mpls-graceful-shutdown-xx.txt). I think got missed in
your list. can you please include this work item in the milestone list
as well. 
 
Thanks
 
Regards... Zafar  


________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Adrian Farrel
Sent: Tuesday, August 16, 2005 7:28 AM
To: [e-mail]
Cc: [e-mail]; 'Kireeti Kompella'
Subject: Moving forward with the CCAMP charter


Hi,

Please find attached a file that contains:

- a set of proposed *draft* milestones
- a discussion of why there are so many milestones
- a high-level explanation of the work items.

Note that this looks like a lot of milestones, but please read
the text on this issue in the attached file. The bottom line is that
this is a product of micro management where I have tried to identify all
of the I-Ds that we might produce to cover the referenced work, and
where I have placed two (sometimes three) milestones for each I-D.

This micro-management may be over the top, and represents a full
pendulum swing from the previous style of CCAMP milestones, but in the
light of the hiatus of the last 12 months, i think this may be
beneficial and might achieve rapid forwards movement.

I would welcome your (constructive!) comments.

Notes:
- Why isn't my I-D also cited as input material?
  No insult intended. The current list is simply there to
  show the ADs that work is already in progress. All I-Ds
  will be used as input.      
- Why isn't my pet topic included?
  Are you sure it is not there between the lines? This 
  list of milestones isn't completely proscriptive.
  
The objective is to have the WG agreed on the milestones that it
wants to commit to by the end of August.

Thanks,
Adrian





Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2005 18:55:54 +0000
Message-ID: <01d401c5a294$477581f0$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "JP Vasseur" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Date: Tue, 16 Aug 2005 19:53:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> (1) Analysis of inter-domain issues for disjoint and protected paths
>        - Informational I-D to close off the topic and devolve to PCE
>        * first version of WG draft
>        * submit for IESG review
>
> Could you briefly elaborate on this item ?

I think we have the need for an informational I-D that is a bit like the
existing inter-domain framework I-D, but that examines the more complex
question of the provisioning of disjoint and protection paths across
domain boundaries. I am aware that there a lot of ideas out there and that
there has been a lot of research. I think we need to capture an overview.

It is my (personal - not WG chair) opinion that this I-D will point firmly
at the PCE WG. But just as for single paths we discovered that there are
some (limited) scenarios for single paths where signaling is suitable on
its own, we may find some solutions for diverse and protected paths.

> (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful-
> shutdown, you may want to add draft-leroux-ccamp-ctrl-
> saturation-01.txt ?

Yes. I am inclined to add a work item for "control plane robustness".

Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2005 16:49:56 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Aug 2005 18:48:09 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail],  [e-mail],  'Kireeti Kompella' <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian

i would consider the saturarion document and probably cluster it with 
the set of items on "deployment/advices/BCPs/etc."

there is an item on "OAM Requirements for GMPLS Networks" with a 
lifetime of around 18 months, while it is difficult to have a detailed 
view on them wouldn't be advisable to think upon starting an item mid of 
next year where details (could be info) would be put together

several questions

 >     - ASON Routing solutions
 >       * first version of WG draft
 >       * submit for IESG review

-> does this mean you envision a single document for IS-IS and OSPF 
(note i hope these can be submitted to the IESG by 2Q'06 instead of 
October 2006) also cross-WG review period should be considered

 > Mar 06 First version of WG informational I-D Aligning GMPLS protocols 
across the standards bodies

and

 >     - Aligning GMPLS protocols across the standards bodies
 >       - Information I-D not intended for publication as an RFC
 >       * first version of WG draft

-> what the first sub-bullet implies ? note that i do not see other 
specific milestone(s) for this document while the second sub-bullet 
refers to a WG I-D ?

 > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D 
for IESG review

-> do you have more details on this specific work item

thanks for the hard work,
- dimitri.



Adrian Farrel wrote:
> Hi,
> 
> Please find attached a file that contains:
> 
> - a set of proposed *draft* milestones
> - a discussion of why there are so many milestones
> - a high-level explanation of the work items.
> 
> Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D.
> 
> This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement.
> 
> I would welcome your (constructive!) comments.
> 
> Notes:
> - Why isn't my I-D also cited as input material?
>   No insult intended. The current list is simply there to
>   show the ADs that work is already in progress. All I-Ds
>   will be used as input.      
> - Why isn't my pet topic included?
>   Are you sure it is not there between the lines? This 
>   list of milestones isn't completely proscriptive.
>   
> The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August.
> 
> Thanks,
> Adrian
> 
> 
> ------------------------------------------------------------------------
> 
> CCAMP Working Group - Rechartering Effort
> 
> Below you will find
> - a list of proposed milestones
> - an explanation of why this is a long list
> - overview of proposed drafts and work items
> 
> In reviewing this we should look for:
> - topics that are irrelevant or unwanted by the WG
> - topics that have been left out but are wanted by the WG
> - topics that have been assigned the wrong priority or urgency
> - topics or collections or topics that are sufficiently large
>   to potentially warrant their own working group.
> 
> Proposed New milestones
> -----------------------
> 
> Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF
> Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh membership
> Nov 05 Submit ASON Routing evaluation I-D for IESG review
> Nov 05 First version of WG I-D on path computation implmentation advice
> Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF
> Nov 05 First version WG I-D MPLS to GMPLS migration strategies
> Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS
> Nov 05 First version WG I-D Change of LSP ownership between management and control planes
> Dec 05 First version of WG I-D for ASON Routing solutions
> Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review
> Dec 05 Submit Per-domain path computation signaling I-D for IESG review
> Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region Networks
> Dec 05 First version WG I-D for Evaluation of existing protocols for MLN/MRN
> Dec 05 First version WG I-D for Protocol solutions for MLN/MRN
> Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG review
> Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review
> Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module
> Jan 06 First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths
> Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review
> Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and solutions
> Jan 06 First version WG I-D GMPLS OAM Requirements
> Jan 06 First version WG I-D Routing and signaling for complex optical constraints
> Feb 06 Submit LSP Stitching I-D for IESG review
> Mar 06 First version of WG informational I-D Aligning GMPLS protocols across the standards bodies
> Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for IESG review
> Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module
> Mar 06 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions
> Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review
> Jun 06 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review
> Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review
> Jun 06 Submit Change of LSP ownership between management and control planes I-D for IESG review
> Aug 06 Submit path computation implmentation advice I-D for IESG review
> Oct 06 Submit ASON Routing solutions I-D for IESG review
> Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review
> Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG review
> Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review
> Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review
> Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
> Dec 06 Submit GMPLS OAM Requirements I-D for IESG review
> Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review
> Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review
> Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review
> Oct 07 Submit Routing and signaling for complex optical constraints I-D for IESG review
> Oct 07 Recharter or close Working Group
> 
> 
> Why so many milestons?
> ----------------------
> The number of milestones shown in this proposed list far exceeds
> anything I have ever seen in a working group charter. This is
> intentional and while it does indicate a heavy work-load it also
> indicates a higher level of micro-management than is usual within
> working groups. Thus two milestones are presented for each I-D
> (adoption as a WG I-D, and passing to the IESG post-WG-last-call).
> 
> This can be compared with the "normal" charter milestones which
> include a single work-related item that may span several I-Ds and
> refers vaguely only to the "submission" of I-Ds.
> 
> In other words, reviewers of this list should not panic because
> of its length, but should see this as beneficial.
> 
> 
> Explanation of I-Ds and work items
> ----------------------------------
> 
> The following text briefly introduces the work items that are
> represented by the milestones listed above. In this text an
> astrix (*) indicates a milestone to be set.
> 
> The work is divided into several categories according to how
> core it is and how it should be prioritized. Existing drafts
> are referenced to indicate that work is already in progress -
> this is not intended to provide a complete list of existing
> drafts.
> 
>   Completing existing work
>   ========================
> 
>     ASON
>     - ASON Routing evaluation
>       - already have draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt
>       * submit for IESG review
>     - ASON Routing solutions
>       * first version of WG draft
>       * submit for IESG review
>     - GMPLS signaling in support of Call Management
>       - already have draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt
>       * submit for IESG review
>     - GMPLS/ASON lexicography
>       - already have draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
>       * submit for IESG review
>     - Aligning GMPLS protocols across the standards bodies
>       - Information I-D not intended for publication as an RFC
>       * first version of WG draft
> 
>     Interoperability reports and advice
>     - signaling and routing
>       - already have draft-ietf-ccamp-gmpls-addressing-01.txt
>       * submit for IESG review
>     - path computation
>       * first version of WG draft
>         - based on draft-otani-ccamp-gmpls-cspf-constraints-01.txt
>       * submit for IESG review
> 
>     Additional MIB modules
>     - OSPF-TE
>       * first version of WG draft
>         - based on draft-otani-ccamp-gmpls-ospf-mib-00.txt
>       * submit for IESG review
>     - ISIS-TE
>       * first version of WG draft
>       * submit for IESG review
>     - Signaling
>       - Need "living" MIB module under development to catch
>         the minor protocol extensions that have been made
>         * first version of WG draft
>         * submit for IESG review
> 
>     Inter-domain
>     - LSP Stitching
>       - already have draft-ietf-ccamp-lsp-stitching-01.txt
>       * submit for IESG review
>     - RSVP-TE extensions for interdomain
>       - already have draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
>       * submit for IESG review
>     - Per-domain path computation signaling
>       - already have draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
>       * submit for IESG review
>     - Analysis of inter-domain issues for disjoint and protected paths
>       - Informational I-D to close off the topic and devolve to PCE
>       * first version of WG draft
>       * submit for IESG review
> 
>   New items already started and within existing charter
>   =====================================================
> 
>     Advertising TE Node Capabilities
>     - ISIS and OSPF in the same I-D
>       * first version of WG draft
>         - based on draft-vasseur-ccamp-te-node-cap-00.txt
>       * review by IGP working groups
>       * submit for IESG review
> 
>     Automatic discovery of MPLS-TE mesh membership
>     - depends on TE Node capabilities I-D
>       * first version of WG draft
>         - based on draft-vasseur-ccamp-automesh-00.txt
>       * submit for IESG review
> 
>     Multi-layer networks (also multi-region networks)
>     - Requirements
>       * first version of WG draft
>         - based on draft-shiomoto-ccamp-gmpls-mrn-reqs-02.txt
>       * submit for IESG review
>     - Evaluation of existing protocols
>       * first version of WG draft
>         - based on draft-leroux-ccamp-gmpls-mrn-eval-01.txt
>       * submit for IESG review
>     - Solutions
>       * first version of WG draft
>         - based on draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt
>       * submit for IESG review
> 
>     MPLS-GMPLS interworking requirements and solutions
>       * first version of WG draft
>         - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt
>       * submit for IESG review
> 
>     MPLS to GMPLS migration strategies
>       * Informational I-D first version of WG draft
>         - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt
>         - material from draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt
>       * submit Informational I-D for IESG review
> 
>   Minor items just starting but close to heart of WG
>   ==================================================
> 
>     GMPLS OAM Requirements
>     - Interesting and worthwhile
>       * first version of WG draft
>         - based on immature draft-nadeau-ccamp-gmpls-oam-requirements-00.txt
>       * submit for IESG review
> 
>   Minor items just starting and important becuase of inter-SDO interactions
>   =========================================================================
> 
>     GMPLS coordination of VCAT and LCAS
>     - single requirements and solutions draft almost an applicablity statement
>       * first version of WG draft
>         - based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt
>       * submit for IESG review
> 
>     Change of LSP ownership between management and control planes
>     - single requirements and solutions draft defines one bit and a procedure
>       * first version of WG draft
>         - based on draft-caviglia-mp2cpcp2mp-02.txt
>       * submit for IESG review
> 
>   More forward-looking
>   ====================
> 
>     Routing and signaling for complex optical constraints
>       * first version of WG draft
>         - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
>       * submit for IESG review



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2005 15:38:51 +0000
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: multipart/alternative; boundary=Apple-Mail-54--129477393
Message-Id: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
From: JP Vasseur <[e-mail]>
Subject: Re: Moving forward with the CCAMP charter
Date: Tue, 16 Aug 2005 11:36:50 -0400
To: "Adrian Farrel" <[e-mail]>

--Apple-Mail-54--129477393
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Hi Adrian,

Looks like a detailed, ambitious constructive action plan.

Two comments:

(1) Analysis of inter-domain issues for disjoint and protected paths
       - Informational I-D to close off the topic and devolve to PCE
       * first version of WG draft
       * submit for IESG review

Could you briefly elaborate on this item ?

(2) May be in the same bucket as draft-ali-ccamp-mpls-graceful- 
shutdown, you may want to add draft-leroux-ccamp-ctrl- 
saturation-01.txt ?

thanks.

JP.

On Aug 16, 2005, at 7:28 AM, Adrian Farrel wrote:

> Hi,
>
> Please find attached a file that contains:
>
> - a set of proposed *draft* milestones
> - a discussion of why there are so many milestones
> - a high-level explanation of the work items.
>
> Note that this looks like a lot of milestones, but please read the  
> text on this issue in the attached file. The bottom line is that  
> this is a product of micro management where I have tried to  
> identify all of the I-Ds that we might produce to cover the  
> referenced work, and where I have placed two (sometimes three)  
> milestones for each I-D.
>
> This micro-management may be over the top, and represents a full  
> pendulum swing from the previous style of CCAMP milestones, but in  
> the light of the hiatus of the last 12 months, i think this may be  
> beneficial and might achieve rapid forwards movement.
>
> I would welcome your (constructive!) comments.
>
> Notes:
> - Why isn't my I-D also cited as input material?
>   No insult intended. The current list is simply there to
>   show the ADs that work is already in progress. All I-Ds
>   will be used as input.
> - Why isn't my pet topic included?
>   Are you sure it is not there between the lines? This
>   list of milestones isn't completely proscriptive.
>
> The objective is to have the WG agreed on the milestones that it  
> wants to commit to by the end of August.
>
> Thanks,
> Adrian
> <ccamp-milestones.txt>


--Apple-Mail-54--129477393
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Hi Adrian,<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Looks like a detailed, =
ambitious constructive action plan.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Two =
comments:=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>(1)=A0Analysis of =
inter-domain issues for disjoint and protected paths</DIV><DIV>=A0 =A0 =A0=
 - Informational I-D to close off the topic and devolve to =
PCE</DIV><DIV>=A0 =A0 =A0 * first version of WG draft</DIV><DIV>=A0 =A0 =
=A0 * submit for IESG review</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Could you briefly elaborate =
on this item ?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>(2)=A0May be in the same =
bucket as draft-ali-ccamp-mpls-graceful-shutdown, you may want to =
add=A0draft-leroux-ccamp-ctrl-saturation-01.txt ?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>thanks.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>JP.</DIV><DIV><BR><DIV><DIV>O=
n Aug 16, 2005, at 7:28 AM, Adrian Farrel wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"> =
<DIV><FONT face=3D"Courier" size=3D"2">Hi,<BR><BR>Please find attached a =
file that contains:<BR><BR>- a set of proposed *draft* milestones<BR>- a =
discussion of why there are so many milestones<BR>- a high-level =
explanation of the work items.<BR><BR>Note that this looks like a lot of =
milestones, but please read the text on this issue in the attached file. =
The bottom line is that this is a product of micro management where I =
have tried to identify all of the I-Ds that we might produce to cover =
the referenced work, and where I have placed two (sometimes three) =
milestones for each I-D.<BR><BR>This micro-management may be over the =
top, and represents a full pendulum swing from the previous style of =
CCAMP milestones, but in the light of the hiatus of the last 12 months, =
i think this may be beneficial and might achieve rapid forwards =
movement.<BR><BR>I would welcome your (constructive!) =
comments.<BR><BR>Notes:<BR>- Why isn't my I-D also cited as input =
material?<BR>=A0 No insult intended. The current list is simply there =
to<BR>=A0 show the ADs that work is already in progress. All I-Ds<BR>=A0 =
will be used as input.=A0=A0=A0=A0=A0 <BR>- Why isn't my pet topic =
included?</FONT></DIV> <DIV><FONT face=3D"Courier" size=3D"2">=A0=A0Are =
you sure it is not there between the lines? This </FONT></DIV> =
<DIV><FONT face=3D"Courier" size=3D"2">=A0 list of milestones isn't =
completely proscriptive.</FONT></DIV> <DIV><FONT face=3D"Courier" =
size=3D"2">=A0 </FONT></DIV> <DIV><FONT face=3D"Courier" size=3D"2">The =
objective is to have the WG agreed on the milestones that it wants to =
commit to by the end of August.</FONT></DIV> <DIV><FONT face=3D"Courier" =
size=3D"2"></FONT>=A0</DIV> <DIV><FONT face=3D"Courier" =
size=3D"2">Thanks,</FONT></DIV> <DIV><FONT face=3D"Courier" =
size=3D"2">Adrian</FONT><SPAN><DIV>&lt;ccamp-milestones.txt&gt;</DIV></SPA=
N></DIV></BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-54--129477393--



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2005 14:37:11 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A26F.8BA4FA1B"
Subject: RE: Moving forward with the CCAMP charter
Date: Tue, 16 Aug 2005 10:34:00 -0400
Message-ID: <[e-mail]>
Thread-Topic: Moving forward with the CCAMP charter
Thread-Index: AcWiVstE/f8Ki9VCQe+ORuiO8XQAdgAGLSXQ
From: "Zafar Ali \(zali\)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Kireeti Kompella" <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5A26F.8BA4FA1B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Adrian,=20
=20
Graceful shutdown, a method for explicitly notifying a set of nodes that
either a Link or an entire node will remove itself from the network or
the protocol is going to be disabled for a link or a node, had good
response when kireeti polled for charter updates some times back. We
have been waiting for a charter update to move with this ID
(draft-ali-ccamp-mpls-graceful-shutdown-xx.txt). I think got missed in
your list. can you please include this work item in the milestone list
as well.=20
=20
Thanks
=20
Regards... Zafar =20


________________________________

	From: [e-mail] [mailto:[e-mail]]
On Behalf Of Adrian Farrel
	Sent: Tuesday, August 16, 2005 7:28 AM
	To: [e-mail]
	Cc: [e-mail]; 'Kireeti Kompella'
	Subject: Moving forward with the CCAMP charter
=09
=09
	Hi,
=09
	Please find attached a file that contains:
=09
	- a set of proposed *draft* milestones
	- a discussion of why there are so many milestones
	- a high-level explanation of the work items.
=09
	Note that this looks like a lot of milestones, but please read
the text on this issue in the attached file. The bottom line is that
this is a product of micro management where I have tried to identify all
of the I-Ds that we might produce to cover the referenced work, and
where I have placed two (sometimes three) milestones for each I-D.
=09
	This micro-management may be over the top, and represents a full
pendulum swing from the previous style of CCAMP milestones, but in the
light of the hiatus of the last 12 months, i think this may be
beneficial and might achieve rapid forwards movement.
=09
	I would welcome your (constructive!) comments.
=09
	Notes:
	- Why isn't my I-D also cited as input material?
	  No insult intended. The current list is simply there to
	  show the ADs that work is already in progress. All I-Ds
	  will be used as input.     =20
	- Why isn't my pet topic included?
	  Are you sure it is not there between the lines? This=20
	  list of milestones isn't completely proscriptive.
	 =20
	The objective is to have the WG agreed on the milestones that it
wants to commit to by the end of August.
	=20
	Thanks,
	Adrian


------_=_NextPart_001_01C5A26F.8BA4FA1B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1505" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV dir=3Dltr align=3Dleft>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D740012914-16082005><FONT =
face=3DArial=20
color=3D#000080 size=3D2>Hi Adrian, </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D740012914-16082005><FONT =
face=3DArial=20
color=3D#000080 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><FONT color=3D#000080><SPAN=20
class=3D740012914-16082005><FONT face=3DArial>Graceful shutdown, a =
method for=20
explicitly notifying a set of nodes that either a Link or an entire node =
will=20
remove itself from the network or the protocol is going to be disabled =
for a=20
link or a node, had </FONT></SPAN><SPAN class=3D740012914-16082005><FONT =

face=3DArial>good response&nbsp;when kireeti polled for charter updates =
some times=20
back. We have been waiting for a charter update to move with this ID=20
(draft-ali-ccamp-mpls-graceful-shutdown-xx.txt). </FONT></SPAN><SPAN=20
class=3D740012914-16082005><FONT face=3DArial>I think got missed=20
in&nbsp;your&nbsp;list. can you please include this work item&nbsp;in=20
the&nbsp;milestone list as well.&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D740012914-16082005><FONT =
face=3DArial=20
color=3D#000080 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D740012914-16082005><FONT =
face=3DArial=20
color=3D#000080 size=3D2>Thanks</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D740012914-16082005><FONT =
face=3DArial=20
color=3D#000080 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D740012914-16082005><FONT =
face=3DArial><FONT=20
color=3D#000080 size=3D2>Regards... Zafar=20
&nbsp;</FONT></FONT></SPAN></DIV></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
  [mailto:[e-mail]] <B>On Behalf Of </B>Adrian=20
  Farrel<BR><B>Sent:</B> Tuesday, August 16, 2005 7:28 AM<BR><B>To:</B>=20
  [e-mail]<BR><B>Cc:</B> [e-mail]; 'Kireeti=20
  Kompella'<BR><B>Subject:</B> Moving forward with the CCAMP=20
  charter<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DCourier size=3D2>Hi,<BR><BR>Please find attached a =
file that=20
  contains:<BR><BR>- a set of proposed *draft* milestones<BR>- a =
discussion of=20
  why there are so many milestones<BR>- a high-level explanation of the =
work=20
  items.<BR><BR>Note that this looks like a lot of milestones, but =
please read=20
  the text on this issue in the attached file. The bottom line is that =
this is a=20
  product of micro management where I have tried to identify all of the =
I-Ds=20
  that we might produce to cover the referenced work, and where I have =
placed=20
  two (sometimes three) milestones for each I-D.<BR><BR>This =
micro-management=20
  may be over the top, and represents a full pendulum swing from the =
previous=20
  style of CCAMP milestones, but in the light of the hiatus of the last =
12=20
  months, i think this may be beneficial and might achieve rapid =
forwards=20
  movement.<BR><BR>I would welcome your (constructive!)=20
  comments.<BR><BR>Notes:<BR>- Why isn't my I-D also cited as input=20
  material?<BR>&nbsp; No insult intended. The current list is simply =
there=20
  to<BR>&nbsp; show the ADs that work is already in progress. All =
I-Ds<BR>&nbsp;=20
  will be used as input.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>- Why isn't =
my pet=20
  topic included?</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;Are you sure it is not =
there=20
  between the lines? This </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp; list of milestones isn't =
completely=20
  proscriptive.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp; </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>The objective is to have the WG =
agreed on the=20
  milestones that it wants to commit to by the end of =
August.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
  <DIV><FONT face=3DCourier =
size=3D2>Adrian</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C5A26F.8BA4FA1B--



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2005 11:35:10 +0000
Message-ID: <00db01c5a256$6624ebb0$4f849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Subject: Moving forward with the CCAMP charter
Date: Tue, 16 Aug 2005 12:28:11 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_00CE_01C5A25D.F741F3C0"

This is a multi-part message in MIME format.

------=_NextPart_000_00CE_01C5A25D.F741F3C0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00CF_01C5A25D.F741F3C0"


------=_NextPart_001_00CF_01C5A25D.F741F3C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Please find attached a file that contains:

- a set of proposed *draft* milestones
- a discussion of why there are so many milestones
- a high-level explanation of the work items.

Note that this looks like a lot of milestones, but please read the text =
on this issue in the attached file. The bottom line is that this is a =
product of micro management where I have tried to identify all of the =
I-Ds that we might produce to cover the referenced work, and where I =
have placed two (sometimes three) milestones for each I-D.

This micro-management may be over the top, and represents a full =
pendulum swing from the previous style of CCAMP milestones, but in the =
light of the hiatus of the last 12 months, i think this may be =
beneficial and might achieve rapid forwards movement.

I would welcome your (constructive!) comments.

Notes:
- Why isn't my I-D also cited as input material?
  No insult intended. The current list is simply there to
  show the ADs that work is already in progress. All I-Ds
  will be used as input.     =20
- Why isn't my pet topic included?
  Are you sure it is not there between the lines? This=20
  list of milestones isn't completely proscriptive.
 =20
The objective is to have the WG agreed on the milestones that it wants =
to commit to by the end of August.

Thanks,
Adrian
------=_NextPart_001_00CF_01C5A25D.F741F3C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT face=3DCourier size=3D2>Hi,<BR><BR>Please find attached a =
file that=20
contains:<BR><BR>- a set of proposed *draft* milestones<BR>- a =
discussion of why=20
there are so many milestones<BR>- a high-level explanation of the work=20
items.<BR><BR>Note that this looks like a lot of milestones, but please =
read the=20
text on this issue in the attached file. The bottom line is that this is =
a=20
product of micro management where I have tried to identify all of the =
I-Ds that=20
we might produce to cover the referenced work, and where I have placed =
two=20
(sometimes three) milestones for each I-D.<BR><BR>This micro-management =
may be=20
over the top, and represents a full pendulum swing from the previous =
style of=20
CCAMP milestones, but in the light of the hiatus of the last 12 months, =
i think=20
this may be beneficial and might achieve rapid forwards =
movement.<BR><BR>I would=20
welcome your (constructive!) comments.<BR><BR>Notes:<BR>- Why isn't my =
I-D also=20
cited as input material?<BR>&nbsp; No insult intended. The current list =
is=20
simply there to<BR>&nbsp; show the ADs that work is already in progress. =
All=20
I-Ds<BR>&nbsp; will be used as input.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>- Why=20
isn't my pet topic included?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;Are you sure it is not =
there between=20
the lines? This </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; list of milestones isn't =
completely=20
proscriptive.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>The objective is to have the WG =
agreed on the=20
milestones that it wants to commit to by the end of August.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV></BODY></HTML>

------=_NextPart_001_00CF_01C5A25D.F741F3C0--

------=_NextPart_000_00CE_01C5A25D.F741F3C0
Content-Type: text/plain;
	name="ccamp-milestones.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="ccamp-milestones.txt"

CCAMP Working Group - Rechartering Effort

Below you will find
- a list of proposed milestones
- an explanation of why this is a long list
- overview of proposed drafts and work items

In reviewing this we should look for:
- topics that are irrelevant or unwanted by the WG
- topics that have been left out but are wanted by the WG
- topics that have been assigned the wrong priority or urgency
- topics or collections or topics that are sufficiently large
  to potentially warrant their own working group.

Proposed New milestones
-----------------------

Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS =
and OSPF
Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh =
membership
Nov 05 Submit ASON Routing evaluation I-D for IESG review
Nov 05 First version of WG I-D on path computation implmentation advice
Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in =
ISIS and OSPF
Nov 05 First version WG I-D MPLS to GMPLS migration strategies
Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS
Nov 05 First version WG I-D Change of LSP ownership between management =
and control planes
Dec 05 First version of WG I-D for ASON Routing solutions
Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG =
review
Dec 05 Submit Per-domain path computation signaling I-D for IESG review
Dec 05 First version WG I-D Requirements for Multi-Layer and =
Multi-Region Networks
Dec 05 First version WG I-D for Evaluation of existing protocols for =
MLN/MRN
Dec 05 First version WG I-D for Protocol solutions for MLN/MRN
Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG =
review
Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review
Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module
Jan 06 First version WG Informational I-D for Analysis of inter-domain =
issues for disjoint and protected paths
Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF =
for IESG review
Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and =
solutions
Jan 06 First version WG I-D GMPLS OAM Requirements
Jan 06 First version WG I-D Routing and signaling for complex optical =
constraints
Feb 06 Submit LSP Stitching I-D for IESG review
Mar 06 First version of WG informational I-D Aligning GMPLS protocols =
across the standards bodies
Mar 06 Submit GMPLS routing and signaling interoperability advice I-D =
for IESG review
Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module
Mar 06 First version of WG I-D for additional MIB module to cover =
RSVP-TE signaling extensions
Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for =
IESG review
Jun 06 Submit Informational I-D for Analysis of inter-domain issues for =
disjoint and protected paths for IESG review
Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review
Jun 06 Submit Change of LSP ownership between management and control =
planes I-D for IESG review
Aug 06 Submit path computation implmentation advice I-D for IESG review
Oct 06 Submit ASON Routing solutions I-D for IESG review
Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D =
for IESG review
Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG =
review
Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for =
IESG review
Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review
Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
Dec 06 Submit GMPLS OAM Requirements I-D for IESG review
Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review
Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review
Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor =
and IESG review
Oct 07 Submit Routing and signaling for complex optical constraints I-D =
for IESG review
Oct 07 Recharter or close Working Group


Why so many milestons?
----------------------
The number of milestones shown in this proposed list far exceeds
anything I have ever seen in a working group charter. This is
intentional and while it does indicate a heavy work-load it also
indicates a higher level of micro-management than is usual within
working groups. Thus two milestones are presented for each I-D
(adoption as a WG I-D, and passing to the IESG post-WG-last-call).

This can be compared with the "normal" charter milestones which
include a single work-related item that may span several I-Ds and
refers vaguely only to the "submission" of I-Ds.

In other words, reviewers of this list should not panic because
of its length, but should see this as beneficial.


Explanation of I-Ds and work items
----------------------------------

The following text briefly introduces the work items that are
represented by the milestones listed above. In this text an
astrix (*) indicates a milestone to be set.

The work is divided into several categories according to how
core it is and how it should be prioritized. Existing drafts
are referenced to indicate that work is already in progress -
this is not intended to provide a complete list of existing
drafts.

  Completing existing work
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    ASON
    - ASON Routing evaluation
      - already have draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt
      * submit for IESG review
    - ASON Routing solutions
      * first version of WG draft
      * submit for IESG review
    - GMPLS signaling in support of Call Management
      - already have draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt
      * submit for IESG review
    - GMPLS/ASON lexicography
      - already have draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
      * submit for IESG review
    - Aligning GMPLS protocols across the standards bodies
      - Information I-D not intended for publication as an RFC
      * first version of WG draft

    Interoperability reports and advice
    - signaling and routing
      - already have draft-ietf-ccamp-gmpls-addressing-01.txt
      * submit for IESG review
    - path computation
      * first version of WG draft
        - based on draft-otani-ccamp-gmpls-cspf-constraints-01.txt
      * submit for IESG review

    Additional MIB modules
    - OSPF-TE
      * first version of WG draft
        - based on draft-otani-ccamp-gmpls-ospf-mib-00.txt
      * submit for IESG review
    - ISIS-TE
      * first version of WG draft
      * submit for IESG review
    - Signaling
      - Need "living" MIB module under development to catch
        the minor protocol extensions that have been made
        * first version of WG draft
        * submit for IESG review

    Inter-domain
    - LSP Stitching
      - already have draft-ietf-ccamp-lsp-stitching-01.txt
      * submit for IESG review
    - RSVP-TE extensions for interdomain
      - already have draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
      * submit for IESG review
    - Per-domain path computation signaling
      - already have draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
      * submit for IESG review
    - Analysis of inter-domain issues for disjoint and protected paths
      - Informational I-D to close off the topic and devolve to PCE
      * first version of WG draft
      * submit for IESG review

  New items already started and within existing charter
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

    Advertising TE Node Capabilities
    - ISIS and OSPF in the same I-D
      * first version of WG draft
        - based on draft-vasseur-ccamp-te-node-cap-00.txt
      * review by IGP working groups
      * submit for IESG review

    Automatic discovery of MPLS-TE mesh membership
    - depends on TE Node capabilities I-D
      * first version of WG draft
        - based on draft-vasseur-ccamp-automesh-00.txt
      * submit for IESG review

    Multi-layer networks (also multi-region networks)
    - Requirements
      * first version of WG draft
        - based on draft-shiomoto-ccamp-gmpls-mrn-reqs-02.txt
      * submit for IESG review
    - Evaluation of existing protocols
      * first version of WG draft
        - based on draft-leroux-ccamp-gmpls-mrn-eval-01.txt
      * submit for IESG review
    - Solutions
      * first version of WG draft
        - based on draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt
      * submit for IESG review

    MPLS-GMPLS interworking requirements and solutions
      * first version of WG draft
        - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt
      * submit for IESG review

    MPLS to GMPLS migration strategies
      * Informational I-D first version of WG draft
        - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt
        - material from =
draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt
      * submit Informational I-D for IESG review

  Minor items just starting but close to heart of WG
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


    GMPLS OAM Requirements
    - Interesting and worthwhile
      * first version of WG draft
        - based on immature =
draft-nadeau-ccamp-gmpls-oam-requirements-00.txt
      * submit for IESG review

  Minor items just starting and important becuase of inter-SDO =
interactions
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    GMPLS coordination of VCAT and LCAS
    - single requirements and solutions draft almost an applicablity =
statement
      * first version of WG draft
        - based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt
      * submit for IESG review

    Change of LSP ownership between management and control planes
    - single requirements and solutions draft defines one bit and a =
procedure
      * first version of WG draft
        - based on draft-caviglia-mp2cpcp2mp-02.txt
      * submit for IESG review

  More forward-looking
  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    Routing and signaling for complex optical constraints
      * first version of WG draft
        - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
      * submit for IESG review

------=_NextPart_000_00CE_01C5A25D.F741F3C0--




Envelope-to: [e-mail]
Delivery-date: Sat, 13 Aug 2005 14:38:54 +0000
Message-ID: <0dd501c5a014$d27d8a40$08849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "JP Vasseur" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: PCE Requirement in CCAMP
Date: Sat, 13 Aug 2005 15:34:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Dimitri,

GMPLS and non-packet requirements for PCE are likely to include the
specification of protection types, switching types, encoding types,
optical constraints, and so forth. While you could argue that CCAMP has
best knowledge of these items, it does not seem to me to matter if the
corresponding requirements I-D (that describes what constraints PCE must
be able to receive and satisfy) is developed in the PCE working group.

The question that JP's email asks is: "Is it OK with the CCAMP WG if that
requirements I-D is developed in the PCE WG with review from the CCAMP
WG?"

If we can answer this question in isolation of your other point, this
would be helpful. We can then move on to discuss you other point as
follows...


While I understand your concern (that the computational architecture
should not force signaling behavior) I do not believe that it can be
addressed by limiting the discussion to the CCAMP working group. It is
clear that the PCE working group is responsible for the PCE architecture
and should suggest applicability to specific environments including
multi-domain MPLS-TE and GMPLS. The questions then arise: if the
application of PCE to a specific environment requires additions to the
MPLS-TE or GMPLS signaling protocols:
1. which working group should decide that the applicability of PCE in this
environment is valid?
2. which working group should identify the requirement for these protocol
extensions?
3. which working group should validate the requirements for these protocol
extensions?
4. which working group should develop the protocol extensions?
5. which working group should review the protocol extensions?

*My* answers to these questions are:
1 PCE and CCAMP
2 PCE
3 CCAMP
4 PCE
5 CCAMP

My reasoning is:
- the purpose of PCE is to do this work
- CCAMP cannot (and should not) do everything
- CCAMP must keep "supervision" of protocol extensions

I would like to hear other people's opinion on both issues - that raised
by JP and that raised by Dimitri.

Thanks,
Adrian

----- Original Message ----- 
From: "dimitri papadimitriou" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "JP Vasseur" <[e-mail]>;
<[e-mail]>; <[e-mail]>
Sent: Friday, August 12, 2005 7:59 PM
Subject: Re: PCE Requirement in CCAMP


> hi adrian
>
> i perfectly understand the need from the PCE perspective but that's not
> the real question (even if one might question under which charter item
> this work would be initiated - something not clear to me from your reply
> here below)
>
> the real issue is that with such proposal PCE WG would be entering into
> a mode where the computational capabilities are going to drive LSP
> signaling itself - please note here the difference with the discovery
> process through IGP extensions that is going to be put in place - but
> the impact of the global PCE architecture on the independence wrt path
> computation of the RSVP-TE protocol; hence, i always thought that the
> CCAMP WG would have initially provided "guidelines" to the PCE WG before
> such work would start in the PCE WG
>
> i hope you see that the issue is not about the "owning WG" or the
> "reviewing WG" or their cooperation but the need to know more about the
> acceptable level of integration/cooperation of the PCE architecture with
> the operations on signaling LSP before deciding from where the wind will
> come from
>
> hope this clarifies (at least a bit),
> - dimitri.
>
> Adrian Farrel wrote:
>
> > Hi Dimitri,
> >
> >
> >>it depends on the perspective, as such this document is meant to
address
> >>the following item of the charter (last part)
> >>
> >>"- In cooperation with protocol specific Working Group (OSPF, ISIS,
IDR,
> >>MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP
> >>signaling (RSVP-TE) extensions required to support PCE-based path
> >>computation models."
> >
> >
> > No, it is not meant to address that part of the charter. That item
remains
> > unchanged by this discussion.
> >
> > JP's email is clearly specific to the documentation of requirements
for
> > PCE placed by the GMPLS protocols and non-packet networks under the
> > control of GMPLS protocols.
> >
> > Our proposal is to develop all requirements for PCE within the PCE
working
> > group with review by the appropriate external working group.
> >
> > In practice, this only a small change since it is likely to be the
same
> > people involved in the work. It is, however, a formal change in CCAMP
> > which previously had a commitment to work on these requirements.
> >
> >
> >>therefore, it was my understanding that the PCE WG would be waiting
for
> >>the need wrt signaling for detailing its applicability; you (and
adrian)
> >>seems to say we will define the requirement for PCE-based inter-domain
> >>path computation and resulting signaling behaviour/mechanisms would
then
> >>need to be adapted in CCAMP
> >>
> >>in brief, with your proposal PCE WG would be entering into a mode
where
> >>the computational capabilities are going to drive LSP signaling
itself,
> >>as an analogy RSVP-TE operations are decoupled from the routing
> >>topology; so here, the same relationship should be kept with respect
to
> >>the computational scope/capabilities and behaviour of PCE(s)
> >
> >
> > If you are objecting to the specific item on the PCE charter then now
may
> > be a little late, but let me explain the sort of thing that the
charter
> > item is intended to cover by giving a couple of examples.
> >
> > - PCE discovery may be achieved through the presence of
> >   information withing IGP advertisements. This would require changes
> >   to the IGPs and such changes MUST be reviewed by the
> >   appropriate WGs.
> >
> > - The use of a fully computed path that crosses multiple domains
> >   raises confidentiality issues. These issues can be solved by
> >   inserting new sub-objects into an RSVP-TE Explicit Route
> >   object (for example a cookie and PCE ID, or an encrypted
> >   hop).
> >
> > The normal way in which such small protocol changes are made (witness
> > GMPLS additions to the IGPs) is either:
> > a. An I-D is written and taken to the "owning" WG
> > b. An I-D is written in the WG that needs the solutions and
> >    is reviewed in the "owning" WG.
> > This process is usually refered to as "cooperation between WGs".
> > The PCE charter proposes business as usual.
> >
> > Thanks,
> > Adrian
> >
> >
> >
> >>>Dear WG,
> >>>
> >>>CCAMP proposed to work on GMPLS requirements for PCE as necessary.
> >>>
> >>>Considering the work which has been done by the PCE WG on
> >
> > requirements, it
> >
> >>>looks now more natural to move this work exclusively to the PCE WG.
> >>>
> >>>That said, since Inter-domain (G)MPLS TE falls under the scope of
> >
> > CCAMP,
> >
> >>>any requirements for PCE-based Inter-domain LSP computation should be
> >>>discussed in the PCE WG *with* the review of the CCAMP WG.
> >>>
> >>>Similarly, non-packet networks may result in specific additional
> >>>requirements for PCE. We propose that these requirements are also
> >
> > raised
> >
> >>>within the PCE working group and reviewed by CCAMP.
> >>>
> >>>Let us know if you have any opinion on or objection to these
> >
> > proposals.
> >
> >>>JP and Adrian (wearing PCE chair hat)
> >>>
> >>>
> >>>.
> >>>
> >>
> >>
> >>
> >
> >
> >
> > .
> >
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 12 Aug 2005 19:00:31 +0000
Message-ID: <[e-mail]>
Date: Fri, 12 Aug 2005 20:59:39 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail], JP Vasseur <[e-mail]>,  [e-mail],  [e-mail]
Subject: Re: PCE Requirement in CCAMP
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian

i perfectly understand the need from the PCE perspective but that's not 
the real question (even if one might question under which charter item 
this work would be initiated - something not clear to me from your reply 
here below)

the real issue is that with such proposal PCE WG would be entering into 
a mode where the computational capabilities are going to drive LSP 
signaling itself - please note here the difference with the discovery 
process through IGP extensions that is going to be put in place - but 
the impact of the global PCE architecture on the independence wrt path 
computation of the RSVP-TE protocol; hence, i always thought that the 
CCAMP WG would have initially provided "guidelines" to the PCE WG before 
such work would start in the PCE WG

i hope you see that the issue is not about the "owning WG" or the 
"reviewing WG" or their cooperation but the need to know more about the 
acceptable level of integration/cooperation of the PCE architecture with 
the operations on signaling LSP before deciding from where the wind will 
come from

hope this clarifies (at least a bit),
- dimitri.

Adrian Farrel wrote:

> Hi Dimitri,
> 
> 
>>it depends on the perspective, as such this document is meant to address
>>the following item of the charter (last part)
>>
>>"- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR,
>>MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP
>>signaling (RSVP-TE) extensions required to support PCE-based path
>>computation models."
> 
> 
> No, it is not meant to address that part of the charter. That item remains
> unchanged by this discussion.
> 
> JP's email is clearly specific to the documentation of requirements for
> PCE placed by the GMPLS protocols and non-packet networks under the
> control of GMPLS protocols.
> 
> Our proposal is to develop all requirements for PCE within the PCE working
> group with review by the appropriate external working group.
> 
> In practice, this only a small change since it is likely to be the same
> people involved in the work. It is, however, a formal change in CCAMP
> which previously had a commitment to work on these requirements.
> 
> 
>>therefore, it was my understanding that the PCE WG would be waiting for
>>the need wrt signaling for detailing its applicability; you (and adrian)
>>seems to say we will define the requirement for PCE-based inter-domain
>>path computation and resulting signaling behaviour/mechanisms would then
>>need to be adapted in CCAMP
>>
>>in brief, with your proposal PCE WG would be entering into a mode where
>>the computational capabilities are going to drive LSP signaling itself,
>>as an analogy RSVP-TE operations are decoupled from the routing
>>topology; so here, the same relationship should be kept with respect to
>>the computational scope/capabilities and behaviour of PCE(s)
> 
> 
> If you are objecting to the specific item on the PCE charter then now may
> be a little late, but let me explain the sort of thing that the charter
> item is intended to cover by giving a couple of examples.
> 
> - PCE discovery may be achieved through the presence of
>   information withing IGP advertisements. This would require changes
>   to the IGPs and such changes MUST be reviewed by the
>   appropriate WGs.
> 
> - The use of a fully computed path that crosses multiple domains
>   raises confidentiality issues. These issues can be solved by
>   inserting new sub-objects into an RSVP-TE Explicit Route
>   object (for example a cookie and PCE ID, or an encrypted
>   hop).
> 
> The normal way in which such small protocol changes are made (witness
> GMPLS additions to the IGPs) is either:
> a. An I-D is written and taken to the "owning" WG
> b. An I-D is written in the WG that needs the solutions and
>    is reviewed in the "owning" WG.
> This process is usually refered to as "cooperation between WGs".
> The PCE charter proposes business as usual.
> 
> Thanks,
> Adrian
> 
> 
> 
>>>Dear WG,
>>>
>>>CCAMP proposed to work on GMPLS requirements for PCE as necessary.
>>>
>>>Considering the work which has been done by the PCE WG on
> 
> requirements, it
> 
>>>looks now more natural to move this work exclusively to the PCE WG.
>>>
>>>That said, since Inter-domain (G)MPLS TE falls under the scope of
> 
> CCAMP,
> 
>>>any requirements for PCE-based Inter-domain LSP computation should be
>>>discussed in the PCE WG *with* the review of the CCAMP WG.
>>>
>>>Similarly, non-packet networks may result in specific additional
>>>requirements for PCE. We propose that these requirements are also
> 
> raised
> 
>>>within the PCE working group and reviewed by CCAMP.
>>>
>>>Let us know if you have any opinion on or objection to these
> 
> proposals.
> 
>>>JP and Adrian (wearing PCE chair hat)
>>>
>>>
>>>.
>>>
>>
>>
>>
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 12 Aug 2005 18:07:57 +0000
Message-ID: <0d4c01c59f68$ea4b5d70$08849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "JP Vasseur" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: PCE Requirement in CCAMP
Date: Fri, 12 Aug 2005 19:08:56 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Dimitri,

> it depends on the perspective, as such this document is meant to address
> the following item of the charter (last part)
>
> "- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR,
> MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP
> signaling (RSVP-TE) extensions required to support PCE-based path
> computation models."

No, it is not meant to address that part of the charter. That item remains
unchanged by this discussion.

JP's email is clearly specific to the documentation of requirements for
PCE placed by the GMPLS protocols and non-packet networks under the
control of GMPLS protocols.

Our proposal is to develop all requirements for PCE within the PCE working
group with review by the appropriate external working group.

In practice, this only a small change since it is likely to be the same
people involved in the work. It is, however, a formal change in CCAMP
which previously had a commitment to work on these requirements.

> therefore, it was my understanding that the PCE WG would be waiting for
> the need wrt signaling for detailing its applicability; you (and adrian)
> seems to say we will define the requirement for PCE-based inter-domain
> path computation and resulting signaling behaviour/mechanisms would then
> need to be adapted in CCAMP
>
> in brief, with your proposal PCE WG would be entering into a mode where
> the computational capabilities are going to drive LSP signaling itself,
> as an analogy RSVP-TE operations are decoupled from the routing
> topology; so here, the same relationship should be kept with respect to
> the computational scope/capabilities and behaviour of PCE(s)

If you are objecting to the specific item on the PCE charter then now may
be a little late, but let me explain the sort of thing that the charter
item is intended to cover by giving a couple of examples.

- PCE discovery may be achieved through the presence of
  information withing IGP advertisements. This would require changes
  to the IGPs and such changes MUST be reviewed by the
  appropriate WGs.

- The use of a fully computed path that crosses multiple domains
  raises confidentiality issues. These issues can be solved by
  inserting new sub-objects into an RSVP-TE Explicit Route
  object (for example a cookie and PCE ID, or an encrypted
  hop).

The normal way in which such small protocol changes are made (witness
GMPLS additions to the IGPs) is either:
a. An I-D is written and taken to the "owning" WG
b. An I-D is written in the WG that needs the solutions and
   is reviewed in the "owning" WG.
This process is usually refered to as "cooperation between WGs".
The PCE charter proposes business as usual.

Thanks,
Adrian


> > Dear WG,
> >
> > CCAMP proposed to work on GMPLS requirements for PCE as necessary.
> >
> > Considering the work which has been done by the PCE WG on
requirements, it
> > looks now more natural to move this work exclusively to the PCE WG.
> >
> > That said, since Inter-domain (G)MPLS TE falls under the scope of
CCAMP,
> > any requirements for PCE-based Inter-domain LSP computation should be
> > discussed in the PCE WG *with* the review of the CCAMP WG.
> >
> > Similarly, non-packet networks may result in specific additional
> > requirements for PCE. We propose that these requirements are also
raised
> > within the PCE working group and reviewed by CCAMP.
> >
> > Let us know if you have any opinion on or objection to these
proposals.
> >
> > JP and Adrian (wearing PCE chair hat)
> >
> >
> > .
> >
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 12 Aug 2005 16:16:04 +0000
Message-ID: <[e-mail]>
Date: Fri, 12 Aug 2005 18:15:37 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: JP Vasseur <[e-mail]>
CC:  [e-mail],  [e-mail]
Subject: Re: PCE Requirement in CCAMP
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi jp, adrian

it depends on the perspective, as such this document is meant to address 
the following item of the charter (last part)

"- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR,
MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP
signaling (RSVP-TE) extensions required to support PCE-based path
computation models."

therefore, it was my understanding that the PCE WG would be waiting for 
the need wrt signaling for detailing its applicability; you (and adrian) 
seems to say we will define the requirement for PCE-based inter-domain 
path computation and resulting signaling behaviour/mechanisms would then 
need to be adapted in CCAMP

in brief, with your proposal PCE WG would be entering into a mode where 
the computational capabilities are going to drive LSP signaling itself, 
as an analogy RSVP-TE operations are decoupled from the routing 
topology; so here, the same relationship should be kept with respect to 
the computational scope/capabilities and behaviour of PCE(s)

thanks,
- dimitri.

JP Vasseur wrote:

> Dear WG,
> 
> CCAMP proposed to work on GMPLS requirements for PCE as necessary.
> 
> Considering the work which has been done by the PCE WG on  requirements, it
> looks now more natural to move this work exclusively to the PCE WG.
> 
> That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP,
> any requirements for PCE-based Inter-domain LSP computation should be
> discussed in the PCE WG *with* the review of the CCAMP WG.
> 
> Similarly, non-packet networks may result in specific additional
> requirements for PCE. We propose that these requirements are also raised
> within the PCE working group and reviewed by CCAMP.
> 
> Let us know if you have any opinion on or objection to these proposals.
> 
> JP and Adrian (wearing PCE chair hat)
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 12 Aug 2005 15:42:40 +0000
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail]
Content-Transfer-Encoding: 7bit
From: JP Vasseur <[e-mail]>
Subject: PCE Requirement in CCAMP
Date: Fri, 12 Aug 2005 11:41:06 -0400
To: [e-mail]

Dear WG,

CCAMP proposed to work on GMPLS requirements for PCE as necessary.

Considering the work which has been done by the PCE WG on  
requirements, it
looks now more natural to move this work exclusively to the PCE WG.

That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP,
any requirements for PCE-based Inter-domain LSP computation should be
discussed in the PCE WG *with* the review of the CCAMP WG.

Similarly, non-packet networks may result in specific additional
requirements for PCE. We propose that these requirements are also raised
within the PCE working group and reviewed by CCAMP.

Let us know if you have any opinion on or objection to these proposals.

JP and Adrian (wearing PCE chair hat)



Envelope-to: [e-mail]
Delivery-date: Fri, 12 Aug 2005 11:53:34 +0000
Message-ID: <0cc301c59f34$a11aefa0$08849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Lou Berger" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>, "Reshad Rahman" <[e-mail]>, "Anca Zamfir" <[e-mail]>, "Junaid Israr" <[e-mail]>, "Arun Satyanarayana \(asatyana\)" <[e-mail]>
Subject: Short additional working group last call on draft-ietf-ccamp-rsvp-restart-ext-03.txt
Date: Fri, 12 Aug 2005 12:29:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

As mentioned by Arun in his email (below),
draft-ietf-ccamp-rsvp-restart-ext-03.txt has been marked up after working
group last call.

At the same time, the authors made a minor functional change to the
protocol extensions to handle a potential scaling issue.

This email starts a short, additional working group last call on the I-D.
Since the draft has already been through last call, I expect you to focus
on the new material only.

The last call will end on Sunday 21st August at 12 noon GMT.

Thanks,
Adrian

----- Original Message ----- 
From: "Arun Satyanarayana" <[e-mail]>
To: <[e-mail]>; "Adrian Farrel" <[e-mail]>; "Kireeti
Kompella" <[e-mail]>
Cc: "Lou Berger" <[e-mail]>; "Dimitri Papadimitriou"
<[e-mail]>; "Reshad Rahman" <[e-mail]>;
"Anca Zamfir" <[e-mail]>; "Junaid Israr" <[e-mail]>; "Arun
Satyanarayana (asatyana)" <[e-mail]>
Sent: Sunday, July 24, 2005 4:33 AM
Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-03.txt


> Hi all,
>
> Version -03 is the updated version resulting from last-call comments.
>
> A scalability concern was raised, where, the restarting node does not
> support the mechanism in this I-D, but, one or more RSVP neighbors do.
> This would result in unnecessary generation (and possible
> retransmission) of RecoveryPath msgs by the neighbors, and, receive
> processing of the RecoveryPath msg until the restarting node has to
> decide to drop it. This may be a scalability issue when a large number
> of LSPs are active on the restarting node.
>
> The solution is to indicate the capability to transmit and receive
> RecoveryPath msgs with 2 new bits in the Capability object.
>
> Note: The above solution also addresses a similar concern raised
> earlier, where, the restarting node support the extensions but one or
> more of its neighbors do not. The restarting node would have to wait
> until the end of the Recovery Period to revert to restart processing per
> RFC3473. With an explicit advertisement of RecoveryPath capability, this
> requirement no longer exists.




Envelope-to: [e-mail]
Delivery-date: Fri, 12 Aug 2005 10:49:14 +0000
Message-ID: <0c8201c59f2b$981350e0$08849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, <[e-mail]>, "Lam, Hing-Kam \(Kam\)" <[e-mail]>
Subject: Liaison to SG15 on RFC 4139
Date: Fri, 12 Aug 2005 11:46:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

To: ITU-T Study Group 15
From: IETF CCAMP Working Group
Subject: New Request for Comment Published
For: Information

The CCAMP Working Group of the IETF wishes to inform Study Group 15 of the
ITU-T of the publication of a new Request for Comment.

RFC 4139 "Requirements for Generalized MPLS (GMPLS) Signaling Usage and
Extensions for Automatically Switched Optical Network (ASON)" is available
at http://www.ietf.org/rfc/rfc4139.txt

The Abstract of this RFC reads as follows.

   The Generalized Multi-Protocol Label Switching (GMPLS) suite of
   protocols has been defined to control different switching
   technologies and different applications.  These include support
   for requesting Time Division Multiplexing (TDM) connections, including
   Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy
   (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 signaling protocol to support the capabilities of an
   Automatically Switched Optical Network (ASON).  This document provides
   a problem statement and additional requirements for the GMPLS
   signaling protocol to support the ASON functionality.

The CCAMP Working Group would like to thank the members and Questions of
Study Group 15 for the helpful input and review feedback that they
provided while this document was being developed.

The CCAMP Working Group continues to actively pursue protocol solutions
for the ASON model and seeks to harmonise GMPLS and ASON. We will keep you
informed of our future progress.

Regards,
Adrian Farrel and Kireeti Kompella
CCAMP Working Group Co-chairs




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Aug 2005 15:34:41 +0000
Message-ID: <093301c59e8a$59137510$08849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Updated minutes - more comments please
Date: Thu, 11 Aug 2005 16:21:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks to Richard and Dimitri for filling some gaps.

======

IETF-63 Paris August 2005

CCAMP Working Group

Minutes thanks to Deborah Brungard and Don Fedyk

------------------
1) Admin
Adrian reviewed slides of agenda
------------------

------------------
2) WG Status
Adrian reviewed draft status and milestones
------------------

------------------
3) ITU and OIF  liaison report - Lyndon Ong

Reviewed slides
- Q14 Plan to share g7713 before goes for consent
- No signaling activities, routing they are waiting for our DT
  response, next meeting in Chicago
- OIF activities
  - OIF communication to IETF with identified issues from demo
------------------
Adrian: Understand that there is no urgency for responding
        Will respond as quickly as possible, will post on mailing list.
Lyndon: These are results of the demo so there is no dependence but
        they are important.
Dimitri: Were these issues identified before or after demo?
Lyndon: Some before, some after.
Dimitri: Why not asked over the list for those before?
Lyndon: Some of the issues were, like the encoding.
        The first issue was on an informal response. So we want a formal
        response.
        The other issues we made some implementation decisions so we want
        to verify the decisions.
------------------

------------------
4) Interdomain RSVP - Arthi Ayyangar

Reviewed slides
- Hope to get comments before do next revision (soon) then hope to go
  for last call
------------------
Dimitri: Do you plan to keep the examples in the document or as
         appendix?
Arthi: Do you think it affects readability?
Dimitri: Prefer as appendix
Arthi: OK
Adrian: Is this an example or is it normative?
Arthi: The example only describes the overall working.
------------------

------------------
5) LSP stitching: Arthi Ayyangar

Reviewed slides
- Summarized discussion on list
- First point
  - Are procedures required for both PSC and non-PSC LSPs?
  - Discussion on list indicated yes
  Adrian: Also from a control plane point of view it is better to
          have a consistent behavior
- 2nd point
  - Should allow stitching while traversing region boundaries?
  Dimitri: I see no reason for this, why are we still discussing?
  Adrian: I said yes on the list because of the last bullet on the
          slide. Why disallow it?
  Kireeti: I think yes also, why disallow it?
  Dimitri: Why allow it?
  Adrian: If we take it out of scope now, we may have to change later,
          so why remove it now?
          Yet we don't want to do it speculatively.
  Igor: Question for kireeti: Can we stitch PSC1 with PSC2 LSP?
        And we said while we could do this with a label stack, but we
        shouldn't allow it as these LSPs were provisioned for a reason
        as two different types (PSC1 and PSC2).
        In the non-packet world this more clear. Use hierarchy and
        adaptation.
  Kireeti: Not so clear for me. PSC1 & PSC2 We understand but Non-PSC
           we don't understand. For non PSC, we don't know where it
           will go, e.g. wavelength switching. So why prevent it?
  Igor: It is not complex but it is pointless.
  Kireeti: You can always say no when you receive a request to stitch.
  Arthi and Igor: No, you can't say no
  Lou: What is the difference between stitching and hierarchical LSP.
       The LSP on top (inner label) uses all the bandwidth of the one
       below (outer label).
  Adrian: The difference is if you add a label for the passenger LSP.
  Arthi: It's not just label allocation it's resource allocation.
         I'll address this later.
- Bidirectional LSPs and control of labels
  - Current proposal resolves this by not sending a Label.
  - 4 options: In Slides:
  Lou: Minor suggestion; use a different C-type.
       Call it Option 2 Prime.
  Arthi: You can, but it is still an issue.
  Adrian: You have to do special processing when you do stitching
          anyway.
  Arthi: You still have to implement the C-type.
  Kireeti: You don't have to allocate a special label.
  Adrian: Agree Point 4: Need to provide end-to-end bidirectional
          service. For example for mpls/gmpls migration. Need to
          stitch two unidirectional LSPs in the middle.
  Arthi: Or could do 2nd part of (4). This is not really any changes
         Just need stronger description on what we are doing
         Personally like a sending label that is ignored.
  Adrian: Who likes this 2nd part?
          - Send any label and have receiver ignore it
          # Some show of hands
  Adrian: Anyone prefer one of the other solutions?
          # (No one?)
  Adrian: Seems a preference for this 2nd option, will take to list
  Lou: Clear to make the change. Change the text to Must.
  Dimitri: Can you make clear on the stitching for bidirectionality
  Arthi: Should it be required for non PSC?
  Lou: Anyone that supports stitching MUST support the procedures if
       they support stitching.
  Arthi: But if you are not following this document.
         You could be doing data plane stitching and not control
         plane stitching.
  Lou: If it is outside the standard then it is out of scope. If you
       follow the document you MUST follow the procedures.
------------------

------------------
6) Per-Domain-Paths - JP Vasseur

Would like to get feedback on last issue on slides.
------------------
Adrian: I think the use of IP reachability information is important.
        The WG must make a conscious decision.
JP: This I-D is only describing reachability outside of domain
Adrian: We should say so more clearly
Dimitri: I sent feedback. We should cover this question.
         Not sure if part of this document. This is a problem in several
         documents.
         If we have IP reachability, but don't know switching
         capability, then it's not sure if we can make the connection.
         This an issue when have a mixture of switching capabilities.
Igor: When we compute path, we consider TE resources, not IP
      reachability. Should not rely on knowing reachability.
      Once you have a mix of terminating points this is a real issue.
Adrian: We need to have a global solution.
Igor: You want to compute path consider the resources TE resource
      reachability of destination.  Not to rely on the IP but have
      static information that you can reach the path.
JP: Just want to rely on IP reachability to reach next domain, and then
    let next domain decide if it can satisfy the request.
Igor: OK - maybe could do aggregation rules
      You can have a static TE entry.
JP: But we don't have information on resources
Janis ??: Agree that if we are separating data and control plane, this
          will not work
Adrian: Specifying what information to use for path computation is not
        covered anywhere. It is part of the algorithm, but not part of
        the protocol. CSPF can use any information including IP
        reachability or the weather.
Arthi: So how do we find next hop? How do you get to the next domain?
Adrian: If we don't do this process inside the domain, why do we have
        to have a way to get out of the domain?
JP: So we should remove next hop?
Arthi: Does not make sense. How to do crankback?
Kireeti: OK - we need to consider further
------------------

------------------
7) Addresses in GMPLS networks - Richard Rabbat

Reviewed slides
------------------
Arthi: why you are proposing as a std track?
Adrian: This decision was a result of a loose poll based on
        whether this advises, recommends or mandates.
Arthi: Can we do again the poll
Adrian: We can, who prefers:
        # BCP - some show of hands
        # Stds track - less show of hands
Arthi: My concern is that it is good to have this document, but
       it is using items from other docs and making some changes
       Have to change the Musts and Shoulds.
Adrian: If text is repeating the same must/should from another document
        then it should be deleted.
        If this is new must/should language then it should be std track
        Need to clarify definitions. If you are Restating with same
        values, its BCP. If you change values it is Standards updating
        an existing RFC or a new Standards track document.
Arthi: Then this should be std track as it is already doing it
Lou: It is bringing together many items - would suggest informational
     Could be informational. I did not vote because I was waiting for
     informational.
Adrian: Who wants informational?
        # almost same show of hands as BCP
Lou: If it's implementation then BCP, but if bringing together info,
     then informational
     The document is putting recommendations on implementing.
     Is it just for building and deploying?
     Or is it Defining a new field or procedure?
Adrian: OK we should discuss more
Dimitri: I thought the same - it is bringing together experience on
         using addresses, not saying how to do, and not covering
         future issues. So I have issue with 9.3 which is not based
         on experience
Adrian: The WG needs to decide how want to do
Kireeti: We will discuss with ADs and take to list
Arthi: For example, for the FA it says a MUST for how to use, but it
       doesn't say what to do for static case, so doesn't cover all
       cases
Richard: This is an oversight. we'll correct it in the next revision
         to say that we're talking about the dynamic case.
Yakov: Slide #3. Why the decision on FA LSP, this is a change to the
       protocol.
Richard: You don't know it is a FA LSP. How do you know that it is to
         be advertised back?
John Drake: It is covered in RFC3477.
Lou: That is unnumbered interfaces.
Adrian: Numbered FA LSPs need a way to indicate to the egress that
        they will be used as FAs. Compare with unnumbered LSPs that
        have a special object.
Arthi: What is the point of changing it to 0?
Kireeti: Let's discuss on the list
------------------

------------------
8) GMPLS/ASON Lexicography - Igor Bryskin

Reviewed slides
------------------
Igor: If anyone is interested in furthering ason-gmpls convergence,
      talk to Adrian or myself to help
Richard: What is your objective?
Igor: Have consensus in the group and expand the dictionary.
Richard: Saw in one the drafts on ASON there is an appendix.
         With ASON terms. Should we integrate the ason-gmpls
         documents' reference terms into this document?
Dimitri: No, that work was for CCAMP people to understand ASON.
         This is a different purpose
Igor: Agree. This is for ITU people to understand GMPLS
------------------

------------------
9) ASON routing evaluation - Dimitri Papadimitriou

Reviewed slides
------------------
Adrian: Who from DT is in the room?
        # Dimitri and Lyndon
Adrian: Thanks for work.
        Does the DT think this is ready for last call?
Lyndon: Yes. Just some minor editing
Adrian: Anyone object to last call
        # None
Alex: Doesn't WG need to read this first
Adrian: Yes, need to read it for last call
        OK take to list for last call
------------------

------------------
10) ASON signaling - Dimitri Papadimitriou

Reviewed slides
------------------
Dimitri: The community that wants to use this document needs it
         to be recognized as an RFC, it is important to finish
Alex: Any technical issues on this or the last document that need to
      discuss now?
Dimitri: Only this item on simultaneous call/connection signaling
Alex: Please summarize the technical issues.
      Please focus the time in the meeting to raise and discuss
      open issues
Lyndon: Will you liaison to SG15 before last call?
Kireeti: Yes
Steve Trowbridge: Should also include specific changes against g7713.2
Adrian: What is the intention?
Steve: Should be for alignment, should not have two normative versions
       of ASON signaling
Adrian: ITU already has versions .1, .2, .3
Steve: State how it differs from .2 version
Adrian: OK. This is GMPLS. 7713.2 is not GMPLS.
        We can do a comparative analysis.
        Principal difference is call/connection piggybacking
Lyndon: Is this UNI/ENNI/INNI?
Dimitri: The document states clearly this if you read it
         Answer is all three
Alex: Are the technical issues complete? It would be much better if we
      have the technical summary.  Not just say this work is ready or
      work is stable.
Adrian: We owe the WG status.
Kireeti: Dimitri, can you start the liaison?
Dimitri: OK
------------------

------------------
11) CCAMP Work Plan

Kireeti reviewed the slide on options what to do
- We have pretty much cleared the documents in our queue,
  and we are reviewing the charter to update
------------------
Alex: - I have 12 documents submitted to me, 10 docs in id list.
      - Documents are done when finished also IESG review, I don't
        expect to wait for this though before going on to new items.
Alex reviewed slide on potential new work
- Inter domain OK
- Layer 2 switching: where is this?
Kireeti: We will have a discussion on where to put it
Alex continues:
- L1VPN New WG
- doesn't seem any objection, should prioritize and timeline
- Are these Milestones or Work items?
Kireeti:
- Could do milestones, but defining work items is easier
- For example, MPLS/GMPLS interworking is implicit in the charter
  but not specifically covered.
Alex: Can identify high priority items now
Adrian: - We already asked the working group and this is on the first
          slide.
        - There are six items shown on the slide
Alex: Six items that need some work. Is that too much?
Adrian:
- Not all things are the same size.
- Interoperability issues are already on the plate.
- Layer 2 switching Moderate size thing.
- MPLS/GMPLS migration moderate size.
- Second slide shows recent new topics. Maybe take on new items.
  - Signaling Issues:
  - Routing issues
  - GMPLS OAM requirements.
Alex: These items are also important
Kireeti: Should look at pipelining work as we already started first
         slide. It all depends on how long it takes to do charter.
         We have been waiting now for more than a year
Alex: Can prioritize and identify if can spin off work to a new,
      separate working group.
      Just like Layer 1 VPN that uses GMPLS.
      Take out other lumps and put in other WGs?
      Chairs should identify items.
Adrian: We can discuss which could spin off, though we need to decide,
        and not delay, as many items are already being worked on.
Bijan Jabbari: When I look at what is being implemented by vendors
               there is a mismatch with what this group is doing.
               Perhaps should look at short term.
Alex: Yes my thoughts should look at 1 year to 2 years.
Bijan: Not really clear what is being implemented
Bijan: I work with Academia and industry, and the answer is not clear.
       You see implementations but you don't see deployments.
       Business reasons etc. New way of thinking that takes time.
Alex: When go for standard track, do need implementation
Kireeti: Also need deployments, and that takes time
JP: Regarding the item on "input to PCE requirements".
    Not sure if need this input
Adrian: Explain history is that CCAMP made a commitment to assist PCE
        Could agree to remove this commitment
Alex: Yes we should discuss more in both groups. Don't want to make
      commitment to remove this before discussing it.
      If we have consensus maybe we don't need the document.
JP: On advertisement of TE/GMPLS capabilities, we have implemented
    and deployed in 5 large service providers, so would like to
    expedite this
Lou: Slide Back to Slide3:
     For the item on charter - missing is ASON.
     What do we do about alignment, and that we have two versions of
     RSVP? There is only one version of GMPLS, what do we need to do?
     What steps that we need to take as a WG?
Alex: ASON is on our charter
Lou: It's on charter - we have completed our documents.
     We can send to SG15, but what do we do from there to align GMPLS and
     ASON solutions?
Adrian: Added it to slides
Richard: On recent new topics - do we know what is in-charter currently?
Alex: It is up to chairs:
Adrian: If it is in the scope of the charter, we will do milestones
        There will be discussion on the list.
Dimitri: Why is "deployment considerations" considered marginal?
         If you want feedback, how can this be classified as marginal?
         Please prioritize and please discuss.
Adrian: This is from the community view gathered on the list last year
Dimitri: Then how will we have deployment
Kireeti: You can do canvassing to get people to discuss.
         We will take back to the list to do a poll again
------------------

------------------
12) GMPLS for Ethernet - Dimitri Papadimitriou

Reviewed slides
Define a set of scenarios:
4 Scenarios
-Aggregation
-Metro
-Unified? Core
-Transport
Dimitri asked if interest to do this work
------------------
Don Fedyk: We still don't know what is actually meant by GMPLS
           Ethernet. The document does not go far enough today
           with enough detail. The document is too open ended and
           we don't know what exactly is being specified. I asked
           for more detailed specification.
Dimitri: <Nodded>
Ali Sajassi: Ethernet differs from other data planes as it's not point
             to point. Do you want to keep it as in the perspective of
             IEEE?
             Other comments: you want to replace existing Ethernet
             control plane with GMPLS: again how will you do multipoint?
             Shortest path may overlap with issues discussed in TRILL.
             How are you going to coordinate with other WGs?
Loa: Not speaking for the DT as we didn't discuss it: I have experience
     running a medium/large scale Ethernet network as a point-to-point
     network (unified/core). It would be very applicable to add a gmpls
     control plane.
     Note that if we can't do it as a standard we (deployers) will do
     it ourselves. It is pretty straight forward.
Ali: I can see for point to point, it's for multipoint that I see it
     will have issues
Dimitri: OK. Can you input specifics? This said these questions are
         relevant but the scope (of the document) has been restricted
         to point-to-point. The issues on how we coordinate and
         potentially overlap with other working groups must also be
         addressed (implicitly: if we decide to move forward with this
         item.)
Richard Spencer: Can you confirm that using GMPLS in enterprise is out
                 of scope?
Dimitri: As no one has expressed interest I would say it is out of scope
Richard S: Will there be any changes to Ethernet control/data plane?
           What would be the potential difficulties?
           Have a discussion with the IEEE and see where they would be
           impacted.
Dimitri: I can not say what will be the solution chosen, we already
         suggested we work with IEEE to assess impact
Richard S: I see little value for aggregation.
           I don't see in metro why a provider would want to use this
           instead of VPLS
Dimitri: I have replied to some of the issues you are currently raising
         on the list. If further clarification required we should
         discuss them on the list.
Kireeti: We will not change the Ethernet data plane here. If we conclude
         it may need to be changed, we will liaise to IEEE and get their
         agreement.
         CCAMP is focused on core tunneling technologies, though we
         don't say how you will use them - metro or core - I would like
         us to continue not to be specific for access or core. If
         there is anything specifically different for access, then need
         to add to charter.
Lyndon: There is a lot of interest in other groups (ITU, OIF, MEF).
        I think there is interest. Where people are uncertain is how.
        Need to look at more on supporting pt to pt or multipt.
Don O'Conner: How does this differ from l2vpn?
Dimitri: As explained in the introduction of the problem statement
         document it differs from the forwarding which is not based
         on packet header (as in MPLS) but based on the Layer-2 frame
         header.
Kireeti: L2VPON charter is different. L2VPN sets up vpns.
         This work is on signaling and routing in Ethernet networks.
Tom Nadeau: Is this in the scope of CCAMP today?
Adrian: Yes this is in the scope as a core network.
        GMPLS handles packet transport networks.
        Maybe this is could be a new working group.
        Note, however, that changes to the data plane are not in
        scope for CCAMP and would require action by other SDOs,
        in this case IEEE.
Tom: Seems similar to TRILL.
Adrian: Yes. Need to determine if there is overlap. Perhaps this work
        should go there. Alternatively, perhaps this work goes in a new
        WG.
Dimitri: Some of these items such as the difference with TRILL have
         been discussed on the mailing list.
Loa: Trill is in campus networks.
Alex: For structuring this work, we need to be very clear what data path
      modifications need to be done. Should communicate with IEEE
      liaison, preferably before BOF.
      TRILL working group is a specific example.
Dimitri: What would be the way to contact the IEEE to do this?
         Is there a liaison with IEEE that we can make use of?
Alex: We have an established liaison relationship with IEEE.
Dimitri: OK, we will enter in contact with the liaison representative.
Kireeti: First need to decide if we need a change in the data plane.
         Then talk to the IEEE.
Adrian: Also need to tell IEEE what we plan to do, no matter how we do
        it.
<Marcus? Michael?> Smith: There are limits to the use of VLAN-ID.
        There are only 4K of them. Will you use this as the label?
Adrian: We haven't decided anything about how forwarding will occur yet
Dinesh Mohan: I haven't heard yet that there is planned a change to the
              data plane. Need to understand better.
              Should look at this as a new control plane using existing
              data plane.
              It would be nice to have the GMPLS Control plane but is
              there no intent to change the control plane?  The basic
              assumption is that you have a different control plane
              then that should be the assumption.
              This is fine to explore, but the starting point is not to
              modify the data plane.
Adrian: When we control SDH we did not mess with the data plane. We
        should not be modifying the transport technology.
Monique Morrow: Echo what Alex said, any modification we need to talk
                to the IEEE.
Dimitri: OK, but we are not talking in the context that there is a
         change to data plane.
Ali: Trill and this are using ISIS. Trill plan to change the data
     plane.
Kireeti: Please stop, take to list.
Ali: Several vendors offer Ethernet switches that offer point to
     point using MPLS control plane supporting millions of
     connections.
Yakov: How? Could you tell me whether they carry a label?
Ali: Yes. They are MPLS switches
Yakov: So it is a router, an LSR , that you can call an Ethernet
       switch and you are done?
Adrian: That is indeed a suggestion.
Don O'C: Ethernet is connectionless and now GMPLS is connection-
         oriented, so this is different.
         This is redefining Ethernet to make it connection oriented.
         Is that the intent?
         Is this making VLAN tags look like GMPLS labels?
Adrian: Again, this has not been discussed
Loa: From experience, we don't want to remove VLAN tags. Need something
     else. And the chairs said to the design team not to do that, yet
     80% of CCAMP are already assuming this is what we want to do.
Adrian: Design team job is done - Thanks.
        We need now for the WG to discuss.
------------------

Time is over. Other drafts that we didn't get to discuss, take to list.




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Aug 2005 15:34:33 +0000
Message-ID: <093501c59e8a$626f8b80$08849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: ASON Routing evaluation ready for WG last call?
Date: Thu, 11 Aug 2005 16:31:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt

The DT said in Paris that this I-D is cooked apart from "some minor
editing".

I asked the room if anyone would object to a WG last call now, and Alex
(as AD) suggested that more people should read the I-D before we decided
whether it was ready for last call.

This gives me the odd position of having a last call for a last call :-)

This email gives notice that you need to read this I-D and make comments
before 11th September 2005.

Barring unresolved comments we will have a WG last call starting then.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Aug 2005 12:41:54 +0000
Message-ID: <08c901c59e72$56e425e0$08849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Responding to the OIF
Date: Thu, 11 Aug 2005 13:42:56 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_08C6_01C59E7A.94425120"

This is a multi-part message in MIME format.

------=_NextPart_000_08C6_01C59E7A.94425120
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

As Lyndon noted in Paris, the OIF has sent us a communication requesting =
some guidance on a bunch of questions.

This is to start the business of constructing a reply. thanks to Dimitri =
for supplying some of this text.

Please send comments and improvements.

Adrian

=3D=3D=3D=3D=3D=3D

To: Jim Jones, OIF Technical Committee Chair
From: Adrian Farrel and Kireeti Kompella,=20
          WG Co-Chairs for IETF CCAMP
Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors
Subject: Response to your questions about GMPLS parameters.

Dear Jim,

Thanks for your correspondence about the questions with respect to GMPLS =
parameters that arose before and during your interoperability testing. =
CCAMP is pleased to receive such questions and is glad to have the =
opportunity to explain the intended operation of the GMPLS protocols.

Much of the material supplied below can be simply extracted from the =
relevant RFCs.


> 1. Use of the NCC and RCC fields for STS-3c/VC-4 connections
>=20
> During OIF testing it was noted that some ambiguity exists in the
> specification of encoding of NCC, RCC and NVC for certain types of
> connections: NCC and RCC for an STS-3c/VC-4 connection can be set to 0 =
or
> to 1 depending on which example of RFC 3946 is followed.
>=20
> Clarification is requested from IETF CCAMP as to which setting is
> considered correct, or if both settings should be accepted (this =
procedure
> was used during testing at Supercomm).

This question about RFC 3946 was raised informally on the CCAMP mailing =
list at the start of March this year.=20

Even when the signal Type value is the same (i.e. value 6) the NCC, RCC =
and NVC values depend on the specific signal being requested.

>From the examples in the annex we have...

   A VC-4 signal is formed by applying the following
   settings to a VC-4 Elementary Signal.
      RCC =3D 0
      NCC =3D 0
      NVC =3D 0
      MT  =3D 1
      T   =3D 0

   An STS-3c SPE signal is formed by applying the following
   settings to an STS-3c SPE Elementary Signal.
      RCC =3D 1 (standard contiguous concatenation)
      NCC =3D 1
      NVC =3D 0
      MT  =3D 1
      T   =3D 0

Your question probably arises from the two notes and subsequent =
paragraph in section 2.1 or RFC 3946. Here it says...

   Note 1: when requesting a SONET STS-Nc SPE with N=3D3*X, the
      Elementary Signal to use must always be an STS-3c_SPE signal type
      and the value of NCC must always be equal to X.  This allows also
      facilitating the interworking between SONET and SDH.  In
      particular, it means that the contiguous concatenation of three
      STS-1 SPEs can not be requested because according to this
      specification, this type of signal must be coded using the STS-3c
      SPE signal type.

   Note 2: when requesting a transparent STS-N/STM-N signal
      limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc,
      the signal type must be STS-N/STM-N, RCC with flag 1 and NCC set
      to 1.

   The NCC value must be consistent with the type of contiguous
   concatenation being requested in the RCC field.  In particular, this
   field is irrelevant if no contiguous concatenation is requested (RCC
   =3D 0), in that case it must be set to zero when sent, and should be
   ignored when received.  A RCC value different from 0 must imply a
   number of contiguous components greater than 1.

We believe that this final sentence should read "greater than or equal =
to 1," and that this interpretation resolves all of your issues and =
makes the text consistent with the examples.

> 2. Setting of NVC for VCAT connections
>=20
> It was also noted that the setting of NVC may be somewhat ambiguous =
for
> the case where diverse connections are used within a single VCAT =
group.
> Each individual RSVP session controls a single connection, but the
> connection is part of a larger VCAT group and carries VCAT encoding of =
the
> H4 byte. Clarification is requested from IETF CCAMP and ITU-T Q.14/15 =
as
> to the correct setting of NVC for this case (0 or 1?). It should be =
noted
> that this case may occur with a VCAT group with only a single initial
> member, and that the NVC may provide an indication that VCAT encoding =
of
> the H4 byte is in use for the connection.

A VCn-Xv group split into X components requires each of its component to =
be signaled with the NVC value set to 1. This setting is regardless of =
how the components are established.

> 3. Length of the Interface Switching Capability TLV
>=20
> Although the Interface Switching Capability TLV defined by CCAMP for
> SONET/SDH connections was not used for the testing, it was noted that =
the
> text describing the length of the Interface Switching Capability TLV
> defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be =
slightly
> ambiguous due to the use of padding bytes.
>=20
> RFC 3630 states that "The TLV is padded to four-octet alignment; =
padding
> is not included in the length field (so a three octet value would have =
a
> length of three, but the total size of the TLV would be eight =
octets)."

Yes. Section 2.3.2 of RFC3630 gives a definitive statement of the =
meaning of the length field and the use of padding, and provides an =
example.

> Reading of the encoding in =
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
> specifies that the length of the TLV for TDM is 41 bytes plus 3 bytes =
of
> padding, and should be given in the length field as 41 bytes rather =
than
> 44. OIF requests verification of this interpretation from the experts =
in
> IETF CCAMP group.

Note that the Interface Switching Capability Descriptor defined in =
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link =
TLV. Sub-TLVs and TLVs follow the same encoding rules.

The ISCD TLV for TDM contains the following fields...
  type       2 bytes
  length     2 bytes
  ---
  switch cap 1 byte
  encoding   1 byte
  reserve    2 bytes
  LSP b/w 0  4 bytes
  LSP b/w 1  4 bytes=20
  LSP b/w 2  4 bytes=20
  LSP b/w 3  4 bytes=20
  LSP b/w 4  4 bytes=20
  LSP b/w 5  4 bytes=20
  LSP b/w 6  4 bytes=20
  LSP b/w 7  4 bytes
  min b/w    4 bytes
  indication 1 byte
            =3D=3D
            41 bytes

We presume that your question relates to whether the 3-byte field shown =
as "padding" in the TDM-specific figure on page 6 of =
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an =
explicit field.

It is an implicit field, and should not be included in the length of the =
TLV.

Nevertheless, we take this opportunity to remind the OIF that =
implementations of GMPLS protocols should be conservative in what they =
send and liberal in what they receive. Thus, an implementation that =
receives a TDM ISCD TLV with length 44 should not reject the TLV for =
this reason. It should parse the TLV according to the defined fields and =
skip the final three bytes. Thus, it should not affect a receiving =
implementation if the sending implementation has treated the "padding" =
field as implicit or explicit. In the event that a receiving =
implementation rejected such a TLV on grounds of the value contained in =
the length field being too large, the fault would lie with the receiving =
implementation not the sending implementation.

> 4. Use of ADMIN_STATUS in an initial PATH message
>=20
> Some implementations sent an ADMIN_STATUS object with no flags set in =
the
> initial PATH message, i.e., when no status change was being requested.
> Although this did not serve any particular function, it was believed =
that
> this could be accepted as RFC3473, sect. 7.2 (page 18) states:
>=20
> "The absence of the object is equivalent to receiving an object =
containing
> values all set to zero (0)."
>=20
> It was our interpretation based on this text that a node should accept =
an
> ADMIN_STATUS object with no flags set in the same way as if the object =
was
> missing. Comment on this interpretation is welcome.

The effect of the meaning is as you state, but the intention of the =
meaning is reversed. That is, an implementation should accept the =
absence of the ADMIN_STATUS object in the same way as if the object was =
present with no flags set. That is, the default behavior is to consider =
the ADMIN_STATUS object as a standard part of the processing.

We note from your first paragraph that you assume that the ADMIN_STATUS =
object is used to change the status of the LSP. This is a =
misinterpretation - it is used to control the status of the LSP. Thus, =
if there is no change to the status of an LSP, refresh messages must =
continue to carry the ADMIN_STATUS object with the same bit setting.

In this way, it is not possible to "drop" the ADMIN_STATUS object =
without having the same meaning as transmitting the object with all bits =
cleared.

> 5. Handling of multiple received ResvConf Request objects
>=20
> When a connection desires a confirmation that the service (i.e.
> connection) requested is in place, a RESV_CONF_REQ object is included =
in
> the RESV message. As this object is received by the remote end of the
> reservation, it will send a RESV_CONF message back to the requester.
>=20
> However, it is unclear whether it is necessary to send a RESV_CONF =
message
> when the RSVP connection state is refreshed by subsequent RESV. This
> becomes potentially burdensome, especially when the reservation is =
being
> rapidly refreshed. Therefore we ask: should the remote end send a
> RESV_CONF message for subsequent RESV messages that still include the
> RESV_CONF_REQ object? Or is it required that the requestor of the
> reservation remove the RESV_CONF_REQ object to prevent the generation =
of
> further RESV_CONF messages? Comment on this issue from IETF CCAMP is
> requested.

It is fundamental to the implementation of RSVP-TE that there is a good =
understanding of the distinction between a trigger message and a refresh =
message. This can be achieved by reading section 1.1 of RFC2961.

Following this understanding, you will note that a refresh message does =
not cause any processing to be performed at the LSR that receives it (in =
this case the ingress). You will also note that refresh processing is =
not end-to-end as implied in your text, but is hop-by-hop.

Thus, an downstream LSR that wishes to trigger a new ResvConf message =
must make a specific change to the content of the Resv message that it =
sends in order to cause a trigger message to be propagated through the =
network to the ingress LSR. Such processing is implementation specific.

> 6. Symmetry of Refresh Reduction usage
>=20
> During interop testing, we ran into a conflict caused by varying
> interpretations of RFC2961, regarding the use of SRefresh messages and =
the
> Refresh Reduction capabilities of the two ends of a given link. One
> interpretation of RFC2961 indicates that setting the Refresh Reduction
> Capability flag in the RSVP header indicates that that interface shall =
be
> capable of receiving messages related to Refresh Reduction - including =
the
> SRefresh message. This would be true even if the other end of the link =
for
> that interface were NOT indicating Refresh Reduction Capability, since =
the
> RFC makes no statement about symmetry in this matter.
>=20
> Another interpretation is that both ends of an interface must indicate
> Refresh Reduction Capability before either end can use such messages, =
i.e,
> use of Refresh Reduction on a link is symmetric.
>=20
> Comment from CCAMP WG on the correct interpretation is requested.

We are confused by your question.
You correctly state that the use of the refresh-reduction-capable bit =
indicates the ability of an LSR to support the receipt of refresh =
reduction options and messages. To quote from section 2 of RFC2961...
           When set, indicates that this node is willing and capable of
           receiving all the messages and objects described in this
           document.  This includes the Bundle message described in
           Section 3, the MESSAGE_ID objects and Ack messages described
           in Section 4, and the MESSAGE_ID LIST objects and Srefresh
           message described in Section 5.  This bit is meaningful only
           between RSVP neighbors.
This makes no statement about whether the LSR intends to use these =
options when communicating with another LSR.=20

However, you will note that some refresh reduction procedures require =
that a message is sent and response returned. In order to make use of =
the response, the receiver must be capable of receiving and processing =
the response. Thus, it would be usual for an LSR that is capable of =
sending refresh reduction options and messages to also set the =
refresh-reduction-capable bit.

In summary:
- An LSR must not send refresh reduction options or messages=20
  to an LSR that is not setting the refresh-reduction-capable=20
  bit.
- An LSR may send refresh reduction options or messages =20
  to an LSR that is setting the refresh-reduction-capable bit.
- An LSR that wishes to successfully use responded refresh=20
  reduction options or messages should set the refresh-
  reduction-capable bit.

Note, finally, that section 2 of RFC 2961 states that "When it is not =
known if a next hop supports the extension, standard Path and Resv =
message based refreshes MUST be used."

> 7. Sending of ACKs bundled with the RSVP HELLO
>=20
> During interop testing, it was observed that Message Acks were =
piggybacked
> onto RSVP Hello messages, when the receiving end was not using the =
Hello
> protocol. In this situation, the incoming Hello's were discarded and =
the
> Acks were lost.
>=20
> We believe that Message Acks should only be piggybacked onto mandatory
> messages, and not on Hello messages because of this problem. Comment =
on
> this interpretation is requested.

You use of the terms "bundled" and "piggybacked" are contradictory.

"Bundled" implies the use of the Bundle message.
RFC 2961 states...
   A sub-message MAY be any message type except for another=20
   Bundle message.
Thus, Ack messages may be bundled with other messages. (Although one =
might consider this perverse since the Ack message is only introduced to =
handle the case when the Ac/Nack objects have no other message on which =
they can be carried.)

Further, RFC 3209 states...
   A Hello message may be included
   as a sub-message within a bundle message.

Therefore, it acceptable for a Ack and Hello messages to be bundled =
together.
The processing rules (RFC 29610 for Bundled messages are such that each =
sub-message is processed in its own right, and the non-support/non-use =
of Hello messages should not impact the processing of other messages.

On the other hand, "piggybacked" implies the use of the Ack/Nack objects =
within a Hello message.

Section 4.1 of RFC2961 states that Ack/Nack objects may be included in =
the "standard" RSVP messages, and shows where they are placed. However, =
RFC 3209 defines the Hello message as not including the Ack/Nack =
objects...

   <Hello Message> ::=3D <Common Header> [ <INTEGRITY> ]
                              <HELLO>

Since RFC 3209 post-dates RFC 2961, this definition is definitive and =
the Ack/Nack objects should not be present on the Hello message.

Give that section 5.3 of RFC 3209 states...
   The Hello Message is completely OPTIONAL.  All messages may be
   ignored by nodes which do not wish to participate in Hello message
   processing.
...it is not particularly important what the message format rules are. =
An implementation that chooses to place an Ack/Nack object in a Hello =
message knows that the object might be discarded unprocessed.

> 8. TSPEC format to be used for Ethernet connections

The CCAMP working group is currently discussing the use of GMPLS for =
control of Ethernet devices. We will respond to this point in a separate =
email.

Best regards,
Adrian Farrel
Kireeti Kompella
------=_NextPart_000_08C6_01C59E7A.94425120
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT face=3DCourier size=3D2>Hi,<BR><BR>As Lyndon noted in Paris, =
the OIF has=20
sent us a communication requesting some guidance on a bunch of=20
questions.<BR><BR>This is to start the business of constructing a reply. =
thanks=20
to Dimitri for supplying some of this text.<BR><BR>Please send comments =
and=20
improvements.<BR><BR>Adrian<BR><BR>=3D=3D=3D=3D=3D=3D<BR><BR>To: Jim =
Jones, OIF Technical=20
Committee Chair<BR>From: Adrian Farrel and Kireeti Kompella,=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WG Co-Chairs =
for IETF=20
CCAMP<BR>Copy: Alex Zinin and Bill Fenner, IETF Routing Area=20
Directors<BR>Subject: Response to your questions about GMPLS=20
parameters.<BR><BR>Dear Jim,<BR><BR>Thanks for your correspondence about =
the=20
questions with respect to GMPLS parameters that arose before and during =
your=20
interoperability testing. CCAMP is pleased to receive such questions and =
is glad=20
to have the opportunity to explain the intended operation of the GMPLS=20
protocols.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Much of the material supplied below =
can be simply=20
extracted from the relevant RFCs.</DIV>
<DIV><BR><BR>&gt; 1. Use of the NCC and RCC fields for STS-3c/VC-4=20
connections<BR>&gt; <BR>&gt; During OIF testing it was noted that some =
ambiguity=20
exists in the<BR>&gt; specification of encoding of NCC, RCC and NVC for =
certain=20
types of<BR>&gt; connections: NCC and RCC for an STS-3c/VC-4 connection =
can be=20
set to 0 or<BR>&gt; to 1 depending on which example of RFC 3946 is=20
followed.<BR>&gt; <BR>&gt; Clarification is requested from IETF CCAMP as =
to=20
which setting is<BR>&gt; considered correct, or if both settings should =
be=20
accepted (this procedure<BR>&gt; was used during testing at=20
Supercomm).<BR><BR>This question about RFC 3946 was raised informally on =
the=20
CCAMP mailing list at the start of March this year. <BR><BR>Even when =
the signal=20
Type value is the same (i.e. value 6) the NCC, RCC and NVC values depend =
on the=20
specific signal being requested.<BR><BR>From the examples in the annex =
we=20
have...<BR><BR>&nbsp;&nbsp; A VC-4 signal is formed by applying the=20
following<BR>&nbsp;&nbsp; settings to a VC-4 Elementary=20
Signal.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RCC =3D=20
0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NCC =3D =
0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
NVC =3D 0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MT&nbsp; =3D=20
1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T&nbsp;&nbsp; =3D =
0<BR><BR>&nbsp;&nbsp; An=20
STS-3c SPE signal is formed by applying the following<BR>&nbsp;&nbsp; =
settings=20
to an STS-3c SPE Elementary Signal.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RCC =3D 1=20
(standard contiguous concatenation)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
NCC =3D=20
1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NVC =3D =
0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
MT&nbsp; =3D 1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T&nbsp;&nbsp; =3D =
0<BR><BR>Your=20
question probably arises from the two notes and subsequent paragraph in =
section=20
2.1 or RFC 3946. Here it says...<BR><BR>&nbsp;&nbsp; Note 1: when =
requesting a=20
SONET STS-Nc SPE with N=3D3*X, the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Elementary=20
Signal to use must always be an STS-3c_SPE signal=20
type<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and the value of NCC must always =
be equal=20
to X.&nbsp; This allows also<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
facilitating the=20
interworking between SONET and SDH.&nbsp; =
In<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
particular, it means that the contiguous concatenation of=20
three<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; STS-1 SPEs can not be requested =
because=20
according to this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specification, this =
type of=20
signal must be coded using the STS-3c<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SPE=20
signal type.<BR><BR>&nbsp;&nbsp; Note 2: when requesting a transparent=20
STS-N/STM-N signal<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; limited to a single =

contiguously concatenated =
STS-Nc_SPE/VC-4-Nc,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
the signal type must be STS-N/STM-N, RCC with flag 1 and NCC=20
set<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to 1.<BR><BR>&nbsp;&nbsp; The NCC =
value=20
must be consistent with the type of contiguous<BR>&nbsp;&nbsp; =
concatenation=20
being requested in the RCC field.&nbsp; In particular, =
this<BR>&nbsp;&nbsp;=20
field is irrelevant if no contiguous concatenation is requested=20
(RCC<BR>&nbsp;&nbsp; =3D 0), in that case it must be set to zero when =
sent, and=20
should be<BR>&nbsp;&nbsp; ignored when received.&nbsp; A RCC value =
different=20
from 0 must imply a<BR>&nbsp;&nbsp; number of contiguous components =
greater than=20
1.<BR><BR>We believe that this final sentence should read "greater than =
or equal=20
to 1," and that this interpretation resolves all of your issues and =
makes the=20
text consistent with the examples.<BR><BR>&gt; 2. Setting of NVC for =
VCAT=20
connections<BR>&gt; <BR>&gt; It was also noted that the setting of NVC =
may be=20
somewhat ambiguous for<BR>&gt; the case where diverse connections are =
used=20
within a single VCAT group.<BR>&gt; Each individual RSVP session =
controls a=20
single connection, but the<BR>&gt; connection is part of a larger VCAT =
group and=20
carries VCAT encoding of the<BR>&gt; H4 byte. Clarification is requested =
from=20
IETF CCAMP and ITU-T Q.14/15 as<BR>&gt; to the correct setting of NVC =
for this=20
case (0 or 1?). It should be noted<BR>&gt; that this case may occur with =
a VCAT=20
group with only a single initial<BR>&gt; member, and that the NVC may =
provide an=20
indication that VCAT encoding of<BR>&gt; the H4 byte is in use for the=20
connection.<BR><BR>A VCn-Xv group split into X components requires each =
of its=20
component to be signaled with the NVC value set to 1. This setting is =
regardless=20
of how the components are established.<BR><BR>&gt; 3. Length of the =
Interface=20
Switching Capability TLV<BR>&gt; <BR>&gt; Although the Interface =
Switching=20
Capability TLV defined by CCAMP for<BR>&gt; SONET/SDH connections was =
not used=20
for the testing, it was noted that the<BR>&gt; text describing the =
length of the=20
Interface Switching Capability TLV<BR>&gt; defined in=20
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly<BR>&gt; =
ambiguous=20
due to the use of padding bytes.<BR>&gt; <BR>&gt; RFC 3630 states that =
"The TLV=20
is padded to four-octet alignment; padding<BR>&gt; is not included in =
the length=20
field (so a three octet value would have a<BR>&gt; length of three, but =
the=20
total size of the TLV would be eight octets)."</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Yes. Section 2.3.2 of RFC3630 gives a =
definitive=20
statement of the meaning of the length field and the use of padding, and =

provides an example.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV>
<DIV>&gt; Reading of the encoding in=20
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt<BR>&gt; specifies that the =
length=20
of the TLV for TDM is 41 bytes plus 3 bytes of<BR>&gt; padding, and =
should be=20
given in the length field as 41 bytes rather than<BR>&gt; 44. OIF =
requests=20
verification of this interpretation from the experts in<BR>&gt; IETF =
CCAMP=20
group.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Note that the Interface Switching Capability Descriptor defined in=20
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link =
TLV.=20
Sub-TLVs and TLVs follow the same encoding rules.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The ISCD TLV for TDM contains the following fields...</DIV>
<DIV>&nbsp; type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2 bytes</DIV>
<DIV>&nbsp; length&nbsp;&nbsp;&nbsp;&nbsp; 2 bytes</DIV>
<DIV>&nbsp;&nbsp;---</DIV>
<DIV>&nbsp;&nbsp;switch cap 1 byte</DIV>
<DIV>&nbsp;&nbsp;encoding&nbsp;&nbsp;&nbsp;1 byte</DIV>
<DIV>&nbsp; reserve&nbsp;&nbsp;&nbsp; 2 bytes</DIV>
<DIV>&nbsp;&nbsp;LSP b/w 0&nbsp; 4 bytes</DIV>
<DIV>
<DIV>&nbsp;&nbsp;LSP b/w 1&nbsp; 4 bytes=20
<DIV>&nbsp;&nbsp;LSP b/w 2&nbsp; 4 bytes=20
<DIV>&nbsp;&nbsp;LSP b/w 3&nbsp; 4 bytes=20
<DIV>&nbsp;&nbsp;LSP b/w 4&nbsp; 4 bytes=20
<DIV>&nbsp;&nbsp;LSP b/w 5&nbsp; 4 bytes=20
<DIV>&nbsp;&nbsp;LSP b/w 6&nbsp; 4 bytes=20
<DIV>&nbsp;&nbsp;LSP b/w 7&nbsp; 4=20
bytes</DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV>
<DIV>&nbsp;&nbsp;min&nbsp;b/w&nbsp;&nbsp;&nbsp;&nbsp;4 bytes</DIV>
<DIV>&nbsp;&nbsp;indication&nbsp;1=20
byte<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=3D=3D</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;41=20
bytes</DIV>
<DIV>&nbsp;</DIV>
<DIV>We presume that your question relates to whether the 3-byte field =
shown as=20
"padding" in the TDM-specific figure on page 6 of=20
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an =
explicit=20
field.</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is an implicit field, and should not be included in the length =
of the=20
TLV.</DIV></FONT>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Nevertheless, we take this =
opportunity to remind=20
the OIF that implementations of GMPLS protocols should be conservative =
in what=20
they send and liberal in what they receive. Thus, an implementation that =

receives a TDM ISCD TLV with length 44 should not reject the TLV for =
this=20
reason. It should parse the TLV according to the defined fields and skip =
the=20
final three bytes. Thus, it should not affect a receiving implementation =
if the=20
sending implementation has treated the "padding" field as implicit or =
explicit.=20
In the event that a receiving implementation rejected such a TLV on =
grounds of=20
the value contained in the length field being too large, the fault would =
lie=20
with the receiving implementation not the sending =
implementation.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; 4. Use of ADMIN_STATUS in an =
initial PATH=20
message<BR>&gt; <BR>&gt; Some implementations sent an ADMIN_STATUS =
object with=20
no flags set in the<BR>&gt; initial PATH message, i.e., when no status =
change=20
was being requested.<BR>&gt; Although this did not serve any particular=20
function, it was believed that<BR>&gt; this could be accepted as =
RFC3473, sect.=20
7.2 (page 18) states:<BR>&gt; <BR>&gt; "The absence of the object is =
equivalent=20
to receiving an object containing<BR>&gt; values all set to zero =
(0)."<BR>&gt;=20
<BR>&gt; It was our interpretation based on this text that a node should =
accept=20
an<BR>&gt; ADMIN_STATUS object with no flags set in the same way as if =
the=20
object was<BR>&gt; missing. Comment on this interpretation is=20
welcome.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The effect of the meaning is as you =
state, but=20
the intention of the meaning is reversed. That is, an implementation =
should=20
accept the absence of the ADMIN_STATUS object in the same way as if the =
object=20
was present with no flags set. That is, the default behavior is to =
consider the=20
ADMIN_STATUS object as a standard part of the processing.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>We note from your first paragraph =
that you assume=20
that the ADMIN_STATUS object is used to change the status of the LSP. =
This is a=20
misinterpretation - it is used to control the status of the LSP. Thus, =
if there=20
is no change to the status of an LSP, refresh messages must continue to =
carry=20
the ADMIN_STATUS object with the same bit setting.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>In this way, it is not possible to =
"drop" the=20
ADMIN_STATUS object without having the same meaning as transmitting the =
object=20
with all bits cleared.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; 5. Handling of multiple received =
ResvConf=20
Request objects<BR>&gt; <BR>&gt; When a connection desires a =
confirmation that=20
the service (i.e.<BR>&gt; connection) requested is in place, a =
RESV_CONF_REQ=20
object is included in<BR>&gt; the RESV message. As this object is =
received by=20
the remote end of the<BR>&gt; reservation, it will send a RESV_CONF =
message back=20
to the requester.<BR>&gt; <BR>&gt; However, it is unclear whether it is=20
necessary to send a RESV_CONF message<BR>&gt; when the RSVP connection =
state is=20
refreshed by subsequent RESV. This<BR>&gt; becomes potentially =
burdensome,=20
especially when the reservation is being<BR>&gt; rapidly refreshed. =
Therefore we=20
ask: should the remote end send a<BR>&gt; RESV_CONF message for =
subsequent RESV=20
messages that still include the<BR>&gt; RESV_CONF_REQ object? Or is it =
required=20
that the requestor of the<BR>&gt; reservation remove the RESV_CONF_REQ =
object to=20
prevent the generation of<BR>&gt; further RESV_CONF messages? Comment on =
this=20
issue from IETF CCAMP is<BR>&gt; requested.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>It is fundamental to =
the&nbsp;implementation of=20
RSVP-TE that there is a good understanding of the distinction between a =
trigger=20
message and a refresh message. This can be achieved by reading section =
1.1 of=20
RFC2961.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Following this understanding, you =
will note that=20
a refresh message does not cause any processing to be performed at the =
LSR that=20
receives it (in this case the ingress). You will also note that refresh=20
processing is not end-to-end as implied in your text, but is=20
hop-by-hop.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thus, an downstream LSR that wishes =
to trigger a=20
new ResvConf message must make a specific change to the content of the =
Resv=20
message that it sends in order to cause a trigger message to be =
propagated=20
through the network to the ingress LSR. Such processing is =
implementation=20
specific.</DIV>
<DIV><BR>&gt; 6. Symmetry of Refresh Reduction usage<BR>&gt; <BR>&gt; =
During=20
interop testing, we ran into a conflict caused by varying<BR>&gt;=20
interpretations of RFC2961, regarding the use of SRefresh messages and=20
the<BR>&gt; Refresh Reduction capabilities of the two ends of a given =
link.=20
One<BR>&gt; interpretation of RFC2961 indicates that setting the Refresh =

Reduction<BR>&gt; Capability flag in the RSVP header indicates that that =

interface shall be<BR>&gt; capable of receiving messages related to =
Refresh=20
Reduction - including the<BR>&gt; SRefresh message. This would be true =
even if=20
the other end of the link for<BR>&gt; that interface were NOT indicating =
Refresh=20
Reduction Capability, since the<BR>&gt; RFC makes no statement about =
symmetry in=20
this matter.<BR>&gt; <BR>&gt; Another interpretation is that both ends =
of an=20
interface must indicate<BR>&gt; Refresh Reduction Capability before =
either end=20
can use such messages, i.e,<BR>&gt; use of Refresh Reduction on a link =
is=20
symmetric.<BR>&gt; <BR>&gt; Comment from CCAMP WG on the correct =
interpretation=20
is requested.</DIV>
<DIV>&nbsp;</DIV>
<DIV>We are confused by your question.</DIV>
<DIV>You correctly state that the use of the refresh-reduction-capable =
bit=20
indicates the ability of an LSR to support the receipt of refresh =
reduction=20
options and messages. To quote from section 2 of RFC2961...</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When =
set,=20
indicates that this node is willing and capable=20
of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
receiving all=20
the messages and objects described in=20
this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
document.&nbsp; This includes the Bundle message described=20
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Section 3,=20
the MESSAGE_ID objects and Ack messages=20
described<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 in=20
Section 4, and the MESSAGE_ID LIST objects and=20
Srefresh<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
message=20
described in Section 5.&nbsp; This bit is meaningful=20
only<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
between=20
RSVP neighbors.<BR>This makes no statement about whether the LSR intends =
to use=20
these options when communicating with another LSR. </DIV>
<DIV>&nbsp;</DIV>
<DIV>However, you will note that some refresh reduction procedures =
require that=20
a message is sent and response returned. In order to make use of the =
response,=20
the receiver must be capable of receiving and processing the response. =
Thus, it=20
would be usual for an LSR that is capable of sending refresh reduction =
options=20
and messages to also set the refresh-reduction-capable bit.</DIV>
<DIV>&nbsp;</DIV>
<DIV>In summary:</DIV>
<DIV>- An LSR must not&nbsp;send refresh reduction options or=20
messages&nbsp;</DIV>
<DIV>&nbsp; to an LSR that is not setting the refresh-reduction-capable =
</DIV>
<DIV>&nbsp; bit.</DIV>
<DIV>- An LSR may send refresh reduction options or messages&nbsp;=20
<DIV>&nbsp; to an LSR that is&nbsp;setting the refresh-reduction-capable =

bit.</DIV>
<DIV>- An LSR that wishes to successfully use responded refresh </DIV>
<DIV>&nbsp; reduction options&nbsp;or messages should set the =
refresh-</DIV>
<DIV>&nbsp; reduction-capable bit.</DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>Note, finally, that section 2 of RFC 2961&nbsp;states that "When it =
is not=20
known if a next hop supports the extension, standard Path and Resv =
message based=20
refreshes MUST be used."<BR></DIV>
<DIV>&gt; 7. Sending of ACKs bundled with the RSVP HELLO<BR>&gt; =
<BR>&gt; During=20
interop testing, it was observed that Message Acks were =
piggybacked<BR>&gt; onto=20
RSVP Hello messages, when the receiving end was not using the =
Hello<BR>&gt;=20
protocol. In this situation, the incoming Hello's were discarded and =
the<BR>&gt;=20
Acks were lost.<BR>&gt; <BR>&gt; We believe that Message Acks should =
only be=20
piggybacked onto mandatory<BR>&gt; messages, and not on Hello messages =
because=20
of this problem. Comment on<BR>&gt; this interpretation is =
requested.</DIV>
<DIV>&nbsp;</DIV>
<DIV>You use of the terms "bundled" and "piggybacked" are =
contradictory.</DIV>
<DIV>&nbsp;</DIV>
<DIV>"Bundled" implies the use of the Bundle message.</DIV>
<DIV>RFC 2961 states...</DIV>
<DIV>&nbsp;&nbsp; A&nbsp;sub-message MAY be any message type except for =
another=20
</DIV>
<DIV>&nbsp;&nbsp; Bundle&nbsp;message.</DIV>
<DIV>Thus, Ack messages may be bundled with other messages. (Although =
one might=20
consider this perverse since the Ack message is only introduced to =
handle the=20
case when the Ac/Nack objects have no other message on which they can be =

carried.)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Further, RFC 3209 states...</DIV>
<DIV>&nbsp;&nbsp; A Hello message may be included<BR>&nbsp;&nbsp; as a=20
sub-message within a bundle message.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Therefore, it acceptable for a Ack and Hello messages to be bundled =

together.</DIV>
<DIV>The processing rules (RFC 29610 for Bundled messages are such that =
each=20
sub-message is processed in its own right, and the non-support/non-use =
of Hello=20
messages should not impact the processing of other messages.</DIV>
<DIV>&nbsp;</DIV>
<DIV>On the other hand, "piggybacked" implies the use of the Ack/Nack =
objects=20
within a Hello message.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Section 4.1 of RFC2961 states that Ack/Nack objects may be included =
in the=20
"standard" RSVP messages, and shows where they are placed. However, RFC =
3209=20
defines the Hello message as not including the Ack/Nack objects...</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; &lt;Hello Message&gt; ::=3D &lt;Common Header&gt; [=20
&lt;INTEGRITY&gt;=20
]<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;HELLO&gt;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Since RFC 3209 post-dates RFC 2961, this definition is definitive =
and the=20
Ack/Nack objects should not be present on the Hello message.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Give that section 5.3 of RFC 3209 states...</DIV>
<DIV>&nbsp;&nbsp; The Hello Message is completely OPTIONAL.&nbsp; All =
messages=20
may be<BR>&nbsp;&nbsp; ignored by nodes which do not wish to participate =
in=20
Hello message<BR>&nbsp;&nbsp; processing.</DIV>
<DIV>...it is not particularly important what the message format rules =
are. An=20
implementation that chooses to place an Ack/Nack object in a Hello =
message knows=20
that the object might be discarded unprocessed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; 8. TSPEC format to be used for Ethernet connections</DIV>
<DIV>&nbsp;</DIV>
<DIV>The CCAMP working group is currently discussing the use of GMPLS =
for=20
control of Ethernet devices. We will respond to this point in a separate =

email.</DIV>
<DIV><BR>Best regards,</DIV>
<DIV>Adrian Farrel</DIV>
<DIV>Kireeti Kompella</FONT></DIV></BODY></HTML>

------=_NextPart_000_08C6_01C59E7A.94425120--




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Aug 2005 12:31:49 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-ashwood-ccamp-gmpls-constraints
Date: Thu, 11 Aug 2005 08:29:20 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA403846FC8@zrtphxm2>
Thread-Topic: draft-ashwood-ccamp-gmpls-constraints
Thread-Index: AcWcUaICAhsxzeXeQB2k63l/OCm87QArBlFQ
From: "Don Fedyk" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>

Hi Igor

Thanks for this text.  We will incorporate some this text into the next
version of the draft.  Hamid had asked me to involve the L1VPN list in
this activity going forward.    

Regards,
Don 

> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: Monday, August 08, 2005 3:44 PM
> 
> Don,
> 
> You can find a detailed description of the Virtual Link mode in the 
> Layer 1 VPN WG documents.
> 
> In brief, in this mode a domain is represented to the outside routing 
> domain not as a single node (as in case of the Virtual Node mode), but

> as a set of PEs interconnected by virtual (more correctly, abstract) 
> links. The Virtual Link mode has some serious advantages compared to 
> the Virtual Node mode. Here is some of them:
> 
> 1. In the Virtual Node mode there is some synchronization required 
> between
> PEs: in order for the outside routing domain to perceive the
> hidden domain as a single node all PEs need either to 
> generate exactly the same advertisings ( specifically, they 
> need to agree on the Virtual Node Router ID, learn about 
> every other PE and the links interconnecting the PE with the 
> outside routing domain, etc.) or identify the outside routing 
> domain segments interconnected exclusively by the means of 
> the hidden domain and elect for each of them a single PE that 
> would generate the Virtual Node advertisings. Neither of 
> these approaches is trivial to implement. On the contrary, 
> PEs in the Virtual Link mode advertise information into the 
> outside routing domain completely independently.
> 
> 2. In order to advertise a matrix of acceptable input-output link 
> combinations a PE must periodically solve ALL PEs -TO-ALL PEs 
> constraint based path computation problem. It is far more difficult 
> problem to solve compared to a single PE -TO-ALL PEs constraint based 
> path computation (which is as complex as a single source - single 
> destination path
> computation) required in the Virtual Link mode;
> 
> 3. The constraints used during the computation of the input-output 
> link matrix is not advertised and not available for the external path 
> computer, which diminishes the value of the matrix advertising. In 
> other words, even when the external path computer uses the matrix as a

> constraint, there is still a significant blocking probability of the 
> LSP setup using the computed path because there is no guarantee that
> the sets of the "external" and "internal" path computation 
> constraints match. There is no such problem in the Virtual 
> Link mode where the internal path computation constraints 
> could be advertised as abstract TE link attributes and hence 
> could be considered explicitly by the external path computer
> 
> 4. The matrix of input-output link combinations does not provide 
> information about the cost of a particular input-output binding across

> the hidden domain. This means that suboptimal path selection is quite 
> possible. On the contrary, each abstract TE link advertising has a TE 
> metric sub-TLV;
> 
> 5. It is not trivial to use the matrix of input-output link 
> combinations as a constraint, and some modifications of the external 
> path computation engine algorithms are required. There is no such a 
> requirement for the Virtual Link mode.
> 
> The major disadvantage of the Virtual Link mode, of course, is 
> scalability: the number of the abstract links grows proportionally to 
> the square of number of PEs. Because of that the Virtual Node mode 
> could be the only choice to hide a domain with large number of PEs.
> 
> Hope this helps.
> Igor
> 
> 




Envelope-to: [e-mail]
Delivery-date: Wed, 10 Aug 2005 18:39:24 +0000
Message-ID: <076101c59dda$f00c0c80$08849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Liaison to ITU-T Q3/15 about your Liaison "Reply on  GMPLS/ASON Lexicography"
Date: Wed, 10 Aug 2005 19:32:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

This response from Hiroshi Ohta rapporteur of ITU-T Q3/15 indicates that
no specific action was required to their liaison, but that we should keep
them informed of our progress on the lexicography I-D.

Adrian
----- Original Message ----- 
From: "Hiroshi Ohta" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Thursday, August 04, 2005 8:45 AM
Subject: Re: Liaison to ITU-T Q3/15 about your Liaison "Reply on
GMPLS/ASON Lexicography"


> Dear Adrian,
>
> As we talked after the ccamp session yesterday, Q.3/15 expects
> a response to our liaison from ccamp in some form and hopes to
> continue this on-going dialog between ccamp and some Questions
> within SG15.  This is the reason for the mark "For: Action".
>
> Best regards,
>
> Hiroshi Ohta
> Q.3/15 rapporteur
>
>
> At 17:09 05/06/03 +0100, Adrian Farrel wrote:
> >Title: Liaison to ITU-T Q3/15 about your Liaison "Reply on GMPLS/ASON
> >Lexicography"
> >To: ITU-T Study Group 15 Question 3
> >From: IETF CCAMP Working Group
> >For: Action
> >Deadline: August 1, 2005
> >
> >CCAMP would like to thank Q3/15 for their liaison and the useful
> >explanatory information it contains.
> >
> >The liaison is marked "For: Action" with a deadline of August 31,2005.
> >However, there are no obvious requests for action within the liaison.
> >
> >Can you please clarify whether there was an intent to request specific
> >action.
> >
> >Thank you.
> >
> >Adrian Farrel and Kireeti Kompella
> >CCAMP Working Group Co-Chairs
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 10 Aug 2005 09:37:08 +0000
Message-ID: <000f01c59d86$306c2760$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: Re: Last call complete on GMPLS MIBs
Date: Wed, 10 Aug 2005 10:30:45 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian

I finally got to look at the new versions of the GMPLS MIBs that came out in
June and am pleased to see my previous comments in use:-).  Some follow
up thoughts.

In draft-ietf-ccamp-gmpls-te-mib-09, I see that
IANAGmplsSwitchingType ::= TEXTUAL-CONVENTION
still references
                   "1. Kompella, K., Rekhter, Y. (Editors), Routing Extensions
                in Support of Generalized Multi-Protocol Label Switching
                draft-ietf-ccamp-gmpls-routing, work in progress.
which I think should be draft-ietf-ccamp-ospf-gmpls-extensions for
l2sc (51).  The former introduces the concept but does not give a value; the
latter assigns the value 51.

IANAGmplsLSPEncoding has a reference to
D. Papadimitriou (Editor), Generalized MPLS
                Signalling Extensions for G.709 Optical Transport
                Networks Control, draft-ietf-ccamp-gmpls-g709,
                work in progress
which I think should make that a normative reference.

And, more generally with these references to I-Ds which are normative, should we
add a note to tell the RFC editor to replace this with a reference to the RFC
when it emerges?  That would be business as usual in the References section but
might need a little encouragement buried in a MIB module DESCRIPTION.

IANAGmplsAdminStatusFlags defines BITS as
                     delInProgress (0),
                     adminDown (1),
                     testing (2),
                     reflect (31)
while RFC3471 has reflect as bit 0 and delInProgress as bit 31.  Is that
correct? (I assume that the intent is to keep them in line and I don't know
which way round BITS go; I assumed bit 0 came first and was MSB.  If ITU and
IETF part company over this, we should be using IETF nomenclature:-)

In draft-ietf-ccamp-gmpls-lsr-mib-08.txt, I would like you to give the RFC
Editor a little more help in resolving
GMPLSTCMIB
by explicitly stating that it is the RFC produced from
draft-ietf-ccamp-gmpls-tc-mib-07.txt

Somewhat bigger issue; I am concerned that no constraint is placed on the
allocation by IANA of new values in the IANA MIB module, where the base
documents call for more stringent action (although there is some disagreement as
to what that is).  As it stands, it seems to me that anyone in the world can
e-mail IANA and get a new value assigned in the IANA MIB module, whereas I think
it should be the appearance of an RFC, eg draft-ietf-ccamp-gmpls-routing or
draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, perhaps by
Expert Review ie the existence of a new name/number mapping is documented in an
RFC or I-D and Expert Review allows that mapping to be added to IANA MIB module.
We could require the RFC that introduces a new mapping to have an IANA section
that updates the MIB module but I fear that most editors would forget to include
it, so Expert Review seems best.

Finally, I would prefer the IANA MIB modules to be retained in the published RFC
with a note that the authoritative source is IANA; this gives us an audit trail
of how we got to where we are, or not as the case may be.  There has been a case
just recently elsewhere where the RFC and IANA are different and it is valuable
to see just what it was that was last called and approved by all concerned.  As
and when the RFC containing the IANA MIB module is reissued, then there would be
no need to replicate it.

Tom Petch




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Aug 2005 13:54:35 +0000
Message-ID: <043401c59ce9$d17647f0$08849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Draft minutes - comments please
Date: Tue, 9 Aug 2005 13:09:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

IETF-63 Paris August 2005

CCAMP Working Group

Minutes thanks to Deborah Brungard and Don Fedyk

Admin
Adrian reviewed slides of agenda

WG Status
Adrian reviewed draft status and milestones

ITU and OIF  liaison report - Lyndon Ong
Reviewed slides
- Q14 Plan to share g7713 before goes for consent
- No signaling activities, routing they are waiting for our DT
  response, next meeting in Chicago
- OIF activities
  - OIF communication to IETF with identified issues from demo
Adrian: Understand that there is no urgency for responding
        Will respond as quickly as possible, will post on mailing list.
Lyndon: These are results of the demo so there is no dependence but
        they are important.
Dimitri: Were these issues identified before or after demo?
Lyndon: Some before, some after.
Dimitri: Why not asked over the list for those before?
Lyndon: Some of the issues were, like the encoding.
        The first issue was on an informal response. So we want a formal
        response.
        The other issues we made some implementation decisions so we want
        to verify the decisions.

Interdomain RSVP - Arthi Ayyangar
- Reviewed slides
- Hope to get comments before do next revision (soon) then hope to go
  for last call
Dimitri: Do you plan to keep the examples in the document or as
         appendix?
Arthi: Do you think it affects readability?
Dimitri: Prefer as appendix
Arthi: OK
Adrian: Is this an example or is it normative?
Arthi: The example only describes the overall working.

LSP stitching: Arthi Ayyangar
- Reviewed slides
- Summarized discussion on list
- First point
  - Are procedures required for both PSC and non-PSC LSPs?
  - Discussion on list indicated yes
  Adrian: Also from a control plane point of view it is better to
          have a consistent behavior
- 2nd point
  - Should allow stitching while traversing region boundaries?
  Dimitri: I see no reason for this, why are we still discussing?
  Adrian: I said yes on the list because of the last bullet on the
          slide. Why disallow it?
  Kireeti: I think yes also, why disallow it?
  Dimitri: Why allow it?
  Adrian: If we take it out of scope now, we may have to change later,
          so why remove it now?
          Yet we don't want to do it speculatively.
  Igor: Question for kireeti: Can we stitch PSC1 with PSC2 LSP?
        And we said while we could do this with a label stack, but we
        shouldn't allow it as these LSPs were provisioned for a reason
        as two different types (PSC1 and PSC2).
        In the non-packet world this more clear. Use hierarchy and
        adaptation.
  Kireeti: Not so clear for me. PSC1 & PSC2 We understand but Non-PSC
           we don't understand. For non PSC, we don't know where it
           will go, e.g. wavelength switching. So why prevent it?
  Igor: It is not complex but it is pointless.
  Kireeti: You can always say no when you receive a request to stitch.
  Arthi and Igor: No, you can't say no
  Lou: What is the difference between stitching and hierarchical LSP.
       The LSP on top (inner label) uses all the bandwidth of the one
       below (outer label).
  Adrian: The difference is if you add a label for the passenger LSP.
  Arthi: It's not just label allocation it's resource allocation.
         I'll address this later.
- Bidirectional LSPs and control of labels
  - Current proposal resolves this by not sending a Label.
  - 4 options: In Slides:
  Lou: Minor suggestion; use a different C-type.
       Call it Option 2 Prime.
  Arthi: You can, but it is still an issue.
  Adrian: You have to do special processing when you do stitching
          anyway.
  Arthi: You still have to implement the C-type.
  Kireeti: You don't have to allocate a special label.
  Adrian: Agree Point 4: Need to provide end-to-end bidirectional
          service. For example for mpls/gmpls migration. Need to
          stitch two unidirectional LSPs in the middle.
  Arthi: Or could do 2nd part of (4). This is not really any changes
         Just need stronger description on what we are doing
         Personally like a sending label that is ignored.
  Adrian: Who likes this 2nd part?
          - Send any label and have receiver ignore it
          # Some show of hands
  Adrian: Anyone prefer one of the other solutions?
          # (No one?)
  Adrian: Seems a preference for this 2nd option, will take to list
  Lou: Clear to make the change. Change the text to Must.
  Dimitri: Can you make clear on the stitching for bidirectionality
  Arthi: Should it be required for non PSC?
  Lou: Anyone that supports stitching MUST support the procedures if
       they support stitching.
  Arthi: But if you are not following this document.
         You could be doing data plane stitching and not control
         plane stitching.
  Lou: If it is outside the standard then it is out of scope. If you
       follow the document you MUST follow the procedures.

Per-Domain-Paths - JP Vasseur
Would like to get feedback on last issue on slides.
Adrian: I think the use of IP reachability information is important.
        The WG must make a conscious decision.
JP: This I-D is only describing reachability outside of domain
Adrian: We should say so more clearly
Dimitri: I sent feedback. We should cover this question.
         Not sure if part of this document. This is a problem in several
         documents.
         If we have IP reachability, but don't know switching
         capability, then it's not sure if we can make the connection.
         This an issue when have a mixture of switching capabilities.
Igor: When we compute path, we consider TE resources, not IP
      reachability. Should not rely on knowing reachability.
      Once you have a mix of terminating points this is a real issue.
Adrian: We need to have a global solution.
Igor: You want to compute path consider the resources TE resource
      reachability of destination.  Not to rely on the IP but have
      static information that you can reach the path.
JP: Just want to rely on IP reachability to reach next domain, and then
    let next domain decide if it can satisfy the request.
Igor: OK - maybe could do aggregation rules
      You can have a static TE entry.
JP: But we don't have information on resources
Janis ??: Agree that if we are separating data and control plane, this
          will not work
Adrian: Specifying what information to use for path computation is not
        covered anywhere. It is part of the algorithm, but not part of
        the protocol. CSPF can use any information including IP
        reachability or the weather.
Arthi: So how do we find next hop? How do you get to the next domain?
Adrian: If we don't do this process inside the domain, why do we have
        to have a way to get out of the domain?
JP: So we should remove next hop?
Arthi: Does not make sense. How to do crankback?
Kireeti: OK - we need to consider further

Addresses in GMPLS networks - Richard Rabbat
Reviewed slides
Arthi: why you are proposing as a std track?
Adrian: This decision was a result of a loose poll based on
        whether this advises, recommends or mandates.
Arthi: Can we do again the poll
Adrian: We can, who prefers:
        # BCP - some show of hands
        # Stds track - less show of hands
Arthi: My concern is that it is good to have this document, but
       it is using items from other docs and making some changes
       Have to change the Musts and Shoulds.
Adrian: If text is repeating the same must/should from another document
        then it should be deleted.
        If this is new must/should language then it should be std track
        Need to clarify definitions. If you are Restating with same
        values, its BCP. If you change values it is Standards updating
        an existing RFC or a new Standards track document.
Arthi: Then this should be std track as it is already doing it
Lou: It is bringing together many items - would suggest informational
     Could be informational. I did not vote because I was waiting for
     informational.
Adrian: Who wants informational?
        # almost same show of hands as BCP
Lou: If it's implementation then BCP, but if bringing together info,
     then informational
     The document is putting recommendations on implementing.
     Is it just for building and deploying?
     Or is it Defining a new field or procedure?
Adrian: OK we should discuss more
Dimitri: I thought the same - it is bringing together experience on
         using addresses, not saying how to do, and not covering
         future issues. So I have issue with 9.3 which is not based
         on experience
Adrian: The WG needs to decide how want to do
Kireeti: We will discuss with ADs and take to list
Arthi: For example, for the FA it says a MUST for how to use, but it
       doesn't say what to do for static case, so doesn't cover all
       cases
Richard: <missed response>
Yakov: Slide #3. Why the decision on FA LSP, this is a change to the
       protocol.
Richard: You don't know it is a FA LSP. How do you know that it is to
         be advertised back?
John Drake: It is covered in RFC3477.
Lou: That is unnumbered interfaces.
Adrian: Numbered FA LSPs need a way to indicate to the egress that
        they will be used as FAs. Compare with unnumbered LSPs that
        have a special object.
Arthi: What is the point of changing it to 0?
Kireeti: Let's discuss on the list

GMPLS/ASON Lexicography - Igor Bryskin
Reviewed slides
Igor: If anyone is interested in furthering ason-gmpls convergence,
      talk to Adrian or myself to help
Richard: What is your objective?
Igor: Have consensus in the group and expand the dictionary.
Richard: Saw in one the drafts on ASON there is an appendix.
         With ASON terms. Should we integrate the ason-gmpls
         documents' reference terms into this document?
Dimitri: No, that work was for CCAMP people to understand ASON.
         This is a different purpose
Igor: Agree. This is for ITU people to understand GMPLS

ASON routing evaluation - Dimitri Papadimitriou
Reviewed slides
Adrian: Who from DT is in the room?
        # Dimitri and Lyndon
Adrian: Thanks for work.
        Does the DT think this is ready for last call?
Lyndon: Yes. Just some minor editing
Adrian: Anyone object to last call
        # None
Alex: Doesn't WG need to read this first
Adrian: Yes, need to read it for last call
        OK take to list for last call

ASON signaling - Dimitri Papadimitriou
Reviewed slides
Dimitri: The community that wants to use this document needs it
         to be recognized as an RFC, it is important to finish
Alex: Any technical issues on this or the last document that need to
      discuss now?
Dimitri: Only this item on simultaneous call/connection signaling
Alex: Please summarize the technical issues.
      Please focus the time in the meeting to raise and discuss
      open issues
Lyndon: Will you liaison to SG15 before last call?
Kireeti: Yes
Steve Trowbridge: Should also include specific changes against g7713.2
Adrian: What is the intention?
Steve: Should be for alignment, should not have two normative versions
       of ASON signaling
Adrian: ITU already has versions .1, .2, .3
Steve: State how it differs from .2 version
Adrian: OK. This is GMPLS. 7713.2 is not GMPLS.
        We can do a comparative analysis.
        Principal difference is call/connection piggybacking
Lyndon: Is this UNI/ENNI/INNI?
Dimitri: The document states clearly this if you read it
         Answer is all three
Alex: Are the technical issues complete? It would be much better if we
      have the technical summary.  Not just say this work is ready or
      work is stable.
Adrian: We owe the WG status.
Kireeti: Dimitri, can you start the liaison?
Dimitri: OK

CCAMP Work Plan
Kireeti reviewed the slide on options what to do
- We have pretty much cleared the documents in our queue,
  and we are reviewing the charter to update
Alex: - I have 12 documents submitted to me, 10 docs in id list.
      - Documents are done when finished also IESG review, I don't
        expect to wait for this though before going on to new items.
Alex reviewed slide on potential new work
- Inter domain OK
- Layer 2 switching: where is this?
Kireeti: We will have a discussion on where to put it
Alex continues:
- L1VPN New WG
- doesn't seem any objection, should prioritize and timeline
- Are these Milestones or Work items?
Kireeti:
- Could do milestones, but defining work items is easier
- For example, MPLS/GMPLS interworking is implicit in the charter
  but not specifically covered.
Alex: Can identify high priority items now
Adrian: - We already asked the working group and this is on the first
          slide.
        - There are six items shown on the slide
Alex: Six items that need some work. Is that too much?
Adrian:
- Not all things are the same size.
- Interoperability issues are already on the plate.
- Layer 2 switching Moderate size thing.
- MPLS/GMPLS migration moderate size.
- Second slide shows recent new topics. Maybe take on new items.
  - Signaling Issues:
  - Routing issues
  - GMPLS OAM requirements.
Alex: These items are also important
Kireeti: Should look at pipelining work as we already started first
         slide. It all depends on how long it takes to do charter.
         We have been waiting now for more than a year
Alex: Can prioritize and identify if can spin off work to a new,
      separate working group.
      Just like Layer 1 VPN that uses GMPLS.
      Take out other lumps and put in other WGs?
      Chairs should identify items.
Adrian: We can discuss which could spin off, though we need to decide,
        and not delay, as many items are already being worked on.
Bijan Jabbari: When I look at what is being implemented by vendors
               there is a mismatch with what this group is doing.
               Perhaps should look at short term.
Alex: Yes my thoughts should look at 1 year to 2 years.
Bijan: Not really clear what is being implemented
Bijan: I work with Academia and industry, and the answer is not clear.
       You see implementations but you don't see deployments.
       Business reasons etc. New way of thinking that takes time.
Alex: When go for standard track, do need implementation
Kireeti: Also need deployments, and that takes time

JP: Regarding the item on "input to PCE requirements".
    Not sure if need this input
Adrian: Explain history is that CCAMP made a commitment to assist PCE
        Could agree to remove this commitment
Alex: Yes we should discuss more in both groups. Don't want to make
      commitment to remove this before discussing it.
      If we have consensus maybe we don't need the document.
JP: On advertisement of TE/GMPLS capabilities, we have implemented
    and deployed in 5 large service providers, so would like to
    expedite this
Lou: Slide Back to Slide3:
     For the item on charter - missing is ASON.
     What do we do about alignment, and that we have two versions of
     RSVP? There is only one version of GMPLS, what do we need to do?
     What steps that we need to take as a WG?
Alex: ASON is on our charter
Lou: It's on charter - we have completed our documents.
     We can send to SG15, but what do we do from there to align GMPLS and
     ASON solutions?
Adrian: Added it to slides
Richard: On recent new topics - do we know what is in-charter currently?
Alex: It is up to chairs:
Adrian: If it is in the scope of the charter, we will do milestones
        There will be discussion on the list.
Dimitri: Why is "deployment considerations" considered marginal?
         If you want feedback, how can this be classified as marginal?
         Please prioritize and please discuss.
Adrian: This is from the community view gathered on the list last year
Dimitri: Then how will we have deployment
Kireeti: You can do canvassing to get people to discuss.
         We will take back to the list to do a poll again

GMPLS for Ethernet - Dimitri Papadimitriou
Reviewed slides
Define a set of scenarios:
4 Scenarios
-Aggregation
-Metro
-Unified? Core
-Transport
Dimitri asked if interest to do this work
Don Fedyk: We still don't know what is actually meant by GMPLS
           Ethernet. The document does not go far enough today
           with enough detail. The document is too open ended and
           we don't know what exactly is being specified. I asked
           for more detailed specification.
Dimitri: <Nodded>
Ali Sajassi: Ethernet differs from other data planes as it's not point
             to point. Do you want to keep it as in the perspective of
             IEEE?
             Other comments: you want to replace existing Ethernet
             control plane with GMPLS: again how will you do multipoint?
             Shortest path may overlap with issues discussed in TRILL.
             How are you going to coordinate with other WGs?
Loa: Not speaking for the DT as we didn't discuss it: I have experience
     running a medium/large scale Ethernet network as a point-to-point
     network (unified/core). It would be very applicable to add a gmpls
     control plane.
     Note that if we can't do it as a standard we (deployers) will do
     it ourselves. It is pretty straight forward.
Ali: I can see for point to point, it's for multipoint that I see it
     will have issues
Dimitri: OK. Can you input specifics?
         These questions are relevant.
         How do we work and overlap with various working groups?
Richard Spencer: Can you confirm that using GMPLS in enterprise is out
                 of scope?
Dimitri: As no one has expressed interest I would say it is out of scope
Richard S: Will there be any changes to Ethernet control/data plane?
           What would be the potential difficulties?
           Have a discussion with the IEEE and see where they would be
           impacted.
Dimitri: I can not say what will be the solution chosen, we already
         suggested we work with IEEE
Richard S: I see little value for aggregation.
           I don't see in metro why a provider would want to use this
           instead of VPLS
Dimitri: I have replied to some of the issues on the list. We should
         discuss more on list
Kireeti: We will not change the Ethernet data plane here. If we conclude
         it may need to be changed, we will liaise to IEEE and get their
         agreement.
         CCAMP is focused on core tunneling technologies, though we
         don't say how you will use them - metro or core - I would like
         us to continue not to be specific for access or core. If
         there is anything specifically different for access, then need
         to add to charter.
Lyndon: There is a lot of interest in other groups (ITU, OIF, MEF).
        I think there is interest. Where people are uncertain is how.
        Need to look at more on supporting pt to pt or multipt.


Don O'Conner: How does this differ from l2vpn?
Dimitri: It differs in that this is not mpls.
Kireeti: L2VPON charter is different. L2VPN sets up vpns.
         This work is on signaling and routing in Ethernet networks.
Tom Nadeau: Is this in the scope of CCAMP today?
Adrian: Yes this is in the scope as a core network.
        GMPLS handles packet transport networks.
        Maybe this is could be a new working group.
Tom: Seems similar to TRILL.
Adrian: Yes. Need to determine if there is overlap. Perhaps this work
        should go there. Alternatively, perhaps this work goes in a new
        WG.
Dimitri: Some of the items have been discussed.
Loa: Trill is in campus networks.
Alex: For structuring this work, we need to be very clear what data path
      modifications need to be done. Should communicate with IEEE
      liaison, preferably before BOF.
      MPLS working group is a specific example.
<???>: What would be the way to contact the IEEE to do this?
       Can I get a Liaison?
Alex: We have an established liaison relationship with IEEE.
Kireeti: First need to decide if we need a change in the data plane.
         Then talk to the IEEE.
Adrian: Also need to tell IEEE what we plan to do, no matter how we do
        it.
<Marcus? Michael?> Smith: There are limits to the use of VLAN-ID.
        There are only 4K of them. Will you use this as the label?
Adrian: We haven't decided anything about how forwarding will occur yet
Dinesh Mohan: I haven't heard yet that there is planned a change to the
              data plane. Need to understand better.
              Should look at this as a new control plane using existing
              data plane.
              It would be nice to have the GMPLS Control plane but is
              there no intent to change the control plane?  The basic
              assumption is that you have a different control plane
              then that should be the assumption.
              This is fine to explore, but the starting point is not to
              modify the data plane.
Adrian: When we control SDH we did not mess with the data plane. We
        should not be modifying the transport technology.
Monique Morrow: Echo what Alex said, any modification we need to talk
                to the IEEE.
Dimitri: OK, but we are not talking in the context that there is a
         change to data plane.
Ali: Trill and this are using ISIS. Trill plan to change the data
     plane.
Kireeti: Please stop, take to list.
Ali: Several vendors offer Ethernet switches that offer point to
     point using MPLS control plane supporting millions of
     connections.
Yakov: How? Could you tell me whether they carry a label?
Ali: Yes. They are MPLS switches
Yakov: So it is a router, an LSR , that you can call an Ethernet
       switch and you are done?
Adrian: That is indeed a suggestion.
Don O'C: Ethernet is connectionless and now GMPLS is connection-
         oriented, so this is different.
         This is redefining Ethernet to make it connection oriented.
         Is that the intent?
         Is this making VLAN tags look like GMPLS labels?
Adrian: Again, this has not been discussed
Loa: From experience, we don't want to remove VLAN tags. Need something
     else. And the chairs said to the design team not to do that, yet
     80% of CCAMP are already assuming this is what we want to do.
Adrian: Design team job is done - Thanks.
        We need now for the WG to discuss.

Time is over. Other drafts that we didn't get to discuss, take to list.




Envelope-to: [e-mail]
Delivery-date: Mon, 08 Aug 2005 19:45:55 +0000
Message-ID: <00d701c59c51$94875bb0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: draft-ashwood-ccamp-gmpls-constraints
Date: Mon, 8 Aug 2005 15:44:24 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Don,

You can find a detailed description of the Virtual Link mode in the Layer 1
VPN WG documents.

In brief, in this mode a domain is represented to the outside routing domain
not as a single node (as in case of the Virtual Node mode), but as a set of
PEs interconnected by virtual (more correctly, abstract) links. The Virtual
Link mode has some serious advantages compared to the Virtual Node mode.
Here is some of them:

1. In the Virtual Node mode there is some synchronization required between
PEs: in order for the outside routing domain to perceive the hidden domain
as a single node all PEs need either to generate exactly the same
advertisings ( specifically, they need to agree on the Virtual Node Router
ID, learn about every other PE and the links interconnecting the PE with the
outside routing domain, etc.) or identify the outside routing domain
segments interconnected exclusively by the means of the hidden domain and
elect for each of them a single PE that would generate the Virtual Node
advertisings. Neither of these approaches is trivial to implement. On the
contrary, PEs in the Virtual Link mode advertise information into the
outside routing domain completely independently.

2. In order to advertise a matrix of acceptable input-output link
combinations a PE must periodically solve ALL PEs -TO-ALL PEs constraint
based path computation problem. It is far more difficult problem to solve
compared to a single PE -TO-ALL PEs constraint based path computation (which
is as complex as a single source - single destination path computation)
required in the Virtual Link mode;

3. The constraints used during the computation of the input-output link
matrix is not advertised and not available for the external path computer,
which diminishes the value of the matrix advertising. In other words, even
when the external path computer uses the matrix as a constraint, there is
still a significant blocking probability of the LSP setup using the computed
path because there is no guarantee that the sets of the "external" and
"internal" path computation constraints match. There is no such problem in
the Virtual Link mode where the internal path computation constraints could
be advertised as abstract TE link attributes and hence could be considered
explicitly by the external path computer

4. The matrix of input-output link combinations does not provide information
about the cost of a particular input-output binding across the hidden
domain. This means that suboptimal path selection is quite possible. On the
contrary, each abstract TE link advertising has a TE metric sub-TLV;

5. It is not trivial to use the matrix of input-output link combinations as
a constraint, and some modifications of the external path computation engine
algorithms are required. There is no such a requirement for the Virtual Link
mode.

The major disadvantage of the Virtual Link mode, of course, is scalability:
the number of the abstract links grows proportionally to the square of
number of PEs. Because of that the Virtual Node mode could be the only
choice to hide a domain with large number of PEs.

Hope this helps.
Igor


----- Original Message ----- 
From: "Don Fedyk" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, August 04, 2005 6:03 AM
Subject: RE: draft-ashwood-ccamp-gmpls-constraints


Igor

Thanks for the feedback I would like to work with you to capture the
Virtual Link Mode into the draft.

Regards,
Don

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, August 04, 2005 5:32 AM
>
> Hi,
>
> I believe this is a very useful draft. The described blocking
> problem (a limited ability of a node to cross-connect
> resources on input and output links wrt a particular LSP)
> exists not only in the Virtual Node scenario: there could be
> "real" network elements experiencing the problem (perhaps,
> because of the hardware limitations). Hence there is a need
> for a routing controller to be capable to advertise a map of
> acceptable (or
> unacceptable) input-output link combinations, and for a path
> computer to account for such a constraint (which is not trivial).
>
> I also would suggest the authors to consider the Virtual Link
> mode, that is, representing the domain to the outside world
> as a bunch of PEs interconnected by abstract (virtual) links.
> This approach may require more advertisements compared to the
> Virtual Node mode; however, it does relieve external path
> computers from handling the interface maps, plus it gives the
> idea about the cost and attributes of feasible paths across
> the domain.
>
> Igor




Envelope-to: [e-mail]
Delivery-date: Mon, 08 Aug 2005 10:32:18 +0000
Message-ID: <00dd01c59c04$8ad14560$08849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Alan Davey" <[e-mail]>
Subject: GMPLS Addressing draft
Date: Fri, 5 Aug 2005 15:30:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

In CCAMP in Paris Dimitri raised a specific question about section 9.3 of
draft-ietf-ccamp-gmpls-addressing-01.txt.

As I understood this question, Dimitri wants only to include material that
is relevant to current testing or operational experience. He asks,
therefore, whether anyone has deployed or tested scenarios where the
source is IPv4 and the destination is IPv6 or vice versa.

My view is that we should avoid completeness arguments and limit ourselves
to implementations and likely deployments. So if anyone has direct
experience of this scenario we will keep the text - otherwise section 9.3
will be deleted.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 04 Aug 2005 10:30:04 +0000
Message-ID: <[e-mail]>
Date: Thu, 4 Aug 2005 06:29:41 -0400 (EDT)
Subject: RE: draft-ashwood-ccamp-gmpls-constraints
From: [e-mail]
To: "Don Fedyk" <[e-mail]>
Cc: [e-mail], [e-mail]
User-Agent: SquirrelMail/1.4.1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Sure. We can meet today after lunch, otherwise, by email.

Igor


> Igor
>
> Thanks for the feedback I would like to work with you to capture the
> Virtual Link Mode into the draft.
>
> Regards,
> Don
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Thursday, August 04, 2005 5:32 AM
>>
>> Hi,
>>
>> I believe this is a very useful draft. The described blocking
>> problem (a limited ability of a node to cross-connect
>> resources on input and output links wrt a particular LSP)
>> exists not only in the Virtual Node scenario: there could be
>> "real" network elements experiencing the problem (perhaps,
>> because of the hardware limitations). Hence there is a need
>> for a routing controller to be capable to advertise a map of
>> acceptable (or
>> unacceptable) input-output link combinations, and for a path
>> computer to account for such a constraint (which is not trivial).
>>
>> I also would suggest the authors to consider the Virtual Link
>> mode, that is, representing the domain to the outside world
>> as a bunch of PEs interconnected by abstract (virtual) links.
>> This approach may require more advertisements compared to the
>> Virtual Node mode; however, it does relieve external path
>> computers from handling the interface maps, plus it gives the
>> idea about the cost and attributes of feasible paths across
>> the domain.
>>
>> Igor
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 04 Aug 2005 10:04:18 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-ashwood-ccamp-gmpls-constraints
Date: Thu, 4 Aug 2005 06:03:50 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4036157B7@zrtphxm2>
Thread-Topic: draft-ashwood-ccamp-gmpls-constraints
Thread-Index: AcWY127F1UPE2b1sQ0Syyj3IohxigQAA6fdw
From: "Don Fedyk" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

Igor

Thanks for the feedback I would like to work with you to capture the
Virtual Link Mode into the draft.=20

Regards,
Don=20

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]=20
> Sent: Thursday, August 04, 2005 5:32 AM
>=20
> Hi,
>=20
> I believe this is a very useful draft. The described blocking=20
> problem (a limited ability of a node to cross-connect=20
> resources on input and output links wrt a particular LSP)=20
> exists not only in the Virtual Node scenario: there could be=20
> "real" network elements experiencing the problem (perhaps,=20
> because of the hardware limitations). Hence there is a need=20
> for a routing controller to be capable to advertise a map of=20
> acceptable (or
> unacceptable) input-output link combinations, and for a path=20
> computer to account for such a constraint (which is not trivial).
>=20
> I also would suggest the authors to consider the Virtual Link=20
> mode, that is, representing the domain to the outside world=20
> as a bunch of PEs interconnected by abstract (virtual) links.=20
> This approach may require more advertisements compared to the=20
> Virtual Node mode; however, it does relieve external path=20
> computers from handling the interface maps, plus it gives the=20
> idea about the cost and attributes of feasible paths across=20
> the domain.
>=20
> Igor



Envelope-to: [e-mail]
Delivery-date: Thu, 04 Aug 2005 09:52:15 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-ashwood-ccacmp-gmpls-constraints
Date: Thu, 4 Aug 2005 05:51:41 -0400
Message-ID: <[e-mail]>
Thread-Topic: draft-ashwood-ccacmp-gmpls-constraints
Thread-Index: AcWY2A9cRcxBNRNWRBqnPuo6V05ZKAAAMbuw
From: "Ong, Lyndon" <[e-mail]>
To: <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>

Hi Igor,

I was wondering also about using a virtual link model, that seems to=20
be able to carry similar or more information, with maybe a bit more
overhead.

Cheers,

Lyndon=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Thursday, August 04, 2005 2:32 AM
To: Don Fedyk
Cc: [e-mail]
Subject: Re: draft-ashwood-ccacmp-gmpls-constraints

Hi,

I believe this is a very useful draft. The described blocking problem (a
limited ability of a node to cross-connect resources on input and output
links wrt a particular LSP) exists not only in the Virtual Node
scenario:
there could be "real" network elements experiencing the problem
(perhaps, because of the hardware limitations). Hence there is a need
for a routing controller to be capable to advertise a map of acceptable
(or
unacceptable) input-output link combinations, and for a path computer to
account for such a constraint (which is not trivial).

I also would suggest the authors to consider the Virtual Link mode, that
is, representing the domain to the outside world as a bunch of PEs
interconnected by abstract (virtual) links. This approach may require
more advertisements compared to the Virtual Node mode; however, it does
relieve external path computers from handling the interface maps, plus
it gives the idea about the cost and attributes of feasible paths across
the domain.

Igor

>
> Since we did not get through all the CCAMP agenda today, I would still

> like to get feedback on the following draft.
>
> Link Viability Constraints Don Fedyk (5 mins)=20
> http://home.clara.net/olddog/63/draft-ashwood-ccamp-gmpls-constraint-r
> eq
> ts-00.ppt
> http://www.ietf.org/internet-drafts/draft-ashwood-ccamp-gmpls-constrai
> nt
> -reqts-00.txt
>
> Note the draft is about interfacing a dynamic optical system to a=20
> GMPLS control plane but puts forward the argument we can avoid for now

> the standardization of the detailed optical constraints.  I would like

> to see this in Scope for the IETF (CCAMP) even though I realize the=20
> detailed (or complex) optical constraints may be years from being in=20
> scope and standardization. The current draft is a requirements draft=20
> with some preliminary ideas on how this can be achieved. I would like=20
> to solicit others who are interested in working this problem.
>
> Please send feedback, I'm around till Friday if anyone would like to=20
> discuss in person, Thanks, Don
>
>
>
>
>
>





Envelope-to: [e-mail]
Delivery-date: Thu, 04 Aug 2005 09:33:47 +0000
Message-ID: <[e-mail]>
Date: Thu, 4 Aug 2005 05:32:07 -0400 (EDT)
Subject: Re: draft-ashwood-ccacmp-gmpls-constraints
From: [e-mail]
To: "Don Fedyk" <[e-mail]>
Cc: [e-mail]
User-Agent: SquirrelMail/1.4.1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

I believe this is a very useful draft. The described blocking problem (a
limited ability of a node to cross-connect resources on input and output
links wrt a particular LSP) exists not only in the Virtual Node scenario:
there could be “real” network elements experiencing the problem (perhaps,
because of the hardware limitations). Hence there is a need for a routing
controller to be capable to advertise a map of acceptable (or
unacceptable) input-output link combinations, and for a path computer to
account for such a constraint (which is not trivial).

I also would suggest the authors to consider the Virtual Link mode, that
is, representing the domain to the outside world as a bunch of PEs
interconnected by abstract (virtual) links. This approach may require more
advertisements compared to the Virtual Node mode; however, it does relieve
external path computers from handling the interface maps, plus it gives
the idea about the cost and attributes of feasible paths across the
domain.

Igor

>
> Since we did not get through all the CCAMP agenda today, I would still
> like to get feedback on the following draft.
>
> Link Viability Constraints Don Fedyk (5 mins)
> http://home.clara.net/olddog/63/draft-ashwood-ccamp-gmpls-constraint-req
> ts-00.ppt
> http://www.ietf.org/internet-drafts/draft-ashwood-ccamp-gmpls-constraint
> -reqts-00.txt
>
> Note the draft is about interfacing a dynamic optical system to a GMPLS
> control plane but puts forward the argument we can avoid for now the
> standardization of the detailed optical constraints.  I would like to
> see this in Scope for the IETF (CCAMP) even though I realize the
> detailed (or complex) optical constraints may be years from being in
> scope and standardization. The current draft is a requirements draft
> with some preliminary ideas on how this can be achieved. I would like to
> solicit others who are interested in working this problem.
>
> Please send feedback, I'm around till Friday if anyone would like to
> discuss in person,
> Thanks,
> Don
>
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 03 Aug 2005 16:53:05 +0000
Content-class: urn:content-classes:message
Subject: draft-ashwood-ccacmp-gmpls-constraints
Date: Wed, 3 Aug 2005 12:50:37 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA403615077@zrtphxm2>
Thread-Topic: draft-ashwood-ccacmp-gmpls-constraints
Thread-Index: AcWR8KZ24x4uqrZrQTmtl148bcRRTwGVHAgg
From: "Don Fedyk" <[e-mail]>
To: <[e-mail]>

Hi 

Since we did not get through all the CCAMP agenda today, I would still
like to get feedback on the following draft. 

Link Viability Constraints Don Fedyk (5 mins) 
http://home.clara.net/olddog/63/draft-ashwood-ccamp-gmpls-constraint-req
ts-00.ppt
http://www.ietf.org/internet-drafts/draft-ashwood-ccamp-gmpls-constraint
-reqts-00.txt

Note the draft is about interfacing a dynamic optical system to a GMPLS
control plane but puts forward the argument we can avoid for now the
standardization of the detailed optical constraints.  I would like to
see this in Scope for the IETF (CCAMP) even though I realize the
detailed (or complex) optical constraints may be years from being in
scope and standardization. The current draft is a requirements draft
with some preliminary ideas on how this can be achieved. I would like to
solicit others who are interested in working this problem.

Please send feedback, I'm around till Friday if anyone would like to
discuss in person,
Thanks,
Don 







Envelope-to: [e-mail]
Delivery-date: Tue, 02 Aug 2005 12:07:35 +0000
Message-ID: <01ab01c5975a$f386dd80$7810ff56@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Tue, 2 Aug 2005 13:08:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Thanks Michael,

That fits with my assessment.
Its a plan.

Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Tuesday, August 02, 2005 11:46 AM
Subject: AW: LCAS and GMPLS


Hi,

Clearly CCAMP is not supposed to do TU-T's job... I have a feeling we need
more clarification of the actual requrirements, and then assess which
functionalities are supported by SONET/SDH or GMPLS already to identify
the missing bits. It may then turn out that we actually most of the
mechanisms in place, but need a BCP to clarify how to use them properly.
My suggestion to take this forward is that we briefly discuss the two
drafts tomorrow, then refine the requirements and the solution drafts
until the next IETF meeting. Again, there is definitive interest by
operators to get the SDH and GMPLS interworking as clear as possible.

Regards,

Michael



-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag
von Adrian Farrel
Gesendet: Dienstag, 2. August 2005 11:42
An: Huub van Helvoort; ccamp
Betreff: Re: LCAS and GMPLS


Hi Huub,

> > I think the original proposal is that SG15 may want to send CCAMP a
> > liaison about this work. That would certainly be fine.
>
> [hvh] I tried but did not get enough support

That is a shame because it is hard for CCAMP to work on this without a
clear statement of the requirements and we look to the ITU-T to supply the
details of LCAS.

If we can identify more precisely what it is we need to know, then we can
liaise a request for information.

> > I don't think that CCAMP can send a liaison back to support the work
> > without having seen it first.
>
> [hvh] both   draft-imajuku-ccamp-gmpls-vcat-lagr-req
>        and    draft-bernstein-LCAS-GMPLS
>        refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this
>        recommendation contains the following note:
> "NOTE - If a permanent removal of an active member is initiated at the
> Sk, this will result in a hit to the reconstructed data. The duration
> of this hit will be from the time the member is removed (starts
> sending MST = FAIL) until the DNU would have been received from the
> So."
>
>        So I supposed the authors of these drafts were aware
>        of this note, and consequently the mandatory sequence
>        for a hitless decrease of bandwidth: remove member at
>        source node first, wait for confirmation, remove member
>        at sink node (and network path).
>        Maybe the authors were not aware of a possible solution
>        presented at the recent SG 15 meeting.

I can't speak for the authors.
Speaking for myself, I was not aware of the work at the SG15 meeting. I am
certain that the majority of CCAMP was not aware.

> > With regard to the solution space for the problem:
> > - If the solution lies entirely within LCAS then it is out of scope
for
> > CCAMP. The LSP will simply be torn down when the LCAS
> > synchronization
has
> > been done.
>
> [hvh] indeed the solution is within the LCAS protocol, but has an
>        impact on the control plane: it removes the mandatory sequence
>        for hitless decrease.

Yes. it removes a requirement.
It doesn't remove any protocol elements because they already exist. It
changes the solutions doc, because there is no need to describe a
non-requirement.

> > - If the problem is to be solved within GMPLS, then we have a
> > suitable mechanism already.
>
> [hvh] if you mean that GMPLS can take care of or guarantee the
>        above mentioned mandatory sequence, then indeed there is
>        no problem.
>        However IMHO it may be a complex solution.

Well, if we establish that this *is* a requirement we have to solve it.
That will start a discussion of how simple/practical the solution is.
IM(NS)HO this is easy work using existing GMPLS tools.

> > Thus, it turns out that it is important to scope problems not just
> > functionally, but according to which components are intended to
resolve
> > them.
>
> [hvh] I hope I did above.

Thanks, yes.

But in order to understand the requirements here we must understand what
we are tyring to support. Do we need to support existing LCAS
implementations, or can we assume that the SG15 proposals will come to
agreement/standardisation and will be implemented ubiquitously?

See below...

> > Very obviously, the industry does not need or want two solutions to
the
> > same problem.
>
> [hvh] the solution proposed in the last plenary meeting of ITU-T
>        SG15 delayed document D.286 did not get concensus in the Q11
>        meeting. When presented in the Q14 meeting it was agreed that
>        this proposal would simplify the control of LCAS LSPs.
>
>        If this solution is not accepted soon, more LCAS implementations
>        will be cast in silicon (currently the majority is in SW) and
>        t will be very hard to get it accepted at a later date.
>
>        When CCAMP sees the need for adding this enhancement that
>        removes the mandatory remove sequence, shouldn't a liaison
>        be sent to SG15/Q11 to express their concern?

I think CCAMP will understand the need for hitless add/remove. If CCAMP
sees/believes that LCAS does not support this function, then CCAMP will
attempt to deliver this function. If CCAMP sees/believes that LCAS already
delivers the function, this will not be something that CCAMP discusses
further.

However, it is not for CCAMP to comment on the function contained within
LCAS. LCAS is not our protocol to comment on.

Thanks,
Adrian

>
> Cheers, Huub.
>
> > Adrian
> > ----- Original Message -----
> > From: "Huub van Helvoort" <[e-mail]>
> > To: "ccamp" <[e-mail]>
> > Sent: Sunday, July 31, 2005 3:21 PM
> > Subject: Re: LCAS and GMPLS
> >
> >>Hello Wataru,
> >>
> >>You wrote:
> >>
> >>>I forward a nice comment from Mr. Huub van Helvoort.
> >>
> >>Thank you for forwarding.
> >>(I hope I can send this message the list myself).
> >>
> >>>His comments indicates we need liason from ITU-T SG-15 regarding to
> >>>this issue.
> >>
> >>This is a good proposal, it will indicate to ITU-T SG15/Q11 that
> >>IETF/CCAMP supports this enhancement.
> >>
> >>Kind regards, Huub.
> >>
> >>--- from message 27-7-2005 ---
> >>
> >>
> >>>>One point for the problem statement could be that in order to
> >>>>guarantee a hitless removal of one of the members in a VCG
> >>>>(decrease of bandwidth) there is a mandatory sequence: First
> >>>>remove member at ingress node, wait for confirm and only then
> >>>>remove path and member at egress node.
> >>>>
> >>>>However, a solution was presented at the last ITU-T SG15/q11
> >>>>meeting that removes this requirement.
> >>>>
> >>>>Cheers, Huub.
>
> --
> ================================================================
>               http://members.chello.nl/hhelvoort/
> ================================================================
> Always remember that you are unique...just like everyone else...
>
>






Envelope-to: [e-mail]
Delivery-date: Tue, 02 Aug 2005 10:48:39 +0000
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: AW: LCAS and GMPLS
Date: Tue, 2 Aug 2005 12:46:18 +0200 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,=20

Clearly CCAMP is not supposed to do TU-T's job... I have a feeling we =
need more clarification of the actual requrirements, and then assess =
which functionalities are supported by SONET/SDH or GMPLS already to =
identify the missing bits. It may then turn out that we actually most =
of the mechanisms in place, but need a BCP to clarify how to use them =
properly. My suggestion to take this forward is that we briefly discuss =
the two drafts tomorrow, then refine the requirements and the solution =
drafts until the next IETF meeting. Again, there is definitive interest =
by operators to get the SDH and GMPLS interworking as clear as =
possible.

Regards,

Michael=20



-----Urspr=FCngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im =
Auftrag von Adrian Farrel
Gesendet: Dienstag, 2. August 2005 11:42
An: Huub van Helvoort; ccamp
Betreff: Re: LCAS and GMPLS


Hi Huub,

> > I think the original proposal is that SG15 may want to send CCAMP a =

> > liaison about this work. That would certainly be fine.
>
> [hvh] I tried but did not get enough support

That is a shame because it is hard for CCAMP to work on this without a =
clear statement of the requirements and we look to the ITU-T to supply =
the details of LCAS.

If we can identify more precisely what it is we need to know, then we =
can liaise a request for information.

> > I don't think that CCAMP can send a liaison back to support the =
work=20
> > without having seen it first.
>
> [hvh] both   draft-imajuku-ccamp-gmpls-vcat-lagr-req
>        and    draft-bernstein-LCAS-GMPLS
>        refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this
>        recommendation contains the following note:
> "NOTE - If a permanent removal of an active member is initiated at =
the=20
> Sk, this will result in a hit to the reconstructed data. The duration =

> of this hit will be from the time the member is removed (starts=20
> sending MST =3D FAIL) until the DNU would have been received from the =

> So."
>
>        So I supposed the authors of these drafts were aware
>        of this note, and consequently the mandatory sequence
>        for a hitless decrease of bandwidth: remove member at
>        source node first, wait for confirmation, remove member
>        at sink node (and network path).
>        Maybe the authors were not aware of a possible solution
>        presented at the recent SG 15 meeting.

I can't speak for the authors.
Speaking for myself, I was not aware of the work at the SG15 meeting. I =
am certain that the majority of CCAMP was not aware.

> > With regard to the solution space for the problem:
> > - If the solution lies entirely within LCAS then it is out of scope
for
> > CCAMP. The LSP will simply be torn down when the LCAS=20
> > synchronization
has
> > been done.
>
> [hvh] indeed the solution is within the LCAS protocol, but has an
>        impact on the control plane: it removes the mandatory sequence
>        for hitless decrease.

Yes. it removes a requirement.
It doesn't remove any protocol elements because they already exist. It =
changes the solutions doc, because there is no need to describe a =
non-requirement.

> > - If the problem is to be solved within GMPLS, then we have a=20
> > suitable mechanism already.
>
> [hvh] if you mean that GMPLS can take care of or guarantee the
>        above mentioned mandatory sequence, then indeed there is
>        no problem.
>        However IMHO it may be a complex solution.

Well, if we establish that this *is* a requirement we have to solve it. =
That will start a discussion of how simple/practical the solution is. =
IM(NS)HO this is easy work using existing GMPLS tools.

> > Thus, it turns out that it is important to scope problems not just=20
> > functionally, but according to which components are intended to
resolve
> > them.
>
> [hvh] I hope I did above.

Thanks, yes.

But in order to understand the requirements here we must understand =
what we are tyring to support. Do we need to support existing LCAS =
implementations, or can we assume that the SG15 proposals will come to =
agreement/standardisation and will be implemented ubiquitously?

See below...

> > Very obviously, the industry does not need or want two solutions to
the
> > same problem.
>
> [hvh] the solution proposed in the last plenary meeting of ITU-T
>        SG15 delayed document D.286 did not get concensus in the Q11
>        meeting. When presented in the Q14 meeting it was agreed that
>        this proposal would simplify the control of LCAS LSPs.
>
>        If this solution is not accepted soon, more LCAS =
implementations
>        will be cast in silicon (currently the majority is in SW) and
>        t will be very hard to get it accepted at a later date.
>
>        When CCAMP sees the need for adding this enhancement that
>        removes the mandatory remove sequence, shouldn't a liaison
>        be sent to SG15/Q11 to express their concern?

I think CCAMP will understand the need for hitless add/remove. If CCAMP =
sees/believes that LCAS does not support this function, then CCAMP will =
attempt to deliver this function. If CCAMP sees/believes that LCAS =
already delivers the function, this will not be something that CCAMP =
discusses further.

However, it is not for CCAMP to comment on the function contained =
within LCAS. LCAS is not our protocol to comment on.

Thanks,
Adrian

>
> Cheers, Huub.
>
> > Adrian
> > ----- Original Message -----
> > From: "Huub van Helvoort" <[e-mail]>
> > To: "ccamp" <[e-mail]>
> > Sent: Sunday, July 31, 2005 3:21 PM
> > Subject: Re: LCAS and GMPLS
> >
> >>Hello Wataru,
> >>
> >>You wrote:
> >>
> >>>I forward a nice comment from Mr. Huub van Helvoort.
> >>
> >>Thank you for forwarding.
> >>(I hope I can send this message the list myself).
> >>
> >>>His comments indicates we need liason from ITU-T SG-15 regarding =
to=20
> >>>this issue.
> >>
> >>This is a good proposal, it will indicate to ITU-T SG15/Q11 that=20
> >>IETF/CCAMP supports this enhancement.
> >>
> >>Kind regards, Huub.
> >>
> >>--- from message 27-7-2005 ---
> >>
> >>
> >>>>One point for the problem statement could be that in order to=20
> >>>>guarantee a hitless removal of one of the members in a VCG=20
> >>>>(decrease of bandwidth) there is a mandatory sequence: First=20
> >>>>remove member at ingress node, wait for confirm and only then=20
> >>>>remove path and member at egress node.
> >>>>
> >>>>However, a solution was presented at the last ITU-T SG15/q11=20
> >>>>meeting that removes this requirement.
> >>>>
> >>>>Cheers, Huub.
>
> --
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>               http://members.chello.nl/hhelvoort/
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Always remember that you are unique...just like everyone else...
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 02 Aug 2005 09:40:17 +0000
Message-ID: <013b01c59746$7d268af0$7810ff56@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Huub van Helvoort" <[e-mail]>, "ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Tue, 2 Aug 2005 10:42:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 8bit

Hi Huub,

> > I think the original proposal is that SG15 may want to send CCAMP a
> > liaison about this work. That would certainly be fine.
>
> [hvh] I tried but did not get enough support

That is a shame because it is hard for CCAMP to work on this without a
clear statement of the requirements and we look to the ITU-T to supply the
details of LCAS.

If we can identify more precisely what it is we need to know, then we can
liaise a request for information.

> > I don't think that CCAMP can send a liaison back to support the work
> > without having seen it first.
>
> [hvh] both   draft-imajuku-ccamp-gmpls-vcat-lagr-req
>        and    draft-bernstein-LCAS-GMPLS
>        refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this
>        recommendation contains the following note:
> "NOTE – If a permanent removal of an active member is initiated at the
> Sk, this will result in a hit to the reconstructed data. The duration of
> this hit will be from the time the member is removed (starts sending MST
> = FAIL) until the DNU would have been received from the So."
>
>        So I supposed the authors of these drafts were aware
>        of this note, and consequently the mandatory sequence
>        for a hitless decrease of bandwidth: remove member at
>        source node first, wait for confirmation, remove member
>        at sink node (and network path).
>        Maybe the authors were not aware of a possible solution
>        presented at the recent SG 15 meeting.

I can't speak for the authors.
Speaking for myself, I was not aware of the work at the SG15 meeting.
I am certain that the majority of CCAMP was not aware.

> > With regard to the solution space for the problem:
> > - If the solution lies entirely within LCAS then it is out of scope
for
> > CCAMP. The LSP will simply be torn down when the LCAS synchronization
has
> > been done.
>
> [hvh] indeed the solution is within the LCAS protocol, but has an
>        impact on the control plane: it removes the mandatory sequence
>        for hitless decrease.

Yes. it removes a requirement.
It doesn't remove any protocol elements because they already exist. It
changes the solutions doc, because there is no need to describe a
non-requirement.

> > - If the problem is to be solved within GMPLS, then we have a suitable
> > mechanism already.
>
> [hvh] if you mean that GMPLS can take care of or guarantee the
>        above mentioned mandatory sequence, then indeed there is
>        no problem.
>        However IMHO it may be a complex solution.

Well, if we establish that this *is* a requirement we have to solve it.
That will start a discussion of how simple/practical the solution is.
IM(NS)HO this is easy work using existing GMPLS tools.

> > Thus, it turns out that it is important to scope problems not just
> > functionally, but according to which components are intended to
resolve
> > them.
>
> [hvh] I hope I did above.

Thanks, yes.

But in order to understand the requirements here we must understand what
we are tyring to support. Do we need to support existing LCAS
implementations, or can we assume that the SG15 proposals will come to
agreement/standardisation and will be implemented ubiquitously?

See below...

> > Very obviously, the industry does not need or want two solutions to
the
> > same problem.
>
> [hvh] the solution proposed in the last plenary meeting of ITU-T
>        SG15 delayed document D.286 did not get concensus in the Q11
>        meeting. When presented in the Q14 meeting it was agreed that
>        this proposal would simplify the control of LCAS LSPs.
>
>        If this solution is not accepted soon, more LCAS implementations
>        will be cast in silicon (currently the majority is in SW) and
>        t will be very hard to get it accepted at a later date.
>
>        When CCAMP sees the need for adding this enhancement that
>        removes the mandatory remove sequence, shouldn't a liaison
>        be sent to SG15/Q11 to express their concern?

I think CCAMP will understand the need for hitless add/remove.
If CCAMP sees/believes that LCAS does not support this function, then
CCAMP will attempt to deliver this function.
If CCAMP sees/believes that LCAS already delivers the function, this will
not be something that CCAMP discusses further.

However, it is not for CCAMP to comment on the function contained within
LCAS. LCAS is not our protocol to comment on.

Thanks,
Adrian

>
> Cheers, Huub.
>
> > Adrian
> > ----- Original Message ----- 
> > From: "Huub van Helvoort" <[e-mail]>
> > To: "ccamp" <[e-mail]>
> > Sent: Sunday, July 31, 2005 3:21 PM
> > Subject: Re: LCAS and GMPLS
> >
> >>Hello Wataru,
> >>
> >>You wrote:
> >>
> >>>I forward a nice comment from Mr. Huub van Helvoort.
> >>
> >>Thank you for forwarding.
> >>(I hope I can send this message the list myself).
> >>
> >>>His comments indicates we need liason from ITU-T SG-15 regarding to
> >>>this issue.
> >>
> >>This is a good proposal, it will indicate to ITU-T SG15/Q11
> >>that IETF/CCAMP supports this enhancement.
> >>
> >>Kind regards, Huub.
> >>
> >>--- from message 27-7-2005 ---
> >>
> >>
> >>>>One point for the problem statement could be that in order to
> >>>>guarantee a hitless removal of one of the members in a VCG
> >>>>(decrease of bandwidth) there is a mandatory sequence:
> >>>>First remove member at ingress node, wait for confirm and
> >>>>only then remove path and member at egress node.
> >>>>
> >>>>However, a solution was presented at the last ITU-T SG15/q11
> >>>>meeting that removes this requirement.
> >>>>
> >>>>Cheers, Huub.
>
> -- 
> ================================================================
>               http://members.chello.nl/hhelvoort/
> ================================================================
> Always remember that you are unique...just like everyone else...
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 02 Aug 2005 08:50:48 +0000
Message-ID: <[e-mail]>
Date: Tue, 02 Aug 2005 10:49:25 +0200
From: Huub van Helvoort <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: ccamp <[e-mail]>
CC: Adrian Farrel <[e-mail]>
Subject: Re: LCAS and GMPLS
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hello Adrian,

Thanks for your comments.
I shall try to give some more insight.

You wrote:

> I think the original proposal is that SG15 may want to send CCAMP a
> liaison about this work. That would certainly be fine.

[hvh] I tried but did not get enough support

> I don't think that CCAMP can send a liaison back to support the work
> without having seen it first.

[hvh] both   draft-imajuku-ccamp-gmpls-vcat-lagr-req
       and    draft-bernstein-LCAS-GMPLS
       refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this
       recommendation contains the following note:
"NOTE – If a permanent removal of an active member is initiated at the 
Sk, this will result in a hit to the reconstructed data. The duration of 
this hit will be from the time the member is removed (starts sending MST 
= FAIL) until the DNU would have been received from the So."

       So I supposed the authors of these drafts were aware
       of this note, and consequently the mandatory sequence
       for a hitless decrease of bandwidth: remove member at
       source node first, wait for confirmation, remove member
       at sink node (and network path).
       Maybe the authors were not aware of a possible solution
       presented at the recent SG 15 meeting.

> With regard to the solution space for the problem:
> - If the solution lies entirely within LCAS then it is out of scope for
> CCAMP. The LSP will simply be torn down when the LCAS synchronization has
> been done.

[hvh] indeed the solution is within the LCAS protocol, but has an
       impact on the control plane: it removes the mandatory sequence
       for hitless decrease.

> - If the problem is to be solved within GMPLS, then we have a suitable
> mechanism already.

[hvh] if you mean that GMPLS can take care of or guarantee the
       above mentioned mandatory sequence, then indeed there is
       no problem.
       However IMHO it may be a complex solution.

> Thus, it turns out that it is important to scope problems not just
> functionally, but according to which components are intended to resolve
> them.

[hvh] I hope I did above.

> Very obviously, the industry does not need or want two solutions to the
> same problem.

[hvh] the solution proposed in the last plenary meeting of ITU-T
       SG15 delayed document D.286 did not get concensus in the Q11
       meeting. When presented in the Q14 meeting it was agreed that
       this proposal would simplify the control of LCAS LSPs.

       If this solution is not accepted soon, more LCAS implementations
       will be cast in silicon (currently the majority is in SW) and
       t will be very hard to get it accepted at a later date.

       When CCAMP sees the need for adding this enhancement that
       removes the mandatory remove sequence, shouldn't a liaison
       be sent to SG15/Q11 to express their concern?

Cheers, Huub.

> Adrian
> ----- Original Message ----- 
> From: "Huub van Helvoort" <[e-mail]>
> To: "ccamp" <[e-mail]>
> Sent: Sunday, July 31, 2005 3:21 PM
> Subject: Re: LCAS and GMPLS
> 
>>Hello Wataru,
>>
>>You wrote:
>>
>>>I forward a nice comment from Mr. Huub van Helvoort.
>>
>>Thank you for forwarding.
>>(I hope I can send this message the list myself).
>>
>>>His comments indicates we need liason from ITU-T SG-15 regarding to
>>>this issue.
>>
>>This is a good proposal, it will indicate to ITU-T SG15/Q11
>>that IETF/CCAMP supports this enhancement.
>>
>>Kind regards, Huub.
>>
>>--- from message 27-7-2005 ---
>>
>>
>>>>One point for the problem statement could be that in order to
>>>>guarantee a hitless removal of one of the members in a VCG
>>>>(decrease of bandwidth) there is a mandatory sequence:
>>>>First remove member at ingress node, wait for confirm and
>>>>only then remove path and member at egress node.
>>>>
>>>>However, a solution was presented at the last ITU-T SG15/q11
>>>>meeting that removes this requirement.
>>>>
>>>>Cheers, Huub.

-- 
================================================================
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...



Envelope-to: [e-mail]
Delivery-date: Tue, 02 Aug 2005 00:28:53 +0000
Message-ID: <00b001c596f6$07f38c10$7810ff56@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Huub van Helvoort" <[e-mail]>, "ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Tue, 2 Aug 2005 01:04:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Huub, Wataru,

I think the original proposal is that SG15 may want to send CCAMP a
liaison about this work. That would certainly be fine.

I don't think that CCAMP can send a liaison back to support the work
without having seen it first.

With regard to the solution space for the problem:
- If the solution lies entirely within LCAS then it is out of scope for
CCAMP. The LSP will simply be torn down when the LCAS synchronization has
been done.
- If the problem is to be solved within GMPLS, then we have a suitable
mechanism already.

Thus, it turns out that it is important to scope problems not just
functionally, but according to which components are intended to resolve
them.

Very obviously, the industry does not need or want two solutions to the
same problem.

Adrian
----- Original Message ----- 
From: "Huub van Helvoort" <[e-mail]>
To: "ccamp" <[e-mail]>
Sent: Sunday, July 31, 2005 3:21 PM
Subject: Re: LCAS and GMPLS


> Hello Wataru,
>
> You wrote:
>
> > I forward a nice comment from Mr. Huub van Helvoort.
>
> Thank you for forwarding.
> (I hope I can send this message the list myself).
>
> > His comments indicates we need liason from ITU-T SG-15 regarding to
> > this issue.
>
> This is a good proposal, it will indicate to ITU-T SG15/Q11
> that IETF/CCAMP supports this enhancement.
>
> Kind regards, Huub.
>
> --- from message 27-7-2005 ---
>
> >>
> >> One point for the problem statement could be that in order to
> >> guarantee a hitless removal of one of the members in a VCG
> >> (decrease of bandwidth) there is a mandatory sequence:
> >> First remove member at ingress node, wait for confirm and
> >> only then remove path and member at egress node.
> >>
> >> However, a solution was presented at the last ITU-T SG15/q11
> >> meeting that removes this requirement.
> >>
> >> Cheers, Huub.
>
> -- 
> ================================================================
>               http://members.chello.nl/hhelvoort/
> ================================================================
> Always remember that you are unique...just like everyone else...
>
>
>





Envelope-to: [e-mail]
Delivery-date: Tue, 02 Aug 2005 00:06:43 +0000
Message-ID: <00b001c596f6$07f38c10$7810ff56@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Huub van Helvoort" <[e-mail]>, "ccamp" <[e-mail]>
Subject: Re: LCAS and GMPLS
Date: Tue, 2 Aug 2005 01:04:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Huub, Wataru,

I think the original proposal is that SG15 may want to send CCAMP a
liaison about this work. That would certainly be fine.

I don't think that CCAMP can send a liaison back to support the work
without having seen it first.

With regard to the solution space for the problem:
- If the solution lies entirely within LCAS then it is out of scope for
CCAMP. The LSP will simply be torn down when the LCAS synchronization has
been done.
- If the problem is to be solved within GMPLS, then we have a suitable
mechanism already.

Thus, it turns out that it is important to scope problems not just
functionally, but according to which components are intended to resolve
them.

Very obviously, the industry does not need or want two solutions to the
same problem.

Adrian
----- Original Message ----- 
From: "Huub van Helvoort" <[e-mail]>
To: "ccamp" <[e-mail]>
Sent: Sunday, July 31, 2005 3:21 PM
Subject: Re: LCAS and GMPLS


> Hello Wataru,
>
> You wrote:
>
> > I forward a nice comment from Mr. Huub van Helvoort.
>
> Thank you for forwarding.
> (I hope I can send this message the list myself).
>
> > His comments indicates we need liason from ITU-T SG-15 regarding to
> > this issue.
>
> This is a good proposal, it will indicate to ITU-T SG15/Q11
> that IETF/CCAMP supports this enhancement.
>
> Kind regards, Huub.
>
> --- from message 27-7-2005 ---
>
> >>
> >> One point for the problem statement could be that in order to
> >> guarantee a hitless removal of one of the members in a VCG
> >> (decrease of bandwidth) there is a mandatory sequence:
> >> First remove member at ingress node, wait for confirm and
> >> only then remove path and member at egress node.
> >>
> >> However, a solution was presented at the last ITU-T SG15/q11
> >> meeting that removes this requirement.
> >>
> >> Cheers, Huub.
>
> -- 
> ================================================================
>               http://members.chello.nl/hhelvoort/
> ================================================================
> Always remember that you are unique...just like everyone else...
>
>
>




Envelope-to: [e-mail]
Delivery-date: Mon, 01 Aug 2005 08:09:49 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Date: Mon, 1 Aug 2005 10:08:17 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Thread-Index: AcWU6UF6wMowosxgRreHsS9OWN0BPQBhkwkg
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Adrian,

See inline
=20

> -----Message d'origine-----
> De : Adrian Farrel [mailto:[e-mail]]=20
> Envoy=E9 : samedi 30 juillet 2005 11:30
> =C0 : LE ROUX Jean-Louis RD-CORE-LAN; [e-mail]
> Cc : [e-mail]; [e-mail]; [e-mail];=20
> [e-mail]
> Objet : Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
>=20
> Hi,=20
>=20
> Time for me to speak out about the omission of hitherto=20
> mandatory objects from signaling messages.=20
>=20
> I would MUCH prefer that you keep the objects (Upstream Label=20
> or Path, Label on Resv) and use a special label value=20
> (implicit null? some new reserved label value?) to mean=20
> "stitch this".=20

I agree with you.=20
Actually this is what I suggested in the previous email, see below

> > JLLR: Yes, and what about defining a new MPLS label value, let say=20
> > label
> > 4 =3D "No label assigned", with a semantic distinct from label=20
> >3 semantic (=3Dlabel pop). The UPSTREAM label object with this=20
> >new label value  would be included in the end-to-end Path=20
> >message over the LSP-Segment...

Regards,

JL



>=20
> For me this is more natural and is less of a significant=20
> change to the existing protocol and implementation.=20
>=20
> It also solves the bidirection problem.=20
>=20
> Opinions?=20
>=20
> Cheers,
> Adrian=20
>=20
>=20
>  ----- Original Message -----
> From: <[e-mail]>
> To: "LE ROUX Jean-Louis RD-CORE-LAN"=20
> <[e-mail]>
> Cc: "Arthi Ayyangar" <[e-mail]>;=20
> <[e-mail]>; <[e-mail]>
> Sent: Friday, July 29, 2005 9:39 PM
> Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt=20
>=20
>=20
> >
> > hi j-l, arthi
> >
> >
> > > > -In section 4.1.2 you partially describe bidirectional LSP
> > > stitching
> > > > procedure. You mention that an Upstream Label MUST NOT be
> > > allocated by
> > > > the end-to-end LSP on the LSP segment, which is OK. But
> > > then how the
> > > > LSP-Segment Egress will now that the end-to-end LSP is
> > > bidirectional?
> > > AA--------> Excellent point.
> > >
> > > > What about defining a flag in the Attributes Flags TLV of the=20
> > > > LSP_ATTRIBUTE object so as to indicate that the LSP is
> > > bidirectional?
> > > AA------> That would be a change to the processing that GMPLS
> > > nodes use
> > > AA------> to
> > > detect bidirectionality, isn't it ? Normally nodes look for the=20
> > > Upstream Label object to detect bidirectionality.
> > >
> > > So let us say that an LSP is bidirectional if a) an=20
> Upstream Label=20
> > > is present or b) no Upstream Label, but bit set in=20
> LSP_ATTRIBUTE or=20
> > > c) both However, reliance on an e2e attributes bit set by=20
> head end,=20
> > > means existing head ends will not be setting this bit, so=20
> that will=20
> > > be an issue (wrt compatibility).
> >
> > JLLR: I agree this may raise some backward compatibility issues.
> > This would require that head-ends be upgraded...=20
> >
> >
> > DP: the other issue is having two methods for indicating the same=20
> > thing
> is also not advisable
> >=20
> >
> > > Could be nice if this signaling was just between the node=20
> doing the=20
> > > stitching and the end point of the LSP segment, since this is the=20
> > > hop that the bidirectionality information is lost. Let me think=20
> > > about this.
> >
> > JLLR: Yes, and what about defining a new MPLS label value, let say=20
> > label
> 4 =3D "No label assigned", with a semantic distinct from label=20
> 3 semantic (=3Dlabel pop). The UPSTREAM label object with this=20
> new label value  would be included in the end-to-end Path=20
> message over the LSP-Segment...
> >=20
> >
> > DP: assuming an information has to be passed for the indicating this
> capability i do also think a method like passing an implicit=20
> indication in the upstream label value would be more=20
> appropriated (note that the initial issue is due to the fact=20
> one would allow for unidirectional e2e LSP making use of=20
> bidirectional LSP segments - see comment from J-L here below=20
> - and not maintaining a 1:1 relationship for the=20
> directionality between the e2e LSP and the LSP segment that=20
> can be retrieved with the procedure described in section=20
> 4.2.4 - and so the first question is it worth allowing this?)
> >=20
> >
> > > > Also the selection of the LSP segment in case of=20
> bidirectional LSP=20
> > > > should be detailed (e.g. If the end-to-end LSP is
> > > bidirecitonal then
> > > > the LSP-segment MUST be bidirectional. Also shall we allow that=20
> > > > two unidrectional end-to-end LSP use the same bidirectional LSP=20
> > > > segment (one in each direction)?
> > > AA----> Yes, this should be okay. IMO.
> > >
> > > > -At the end of section 4.2.5 you mention that LSP-Segment
> > > failure or
> > > > maintenance SHOULD be treated as a failure event for the
> > > end-to-end LSP.
> > > > I agree for LSP-Segment failure but not for LSP-Segment=20
> maintenance.
> > > > LSP-Segment maintenance should be treated as TE-link
> > > maintenance for
> > > > the end-to-end LSP, and procedures defined in GMPLS
> > > graceful TE-link
> > > > shutdown draft may be useful (Specific RSVP error code=20
> and TE-link=20
> > > > attribute)...
> > > AA---> Yes, I agree; we will mention this. Actually the graceful=20
> > > AA---> teardown
> > > sentence occurs few paragraphs before, but not in the=20
> right context.=20
> > > So we will clarify the above.
> >
> >
> > DP: i am not sure to understand the comment, the sentence=20
> speaks about
> deletion of the LSP segment due to failure/maintenance should=20
> be treated as a failure event for the e2e LSP, so i don't=20
> think the initial sentence was meant to translated the=20
> initial comment, anyway it would be of interest that you=20
> detail the error code
> >
> > DP: note also that section 4.2.5 indicates that for stitched LSPs
> Graceful deletion can be used - i perfectly agree - but the=20
> sequence should be detailed as part of this section
> >=20
> >
> > > > Hope this helps,
> > > AA--->  Sure does.
> > >
> > >
> > > Thanks!
> > >
> > > -arthi
> > >
> > > >
> > > >
> > > > > -----Message d'origine-----
> > > > > De : [e-mail]
> > > > > [mailto:[e-mail]] De la part de=20
> > > > > [e-mail] Envoy=E9 : vendredi 15 juillet
> > > 2005 21:50 =C0 :
> > > > > [e-mail] Cc : [e-mail] Objet : I-D=20
> > > > > ACTION:draft-ietf-ccamp-lsp-stitching-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=20
> Measurement=20
> > > > > Plane Working Group of the IETF.
> > > > >
> > > > > Title: Label Switched Path Stitching with Generalized MPLS=20
> > > > > Traffic Engineering
> > > > > Author(s): A. Ayyangar, J. Vasseur
> > > > > Filename: draft-ietf-ccamp-lsp-stitching-01.txt
> > > > > Pages: 19
> > > > > Date: 2005-7-15
> > > > >
> > > > > In certain scenarios, there may be a need to combine=20
> together two
> > > > >    different Generalized Multi-Protocol Label Switching
> > > (GMPLS) Label
> > > > >    Switched Paths (LSPs) such that in the data plane, a
> > > single end-to-
> > > > >    end (e2e) LSP is achieved and all traffic from one LSP
> > > is switched
> > > > >    onto the other LSP.  We will refer to this as "LSP
> > > stitching".
> > > > > This
> > > > >    document covers cases where: a) the node performing
> > > the stitching
> > > > >    does not require configuration of every LSP pair=20
> to be stitched
> > > > >    together b) the node performing the stitching is not
> > > the egress of
> > > > >    any of the LSPs c) LSP stitching not only results in
> > > an end-to-end
> > > > >    LSP in the data plane, but there is also a
> > > corresponding end-to-end
> > > > >    LSP (RSVP session) in the control plane.  It might be
> > > possible to
> > > > >    configure a GMPLS node to switch the traffic from=20
> an LSP for=20
> > > > > which it
> > > > >    is the egress, to another LSP for which it is the
> > > ingress, without
> > > > >    requiring any signaling or routing extensions whatsoever,=20
> > > > > completely
> > > > >    transparent to other nodes.  This will also result in
> > > LSP stitching
> > > > >    in the data plane.  However, this document does=20
> not cover this
> > > > >    scenario of LSP stitching.
> > > > >
> > > > > A URL for this Internet-Draft is:
> > > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitc
> > > > hing-01.txt
> > > > >
> > > > > To remove yourself from the I-D Announcement list, send a
> > > message to
> > > > > [e-mail] 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.=20
> > > > > After logging in, type "cd internet-drafts" and then "get=20
> > > > > draft-ietf-ccamp-lsp-stitching-01.txt".
> > > > >
> > > > > A list of Internet-Drafts directories can be found in=20
> > > > > http://www.ietf.org/shadow.html or=20
> > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > > >
> > > > >
> > > > > Internet-Drafts can also be obtained by e-mail.
> > > > >
> > > > > Send a message to:
> > > > > [e-mail].
> > > > > In the body type:
> > > > > "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
> > > > >
> > > > > NOTE:The mail server at ietf.org can return the document in=20
> > > > > MIME-encoded form by using the "mpack" utility.  To use this=20
> > > > > feature, insert the command "ENCODING mime" before the "FILE"
> > > > > command.  To decode the response(s), you will need=20
> "munpack" or=20
> > > > > a MIME-compliant mail reader.  Different MIME-compliant mail=20
> > > > > readers exhibit different behavior, especially when=20
> dealing with=20
> > > > > "multipart" MIME messages (i.e. documents which have=20
> been split=20
> > > > > up into multiple messages), so check your local=20
> documentation on=20
> > > > > how to manipulate these messages.
> > > > >
> > > > >
> > > > > Below is the data which will enable a MIME compliant=20
> mail reader=20
> > > > > implementation to automatically retrieve the ASCII version of=20
> > > > > the Internet-Draft.
> > > > >
> > > >
> > >=20
> >
>=20
>=20