Subject: Opinion sought on drafts being adopted by CCAMP

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 4 Mar 2004 11:46:04 -0000

All,

At the CCAMP meeting today we discussed making several drafts working group items. Can you
please express your opinion (yes/no) on whether each of the following drafts is ready to
become a CCAMP working group draft.

Feel free to express yes with reservations. If you have reservations or objections, please
express them on the list. if you need anonymity for your comments then please filter them
through the chairs.

Silence will be taken as meaning nothing, so please say what you think.

GMPLS Signaling Procedure For Egress Control
http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt

Generic Tunnel Tracing Protocol (GTTP) Specification
http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt

RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt

GMPLS Based Segment Recovery
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt

Thank you,
Adrian

---

From: Lou Berger <[email-masked]>
Date: Thu, 04 Mar 2004 09:13:21 -0500

Adrian,
         I believe the alarm spec document also fell into this category, no?
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt

Much thanks,
Lou

At 06:46 AM 3/4/2004 -0500, Adrian Farrel wrote:

><http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt 
>
>
><http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt>http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt 
>
>
><http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt 
>
>
><http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt 
>
>
>Thank you,
>Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 6 Mar 2004 12:17:16 -0000

Lou,
It falls into a slightly different category as it was not presented because we ran out of
time.
Hence a separate thread to follow.
Adrian
----- Original Message ----- 
From: "Lou Berger" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 04, 2004 2:13 PM
Subject: Re: Opinion sought on drafts being adopted by CCAMP

><http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt>http://www.
ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt
><http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt>http://www.ietf.org/int
ernet-drafts/draft-bonica-tunproto-05.txt
><http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt
><http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt>htt
p://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 6 Mar 2004 12:20:45 -0000

In Seoul we ran out of time before we could discuss this draft.

However, the draft is pretty stable, and it is the opinion of the authors that this should
be brought under the wing of the WG.

Can you please send your opinions to the list or to the chairs direct.

Silence (as usual) will be interpreted as you saying nothing.

Thanks,
Adrian

---

From: [email-masked]
Date: Sat, 06 Mar 2004 15:35:07 +0100

hi adrian, see in-line:

> http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt

yes

> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt

yes

> http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt

yes

> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt

yes

---

From: [email-masked]
Date: Sat, 06 Mar 2004 15:36:33 +0100

hi adrian, see in-line:

> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt

yes.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Sat, 06 Mar 2004 10:38:09 -0500

yes

JP.

---

From: "Vishal Sharma" <[email-masked]>
Date: Sat, 6 Mar 2004 12:42:00 -0800

Adrian,

Opinions in-line. (Some of the drafts need more discussion and socializing
on the list, before we can determine whether they are ready to be
made CCAMP WG documents.)

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Thursday, March 04, 2004 3:46 AM
> To: [email-masked]
> Subject: Opinion sought on drafts being adopted by CCAMP
>
>
> All,
>

Yes.

> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt

Yes.
> RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-sign
aling-03.txt

No.

GMPLS Based Segment Recovery
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recover
y-00.txt

No.

---

From: "Vishal Sharma" <[email-masked]>
Date: Sat, 6 Mar 2004 12:45:44 -0800

Folks,

It would be useful for the draft to state how it fits into the CCAMP
WG, and how it relates to the charter.

One of my concerns is that exposing alarm information is something
that the providers may _not_ want. Moreover, there are already likely
to be other methods by which a provider coordinates alarm information
through their network (and layers), without having it be communicated 
explicitly via signaling.

Some clarification on these points would be useful. Until such time,
I would prefer to hold off on it being brought under the wing of the WG.

-Vishal

> Sent: Saturday, March 06, 2004 4:21 AM
> To: [email-masked]
> Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 6 Mar 2004 23:17:32 -0000

Thanks Vishal,

If you have issues or concerns about these drafts I'd appreciate it if you would raise
them on the list.
draft-lang-ccamp-gmpls-recovery-e2e-signaling is over 18 months old, so no-one can claim
unseemly haste!

Please note that adoption as a WG draft means
- the draft addresses a WG charter item
- the direction of the draft is approximately right
- the WG feels that this is something they want to work on

It does not mean that this draft is perfect and ready to become an RFC tomorrow.

Thanks,
Adrian

---

From: [email-masked]
Date: Sun, 07 Mar 2004 00:30:11 +0100

hi vishal,

> that the providers may _not_ want. 

for your information, the document explicitly mentions

"[...] The support of this functionality is optional.

The communication of alarms within GMPLS does not imply any
modification in behavior of processing of alarms, or for the
communication of alarms outside of GMPLS."

i think this concern has been addressed but you may want to
be a bit more specific on *your* expectation(s) so that the
authors may complete this section

> Moreover, there are already likely

i don't think this document puts this under questioning
- see also above

> I would prefer to hold off on it being brought under the wing of the WG.

i think there is a more broader issue here, wg i-d status
doesn't mean rfc status, it means this is a topic on which
the working group is interested to actively work on

thanks,
- dimitri.

---

From: [email-masked]
Date: Sun, 07 Mar 2004 01:10:36 +0100

all, i don't know where the end of the sentence has gone
but read the following "wg i-d status doesn't mean rfc
status, it means this is a topic on which the working
group is interested to actively work on starting from a
reasonable basis towards an acceptable and interoperable
solution for the wg."

note that all the words "reasonable" and "acceptable"
are imho to be gauged on a case by case basis depending
on the topic itself

thanks,
- dimitri.

---

From: "Vishal Sharma" <[email-masked]>
Date: Sat, 6 Mar 2004 17:38:06 -0800

Dmitri et al,

An important phrase missing from the definition
below is "in the charter" (also emphasized in Adrian's recent
clarifiction in another email). Thus,

"... WG i-d status does not mean RFC status, it means it is
a topic that [is in the charter] _and_ on which the WG is
intersted to actively work on, starting from a reasonable
basis towards an acceptable and interoperable solution
for the WG."

-Vishal

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Saturday, March 06, 2004 4:11 PM
> To: Vishal Sharma
> Cc: Adrian Farrel; [email-masked]
> Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>
>

---

From: "Vishal Sharma" <[email-masked]>
Date: Sat, 6 Mar 2004 17:40:16 -0800

Dmitri et al,

Actually, I think this is better worded as

 [for the industry]."

since the industry at large, and not just the WG, is the user of
any solution emerging from an IETF WG.

-Vishal

> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Saturday, March 06, 2004 5:38 PM
> To: [email-masked]
> Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>
>
> Dmitri et al,
>

---

From: [email-masked]
Date: Sun, 07 Mar 2004 06:46:07 +0100

vishal, well, this is why the wg expects as much
opinion/voices as possible

this said, would you be more specific about yours
(i.e. when you are questioning the use/applicability
of this method) such that the authors can address
it

thanks,
- dimitri.

ps: concerning the charter fitting imho either it
is considered as part of the cp mechanisms the wg
is expected to deliver (i.e. this could have been
part of RFC 3473) or it is the right time to add it
more explicitly in the charter (if so desired)

Vishal Sharma wrote:

>>>>>through their network (and layers), without having it be
>>
>>communicated
>>
>>>>>I would prefer to hold off on it being brought under the wing
>>>
>>>of the WG.
>>>
>>>>
>>>>>>Can you please send your opinions to the list or to the
>>
>>chairs direct.
>>

---

From: Lou Berger <[email-masked]>
Date: Sun, 07 Mar 2004 07:44:51 -0500

no surprise here, IMO yes.

At 07:20 AM 3/6/2004 -0500, Adrian Farrel wrote:

><http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt 
>
>
>Thanks,
>Adrian

---

From: Lou Berger <[email-masked]>
Date: Sun, 07 Mar 2004 07:44:19 -0500

Yes on all.

---

From: Lou Berger <[email-masked]>
Date: Sun, 07 Mar 2004 08:40:50 -0500

Vishal,

As to fit&charter:  This work extends the path setup portion of common 
control plane protocol defined by the WG, namely GMPLS-RSVP.  Additionally 
this work matches the work item, note asterisks "Define a protocol that can 
determine the actual route and **other properties** of paths set up by 
CCAMP signaling protocols..."  You might also want to check out Hiro 
Ishimatsu's comment  from last November on this topic on the list.

As to the other issues:  In addition to Dimitri's references, the document 
already states:

    Some operators may consider alarm information as sensitive.  To
    support environments where this is the case, implementations SHOULD
    allow the user to disable the generation of ALARM_SPEC objects.

also:

    The communication of alarms within GMPLS does not imply any
    modification in behavior of processing of alarms, or for the
    communication of alarms outside of GMPLS.

What additional clarifications do you think are need in the text?

Lou

At 03:45 PM 3/6/2004 -0500, Vishal Sharma wrote:

> > From: [email-masked] 
> [<mailto:[email-masked]>mailto:[email-masked]]On
> > Behalf Of Adrian Farrel
> <http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm 
>
> > -spec-01.txt
> >
> > Thanks,
> > Adrian
> >

---

From: "Vishal Sharma" <[email-masked]>
Date: Sun, 7 Mar 2004 13:37:16 -0800

Dimitri,

Thanks for the response.

Although the issue of what it takes for a document to become
a WG document was not really reaised in my original email, it
is good to have had some explanations about it.

With regards to the charter, as I already mentioned in my
original email, it is important for the WG to be clear on
what current charter item each specific document/work is trying to
address or solve, if any.
I think the Chairs have repeatedly made this clear over the
past several months, and I see value in that.

Also, the process of adding any work to the charter is a broader
undertaking. From the statement of the Chairs and ADs at Seoul, this
is something the WG is planning to undertake at some point, once
our current plate is cleared. And, it is a rather formal process
requiring approval from the ADs etc., so it is not a matter of
just adding an item "more explicitly" in the charter.

Whether or not this needs to be added to the charter should be addressed
closer to when the charter is up for revision, hopefully in a couple
of months.

-Vishal

> Behalf Of [email-masked]
> Sent: Saturday, March 06, 2004 9:46 PM
> To: Vishal Sharma

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 07 Mar 2004 18:48:02 -0500

yes

> >However, the draft is pretty stable, and it is the opinion of the 
> >authors
> >that this should
> ><http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls
-alarm-spe
>c-01.txt>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm
-spec-01.txt

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 07 Mar 2004 18:48:32 -0500

yes

-alarm-spe
-spec-01.txt

---

From: "Vishal Sharma" <[email-masked]>
Date: Sun, 7 Mar 2004 17:37:45 -0800

Hi Lou,

While the document describes well _what_ it is doing, I think it is
not clear on why this needs to be done, why it is important
(motivation), what requirements it is satisfying, and how they relate to
the current WG charter.
(Note this does not mean that the problem may not be important or should
not be in the charter.)

Also, in response to your explanation below, it is not really clear
that alarm reporting is a component of path setup. Seems to me that
the two are decoupled.
And, the "determing the actual route and other  properties" phrase
mentioned in the CCAMP WG charter I thought is aimed at addressing the
issue of tunnel tracing
(and determing LSP properties therefrom), rather than reporting alarms
at specific nodes along the path of an LSP.

With regard to your question, here is some additional feedback
on the draft:

-- The following phrase is actually unclear, as I explain below.

>     communication of alarms outside of GMPLS.

If there is no modification in the behavior of alarm processing, then
presumably there is already a way to monitor and process them, so how
(and with what) does this communication help?
(I have seen the few phrases in the document in Section 1, along the
lines of "there may be a desire to retain an LSP, particularly in
optical transport networks, and communicate
alarm information," but these do not say why.)

-- The technique described in this draft relies on existing
techniques for monitoring and correlating alarms, and appears to
focus on the communication of this information along an LSP
path.
(While it may be argued that the latter is a "monitoring"
function, I am not sure how strong an argument that is, since
the monitoring (or most of it) has presumably happened before this
communication begins.)

-- Also, are there interactions/race conditions between this alarm
communication with other mechanisms conveying problems along an LSP?
Some discussion in the doc. would be valuable.

-- The document mentions briefly that the LSP state must
be retained for the communicated alarm information to be useful.

I think this is an important point, and worth expanding on in the doc.
I don't think there is any discussion right now of how one might
ensure that state has not been torn down by the time the alarm
information is correlated and ready to be communicated upstream
and downstream.

-- And, can the document provide some examples of the types of alarms
it is talking about/referring to? I think this will help a reader
understand better the why behind this approach.

-- Finally, I wasn't sure if the issue of enumeration dicussed
with Tom Petch and Bert in Nov. was solved. (I saw that the draft
refers to GR833 for Error String enumerations and to the ALARM-MIB
for the Error Codes field.)

So these are my thoughts and feedback to the authors and WG.
It may be good to hear from some other WG participants who have also
read the document.

-Vishal

> From: Lou Berger [mailto:[email-masked]]
> Sent: Sunday, March 07, 2004 5:41 AM
> To: Vishal Sharma
> > > authors that this should
> <http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alar
> m>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm
> >
> > > -spec-01.txt
> > >
> > > Thanks,
> > > Adrian
> > >

---

From: [email-masked]
Date: Mon, 08 Mar 2004 17:14:35 +0100

yes to all.

---

From: Kohei Shiomoto <[email-masked]>
Date: Wed, 10 Mar 2004 10:01:40 +0900

Yes to all

-- 
Kohei Shiomoto
NTT Network Innovation Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone +81 422 59 4402    Fax +81 422 59 6387

---

From: Sudheer Dharanikota <[email-masked]>
Date: Wed, 10 Mar 2004 03:50:36 -0500

>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt
Yes

>http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
No opinion.

>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt
Yes

Yes.

- sudheer

---

From: Loa Andersson <[email-masked]>
Date: Wed, 10 Mar 2004 12:29:59 +0100

yes - to all

/Loa

-- 

Loa Andersson

mobile +46 739 81 21 64

---

From: Eiji Oki <[email-masked]>
Date: Wed, 10 Mar 2004 22:00:05 +0900

Yes to all.

Eiji

On Thu, 4 Mar 2004 11:46:04 -0000

---

From: "zafar ali" <[email-masked]>
Date: Thu, 11 Mar 2004 23:42:37 -0500

Adrian, 

Yes to all. 

Thanks
 
Regards... Zafar

>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Thursday, March 04, 2004 6:46 AM
>To: [email-masked]
>At the CCAMP meeting today we discussed making several drafts 
>working group items. Can you please express your opinion 
>(yes/no) on whether each of the following drafts is ready to 
>Feel free to express yes with reservations. If you have 
>reservations or objections, please express them on the list. 
>if you need anonymity for your comments then please filter 
>them through the chairs.
>

RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-
signaling-03.txt

GMPLS Based Segment Recovery
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-rec
overy-00.txt

Thank you,
Adrian