Subject: Response to ITU-T liaison on LMP transport terminology

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 31 Dec 2004 21:32:45 -0000

Hi,

I think it would be good if we could construct a response to the ITU-T
liaison about the use of terminology in the LMP transport draft.

Ideally we would send this to the Q14/15 rapporteur on or before 16th
January so that it can be read by everyone before the meeting later in the
month.

Is anyone prepared to step up and craft some text? Perhaps the draft's
authors have a little something to say?

I'm prepared to do the necessary work to put it into an appropriate
format.

By the way, if anyone has personal opinions about this terminology that
they want to raise for the meeting, they should send them to Kam Lam
([email-masked]) before 16th January so that he can take them as
contributions to the meeting.

Happy New Year,
Adrian

Delivery-date: Fri, 31 Dec 2004 21:35:08 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Response to ITU-T liaison on LMP transport terminology
Date: Fri, 31 Dec 2004 21:32:45 -0000

Hi,

I think it would be good if we could construct a response to the ITU-T
liaison about the use of terminology in the LMP transport draft.

Ideally we would send this to the Q14/15 rapporteur on or before 16th
January so that it can be read by everyone before the meeting later in the
month.

Is anyone prepared to step up and craft some text? Perhaps the draft's
authors have a little something to say?

I'm prepared to do the necessary work to put it into an appropriate
format.

By the way, if anyone has personal opinions about this terminology that
they want to raise for the meeting, they should send them to Kam Lam
([email-masked]) before 16th January so that he can take them as
contributions to the meeting.

Happy New Year,
Adrian

Delivery-date: Tue, 28 Dec 2004 16:58:27 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, [email-masked]
Subject: RE: Meeting about ASON/GMPLS terminology
Date: Tue, 28 Dec 2004 11:56:39 -0500

Dear Adrian and All,

I support Adrian's suggestion. Let us tentatively allocate Tuesday and Wednesday (i.e., January 25-26) for the ASON/GMPLS terminology discussion.

I have created a directory in the ITU-T informal FTP site for contributions
http://ties.itu.int/u/tsg15/sg15/xchange/wp3/q14/0501/wd/, which needs a ITU-T TIES account to access this site.

As you are invited to attend this interim meeting, I have also created a directory in the ITU-T public site at
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/wp3/q14/0501/wd/ for you to access the contributions and logistic information without the need of an ITU-T TIES account. I will try to synchronize the information in this public directory with the TIES directory as often as possible.

Deadline for contribution submission is midnight (U.S. EST) 16th January 2005.

If you plan to submit contributions, please send me the title as soon as possible so that I can assign you the Working Document (wd) numbers. When your contributions are ready for submission, please email me the files.

The meeting will start on Monday January 24th at 9:00 AM and will end on Friday January 28th at 12:00 noon.  

If you plan to attend but your name is not yet on the list at 
http://ties.itu.int/u/tsg15/sg15/xchange/wp3/q14/0501/wd/attendee_tentative.doc or
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/wp3/q14/0501/wd/attendee_tentative.doc 
please let me know. 

The closest airport to the meeting location is the Newark Liberty International Airport.
Detail logistic and venue information can be found at
http://ties.itu.int/u/tsg15/sg15/xchange/wp3/q14/0501/wd/logistic.doc and
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/wp3/q14/0501/wd/logistic.doc. 

Regards,
Kam

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, December 27, 2004 3:11 PM
> To: [email-masked]; Lam, Hing-Kam (Kam)
> Subject: Meeting about ASON/GMPLS terminology
> 
> 
> All,
> 
> In the recent liaison, Question 14 of Study Group 15 of the 
> ITU-T invited
> any CCAMP participants to a meeting to discuss and converge 
> terminology
> with respect to ASON and GMPLS, in particular in the context 
> of the LMP
> Transport draft.
> 
> The proposal is that some time will be allocated to this 
> topic during the
> Q14/15 interim meeting, in New Jersey, USA, running from 
> January 24-28.
> 
> There's probably a bit of a chicken and egg situation for 
> scheduling this
> as Kam would obviously like to pick a date and time when most 
> people can
> be there, and many people will not be able to confirm their attendance
> until the date and time is set. I think that the best idea 
> would be for
> Kam to set some probable constraints (for example, most 
> likely to meet on
> Tuesday or Wednesday).
> 
> At the same time, anyone who thinks that they might possibly 
> be able to
> attend for this discussion should drop Kam a note 
> ([email-masked]) as
> soon as possible. If you know that you have some constraints yourself,
> then let him know and he can try to factor this in.
> 
> Note, this is an open invitation to CCAMP participants. Your
> company/employer does not need to be an ITU-T member in order 
> for you to
> attend.
> 
> Hoping some of you can make this meeting and help resolve the 
> remaining
> terminology issues.
> 
> Adrian
> 

Delivery-date: Mon, 27 Dec 2004 21:29:50 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>
Subject: Meeting about ASON/GMPLS terminology
Date: Mon, 27 Dec 2004 20:11:07 -0000

All,

In the recent liaison, Question 14 of Study Group 15 of the ITU-T invited
any CCAMP participants to a meeting to discuss and converge terminology
with respect to ASON and GMPLS, in particular in the context of the LMP
Transport draft.

The proposal is that some time will be allocated to this topic during the
Q14/15 interim meeting, in New Jersey, USA, running from January 24-28.

There's probably a bit of a chicken and egg situation for scheduling this
as Kam would obviously like to pick a date and time when most people can
be there, and many people will not be able to confirm their attendance
until the date and time is set. I think that the best idea would be for
Kam to set some probable constraints (for example, most likely to meet on
Tuesday or Wednesday).

At the same time, anyone who thinks that they might possibly be able to
attend for this discussion should drop Kam a note ([email-masked]) as
soon as possible. If you know that you have some constraints yourself,
then let him know and he can try to factor this in.

Note, this is an open invitation to CCAMP participants. Your
company/employer does not need to be an ITU-T member in order for you to
attend.

Hoping some of you can make this meeting and help resolve the remaining
terminology issues.

Adrian

Delivery-date: Fri, 24 Dec 2004 19:21:47 +0000
Date: Wed, 22 Dec 2004 17:17:52 -0500
To: "Loa Andersson" <[email-masked]>
From: Lou Berger <[email-masked]>
Cc: [email-masked], Bill Fenner <[email-masked]>, [email-masked], [email-masked]
Subject: [mpls] Re: MPLS wg last call on re-spun bundling draft - ended

At 08:16 AM 12/20/2004, Loa Andersson wrote:

>I've asked the authors to update the draft according to
>comments and discussion.
>
>/Loa

Loa,
         We submitted the -06 version of draft-ietf-mpls-bundle today.  The 
updates were made based on the comments received during the last call 
period.  They include:
1) Noted that document also updates 3472 and 3473
2) Adding a table of contents
3) Clarified intent of "node scope."
4) Removed a duplicate paragraph
5) Fixed a number of typos
6) Removed some text that was redundant with RFC3472/RFC3473.
7) Clarified that in Path and REQUEST messages link identifiers MUST be 
specified from the sender's perspective.
8) Added a paragraph on Errored Component Identification
9) Updated references

We believe all issues raised during the WG last call have been addressed.

Much thanks to all who commented!

Lou (and Yakov and Kireeti)

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

Delivery-date: Fri, 24 Dec 2004 19:21:38 +0000
Date: Wed, 22 Dec 2004 17:17:52 -0500
To: "Loa Andersson" <[email-masked]>
From: Lou Berger <[email-masked]>
Cc: [email-masked], Bill Fenner <[email-masked]>, [email-masked], [email-masked]
Subject: [mpls] Re: MPLS wg last call on re-spun bundling draft - ended

At 08:16 AM 12/20/2004, Loa Andersson wrote:

>I've asked the authors to update the draft according to
>comments and discussion.
>
>/Loa

Loa,
         We submitted the -06 version of draft-ietf-mpls-bundle today.  The 
updates were made based on the comments received during the last call 
period.  They include:
1) Noted that document also updates 3472 and 3473
2) Adding a table of contents
3) Clarified intent of "node scope."
4) Removed a duplicate paragraph
5) Fixed a number of typos
6) Removed some text that was redundant with RFC3472/RFC3473.
7) Clarified that in Path and REQUEST messages link identifiers MUST be 
specified from the sender's perspective.
8) Added a paragraph on Errored Component Identification
9) Updated references

We believe all issues raised during the WG last call have been addressed.

Much thanks to all who commented!

Lou (and Yakov and Kireeti)

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

Delivery-date: Thu, 23 Dec 2004 13:41:08 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: <[email-masked]>, "Stephen J Trowbridge" <[email-masked]>
Subject: Re: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Thu, 23 Dec 2004 13:25:40 -0000

Ben,

[Some gratuitous snipping, throughout]

> > You are right. The liaison appears to state that there were some
> > comments on the draft made at the meeting which have not been
> > included in the liaison. I wonder why this would be?

> The liaison was submitted late to the SG15 meeting, 2 working days
> instead of the normal 7 (note the IETF's limit is 10), not giving
> participants sufficient time to read/review it.  Thus it was not
> possible to provide a liaison with a complete set of comments.  It was
> decided that there would be value in discussing the draft and
> communicating some comments nonetheless.

Agreed. It came late, and that made it hard for folks to read it. All
comments partial or full are welcome.

> > You say that...
> > > Just trying to answer the comments/questions that were recorded
> > > in the liaison would seem to be inadequate to meet the stated goal
> > > of the draft.
> >
> > Well, what can I say?
> > The intention of liaising this draft to SG15 was to allow people who
> > had not previously seen the draft (which has been around for a while
> > in the public domain)
>
> Yes, since September as a WG draft.

That's true.
And as a personal draft for about 18 months before that.

> > Had the liaison said "We are very concerned that there is a
> > significant mismatch in terminology in this draft and believe
> > that it should not be published without further face-to-face
> > discussions", this would have been a very significant issue. I
> > would, of course, have asked for some examples so that we
> > could qualify the problem. If the liaison had said "There
> > appears to be a major disconnect on the following terms..."
> > we would obviously have worked to resolve the disconnect
> > and welcomed face-to-face meetings as necessary.

> Well, I think the liaison was meant to convey something along
> those lines, albeit not in those words.

That's helpful. Thanks.

Would you say that the list of terms over which there is a disconnect is
limited to those explicitly mentioned in the liaison, or are there other
terms that we should bring into the discussion? Although other things
might come up in the course of discussions, it would be good to get as
much into the open now as is possible.

> > But the liaison hints (as you say) that there may be other issues that
> > are not mentioned in the liaison. So perhaps I can ask everyone to
> > think very hard and let me (or preferably the CCAMP mailing list)
> > know what those issues are.
>
> I presume the reason for providing a liaison to the ITU is that not all
> members of the ITU participate in the CCAMP mailing list, and if
> they do they cannot speak for the ITU, so there may be a problem
> with this process.

You're right that the purpose of the liaison is to give individuals who
participate in the ITU-T but not CCAMP to see the material and comment on
it. There are several ways that they can return their comments, one of
which is a return liaison, but this is not the only way - comments may be
returned to the authors, to the CCAMP chairs or to the CCAMP mailing list.
I believe I explained these options in Geneva.

In fact, what we really want is a host of contributions from everyone who
has an opinion. It is certainly useful to have "the view of the ITU", but
we are just as concerned to have individual contributions. So no-one
should hold up or mitigate their views waiting for ITU-T consensus.

> > The liaison also suggests that time at a future Q14/15 meeting
> > could be given over to align the views on terminology to facilitate
> > future progress. This certainly does not imply to me that there are
> > any issues in the current draft (beyond those raised in the current
> > liaison) that need to be addressed before the draft is published.

> Well, if the I-D purports to provide "an
>  overview of LMP in the context of the ITU-T Automatically Switched
>  Optical Networks (ASON) and transport network terminology and
>  relates it to the ITU-T discovery work to promote a common
>   understanding for progressing the work of IETF and ITU-T."
> then I would think that publishing it before reaching a common
> understanding would be counter to the purpose.

I agree on the your representation of the aims.
So back to my previous question, are there any specific issues beyond
those raised in the current liaison that need to be addressed? It's fine
if the answer is "None have been identified, but we're feeling really
uneasy about the draft."

> > I hope you don't think I'm being difficult, but when communications
> > are reduced to formal liaisons we must take the liaisons at face
value.
> > So I would urge (again) that anyone who has any issues with the
current
> > draft (or any CCAMP draft) should bring those issues to me or
> > (preferably) to the CCAMP mailing list without delay. If issues are
> > raised I will do my best to ensure that they are resolved.

> I am not trying to be difficult either.

Accepted.

> I think the difficulty arises
> from attempting to rush to publish the I-D.  If the liaison had been
> sent with sufficient time to review, a more complete response could
> have been given.

One man's rush is another man's delay, but I accept that greater time
might have generated a more thorough response.

> Even so, the need for further discussion has been
> identified, and I agree that a face-to-face meeting would be much more
> efficient than limiting the exchange to formal liaisons.  (In fact
> achieving common understanding may be more in the process than in the
> paper.)

Two points here.
1. The need for further discussion has not really been identified. I would
like to push for further details of what it is that needs discussion.
Let's look at this as "setting the agenda for the meeting."
2. I agree that face-to-face meetings are much more productive: this is
one of the reasons why I have attended all of the Q14/15 meetings in the
last year. On the other hand, turning up unprepared at an unplanned and
free-ranging discussion is also not hugely efficient. So let's expose the
issues for discussion now.

Happy Christmas,
Adrian

Delivery-date: Wed, 22 Dec 2004 22:26:44 +0000
Date: Wed, 22 Dec 2004 17:26:11 -0500
To: <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-02.txt
Cc: "Igor Bryskin" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, [email-masked], "Adrian Farrel" <[email-masked]>, [email-masked]

At 10:12 AM 12/7/2004, WG Chair wrote:

>So, for this draft, can we please have:
>- an email that shows what has been done to address each last call comment

Here are a summary of the changes made in 
draft-ietf-ccamp-gmpls-alarm-spec-02.txt:
1) Noted that RFC3473 is updated by the document
2) Reiterated the extension does not replace any (existing) data plane 
fault propagation techniques.
3) Made c-type 1 and 2 reserved, and removed related references
4) Clarified ordering requirements within the IF_ID ALARM_SPEC (and 
ERROR_SPEC) TLVs
5) Clarified Reference Count field definition
6) Clarified handling of Reserved field
7) Added clarification and reference to definition of Impact and Severity 
fields
8) Clarified length of Error String field
9) Clarified procedures related
10) Removed some redundant text
11) Corrected typos and add other minor clarification text

>- a clean version with
>    - page throws
>    - formatting fixed
>    - line lengths kept to the required minimum

Any issues introduced by the secretariat that aren't cleaned up by them 
will be corrected in the 48 hour Authors review or, if needed, in the next 
rev of the draft.  (as will the extra characters.)

Lou (and co-authors)

Delivery-date: Wed, 22 Dec 2004 22:18:48 +0000
Date: Wed, 22 Dec 2004 17:17:52 -0500
To: "Loa Andersson" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: MPLS wg last call on re-spun bundling draft - ended
Cc: "Loa Andersson" <[email-masked]>, <[email-masked]>, "George Swallow" <[email-masked]>, "Alex Zinin" <[email-masked]>, "Bill Fenner" <[email-masked]>, <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, [email-masked]

At 08:16 AM 12/20/2004, Loa Andersson wrote:

>I've asked the authors to update the draft according to
>comments and discussion.
>
>/Loa

Loa,
         We submitted the -06 version of draft-ietf-mpls-bundle today.  The 
updates were made based on the comments received during the last call 
period.  They include:
1) Noted that document also updates 3472 and 3473
2) Adding a table of contents
3) Clarified intent of "node scope."
4) Removed a duplicate paragraph
5) Fixed a number of typos
6) Removed some text that was redundant with RFC3472/RFC3473.
7) Clarified that in Path and REQUEST messages link identifiers MUST be 
specified from the sender's perspective.
8) Added a paragraph on Errored Component Identification
9) Updated references

We believe all issues raised during the WG last call have been addressed.

Much thanks to all who commented!

Lou (and Yakov and Kireeti)

Delivery-date: Wed, 22 Dec 2004 21:07:59 +0000
Content-class: urn:content-classes:message
Subject: RE: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Wed, 22 Dec 2004 15:06:00 -0600
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Stephen J Trowbridge" <[email-masked]>, <[email-masked]>

Adrian,

Please see comments in-line.

Regards,
Ben

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, December 21, 2004 8:45 AM
> To: Mack-Crane, T. Benjamin; Stephen J Trowbridge; [email-masked]
> Subject: Re: ITU-T SG15 comments on
draft-ietf-ccamp-transport-lmp-00.txt
>=20
> Thanks Ben,
>=20
> All paragraphs of the liaison are very relevant.
>=20
> I note that the two paragraphs that you quote suggest a meeting to
resolve
> disconnects in terminology. I also note that the liaison suggests that
the
> value of such a meeting would be to facilitate our future work
efforts.
> This seems like an excellent idea.
>=20
> You are right. The liaison appears to state that there were some
comments
> on the draft made at the meeting which have not been included in the
> liaison. I wonder why this would be?

The liaison was submitted late to the SG15 meeting, 2 working days
instead of the normal 7 (note the IETF's limit is 10), not giving
participants sufficient time to read/review it.  Thus it was not
possible to provide a liaison with a complete set of comments.  It was
decided that there would be value in discussing the draft and
communicating some comments nonetheless.

>=20
> You say that...
> > Just trying to answer the comments/questions that were recorded
> > in the liaison would seem to be inadequate to meet the stated goal
> > of the draft.
>=20
> Well, what can I say?
> The intention of liaising this draft to SG15 was to allow people who
had
> not previously seen the draft (which has been around for a while in
the
> public domain)=20

Yes, since September as a WG draft.

> the opportunity to comment while the draft was in working
> group last call. Working group last call (as I explained during the
SG15
> Question 14 and joint Q12/14 meetings in Geneva earlier this month)
means
> that the authors believe that the draft is complete - it is a check
with
> the rest of the working group that they agree.
> We received some useful feedback from Q12/15 in this liaison and the
> authors will be able to enhance the draft accordingly.
>=20
> Had the liaison said "We are very concerned that there is a
significant
> mismatch in terminology in this draft and believe that it should not
be
> published without further face-to-face discussions", this would have
been
> a very significant issue. I would, of course, have asked for some
examples
> so that we could qualify the problem. If the liaison had said "There
> appears to be a major disconnect on the following terms..." we would
> obviously have worked to resolve the disconnect and welcomed
face-to-face
> meetings as necessary.

Well, I think the liaison was meant to convey something along those
lines, albeit not in those words.

>=20
> But the liaison hints (as you say) that there may be other issues that
are
> not mentioned in the liaison. So perhaps I can ask everyone to think
very
> hard and let me (or preferably the CCAMP mailing list) know what those
> issues are.

I presume the reason for providing a liaison to the ITU is that not all
members of the ITU participate in the CCAMP mailing list, and if they do
they cannot speak for the ITU, so there may be a problem with this
process.

>=20
> The liaison also suggests that time at a future Q14/15 meeting could
be
> given over to align the views on terminology to facilitate future
> progress. This certainly does not imply to me that there are any
issues in
> the current draft (beyond those raised in the current liaison) that
need
> to be addressed before the draft is published.
>=20

Well, if the I-D purports to provide "an=20
   overview of LMP in the context of the ITU-T Automatically Switched=20
   Optical Networks (ASON) and transport network terminology and=20
   relates it to the ITU-T discovery work to promote a common=20
   understanding for progressing the work of IETF and ITU-T."
then I would think that publishing it before reaching a common
understanding would be counter to the purpose.

>=20
> I hope you don't think I'm being difficult, but when communications
are
> reduced to formal liaisons we must take the liaisons at face value. So
I
> would urge (again) that anyone who has any issues with the current
draft
> (or any CCAMP draft) should bring those issues to me or (preferably)
to
> the CCAMP mailing list without delay. If issues are raised I will do
my
> best to ensure that they are resolved.
>=20

I am not trying to be difficult either.  I think the difficulty arises
from attempting to rush to publish the I-D.  If the liaison had been
sent with sufficient time to review, a more complete response could have
been given.  Even so, the need for further discussion has been
identified, and I agree that a face-to-face meeting would be much more
efficient than limiting the exchange to formal liaisons.  (In fact
achieving common understanding may be more in the process than in the
paper.)

> But this is not open season on delaying this draft. The reason for a
last
> call and a liaison are clear: they provide a line in the sand.
Discovery
> of defects after that time is welcomed (all defect discovery is always
> welcomed), but there is a time and a place to actively search for
> problems.
>=20
> Regards,
> Adrian
> ----- Original Message -----
> From: "Mack-Crane, T. Benjamin" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>; "Stephen J Trowbridge"
> <[email-masked]>; <[email-masked]>
> Cc: "Don Fedyk" <[email-masked]>;
<[email-masked]>;
> "Brungard, Deborah A, ALABS" <[email-masked]>; "Jonathan Lang"
> <[email-masked]>; "Dimitri Papadimitriou"
> <[email-masked]>
> Sent: Monday, December 20, 2004 9:35 PM
> Subject: RE: ITU-T SG15 comments on
draft-ietf-ccamp-transport-lmp-00.txt
>=20
>=20
> Adrian and all,
>=20
> I think the first and last paragraphs of the liaison (see below) are
> quite relevant as well.  In particular, they suggest that the liaison
> does not provide all of the comments from SG15, and that joint
> discussion is needed (an invitation to participate in an upcoming
> meeting is included).  Just trying to answer the comments/questions
that
> were recorded in the liaison would seem to be inadequate to meet the
> stated goal of the draft.
>=20
> Regards,
> Ben
>=20
> "Q14/15 thanks the IETF CCAMP WG for providing us the draft document
> <draft-ietf-ccamp-transport-lmp-00.txt>. This I-D was discussed at the
> meeting and several of the comments are provided below.  Based upon
this
> discussion we believe it would be highly beneficial to have some joint
> discussions on terminology to ensure an aligned view to facilitate our
> future work efforts."
>=20
> "As noted above, these represent several of the comments discussed.
In
> order to progress our mutual understanding, we would like to invite
IETF
> participants to attend the January 24-28, 2005 Q14/15 interim meeting,
> in New Jersey, USA, where we could devote a session to terminology
> alignment.  We believe this effort will greatly benefit our future
> collaboration on control plane standards development.  We welcome IETF
> experts' participation in other sessions of the interim meeting as
well.
> Details of the meeting agenda will be provided prior to the meeting.
For
> those interested in further information and/or attending the interim
> meeting should contact the Rapporteur for Q.14/15 (H. Kam Lam,
> [email-masked]) by 10th January 2005."
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Adrian Farrel
> Sent: Friday, December 17, 2004 1:48 PM
> To: Stephen J Trowbridge; [email-masked]
> Cc: Don Fedyk; [email-masked]; Brungard, Deborah A, ALABS;
> Jonathan Lang; Dimitri Papadimitriou
> Subject: Re: ITU-T SG15 comments on
> draft-ietf-ccamp-transport-lmp-00.txt
>=20
> Thanks Steve,
>=20
> And available in glorious HTML
>=20
> Authors, the relevant text from the liaison is included below. I think
> we
> can assume it is no different to what will receive through the formal
> channels.
>=20
> Adrian
>=20
> =3D=3D=3D=3D=3D=3D=3D
>=20
> We have several questions of clarification, e.g., in section 3.1
> (paragraph 2) of the I-D, "The separation between the two processes
and
> corresponding two name spaces has the advantage that the discovery of
> the
> transport plane can be performed independent from that of the control
> plane (and vice-versa), and independent of the method used in each
name
> space. This allows assigning link connections in the control plane
> without
> the link connection being physically connected."
>   1.. What is the intention of the term independent, for example,
could
> it
> be indicating at a different time or different approaches?
>=20
>   2.. In the last sentence, is "assign" used in the context of the
> management plane, meaning management plane provisioning?  Is it
assumed
> that the transport plane resources supporting the link connection
> endpoints exist or do not exist?
> In section 4.2 (paragraph 2) of the I-D, "G.8080 refers to a component
> link as a variable adaptation function i.e. a single server layer
trail
> dynamically supporting different multiplexing structures." This could
be
> interpreted as indicating G.8080 defines the term "component link".
> G.8080 does not use this term.  Some clarification would be
beneficial.
> Initial reviews of the draft document have raised concerns about the
> possible misinterpretation in the usage of the term 'TE link'. As the
> draft notes, the definition of a TE link is concise. Some more clarity
> would be appreciated.  Our current understanding of this term includes
> the
> following:
>=20
>   1.. A TE link may be composed of resource from multiple (G.805)
layers
> in parallel.  If so, this is an important distinction as an SNPP link
is
> in a single layer only.
>=20
>   2.. An SNPP link may contain SNP link connections from various links
> (e.g., different STS-1s from a set of parallel OC -48 trails).  It is
> not
> clear if this is also true for TE links.  We think it may, but it is
not
> stated.
>=20
>   3.. SNPPs exist at different routing levels (not layers) and thus an
> SNPP link at a higher level can encompass SNPPs at a lower level (see
> Section 6.2.2 of G.8080 Amendment 2, which is attached for your
> convenience).  We think TE links may do this with bundles and FAs, but
> the
> definition is not clear to us.
> Please advise if this is a correct understanding or not.  This may
have
> an
> impact on the terminology mapping in the draft.  We think it would be
> beneficial to have a TE link definition that enables these
distinctions
> to
> be understood.
> In the table in section 4.2 "CP" is mapped to "Interface".  A
Connection
> Point is more closely related to a timeslot, wavelength, etc. rather
> than
> to an entire interface.  Similarly "CP Name" is mapped to "Interface
ID"
> while it might more closely relate to a "Label".  Joint discussion of
> the
> terminology mapping may be beneficial in reaching alignment on the
most
> accurate mapping.
>=20
>=20
> ----- Original Message -----
> From: "Stephen J Trowbridge" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>
> Cc: <[email-masked]>; "Don Fedyk" <[email-masked]>;
> <[email-masked]>; "Brungard, Deborah A, ALABS"
> <[email-masked]>; "Jonathan Lang" <[email-masked]>;
"Dimitri
> Papadimitriou" <[email-masked]>
> Sent: Friday, December 17, 2004 6:53 PM
> Subject: Re: ITU-T SG15 comments on
> draft-ietf-ccamp-transport-lmp-00.txt
>=20
>=20
> > Adrian,
> > I don't know why the TSB would not have sent out the liaison
> statements
> > generated from December 3. In any case, all of the liaison
statements
> to
> ccamp
> > that were generated in our meeting are available at the usual spot
in
> the FTP area:
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICA
> TIONS/index.html
> >
> > Follow the links for the ccamp working group.
> > Regards,
> > Steve
> >
> > On 12/17/2004 11:22 AM, Adrian Farrel wrote:
> > > Hi,
> > >
> > > Please note that these are the unofficial comments from SG15.
> > > I was present when this was discussed in the Q14/15 meeting in
> Geneva
> at
> > > the end of November / start of December, but I have not seen the
> final
> > > version of the material that they intended to liaise to us.
> > >
> > > Unfortunatley, the liaison response missed the deadline (set to
> allow
> good
> > > time after the Geneva meeting) and the WG last call (set to end
> after
> the
> > > liaison deadline). No matter; let's see what we can do with my
notes
> from
> > > the meeting.
> > >
> > > Thanks,
> > > Adrian
> > > =3D=3D=3D
> > >
> > > Section 3.1
> > >
> > > "The separation between the two processes and corresponding two
name
> > > spaces has the advantage that the discovery of the transport plane
> can
> be
> > > performed independent from that of the control plane (and
> vice-versa),
> and
> > > independent of the method used in each name space. This allows
> assigning
> > > link connections in the control plane without the link connection
> being
> > > physically connected."
> > >
> > > There were some questions about the term "independent". Does it
> imply
> a
> > > different mechanism or a different timing?
> > > Also, what is meant by the last sentence? Do the transport
resource
> exist
> > > or not when the control plane assignment is made?
> > >
> > > My understanding of this paragraph is that:
> > > - It is material extracted from G.8080 so Q14/15 should be better
> > >   placed to answer these questions than us.
> > > - The "independence" is precisely that raised in the final
question.
> > >    That is, assignment in the management plane is independent of
> > >    connectivity in the data plane. The two discovery processes
> > >    are fully independent (time and mechanism).
> > >
> > > Perhaps you can find a way to clarify the text.
> > >
> > >
> > >
> > > Section 4.2
> > >
> > > "G.8080 refers to a component link as a variable adaptation
> function"
> > >
> > > It was pointed out that G.8080 does not use the term "component
> link".
> > > Obviously what your text means is that the term "variable
adaptation
> > > function" used in G.8080 is broadly equivalent to the term
> "component
> > > link" used in [LMP] and [BUNDLE]. Perhaps you can change the
wording
> so
> > > that there is no misunderstanding possible.
> > >
> > >
> > > Section 4.2 table
> > >
> > > CP---Interface
> > > The meaning of the term "interface" was misunderstood in that it
> appeared
> > > to be applied in some non-IETF context, thus we are told that a CP
> is
> like
> > > a timeslot or wavelength not an interface. Further, the two
columns
> for
> > > port and component link terminology should make this clear.
> > > I don't believe we can go through the pain of writing out an
> explanation
> > > of every IETF term. This draft is intended to bring LMP transport
> within
> > > the view of the IETF, not the other way around.
> > >
> > >
> > > General comments on TE links
> > >
> > > There was (still) some considerable unquiet about the precise
nature
> of a
> > > TE link and how it maps to G.805/8080 concepts. There are a bunch
of
> > > specific questions about the definition of a TE link, and it is
not
> clear
> > > whether this is the right document to contain the answers. I
suggest
> that
> > > you have a go at answering the questions (we can liaise them back
to
> > > Q14/15 when we recieve the questions :-) and include them in the
> draft
> if
> > > you think it is appropriate.
> > >
> > > IMHO some of the questions are refusing to acknowledge the
abstract
> nature
> > > of a TE link, and the fact that it is not material how it is
> constructed
> > > at a lower level because it simply exists at the higher level. In
> any
> > > case, as I say above, this draft is intended to explain transport
> concepts
> > > so that the IETF can understand them, not the other way around.
> > >
> > > q1: Can a TE link use parallel resources from different transport
> layers?
> > > For example, could a TE link between LSR A and LSR B use a lambda
> and
> a
> > > timeslot from the same fiber? (Note that there is a claim that an
> SNPP
> > > cannot do this because it exists only within a single layer.)
> > >
> > > q2: Can a TE link use component resources from parallel links. For
> > > example, could a TE link be built from all of the red lambdas from
a
> > > collection of parallel fibers? Or could a TE link be built from
> different
> > > STS-1s from parallel OC-48s? (This is said to be true of SNPPs.)
> > >
> > > q3: Is it possible to build a TE link out of other TE links at
> different
> > > routing levels? This might (I suppose) involve bundling FAs to
> provide
> > > another TE link. Or possibly we are talking about concatenating
FAs
> to
> > > provide a path that is presented as a TE link. (Again, the claim
is
> that
> > > an SNPP link at one level can include SNPPs from a lower level).
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 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
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=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
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Delivery-date: Tue, 21 Dec 2004 17:27:01 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Incoming liaison (3) from ITU-T SG15
Date: Tue, 21 Dec 2004 16:36:56 -0000

Hi,

Here is the text of an incoming liaison just received.
In due course it will be posted at the IETF's liaison web site. Until then
you can see the original at http://www.olddog.co.uk/incoming.htm

Cheers,
Adrian

============
From: ITU-T SG15
To: CCAMP
For: Information
Subject: Response to Liaison Statement from IETF CCAMP WG on GMPLS MIB
Modules

Q.14/15 thanks the liaison statement from the IETF CCAMP WG and
appreciates the opportunity for providing input to the draft GMPLS MIB
modules. At our 29th November - 3rd December 2004 SG15 meeting, the drafts
were presented. No specific comments were raised. Q.14/15 delegates were
encouraged to continue reviewing the MIBs and to provide their comments
directly to the CCAMP mailing list or at the next Q.14/15 meeting, which
is planed for 24 - 28 January 2005.

At the 29 November - 3 December 2004 meeting, SG15 reached consensus on
new draft Recommendation G.7718/Y.1709 "Framework for ASON management".
This Recommendation addresses the management aspects of the ASON control
plane and the interaction between the management plane and the ASON
control plane. This Recommendation follows the TMN principles specified in
ITU-T Recommendation M.3010 and the ASON architecture principles specified
in Recommendation G.8080.

A copy of this document is attached for your information.

An electronic copy of this liaison statement is also available at
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

Attachment: Draft G.7718/Y.1709 (TD37/PLEN)
(attachment can be found at the alternate CCAMP web site]

Delivery-date: Tue, 21 Dec 2004 17:05:30 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Incoming liaison (2) from ITU-T SG15
Date: Tue, 21 Dec 2004 16:27:20 -0000

Hi,

Here is the text of an incoming liaison just received.
In due course it will be posted at the IETF's liaison web site. Until then
you can see the original at http://www.olddog.co.uk/incoming.htm

Cheers,
Adrian

============
From: ITU-T SG15
To: CCAMP
For: Action
Deadline: 15 March 2005
Subject: Response to IETF CCAMP WG on Comparison of LMP and ASON Discovery

Q14/15 thanks the IETF CCAMP WG for providing us the draft document
<draft-ietf-ccamp-transport-lmp-00.txt>. This I-D was discussed at the
meeting and several of the comments are provided below.  Based upon this
discussion we believe it would be highly beneficial to have some joint
discussions on terminology to ensure an aligned view to facilitate our
future work efforts.

We have several questions of clarification, e.g., in section 3.1
(paragraph 2) of the I-D, "The separation between the two processes and
corresponding two name spaces has the advantage that the discovery of the
transport plane can be performed independent from that of the control
plane (and vice-versa), and independent of the method used in each name
space. This allows assigning link connections in the control plane without
the link connection being physically connected."

What is the intention of the term independent, for example, could it be
indicating at a different time or different approaches?
In the last sentence, is "assign" used in the context of the management
plane, meaning management plane provisioning?  Is it assumed that the
transport plane resources supporting the link connection endpoints exist
or do not exist?
In section 4.2 (paragraph 2) of the I-D, "G.8080 refers to a component
link as a variable adaptation function i.e. a single server layer trail
dynamically supporting different multiplexing structures." This could be
interpreted as indicating G.8080 defines the term "component link".
G.8080 does not use this term.  Some clarification would be beneficial.

Initial reviews of the draft document have raised concerns about the
possible misinterpretation in the usage of the term 'TE link'. As the
draft notes, the definition of a TE link is concise. Some more clarity
would be appreciated.  Our current understanding of this term includes the
following:
A TE link may be composed of resource from multiple (G.805) layers in
parallel.  If so, this is an important distinction as an SNPP link is in a
single layer only.
An SNPP link may contain SNP link connections from various links (e.g.,
different STS-1s from a set of parallel OC -48 trails).  It is not clear
if this is also true for TE links.  We think it may, but it is not stated.
SNPPs exist at different routing levels (not layers) and thus an SNPP link
at a higher level can encompass SNPPs at a lower level (see Section 6.2.2
of G.8080 Amendment 2, which is attached for your convenience).  We think
TE links may do this with bundles and FAs, but the definition is not clear
to us.

Please advise if this is a correct understanding or not.  This may have an
impact on the terminology mapping in the draft.  We think it would be
beneficial to have a TE link definition that enables these distinctions to
be understood.

In the table in section 4.2 "CP" is mapped to "Interface".  A Connection
Point is more closely related to a timeslot, wavelength, etc. rather than
to an entire interface.  Similarly "CP Name" is mapped to "Interface ID"
while it might more closely relate to a "Label".  Joint discussion of the
terminology mapping may be beneficial in reaching alignment on the most
accurate mapping.
As noted above, these represent several of the comments discussed.  In
order to progress our mutual understanding, we would like to invite IETF
participants to attend the January 24-28, 2005 Q14/15 interim meeting, in
New Jersey, USA, where we could devote a session to terminology alignment.
We believe this effort will greatly benefit our future collaboration on
control plane standards development.  We welcome IETF experts'
participation in other sessions of the interim meeting as well. Details of
the meeting agenda will be provided prior to the meeting. For those
interested in further information and/or attending the interim meeting
should contact the Rapporteur for Q.14/15 (H. Kam Lam, [email-masked])
by 10th January 2005.

An electronic copy of this liaison and the attachments can be found at
<ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICAT
IONS/index.html >

Attachment: Editor's draft of G.8080 incorporating Amendment 2
[this can be seen at the CCAMP alternative web site]

Delivery-date: Tue, 21 Dec 2004 17:05:17 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Incoming liaison (4) from ITU-T SG15
Date: Tue, 21 Dec 2004 16:39:49 -0000

Hi,

Here is the text of an incoming liaison just received.
In due course it will be posted at the IETF's liaison web site. Until then
you can see the original at http://www.olddog.co.uk/incoming.htm

Cheers,
Adrian

============
From: ITU-T SG15
To: CCAMP
For: Information
Subject: ASON Routing Solutions status

Q.14/15 appreciates being informed of the status of the ASON Routing
Solution Design Team in the IETF via the liaison received, and looks
forward to future update to the status.
An electronic copy of this liaison and the attachments can be found at
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

Delivery-date: Tue, 21 Dec 2004 17:05:05 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Incoming liaison (1) from ITU-T SG15
Date: Tue, 21 Dec 2004 16:17:44 -0000

Hi,

Here is the text of an incoming liaison just received.
In due course it will be posted at the IETF's liaison web site. Until then
you can see the original at http://www.olddog.co.uk/incoming.htm

Cheers,
Adrian

============
From: ITU-T SG15
To: CCAMP
For: Action
Deadline: 15 March 2005
Subject: Crankback in GMPLS Systems

Q14 wishes to thank CCAMP for information regarding the crankback
signalling capability.  <draft-ietf-ccamp-crankback-03.txt> was discussed
and is helpful to Q14 in the development of crankback requirements.  As
requested, we have the following comments on the I-D for your
consideration of the next version of the draft:

1.       Semantics of the term "node".  Due to the GMPLS principle of
maintaining separation of control and transport (data/bearer) planes,
there are two meanings for the term "node".  First, an instance of a
signalling protocol (and/or routing protocol) that has some transport
resources in its scope.  Second, a transport plane resource such as a
cross connect.  Using the first meaning, a node is not the context for the
interface identifiers that are passed in crankback TLVs.  Throughout the
document the particular meaning can be determined by the context of the
term.  Examples are:

- Section 5.2, the sentence "Otherwise, multiple nodes might attempt to
repair the LSP." means the control functions of signalling and routing.

- Section 7.1 "As described above, full crankback information SHOULD
indicate the node, link and other resources, which have been attempted."
refers to the transport resource.

There are some occasions where the use of the term appear to be ambiguous
and clarity would be appreciated.  In particular TLV types 10 and 32.  If
type 10 represents a routing and signalling function, then what TLV
describes the "transport plane node" (e.g., cross connect or Network
Element)?  If type 32 means "transport plane nodes", then a different TLV
may be needed to identify the "routing/signalling nodes" that have already
participated in crankback attempts.
Having a clearer distinction between control plane functions and transport
plane resources would be helpful.

2.       When crankback information is received at a "routing/signalling
node", can it be used by the routing path computation function for other
LSP requests than the LSP whose signalling caused the crankback action?

3.       Section 6.1 "Segment-based Re-routing" option.  It is not clear
what this means.  Can multiple "routing/signalling nodes" perform
crankback on the same LSP at the same time if this flag is set?

4.       Section 4.3 History persistence.  If a repair point (a
"routing/signalling node") is unsuccessful in a crankback attempt, is it
possible for it to be not involved when another repair point (e.g., closer
to the source) succeeds in a crankback attempt.  If so, how does the first
repair point know to clear its history?

5.       Section 4.5 Retries.  Some guidance on setting the number of
retries may be helpful as this is a distributed parameter.  Is it set to
be the same value at all points that can perform crankback within one
network?

An electronic copy of this liaison and the attachments can be found at
<ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICAT
IONS/index.html >

Delivery-date: Tue, 21 Dec 2004 16:22:43 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Mack-Crane, T. Benjamin" <[email-masked]>, "Stephen J Trowbridge" <[email-masked]>, <[email-masked]>
Subject: Re: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Tue, 21 Dec 2004 14:44:34 -0000

Thanks Ben,

All paragraphs of the liaison are very relevant.

I note that the two paragraphs that you quote suggest a meeting to resolve
disconnects in terminology. I also note that the liaison suggests that the
value of such a meeting would be to facilitate our future work efforts.
This seems like an excellent idea.

You are right. The liaison appears to state that there were some comments
on the draft made at the meeting which have not been included in the
liaison. I wonder why this would be?

You say that...
> Just trying to answer the comments/questions that were recorded
> in the liaison would seem to be inadequate to meet the stated goal
> of the draft.

Well, what can I say?
The intention of liaising this draft to SG15 was to allow people who had
not previously seen the draft (which has been around for a while in the
public domain) the opportunity to comment while the draft was in working
group last call. Working group last call (as I explained during the SG15
Question 14 and joint Q12/14 meetings in Geneva earlier this month) means
that the authors believe that the draft is complete - it is a check with
the rest of the working group that they agree.
We received some useful feedback from Q12/15 in this liaison and the
authors will be able to enhance the draft accordingly.

Had the liaison said "We are very concerned that there is a significant
mismatch in terminology in this draft and believe that it should not be
published without further face-to-face discussions", this would have been
a very significant issue. I would, of course, have asked for some examples
so that we could qualify the problem. If the liaison had said "There
appears to be a major disconnect on the following terms..." we would
obviously have worked to resolve the disconnect and welcomed face-to-face
meetings as necessary.

But the liaison hints (as you say) that there may be other issues that are
not mentioned in the liaison. So perhaps I can ask everyone to think very
hard and let me (or preferably the CCAMP mailing list) know what those
issues are.

The liaison also suggests that time at a future Q14/15 meeting could be
given over to align the views on terminology to facilitate future
progress. This certainly does not imply to me that there are any issues in
the current draft (beyond those raised in the current liaison) that need
to be addressed before the draft is published.

I hope you don't think I'm being difficult, but when communications are
reduced to formal liaisons we must take the liaisons at face value. So I
would urge (again) that anyone who has any issues with the current draft
(or any CCAMP draft) should bring those issues to me or (preferably) to
the CCAMP mailing list without delay. If issues are raised I will do my
best to ensure that they are resolved.

But this is not open season on delaying this draft. The reason for a last
call and a liaison are clear: they provide a line in the sand. Discovery
of defects after that time is welcomed (all defect discovery is always
welcomed), but there is a time and a place to actively search for
problems.

Regards,
Adrian
----- Original Message ----- 
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "Stephen J Trowbridge"
<[email-masked]>; <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>; <[email-masked]>;
"Brungard, Deborah A, ALABS" <[email-masked]>; "Jonathan Lang"
<[email-masked]>; "Dimitri Papadimitriou"
<[email-masked]>
Sent: Monday, December 20, 2004 9:35 PM
Subject: RE: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt

Adrian and all,

I think the first and last paragraphs of the liaison (see below) are
quite relevant as well.  In particular, they suggest that the liaison
does not provide all of the comments from SG15, and that joint
discussion is needed (an invitation to participate in an upcoming
meeting is included).  Just trying to answer the comments/questions that
were recorded in the liaison would seem to be inadequate to meet the
stated goal of the draft.

Regards,
Ben

"Q14/15 thanks the IETF CCAMP WG for providing us the draft document
<draft-ietf-ccamp-transport-lmp-00.txt>. This I-D was discussed at the
meeting and several of the comments are provided below.  Based upon this
discussion we believe it would be highly beneficial to have some joint
discussions on terminology to ensure an aligned view to facilitate our
future work efforts."

"As noted above, these represent several of the comments discussed.  In
order to progress our mutual understanding, we would like to invite IETF
participants to attend the January 24-28, 2005 Q14/15 interim meeting,
in New Jersey, USA, where we could devote a session to terminology
alignment.  We believe this effort will greatly benefit our future
collaboration on control plane standards development.  We welcome IETF
experts' participation in other sessions of the interim meeting as well.
Details of the meeting agenda will be provided prior to the meeting. For
those interested in further information and/or attending the interim
meeting should contact the Rapporteur for Q.14/15 (H. Kam Lam,
[email-masked]) by 10th January 2005."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Friday, December 17, 2004 1:48 PM
To: Stephen J Trowbridge; [email-masked]
Cc: Don Fedyk; [email-masked]; Brungard, Deborah A, ALABS;
Jonathan Lang; Dimitri Papadimitriou
Subject: Re: ITU-T SG15 comments on
draft-ietf-ccamp-transport-lmp-00.txt

Thanks Steve,

And available in glorious HTML

Authors, the relevant text from the liaison is included below. I think
we
can assume it is no different to what will receive through the formal
channels.

Adrian

=======

We have several questions of clarification, e.g., in section 3.1
(paragraph 2) of the I-D, "The separation between the two processes and
corresponding two name spaces has the advantage that the discovery of
the
transport plane can be performed independent from that of the control
plane (and vice-versa), and independent of the method used in each name
space. This allows assigning link connections in the control plane
without
the link connection being physically connected."
  1.. What is the intention of the term independent, for example, could
it
be indicating at a different time or different approaches?

  2.. In the last sentence, is "assign" used in the context of the
management plane, meaning management plane provisioning?  Is it assumed
that the transport plane resources supporting the link connection
endpoints exist or do not exist?
In section 4.2 (paragraph 2) of the I-D, "G.8080 refers to a component
link as a variable adaptation function i.e. a single server layer trail
dynamically supporting different multiplexing structures." This could be
interpreted as indicating G.8080 defines the term "component link".
G.8080 does not use this term.  Some clarification would be beneficial.
Initial reviews of the draft document have raised concerns about the
possible misinterpretation in the usage of the term 'TE link'. As the
draft notes, the definition of a TE link is concise. Some more clarity
would be appreciated.  Our current understanding of this term includes
the
following:

  1.. A TE link may be composed of resource from multiple (G.805) layers
in parallel.  If so, this is an important distinction as an SNPP link is
in a single layer only.

  2.. An SNPP link may contain SNP link connections from various links
(e.g., different STS-1s from a set of parallel OC -48 trails).  It is
not
clear if this is also true for TE links.  We think it may, but it is not
stated.

  3.. SNPPs exist at different routing levels (not layers) and thus an
SNPP link at a higher level can encompass SNPPs at a lower level (see
Section 6.2.2 of G.8080 Amendment 2, which is attached for your
convenience).  We think TE links may do this with bundles and FAs, but
the
definition is not clear to us.
Please advise if this is a correct understanding or not.  This may have
an
impact on the terminology mapping in the draft.  We think it would be
beneficial to have a TE link definition that enables these distinctions
to
be understood.
In the table in section 4.2 "CP" is mapped to "Interface".  A Connection
Point is more closely related to a timeslot, wavelength, etc. rather
than
to an entire interface.  Similarly "CP Name" is mapped to "Interface ID"
while it might more closely relate to a "Label".  Joint discussion of
the
terminology mapping may be beneficial in reaching alignment on the most
accurate mapping.

----- Original Message ----- 
From: "Stephen J Trowbridge" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; "Don Fedyk" <[email-masked]>;
<[email-masked]>; "Brungard, Deborah A, ALABS"
<[email-masked]>; "Jonathan Lang" <[email-masked]>; "Dimitri
Papadimitriou" <[email-masked]>
Sent: Friday, December 17, 2004 6:53 PM
Subject: Re: ITU-T SG15 comments on
draft-ietf-ccamp-transport-lmp-00.txt

> Adrian,
> I don't know why the TSB would not have sent out the liaison
statements
> generated from December 3. In any case, all of the liaison statements
to
ccamp
> that were generated in our meeting are available at the usual spot in
the FTP area:
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICA
TIONS/index.html
>
> Follow the links for the ccamp working group.
> Regards,
> Steve
>
> On 12/17/2004 11:22 AM, Adrian Farrel wrote:
> > Hi,
> >
> > Please note that these are the unofficial comments from SG15.
> > I was present when this was discussed in the Q14/15 meeting in
Geneva
at
> > the end of November / start of December, but I have not seen the
final
> > version of the material that they intended to liaise to us.
> >
> > Unfortunatley, the liaison response missed the deadline (set to
allow
good
> > time after the Geneva meeting) and the WG last call (set to end
after
the
> > liaison deadline). No matter; let's see what we can do with my notes
from
> > the meeting.
> >
> > Thanks,
> > Adrian
> > ===
> >
> > Section 3.1
> >
> > "The separation between the two processes and corresponding two name
> > spaces has the advantage that the discovery of the transport plane
can
be
> > performed independent from that of the control plane (and
vice-versa),
and
> > independent of the method used in each name space. This allows
assigning
> > link connections in the control plane without the link connection
being
> > physically connected."
> >
> > There were some questions about the term "independent". Does it
imply
a
> > different mechanism or a different timing?
> > Also, what is meant by the last sentence? Do the transport resource
exist
> > or not when the control plane assignment is made?
> >
> > My understanding of this paragraph is that:
> > - It is material extracted from G.8080 so Q14/15 should be better
> >   placed to answer these questions than us.
> > - The "independence" is precisely that raised in the final question.
> >    That is, assignment in the management plane is independent of
> >    connectivity in the data plane. The two discovery processes
> >    are fully independent (time and mechanism).
> >
> > Perhaps you can find a way to clarify the text.
> >
> >
> >
> > Section 4.2
> >
> > "G.8080 refers to a component link as a variable adaptation
function"
> >
> > It was pointed out that G.8080 does not use the term "component
link".
> > Obviously what your text means is that the term "variable adaptation
> > function" used in G.8080 is broadly equivalent to the term
"component
> > link" used in [LMP] and [BUNDLE]. Perhaps you can change the wording
so
> > that there is no misunderstanding possible.
> >
> >
> > Section 4.2 table
> >
> > CP---Interface
> > The meaning of the term "interface" was misunderstood in that it
appeared
> > to be applied in some non-IETF context, thus we are told that a CP
is
like
> > a timeslot or wavelength not an interface. Further, the two columns
for
> > port and component link terminology should make this clear.
> > I don't believe we can go through the pain of writing out an
explanation
> > of every IETF term. This draft is intended to bring LMP transport
within
> > the view of the IETF, not the other way around.
> >
> >
> > General comments on TE links
> >
> > There was (still) some considerable unquiet about the precise nature
of a
> > TE link and how it maps to G.805/8080 concepts. There are a bunch of
> > specific questions about the definition of a TE link, and it is not
clear
> > whether this is the right document to contain the answers. I suggest
that
> > you have a go at answering the questions (we can liaise them back to
> > Q14/15 when we recieve the questions :-) and include them in the
draft
if
> > you think it is appropriate.
> >
> > IMHO some of the questions are refusing to acknowledge the abstract
nature
> > of a TE link, and the fact that it is not material how it is
constructed
> > at a lower level because it simply exists at the higher level. In
any
> > case, as I say above, this draft is intended to explain transport
concepts
> > so that the IETF can understand them, not the other way around.
> >
> > q1: Can a TE link use parallel resources from different transport
layers?
> > For example, could a TE link between LSR A and LSR B use a lambda
and
a
> > timeslot from the same fiber? (Note that there is a claim that an
SNPP
> > cannot do this because it exists only within a single layer.)
> >
> > q2: Can a TE link use component resources from parallel links. For
> > example, could a TE link be built from all of the red lambdas from a
> > collection of parallel fibers? Or could a TE link be built from
different
> > STS-1s from parallel OC-48s? (This is said to be true of SNPPs.)
> >
> > q3: Is it possible to build a TE link out of other TE links at
different
> > routing levels? This might (I suppose) involve bundling FAs to
provide
> > another TE link. Or possibly we are talking about concatenating FAs
to
> > provide a path that is presented as a TE link. (Again, the claim is
that
> > an SNPP link at one level can include SNPPs from a lower level).
> >
> >
> >
> >
> >
> >
>
>
>
>
>
============================================================
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
============================================================

Delivery-date: Mon, 20 Dec 2004 21:37:01 +0000
Content-class: urn:content-classes:message
Subject: RE: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Mon, 20 Dec 2004 15:35:29 -0600
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Stephen J Trowbridge" <[email-masked]>, <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Jonathan Lang" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>

Adrian and all,

I think the first and last paragraphs of the liaison (see below) are
quite relevant as well.  In particular, they suggest that the liaison
does not provide all of the comments from SG15, and that joint
discussion is needed (an invitation to participate in an upcoming
meeting is included).  Just trying to answer the comments/questions that
were recorded in the liaison would seem to be inadequate to meet the
stated goal of the draft.

Regards,
Ben

"Q14/15 thanks the IETF CCAMP WG for providing us the draft document
<draft-ietf-ccamp-transport-lmp-00.txt>. This I-D was discussed at the
meeting and several of the comments are provided below.  Based upon this
discussion we believe it would be highly beneficial to have some joint
discussions on terminology to ensure an aligned view to facilitate our
future work efforts."

"As noted above, these represent several of the comments discussed.  In
order to progress our mutual understanding, we would like to invite IETF
participants to attend the January 24-28, 2005 Q14/15 interim meeting,
in New Jersey, USA, where we could devote a session to terminology
alignment.  We believe this effort will greatly benefit our future
collaboration on control plane standards development.  We welcome IETF
experts' participation in other sessions of the interim meeting as well.
Details of the meeting agenda will be provided prior to the meeting. For
those interested in further information and/or attending the interim
meeting should contact the Rapporteur for Q.14/15 (H. Kam Lam,
[email-masked]) by 10th January 2005."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Friday, December 17, 2004 1:48 PM
To: Stephen J Trowbridge; [email-masked]
Cc: Don Fedyk; [email-masked]; Brungard, Deborah A, ALABS;
Jonathan Lang; Dimitri Papadimitriou
Subject: Re: ITU-T SG15 comments on
draft-ietf-ccamp-transport-lmp-00.txt

Thanks Steve,

And available in glorious HTML

Authors, the relevant text from the liaison is included below. I think
we
can assume it is no different to what will receive through the formal
channels.

Adrian

=3D=3D=3D=3D=3D=3D=3D

We have several questions of clarification, e.g., in section 3.1
(paragraph 2) of the I-D, "The separation between the two processes and
corresponding two name spaces has the advantage that the discovery of
the
transport plane can be performed independent from that of the control
plane (and vice-versa), and independent of the method used in each name
space. This allows assigning link connections in the control plane
without
the link connection being physically connected."
  1.. What is the intention of the term independent, for example, could
it
be indicating at a different time or different approaches?

  2.. In the last sentence, is "assign" used in the context of the
management plane, meaning management plane provisioning?  Is it assumed
that the transport plane resources supporting the link connection
endpoints exist or do not exist?
In section 4.2 (paragraph 2) of the I-D, "G.8080 refers to a component
link as a variable adaptation function i.e. a single server layer trail
dynamically supporting different multiplexing structures." This could be
interpreted as indicating G.8080 defines the term "component link".
G=2E8080 does not use this term.  Some clarification would be beneficial.
Initial reviews of the draft document have raised concerns about the
possible misinterpretation in the usage of the term 'TE link'. As the
draft notes, the definition of a TE link is concise. Some more clarity
would be appreciated.  Our current understanding of this term includes
the
following:

  1.. A TE link may be composed of resource from multiple (G.805) layers
in parallel.  If so, this is an important distinction as an SNPP link is
in a single layer only.

  2.. An SNPP link may contain SNP link connections from various links
(e.g., different STS-1s from a set of parallel OC -48 trails).  It is
not
clear if this is also true for TE links.  We think it may, but it is not
stated.

  3.. SNPPs exist at different routing levels (not layers) and thus an
SNPP link at a higher level can encompass SNPPs at a lower level (see
Section 6.2.2 of G.8080 Amendment 2, which is attached for your
convenience).  We think TE links may do this with bundles and FAs, but
the
definition is not clear to us.
Please advise if this is a correct understanding or not.  This may have
an
impact on the terminology mapping in the draft.  We think it would be
beneficial to have a TE link definition that enables these distinctions
to
be understood.
In the table in section 4.2 "CP" is mapped to "Interface".  A Connection
Point is more closely related to a timeslot, wavelength, etc. rather
than
to an entire interface.  Similarly "CP Name" is mapped to "Interface ID"
while it might more closely relate to a "Label".  Joint discussion of
the
terminology mapping may be beneficial in reaching alignment on the most
accurate mapping.

----- Original Message -----=20
From: "Stephen J Trowbridge" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; "Don Fedyk" <[email-masked]>;
<[email-masked]>; "Brungard, Deborah A, ALABS"
<[email-masked]>; "Jonathan Lang" <[email-masked]>; "Dimitri
Papadimitriou" <[email-masked]>
Sent: Friday, December 17, 2004 6:53 PM
Subject: Re: ITU-T SG15 comments on
draft-ietf-ccamp-transport-lmp-00.txt

> Adrian,
> I don't know why the TSB would not have sent out the liaison
statements
> generated from December 3. In any case, all of the liaison statements
to
ccamp
> that were generated in our meeting are available at the usual spot in
the FTP area:
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICA
TIONS/index.html
>
> Follow the links for the ccamp working group.
> Regards,
> Steve
>
> On 12/17/2004 11:22 AM, Adrian Farrel wrote:
> > Hi,
> >
> > Please note that these are the unofficial comments from SG15.
> > I was present when this was discussed in the Q14/15 meeting in
Geneva
at
> > the end of November / start of December, but I have not seen the
final
> > version of the material that they intended to liaise to us.
> >
> > Unfortunatley, the liaison response missed the deadline (set to
allow
good
> > time after the Geneva meeting) and the WG last call (set to end
after
the
> > liaison deadline). No matter; let's see what we can do with my notes
from
> > the meeting.
> >
> > Thanks,
> > Adrian
> > =3D=3D=3D
> >
> > Section 3.1
> >
> > "The separation between the two processes and corresponding two name
> > spaces has the advantage that the discovery of the transport plane
can
be
> > performed independent from that of the control plane (and
vice-versa),
and
> > independent of the method used in each name space. This allows
assigning
> > link connections in the control plane without the link connection
being
> > physically connected."
> >
> > There were some questions about the term "independent". Does it
imply
a
> > different mechanism or a different timing?
> > Also, what is meant by the last sentence? Do the transport resource
exist
> > or not when the control plane assignment is made?
> >
> > My understanding of this paragraph is that:
> > - It is material extracted from G.8080 so Q14/15 should be better
> >   placed to answer these questions than us.
> > - The "independence" is precisely that raised in the final question.
> >    That is, assignment in the management plane is independent of
> >    connectivity in the data plane. The two discovery processes
> >    are fully independent (time and mechanism).
> >
> > Perhaps you can find a way to clarify the text.
> >
> >
> >
> > Section 4.2
> >
> > "G.8080 refers to a component link as a variable adaptation
function"
> >
> > It was pointed out that G.8080 does not use the term "component
link".
> > Obviously what your text means is that the term "variable adaptation
> > function" used in G.8080 is broadly equivalent to the term
"component
> > link" used in [LMP] and [BUNDLE]. Perhaps you can change the wording
so
> > that there is no misunderstanding possible.
> >
> >
> > Section 4.2 table
> >
> > CP---Interface
> > The meaning of the term "interface" was misunderstood in that it
appeared
> > to be applied in some non-IETF context, thus we are told that a CP
is
like
> > a timeslot or wavelength not an interface. Further, the two columns
for
> > port and component link terminology should make this clear.
> > I don't believe we can go through the pain of writing out an
explanation
> > of every IETF term. This draft is intended to bring LMP transport
within
> > the view of the IETF, not the other way around.
> >
> >
> > General comments on TE links
> >
> > There was (still) some considerable unquiet about the precise nature
of a
> > TE link and how it maps to G.805/8080 concepts. There are a bunch of
> > specific questions about the definition of a TE link, and it is not
clear
> > whether this is the right document to contain the answers. I suggest
that
> > you have a go at answering the questions (we can liaise them back to
> > Q14/15 when we recieve the questions :-) and include them in the
draft
if
> > you think it is appropriate.
> >
> > IMHO some of the questions are refusing to acknowledge the abstract
nature
> > of a TE link, and the fact that it is not material how it is
constructed
> > at a lower level because it simply exists at the higher level. In
any
> > case, as I say above, this draft is intended to explain transport
concepts
> > so that the IETF can understand them, not the other way around.
> >
> > q1: Can a TE link use parallel resources from different transport
layers?
> > For example, could a TE link between LSR A and LSR B use a lambda
and
a
> > timeslot from the same fiber? (Note that there is a claim that an
SNPP
> > cannot do this because it exists only within a single layer.)
> >
> > q2: Can a TE link use component resources from parallel links. For
> > example, could a TE link be built from all of the red lambdas from a
> > collection of parallel fibers? Or could a TE link be built from
different
> > STS-1s from parallel OC-48s? (This is said to be true of SNPPs.)
> >
> > q3: Is it possible to build a TE link out of other TE links at
different
> > routing levels? This might (I suppose) involve bundling FAs to
provide
> > another TE link. Or possibly we are talking about concatenating FAs
to
> > provide a path that is presented as a TE link. (Again, the claim is
that
> > an SNPP link at one level can include SNPPs from a lower level).
> >
> >
> >
> >
> >
> >
>
>
>
>
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Delivery-date: Mon, 20 Dec 2004 13:30:38 +0000
Date: Mon, 20 Dec 2004 14:16:32 +0100
From: Loa Andersson <[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: [email-masked], Bill Fenner <[email-masked]>, [email-masked]
Subject: [mpls] MPLS wg last call on re-spun bundling draft - ended

All,

this mail is to close the wg last call on the re-spun
bundling draft. We've had very few comments, which is
acceptable because of the limited scope of the last call.

However we would need info on existing implementations
of draft-ietf-mpls-bundle-05.txt.

I've asked the authors to update the draft according to
comments and discussion.

/Loa

Loa Andersson wrote:
> Working group,
> 
> this is to initiate a 2 weeks working group last call on
> <>
> 
> The CCAMP working is copied on this MPLS working group last,
> since there are interdependencies between specifications from
> both working groups. Pleae use the MPLS mailing list for
> comments, cross-publishing is not necessary.
> 
> Background: This draft was reviewed by the IESG and approved
> for publication. During implementation there were some issues
> found and it was decided to pull the draft from the RFC Editors
> queue. This wg last call is limited to these issues and how
> they been addressed only.
> 
> The list of issues and how the authors has addresed has been
> sent to the mailing list(s). That text is also included in this
> mail.
> 
> For the record please note that I've asked the authors to
> update some ID-nits, those are not part of the wg last call.
> But has been included just to make it easier to progress the
> document through IESG review.
> 
> This working group last call ends on EOB December 10 PST.
> 
> /Loa
> 
> ------- issues and how they been addressed -------------
> Here is the summary:
> 
> draft-ietf-mpls-bundle-05.txt has been updated to reflect
> the comments made in the MPLS WG and on the list.  The issues
> raised are:
> 
> 1. Scope of component identifiers is open to interpretation
>    (i.e., node vs link)
> 2. No way to specify different upstream and downstream components
>    then using TLV types 1, 2 and 3
> 3. Ambiguity of contents of the IP address field in TLV types 3, 4, 5
> 4. Lack of IPv6 support for types 3, 4, and 5.
> 5. Ambiguity of when to use types 4 and 5 and when to use type 3.
> 6. No coverage of ERO and RRO implications
> 
> These issues have been addressed in the following ways:
> 
> Issue 1:  The -05 document states that all component link TLV types
>           have Node/IP scope
> Issue 2: -05 Tightly defines support for different components in each
>           direction (for bidirectional LSPs, and for all TLV types)
> Issue 3: Format of the Value field for types 3, 4 and 5 now has the
>           identical format as the contents of the C-Type 1
>           LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477].
> Issue 4: Based on the previous change, support of IPv6 unnumbered
>           components is now tied to, and the same as, the support of
>           IPv6 unnumber TE links.
> Issue 5: -05 allows, but recommend against use of types 4 and 5
> Issue 6: EROs, RROs remain out of scope of bundling document
> 
> Current planned changes are:
> - Fix nits found by Adrian and Loa
> - Insert a Table of Contents
> - Section numbering will remain unchanged so as not to break
>   any potentially existing references to the draft
> 
> Yakov.
> -------------------- end of included text --------------------
> 
> Loa Andersson
> 
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                            [email-masked]
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

Delivery-date: Mon, 20 Dec 2004 13:30:32 +0000
Date: Mon, 20 Dec 2004 14:16:32 +0100
From: Loa Andersson <[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: [email-masked], Bill Fenner <[email-masked]>, [email-masked]
Subject: [mpls] MPLS wg last call on re-spun bundling draft - ended

All,

this mail is to close the wg last call on the re-spun
bundling draft. We've had very few comments, which is
acceptable because of the limited scope of the last call.

However we would need info on existing implementations
of draft-ietf-mpls-bundle-05.txt.

I've asked the authors to update the draft according to
comments and discussion.

/Loa

Loa Andersson wrote:
> Working group,
> 
> this is to initiate a 2 weeks working group last call on
> <>
> 
> The CCAMP working is copied on this MPLS working group last,
> since there are interdependencies between specifications from
> both working groups. Pleae use the MPLS mailing list for
> comments, cross-publishing is not necessary.
> 
> Background: This draft was reviewed by the IESG and approved
> for publication. During implementation there were some issues
> found and it was decided to pull the draft from the RFC Editors
> queue. This wg last call is limited to these issues and how
> they been addressed only.
> 
> The list of issues and how the authors has addresed has been
> sent to the mailing list(s). That text is also included in this
> mail.
> 
> For the record please note that I've asked the authors to
> update some ID-nits, those are not part of the wg last call.
> But has been included just to make it easier to progress the
> document through IESG review.
> 
> This working group last call ends on EOB December 10 PST.
> 
> /Loa
> 
> ------- issues and how they been addressed -------------
> Here is the summary:
> 
> draft-ietf-mpls-bundle-05.txt has been updated to reflect
> the comments made in the MPLS WG and on the list.  The issues
> raised are:
> 
> 1. Scope of component identifiers is open to interpretation
>    (i.e., node vs link)
> 2. No way to specify different upstream and downstream components
>    then using TLV types 1, 2 and 3
> 3. Ambiguity of contents of the IP address field in TLV types 3, 4, 5
> 4. Lack of IPv6 support for types 3, 4, and 5.
> 5. Ambiguity of when to use types 4 and 5 and when to use type 3.
> 6. No coverage of ERO and RRO implications
> 
> These issues have been addressed in the following ways:
> 
> Issue 1:  The -05 document states that all component link TLV types
>           have Node/IP scope
> Issue 2: -05 Tightly defines support for different components in each
>           direction (for bidirectional LSPs, and for all TLV types)
> Issue 3: Format of the Value field for types 3, 4 and 5 now has the
>           identical format as the contents of the C-Type 1
>           LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477].
> Issue 4: Based on the previous change, support of IPv6 unnumbered
>           components is now tied to, and the same as, the support of
>           IPv6 unnumber TE links.
> Issue 5: -05 allows, but recommend against use of types 4 and 5
> Issue 6: EROs, RROs remain out of scope of bundling document
> 
> Current planned changes are:
> - Fix nits found by Adrian and Loa
> - Insert a Table of Contents
> - Section numbering will remain unchanged so as not to break
>   any potentially existing references to the draft
> 
> Yakov.
> -------------------- end of included text --------------------
> 
> Loa Andersson
> 
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                            [email-masked]
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

Delivery-date: Mon, 20 Dec 2004 13:21:49 +0000
Date: Mon, 20 Dec 2004 14:16:32 +0100
From: Loa Andersson <[email-masked]>
To: Loa Andersson <[email-masked]>
CC: [email-masked], George Swallow <[email-masked]>, Alex Zinin <[email-masked]>, Bill Fenner <[email-masked]>, [email-masked]
Subject: MPLS wg last call on re-spun bundling draft - ended

All,

this mail is to close the wg last call on the re-spun
bundling draft. We've had very few comments, which is
acceptable because of the limited scope of the last call.

However we would need info on existing implementations
of draft-ietf-mpls-bundle-05.txt.

I've asked the authors to update the draft according to
comments and discussion.

/Loa

Loa Andersson wrote:
> Working group,
> 
> this is to initiate a 2 weeks working group last call on
> <>
> 
> The CCAMP working is copied on this MPLS working group last,
> since there are interdependencies between specifications from
> both working groups. Pleae use the MPLS mailing list for
> comments, cross-publishing is not necessary.
> 
> Background: This draft was reviewed by the IESG and approved
> for publication. During implementation there were some issues
> found and it was decided to pull the draft from the RFC Editors
> queue. This wg last call is limited to these issues and how
> they been addressed only.
> 
> The list of issues and how the authors has addresed has been
> sent to the mailing list(s). That text is also included in this
> mail.
> 
> For the record please note that I've asked the authors to
> update some ID-nits, those are not part of the wg last call.
> But has been included just to make it easier to progress the
> document through IESG review.
> 
> This working group last call ends on EOB December 10 PST.
> 
> /Loa
> 
> ------- issues and how they been addressed -------------
> Here is the summary:
> 
> draft-ietf-mpls-bundle-05.txt has been updated to reflect
> the comments made in the MPLS WG and on the list.  The issues
> raised are:
> 
> 1. Scope of component identifiers is open to interpretation
>    (i.e., node vs link)
> 2. No way to specify different upstream and downstream components
>    then using TLV types 1, 2 and 3
> 3. Ambiguity of contents of the IP address field in TLV types 3, 4, 5
> 4. Lack of IPv6 support for types 3, 4, and 5.
> 5. Ambiguity of when to use types 4 and 5 and when to use type 3.
> 6. No coverage of ERO and RRO implications
> 
> These issues have been addressed in the following ways:
> 
> Issue 1:  The -05 document states that all component link TLV types
>           have Node/IP scope
> Issue 2: -05 Tightly defines support for different components in each
>           direction (for bidirectional LSPs, and for all TLV types)
> Issue 3: Format of the Value field for types 3, 4 and 5 now has the
>           identical format as the contents of the C-Type 1
>           LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477].
> Issue 4: Based on the previous change, support of IPv6 unnumbered
>           components is now tied to, and the same as, the support of
>           IPv6 unnumber TE links.
> Issue 5: -05 allows, but recommend against use of types 4 and 5
> Issue 6: EROs, RROs remain out of scope of bundling document
> 
> Current planned changes are:
> - Fix nits found by Adrian and Loa
> - Insert a Table of Contents
> - Section numbering will remain unchanged so as not to break
>   any potentially existing references to the draft
> 
> Yakov.
> -------------------- end of included text --------------------
> 
> Loa Andersson
> 
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                            [email-masked]
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Fri, 17 Dec 2004 19:48:49 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Stephen J Trowbridge" <[email-masked]>, <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Jonathan Lang" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Subject: Re: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Fri, 17 Dec 2004 19:48:12 -0000

Thanks Steve,

And available in glorious HTML

Authors, the relevant text from the liaison is included below. I think we
can assume it is no different to what will receive through the formal
channels.

Adrian

=======

We have several questions of clarification, e.g., in section 3.1
(paragraph 2) of the I-D, "The separation between the two processes and
corresponding two name spaces has the advantage that the discovery of the
transport plane can be performed independent from that of the control
plane (and vice-versa), and independent of the method used in each name
space. This allows assigning link connections in the control plane without
the link connection being physically connected."
  1.. What is the intention of the term independent, for example, could it
be indicating at a different time or different approaches?

  2.. In the last sentence, is "assign" used in the context of the
management plane, meaning management plane provisioning?  Is it assumed
that the transport plane resources supporting the link connection
endpoints exist or do not exist?
In section 4.2 (paragraph 2) of the I-D, "G.8080 refers to a component
link as a variable adaptation function i.e. a single server layer trail
dynamically supporting different multiplexing structures." This could be
interpreted as indicating G.8080 defines the term "component link".
G.8080 does not use this term.  Some clarification would be beneficial.
Initial reviews of the draft document have raised concerns about the
possible misinterpretation in the usage of the term 'TE link'. As the
draft notes, the definition of a TE link is concise. Some more clarity
would be appreciated.  Our current understanding of this term includes the
following:

  1.. A TE link may be composed of resource from multiple (G.805) layers
in parallel.  If so, this is an important distinction as an SNPP link is
in a single layer only.

  2.. An SNPP link may contain SNP link connections from various links
(e.g., different STS-1s from a set of parallel OC -48 trails).  It is not
clear if this is also true for TE links.  We think it may, but it is not
stated.

  3.. SNPPs exist at different routing levels (not layers) and thus an
SNPP link at a higher level can encompass SNPPs at a lower level (see
Section 6.2.2 of G.8080 Amendment 2, which is attached for your
convenience).  We think TE links may do this with bundles and FAs, but the
definition is not clear to us.
Please advise if this is a correct understanding or not.  This may have an
impact on the terminology mapping in the draft.  We think it would be
beneficial to have a TE link definition that enables these distinctions to
be understood.
In the table in section 4.2 "CP" is mapped to "Interface".  A Connection
Point is more closely related to a timeslot, wavelength, etc. rather than
to an entire interface.  Similarly "CP Name" is mapped to "Interface ID"
while it might more closely relate to a "Label".  Joint discussion of the
terminology mapping may be beneficial in reaching alignment on the most
accurate mapping.

----- Original Message ----- 
From: "Stephen J Trowbridge" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; "Don Fedyk" <[email-masked]>;
<[email-masked]>; "Brungard, Deborah A, ALABS"
<[email-masked]>; "Jonathan Lang" <[email-masked]>; "Dimitri
Papadimitriou" <[email-masked]>
Sent: Friday, December 17, 2004 6:53 PM
Subject: Re: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt

> Adrian,
> I don't know why the TSB would not have sent out the liaison statements
> generated from December 3. In any case, all of the liaison statements to
ccamp
> that were generated in our meeting are available at the usual spot in
the FTP area:
ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html
>
> Follow the links for the ccamp working group.
> Regards,
> Steve
>
> On 12/17/2004 11:22 AM, Adrian Farrel wrote:
> > Hi,
> >
> > Please note that these are the unofficial comments from SG15.
> > I was present when this was discussed in the Q14/15 meeting in Geneva
at
> > the end of November / start of December, but I have not seen the final
> > version of the material that they intended to liaise to us.
> >
> > Unfortunatley, the liaison response missed the deadline (set to allow
good
> > time after the Geneva meeting) and the WG last call (set to end after
the
> > liaison deadline). No matter; let's see what we can do with my notes
from
> > the meeting.
> >
> > Thanks,
> > Adrian
> > ===
> >
> > Section 3.1
> >
> > "The separation between the two processes and corresponding two name
> > spaces has the advantage that the discovery of the transport plane can
be
> > performed independent from that of the control plane (and vice-versa),
and
> > independent of the method used in each name space. This allows
assigning
> > link connections in the control plane without the link connection
being
> > physically connected."
> >
> > There were some questions about the term "independent". Does it imply
a
> > different mechanism or a different timing?
> > Also, what is meant by the last sentence? Do the transport resource
exist
> > or not when the control plane assignment is made?
> >
> > My understanding of this paragraph is that:
> > - It is material extracted from G.8080 so Q14/15 should be better
> >   placed to answer these questions than us.
> > - The "independence" is precisely that raised in the final question.
> >    That is, assignment in the management plane is independent of
> >    connectivity in the data plane. The two discovery processes
> >    are fully independent (time and mechanism).
> >
> > Perhaps you can find a way to clarify the text.
> >
> >
> >
> > Section 4.2
> >
> > "G.8080 refers to a component link as a variable adaptation function"
> >
> > It was pointed out that G.8080 does not use the term "component link".
> > Obviously what your text means is that the term "variable adaptation
> > function" used in G.8080 is broadly equivalent to the term "component
> > link" used in [LMP] and [BUNDLE]. Perhaps you can change the wording
so
> > that there is no misunderstanding possible.
> >
> >
> > Section 4.2 table
> >
> > CP---Interface
> > The meaning of the term "interface" was misunderstood in that it
appeared
> > to be applied in some non-IETF context, thus we are told that a CP is
like
> > a timeslot or wavelength not an interface. Further, the two columns
for
> > port and component link terminology should make this clear.
> > I don't believe we can go through the pain of writing out an
explanation
> > of every IETF term. This draft is intended to bring LMP transport
within
> > the view of the IETF, not the other way around.
> >
> >
> > General comments on TE links
> >
> > There was (still) some considerable unquiet about the precise nature
of a
> > TE link and how it maps to G.805/8080 concepts. There are a bunch of
> > specific questions about the definition of a TE link, and it is not
clear
> > whether this is the right document to contain the answers. I suggest
that
> > you have a go at answering the questions (we can liaise them back to
> > Q14/15 when we recieve the questions :-) and include them in the draft
if
> > you think it is appropriate.
> >
> > IMHO some of the questions are refusing to acknowledge the abstract
nature
> > of a TE link, and the fact that it is not material how it is
constructed
> > at a lower level because it simply exists at the higher level. In any
> > case, as I say above, this draft is intended to explain transport
concepts
> > so that the IETF can understand them, not the other way around.
> >
> > q1: Can a TE link use parallel resources from different transport
layers?
> > For example, could a TE link between LSR A and LSR B use a lambda and
a
> > timeslot from the same fiber? (Note that there is a claim that an SNPP
> > cannot do this because it exists only within a single layer.)
> >
> > q2: Can a TE link use component resources from parallel links. For
> > example, could a TE link be built from all of the red lambdas from a
> > collection of parallel fibers? Or could a TE link be built from
different
> > STS-1s from parallel OC-48s? (This is said to be true of SNPPs.)
> >
> > q3: Is it possible to build a TE link out of other TE links at
different
> > routing levels? This might (I suppose) involve bundling FAs to provide
> > another TE link. Or possibly we are talking about concatenating FAs to
> > provide a path that is presented as a TE link. (Again, the claim is
that
> > an SNPP link at one level can include SNPPs from a lower level).
> >
> >
> >
> >
> >
> >
>
>
>
>
>

Delivery-date: Fri, 17 Dec 2004 19:30:51 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>
Cc: "'Jean Philippe Vasseur'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>
Subject: Re: Stitching and inter-domain signaling
Date: Fri, 17 Dec 2004 19:30:09 -0000

> > Section 3.2 currently only describes stitching of packet LSPs.
> -------> Are you sure you read the 01 version ? Because the 00 version
is
> the one that only talks about 'stitching of packet LSPs' and only talks
> about inter-domain LSPs wrt stitching. These issues have mostly been
> addressed in the 01 version.

Oh pooh!
Too many drafts. Too much to review :-(

Sorry,
I'll try again with the right version of the document.

A

Delivery-date: Fri, 17 Dec 2004 18:54:34 +0000
Date: Fri, 17 Dec 2004 11:53:15 -0700
From: Stephen J Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Adrian Farrel <[email-masked]>
CC: [email-masked], Don Fedyk <[email-masked]>, [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, Jonathan Lang <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Subject: Re: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt

Adrian,
I don't know why the TSB would not have sent out the liaison statements
generated from December 3. In any case, all of the liaison statements to ccamp
that were generated in our meeting are available at the usual spot in the FTP area:

ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIONS/index.html

Follow the links for the ccamp working group.
Regards,
Steve

On 12/17/2004 11:22 AM, Adrian Farrel wrote:
> Hi,
> 
> Please note that these are the unofficial comments from SG15.
> I was present when this was discussed in the Q14/15 meeting in Geneva at
> the end of November / start of December, but I have not seen the final
> version of the material that they intended to liaise to us.
> 
> Unfortunatley, the liaison response missed the deadline (set to allow good
> time after the Geneva meeting) and the WG last call (set to end after the
> liaison deadline). No matter; let's see what we can do with my notes from
> the meeting.
> 
> Thanks,
> Adrian
> ===
> 
> Section 3.1
> 
> "The separation between the two processes and corresponding two name
> spaces has the advantage that the discovery of the transport plane can be
> performed independent from that of the control plane (and vice-versa), and
> independent of the method used in each name space. This allows assigning
> link connections in the control plane without the link connection being
> physically connected."
> 
> There were some questions about the term "independent". Does it imply a
> different mechanism or a different timing?
> Also, what is meant by the last sentence? Do the transport resource exist
> or not when the control plane assignment is made?
> 
> My understanding of this paragraph is that:
> - It is material extracted from G.8080 so Q14/15 should be better
>   placed to answer these questions than us.
> - The "independence" is precisely that raised in the final question.
>    That is, assignment in the management plane is independent of
>    connectivity in the data plane. The two discovery processes
>    are fully independent (time and mechanism).
> 
> Perhaps you can find a way to clarify the text.
> 
> 
> 
> Section 4.2
> 
> "G.8080 refers to a component link as a variable adaptation function"
> 
> It was pointed out that G.8080 does not use the term "component link".
> Obviously what your text means is that the term "variable adaptation
> function" used in G.8080 is broadly equivalent to the term "component
> link" used in [LMP] and [BUNDLE]. Perhaps you can change the wording so
> that there is no misunderstanding possible.
> 
> 
> Section 4.2 table
> 
> CP---Interface
> The meaning of the term "interface" was misunderstood in that it appeared
> to be applied in some non-IETF context, thus we are told that a CP is like
> a timeslot or wavelength not an interface. Further, the two columns for
> port and component link terminology should make this clear.
> I don't believe we can go through the pain of writing out an explanation
> of every IETF term. This draft is intended to bring LMP transport within
> the view of the IETF, not the other way around.
> 
> 
> General comments on TE links
> 
> There was (still) some considerable unquiet about the precise nature of a
> TE link and how it maps to G.805/8080 concepts. There are a bunch of
> specific questions about the definition of a TE link, and it is not clear
> whether this is the right document to contain the answers. I suggest that
> you have a go at answering the questions (we can liaise them back to
> Q14/15 when we recieve the questions :-) and include them in the draft if
> you think it is appropriate.
> 
> IMHO some of the questions are refusing to acknowledge the abstract nature
> of a TE link, and the fact that it is not material how it is constructed
> at a lower level because it simply exists at the higher level. In any
> case, as I say above, this draft is intended to explain transport concepts
> so that the IETF can understand them, not the other way around.
> 
> q1: Can a TE link use parallel resources from different transport layers?
> For example, could a TE link between LSR A and LSR B use a lambda and a
> timeslot from the same fiber? (Note that there is a claim that an SNPP
> cannot do this because it exists only within a single layer.)
> 
> q2: Can a TE link use component resources from parallel links. For
> example, could a TE link be built from all of the red lambdas from a
> collection of parallel fibers? Or could a TE link be built from different
> STS-1s from parallel OC-48s? (This is said to be true of SNPPs.)
> 
> q3: Is it possible to build a TE link out of other TE links at different
> routing levels? This might (I suppose) involve bundling FAs to provide
> another TE link. Or possibly we are talking about concatenating FAs to
> provide a path that is presented as a TE link. (Again, the claim is that
> an SNPP link at one level can include SNPPs from a lower level).
> 
> 
> 
> 
> 
> 

Delivery-date: Fri, 17 Dec 2004 18:29:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Jonathan Lang" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Subject: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Fri, 17 Dec 2004 18:22:41 -0000

Hi,

Please note that these are the unofficial comments from SG15.
I was present when this was discussed in the Q14/15 meeting in Geneva at
the end of November / start of December, but I have not seen the final
version of the material that they intended to liaise to us.

Unfortunatley, the liaison response missed the deadline (set to allow good
time after the Geneva meeting) and the WG last call (set to end after the
liaison deadline). No matter; let's see what we can do with my notes from
the meeting.

Thanks,
Adrian
===

Section 3.1

"The separation between the two processes and corresponding two name
spaces has the advantage that the discovery of the transport plane can be
performed independent from that of the control plane (and vice-versa), and
independent of the method used in each name space. This allows assigning
link connections in the control plane without the link connection being
physically connected."

There were some questions about the term "independent". Does it imply a
different mechanism or a different timing?
Also, what is meant by the last sentence? Do the transport resource exist
or not when the control plane assignment is made?

My understanding of this paragraph is that:
- It is material extracted from G.8080 so Q14/15 should be better
  placed to answer these questions than us.
- The "independence" is precisely that raised in the final question.
   That is, assignment in the management plane is independent of
   connectivity in the data plane. The two discovery processes
   are fully independent (time and mechanism).

Perhaps you can find a way to clarify the text.

Section 4.2

"G.8080 refers to a component link as a variable adaptation function"

It was pointed out that G.8080 does not use the term "component link".
Obviously what your text means is that the term "variable adaptation
function" used in G.8080 is broadly equivalent to the term "component
link" used in [LMP] and [BUNDLE]. Perhaps you can change the wording so
that there is no misunderstanding possible.

Section 4.2 table

CP---Interface
The meaning of the term "interface" was misunderstood in that it appeared
to be applied in some non-IETF context, thus we are told that a CP is like
a timeslot or wavelength not an interface. Further, the two columns for
port and component link terminology should make this clear.
I don't believe we can go through the pain of writing out an explanation
of every IETF term. This draft is intended to bring LMP transport within
the view of the IETF, not the other way around.

General comments on TE links

There was (still) some considerable unquiet about the precise nature of a
TE link and how it maps to G.805/8080 concepts. There are a bunch of
specific questions about the definition of a TE link, and it is not clear
whether this is the right document to contain the answers. I suggest that
you have a go at answering the questions (we can liaise them back to
Q14/15 when we recieve the questions :-) and include them in the draft if
you think it is appropriate.

IMHO some of the questions are refusing to acknowledge the abstract nature
of a TE link, and the fact that it is not material how it is constructed
at a lower level because it simply exists at the higher level. In any
case, as I say above, this draft is intended to explain transport concepts
so that the IETF can understand them, not the other way around.

q1: Can a TE link use parallel resources from different transport layers?
For example, could a TE link between LSR A and LSR B use a lambda and a
timeslot from the same fiber? (Note that there is a claim that an SNPP
cannot do this because it exists only within a single layer.)

q2: Can a TE link use component resources from parallel links. For
example, could a TE link be built from all of the red lambdas from a
collection of parallel fibers? Or could a TE link be built from different
STS-1s from parallel OC-48s? (This is said to be true of SNPPs.)

q3: Is it possible to build a TE link out of other TE links at different
routing levels? This might (I suppose) involve bundling FAs to provide
another TE link. Or possibly we are talking about concatenating FAs to
provide a path that is presented as a TE link. (Again, the claim is that
an SNPP link at one level can include SNPPs from a lower level).

Delivery-date: Fri, 17 Dec 2004 17:17:44 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Jonathan Lang" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Subject: Chair review of draft-ietf-ccamp-tranport-lmp-00.txt
Date: Fri, 17 Dec 2004 17:13:11 -0000

Hi,

In addition to the id-nits (previous) and ITU-T comments (to follow),
here are a few additional comments.

If you can address all of these and respin the draft, I will take to the
ADs.

The best process, BTW, is for each comment to give and ack or nack, with
a hint as to how you have fixed it or a reason why it is not an issue.

Cheers,
Adrian

====

Substantive

Section 1. It seems to me that this section makes use of a bunch of
terms that are not in common use in the IETF and which are not defined
in this section. For example:
- Access Group
- North input port of an Adaptation function
- Trail Termination source/sink function
You might also want to split the definition of CP out from CTP

Section 4.2
   where:
   - Data Link ID: <Local Interface ID; Remote Interface ID>
   - TE Link ID: <Local Link ID; Remote Link ID>
Not clear what mapping is implied here. Can you spell it out please.

Section 4.2.1
   A typical TE link between GMPLS controlled optical nodes would
   consist of a bundled (TE link) which itself consists
   of a mix of point-to-point links and FAs [BUNDLE] . A TE link is
   identified by the tuple: (Bundled link Identifier(32 bit number),
   Component link Identifier(32 bit number) and generalized label(media
   specific)).
I don't get this at all. Surely this is the identification of a resource
(as described in [GMPLS-RTG] or [BUNDLE])?

Section 4.3
   LMP control channel management is used to establish and maintain
   control channel connectivity between LMP adjacent nodes. In GMPLS,
   the control channels between two adjacent nodes are not required to
   use the same physical medium as the TE links between those nodes.
   The control channels that are used to exchange the GMPLS control-
   plane information exist independently of the TE links they manage
   (i.e., control channels may be in-band or out-of-band, provided the
   associated control points terminate the LMP packets). The Link
   Management Protocol [LMP] was designed to manage TE links,
   independently of the physical medium capabilities of the data links.
   This is done using a Config message exchange followed by a
   lightweight keep-alive message exchange.
This is a non sequita! This last sentence applies to control channel
maintenance. It is true, but has nothing to do with the previous
sentence.

Nits

Spurious blank line between Deborah and AT&T

Can you change the title from "A Transport Network View of LMP" to "A
Transport Network View of the Link Management Protocol".

If you can fit the whole Abstract on the first page, this would be nice.

Section 1. Characteristic Information
Spurious period (".") on line 4

Section 1.
Would it be useful to put the terminology in a logical order or
alphabetical order?

Section 1. Connection Termination Point
s/(CP) [M.3100] The/(CP) [M.3100]. The/

Section 2.
s/G.8080 Amendment 1 [G.8080] defines/ITU-T Recommendation G.8080
Amendment 1 [G.8080] defines/

Section 3.1.
s/Termination and Adaptation performer [TAP]/Termination and Adaptation
performer (TAP)/

Section 3.1.
s/Figure 3: Discover in the Control/Figure 3: Discovery in the Control/

Section 4.1
s/elements of LMP are included in this set of procedures./elements of
LMP is included in this set of procedures./

Section 4.2
s/"architecture for optical/ transport networks"/"architecture for
optical/transport networks"/

Section 4.2.1
<   In the table TE link is equated the concept of SNP, SNP LC, SNPP and
<  SNPP link. The definition of the TE link is broad in scope and is
<   useful repeating here. The original definition appears in [GMPLS-
<   RTG]:
>   In the table, TE link is equated with the concepts of SNP, SNP LC,
SNPP and
>   SNPP link. The definition of TE link is broad in scope and it is
>   useful to repeat it here. The original definition appears in [GMPLS-
>   RTG]:

Section 4.2.1
s/it is probably worth pointing some/it is probably worth pointing out
some/

Section 4.2.1
s/A For example,/For Example/

Section 4.2.1
s/booking or other form of statistical/booking or other forms of
statistical/

Section 4.2.1
s/TE links may represent large number/TE links may represent large
numbers/

Section 4.2.1
s/Interface switching capability/Interface Switching Capability/

Section 4.2.1 (sic)
s/Interface Switching capability/Interface Switching Capability/

Section 4.2.1 (really!)
s/interface switching capability/Interface Switching Capability/

Section 4.2.1
s/Packet switch Capable(PSC)/Packet Switch Capable (PSC)/

Section 4.2.1
s/and FAs [BUNDLE] ./and FAs [BUNDLE]./

Section 4.3
s/Verification.. Key/Verification. Key/

Section 4.3
s/use of a Discovery Agent could be located/use of a Discovery Agent
that could be located/

Section 4.4
   LMP exists to support GMPLS TE link discovery. In section 5.2.1 we
Broken reference

Section 4.4
s/procedure for managing GMPLS TEs/procedure for managing GMPLS TE
links/

Section 5.
s/Since this draft is purely descriptive/Since this document is purely
descriptive/

Section 7.2
Some formating problems

Section 7.2
Some references are out of date now
- GMPLS-Arch now RFC3495
- bundle now at rev05

Delivery-date: Fri, 17 Dec 2004 14:34:58 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Jonathan Lang" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Subject: id-nits output for draft-ietf-ccamp-tranport-lmp-00.txt
Date: Fri, 17 Dec 2004 14:07:03 -0000

Authors,

You definitely need to get into the habit of running the id-nits script
before submitting drafts. Although some of the reports from id-nits are
*very* annoying, you can quickly smooth the errors out. see my hints
prefixed with ##. This isn't rocket science.

Thanks,
Adrian

====

sh ../idnits-v1.51 draft-ietf-ccamp-transport-lmp-00.txt

idnits 1.51 (27 Nov 2004)

draft-ietf-ccamp-transport-lmp-00.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

    The document seems to lack an IANA Considerations section

## Please add an IANA section. IANA finds this very helpful.
## You only need to say...
##    This informational document makes no requests for IANA action.

    Checking conformance with RFC 3667/3668 boilerplate...
    The document seems to lack an RFC 3667 Section 5.1 IPR Disclosure
    Acknowledgement  -- however, there's a paragraph with a matching
    beginning. Boilerplate error?

## The format is slightly broken and you have included a citation (which
is wrong).
## Text should read
##   By submitting this Internet-Draft, I certify that any applicable
##   patent or other IPR claims of which I am aware have been disclosed,
##   and any of which I become aware will be disclosed, in accordance
with
##   RFC 3668.

    The document seems to lack an RFC 3667 Section 5.4 Copyright Notice
    -- however, there's a paragraph with a matching beginning.
    Boilerplate error?

## you need to remove the quote marks from your Copyright section

    The document seems to lack an RFC 3667 Section 5.5 Disclaimer --
    however, there's a paragraph with a matching beginning. Boilerplate
    error?

## you need to remove the quote marks from your Copyright section
## and there is a blank line in the text

    There are 1 instances of lines with non-ascii characters in the
document.

## section 4.4 para 3

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:

    The document seems to lack a 1id_guidelines paragraph about
    Internet-Drafts being working documents -- however, there's a
    paragraph with a matching beginning. Boilerplate error?

## you have folded two paras together at the top of the doc.
## and you have removed a hyphen form "Internet-Drafts"

  Miscellaneous warnings:

    There are 7 instances of lines with hyphenated line breaks in the
document.

## These are bogus warnings that you can ignore.

Delivery-date: Fri, 17 Dec 2004 13:23:11 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Jonathan Lang" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Subject: Re: Working group last call on draft-ietf-ccamp-tranport-lmp-00.txt
Date: Fri, 17 Dec 2004 13:21:10 -0000

Working group last call has completed on this draft.

No additional comments were made on the list.
The draft was liaised to SG15 of the ITU-T and I know that they
discussed the draft at their meeting in Geneva at the end of November.
They prepared a liaison on the draft, but unfortunately this has not
reached us formally.

I have a draft copy of the liaison and I will summarise the points on
the list for the authors to examine and act upon.
I will also supply the chair's review comments.

Thanks,
Adrian

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 25, 2004 2:08 PM
Subject: Working group last call on draft-ietf-ccamp-tranport-lmp-00.txt

> Hi,
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-00.txt
>
> The authors tell me that this draft is cooked.
> There may be future changes in the ITU-T that would require to be
reflected in this work,
> but at the moment it is the opinion of the authors that the I-D
reflects the current set
> of consented recommendations within the ITU-T.
>
> I am liaising the current version of the I-D to ITU-T Study Group 15,
Question 14 that has
> responsibility for ASON Discovery, and I hope that they will spot any
discrepancies that
> may exist.
>
> This email begins an elongated WG last call that will end on December
17th at noon GMT.
> The unusually long last call period is to allow the ITU-T to return
its comments.
>
> Please review and comment on the draft with a view to accuracy,
clarity and usability.
> Thanks,
> Adrian

Delivery-date: Thu, 16 Dec 2004 19:41:57 +0000
Date: Thu, 16 Dec 2004 11:38:21 -0800 (PST)
From: Arthi Ayyangar <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: "'Jean Philippe Vasseur'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: Re: Stitching and inter-domain signaling

Hi Adrian,

> Well, I just went and re-read your draft to try to decide about where
> stitching lives, and I think I am a little clearer on the direction we
> should take.
>
> Section 3.2 currently only describes stitching of packet LSPs.
-------> Are you sure you read the 01 version ? Because the 00 version is
the one that only talks about 'stitching of packet LSPs' and only talks
about inter-domain LSPs wrt stitching. These issues have mostly been
addressed in the 01 version.

Further,
> it specifically limits itself to the stitching of an inter-domain LSP to
> an intra-domain LSP. This is clearly not an adequate description of LSP
> stitching in the context of CCAMP.
-------> I think we do spell out in the draft that any node (not just a
domain boundary node) may use stitching or nesting....although in the
document we may refer to the "inner LSP" as an inter-domain LSP in most
places.

> LSP stitching is a very useful concept in inter-domain signaling for
> packet and non-packet environments and is particularly important in
> non-packet environments where the domains have the same non-packet
> switching capability since nesting will not be possible. Additionally,
> stitching has applicability to nested domains where the interior domain
> is of the same switching capability as the exterior domain - thus FA
> LSPs may be established, but stitched in the data plane.
------> Sure, we agreed that it is a useful concept and applicable to
other areas besides inter-domain TE and also applicable to non-packet
LSPs, and hence the changes were made to the 01 version.

> I think there is sufficient material here to justify a separate draft,
> and it seems to me that the WG is slightly in favor of this split as
> well.
>
> I would like you two (Arthi and JP) to be involved in this new draft
> since you have been developing the stitching concept. Please can you let
> me know ASAP whether (and when!) you will be able to work on this draft.
------> We will come up with a separate draft for stitching, if that is
what is prefered by the WG. We will propose a date once JP and I have had
a chance to sync up on this.

> Otherwise, I know there are a lot of people who would like to do it (not
> a threat - just a subtle hint!).
-------> Thanks for clarifying it explicitly. :-)

I will not reply to your following comments right now, since I am tending
to believe that you have looked at the older version of the draft; e.g.
the new draft does not even have a section 2.3 that you mention below. :-)
Nevertheless, I will  take your comments into account (where applicable),
when the changes are made for the next revision

I will send out a separate mail with a proposed date for the stitching
doc.

thanks,
-arthi

>
> If we can move forward with a stitching draft, I don't see why we can't
> take the inter-domain signaling draft into the WG.
>
> I don't think this has a large impact on your current draft. Section 3.2
> will need to change as follows:
> - generalize it to include non-packet LSPs
>    - simply point out that stitching assumes continuity of switching
> caps
> - leave it with the current inter-domain to intra-domain limitation
> - retain the LSP Attribute control bit (that is specifically relevant to
>   your draft and not the general stitching draft)
> - retain (but modify) the description of stitching behavior in the
>   context of inter/intra-domain LSPs
>
>
> Smaller points to fix sometime (now is good :-)
>

> 2.3 does not seem to be complete because it does not clearly explain
> that in the case of a contiguous LSP the incoming boundary node *is*
> allowed to look ahead in the ERO and perform full computation to the
> next boundary node even if the immediate next hop is strictly specified.
> This is a deviation from RFC3209 that I believe you intend to allow.
>
> 2.3 is missing a similar section for RROs.
>
> 3.1 since you are adding an option here, I think you need to explain why
> it might be selected. What change in service will the head-end see as a
> result of setting or clearing this bit?
>
> 3.1 bit 5 (0x10) is currently reserved for "contiguous" in my pre-IANA
> file on the CCAMP web pages
>
> 3.1    indicates that a boundary LSR MUST not perform any stitching or
> s/not/NOT/
> (in general, please check your use of 2119 terms in the whole draft)
>
> 3.2 bit 6 (0x20) is currently reserved to "force" stitching in my
> pre-IANA file on the CCAMP web pages
>
> 3.2 I think you need to clarify this text (quite a bit) because it is
> very unclear what you mean by "egress".
>
> 5. It would be wise to explain that FRR is a packet technology. You need
> to flag (by reference) how this form of protection is achieved in
> non-packet environments.
>
> 7. The security section is a bit flaccid.
>
> 8.2 Best to refer to the error numbers by their formal names of Error
> Code and Error Value.
>
> 10.1 Please move this text to the draft header and kill the reference to
> RFC2026
>
> 11.1 Please try to control your normative references. Certainly things
> that are referenced only from your example should not be considered
> normative. Similarly, drafts that are not referenced at all seem
> unlikely normative references. just shunt 'em into the informational
> section.
>
> Cheers,
> Adrian
>

Delivery-date: Thu, 16 Dec 2004 16:00:00 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>, "'Jean Philippe Vasseur'" <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>
Subject: Stitching and inter-domain signaling
Date: Thu, 16 Dec 2004 15:54:27 -0000

Hi,

Well, I just went and re-read your draft to try to decide about where
stitching lives, and I think I am a little clearer on the direction we
should take.

Section 3.2 currently only describes stitching of packet LSPs. Further,
it specifically limits itself to the stitching of an inter-domain LSP to
an intra-domain LSP. This is clearly not an adequate description of LSP
stitching in the context of CCAMP.

LSP stitching is a very useful concept in inter-domain signaling for
packet and non-packet environments and is particularly important in
non-packet environments where the domains have the same non-packet
switching capability since nesting will not be possible. Additionally,
stitching has applicability to nested domains where the interior domain
is of the same switching capability as the exterior domain - thus FA
LSPs may be established, but stitched in the data plane.

I think there is sufficient material here to justify a separate draft,
and it seems to me that the WG is slightly in favor of this split as
well.

I would like you two (Arthi and JP) to be involved in this new draft
since you have been developing the stitching concept. Please can you let
me know ASAP whether (and when!) you will be able to work on this draft.
Otherwise, I know there are a lot of people who would like to do it (not
a threat - just a subtle hint!).

If we can move forward with a stitching draft, I don't see why we can't
take the inter-domain signaling draft into the WG.

I don't think this has a large impact on your current draft. Section 3.2
will need to change as follows:
- generalize it to include non-packet LSPs
   - simply point out that stitching assumes continuity of switching
caps
- leave it with the current inter-domain to intra-domain limitation
- retain the LSP Attribute control bit (that is specifically relevant to
  your draft and not the general stitching draft)
- retain (but modify) the description of stitching behavior in the
  context of inter/intra-domain LSPs

Smaller points to fix sometime (now is good :-)

2.3 does not seem to be complete because it does not clearly explain
that in the case of a contiguous LSP the incoming boundary node *is*
allowed to look ahead in the ERO and perform full computation to the
next boundary node even if the immediate next hop is strictly specified.
This is a deviation from RFC3209 that I believe you intend to allow.

2.3 is missing a similar section for RROs.

3.1 since you are adding an option here, I think you need to explain why
it might be selected. What change in service will the head-end see as a
result of setting or clearing this bit?

3.1 bit 5 (0x10) is currently reserved for "contiguous" in my pre-IANA
file on the CCAMP web pages

3.1    indicates that a boundary LSR MUST not perform any stitching or
s/not/NOT/
(in general, please check your use of 2119 terms in the whole draft)

3.2 bit 6 (0x20) is currently reserved to "force" stitching in my
pre-IANA file on the CCAMP web pages

3.2 I think you need to clarify this text (quite a bit) because it is
very unclear what you mean by "egress".

5. It would be wise to explain that FRR is a packet technology. You need
to flag (by reference) how this form of protection is achieved in
non-packet environments.

7. The security section is a bit flaccid.

8.2 Best to refer to the error numbers by their formal names of Error
Code and Error Value.

10.1 Please move this text to the draft header and kill the reference to
RFC2026

11.1 Please try to control your normative references. Certainly things
that are referenced only from your example should not be considered
normative. Similarly, drafts that are not referenced at all seem
unlikely normative references. just shunt 'em into the informational
section.

Cheers,
Adrian

Delivery-date: Fri, 10 Dec 2004 21:51:54 +0000
From: "Baktha Muralidharan" <[email-masked]>
To: "'Bradford, Richard'" <[email-masked]>, "'Baktha Muralidharan'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Question on LMP Fault Localization
Date: Fri, 10 Dec 2004 16:50:31 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_00BB_01C4DED8.5C941F90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Rich,
 
Thanks!.
 
So, if a Node (node A) sends a channel status to an upstream node (node B)
indicating that it  (node A) is experiencing LoL, for node B does the
following:
 
1. Figures out which LSPs are carried on the interface reported by node A
2. Each of the LSPs could be taking different route and so, could go out on
a different interface off node B. Determines the corresponding "upstream
side" interface for each of the LSPs.
3. On each of the "upstream side" interface, checks if it (node B) is
receiving light.
4. If even one of the "upstream side" interface is receiving light,  then
node B concludes that failure is clear on its' upstream side
 
Assuming a PXC (Lambda link switching) in this case, by the way.
 
Finally, it is interesting that a "lower level layer" (LMP) requires
knowledge of "higher level layers" to perform its function. Was it by
design?
 
Thanks,
/Baktha

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bradford, Richard
Sent: Friday, December 10, 2004 2:32 PM
To: Baktha Muralidharan
Cc: [email-masked]
Subject: Re: Question on LMP Fault Localization

At 12:44 PM 12/10/2004 -0500, Baktha Muralidharan wrote:

I have question about LMP fault localization process. It appears that fault
localization process requires that LMP be "LSP aware". All other LMP
procedures, in contrast, are "LSP agnostic" and work only with interfaces.

The LMP draft illustrates LMP Fault Localization with two examples. The
configuration for the first example is as follows:

       +-------+        +-------+        +-------+        +-------+
       + Node1 +        + Node2 +        + Node3 +        + Node4 +
       +       +-- c ---+       +-- c ---+       +-- c ---+       +
   ----+---\   +        +       +        +       +        +       +
   <---+---\\--+--------+-------+---\    +       +        +    /--+--->
       +    \--+--------+-------+---\\---+-------+---##---+---//--+----
       +       +        +       +    \---+-------+--------+---/   +
       +       +        +       +        +       +        +       +
       +-------+        +-------+        +-------+        +-------+

"
   In the first example [see Fig. 2(a)], there is a failure on one
   direction of the bi-directional LSP. Node 4 will detect the failure
   and will send a ChannelStatus message to Node 3 indicating the
   failure (e.g., LOL) to the corresponding upstream node. When Node 3
   receives the ChannelStatus message from Node 4, it returns a
   ChannelStatusAck message back to Node 4 and correlates the failure
   locally. When Node 3 correlates the failure and verifies that the
   failure is clear, it has localized the failure to the data link
   between Node 3 and Node 4. At that time, Node 3 should send a
   ChannelStatus message to Node 4 indicating that the failure has been
   localized.
"

In the illustration above, Node 3 verifies that the "failure is clear",
presumably by checking if the interface on its upstream side (i.e. facing
Node 2) is receiving light. However, in this case, there is only one other
interface (besides the one Node 4 reported on) emenating from Node 3 and so,
seems simple enough to check if that interface is receiving light.

Consider the following, slightly modified configuration, in which Node 3 has
multiple interfaces:

       +-------+        +-------+        +-------+        +-------+
       + Node1 +        + Node2 +        + Node3 +        + Node4 +
       +       +-- c ---+       +-- c ---+       +-- c ---+       +
   ----+---\   +        +       +        +       +        +       +
   <---+---\\--+--------+-------+---\    +       +        +    /--+--->
       +    \--+--------+-------+---\\---+-------+---##---+---//--+----
       +       +        +       +    \---+-------+--------+---/   +
       +       +        +       +        +       +        +       +
       +-------+        +-------+        +-------+        +-------+
                                          | | | |
                                          | | | |
                                          | | | |

How does Node 3 know which interface to check to see if the failure is
further "upstream"? It looks like Node 3 needs LSP route knowledge to locate
the "upstream" interface (corresponding to the interface Node 4 reports on)?

Yes, LMP needs to know this information.

If yes, how will the LMP instance on Node 3 gather the LSP information?.

It's left as an implementation detail. Presumably the LMP module in each
node exchanged information with the signalling module in each node. It is
already assumed that the LMP module provides control channel, data-link and
TE-Link information to the local signalling and routing modules. This is a
case where the direction of that exchange is reversed.
-- Rich

Channel Status only provides interface ID.

Thanks,
/Baktha
Cisco Systems, Inc. 

------=_NextPart_000_00BB_01C4DED8.5C941F90
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.1479" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Rich,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks!.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>So, if a Node (node A) sends a channel status =
to an=20
upstream node (node B) indicating that it&nbsp; (node A)&nbsp;is =
experiencing=20
LoL, for node B does the following:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>1. Figures out which LSPs are carried on the =
interface=20
reported by node A</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>2. Each of the LSPs could be taking different =
route and so,=20
could go out on a different interface off node B. Determines the =
corresponding=20
"upstream side" interface for each of the LSPs.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>3. On each of the "upstream side" interface, =
checks if it=20
(node B)&nbsp;is receiving light.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>4.&nbsp;If even one of the "upstream side" =
interface is=20
receiving light,&nbsp; then node B concludes that failure is clear on =
its'=20
upstream side</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Assuming a PXC (Lambda link switching) in this =
case, by the=20
way.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Finally, it is interesting that a "lower level =
layer" (LMP)=20
requires knowledge of "higher level layers" to perform its function. Was =
it by=20
design?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>/Baktha</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D174533021-10122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Bradford,=20
Richard<BR><B>Sent:</B> Friday, December 10, 2004 2:32 PM<BR><B>To:</B> =
Baktha=20
Muralidharan<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> Re: =
Question on=20
LMP Fault Localization<BR></FONT><BR></DIV>
<DIV></DIV><FONT size=3D3>At 12:44 PM 12/10/2004 -0500, Baktha =
Muralidharan=20
wrote:<BR>
<BLOCKQUOTE cite=3D"" type=3D"cite">I have question about LMP fault =
localization=20
  process. It appears that fault<BR>localization process requires that =
LMP be=20
  "LSP aware". All other LMP<BR>procedures, in contrast, are "LSP =
agnostic" and=20
  work only with interfaces.<BR><BR>The LMP draft illustrates LMP Fault=20
  Localization with two examples. The<BR>configuration for the first =
example is=20
  as follows:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node1=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node2=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node3=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node4=20
  +<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c=20
  ---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c=20
  ---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c=20
  ---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +<BR>&nbsp;&nbsp;=20
  ----+---\&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +<BR>&nbsp;&nbsp;=20
  &lt;---+---\\--+--------+-------+---\&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;=20
  /--+---&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+&nbsp;&nbsp;&nbsp;=20
  =
\--+--------+-------+---\\---+-------+---##---+---//--+----<BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;=20
  \---+-------+--------+---/&nbsp;&nbsp;=20
  +<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+<BR><BR><BR>"<BR>&nbsp;&nbsp; In the first example [see Fig. =
2(a)],=20
  there is a failure on one<BR>&nbsp;&nbsp; direction of the =
bi-directional LSP.=20
  Node 4 will detect the failure<BR>&nbsp;&nbsp; and will send a =
ChannelStatus=20
  message to Node 3 indicating the<BR>&nbsp;&nbsp; failure (e.g., LOL) =
to the=20
  corresponding upstream node. When Node 3<BR>&nbsp;&nbsp; receives the=20
  ChannelStatus message from Node 4, it returns a<BR>&nbsp;&nbsp;=20
  ChannelStatusAck message back to Node 4 and correlates the=20
  failure<BR>&nbsp;&nbsp; locally. When Node 3 correlates the failure =
and=20
  verifies that the<BR>&nbsp;&nbsp; failure is clear, it has localized =
the=20
  failure to the data link<BR>&nbsp;&nbsp; between Node 3 and Node 4. At =
that=20
  time, Node 3 should send a<BR>&nbsp;&nbsp; ChannelStatus message to =
Node 4=20
  indicating that the failure has been<BR>&nbsp;&nbsp; =
localized.<BR>"<BR><BR>In=20
  the illustration above, Node 3 verifies that the "failure is=20
  clear",<BR>presumably by checking if the interface on its upstream =
side (i.e.=20
  facing<BR>Node 2) is receiving light. However, in this case, there is =
only one=20
  other<BR>interface (besides the one Node 4 reported on) emenating from =
Node 3=20
  and so,<BR>seems simple enough to check if that interface is receiving =

  light.<BR><BR>Consider the following, slightly modified configuration, =
in=20
  which Node 3 has<BR>multiple=20
  interfaces:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node1=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node2=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node3=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node4=20
  +<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c=20
  ---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c=20
  ---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c=20
  ---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +<BR>&nbsp;&nbsp;=20
  ----+---\&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +<BR>&nbsp;&nbsp;=20
  &lt;---+---\\--+--------+-------+---\&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;=20
  /--+---&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+&nbsp;&nbsp;&nbsp;=20
  =
\--+--------+-------+---\\---+-------+---##---+---//--+----<BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;=20
  \---+-------+--------+---/&nbsp;&nbsp;=20
  +<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
+-------+<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | | |=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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | | |=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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  | | | |<BR><BR>How does Node 3 know which interface to check to see if =
the=20
  failure is<BR>further "upstream"? It looks like Node 3 needs LSP route =

  knowledge to locate<BR>the "upstream" interface (corresponding to the=20
  interface Node 4 reports on)?</FONT></BLOCKQUOTE>Yes, LMP needs to =
know this=20
information.<BR><BR>
<BLOCKQUOTE cite=3D"" type=3D"cite"><FONT size=3D3>If yes, how will the =
LMP instance=20
  on Node 3 gather the LSP information?.</FONT></BLOCKQUOTE><BR>It's =
left as an=20
implementation detail. Presumably the LMP module in each node exchanged=20
information with the signalling module in each node. It is already =
assumed that=20
the LMP module provides control channel, data-link and TE-Link =
information to=20
the local signalling and routing modules. This is a case where the =
direction of=20
that exchange is reversed.<BR>-- Rich<BR><BR><BR>
<BLOCKQUOTE cite=3D"" type=3D"cite"><FONT size=3D3>Channel Status only =
provides=20
  interface ID.<BR><BR>Thanks,<BR>/Baktha<BR>Cisco Systems, Inc.=20
</FONT></BLOCKQUOTE><BR><FONT face=3D"Courier, =
Courier"></FONT></BODY></HTML>

------=_NextPart_000_00BB_01C4DED8.5C941F90--

Delivery-date: Fri, 10 Dec 2004 19:32:35 +0000
Date: Fri, 10 Dec 2004 14:31:31 -0500
To: "Baktha Muralidharan" <[email-masked]>
From: "Bradford, Richard" <[email-masked]>
Subject: Re: Question on LMP Fault Localization
Cc: <[email-masked]>

--=====================_77757429==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:44 PM 12/10/2004 -0500, Baktha Muralidharan wrote:
>I have question about LMP fault localization process. It appears that fault
>localization process requires that LMP be "LSP aware". All other LMP
>procedures, in contrast, are "LSP agnostic" and work only with interfaces.
>
>The LMP draft illustrates LMP Fault Localization with two examples. The
>configuration for the first example is as follows:
>
>        +-------+        +-------+        +-------+        +-------+
>        + Node1 +        + Node2 +        + Node3 +        + Node4 +
>        +       +-- c ---+       +-- c ---+       +-- c ---+       +
>    ----+---\   +        +       +        +       +        +       +
>    <---+---\\--+--------+-------+---\    +       +        +    /--+--->
>        +    \--+--------+-------+---\\---+-------+---##---+---//--+----
>        +       +        +       +    \---+-------+--------+---/   +
>        +       +        +       +        +       +        +       +
>        +-------+        +-------+        +-------+        +-------+
>
>
>"
>    In the first example [see Fig. 2(a)], there is a failure on one
>    direction of the bi-directional LSP. Node 4 will detect the failure
>    and will send a ChannelStatus message to Node 3 indicating the
>    failure (e.g., LOL) to the corresponding upstream node. When Node 3
>    receives the ChannelStatus message from Node 4, it returns a
>    ChannelStatusAck message back to Node 4 and correlates the failure
>    locally. When Node 3 correlates the failure and verifies that the
>    failure is clear, it has localized the failure to the data link
>    between Node 3 and Node 4. At that time, Node 3 should send a
>    ChannelStatus message to Node 4 indicating that the failure has been
>    localized.
>"
>
>In the illustration above, Node 3 verifies that the "failure is clear",
>presumably by checking if the interface on its upstream side (i.e. facing
>Node 2) is receiving light. However, in this case, there is only one other
>interface (besides the one Node 4 reported on) emenating from Node 3 and so,
>seems simple enough to check if that interface is receiving light.
>
>Consider the following, slightly modified configuration, in which Node 3 has
>multiple interfaces:
>
>        +-------+        +-------+        +-------+        +-------+
>        + Node1 +        + Node2 +        + Node3 +        + Node4 +
>        +       +-- c ---+       +-- c ---+       +-- c ---+       +
>    ----+---\   +        +       +        +       +        +       +
>    <---+---\\--+--------+-------+---\    +       +        +    /--+--->
>        +    \--+--------+-------+---\\---+-------+---##---+---//--+----
>        +       +        +       +    \---+-------+--------+---/   +
>        +       +        +       +        +       +        +       +
>        +-------+        +-------+        +-------+        +-------+
>                                           | | | |
>                                           | | | |
>                                           | | | |
>
>How does Node 3 know which interface to check to see if the failure is
>further "upstream"? It looks like Node 3 needs LSP route knowledge to locate
>the "upstream" interface (corresponding to the interface Node 4 reports on)?
Yes, LMP needs to know this information.

>If yes, how will the LMP instance on Node 3 gather the LSP information?.

It's left as an implementation detail. Presumably the LMP module in each 
node exchanged information with the signalling module in each node. It is 
already assumed that the LMP module provides control channel, data-link and 
TE-Link information to the local signalling and routing modules. This is a 
case where the direction of that exchange is reversed.
-- Rich

>Channel Status only provides interface ID.
>
>Thanks,
>/Baktha
>Cisco Systems, Inc.

--=====================_77757429==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 12:44 PM 12/10/2004 -0500, Baktha Muralidharan
wrote:<br>
<blockquote type=cite cite>I have question about LMP fault localization
process. It appears that fault<br>
localization process requires that LMP be &quot;LSP aware&quot;. All
other LMP<br>
procedures, in contrast, are &quot;LSP agnostic&quot; and work only with
interfaces.<br>
<br>
The LMP draft illustrates LMP Fault Localization with two examples.
The<br>
configuration for the first example is as follows:<br>
<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; +-------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node1
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node2
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node3
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node4 +<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c
---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c
---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c
---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +<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;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +<br>
&nbsp;&nbsp; &lt;---+---\\--+--------+-------+---\&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;
/--+---&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;
\--+--------+-------+---\\---+-------+---##---+---//--+----<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;&nbsp; +<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;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +<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; +-------+<br>
<br>
<br>
&quot;<br>
&nbsp;&nbsp; In the first example [see Fig. 2(a)], there is a failure on
one<br>
&nbsp;&nbsp; direction of the bi-directional LSP. Node 4 will detect the
failure<br>
&nbsp;&nbsp; and will send a ChannelStatus message to Node 3 indicating
the<br>
&nbsp;&nbsp; failure (e.g., LOL) to the corresponding upstream node. When
Node 3<br>
&nbsp;&nbsp; receives the ChannelStatus message from Node 4, it returns
a<br>
&nbsp;&nbsp; ChannelStatusAck message back to Node 4 and correlates the
failure<br>
&nbsp;&nbsp; locally. When Node 3 correlates the failure and verifies
that the<br>
&nbsp;&nbsp; failure is clear, it has localized the failure to the data
link<br>
&nbsp;&nbsp; between Node 3 and Node 4. At that time, Node 3 should send
a<br>
&nbsp;&nbsp; ChannelStatus message to Node 4 indicating that the failure
has been<br>
&nbsp;&nbsp; localized.<br>
&quot;<br>
<br>
In the illustration above, Node 3 verifies that the &quot;failure is
clear&quot;,<br>
presumably by checking if the interface on its upstream side (i.e.
facing<br>
Node 2) is receiving light. However, in this case, there is only one
other<br>
interface (besides the one Node 4 reported on) emenating from Node 3 and
so,<br>
seems simple enough to check if that interface is receiving light.<br>
<br>
Consider the following, slightly modified configuration, in which Node 3
has<br>
multiple interfaces:<br>
<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; +-------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node1
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node2
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node3
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + Node4 +<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c
---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c
---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c
---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +<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;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +<br>
&nbsp;&nbsp; &lt;---+---\\--+--------+-------+---\&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;
/--+---&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;
\--+--------+-------+---\\---+-------+---##---+---//--+----<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;&nbsp; +<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;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +<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; +-------+<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| | | |<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| | | |<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| | | |<br>
<br>
How does Node 3 know which interface to check to see if the failure
is<br>
further &quot;upstream&quot;? It looks like Node 3 needs LSP route
knowledge to locate<br>
the &quot;upstream&quot; interface (corresponding to the interface Node 4
reports on)?</font></blockquote>Yes, LMP needs to know this
information.<br>
<br>
<blockquote type=cite cite><font size=3>If yes, how will the LMP instance
on Node 3 gather the LSP information?.</font></blockquote><br>
It's left as an implementation detail. Presumably the LMP module in each
node exchanged information with the signalling module in each node. It is
already assumed that the LMP module provides control channel, data-link
and TE-Link information to the local signalling and routing modules. This
is a case where the direction of that exchange is reversed.<br>
-- Rich<br>
<br>
<br>
<blockquote type=cite cite><font size=3>Channel Status only provides
interface ID.<br>
<br>
Thanks,<br>
/Baktha<br>
Cisco Systems, Inc. </font></blockquote><br>

<font face="Courier, Courier"></font></html>

--=====================_77757429==_.ALT--

Delivery-date: Fri, 10 Dec 2004 17:46:14 +0000
From: "Baktha Muralidharan" <[email-masked]>
To: <[email-masked]>
Subject: Question on LMP Fault Localization
Date: Fri, 10 Dec 2004 12:44:38 -0500

I have question about LMP fault localization process. It appears that fault
localization process requires that LMP be "LSP aware". All other LMP
procedures, in contrast, are "LSP agnostic" and work only with interfaces.

The LMP draft illustrates LMP Fault Localization with two examples. The
configuration for the first example is as follows:

       +-------+        +-------+        +-------+        +-------+
       + Node1 +        + Node2 +        + Node3 +        + Node4 +
       +       +-- c ---+       +-- c ---+       +-- c ---+       +
   ----+---\   +        +       +        +       +        +       +
   <---+---\\--+--------+-------+---\    +       +        +    /--+--->
       +    \--+--------+-------+---\\---+-------+---##---+---//--+----
       +       +        +       +    \---+-------+--------+---/   +
       +       +        +       +        +       +        +       +
       +-------+        +-------+        +-------+        +-------+

"
   In the first example [see Fig. 2(a)], there is a failure on one
   direction of the bi-directional LSP. Node 4 will detect the failure
   and will send a ChannelStatus message to Node 3 indicating the
   failure (e.g., LOL) to the corresponding upstream node. When Node 3
   receives the ChannelStatus message from Node 4, it returns a
   ChannelStatusAck message back to Node 4 and correlates the failure
   locally. When Node 3 correlates the failure and verifies that the
   failure is clear, it has localized the failure to the data link
   between Node 3 and Node 4. At that time, Node 3 should send a
   ChannelStatus message to Node 4 indicating that the failure has been
   localized.
"

In the illustration above, Node 3 verifies that the "failure is clear",
presumably by checking if the interface on its upstream side (i.e. facing
Node 2) is receiving light. However, in this case, there is only one other
interface (besides the one Node 4 reported on) emenating from Node 3 and so,
seems simple enough to check if that interface is receiving light.

Consider the following, slightly modified configuration, in which Node 3 has
multiple interfaces:

       +-------+        +-------+        +-------+        +-------+
       + Node1 +        + Node2 +        + Node3 +        + Node4 +
       +       +-- c ---+       +-- c ---+       +-- c ---+       +
   ----+---\   +        +       +        +       +        +       +
   <---+---\\--+--------+-------+---\    +       +        +    /--+--->
       +    \--+--------+-------+---\\---+-------+---##---+---//--+----
       +       +        +       +    \---+-------+--------+---/   +
       +       +        +       +        +       +        +       +
       +-------+        +-------+        +-------+        +-------+
                                          | | | |
                                          | | | |
                                          | | | |

How does Node 3 know which interface to check to see if the failure is
further "upstream"? It looks like Node 3 needs LSP route knowledge to locate
the "upstream" interface (corresponding to the interface Node 4 reports on)?
If yes, how will the LMP instance on Node 3 gather the LSP information?.
Channel Status only provides interface ID.

Thanks,
/Baktha
Cisco Systems, Inc.

Delivery-date: Fri, 10 Dec 2004 08:22:45 +0000
Reply-To: =?ks_c_5601-1987?B?sei/tcit?= <[email-masked]>
From: =?ks_c_5601-1987?B?sei/tcit?= <[email-masked]>
To: <[email-masked]>
Cc: 
Bcc: 
Subject: Addition to my question on LMP Adjacency
Date: Fri, 10 Dec 2004 17:22:26 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCCxpMD8tN64wcGmvu7GwCwgtOM=?= =?ks_c_5601-1987?B?tOc=?=
content-class: urn:content-classes:message

This is a multi-part message in MIME format.

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

------=_NextPart_000_20716_01C4DEDC.D16E88B0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

<DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =B1=BC=B8=B2">
<DIV>
<DIV>Hi, ccamper</DIV>
<DIV>&nbsp;</DIV>
<DIV>I'm sorry but, my question is about the LMP adjacency&nbsp;from the =
view-point of&nbsp;data plane.</DIX !V>=20
<DIV>The samle network&nbsp;is that&nbsp;in data plane Node#1 is =
physically connected to Node#2, then Node#2 is physically connected to =
Node#3. There is no physical connection between Node#1 and Node#3 in =
data plane.</DIV>
<DIV>In the data plane, an EoS#1 channel&nbsp; is terminated in Node#1 =
amd Node#2, the other EoS#2 channel is </DIV>
<DIV>terminated in Node#1 and Node#3 via Node#2. Here, I think that in =
case of the EoS#1, LMP adjacent nodes are Node#1 and Node#2, but in case =
of the EoS#2, LMP adjacent nodes are Node#1 and Node#3 under the =
condition that the definition of LMP adjacency is observed. I also think =
that the type of data link for EoS#1 and EoS#2 is a component link and =
the link connection verification of EoS#2 between Node#1 and Node#3 =
could be performed.</DIV>
<DIV>I'm not sure&nbsp;if my understanding is correct or not.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Young</DIV>
<DIV>&nbsp;</DIV></DIV></DIV></DIV><img style=3D"display:none" width=3D0 =
height=3D0 =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3Dccamp@ops.=
ietf.org&name=3Dccamp%40ops.ietf.org&fromemail=[email-masked]&messag=
eid=[email-masked]%3E">
------=_NextPart_000_20716_01C4DEDC.D16E88B0--

Delivery-date: Fri, 10 Dec 2004 08:02:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "=?ks_c_5601-1987?B?ob5loq+l7EWhqQ==?=" <[email-masked]>, <[email-masked]>
Subject: Re: Question on LMP Adjacency
Date: Fri, 10 Dec 2004 08:00:47 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_008C_01C4DE8E.5BC18CF0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

Hi,

I *think* what you are saying is that in the control plane the physical =
connectivity is=20

node#1----node#2----node#3

but in the data plane the TE connectivity is

node#1----node#2      node#3
  |                     |
   ---------------------

Note that these are TE links and there may be other underlying physical =
connectivity.

Note that an LMP control channel is formed simply when the two LMP =
speakers are in communication. Since they communicate using LMP over =
UDP, this is not a big problem in your figure so long as:

1. node#1 knows about the existence of node#3
   and can send UDP packets to it.
2. node#2 is capable of forwarding IP packets

Cheers,
Adrian

----- Original Message -----=20
From: "Harish M" <[email-masked]>
To: "=A1=BEe=A2=AF=A5=ECE=A1=A9" <[email-masked]>; =
<[email-masked]>
Sent: Friday, December 10, 2004 7:29 AM
Subject: RE: Question on LMP Adjacency

> Question is not clear.
>=20
>  -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On =
Behalf Of
> =B1=E8=BF=B5=C8=AD
> Sent: Friday, December 10, 2004 12:37 PM
> To: [email-masked]
> Subject: Question on LMP Adjacency
>=20
>=20
>   Hi, ccampers
>=20
>   I've a question on the LMP adjacency.
>   In the LMP draft, the definition is as follows:
>=20
>      An "LMP adjacency" is formed between two nodes when at least one =
bi-
>      directional control channel is established between them. Multiple
>      control channels may be active simultaneously for each adjacency;
>      control channel parameters, however, MUST be individually =
negotiated
>      for each control channel.
>=20
>   Then, my question is this.
>=20
>   For an example,
>   we assume a sample network consisting of Node#1, Node#2, and Node#3.
> Node#1 is directly connected to Node#2, and Node#2 is directly =
connected to
> Node#3.
>   This means there is no direct connection between Node#1 and Node#3 =
in the
> sample network.
>   In this situation, we assume that an EoS channel(EoS#1) between =
Node#1 and
> Node#2 is terminated, but another EoS channel(EoS#2) between Node#1 =
and
> Node#3 is terminated through Node#2.
>   Here, I think that in case of the EoS#1, LMP adjacent nodes are =
Node#1 and
> Node#2, but in case of the EoS#2, LMP adjacent nodes are Node#1 and =
Node#3.
> In addition, I think that the type of data link for EoS#1 and EoS#2 is =
a
> component link and the link connection verification of EoS#2 between =
Node#1
> and Node#3 could be performed. The only condition is, of course,  is =
to
> observe the definition of the LMP adjacency above.
>=20
>      Node#1         Node#2         Node#3
>         |-----EoS#1----|              |
>         |------------EoS#2------------|
>=20
>   Could you help me if my understanding is short ?
>=20
>   Thanks,
>=20
>   Young.
>=20
>=20
>=20
> 
------=_NextPart_000_008C_01C4DE8E.5BC18CF0
Content-Type: text/html;
	charset="ks_c_5601-1987"
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=3Dks_c_5601-1987">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I *think* what you are saying is that =
in the=20
control plane the physical connectivity is </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier =
size=3D2>node#1----node#2----node#3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>but in the data plane the =
TE&nbsp;connectivity=20
is</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier =
size=3D2>node#1----node#2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
node#3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; =
---------------------</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Note that these are TE links and =
there may be=20
other underlying physical connectivity.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Note that an LMP control channel is =
formed simply=20
when the two LMP speakers are in communication. Since they communicate =
using LMP=20
over UDP, this is not a big problem in your figure so long =
as:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>1. node#1 knows about the existence =
of=20
node#3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; and can send UDP packets =
to=20
it.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>2. node#2 is capable of forwarding IP =

packets</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Cheers,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DCourier size=3D2>From: "Harish M" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>To: "=A1=BEe=A2=AF=A5=ECE&shy;" =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Sent: Friday, December 10, 2004 7:29=20
AM</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Subject: RE: Question on LMP=20
Adjacency</FONT></DIV></DIV>
<DIV><FONT face=3DCourier><BR><FONT size=3D2></FONT></FONT></DIV><FONT =
face=3DCourier=20
size=3D2>&gt; Question is not clear.<BR>&gt; <BR>&gt; =
&nbsp;-----Original=20
Message-----<BR>&gt; From: </FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>=20
[mailto:[email-masked]]On Behalf Of<BR>&gt; =
=B1=E8=BF=B5=C8=AD<BR>&gt; Sent: Friday,=20
December 10, 2004 12:37 PM<BR>&gt; To: </FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt; Subject:=20
Question on LMP Adjacency<BR>&gt; <BR>&gt; <BR>&gt; &nbsp; Hi, =
ccampers<BR>&gt;=20
<BR>&gt; &nbsp; I've a question on the LMP adjacency.<BR>&gt; &nbsp; In =
the LMP=20
draft, the definition is as follows:<BR>&gt; <BR>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;=20
An "LMP adjacency" is formed between two nodes when at least one =
bi-<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp; directional control channel is established =
between=20
them. Multiple<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp; control channels may be =
active=20
simultaneously for each adjacency;<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp; =
control=20
channel parameters, however, MUST be individually negotiated<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp; for each control channel.<BR>&gt; <BR>&gt; =
&nbsp; Then,=20
my question is this.<BR>&gt; <BR>&gt; &nbsp; For an example,<BR>&gt; =
&nbsp; we=20
assume a sample network consisting of Node#1, Node#2, and =
Node#3.<BR>&gt; Node#1=20
is directly connected to Node#2, and Node#2 is directly connected =
to<BR>&gt;=20
Node#3.<BR>&gt; &nbsp; This means there is no direct connection between =
Node#1=20
and Node#3 in the<BR>&gt; sample network.<BR>&gt; &nbsp; In this =
situation, we=20
assume that an EoS channel(EoS#1) between Node#1 and<BR>&gt; Node#2 is=20
terminated, but another EoS channel(EoS#2) between Node#1 and<BR>&gt; =
Node#3 is=20
terminated through Node#2.<BR>&gt; &nbsp; Here, I think that in case of =
the=20
EoS#1, LMP adjacent nodes are Node#1 and<BR>&gt; Node#2, but in case of =
the=20
EoS#2, LMP adjacent nodes are Node#1 and Node#3.<BR>&gt; In addition, I =
think=20
that the type of data link for EoS#1 and EoS#2 is a<BR>&gt; component =
link and=20
the link connection verification of EoS#2 between Node#1<BR>&gt; and =
Node#3=20
could be performed. The only condition is, of course,&nbsp; is =
to<BR>&gt;=20
observe the definition of the LMP adjacency above.<BR>&gt;=20
<BR>&gt;&nbsp;&nbsp;&nbsp; &nbsp;=20
Node#1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Node#2&nbsp; =
&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; Node#3<BR>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|-----EoS#1----|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
|<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|------------EoS#2------------|<BR>&gt; <BR>&gt; &nbsp; Could you help =
me if my=20
understanding is short ?<BR>&gt; <BR>&gt; &nbsp; Thanks,<BR>&gt; =
<BR>&gt; &nbsp;=20
Young.<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; </FONT></BODY></HTML>

------=_NextPart_000_008C_01C4DE8E.5BC18CF0--

Delivery-date: Fri, 10 Dec 2004 07:53:09 +0000
Date: Fri, 10 Dec 2004 13:29:01 +0530
From: Harish M <[email-masked]>
Subject: RE: RE: Question on LMP Adjacency
To: =?iso-8859-1?B?sei/tcit?= <[email-masked]>, [email-masked]
Reply-to: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_ms8EbzYvxEPRPWPRq0zq4g)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT

LMP adjacency is established between two directly connected nodes over CC

   An "LMP adjacency" is formed between two nodes when at least one bi-
   directional control channel is established between them. Multiple
   control channels may be active simultaneously for each adjacency;
   control channel parameters, however, MUST be individually negotiated
   for each control channel.

If multiple CC's present (in one adjacency) then, keep-alive hello will be
there on all CCs separately.
Control information (Signaling/Routing protocol updates) can be sent on any
one CC.

  -----Original Message-----
  From: Kim Young Hwa [mailto:[email-masked]]
  Sent: Friday, December 10, 2004 1:06 PM
  To: Harish M
  Subject: RE:RE: Question on LMP Adjacency

  Thanks for very and very fast response.

  I'm sorry but, my question is about the LMP adjacency.
  The samle network is that Node#1 is physically connected to Node#2, then
Node#2 is physically connected to Node#3. There is no physical connection
between Node#1 and Node#3.
  And, an EoS#1 channel  is terminated in Node#1 amd Node#2, the other EoS#2
channel is
  terminated in Node#1 and Node#3 via Node#2. Here, in case of the EoS#1,
LMP adjacent nodes are Node#1 and Node#2, but in case of the EoS#2, LMP
adjacent nodes are Node#1 and Node#3 under th condition that the definition
of LMP adjacency is observed.
  My question is if my understanding is correct or not.

  -----?? ???-----
  ?? ??: "Harish M" <[email-masked]>
  ?? ??: 2004-12-10 ?? 4:29:21
  ?? ??: "±e¿?E" <[email-masked]>, "[email-masked]"
<[email-masked]>
  ??:
  ??: RE: Question on LMP Adjacency

  Question is not clear.
   -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of ???
  Sent: Friday, December 10, 2004 12:37 PM
  To: [email-masked]
  Subject: Question on LMP Adjacency

    Hi, ccampers

    I've a question on the LMP adjacency.
    In the LMP draft, the definition is as follows:

       An "LMP adjacency" is formed between two nodes when at least one bi-
       directional control channel is established between them. Multiple
       control channels may be active simultaneously for each adjacency;
       control channel parameters, however, MUST be individually negotiated
       for each control channel.

    Then, my question is this.

    For an example,
    we assume a sample network consisting of Node#1, Node#2, and Node#3.
Node#1 is directly connected to Node#2, and Node#2 is directly connected to
Node#3.
    This means there is no direct connection between Node#1 and Node#3 in
the sample network.
    In this situation, we assume that an EoS channel(EoS#1) between Node#1
and Node#2 is terminated, but another EoS channel(EoS#2) between Node#1 and
Node#3 is terminated through Node#2.
    Here, I think that in case of the EoS#1, LMP adjacent nodes are Node#1
and Node#2, but in case of the EoS#2, LMP adjacent nodes are Node#1 and
Node#3. In addition, I think that the type of data link for EoS#1 and EoS#2
is a component link and the link connection verification of EoS#2 between
Node#1 and Node#3 could be performed. The only condition is, of course,  is
to observe the definition of the LMP adjacency above.

    Node#1               Node#2            Node#3
          |-----EoS#1----|                        |
          |------------EoS#2------------|

    Could you help me if my understanding is short ?

    Thanks,

    Young.

--Boundary_(ID_ms8EbzYvxEPRPWPRq0zq4g)
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.1479" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D687344507-10122004><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D843275207-10122004><FONT face=3DArial color=3D#0000ff =
size=3D2>LMP adjacency is=20
established between two directly connected nodes over=20
CC</FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D687344507-10122004><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D843275207-10122004></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D687344507-10122004><FONT face=3DArial =
size=3D2>&nbsp;&nbsp; An "LMP=20
adjacency" is formed between two nodes when at least one =
bi-<BR>&nbsp;&nbsp;=20
directional control channel is established between them.=20
Multiple<BR>&nbsp;&nbsp; control channels may be active simultaneously =
for each=20
adjacency;<BR>&nbsp;&nbsp; control channel parameters, however, MUST be=20
individually negotiated<BR>&nbsp;&nbsp; for each control=20
channel.</FONT></SPAN></DIV>
<DIV><SPAN class=3D687344507-10122004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D687344507-10122004><FONT face=3DArial size=3D2>
<DIV><SPAN class=3D687344507-10122004><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D843275207-10122004><FONT face=3DArial color=3D#0000ff =
size=3D2>If multiple CC's=20
present (in one adjacency) then, keep-alive hello will be there on all =
CCs=20
separately.</FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D687344507-10122004><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D843275207-10122004><FONT face=3DArial color=3D#0000ff =
size=3D2>Control=20
information (Signaling/Routing protocol updates) can be sent on any one=20
CC.</FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D687344507-10122004><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D843275207-10122004></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D687344507-10122004><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D843275207-10122004><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT></SPAN></FONT></SPAN>&nbsp;</DIV></FONT></SPAN></DIV>
<BLOCKQUOTE>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Kim Young Hwa=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, December 10, 2004 =
1:06=20
  PM<BR><B>To:</B> Harish M<BR><B>Subject:</B> RE:RE: Question on LMP=20
  Adjacency<BR><BR></FONT></DIV>
  <DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: System">
  <DIV>Thanks for very and very fast response.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>I'm sorry but, my question is about the LMP adjacency.</DIV>
  <DIV>The samle network&nbsp;is that&nbsp;Node#1 is physically =
connected to=20
  Node#2, then Node#2 is physically connected to Node#3. There is no =
physical=20
  connection between Node#1 and Node#3.</DIV>
  <DIV>And, an EoS#1 channel&nbsp; is terminated in Node#1 amd Node#2, =
the other=20
  EoS#2 channel is </DIV>
  <DIV>terminated in Node#1 and Node#3 via Node#2. Here, in case of the =
EoS#1,=20
  LMP adjacent nodes are Node#1 and Node#2, but in case of the EoS#2, =
LMP=20
  adjacent nodes are Node#1 and Node#3 under th condition that the =
definition of=20
  LMP adjacency is observed.</DIV>
  <DIV>My question is&nbsp;if my understanding is correct or not.</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff></FONT><BR>-----?? =
???-----<BR><B>??=20
  ??:</B> "Harish M" &lt;[email-masked]&gt;<BR><B>?? ??:</B> =
2004-12-10 ??=20
  4:29:21<BR><B>?? ??:</B> "=B1e=BF?E&shy;" &lt;[email-masked]&gt;,=20
  "[email-masked]" &lt;[email-masked]&gt;<BR><B>??:</B> =
<BR><B>??:</B>=20
  RE: Question on LMP Adjacency<BR><BR></DIV>
  <DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Question is not=20
  clear.</FONT></SPAN></DIV>
  <DIV><FONT face=3DTahoma><FONT size=3D2><FONT face=3DArial=20
  color=3D#0000ff></FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3DTahoma><FONT size=3D2>&nbsp;</SPAN>-----Original=20
  Message-----<BR><B>From:</B> [email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of =
</B>???<BR><B>Sent:</B>=20
  Friday, December 10, 2004 12:37 PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Question on LMP=20
  Adjacency<BR><BR></DIV></FONT></FONT>
  <BLOCKQUOTE>
    <DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: ??">
    <DIV>
    <DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: ??">
    <DIV>Hi, ccampers</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>I've a question on the LMP adjacency.</DIV>
    <DIV>In the LMP draft, the definition is as follows:</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>&nbsp;&nbsp; An "LMP adjacency" is formed between two nodes =
when at=20
    least one bi-<BR>&nbsp;&nbsp; directional control channel is =
established=20
    between them. Multiple<BR>&nbsp;&nbsp; control channels may be =
active=20
    simultaneously for each adjacency;<BR>&nbsp;&nbsp; control channel=20
    parameters, however, MUST be individually negotiated<BR>&nbsp;&nbsp; =
for=20
    each control channel.</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
    <DIV>Then, my question is this.</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>For an example, </DIV>
    <DIV>we assume&nbsp;a sample network&nbsp;consisting of Node#1, =
Node#2, and=20
    Node#3. Node#1 is directly connected to Node#2, and Node#2 is =
directly=20
    connected to Node#3.</DIV>
    <DIV>This means there is no direct connection between Node#1 and =
Node#3 in=20
    the sample network.</DIV>
    <DIV>In this situation, we assume that an EoS =
channel(EoS#1)&nbsp;between=20
    Node#1 and Node#2 is terminated, but another EoS channel(EoS#2) =
between=20
    Node#1 and Node#3 is terminated through Node#2.</DIV>
    <DIV>Here, I think that in case of the EoS#1, LMP adjacent nodes are =
Node#1=20
    and Node#2, but in case of the EoS#2, LMP adjacent nodes are Node#1 =
and=20
    Node#3. In addition, I think that the type of data link for EoS#1 =
and EoS#2=20
    is a component link and the link connection verification of EoS#2 =
between=20
    Node#1 and Node#3 could be performed. The only condition is, of=20
    course,&nbsp; is to observe the definition of the LMP adjacency =
above.=20
</DIV>
    <DIV>&nbsp;</DIV>
    =
<DIV>Node#1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
    =
Node#2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

    Node#3</DIV>
    <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|-----EoS#1----|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
    |</DIV>
    <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|------------EoS#2------------|</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>Could&nbsp;you help me if my understanding is short ?</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>Thanks,</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>Young.</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>&nbsp;</DIV></DIV><IMG style=3D"DISPLAY: none" height=3D0=20
    =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3D0622@etri.=
re.kr&amp;name=3D%b1%a4%c0%fc%b4%de%b8%c1%c1%a6%be%ee%c6%c0&amp;fromemail=
=[email-masked]&amp;messageid=3D%3C1778101c4ddfa$a7cd2b20$8310fe81@e=
tri.info%3E"=20
    width=3D0 NOSEND=3D"1"></DIV></DIV><IMG style=3D"DISPLAY: none" =
height=3D0=20
    =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3Dccamp@ops.=
ietf.org&amp;name=3Dccamp%40ops.ietf.org&amp;fromemail=[email-masked]=
r&amp;messageid=[email-masked]%3E"=20
    width=3D0 NOSEND=3D"1"></BLOCKQUOTE></DIV></DIV><IMG =
style=3D"DISPLAY: none"=20
  height=3D0=20
  =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3Dharishm@hu=
awei.com&amp;name=3DHarish+M&amp;fromemail=[email-masked]&amp;messag=
eid=[email-masked]%3E"=20
  width=3D0 NOSEND=3D"1"></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_ms8EbzYvxEPRPWPRq0zq4g)--

Delivery-date: Fri, 10 Dec 2004 07:23:42 +0000
Date: Fri, 10 Dec 2004 12:59:21 +0530
From: Harish M <[email-masked]>
Subject: RE: Question on LMP Adjacency
To: =?ks_c_5601-1987?B?ob5loq+l7EWhqQ==?= <[email-masked]>, [email-masked]
Reply-to: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_d9vC5O9cBhNsUS8WAR8QWw)
Content-type: text/plain; charset=ks_c_5601-1987
Content-transfer-encoding: 8BIT

Question is not clear.

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
±è¿µÈ­
Sent: Friday, December 10, 2004 12:37 PM
To: [email-masked]
Subject: Question on LMP Adjacency

  Hi, ccampers

  I've a question on the LMP adjacency.
  In the LMP draft, the definition is as follows:

     An "LMP adjacency" is formed between two nodes when at least one bi-
     directional control channel is established between them. Multiple
     control channels may be active simultaneously for each adjacency;
     control channel parameters, however, MUST be individually negotiated
     for each control channel.

  Then, my question is this.

  For an example,
  we assume a sample network consisting of Node#1, Node#2, and Node#3.
Node#1 is directly connected to Node#2, and Node#2 is directly connected to
Node#3.
  This means there is no direct connection between Node#1 and Node#3 in the
sample network.
  In this situation, we assume that an EoS channel(EoS#1) between Node#1 and
Node#2 is terminated, but another EoS channel(EoS#2) between Node#1 and
Node#3 is terminated through Node#2.
  Here, I think that in case of the EoS#1, LMP adjacent nodes are Node#1 and
Node#2, but in case of the EoS#2, LMP adjacent nodes are Node#1 and Node#3.
In addition, I think that the type of data link for EoS#1 and EoS#2 is a
component link and the link connection verification of EoS#2 between Node#1
and Node#3 could be performed. The only condition is, of course,  is to
observe the definition of the LMP adjacency above.

  Node#1               Node#2            Node#3
        |-----EoS#1----|                        |
        |------------EoS#2------------|

  Could you help me if my understanding is short ?

  Thanks,

  Young.

--Boundary_(ID_d9vC5O9cBhNsUS8WAR8QWw)
Content-type: text/html; charset=ks_c_5601-1987
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=3Dks_c_5601-1987">
<META content=3D"MSHTML 6.00.2800.1479" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D015522807-10122004><FONT face=3DArial color=3D#0000ff =

size=3D2>Question is not clear.</FONT></SPAN></DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN =
class=3D015522807-10122004><FONT=20
face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
class=3D015522807-10122004>&nbsp;</SPAN>-----Original =
Message-----<BR><B>From:</B>=20
[email-masked] [mailto:[email-masked]]<B>On Behalf =
Of=20
</B>=B1=E8=BF=B5=C8=AD<BR><B>Sent:</B> Friday, December 10, 2004 12:37 =
PM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> Question on LMP=20
Adjacency<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE>
  <DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
=B1=BC=B8=B2">
  <DIV>
  <DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
=B1=BC=B8=B2">
  <DIV>Hi, ccampers</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>I've a question on the LMP adjacency.</DIV>
  <DIV>In the LMP draft, the definition is as follows:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;&nbsp; An "LMP adjacency" is formed between two nodes when =
at least=20
  one bi-<BR>&nbsp;&nbsp; directional control channel is established =
between=20
  them. Multiple<BR>&nbsp;&nbsp; control channels may be active =
simultaneously=20
  for each adjacency;<BR>&nbsp;&nbsp; control channel parameters, =
however, MUST=20
  be individually negotiated<BR>&nbsp;&nbsp; for each control =
channel.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Then, my question is this.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>For an example, </DIV>
  <DIV>we assume&nbsp;a sample network&nbsp;consisting of Node#1, =
Node#2, and=20
  Node#3. Node#1 is directly connected to Node#2, and Node#2 is directly =

  connected to Node#3.</DIV>
  <DIV>This means there is no direct connection between Node#1 and =
Node#3 in the=20
  sample network.</DIV>
  <DIV>In this situation, we assume that an EoS =
channel(EoS#1)&nbsp;between=20
  Node#1 and Node#2 is terminated, but another EoS channel(EoS#2) =
between Node#1=20
  and Node#3 is terminated through Node#2.</DIV>
  <DIV>Here, I think that in case of the EoS#1, LMP adjacent nodes are =
Node#1=20
  and Node#2, but in case of the EoS#2, LMP adjacent nodes are Node#1 =
and=20
  Node#3. In addition, I think that the type of data link for EoS#1 and =
EoS#2 is=20
  a component link and the link connection verification of EoS#2 between =
Node#1=20
  and Node#3 could be performed. The only condition is, of course,&nbsp; =
is to=20
  observe the definition of the LMP adjacency above. </DIV>
  <DIV>&nbsp;</DIV>
  =
<DIV>Node#1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
  =
Node#2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  Node#3</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|-----EoS#1----|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
  |</DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|------------EoS#2------------|</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Could&nbsp;you help me if my understanding is short ?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Thanks,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Young.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV></DIV><IMG style=3D"DISPLAY: none" height=3D0=20
  =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3D0622@etri.=
re.kr&amp;name=3D%b1%a4%c0%fc%b4%de%b8%c1%c1%a6%be%ee%c6%c0&amp;fromemail=
=[email-masked]&amp;messageid=3D%3C1778101c4ddfa$a7cd2b20$8310fe81@e=
tri.info%3E"=20
  width=3D0 NOSEND=3D"1"></DIV></DIV><IMG style=3D"DISPLAY: none" =
height=3D0=20
  =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3Dccamp@ops.=
ietf.org&amp;name=3Dccamp%40ops.ietf.org&amp;fromemail=[email-masked]=
r&amp;messageid=[email-masked]%3E"=20
  width=3D0 NOSEND=3D"1"></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_d9vC5O9cBhNsUS8WAR8QWw)--

Delivery-date: Fri, 10 Dec 2004 07:09:11 +0000
Reply-To: =?ks_c_5601-1987?B?sei/tcit?= <[email-masked]>
From: =?ks_c_5601-1987?B?sei/tcit?= <[email-masked]>
To: <[email-masked]>
Cc: 
Bcc: 
Subject: Question on LMP Adjacency
Date: Fri, 10 Dec 2004 16:07:25 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCCxpMD8tN64wcGmvu7GwCwgtOM=?= =?ks_c_5601-1987?B?tOc=?=
content-class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_1F04F_01C4DED2.56BA39C0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_1F04F_01C4DED2.56BA39C0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

<DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =B1=BC=B8=B2">
<DIV>
<DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =B1=BC=B8=B2">
<DIV>Hi, ccampers</DIV>
<DIV>&nbsp;</DIV>
<DIV>I've a question on the LMP adjacency.</DIV>
<DIV>In the LMP draft, the definition is as follows:</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; An "LMP adjacency" is formed between two nodes when at =
least one bi-<BR>&nbsp;&nbsp; directional control channel is established =
between them. Multiple<BR>&nbsp;&nbsp; control channels may be active =
simultaneously for each adjacency;<BR>&nbsp;&nbsp; control channel =
parameters, however, MUST be individually negotiated<BR>&nbsp;&nbsp; for =
each control channel.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Then, my question is this.</DIV>
<DIV>&nbsp;</DIV>
<DIV>For an example, </DIV>
<DIV>we assume&nbsp;a sample network&nbsp;consisting of Node#1, Node#2, =
and Node#3. Node#1 is directly connected to Node#2, and Node#2 is =
directly connected to Node#3.</DIV>
<DIV>This means there is no direct connection between Node#1 and Node#3 =
in the sample network.</DIV>
<DIV>In this situation, we assume that an EoS =
channel(EoS#1)&nbsp;between Node#1 and Node#2 is terminated, but another =
EoS channel(EoS#2) between Node#1 and Node#3 is terminated through =
Node#2.</DIV>
<DIV>Here, I think that in case of the EoS#1, LMP adjacent nodes are =
Node#1 and Node#2, but in case of the EoS#2, LMP adjacent nodes are =
Node#1 and Node#3. In addition, I think that the type of data link for =
EoS#1 and EoS#2 is a component link and the link connection verification =
of EoS#2 between Node#1 and Node#3 could be performed. The only =
condition is, of course,&nbsp; is to observe the definition of the LMP =
adjacency above. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Node#1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; =
Node#2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Node#3</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|-----EoS#1----|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; |</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|------------EoS#2------------|</DIV>
<DIV>&nbsp;</DIV>
<DIV>Could&nbsp;you help me if my understanding is short ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Young.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></DIV><IMG style=3D"DISPLAY: none" height=3D0 =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3D0622@etri.=
re.kr&amp;name=3D%b1%a4%c0%fc%b4%de%b8%c1%c1%a6%be%ee%c6%c0&amp;fromemail=
=[email-masked]&amp;messageid=3D%3C1778101c4ddfa$a7cd2b20$8310fe81@e=
tri.info%3E" width=3D0></DIV></DIV><img style=3D"display:none" width=3D0 =
height=3D0 =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3Dccamp@ops.=
ietf.org&name=3Dccamp%40ops.ietf.org&fromemail=[email-masked]&messag=
eid=[email-masked]%3E">
------=_NextPart_000_1F04F_01C4DED2.56BA39C0--

Delivery-date: Thu, 09 Dec 2004 12:38:48 +0000
Date: Thu, 09 Dec 2004 13:36:40 +0100
From: [email-masked]
Reply-To: [email-masked]
Organization: Alcatel CTO/R&I
To: Adrian Farrel <[email-masked]>
Cc: [email-masked], Kireeti Kompella <[email-masked]>, Arthi Ayyangar <[email-masked]>, JP Vasseur <[email-masked]>
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?

Adrian Farrel wrote:

>Hi,
>
>As documented in the minutes from Washington DC, we discussed whether to make this draft
>an WG document.
>
>A show of hands in the room indicated that there were no objections but that not many had
>read the draft. So, two questions for the list...
>
>Should this become a WG draft?
>  
>
yes

>Is it fine to include stitching in this draft, or does the wider applicability of
>stitching mean that it should be pulled out into a separate draft?
>
>  
>
As wider applicability foreseen, it should be better for process and 
clarity purpose to have a separate draft.

>Thanks,
>Adrian

Delivery-date: Wed, 08 Dec 2004 19:27:43 +0000
content-class: urn:content-classes:message
Subject: RE: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Wed, 8 Dec 2004 13:26:00 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "JP Vasseur" <[email-masked]>

Answers below-
Deborah=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, December 07, 2004 9:43 AM
To: [email-masked]
Cc: Kireeti Kompella; Arthi Ayyangar; JP Vasseur
Subject: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?

Hi,

As documented in the minutes from Washington DC, we discussed whether to
make this draft
an WG document.

A show of hands in the room indicated that there were no objections but
that not many had
read the draft. So, two questions for the list...

Should this become a WG draft?
> Yes

Is it fine to include stitching in this draft, or does the wider
applicability of
stitching mean that it should be pulled out into a separate draft?
>If wider applicability, then a separate draft, with links to the other
draft (and hopefully both drafts progress in-sync)

Thanks,
Adrian

Delivery-date: Wed, 08 Dec 2004 14:32:41 +0000
Date: Wed, 8 Dec 2004 09:32:12 -0500 (EST)
Subject: Re: Starting a discussion on graceful shutdown
From: [email-masked]
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked]

Adrian,

Thanks for starting these discussions. See my comments in-line.

Igor

> Hi,
>
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-00.txt
> was
> discussed at the meeting in Washington DC, and one of the questions raised
> was whether or
> not we already had (multiple!) mechanisms capable of performing the
> function described in
> the draft.
>
> Kireeti quite rightly suggested that we step back and make sure we
> understand the
> requirements. This is my take on those requirements and I would appreciate
> it if the
> authors of the draft joined in and other people on the list commented.
>
> We wish to manage a link that needs to be taken out of service in some way
> (data plane
> and/or control plane will be disrupted). The link concerned has active
> LSPs and we wish to
> offer upstream LSRs (in particular the ingress) the opportunity to use
> make-before-break
> to re-route the LSPs.
>
> In order to achieve this, we need to communicate to the upstream nodes.
> Should we choose
> signaling or routing? Are there benefits that mean we should use both, or
> should we limit
Ø	to just one?

IB>> We need both: (a) routing for making sure that the link will not be
used for new LSPs; (b) signaling for suggesting mb4b on active LSPs going
through the link. However, I believe we have more that enough tools to
accomplish this. By re-advertising TE LINK TLV we achieve (a), by
inserting ALARM-SPEC into Resv and/or signaling PathErr with removal state
flag cleared we achieve (b)

>
> There is another aspect to be considered. Should we also attempt to
> protect new path
> computations from selecting the link that will be taken out of service?
IB>> The answer is Yes. The main (if not only) purpose of TE
advertisements is to influence on PCE, isn’t it ?

>
> How should we consider the case of a node (data plane and/or control
> plane) being taken
> out of service? Is a node simply a collection of links?
>

IB>> From the PCE viewpoint a node is a vertex on TE network graph, while
links are edges/arcs. Hence node is not a collection of links, rather an
interconnection of local sides of its links. The removing of TE RTR TLV
advertisement de-synchronizes all links originating/terminating on the
node, making them unavailable for the path computation. It is also
possible to instruct active LSP ingresses to avoid using a node with
particular node ID (TE Router Address), rather than bunch of links, in
mb4b operations.

> If a component link of a bundle is being taken out of service (and
> assuming other
> component links are available) is this just an issue for the adjacent
> nodes or does it
> need to be communicated more widely? If the downstream node decides to
> take the component
Ø	link out of service, how does it inform the upstream node?

IB>> A node that decides to take a component out of service should
re-advertise TE LINK TLV associated with the local side of the
corresponding bundle.
I don’t think we have a solution how to swing an LSP from one component to
another if the current one is intended to go out of service. I always felt
that we are missing a mechanism to negotiate components between adjacent
nodes similar to the label negotiation.

>
> Does it matter whether it is the control plane or the data plane that will
> be taken out of
> service?
>

IB>> It does for active LSPs. For instance, it is possible to temporarily
take out of service control plane of some node without performing mb4b
operations on LSPs going through the node.

> Opinions please.
>
> I would like to see these issues and their answers captured clearly in a
> requirements
> section of any draft. Would the authors of
> draft-ali-ccamp-mpls-graceful-shutdown-00.txt
> be willing to take that on even though the end result might be that
> procedures other than
> those they suggest will be selected?
>
> Adrian
>
>
>

Delivery-date: Wed, 08 Dec 2004 14:21:11 +0000
Date: Wed, 08 Dec 2004 15:18:59 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC: Dimitri Papadimitriou <[email-masked]>,  [email-masked]
Subject: Re: Node ID Hello [Was: Re: Draft minutes from Tove]

hi adrian:

> You're right. It was published on 26th October, but that means it
> must have been submitted before then.
> 
> Can you remind me? This revision was to address all of the WG last
> call comments; yes?

yes - it was

> Can you summarise the changes you made for the list, please.

these are the following:

1. clarify the node-id based Hellos usage when there is more than one 
link between a pair of node and the GMPLS PSC vs MPLS applicability - 
this has been performed by adding the following paragraph:

"  Even in the case of packet switching capable end-points, when link
    failure detection is performed by some means other than RSVP Hello
    messages (e.g., [BFD]), the use of Node-ID based Hello sessions is
    also optimal for detection of signaling adjacency failures for GMPLS-
    /RSVP-TE when there is more than one link between a pair of nodes. "

2. in an IPv6 network, provide "Node ID" details

"  For IPv6, the Node-ID refers to the Router_IPv6_Address for OSPFv3
    [OSPFv3-TE] and the IPv6 TE Router_ID for IS-IS [IS-ISv6-TE]. This
    section formalizes a procedure for establishing Node-ID based Hello
    sessions."

3. justify the compatibility statement of section 4:

"  The procedure presented in this document is backward compatible with
    both [RFC3209] and [RFC3473].

    Per [RFC 3209], the Hello mechanism is intended for use between
    immediate neighbors and Hello messages are by default sent between
    direct RSVP neighbors. This document does not modify this behavior as
    it uses as "local node_id" the IPv4/IPv6 source address of the
    sending node and as "remote node_id" the IPv4/IPv6 destination
    address of the neighbor node. TTL/Hop Limit setting and processing
    are also left unchanged.

    Moreover, this document does not modify the use of Hello Processing
    for State Recovery as defined in Section 9.3 of [RFC 3473] (including
    definition and processing of the RESTART_CAP object). "

4. justify *why* no new security issues are introduced (as part of the 
section 5)

"  As this document does not modify or extend the RSVP Hello messages
    exchange between immediate RSVP neighbors, it does not introduce new
    security considerations.

    The security considerations pertaining to the original [RFC3209]
    remain relevant. RSVP message security is described in [RFC2747] and
    provides Hello message integrity and authentication of the Node-ID
    ownership."

5. a bunch of editorial issues

- IPR boilerplate
- remove the "Routing Area ID Summary"
- remove Table of Contents
- spurious double space
- spurious question mark
- consistency between "Hello" vs "hello" and "node-id" vs "node id"
- formatting of the references

thanks,
- dimitri.

> Thanks, Adrian ----- Original Message ----- From: "dimitri
> papadimitriou" <[email-masked]> To: "Adrian Farrel"
> <[email-masked]> Cc: <[email-masked]> Sent: Saturday,
> December 04, 2004 9:20 PM Subject: Re: Draft minutes from Tove
> 
> 
> 
>> hi adrian,
>> 
>> a small comment:
>> 
>> 
>>> Adrian - Note: Node_Id based Hello has not been updated before 
>>> deadline
>> 
>> i mentioned that the update of the Node_Id based Hello document has
>> been effectively submitted before the deadline
>> 
>> thanks, - dimitri.
>> 
>> Adrian Farrel wrote:
>> 
>> 
>>> Hi ccamp! Thanks to Lyndon Ong, Deborah Brungard, and Dimitri
>>> Papadimitriou we can now read about the ccamp meeting, IETF61. 
>>> Please provide your comments no later than 3rd December if you
>>> miss any important wording (or you like to change the complete
>>> meeting;-) / Tove Tove Madsen Acreo AB [email-masked] === 
>>> 61st IETF CCAMP Minutes 11/11/2004 Minutes taken by Lyndon Ong,
>>> Deborah Brungard, Dimitri Papadimitriou
>>> 
>>> 1. Admin and agenda bash - Chairs (5 min) Agenda bashing - no
>>> changes 2. Status of WG drafts - Adrian (10 min) Drafts - now
>>> unblocked, however the removal of the MPLS bundling draft has 
>>> caused another snag. We have got two new RFCs, Architecture
>>> (3945) and SONET/SDH Extensions (3946).  Six drafts are in the
>>> queue.  Five are in IETF Last Call, two are in IESG review.  15
>>> active drafts - if you want a draft adopted as WG draft, let's
>>> finish these first!  Tunnel trace in particular seems to have
>>> very little interest - will be discussed wrt to rechartering. 
>>> Overall status: almost all milestones completed, should recharter
>>> or close in March '04! Lou - slide does not list all 15 drafts -
>>> others are still active? In particular Alarm_Spec Adrian said no
>>> intention to exclude, asked if implementation on alarm draft, Lou
>>> said at least one, possibly two, Kireeti said only need one, so
>>> Ok to go forward. Adrian - Note: Node_Id based Hello has not been
>>> updated before deadline Adrian - Milestones and re-chartering
>>> will be covered at the end of the meeting. 3. Link Bundling -
>>> Zafar Ali -- Issues with current RFCs and drafts -- Draft removed
>>> from the RFC editor's queue -- Issues with scooping type 4/5 TLVs
>>> for IF_ID_RSVP_HOP and IF_ID_ERROR_SPEC, also recording of route 
>>> -- Plan to address first two issues in an updated draft but
>>> component link recording will remain outside the scope of the
>>> bundling draft.  Will allow but recommend against use of types
>>> 4/5. -- Work on recording/explicit control will be done in a
>>> separate ID.  Home in MPLS or CCAMP? -> see slides -- Plans 
>>> Pulled from queue (reviewed slides) -- Adrian: procedure -> MPLS
>>> WG own document. Do review on what happens in this WG Note: speed
>>> is really important as we have multiple blocking documents in the
>>> CCAMP WG queue. -- Kireeti - this is not free for all on the
>>> bundling draft - change to be proposed and to be sent on the list
>>> (delta only) George: as MPLS chair, MPLS group plans to do
>>> updates quickly - considered as last call comments
>>> 
>>> 4. ASON Signaling Solutions - Dimitri P (5min) 
>>> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.
>>> 
>>> 
>>> txt> 
>>> <http://www.olddog.co.uk/draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt>
>>> 
>>> 
>>> -- Mention OIF response is on the way -- ASON signaling - no
>>> updates but lots of thinking esp. call setup message naming
>>> (Notify vs. specialized message), desire not to "piggyback" call 
>>> information in the connection message.  Expect finalized draft
>>> around Christmas time. -- ASON routing solutions design team -
>>> Evaluation of common "pattern" has taken time, evaluation
>>> document should be issued by end- November. - Model shown - use
>>> of terminology - what is TE Router ID, what is OSPF Router ID? -
>>> Further considerations - control plane does not transport the
>>> actual transport plane ids, but its view of the transport plane,
>>> using an associated IP addressing space. - No internal structure
>>> is associated with an abstract node. - Hierarchy focus is on
>>> exchange of information between peers. - Representation of
>>> bandwidth needs further thought. -- Adrian - it seems the DT has
>>> been making good progress, CCAMP WG has unfortunately not been
>>> aware of the progress, progress must be shown to the group by
>>> either sending status or updating the draft. -- Dimitri - will
>>> mail to the list. -- Zafar - how does this work relate to the
>>> OSPF and ISIS groups? -- DP - we are evaluating what may be
>>> missing, after this evaluation we can address protocol-specific
>>> issues. -- Zafar - Are you looking at existing mechanisms? --
>>> Dimitri - global applicability is next step, currently looking at
>>> what info is exchanged
>>> 
>>> 5. ITU Liaison - Lyndon Ong -- ITU continues to be interested in
>>> converging the work on signaling and routing -- ITU thanks CCAMP
>>> for its liaisons, and esp. Adrian for attending the last Q14
>>> meeting -- ITU is currently working on ASON management
>>> specifications and thanks CCAMP for its liaison of the GMPLS MIB
>>> work for its review -- Zafar - can we also have a report of OIF
>>> status?  Chairs and LO; there is nothing formal to report at this
>>> time that's why it was not scheduled on the agenda.  However,
>>> liaisons will be sent to the mailing list for everyone's review,
>>> and if something formal is made available, it will be scheduled. 
>>> -- Lyndon - there is ongoing discussion and communication just
>>> sent back to IETF -- Adrian - but not there yet (not available) 
>>> -- Lyndon - is there a need for a permanent liaison from the OIF
>>> at the CCAMP meeting? -- Adrian - if there is something to be
>>> discussed it will be considered on a per-request/per-case basis 
>>> 6. Graceful Shutdown - Zafar Ali (10 min) 
>>> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-0
>>> 
>>> 
>>> 0.txt -- Intention is to support a planned shutdown, e.g., for
>>> maintenance purposes -- IGP based solution does not cover
>>> Inter-AS/Area scenarios -- RSVP-based solution does not convey
>>> information to all nodes in the network. -- Both mechanisms must
>>> complement each other -- Use existing sub-code of the Path Error
>>> message, then perform make-before-break for the LSP. Proposed
>>> changes are minor and based on existing framework. -- Would like
>>> to propose this ID as a WG document Rahul- is this intra or
>>> inter?  inter-domain can use hierarchy of LSPs 
>>> (nesting/stitching) to achieve this isolation. -- Zafar - though
>>> recognize two mechanisms -- Rahul- we should clarify these
>>> aspects, as well as inter-domain TE aspects. -- Zafar - can add
>>> these aspects in the document -- Richard Rabbat - why is this
>>> GMPLS rather than MPLS? Zafar - could be shutting down any type
>>> of link. -- Adrian - in terms of problem space it is needed in
>>> both cases -- Igor Bryskin - this is a data plane problem
>>> followed by rerouting - why don't we use existing mechanisms such
>>> as propagating alarms? Zafar - distinguish this from alarms as
>>> this is not something that requires an immediate reroute. This is
>>> not intended to tackle data plane alarms -- Kireeti - maintenance
>>> of the link/node - out-of-service issue is to get traffic out of
>>> the link Igor- alarms do not only mean "failure". Could it use
>>> alarm severity? -- Kireeti - not an alarm situation. -- Adrian -
>>> this is maintenance alarm => requires to scope the work -- Igor -
>>> Tools already exist to trigger the same thing, the existing tools
>>>  are more powerful than this proposed one -- Zafar - point to the
>>> capability of the mechanism having the indication to perform
>>> make-before-break - also suggest put on the list what you think
>>> are alternative mechanisms -- Lou Berger - says if we do this, we
>>> should use existing mechanisms such as admin status or alarm
>>> (Arthi's suggested one, Igor's alarm admin status). -- Zafar -
>>> this mechanism is already in the spec - JP's re-optimization 
>>> draft -- Lou - other mechanisms are in RFCs. We should decide on
>>> mechanisms before we accept as a WG draft. -- Kireeti - step back
>>> from the solution, so the point is to write down what is to be
>>> achieved (take things out gracefully) -> need first to look at 
>>> requirements for what want to do. -- Zafar - agreement 7.
>>> Interdomain Framework - Adrian (5min) 
>>> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework
>>> 
>>> 
>>> -00.txt> -- Minor changes since last time, but published as WG
>>> draft -- Applies to both MPLS and GMPLS, but currently limited to
>>> simpler functions for initial work -- Realize need more
>>> discussion on definition of "domain" e.g. Nested domains, ensure
>>> GMPLS included. Will take to list for discussion. -- This covers
>>> "simple" functions, what about "advanced" functions such as 
>>> diverse paths, mapping domain-specific constraints such as
>>> DiffServ, pt-to-mpt, etc.? -- Adrian's suggestion is to keep this
>>> separate for convenience. -- Rahul - MPLS OAM - building blocks
>>> are in place, so it can go in this document; P2MP is considerably
>>> less well understood. -- Kireeti - what about GMPLS OAM? --
>>> Dimitri - need to understand what we mean by GMPLS OAM. Suggest
>>> phased approach. 8. Interdomain TE Requirements - Tomohiro Otani
>>> (5min) 
>>> <http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-01.t
>>> 
>>> 
>>> xt> -- Joint proposal from NTT/KDDI, can be used for L1VPN,
>>> MPLS-TE -- Changes:  added section identifying the following
>>> general requirements - EGP extensions for GMPLS - GMPLS Inter-AS
>>> signaling, path calculation and recovery - GMPLS interdomain TE
>>> management -- Remaining issues: - Investigate added load created
>>> by EGP extensions - Investigate L1VPN, use of SRLG for
>>> consistency, rechartering impacts - Propose WG document - Zafar -
>>> recommended would be a good basis for inter-domain TE framework 
>>> -- Arthi- support effort, but has too many solutions-related
>>> aspects in it. Also suggest separating requirements into
>>> signaling, routing and path computation. Need to clarify what is
>>> meant by domain - refer to framework document. -- Dimitri - what
>>> about reachability information exchange?  Not addressed, but will
>>> be an important aspect. -- Adrian- this is solution, not
>>> requirements. Suggest to separate requirements and solutions.
>>> General approval of the work, but need to remove solutions.
>>> Should consider reachability as well as TE aspects.  Restructure 
>>> as Arthi suggests. -- Otani- agree, will separate -- Kireeti
>>> summarizing: separate requirements from solution and structure: 
>>> signaling from routing (in part. reachability) 9. Summarize
>>> Status and plans of PCE BOF (JP Vasseur) (5 minutes) -- Scope
>>> issues - No intent to come up with new interdomain routing
>>> paradigm - Scoped applicability to a limited number of TE LSPs -
>>> Scoped to a "simple" topology of ASes or areas -- Previous BOF -
>>> clear requirements from many SPs and common theme of problem -
>>> MPLS TE LSP path computation -- Architecture - comments noted
>>> global picture needed, but no standardization of architecture.
>>> New revision to be submitted soon in the meantime please
>>> comments! -- Note agreed no intention to extend LDP, but possibly
>>> other protocols. -- Agreed on proposed charter and milestones,
>>> proposal to be sent out early next week. -- Many in favor of new
>>> WG, none against - need IESG review and work on charter -- Bijan
>>> Jabbari - what scale of LSPs? -- JP - no specific number, not
>>> full mesh - does this mean no scalability concerns? -- Adrian -
>>> need to make the problem manageable, at least initially. -- Bijan
>>> - will WG be open to new architectures? -- Kireeti - take this to
>>> the list. -- Peter Toms - support this, lots of requests for
>>> this. 10. Inter-Domain RSVP-TE extensions - Arthi Ayyangar (5min)
>>>  
>>> <http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-
>>> 
>>> 
>>> te-00.txt> -- Changes - include separate section on stitching and
>>> required extensions, clarifications for non-packet LSPs. --
>>> Request to make it a WG document - none against, but limited
>>> number agreeing (note: not many read the draft)- list. -- Adrian
>>> - stitching has wider applicability - should we pull it out into
>>> a separate draft? 11. Diverse Inter-region Setup - D'Achille -
>>> presented by Adrian (5 min) 
>>> <http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-
>>> 
>>> 
>>> 04.txt> -- Adrian not that familiar with this draft. Flags one
>>> slide on message exchange where the head end is in the center
>>> rather than at the end. Notes several claim, explicitly claim of
>>> no new protocol seems questionable as new objects are defined.
>>> Need further feedback. Can't take questions as no authors present
>>> to discuss - take to list 12. Related to 11.  Protection for
>>> Inter-AS tunnels - Decnodder - Cristel Pelsser 
>>> <http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas-protectio
>>> 
>>> 
>>> n-00.txt> -- Differs from 11, addresses requirements from TEWG
>>> draft -- Uses RSVP-TE and FRR -- Adds clarifications on SRLG
>>> scope, assumed to correspond to a single AS -- Looking for
>>> feedback, how to generalize to GMPLS -- Adrian - need to apply to
>>> GMPLS if you want the draft to be in this group. -- Zafar - SRLG
>>> issue - need to solve the scooping issue, applies in a number of
>>> places. -- Adrian - WG should look at a framework for diverse
>>> paths, including PCE. -- Zafar - needs more discussion to
>>> understand, and already work in MPLS WG on ABR protection. --
>>> Adrian - authors can continue draft, would also like for CCAMP to
>>>  evaluate if PCE is appropriate, or something else -- JP - should
>>> include the PCE mailing list on this. -- Adrian - need discussion
>>> on the ccamp list. 13. Requirements for multi-region - Kohei
>>> Shiomoto 
>>> <http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-requirem
>>> 
>>> 
>>> ents-00.txt> -- Region defined based on switching capability -
>>> note region is control plane, layer is data plane -- Addresses
>>> pre-provisioned FA, triggered FA and no FA cases.  Plain and 
>>> hybrid type nodes. -- Architecture has generated requirements and
>>> solutions drafts -- Virtual network topology, application example
>>>  -- Propose as WG document. -- Adrian - handling regions are in
>>> scope of CCAMP. -- Adrian - asks Dimitri to immediately present
>>> the extensions then we will take questions 
>>> <http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-extensio
>>> 
>>> 
>>> ns-00.txt> -- TE metric inheritance - how to inherit or map
>>> metrics -- How is recovery abstracted for an FA - e.g., end2end
>>> vs. span protected? -- Reconvergence of VNT -- Handling multiple
>>> switching and adaptation capabilities -- Zafar - is this a good
>>> idea from TE point of view - dynamic FA creation - need
>>> applicability statement - potential bandwidth segmentation issues
>>> - may lose aggregation that you would normally get at the
>>> boundary - could add oscillation.  If still considered a good
>>> idea, should it be triggered by signaling or some other
>>> mechanism?  Document needs to list concerns. -- Arthi - some
>>> parts of requirements still not clear - what is needed outside of
>>> the LSP hierarchy draft?  Need to clarify what is missing from 
>>> the existing, and reference where it's covered by existing
>>> documents. Don't want to reinvent terminology.  Regarding virtual
>>> FA setup can be pre-provisioned or on demand - hierarchy draft
>>> already says this, should not be in the requirements document but
>>> only in the solutions document. Regarding protection - more work
>>> needs to be done in the requirements. -- Igor - region, layer,
>>> hierarchy level are treated interchangeably in the draft,
>>> confusing.  Regarding stitching, this is a very general
>>> capability and should be in LSP hierarchy instead. Kireeti -
>>> thinks this should have a separate document. -- Adrian - more
>>> clarification would be good on layer/region -- Jonathan Sadler -
>>> good stuff in general, agree with the goal. Concern is that IETF
>>> framework is not well aligned to ITU concept of layered network 
>>> (G.805).  It would be good to take into account the ITU
>>> framework.  Work on extensions is premature at this time. --
>>> Deborah Brungard - authors intended to handle multiple layers as
>>> in ITU (e.g. G.805) - limited to single domain for now, should be
>>> addressed to GMPLS RFCs. Not intended to discuss data plane
>>> concepts. Request for more specific comments.
>>> 
>>> 14. MPLS-to-GMPLS Migration - Kohei Shiomoto 
>>> <http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-0
>>> 
>>> 
>>> 4.txt> -- Evolution from legacy MPLS to GMPLS - -- Differences:
>>> architecture (C/D separation, bidirectionality, P&R); routing
>>> (opaque LSA); signaling (new objects, messages) -- Propose WG
>>> document -- Kireeti - question on whether this is in scope -
>>> address on charter -- Zafar - multi-layer comments also apply
>>> here. -- Richard Rabbat - supports the work, suggests looking at
>>> odd numbers rather than even. -- Ping Pan - how does this differ
>>> from the overlay model? -- Kireeti - different, take this to the
>>> list. 15. L1 VPN - Tomonori Takeda (10 Min) 
>>> <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt>
>>>  
>>> <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt
>>> 
>>> 
>>> 
>>> 
>>> <http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05
>>> 
>>> 
>>> .txt> 
>>> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt>
>>>  -- Mailing list - www1.ietf.org/mailman/listinfo/l1vpn -- Two
>>> drafts applicable, ouldbrahim and overlay - guidelines for 
>>> enhancement, deployment scenaros - added terminology refinement,
>>> security considerations, service models -- Further comments
>>> solicited, planning further liaison to SG13. -- Applicability
>>> draft examines existing GMPLS protocols for L1 VPN services. Has
>>> added Deborah as co-author. -- Concept - set up FA LSP between
>>> PEs, use stitching to connect this to CEs. -- Propose to adopt as
>>> CCAMP charter item. -- Kireeti - supports applicability draft.
>>> Liaison with ITU is very important - we need to be responsive.
>>> We will discuss this item as part of the extension of the CCAMP
>>> charter 16. Signaling for L2 LSPs - Dimitri Papadimitriou (10
>>> minutes) 
>>> <http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-ls
>>> 
>>> 
>>> p-03.txt> -- ATM, FR, ETH, etc.  Defines label request
>>> processing, label semantics, added security section. -- Security
>>> - threats analysis, attacks on the data plane, L2 LSP signaling, 
>>> attacks on control plane -- Ask for WG draft, no plan to respin 
>>> -- Dave Allan - Question on Ethernet VLAN tag swapping - not
>>> defined in IEEE. -- Dimitri- intended to cover GMPLS scope, not
>>> data plane.  Should not assume tag is per port unique. -- Don
>>> Fedyk - is this P2P? -- Dimitri - Yes (as starting point). --
>>> Kireeti - ok, we have a fair consensus, so I would say it's a
>>> rough consensus point. We will take this to the list, Dave and
>>> Dimitri to work out VLAN issue. -- Note that an MPLS group draft
>>> on L2 has come up 17. Mesh Carrier Survey - Richard Rabbat (5
>>> min) 
>>> <http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-01.tx
>>> 
>>> 
>>> t> -- Initially 7 carriers polled, open to others -- Also surveys
>>> GMPLS control plane deployment -- 1 has deployed, 3 within 2-3
>>> years, 3 with no current plans -- Concerns with stability,
>>> signaling storms -- Asking for feedback, new carrier input --
>>> Richard - review slides, recommend for CCAMP WG to begin work on
>>> shared mesh restoration performance 18. Milestone and Charter
>>> discussion - Kireeti -- Current activities winding down, esp.
>>> P&R, ASON -- Others underway, esp. multi-domain -- New:
>>> migration, VPNs, control plane resilience, addressing, 
>>> implementation experience, GTTP (?) -- Migration - GMPLS
>>> supersets MPLS, but some objects are different - label request, 
>>> label, upstream label - Need BCP on smooth migration, what issues
>>> may occur -- L1 VPN - Should IETF do this?  Should it be in
>>> CCAMP?  Tied to UNI and Interdomain signaling -- Control plane
>>> resilience - includes graceful restart but also more --
>>> Addressing - transport networks use different kinds of addresses
>>> - need decoder ring for mapping transport network address types
>>> to IP addresses - Kireeti considers this useful -- Interop
>>> results - note that addressing pops up there as well.  BCPs would
>>>  be helpful. -- Send out request for new work items, replies due
>>> Friday 11/19. -- Send out checks for consensus on each item,
>>> replies due Friday 12/3 -- Send resulting list to A-Ds, trimmed
>>> if necessary, add appropriate milestones -- Consensus is a
>>> requirement but not a guarantee. -- Lou - how about dropping
>>> something from the existing charter - -- Kireeti - maybe GTTP -
>>> Lou - should note on the list also things that may be dropped if
>>> no support. -- Alex - about L1 VPNs - is this research work, or
>>> practical?  Need at least one implementation - is anyone
>>> implementing this within a year or two? -- Dimitri - Solutions
>>> exist provided by vendors today, but no common framework.
>>> Timeframe for implementation is 18-24 months. -- Alex reminds the
>>> group of the need for running code. -- Adrian - what about
>>> informational draft on how to use existing functions to do the
>>> service?  Is there any interest from the research groups or the 
>>> real carrier deployment groups? -- Tomonori Takeda - NTT has
>>> interest, but not sure of protocols. Timeframe - cannot say.
>>> Testing is done. -- Yakov Rekhter- vendors cannot disclose future
>>> product plans... -- Deborah Brungard - carriers also cannot
>>> disclose plans, will see interest by number of co-authors. --
>>> Kireeti - have had carriers ask for this technology.  We don't
>>> have all the pieces, but have implemented many of them, and as a
>>> vendor would like to see a solution on how to do. Answer to Alex
>>> is yes. -- Richard Rabbat - could add this to his survey. --
>>> Kireeti supports this. MEETING IS ADJOURNED.
>>> 
>>> 
>>> .
>>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> .
> 

Delivery-date: Wed, 08 Dec 2004 12:25:55 +0000
Date: Wed, 08 Dec 2004 18:00:14 +0530
From: Harish M <[email-masked]>
Subject: FW: LMP Related Questions - 2
To: [email-masked], [email-masked]
Cc: [email-masked]
Reply-to: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_63UqUQb4TTmGRdYI5uLlnw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Thanks Richard, for correcting the last point.

-----Original Message-----
From: Bradford, Richard [mailto:[email-masked]]
Sent: Wednesday, December 08, 2004 5:40 PM
To: [email-masked]
Subject: RE: LMP Related Questions - 2

At 03:49 PM 12/8/2004 +0530, you wrote:

  Hi,

  A node can send BeginVerify message (if Link Connectivity Verification
procedure is supported) before starting Link Property Correlation Procedure.
  Remote node if it does not support Link Connectivity Verification
procedure, it shall send BeginVerifyNack with ERROR_CODE: 0x01 (Procedure
Not supported).
Agreed.

   Link Connectivity Verification procedure can be used for Learning
(automatic discovery) of LinkID (of remote node) & have the mapping of
InterfaceIDs with itself & remote node.
Agreed,

  If this procedure is not used, then adminstrator should configure mapping
of LinkID & InterfaceIDs with neighbor node before triggering "Link Property
Correlation"
Agreed.

  And also, in Link Connectivity Verification procedure, as the LinkID is
optional parameter in BeginVerifyAck, if the initiatior does not receive
this, then administrator should configure the mapping of LinkIDs (Local &
Remote Link ID)
This doesn't seem entirely accurate. The reason that the LinkID is not
required in the BeginVerifyAck is that it may not yet have been discovered.
If the mapping is not configured, then the mapping will be discovered upon
receipt of a Test message, which occurs later in the procedure than the
BeginVerifyAck. In this case, the initiator learns the mapping from the
TestStatusSuccess message.
So, it's only necessary to configure the mapping of LinkIDs if Link
Connectivity Verification fails and is not dependent on the contents of the
BeginVerifyAck.

Hope this helps,
   Rich

  Regards,
  Harish

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]]On
Behalf Of Kim Young Hwa
    Sent: Wednesday, December 08, 2004 1:59 PM
    To: [email-masked]
    Subject: LMP Related Questions - 2

    Hi, ccampers

    Because some give me different responses, but increasingly I'm in a
mess.
    Then, I've some questions as follows:

    (1) When receiving BeginVerify message, the node will first check if
"link verification supported" flag is set. However, this flag is set in a
TE-Link object of LinkSummary message. Without the flag set, the remote node
must send BeginVerifyNack message. Why do we send "link connectivity
verification" messages before "link property correlation" messages?

    (2) BeginVerify can contain Local-Link-ID without Remote-Link-ID.
Without link property correlation, the remote node has no mapping between
two Link-IDs. How can the remote node identify which TE links to be
verified?

    Thanks,

    Young.

--Boundary_(ID_63UqUQb4TTmGRdYI5uLlnw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!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.1479" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=967002812-08122004>Thanks 
Richard, for correcting the last point.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Bradford, Richard 
[mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, December 08, 2004 5:40 
PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> RE: LMP Related Questions 
- 2<BR><BR></FONT></DIV><FONT size=3>At 03:49 PM 12/8/2004 +0530, you 
wrote:<BR></FONT>
<BLOCKQUOTE cite="" type="cite"><FONT face=arial color=#0000ff 
  size=2>Hi,</FONT><FONT size=3><BR>&nbsp;<BR></FONT><FONT face=arial 
  color=#0000ff size=2>A node can send BeginVerify message (if Link Connectivity 
  Verification procedure is supported) before starting Link Property Correlation 
  Procedure.</FONT><FONT size=3><BR></FONT><FONT face=arial color=#0000ff 
  size=2>Remote node if it does not support Link Connectivity Verification 
  procedure, it shall send BeginVerifyNack with ERROR_CODE: 0x01 (Procedure Not 
  supported).</FONT></BLOCKQUOTE>Agreed.<BR><BR>
<BLOCKQUOTE cite="" type="cite"><FONT size=3>&nbsp;</FONT><FONT face=arial 
  color=#0000ff size=2>Link Connectivity Verification procedure can be used for 
  Learning (automatic discovery) of LinkID (of remote node) &amp; have the 
  mapping of InterfaceIDs with itself &amp; remote 
node.</FONT></BLOCKQUOTE>Agreed,<BR><BR>
<BLOCKQUOTE cite="" type="cite"><FONT face=arial color=#0000ff size=2>If this 
  procedure is not used, then adminstrator should configure mapping of LinkID 
  &amp; InterfaceIDs with neighbor node before triggering "Link Property 
  Correlation"</FONT></BLOCKQUOTE>Agreed.<BR><BR>
<BLOCKQUOTE cite="" type="cite"><FONT face=arial color=#0000ff size=2>And 
  also, in Link Connectivity Verification procedure, as the LinkID is optional 
  parameter in BeginVerifyAck, if the initiatior does not receive this, then 
  administrator should configure the mapping of LinkIDs (Local &amp; Remote Link 
  ID)</FONT></BLOCKQUOTE>This doesn't seem entirely accurate. The reason that the 
LinkID is not required in the BeginVerifyAck is that it may not yet have been 
discovered. If the mapping is not configured, then the mapping will be 
discovered upon receipt of a Test message, which occurs later in the procedure 
than the BeginVerifyAck. In this case, the initiator learns the mapping from the 
TestStatusSuccess message.<BR>So, it's only necessary to configure the mapping 
of LinkIDs if Link Connectivity Verification fails and is not dependent on the 
contents of the BeginVerifyAck.<BR><BR><FONT size=3>Hope this 
helps,<BR>&nbsp;&nbsp; Rich<BR><BR>
<BLOCKQUOTE cite="" type="cite"><BR></FONT><FONT face=arial color=#0000ff 
  size=2>Regards,</FONT><FONT size=3><BR></FONT><FONT face=arial color=#0000ff 
  size=2>Harish</FONT><FONT size=3><BR>&nbsp;</FONT> 
  <DL><FONT face=tahoma size=2>
    <DD>-----Original Message----- 
    <DD>From:</B> [email-masked] [<A 
    href="mailto:[email-masked]%5DOn" 
    eudora="autourl">mailto:[email-masked]]</A><A 
    href="mailto:[email-masked]%5DOn" eudora="autourl">On</A> Behalf 
    Of </B>Kim Young Hwa 
    <DD>Sent:</B> Wednesday, December 08, 2004 1:59 PM 
    <DD>To:</B> [email-masked] 
    <DD>Subject:</B> LMP Related Questions - 2<BR><BR></FONT><FONT size=3>
    <DD>Hi, ccampers 
    <DD> 
    <DD>Because some give me different responses, but increasingly I'm in a 
    mess. 
    <DD>Then, I've some questions as follows: 
    <DD> 
    <DD>(1) When receiving BeginVerify message, the node will first check if 
    "link verification supported" flag is set. However, this flag is set in a 
    TE-Link object of LinkSummary message. Without the flag set, the remote node 
    must send BeginVerifyNack message. Why do we send "link connectivity 
    verification" messages before "link property correlation" messages? 
    <DD> 
    <DD>(2) BeginVerify can contain Local-Link-ID without Remote-Link-ID. 
    Without link property correlation, the remote node has no mapping between 
    two Link-IDs. How can the remote node identify which TE links to be 
    verified? 
    <DD> 
    <DD>Thanks, 
    <DD> 
    <DD>Young. 
    <DD> 
    <DD></FONT> </DD></DL></BLOCKQUOTE><BR><FONT 
face="Courier, Courier"></FONT></BODY></HTML>

--Boundary_(ID_63UqUQb4TTmGRdYI5uLlnw)--

Delivery-date: Wed, 08 Dec 2004 10:14:00 +0000
Date: Wed, 08 Dec 2004 15:49:18 +0530
From: Harish M <[email-masked]>
Subject: RE: LMP Related Questions - 2
To: Kim Young Hwa <[email-masked]>, [email-masked]
Reply-to: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_1UaM5Db0gQ2mudilLq8CWw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi,

A node can send BeginVerify message (if Link Connectivity Verification
procedure is supported) before starting Link Property Correlation Procedure.
Remote node if it does not support Link Connectivity Verification procedure,
it shall send BeginVerifyNack with ERROR_CODE: 0x01 (Procedure Not
supported).

Link Connectivity Verification procedure can be used for Learning (automatic
discovery) of LinkID (of remote node) & have the mapping of InterfaceIDs
with itself & remote node.

If this procedure is not used, then adminstrator should configure mapping of
LinkID & InterfaceIDs with neighbor node before triggering "Link Property
Correlation"

And also, in Link Connectivity Verification procedure, as the LinkID is
optional parameter in BeginVerifyAck, if the initiatior does not receive
this, then administrator should configure the mapping of LinkIDs (Local &
Remote Link ID)

Regards,
Harish

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of Kim Young Hwa
  Sent: Wednesday, December 08, 2004 1:59 PM
  To: [email-masked]
  Subject: LMP Related Questions - 2

  Hi, ccampers

  Because some give me different responses, but increasingly I'm in a mess.
  Then, I've some questions as follows:

  (1) When receiving BeginVerify message, the node will first check if "link
verification supported" flag is set. However, this flag is set in a TE-Link
object of LinkSummary message. Without the flag set, the remote node must
send BeginVerifyNack message. Why do we send "link connectivity
verification" messages before "link property correlation" messages?

  (2) BeginVerify can contain Local-Link-ID without Remote-Link-ID. Without
link property correlation, the remote node has no mapping between two
Link-IDs. How can the remote node identify which TE links to be verified?

  Thanks,

  Young.

--Boundary_(ID_1UaM5Db0gQ2mudilLq8CWw)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1479" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=733030610-08122004></SPAN></FONT><FONT face=Arial color=#0000ff 
size=2><SPAN class=733030610-08122004>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=733030610-08122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=733030610-08122004>A node 
can send BeginVerify message (if Link Connectivity Verification procedure is 
supported) before starting Link Property Correlation 
Procedure.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=733030610-08122004>Remote 
node if it does not&nbsp;support Link Connectivity Verification procedure, it 
shall send BeginVerifyNack with ERROR_CODE: 0x01 (Procedure Not 
supported).</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=733030610-08122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=733030610-08122004>Link 
Connectivity Verification procedure can be used for Learning (automatic 
discovery) of&nbsp;LinkID (of remote node) &amp; have the mapping of 
InterfaceIDs with itself &amp; remote node.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=733030610-08122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=733030610-08122004>If 
this procedure is not used, then adminstrator should configure mapping of LinkID 
&amp; InterfaceIDs with neighbor node before triggering "Link Property 
Correlation"</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=733030610-08122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=733030610-08122004>And 
also, in Link Connectivity Verification procedure, as the LinkID is optional 
parameter in BeginVerifyAck, if the initiatior does not receive this, then 
administrator should configure the mapping of LinkIDs (Local &amp; Remote Link 
ID)</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=733030610-08122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=733030610-08122004>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=733030610-08122004>Harish</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=733030610-08122004></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> [email-masked] 
  [mailto:[email-masked]]<B>On Behalf Of </B>Kim Young 
  Hwa<BR><B>Sent:</B> Wednesday, December 08, 2004 1:59 PM<BR><B>To:</B> 
  [email-masked]<BR><B>Subject:</B> LMP Related Questions - 
  2<BR><BR></FONT></DIV>
  <DIV id=msgbody style="FONT-SIZE: 10pt; FONT-FAMILY: System">
  <DIV>Hi, ccampers</DIV>
  <DIV><FONT face=Arial color=#0000ff></FONT>&nbsp;</DIV>
  <DIV>Because some give&nbsp;me&nbsp;different responses, but&nbsp;increasingly 
  I'm in a mess.</DIV>
  <DIV>Then, I've some questions as follows:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>(1) When receiving BeginVerify message, the node will first check if 
  "link verification supported" flag is set. However, this flag is set in a 
  TE-Link object of LinkSummary message. Without the flag set, the remote node 
  must send BeginVerifyNack message. Why do we send "link connectivity 
  verification" messages before "link property correlation" messages?</DIV>
  <DIV><FONT face=Arial color=#0000ff></FONT>&nbsp;</DIV>
  <DIV>(2) BeginVerify can contain Local-Link-ID without Remote-Link-ID. Without 
  link property correlation, the remote node has no mapping between two 
  Link-IDs. How can the remote node identify which TE links to be 
verified?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Thanks,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Young.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff></FONT>&nbsp;</DIV></DIV><IMG 
  style="DISPLAY: none" height=0 
  src="http://umail.etri.re.kr/External_ReadCheck.aspx?email=[email-masked]&amp;name=ccamp%40ops.ietf.org&amp;fromemail=[email-masked]&amp;messageid=[email-masked]%3E" 
  width=0 NOSEND="1"></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_1UaM5Db0gQ2mudilLq8CWw)--

Delivery-date: Wed, 08 Dec 2004 08:30:06 +0000
Reply-To: "Kim Young Hwa" <[email-masked]>
From: "Kim Young Hwa" <[email-masked]>
To: <[email-masked]>
Cc: 
Bcc: 
Subject: LMP Related Questions - 2
Date: Wed, 8 Dec 2004 17:29:12 +0900
Comment: =?ISO-8859-1?B?x9GxucD8wNrF673Fv6yxuL/4LCCxpMD8tN64wcGmvu7GwCwgtOO05w==?=
content-class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_A6C3_01C4DD4B.6E8A2750
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

------=_NextPart_000_A6C3_01C4DD4B.6E8A2750
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: System">
<DIV>Hi, ccampers</DIV>
<DIV>&nbsp;</DIV>
<DIV>Because some give&nbsp;me&nbsp;different responses, =
but&nbsp;increasingly I'm in a mess.</DIV>
<DIV>Then, I've some questions as follows:</DIV>
<DIV>&nbsp;</DIV>
<DIV>(1) When receiving BeginVerify message, the node will first check =
if "link verification supported" flag is set. However, this flag is set =
in a TE-Link object of LinkSummary message. Without the flag set, the =
remote node must send BeginVerifyNack message. Why do we send "link =
connectivity verification" messages before "link property correlation" =
messages?</DIV>
<DIV>&nbsp;</DIV>
<DIV>(2) BeginVerify can contain Local-Link-ID without Remote-Link-ID. =
Without link property correlation, the remote node has no mapping =
between two Link-IDs. How can the remote node identify which TE links to =
be verified?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Young.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></DIV><img style=3D"display:none" width=3D0 height=3D0 =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3Dccamp@ops.=
ietf.org&name=3Dccamp%40ops.ietf.org&fromemail=[email-masked]&messag=
eid=[email-masked]%3E">
------=_NextPart_000_A6C3_01C4DD4B.6E8A2750--

Delivery-date: Wed, 08 Dec 2004 04:27:47 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "JP Vasseur" <[email-masked]>
Subject: RE: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Tue, 7 Dec 2004 20:26:25 -0800

Adrian,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 6:43 AM
> To: [email-masked]
> Cc: Kireeti Kompella; Arthi Ayyangar; JP Vasseur
> Subject: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
> 
> 
> Hi,
> 
> As documented in the minutes from Washington DC, we discussed 
> whether to make this draft
> an WG document.
> 
> A show of hands in the room indicated that there were no 
> objections but that not many had
> read the draft. So, two questions for the list...
> 
> Should this become a WG draft?

Yes.

> Is it fine to include stitching in this draft, or does the wider 
> applicability of
> stitching mean that it should be pulled out into a separate draft?

For the moment, perhaps keeping it in the same document would be fine.
As it evolves, we may look again at whether a separate document is
needed.

-Vishal

Delivery-date: Wed, 08 Dec 2004 02:31:53 +0000
From: "Zafar Ali" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, "'Arthi Ayyangar'" <[email-masked]>, "'JP Vasseur'" <[email-masked]>
Subject: RE: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Tue, 7 Dec 2004 21:30:49 -0500

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Tuesday, December 07, 2004 9:43 AM
>To: [email-masked]
>Cc: Kireeti Kompella; Arthi Ayyangar; JP Vasseur
>Subject: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
>
>
>Hi,
>
>As documented in the minutes from Washington DC, we discussed 
>whether to make this draft an WG document.
>
>A show of hands in the room indicated that there were no 
>objections but that not many had read the draft. So, two 
>questions for the list...
>
>Should this become a WG draft?

Yes, 

>Is it fine to include stitching in this draft, or does the 
>wider applicability of stitching mean that it should be pulled 
>out into a separate draft?

It's already integrated nicely in the draft, moving it to a different ID is
IMO just an overhead. 

>Thanks,
>Adrian

Delivery-date: Wed, 08 Dec 2004 00:34:31 +0000
Cc: <[email-masked]>
From: JP Vasseur <[email-masked]>
Subject: Re: Starting a discussion on graceful shutdown
Date: Tue, 7 Dec 2004 19:32:50 -0500
To: "Adrian Farrel" <[email-masked]>

Hi Adrian,

On Dec 7, 2004, at 10:38 AM, Adrian Farrel wrote:

> Hi,
>
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful- 
> shutdown-00.txt was
> discussed at the meeting in Washington DC, and one of the questions  
> raised was whether or
> not we already had (multiple!) mechanisms capable of performing the  
> function described in
> the draft.
>
> Kireeti quite rightly suggested that we step back and make sure we  
> understand the
> requirements. This is my take on those requirements and I would  
> appreciate it if the
> authors of the draft joined in and other people on the list commented.
>
> We wish to manage a link that needs to be taken out of service in some  
> way (data plane
> and/or control plane will be disrupted). The link concerned has active  
> LSPs and we wish to
> offer upstream LSRs (in particular the ingress) the opportunity to use  
> make-before-break
> to re-route the LSPs.
>

This is indeed the goal. Note that this is just one out of many other  
cases for which a graceful shutdown solution is desirable, the action  
(reroute of existing LSPs, avoidance of the network element for *new*  
LSPs, reoptimization, ...) may of course vary depending on the event.

> In order to achieve this, we need to communicate to the upstream nodes.

Right. Note that this might either be the impacted head-end LSRs *or*  
directly upstream neighbors *or* both depending on the requesting  
actions.

>  Should we choose
> signaling or routing? Are there benefits that mean we should use both,  
> or should we limit
> to just one?
>

Both have pros and cons and are needed ... Routing is, in many cases,  
more efficient in term of sig overhead *but* limited to single area ...  
thus signaling is also required. The use of one of the other should IMO  
be specific of the graceful shutdown triggers and expected actions.

> There is another aspect to be considered. Should we also attempt to  
> protect new path
> computations from selecting the link that will be taken out of service?
>

Again this highly depends on the root cause ... Consider:
1) Link to be shutdown: all LSP (old and new) should be rerouted
2) Memory shortage on some equipment: only *new* LSP should avoid the  
equipment in question
3)  ....

> How should we consider the case of a node (data plane and/or control  
> plane) being taken
> out of service? Is a node simply a collection of links?
>

Good question ... depends again on the data/control plane issue.

> If a component link of a bundle is being taken out of service (and  
> assuming other
> component links are available) is this just an issue for the adjacent  
> nodes or does it
> need to be communicated more widely? If the downstream node decides to  
> take the component
> link out of service, how does it inform the upstream node?
>

This should I think be configurable with the possible to offer a  
notification mechanism.

> Does it matter whether it is the control plane or the data plane that  
> will be taken out of
> service?
>
> Opinions please.
>
> I would like to see these issues and their answers captured clearly in  
> a requirements
> section of any draft. Would the authors of  
> draft-ali-ccamp-mpls-graceful-shutdown-00.txt
> be willing to take that on even though the end result might be that  
> procedures other than
> those they suggest will be selected?

Sure, we will be happy to write such a section.

Cheers.

JP.

> Adrian

Delivery-date: Tue, 07 Dec 2004 20:38:52 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "JP Vasseur" <[email-masked]>
From: [email-masked]
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Tue, 7 Dec 2004 21:35:42 +0100

adrian:

> Hi,
>
> As documented in the minutes from Washington DC, we discussed whether to
> make this draft an WG document.
>
> A show of hands in the room indicated that there were no objections but
> that not many had read the draft. So, two questions for the list...
>
> Should this become a WG draft?

yes

> Is it fine to include stitching in this draft, or does the wider
> applicability of stitching mean that it should be pulled out into a
> separate draft?

preferable to have a separate document (and details the application of
stitching to multi-domain in this document)

> Thanks,
> Adrian

Delivery-date: Tue, 07 Dec 2004 19:13:44 +0000
From: John Drake <[email-masked]>
To: Adrian Farrel <[email-masked]>, [email-masked]
Cc: Kireeti Kompella <[email-masked]>, Arthi Ayyangar <[email-masked]>, JP Vasseur <[email-masked]>
Subject: RE: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status ?
Date: Tue, 7 Dec 2004 11:12:25 -0800 

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, December 07, 2004 6:43 AM
> To: [email-masked]
> Cc: Kireeti Kompella; Arthi Ayyangar; JP Vasseur
> Subject: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
> 
> Hi,
> 
> As documented in the minutes from Washington DC, we discussed whether to
> make this draft
> an WG document.
> 
> A show of hands in the room indicated that there were no objections but
> that not many had
> read the draft. So, two questions for the list...
> 
> Should this become a WG draft?

Yes

> Is it fine to include stitching in this draft, or does the wider
> applicability of
> stitching mean that it should be pulled out into a separate draft?

My preference is for a separate draft

> Thanks,
> Adrian

Delivery-date: Tue, 07 Dec 2004 17:28:01 +0000
Date: Tue, 07 Dec 2004 18:26:31 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel OND
To: Adrian Farrel <[email-masked]>
CC: [email-masked], Kireeti Kompella <[email-masked]>, Arthi Ayyangar <[email-masked]>, JP Vasseur <[email-masked]>
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?

Adrian,

it should become a WG document and stitching should be included unless 
further work on the subject would show that a separate draft would add 
more clarity.

Regards

Gert

Adrian Farrel wrote:

>Hi,
>
>As documented in the minutes from Washington DC, we discussed whether to make this draft
>an WG document.
>
>A show of hands in the room indicated that there were no objections but that not many had
>read the draft. So, two questions for the list...
>
>Should this become a WG draft?
>Is it fine to include stitching in this draft, or does the wider applicability of
>stitching mean that it should be pulled out into a separate draft?
>
>Thanks,
>Adrian
>
>
>  
>

Delivery-date: Tue, 07 Dec 2004 16:37:34 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, "Fabio Ricciato" <[email-masked]>, "Ugo Monaco" <[email-masked]>, "Alessio D'Achille" <[email-masked]>, "Daniele Ali" <[email-masked]>, "Marco Listanti" <[email-masked]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 08:36:39 -0800

Adrian,

Great, thanks for the clarification. I do agree that it
seems a terminology issue. In that case, what we mean is
inter-domain.

I think we picked "inter-region" because somewhere along
the line (around Seoul, I think) some discussions occurred
at the IETF and the ML, where it appeared that one should use "inter-region"
to cover both inter-area and inter-AS.

I guess if "inter-domain" is the preferred terminology, we are
happy to do that, since that is what we have meant all along.

Thanks,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 8:06 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>
>
> Hi,
>
> > Thanks for the observations. I have several things I'd want
> > to discuss with respect to your note below, and will take
> > them one-by-one in different emails to break the discussion
> > down to small, manageable emails that folks can read easily.
>
> Fair enough.
>
> > > > A number of the diverse routing/protection etc. drafts are looking
> > > > at different problems (e.g. draft-decnodder is looking at inter-area
> > > > link protection, while draft-dachille is looking at diverse
> inter-region
> > > > path setup), so it is not clear how a single set of
> protocol extensions
> > > > would serve?
> > >
> > > Do you really mean inter-region? It seems to me that inter-region
> > > is really covered by the
> > > region transit work covered in the two MRN drafts. It is
> > > relatively unlikely that an LSP
> > > will start in one region and end in another - the encapsulation
> > > and adaptation rules to
> > > achieve that don't look nice. But, perhaps someone has a
> > > requirement to deploy this?
> >
> > Wait a minute... there seems a fundamental contradiction above.
> >
> > So, first things first ...
> > If what you say is true (that LSPs are unlikely to start in one
> > region and end in another), why are all of us in
> > CCAMP working on inter-region LSP issues?
>
> I think this is just a terminology issue.
> "Region" got stolen by the hierarchy draft.
>    The information carried in the Interface Switching Capabilities is
>    used to construct LSP regions, and determine regions' boundaries as
>    follows.
> draft-ietf-mpls-lsp-hierarchy-08.txt section 7.
>
> This is confirmed in draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>
> Thus, when trying to consolidate the work within CCAMP I picked
> "domain" which seemed to
> be largely unused around GMPLS. In
> draft-ietf-ccamp-inter-domain-framework-00.txt we
> have...
>    For the purposes of this document, a domain is considered to be any
>    collection of network elements within a common sphere of address
>    management or path computational responsibility. Examples of such
>    domains include IGP areas and Autonomous Systems.
>
> As an aside, nested domains are currently out of scope of
> draft-ietf-ccamp-inter-domain-framework-00.txt because they are
> simply treated using FAs.
> There is, therefore a clear overlap between nested domains and regions.
>
> A
>
>

Delivery-date: Tue, 07 Dec 2004 16:31:57 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 08:31:01 -0800

Adrian,

A few last comments on your note ...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: [email-masked]; Ugo Monaco
> Cc: [email-masked]; Alessio D'Achille; Daniele Alì; Marco Listanti
> Subject: Re: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>

<snip>

> > So, I think we need to be a bit careful when evaluating the extent of
> > discussion.
> >
> > -- There was also significant discussion of this subject in San Diego --
> > cf. the CCAMP WG meeting minutes again.
> >
> > Since it was then clearly stated that CCAMP WG would focus on
> the "simple"
> > TE aspects first, with diverse routing deemed an "advanced" subject, so
> > naturally for a short while there wasn't much that could be done in
> > this area, as people began focussing on the "simple" aspects.
>
> Yes. That's good, isn't it?
> And now we are ready to move on to the diverse path issues and so
> it is appropriate to
> open up the discussions.

Sure, I agree that it is good to discuss the subject again now.

(Although, the conclusion at San Diego, did put a bit of a damper
on work in this area, at least in so far as discussion on CCAMP goes.
Of course, that did not actually stop progress on the work, as is
evident from the additional simulation results presented during
the presentation of draft-dachille in D.C. last month.)

<snip>

> > >As the working group moves on to specify the problem space that we
> > >are trying to resolve, I hope that we will see more debate about the
> > >possible solutions with a view to arriving at a single set of protocol
> > >extensions.
> >
> > I'm not clear on what is meant by your statement above.
>
> I mean that we should aim to have a single protocol solution if
> it can be applied to a
> wide variety of scenarios, rather than a set of different
> protocol extensions that are
> applicable to specific subsets of the problem. Perhaps, in answer
> to your point below, it
> is not clear why a single set of protocol extensions could not be
> found to serve in both
> (all) cases. If that means that neither of the existing drafts is
> sufficient, that sits
> well with me.

I agree that the fewer enhancements to a protocol we make the
better it is. However, we have to also keep in mind that some
of the drafts (in particular, draft-dachille and draft-decnodder)
are solving somewhat different problems, so it may be infeasible to
find a single extension to serve both cases.

That is, the single extension may end-up being more complicated than
two different extensions (which might be simple and easily decomposable
based on the specific application each addresses).

I don't think having different extensions/enhancements is by
itself a bad thing,
as long as we are not trying to achieve the exact same thing by two
or more means.

The different extensions may not all be used at the
same time, and may serve distinct functions, so they don't overload the
signalling protocol.

-Vishal

Delivery-date: Tue, 07 Dec 2004 16:31:49 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 08:30:58 -0800

Adrian,

Continuing on ...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: [email-masked]; Ugo Monaco
> Cc: [email-masked]; Alessio D'Achille; Daniele Alì; Marco Listanti
> Subject: Re: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt

<snip>

> > > I also have the impression that the interest in
> > >implementation is not (yet) very strong.
> >
> > I believe implementation interest will pick up once CCAMP formally
> > states an intent to look at this problem (as has already happened by the
> > structuring of the WG meeting at D.C.).
>
> What I mean is that I do not hear from providers (or vendors)
> that they are currently
> trying to solve this problem in deployed networks. At the moment,
> they are still
> struggling with simple, unprotected inter-AS TE.

I'm not sure why you say that. As far as I can see, both Cisco
and Juniper have been working on various versions of solutions for
the inter-region (inter-domain, which ever is more appropriate)
space for quite a while.

And, 7-odd providers have, after quite some debate, distilled the
requirements for inter-area and inter-AS TE that have come from the
TE WG, so I assume they are interested in having those requirements
be met.

I agree that providers and vendors may currently be focusing on
simple, inter-AS (inter-domain) TE, but the fact that we have
requirements for diverse path routing articulated in the inter-area
and inter-AS requirements documents suggests that this is a problem
they would like to have solutions for.

-Vishal

Delivery-date: Tue, 07 Dec 2004 16:13:20 +0000
content-class: urn:content-classes:message
Subject: RE: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Tue, 7 Dec 2004 10:13:09 -0600
From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "JP Vasseur" <[email-masked]>

> Should this become a WG draft?

Yes

> Is it fine to include stitching in this draft, or does
> the wider applicability of stitching mean that it should=20
> be pulled out into a separate draft?

I'm OK to leave it there -- it is already deeply embedded in the draft.

Jerry

Delivery-date: Tue, 07 Dec 2004 16:09:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 16:05:41 -0000

Hi,

> Thanks for the observations. I have several things I'd want
> to discuss with respect to your note below, and will take
> them one-by-one in different emails to break the discussion
> down to small, manageable emails that folks can read easily.

Fair enough.

> > > A number of the diverse routing/protection etc. drafts are looking
> > > at different problems (e.g. draft-decnodder is looking at inter-area
> > > link protection, while draft-dachille is looking at diverse inter-region
> > > path setup), so it is not clear how a single set of protocol extensions
> > > would serve?
> >
> > Do you really mean inter-region? It seems to me that inter-region
> > is really covered by the
> > region transit work covered in the two MRN drafts. It is
> > relatively unlikely that an LSP
> > will start in one region and end in another - the encapsulation
> > and adaptation rules to
> > achieve that don't look nice. But, perhaps someone has a
> > requirement to deploy this?
>
> Wait a minute... there seems a fundamental contradiction above.
>
> So, first things first ...
> If what you say is true (that LSPs are unlikely to start in one
> region and end in another), why are all of us in
> CCAMP working on inter-region LSP issues?

I think this is just a terminology issue.
"Region" got stolen by the hierarchy draft.
   The information carried in the Interface Switching Capabilities is
   used to construct LSP regions, and determine regions' boundaries as
   follows.
draft-ietf-mpls-lsp-hierarchy-08.txt section 7.

This is confirmed in draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

Thus, when trying to consolidate the work within CCAMP I picked "domain" which seemed to
be largely unused around GMPLS. In draft-ietf-ccamp-inter-domain-framework-00.txt we
have...
   For the purposes of this document, a domain is considered to be any
   collection of network elements within a common sphere of address
   management or path computational responsibility. Examples of such
   domains include IGP areas and Autonomous Systems.

As an aside, nested domains are currently out of scope of
draft-ietf-ccamp-inter-domain-framework-00.txt because they are simply treated using FAs.
There is, therefore a clear overlap between nested domains and regions.

A

Delivery-date: Tue, 07 Dec 2004 16:05:25 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 08:04:31 -0800

Hi Adrian,

A bit more discussion ...

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: [email-masked]; Ugo Monaco
> Cc: [email-masked]; Alessio D'Achille; Daniele Alì; Marco Listanti
> Subject: Re: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>

<snip>

> > Draft-decnodder by contrast has seen much less (perhaps 2-3
> emails), if any,
> > discussion, so clubbing the two drafts in the same category w.r.t. the
> > level of discussion doesn't seem appropriate.
> > (It has largely come from me and a couple others.)
>
> Yes. It is not as old as a draft, and has seen less debate.

Not to belabor the point or beat on draft-decnodder, but I think it's
important to keep the records straight.

draft-decnodder (in earlier versions) predates by _a year_ draft-dachille,
having
been first released in February 2003, whereas draft-dachille was
first released only in January 2004.

See ...

http://www.potaroo.net/ietf/all-ids/draft-decnodder-mpls-interas-protection-
00.txt

But, yes, it true that this draft has not seen any debate as such.
(I am not quite sure why though, as the subject is an important one, and I
did initiate debate on it in March 04.)

Delivery-date: Tue, 07 Dec 2004 15:57:00 +0000
Date: Tue, 7 Dec 2004 10:56:46 -0500 (EST)
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
From: [email-masked]
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked], "Kireeti Kompella" <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "JP Vasseur" <[email-masked]>

Hi,

I believe that stitching is a private case of FAs and as such has a
broader applicability than just for inter-domain TE LSPs, therefore, it
needs to go into a separate document.

Igor Bryskin

Hi,
>
> As documented in the minutes from Washington DC, we discussed whether to
> make this draft
> an WG document.
>
> A show of hands in the room indicated that there were no objections but
> that not many had
> read the draft. So, two questions for the list...
>
> Should this become a WG draft?
> Is it fine to include stitching in this draft, or does the wider
> applicability of
> stitching mean that it should be pulled out into a separate draft?
>
> Thanks,
> Adrian
>
>
>

Delivery-date: Tue, 07 Dec 2004 15:54:24 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 07:53:30 -0800

Adrian,

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, December 07, 2004 4:25 AM
> To: [email-masked]; Ugo Monaco
> Cc: [email-masked]; Alessio D'Achille; Daniele Alì; Marco Listanti;
> Tove Madsen
> Subject: Re: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>
>
>
>
> > And, I should add, that the only protocol "extension" that
> > draft-dachille requires is an ARO object, which is cloned
> > after the ERO object, and can simply be "flipped" to form
> > the ERO object of the second (diverse) path when setting
> > up that path.
> > (As was illustrated in the fig. on slide 3 of the D.C.
> > presentation.)
>
> We're in agreement.
> There is a protocol extension and consequent increase in signaling load.
> It is not a substantial increase.

I'm not sure why a protocol extension should lead necessarily to an increase
in signalling load?

Is the load you're talking about simply that an additional
ARO object needs to be carried during the setting up of the first
of the two LSPs? Or, do you mean something else?

Then again, if one is trying to set up two paths, clearly some
additional signaling will be required (beyond that required
for one path) in any approach.

The main benefit of the ARO approach is the fact that it achieves
this with minimal modifications to the signaling protocol and with
minimal overhead, and without requiring new protocols to be defined
or new uses of existing protocols to be defined.

-Vishal

Delivery-date: Tue, 07 Dec 2004 15:54:16 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 07:53:33 -0800

Adrian,

Thanks for the observations. I have several things I'd want
to discuss with respect to your note below, and will take
them one-by-one in different emails to break the discussion
down to small, manageable emails that folks can read easily.

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: [email-masked]; Ugo Monaco
> Cc: [email-masked]; Alessio D'Achille; Daniele Alì; Marco Listanti
> Subject: Re: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>
>

<snip>

> > A number of the diverse routing/protection etc. drafts are looking
> > at different problems (e.g. draft-decnodder is looking at inter-area
> > link protection, while draft-dachille is looking at diverse inter-region
> > path setup), so it is not clear how a single set of protocol extensions
> > would serve?
>
> Do you really mean inter-region? It seems to me that inter-region
> is really covered by the
> region transit work covered in the two MRN drafts. It is
> relatively unlikely that an LSP
> will start in one region and end in another - the encapsulation
> and adaptation rules to
> achieve that don't look nice. But, perhaps someone has a
> requirement to deploy this?

Wait a minute... there seems a fundamental contradiction above.

So, first things first ...
If what you say is true (that LSPs are unlikely to start in one
region and end in another), why are all of us in
CCAMP working on inter-region LSP issues?

Delivery-date: Tue, 07 Dec 2004 15:54:08 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 07:53:26 -0800

Adrian,

That draft-dachille directly addresses TE WG requirements
is a point that is the basis of the draft itself! And,
finds mention in the introduction of draft-dachille.

And, it has been raised in the extensive discussions on this
draft after Seoul.

I mentioned that the current minutes reflect this, since it
appeared a bit strange that the minutes mentioned that for
draft decnodder, while not stating that for draft-dachille.

It may leave a reader looking at the minutes (which I assume
is a lot of the people on the list) with the impression that draft-dachille
does not address TEWG requirements. In fact, quite the
contrary!

-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, December 07, 2004 3:39 AM
> To: [email-masked]; Ugo Monaco
> Cc: [email-masked]; Alessio D'Achille; Daniele Alì; Marco Listanti;
> Tove Madsen
> Subject: Re: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>
>
> Vishal,
>
> This is a good point that you should definitely be raising in the
> discussions about your
> draft.
>
> I can't however, update the minutes to reflect things you would
> have liked to have been
> said at the meeting.
>
> A
>
> > >  > -- Differs from 11, addresses requirements from TEWG draft
> > >
> > > We want stress that ARO addresses requirements from the TEWG draft too
> >
> > > OK. This is a punctuation error in the minutes.
> >
> > >"-- Differs from 11, addresses requirements from TEWG draft"
> >
> > >should read
> >
> > >"-- Differs from 11
> > > --Addresses requirements from TEWG draft"
> >
> > >We will update the minutes.
> >
> > I think it would be good for the minutes to then also note that
> >
http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-0
> 4.txt
>
> also directly address the requirements from the TE requirements
> draft, as below.
>
> > (draft-ietf-tewg-interas-mpls-te-req-09.txt), in particular is in
> > accordance with Section:
> >
> > 5.1.1. Inter-AS MPLS TE Operations and Interoperability
> > 5.1.5.  Re-optimization
> > 5.1.8. Scalability and Hierarchical LSP Support
> > 5.1.11. Extensibility
> > 6. Security Considerations
> >
> > This was also the basis on which we got some good feedback
> > from the service provider community in the extensive discussions
> > before, during, and after Seoul.
> > May be we need to better point out this issue in the next version of the
> > draft.

Delivery-date: Tue, 07 Dec 2004 15:54:01 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 07:53:37 -0800

Hi Adrian,

Continuing on the thread of my previous email, of discussing
some of the points raised below one-by-one ...

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: [email-masked]; Ugo Monaco
> Cc: [email-masked]; Alessio D'Achille; Daniele Alì; Marco Listanti
> Subject: Re: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>
>
> Vishal,
>
> > > > Finally the phrase "need further feedback" looks not clear,
> who needs
> > > > feedback? -the list or the authors ?-
> >
> > > Despite the fact that both drafts have been around for some while, the
> > > level of discussion on the ccamp list has been quite low.
> >
> > I think a few clarifications are rather crucial here:
> >
> > -- The diverse routing draft has, in fact, received significant
> discussion
> > and debate (from all of the people involved in the inter-area work --
> > vendors and providers), right during and after Seoul, from March-May 04
> > -- please see the CCAMP WG archives for about 60-70-odd emails on it.
> > (I'm not sure how one could classify this as "low".)
>
> You're right, there was some thorough debate on the detailed
> function as described in an
> earlier version of the draft, and you have done a lot to address
> those issues.
>
> What I am missing (but maybe the community doesn't care?) is a
> higher-level debate about
> the methodology to solve what might best be described as a hard
> problem. In other words,
> while it is fine to get into the details of how ARO works and to
> polish that solution, I
> have not seen the debate as to whether we want to adopt ARO.
>
> In order to pursue this, we are now in need of some effort to
> develop a framework for
> inter-domain diverse path computation.
>
> We're now trying to put some text together for this (if it is a
> small amount of text it
> will go into the existing framework draft - if it turns out to be
> a lot of text it will go
> into its own draft). I know that you, Vishal, have volunteered to
> get the ball rolling and
> when I have your text I will add my own (politically correct)
> spin before putting it out
> to the list for debate.

Sure, great. I know I've promised this, and we need to discuss
some of this to know just how much we should write.
I guess we'll talk off-line and come up with something that
nicely captures the essense of the diverse path computation
issue for the framework draft (or another one).

Delivery-date: Tue, 07 Dec 2004 15:45:40 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Starting a discussion on graceful shutdown
Date: Tue, 7 Dec 2004 15:38:55 -0000

Hi,

http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-00.txt was
discussed at the meeting in Washington DC, and one of the questions raised was whether or
not we already had (multiple!) mechanisms capable of performing the function described in
the draft.

Kireeti quite rightly suggested that we step back and make sure we understand the
requirements. This is my take on those requirements and I would appreciate it if the
authors of the draft joined in and other people on the list commented.

We wish to manage a link that needs to be taken out of service in some way (data plane
and/or control plane will be disrupted). The link concerned has active LSPs and we wish to
offer upstream LSRs (in particular the ingress) the opportunity to use make-before-break
to re-route the LSPs.

In order to achieve this, we need to communicate to the upstream nodes. Should we choose
signaling or routing? Are there benefits that mean we should use both, or should we limit
to just one?

There is another aspect to be considered. Should we also attempt to protect new path
computations from selecting the link that will be taken out of service?

How should we consider the case of a node (data plane and/or control plane) being taken
out of service? Is a node simply a collection of links?

If a component link of a bundle is being taken out of service (and assuming other
component links are available) is this just an issue for the adjacent nodes or does it
need to be communicated more widely? If the downstream node decides to take the component
link out of service, how does it inform the upstream node?

Does it matter whether it is the control plane or the data plane that will be taken out of
service?

Opinions please.

I would like to see these issues and their answers captured clearly in a requirements
section of any draft. Would the authors of draft-ali-ccamp-mpls-graceful-shutdown-00.txt
be willing to take that on even though the end result might be that procedures other than
those they suggest will be selected?

Adrian

Delivery-date: Tue, 07 Dec 2004 15:45:32 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-02.txt
Date: Tue, 7 Dec 2004 15:12:32 -0000

Hi,

This version of the draft was submitted to address the WG last call comments. Note that
the DISMAN WG was also polled during WG last call and, although they had a couple of
questions, they did not produce anything that needed a change to the draft.

There are a few nits outstanding and it offers me the oportunity to preach to draft
authors and editors.
(Note: I'm an author of this draft so, as usual, I am talking to myself.)

When you are responsible for a WG draft you need to assume full responsibility for the
state of the draft and for informing the WG about the changes in the draft. Thus, when a
new version is published to address WG last call comments it is important that the editor
sends a note to the mailing list to describe how they have addressed each issue. It should
not be left up to the WG chair to go through the comments one by one and check to see if
they have been handled.

Similarly, if (as often seems to be the case these days)-: the draft is mangled in the
publication process, it is the editor's job to handle this with the secretariat and ensure
that a new, clean copy is published.

So, for this draft, can we please have:
- an email that shows what has been done to address each last call comment
- a clean version with
   - page throws
   - formatting fixed
   - line lengths kept to the required minimum

Thanks,
Adrian

Delivery-date: Tue, 07 Dec 2004 15:43:39 +0000
Content-class: urn:content-classes:message
Subject: RE : draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Tue, 7 Dec 2004 16:40:38 +0100
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "JP Vasseur" <[email-masked]>

Hi Adrian, all

>Should this become a WG draft?

Yes

>Is it fine to include stitching in this draft, or does the=20
>wider applicability of stitching mean that it should be pulled=20
>out into a separate draft?

As you mention stiching could be used in other contexts (e.g. to support =
legacy LSR in P2MP)
So I would say that it could be better to pull it into a separate draft.
But I have no objection for including in this draft.

Regards,

JL

>-----Message d'origine-----
>De : [email-masked]=20
>[mailto:[email-masked]] De la part de Adrian Farrel
>Envoy=E9 : mardi 7 d=E9cembre 2004 15:43
>=C0 : [email-masked]
>Cc : Kireeti Kompella; Arthi Ayyangar; JP Vasseur
>Objet : draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
>
>
>Hi,
>
>As documented in the minutes from Washington DC, we discussed=20
>whether to make this draft an WG document.
>
>A show of hands in the room indicated that there were no=20
>objections but that not many had read the draft. So, two=20
>questions for the list...
>
>Should this become a WG draft?
>Is it fine to include stitching in this draft, or does the=20
>wider applicability of stitching mean that it should be pulled=20
>out into a separate draft?
>
>Thanks,
>Adrian
>
>
>

Delivery-date: Tue, 07 Dec 2004 15:33:15 +0000
Date: Tue, 07 Dec 2004 16:30:38 +0100
From: Loa Andersson <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked], Kireeti Kompella <[email-masked]>, Arthi Ayyangar <[email-masked]>, JP Vasseur <[email-masked]>
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?

Adrian,

my 5c

- yes - a wg doc
- on the stitching issue my opinion is not very
   strong, but my feeling is that it would be good
   to put the stitching issues in the same document,
   if we can't dpo that it would be good to at least
   pull them out of here and into a doc of its own

/Loa

Adrian Farrel wrote:

> Hi,
> 
> As documented in the minutes from Washington DC, we discussed whether to make this draft
> an WG document.
> 
> A show of hands in the room indicated that there were no objections but that not many had
> read the draft. So, two questions for the list...
> 
> Should this become a WG draft?
> Is it fine to include stitching in this draft, or does the wider applicability of
> stitching mean that it should be pulled out into a separate draft?
> 
> Thanks,
> Adrian
> 
> 
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Tue, 07 Dec 2004 14:43:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "JP Vasseur" <[email-masked]>
Subject: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Tue, 7 Dec 2004 14:43:02 -0000

Hi,

As documented in the minutes from Washington DC, we discussed whether to make this draft
an WG document.

A show of hands in the room indicated that there were no objections but that not many had
read the draft. So, two questions for the list...

Should this become a WG draft?
Is it fine to include stitching in this draft, or does the wider applicability of
stitching mean that it should be pulled out into a separate draft?

Thanks,
Adrian

Delivery-date: Tue, 07 Dec 2004 14:23:07 +0000
From: "Baktha Muralidharan" <[email-masked]>
To: <[email-masked]>, "'Adrian Farrel'" <[email-masked]>
Cc: "'???'" <[email-masked]>, <[email-masked]>
Subject: RE: LMP Related Questions
Date: Tue, 7 Dec 2004 09:21:48 -0500

As for the order [of the procedures], unless neighbor port ID info is
manually configured, link property correlation (link summry) cannot run
before link verification as neighbor port ID information won't be available.

[Interestingly however, link summary exchanges "link verification support"
bits in the header, which would suggest that link summary has to precede
link verification?]

I think that link verification could bring up link once neighbor ID mapping
info is successfully discovered.

Thanks,
/Baktha
Cisco Systems, Inc.
Boxborough, MA.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, December 07, 2004 8:24 AM
To: Adrian Farrel
Cc: ???; [email-masked]
Subject: Re: LMP Related Questions

hi adrian - two things the first to complete the below is that the link
property correlation should be done before the link is brought up and may be
done at any time a link is up and not in the verification process - note
also there is an (implicit) assumption that if the link verification process
is not used an alternative mechanism is to be provided for associating the
interface id as part of the data link subobjects to be correlated with the
link summary message

the second is can someone explain why i don't see the original mail (blank)
? is the original sender using a special font and i have to wait that
someone replies to convert it ? not the first time it happens when i
received e-mail from korea

---

> Hi, ccampers.
>
> I've some questions for the LMP implementation.
> First, I'd like to know the UDP port identifier of LMP. But, I can't 
> find out the identifier.
> Is it OK as I define it randomly?

Not if you want to interoperate!

If you look at http://www.iana.org/assignments/port-numbers you will see
that IANA has allocated port 701.

lmp             701/tcp    Link Management Protocol (LMP)
lmp             701/udp    Link Management Protocol (LMP)
#                          RFC-ietf-ccamp-lmp-10.txt

> Second, I do not know the execution order between link connectivity 
> verification and link property correlation.
> Which function should be first performed? In the draft of LMP, I'm 
> very confusing.

First, note that link property correlation is a core (mandatory) function,
but link connectivity verification is an optional procedure.
Second, the link connectivity verification procedure can be run at any time
to verify the physical connectivity.

However, if you do run the link connectivity verification procedure at start
of day in order to determine and exchange the Interface IDs, you would be
wise to run the procedure before link property correlation because that way
you will know which links are being bundled or described in the link
property correlation phase.

> Who help me to solve these questions?

Perhaps someone with some running code would care to comment?

Cheers,
Adrian

Delivery-date: Tue, 07 Dec 2004 13:25:04 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: =?euc-kr?B?sei/tcit?= <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: LMP Related Questions
Date: Tue, 7 Dec 2004 14:24:25 +0100

hi adrian - two things the first to complete the below is that the link
property correlation should be done before the link is brought up and may
be done at any time a link is up and not in the verification process - note
also there is an (implicit) assumption that if the link verification
process is not used an alternative mechanism is to be provided for
associating the interface id as part of the data link subobjects to be
correlated with the link summary message

the second is can someone explain why i don't see the original mail (blank)
? is the original sender using a special font and i have to wait that
someone replies to convert it ? not the first time it happens when i
received e-mail
from korea

---

> Hi, ccampers.
>
> I've some questions for the LMP implementation.
> First, I'd like to know the UDP port identifier of LMP. But, I can't find
> out the identifier.
> Is it OK as I define it randomly?

Not if you want to interoperate!

If you look at http://www.iana.org/assignments/port-numbers you will see
that IANA has
allocated port 701.

lmp             701/tcp    Link Management Protocol (LMP)
lmp             701/udp    Link Management Protocol (LMP)
#                          RFC-ietf-ccamp-lmp-10.txt

> Second, I do not know the execution order between link connectivity
> verification and link property correlation.
> Which function should be first performed? In the draft of LMP, I'm very
> confusing.

First, note that link property correlation is a core (mandatory) function,
but link
connectivity verification is an optional procedure.
Second, the link connectivity verification procedure can be run at any time
to verify the
physical connectivity.

However, if you do run the link connectivity verification procedure at
start of day in
order to determine and exchange the Interface IDs, you would be wise to run
the procedure
before link property correlation because that way you will know which links
are being
bundled or described in the link property correlation phase.

> Who help me to solve these questions?

Perhaps someone with some running code would care to comment?

Cheers,
Adrian

Delivery-date: Tue, 07 Dec 2004 12:56:53 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: Re: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 12:24:49 -0000

> And, I should add, that the only protocol "extension" that
> draft-dachille requires is an ARO object, which is cloned
> after the ERO object, and can simply be "flipped" to form
> the ERO object of the second (diverse) path when setting
> up that path.
> (As was illustrated in the fig. on slide 3 of the D.C.
> presentation.)

We're in agreement.
There is a protocol extension and consequent increase in signaling load.
It is not a substantial increase.

Cheers,
Adrian

Delivery-date: Tue, 07 Dec 2004 12:51:28 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: =?ks_c_5601-1987?B?sei/tcit?= <[email-masked]>
Cc: <[email-masked]>
Subject: Re: LMP Related Questions
Date: Tue, 7 Dec 2004 12:45:04 -0000

> Hi, ccampers.
>
> I've some questions for the LMP implementation.
> First, I'd like to know the UDP port identifier of LMP. But, I can't find
> out the identifier.
> Is it OK as I define it randomly?

Not if you want to interoperate!

If you look at http://www.iana.org/assignments/port-numbers you will see that IANA has
allocated port 701.

lmp             701/tcp    Link Management Protocol (LMP)
lmp             701/udp    Link Management Protocol (LMP)
#                          RFC-ietf-ccamp-lmp-10.txt

> Second, I do not know the execution order between link connectivity
> verification and link property correlation.
> Which function should be first performed? In the draft of LMP, I'm very
> confusing.

First, note that link property correlation is a core (mandatory) function, but link
connectivity verification is an optional procedure.
Second, the link connectivity verification procedure can be run at any time to verify the
physical connectivity.

However, if you do run the link connectivity verification procedure at start of day in
order to determine and exchange the Interface IDs, you would be wise to run the procedure
before link property correlation because that way you will know which links are being
bundled or described in the link property correlation phase.

> Who help me to solve these questions?

Perhaps someone with some running code would care to comment?

Cheers,
Adrian

Delivery-date: Tue, 07 Dec 2004 12:39:18 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>
Subject: Re: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 12:19:01 -0000

Vishal,

> > > Finally the phrase "need further feedback" looks not clear, who needs
> > > feedback? -the list or the authors ?-
>
> > Despite the fact that both drafts have been around for some while, the
> > level of discussion on the ccamp list has been quite low.
>
> I think a few clarifications are rather crucial here:
>
> -- The diverse routing draft has, in fact, received significant discussion
> and debate (from all of the people involved in the inter-area work --
> vendors and providers), right during and after Seoul, from March-May 04
> -- please see the CCAMP WG archives for about 60-70-odd emails on it.
> (I'm not sure how one could classify this as "low".)

You're right, there was some thorough debate on the detailed function as described in an
earlier version of the draft, and you have done a lot to address those issues.

What I am missing (but maybe the community doesn't care?) is a higher-level debate about
the methodology to solve what might best be described as a hard problem. In other words,
while it is fine to get into the details of how ARO works and to polish that solution, I
have not seen the debate as to whether we want to adopt ARO.

In order to pursue this, we are now in need of some effort to develop a framework for
inter-domain diverse path computation.

We're now trying to put some text together for this (if it is a small amount of text it
will go into the existing framework draft - if it turns out to be a lot of text it will go
into its own draft). I know that you, Vishal, have volunteered to get the ball rolling and
when I have your text I will add my own (politically correct) spin before putting it out
to the list for debate.

> Draft-decnodder by contrast has seen much less (perhaps 2-3 emails), if any,
> discussion, so clubbing the two drafts in the same category w.r.t. the
> level of discussion doesn't seem appropriate.
> (It has largely come from me and a couple others.)

Yes. It is not as old as a draft, and has seen less debate.

> So, I think we need to be a bit careful when evaluating the extent of
> discussion.
>
> -- There was also significant discussion of this subject in San Diego --
> cf. the CCAMP WG meeting minutes again.
>
> Since it was then clearly stated that CCAMP WG would focus on the "simple"
> TE aspects first, with diverse routing deemed an "advanced" subject, so
> naturally for a short while there wasn't much that could be done in
> this area, as people began focussing on the "simple" aspects.

Yes. That's good, isn't it?
And now we are ready to move on to the diverse path issues and so it is appropriate to
open up the discussions.

> > I also have the impression that the interest in
> >implementation is not (yet) very strong.
>
> I believe implementation interest will pick up once CCAMP formally
> states an intent to look at this problem (as has already happened by the
> structuring of the WG meeting at D.C.).

What I mean is that I do not hear from providers (or vendors) that they are currently
trying to solve this problem in deployed networks. At the moment, they are still
struggling with simple, unprotected inter-AS TE.

> >As the working group moves on to specify the problem space that we
> >are trying to resolve, I hope that we will see more debate about the
> >possible solutions with a view to arriving at a single set of protocol
> >extensions.
>
> I'm not clear on what is meant by your statement above.

I mean that we should aim to have a single protocol solution if it can be applied to a
wide variety of scenarios, rather than a set of different protocol extensions that are
applicable to specific subsets of the problem. Perhaps, in answer to your point below, it
is not clear why a single set of protocol extensions could not be found to serve in both
(all) cases. If that means that neither of the existing drafts is sufficient, that sits
well with me.

> A number of the diverse routing/protection etc. drafts are looking
> at different problems (e.g. draft-decnodder is looking at inter-area
> link protection, while draft-dachille is looking at diverse inter-region
> path setup), so it is not clear how a single set of protocol extensions
> would serve?

Do you really mean inter-region? It seems to me that inter-region is really covered by the
region transit work covered in the two MRN drafts. It is relatively unlikely that an LSP
will start in one region and end in another - the encapsulation and adaptation rules to
achieve that don't look nice. But, perhaps someone has a requirement to deploy this?

Adrian

Delivery-date: Tue, 07 Dec 2004 12:39:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: Re: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 11:39:28 -0000

Vishal,

This is a good point that you should definitely be raising in the discussions about your
draft.

I can't however, update the minutes to reflect things you would have liked to have been
said at the meeting.

A

> >  > -- Differs from 11, addresses requirements from TEWG draft
> >
> > We want stress that ARO addresses requirements from the TEWG draft too
>
> > OK. This is a punctuation error in the minutes.
>
> >"-- Differs from 11, addresses requirements from TEWG draft"
>
> >should read
>
> >"-- Differs from 11
> > --Addresses requirements from TEWG draft"
>
> >We will update the minutes.
>
> I think it would be good for the minutes to then also note that
> http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-0
> 4.txt
>
> also directly address the requirements from the TE requirements
> draft, as below.
>
> > (draft-ietf-tewg-interas-mpls-te-req-09.txt), in particular is in
> > accordance with Section:
> >
> > 5.1.1. Inter-AS MPLS TE Operations and Interoperability
> > 5.1.5.  Re-optimization
> > 5.1.8. Scalability and Hierarchical LSP Support
> > 5.1.11. Extensibility
> > 6. Security Considerations
> >
> > This was also the basis on which we got some good feedback
> > from the service provider community in the extensive discussions
> > before, during, and after Seoul.
> > May be we need to better point out this issue in the next version of the
> > draft.

Delivery-date: Tue, 07 Dec 2004 07:34:58 +0000
Reply-To: =?ks_c_5601-1987?B?sei/tcit?= <[email-masked]>
From: =?ks_c_5601-1987?B?sei/tcit?= <[email-masked]>
To: <[email-masked]>
Cc: 
Bcc: 
Subject: LMP Related Questions
Date: Tue, 7 Dec 2004 16:34:22 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCCxpMD8tN64wcGmvu7GwCwgtOM=?= =?ks_c_5601-1987?B?tOc=?=
content-class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_1634A_01C4DC7A.9B2C2960
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_1634A_01C4DC7A.9B2C2960
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

<DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =B1=BC=B8=B2">
<DIV>Hi, ccampers.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I've some questions for the LMP implementation.</DIV>
<DIV>First, I'd like to know the UDP port identifier of LMP. But, I =
can't find out the identifier.</DIV>
<DIV>Is it OK as I define it randomly?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Second, I do not know the execution order between link connectivity =
verification and link property correlation.</DIV>
<DIV>Which function should be first performed? In the draft of LMP, I'm =
very confusing.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Who help me to solve these questions?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks in advance,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Young.</DIV>
<DIV>&nbsp;</DIV></DIV><img style=3D"display:none" width=3D0 height=3D0 =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3Dccamp@ops.=
ietf.org&name=3Dccamp%40ops.ietf.org&fromemail=[email-masked]&messag=
eid=[email-masked]%3E">
------=_NextPart_000_1634A_01C4DC7A.9B2C2960--

Delivery-date: Tue, 07 Dec 2004 06:27:53 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Mon, 6 Dec 2004 22:27:22 -0800

And, I should add, that the only protocol "extension" that
draft-dachille requires is an ARO object, which is cloned
after the ERO object, and can simply be "flipped" to form
the ERO object of the second (diverse) path when setting
up that path.
(As was illustrated in the fig. on slide 3 of the D.C.
presentation.)

-Vishal

> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Monday, December 06, 2004 10:22 PM
> To: Adrian Farrel; Ugo Monaco
> Cc: [email-masked]; Alessio D'Achille; Daniele Alì; Marco Listanti;
> Tove Madsen
> Subject: RE: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>
>
> Hi Adrian,
>
> Some comments, observations, and questions in-line
> in two successive emails.
>
> Here's the second ...
>
> -Vishal
>
> > -----Original Message-----
> > From: Adrian Farrel [mailto:[email-masked]]
> > Sent: Saturday, December 04, 2004 10:40 AM
> > To: Ugo Monaco
> > Cc: [email-masked]; Vishal Sharma; Alessio D'Achille; Daniele Alì;
> > Marco Listanti; Tove Madsen
> > Subject: Re: Draft minutes from Tove
> >
>
> <snip>
>
> > (draft-ietf-tewg-interas-mpls-te-req-09.txt), in particular is in
> > accordance with Section:
> >
> > 5.1.1. Inter-AS MPLS TE Operations and Interoperability
> > 5.1.5.  Re-optimization
> > 5.1.8. Scalability and Hierarchical LSP Support
> > 5.1.11. Extensibility
> > 6. Security Considerations
> >
> > This was also the basis on which we got some good feedback
> > from the service provider community in the extensive discussions
> > before, during, and after Seoul.
> > May be we need to better point out this issue in the next version of the
> > draft.
> >
> > Finally the phrase "need further feedback" looks not clear, who needs
> > feedback? -the list or the authors ?-
>
> >Despite the fact that both drafts have been around for some
> while, the level of
> > discussion
> >on the ccamp list has been quite low.
>
> I think a few clarifications are rather crucial here:
>
> -- The diverse routing draft has, in fact, received significant discussion
> and debate (from all of the people involved in the inter-area
> work -- vendors
> and providers), right during and after Seoul, from March-May 04
> -- please see
> the CCAMP WG archives for about 60-70-odd emails on it. (I'm not sure
> how one could classify this as "low".)
>
> Draft-decnodder by contrast has seen much less (perhaps 2-3
> emails), if any,
> discussion, so clubbing the two drafts in the same category w.r.t. the
> level of discussion doesn't seem appropriate.
> (It has largely come from me and a couple others.)
>
> So, I think we need to be a bit careful when evaluating the extent of
> discussion.
>
> -- There was also significant discussion of this subject in San Diego --
> cf. the CCAMP WG meeting minutes again.
>
> Since it was then clearly stated that CCAMP WG would focus on the "simple"
> TE aspects first, with diverse routing deemed an "advanced" subject, so
> naturally for a short while there wasn't much that could be done in
> this area, as people began focussing on the "simple" aspects.
>
> > I also have the impression that the interest in
> >implementation is not (yet) very strong.
>
> I believe implementation interest will pick up once CCAMP formally
> states an intent to look at this problem (as has already happened by the
> structuring of the WG meeting at D.C.).
>
> > As the working group moves on to specify the
> >problem space that we are trying to resolve, I hope that we will
> see more debate about
> > the
> >possible solutions with a view to arriving at a single set of
> protocol extensions.
>
> I'm not clear on what is meant by your statement above.
>
> A number of the diverse routing/protection etc. drafts are looking
> at different problems (e.g. draft-decnodder is looking at inter-area
> link protection, while draft-dachille is looking at diverse inter-region
> path setup), so it is not clear how a single set of protocol extensions
> would serve?
>

Delivery-date: Tue, 07 Dec 2004 06:23:47 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Mon, 6 Dec 2004 22:21:48 -0800

Hi Adrian,

Some comments, observations, and questions in-line
in two successive emails.

Here's the second ...

-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Saturday, December 04, 2004 10:40 AM
> To: Ugo Monaco
> Cc: [email-masked]; Vishal Sharma; Alessio D'Achille; Daniele Alì;
> Marco Listanti; Tove Madsen
> Subject: Re: Draft minutes from Tove
>

<snip>

> (draft-ietf-tewg-interas-mpls-te-req-09.txt), in particular is in
> accordance with Section:
>
> 5.1.1. Inter-AS MPLS TE Operations and Interoperability
> 5.1.5.  Re-optimization
> 5.1.8. Scalability and Hierarchical LSP Support
> 5.1.11. Extensibility
> 6. Security Considerations
>
> This was also the basis on which we got some good feedback
> from the service provider community in the extensive discussions
> before, during, and after Seoul.
> May be we need to better point out this issue in the next version of the
> draft.
>
> Finally the phrase "need further feedback" looks not clear, who needs
> feedback? -the list or the authors ?-

>Despite the fact that both drafts have been around for some while, the
level of
> discussion
>on the ccamp list has been quite low.

I think a few clarifications are rather crucial here:

-- The diverse routing draft has, in fact, received significant discussion
and debate (from all of the people involved in the inter-area work --
vendors
and providers), right during and after Seoul, from March-May 04 -- please
see
the CCAMP WG archives for about 60-70-odd emails on it. (I'm not sure
how one could classify this as "low".)

Draft-decnodder by contrast has seen much less (perhaps 2-3 emails), if any,
discussion, so clubbing the two drafts in the same category w.r.t. the
level of discussion doesn't seem appropriate.
(It has largely come from me and a couple others.)

So, I think we need to be a bit careful when evaluating the extent of
discussion.

-- There was also significant discussion of this subject in San Diego --
cf. the CCAMP WG meeting minutes again.

Since it was then clearly stated that CCAMP WG would focus on the "simple"
TE aspects first, with diverse routing deemed an "advanced" subject, so
naturally for a short while there wasn't much that could be done in
this area, as people began focussing on the "simple" aspects.

> I also have the impression that the interest in
>implementation is not (yet) very strong.

I believe implementation interest will pick up once CCAMP formally
states an intent to look at this problem (as has already happened by the
structuring of the WG meeting at D.C.).

> As the working group moves on to specify the
>problem space that we are trying to resolve, I hope that we will see more
debate about
> the
>possible solutions with a view to arriving at a single set of protocol
extensions.

I'm not clear on what is meant by your statement above.

A number of the diverse routing/protection etc. drafts are looking
at different problems (e.g. draft-decnodder is looking at inter-area
link protection, while draft-dachille is looking at diverse inter-region
path setup), so it is not clear how a single set of protocol extensions
would serve?

Delivery-date: Tue, 07 Dec 2004 06:23:39 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Mon, 6 Dec 2004 22:21:45 -0800

Hi Adrian,

Some comments, observations, and questions in-line,
in two successive emails.

Here's the first.

-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Saturday, December 04, 2004 10:40 AM
> To: Ugo Monaco
> Cc: [email-masked]; Vishal Sharma; Alessio D'Achille; Daniele Alì;
> Marco Listanti; Tove Madsen
> Subject: Re: Draft minutes from Tove
>

<snip>

> >  > 12. Related to 11.  Protection for Inter-AS tunnels -
> Decnodder - Cristel
> >  > Pelsser
> >  >
> >
> <http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas
-protectio
>  > n-00.txt>
>  > -- Differs from 11, addresses requirements from TEWG draft
>
> We want stress that ARO addresses requirements from the TEWG draft too

> OK. This is a punctuation error in the minutes.

>"-- Differs from 11, addresses requirements from TEWG draft"

>should read

>"-- Differs from 11
> --Addresses requirements from TEWG draft"

>We will update the minutes.

I think it would be good for the minutes to then also note that
http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-0
4.txt

also directly address the requirements from the TE requirements
draft, as below.

> (draft-ietf-tewg-interas-mpls-te-req-09.txt), in particular is in
> accordance with Section:
>
> 5.1.1. Inter-AS MPLS TE Operations and Interoperability
> 5.1.5.  Re-optimization
> 5.1.8. Scalability and Hierarchical LSP Support
> 5.1.11. Extensibility
> 6. Security Considerations
>
> This was also the basis on which we got some good feedback
> from the service provider community in the extensive discussions
> before, during, and after Seoul.
> May be we need to better point out this issue in the next version of the
> draft.

Delivery-date: Mon, 06 Dec 2004 12:47:39 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, "Tove Madsen" <[email-masked]>, <[email-masked]>
Subject: IETF 61 : CCAMP Minutes
Date: Mon, 6 Dec 2004 12:43:03 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_02BB_01C4DB91.204D1540
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Please find attached the minutes from the CCAMP meeting at IETF 61.
Please let us know if there any questions.

Regards,
Adrian
------=_NextPart_000_02BB_01C4DB91.204D1540
Content-Type: text/plain;
	name="ccamp-61-minutes.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ccamp-61-minutes.txt"

61st IETF CCAMP Minutes
11/11/2004
Minutes taken by
Lyndon Ong, Deborah Brungard, Dimitri Papadimitriou

1. Admin and agenda bash - Chairs (5 min)
Agenda bashing - no changes

2. Status of WG drafts - Adrian (10 min)

Drafts now unblocked, however the removal of the MPLS bundling draft has
caused another snag.
We have got two new RFCs, Architecture (3945) and SONET/SDH Extensions
(3946).
Six drafts are in the RFC Ed. queue.
Five are in IETF Last Call.
Two are in IESG review.
15 active drafts - if you want a draft adopted as WG draft, let's finish
these first!
Tunnel trace in particular seems to have very little interest - will be
discussed wrt to rechartering.

Overall status: almost all milestones completed, should recharter or
close in March '04!

Lou - slide does not list all 15 drafts - others are still active? In
particular Alarm_Spec
Adrian - no intention to exclude, asked if implementation on alarm
spec draft.
Lou - at least one, possibly two,
Kireeti - only need one, so Ok to go forward

Adrian - Note: Node_Id based Hello has not been updated before deadline
Adrian - Milestones and re-chartering will be covered at the end of the
meeting.
Dimitri Papadimitriou - Correction. Node_Id based hello was submitted in
time. Updates for WG last call comments.

3. Link Bundling - Zafar Ali
 -- Issues with current RFCs and drafts
 -- Draft removed from the RFC editor's queue
 -- Issues with scooping type 4/5 TLVs for IF_ID_RSVP_HOP and
    IF_ID_ERROR_SPEC, also recording of route
 -- Plan to address first two issues in an updated draft but component
    link recording will remain outside the scope of the bundling draft.
    Will allow but recommend against use of types 4/5.
 -- Work on recording/explicit control will be done in a separate ID.
    Home in MPLS or CCAMP?

 -> see slides

 -- Plans
    Pulled from queue (reviewed slides)

Adrian: procedure -> MPLS WG own document. Do review on what happens in
this WG
Note: speed is really important as we have multiple blocking documents
in the CCAMP WG queue.

Kireeti: This is not free for all on the bundling draft - change to be
proposed and to be sent on the list (delta only)

George: as MPLS chair, MPLS group plans to do updates quickly -
considered as last call comments

4. ASON Signaling Solutions - Dimitri P (5min)
<http://www.ietf.org/internet-drafts/
draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt>

<http://www.olddog.co.uk/
draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt>

 -- ASON signaling - no updates but lots of thinking esp. call setup
    message naming (Notify vs. specialized message), desire not to
    "piggyback" call information in the connection message.  Expect
    finalized draft around Christmas time.
 -- ASON routing solutions design team
    - Evaluation of common "pattern" has taken time, evaluation document
      should be issued by end- November.
    - Model shown - use of terminology - what is TE Router ID, what is
      OSPF Router ID?
    - Further considerations - control plane does not transport the
      actual transport plane ids, but its view of the transport plane,
      using an associated IP addressing space.
    - No internal structure is associated with an abstract node.
    - Hierarchy focus is on exchange of information between peers.
    - Representation of bandwidth needs further thought.
Adrian: it seems the DT has been making good progress, CCAMP WG has
unfortunately not been aware of the progress, progress must be shown to
the group by either sending status or updating the draft.
Dimitri: will mail to the list.
Zafar Ali: how does this work relate to the OSPF and ISIS groups?
Dimitri: we are evaluating what may be missing, after this evaluation we
can address protocol-specific issues.
Zafar: Are you looking at existing mechanisms?
Dimitri: global applicability is next step, currently looking at what
info is exchanged

5. ITU Liaison - Lyndon Ong

 -- ITU continues to be interested in converging the work on signaling
    and routing
 -- ITU thanks CCAMP for its liaisons, and esp. Adrian for attending the
    last Q14 meeting
 -- ITU is currently working on ASON management specifications and
    thanks CCAMP for its liaison of the GMPLS MIB work for its review
Zafar: can we also have a report of OIF status?
Chairs and Lyndon: there is nothing formal to report at this time that's
why it was not scheduled on the agenda.  However, liaisons will be sent
to the mailing list for everyone's review, and if something formal is
made available, it will be scheduled.
Lyndon: - there is ongoing discussion and communication just sent back
to IETF
Adrian: but not there yet (not available)
Lyndon: is there a need for a permanent liaison from the OIF at the
CCAMP meeting?
Adrian: if there is something to be discussed it will be considered on a
per-request/per-case basis

6. Graceful Shutdown - Zafar Ali (10 min)
http://www.ietf.org/internet-drafts/
draft-ali-ccamp-mpls-graceful-shutdown-00.txt

 -- Intention is to support a planned shutdown, e.g., for maintenance
    purposes
 -- IGP based solution does not cover Inter-AS/Area scenarios
 -- RSVP-based solution does not convey information to all nodes in the
    network.
 -- Both mechanisms must complement each other
 -- Use existing sub-code of the Path Error message, then perform
    make-before-break for the LSP. Proposed changes are minor and based
    on existing framework.
 -- Would like to propose this ID as a WG document
Rahul: is this intra or inter?  inter-domain can use hierarchy of LSPs
(nesting/stitching) to achieve this isolation.
Zafar: recognize both mechanisms
Rahul: we should clarify these aspects, as well as inter-domain TE
aspects.
Zafar: can add these aspects in the document
Richard Rabbat: why is this GMPLS rather than MPLS?
Zafar: could be shutting down any type of link.
Adrian: in terms of problem space it is needed in both cases
Igor Bryskin: this is a data plane problem followed by rerouting - why
don't we use existing mechanisms such as propagating alarms?
Zafar: distinguish this from alarms as this is not something that
requires an immediate reroute. This is not intended to tackle data plane
alarms
Kireeti: maintenance of the link/node - out-of-service issue is to get
traffic out of the link
Igor: alarms do not only mean "failure". Could it use alarm severity?
Kireeti: not an alarm situation.
Adrian: this is maintenance alarm => requires to scope the work
Igor: Tools already exist to trigger the same thing, the existing tools
are more powerful than this proposed one
Zafar: point to the capability of the mechanism having the indication to
perform make-before-break - also suggest put on the list what you think
are alternative mechanisms
Lou Berger: if we do this, we should use existing mechanisms such as
admin status or alarm (Arthi's suggested one, Igor's alarm admin status)
Zafar: this mechanism is already in the spec - JP's re-optimization
draft
Lou: other mechanisms are in RFCs. We should decide on mechanisms before
we accept as a WG draft.
Kireeti: step back from the solution, so the point is to write down what
is to be achieved (take things out gracefully) -> need first to look at
requirements for what want to do.
Zafar: agreement

7. Interdomain Framework - Adrian (5min)
<http://www.ietf.org/internet-drafts/
  draft-ietf-ccamp-inter-domain-framework-00.txt>
 -- Minor changes since last time, but published as WG draft
 -- Applies to both MPLS and GMPLS, but currently limited to simpler
    functions for initial work
 -- Realize need more discussion on definition of "domain" e.g. Nested
    domains, ensure GMPLS included. Will take to list for discussion.
 -- This covers "simple" functions, what about "advanced" functions such
    as diverse paths, mapping domain-specific constraints such as
    DiffServ, pt-to-mpt, etc.?
 -- Adrian's suggestion is to keep this separate for convenience.
Rahul: MPLS OAM - building blocks are in place, so it can go in this
document; P2MP is considerably less well understood.
Kireeti: what about GMPLS OAM?
Dimitri: need to understand what we mean by GMPLS OAM. Suggest phased
approach.

8. Interdomain TE Requirements - Tomohiro Otani (5min)
<http://www.ietf.org/internet-drafts/
draft-otani-ccamp-interas-gmpls-te-01.txt>

 -- Joint proposal from NTT/KDDI, can be used for L1VPN, MPLS-TE
 -- Changes:  added section identifying the following general
    requirements
    - EGP extensions for GMPLS
    - GMPLS Inter-AS signaling, path calculation and recovery
    - GMPLS interdomain TE management
 -- Remaining issues:
    - Investigate added load created by EGP extensions
    - Investigate L1VPN, use of SRLG for consistency, rechartering
      impacts
    - Propose WG document
Zafar: recommended would be a good basis for inter-domain TE framework
Arthi: support effort, but has too many solutions-related aspects in it.
Also suggest separating requirements into signaling, routing and path
computation. Need to clarify what is meant by domain - refer to
framework document.
Dimitri: what about reachability information exchange?  Not addressed,
but will be an important aspect.
Adrian: this is solution, not requirements. Suggest to separate
requirements and solutions. General approval of the work, but need to
remove solutions. Should consider reachability as well as TE aspects.
Restructure as Arthi suggests.
Otani: agree, will separate
Kireeti summarizing: separate requirements from solution and structure:
signaling from routing (in part. reachability)

9. Summarize Status and plans of PCE BOF (JP Vasseur) (5 minutes)
 -- Scope issues
    - No intent to come up with new interdomain routing paradigm
    - Scoped applicability to a limited number of TE LSPs
    - Scoped to a "simple" topology of ASes or areas
 -- Previous BOF - clear requirements from many SPs and common theme of
    problem - MPLS TE LSP path computation
 -- Architecture - comments noted global picture needed, but no
    standardization of architecture.  New revision to be submitted soon
    in the meantime please comments!
 -- Note agreed no intention to extend LDP, but possibly other protocols
 -- Agreed on proposed charter and milestones, proposal to be sent out
    early next week.
 -- Many in favor of new WG, none against - need IESG review and work on
    charter
Bijan Jabbari: what scale of LSPs?
JP: no specific number, not full mesh - does this mean no scalability
concerns?
Adrian: need to make the problem manageable, at least initially.
Bijan: will WG be open to new architectures?
Kireeti: take this to the list.
Peter Toms: support this, lots of requests for this.

10. Inter-Domain RSVP-TE extensions - Arthi Ayyangar (5min)
<http://www.ietf.org/internet-drafts/
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt>
 -- Changes - include separate section on stitching and required
    extensions, clarifications for non-packet LSPs.
 -- Request to make it a WG document - none against, but limited number
    agreeing (note: not many read the draft)- list.
Adrian: stitching has wider applicability - should we pull it out into a
separate draft?

11. Diverse Inter-region Setup - D'Achille - presented by Adrian (5 min)
<http://www.ietf.org/internet-drafts/
draft-dachille-inter-region-path-setup-04.txt>

 -- Adrian not that familiar with this draft. Flags one slide on message
    exchange where the head end is in the center rather than at the end.
    Notes several claim, explicitly claim of no new protocol seems
    questionable as new objects are defined. Need further feedback.
 -- Can't take questions as no authors present to discuss - take to list

12. Related to 11.  Protection for Inter-AS tunnels - Decnodder - Cristel
Pelsser
<http://www.ietf.org/internet-drafts/
draft-decnodder-ccamp-interas-protection-00.txt>
 -- Differs from 11
 -- Addresses requirements from TEWG draft
 -- Uses RSVP-TE and FRR
 -- Adds clarifications on SRLG scope, assumed to correspond to a single
    AS
 -- Looking for feedback, how to generalize to GMPLS
Adrian: need to apply to GMPLS if you want the draft to be in this group
Zafar: SRLG issue - need to solve the scooping issue, applies in a
number of places.
Adrian: WG should look at a framework for diverse paths, including PCE
Zafar: needs more discussion to understand, and already work in MPLS WG
on ABR protection.
Adrian: authors can continue draft, would also like for CCAMP to
evaluate if PCE is appropriate, or something else
JP: should include the PCE mailing list on this.
Adrian: need discussion on the ccamp list.

13. Requirements for multi-region - Kohei Shiomoto
<http://www.ietf.org/internet-drafts/
draft-shiomoto-ccamp-gmpls-mrn-requirements-00.txt>

 -- Region defined based on switching capability - note region is
    control plane, layer is data plane
 -- Addresses pre-provisioned FA, triggered FA and no FA cases.  Plain
    and hybrid type nodes.
 -- Architecture has generated requirements and solutions drafts
 -- Virtual network topology, application example
 -- Propose as WG document.
Adrian: handling regions are in scope of CCAMP.
Adrian: asks Dimitri to immediately present the extensions then we will
take questions

<http://www.ietf.org/internet-drafts/
draft-shiomoto-ccamp-gmpls-mrn-extensions-00.txt>
Dimitri Papadimitriou

 -- TE metric inheritance - how to inherit or map metrics
 -- How is recovery abstracted for an FA - e.g., end2end vs. span
    protected?
 -- Reconvergence of VNT
 -- Handling multiple switching and adaptation capabilities
Zafar: is this a good idea from TE point of view - dynamic FA creation -
need applicability statement - potential bandwidth segmentation issues -
may lose aggregation that you would normally get at the boundary - could
add oscillation.  If still considered a good idea, should it be
triggered by signaling or some other mechanism?  Document needs to list
concerns.
Arthi: some parts of requirements still not clear - what is needed
outside of the LSP hierarchy draft?  Need to clarify what is missing
from the existing, and reference where it's covered by existing
documents.  Don't want to reinvent terminology.  Regarding virtual FA
setup can be pre-provisioned or on demand - hierarchy draft already says
this, should not be in the requirements document but only in the
solutions document. Regarding protection - more work needs to be done in
the requirements.
Igor: region, layer, hierarchy level are treated interchangeably in the
draft, confusing.  Regarding stitching, this is a very general
capability and should be in LSP hierarchy instead.
Kireeti: thinks this should have a separate document.
Adrian: more clarification would be good on layer/region
Jonathan Sadler: good stuff in general, agree with the goal.  Concern is
that IETF framework is not well aligned to ITU concept of layered
network (G.805).  It would be good to take into account the ITU
framework.  Work on extensions is premature at this time.
Deborah Brungard: authors intended to handle multiple layers as in ITU
(e.g. G.805) - limited to single domain for now, should be addressed to
GMPLS RFCs. Not intended to discuss data plane concepts. Request for
more specific comments.

14. MPLS-to-GMPLS Migration - Kohei Shiomoto
<http://www.ietf.org/internet-drafts/
draft-oki-ccamp-gmpls-ip-interworking-04.txt>

 -- Evolution from legacy MPLS to GMPLS -
 -- Differences: architecture (C/D separation, bidirectionality, P&R);
    routing (opaque LSA); signaling (new objects, messages)
 -- Propose WG document
Kireeti: question on whether this is in scope - address on charter
Zafar: multi-layer comments also apply here.
Richard Rabbat: supports the work, suggests looking at more generic
numbers of regions (not just 2 or 3).
Ping Pan: how does this differ from the overlay model?
Kireeti: different, take this to the list.

15. L1 VPN - Tomonori Takeda (10 Min)
<http://www.ietf.org/internet-drafts/
  draft-takeda-l1vpn-framework-02.txt>
<http://www.ietf.org/internet-drafts/
 draft-takeda-l1vpn-applicability-01.txt>
<http://www.ietf.org/internet-drafts/
 draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt>
<http://www.ietf.org/internet-drafts/
 draft-ietf-ccamp-gmpls-overlay-05.txt>

 -- Mailing list - www1.ietf.org/mailman/listinfo/l1vpn
 -- Two drafts applicable, ouldbrahim and overlay - guidelines for
    enhancement, deployment scenaros - added terminology refinement,
    security considerations, service models
 -- Further comments solicited, planning further liaison to SG13.
 -- Applicability draft examines existing GMPLS protocols for L1 VPN
    services. Has added Deborah as co-author.
 -- Concept - set up FA LSP between PEs, use stitching to connect this
    to CEs.
 -- Propose to adopt as CCAMP charter item.
Kireeti: supports applicability draft.  Liaison with ITU is very
important - we need to be responsive.  We will discuss this item as part
of the extension of the CCAMP charter

16. Signaling for L2 LSPs - Dimitri Papadimitriou (10 minutes)
<http://www.ietf.org/internet-drafts/
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt>

 -- ATM, FR, ETH, etc.  Defines label request processing, label
    semantics, added security section.
 -- Security - threats analysis, attacks on the data plane, L2 LSP
    signaling, attacks on control plane
 -- Ask for WG draft, no plan to respin
Dave Allan: Question on Ethernet VLAN tag swapping - not defined in
IEEE.
Dimitri: intended to cover GMPLS scope, not data plane.  Should not
assume tag is per port unique.
Don Fedyk: is this P2P?
Dimitri: Yes (as starting point).
Kireeti: ok, we have a fair consensus, so I would say it's a rough
consensus point. We will take this to the list, Dave and Dimitri to
work out VLAN issue.
Adrian: Note that an MPLS group draft on L2 has come up

17. Mesh Carrier Survey - Richard Rabbat (5 min)
<http://www.ietf.org/internet-drafts/
draft-rabbat-ccamp-carrier-survey-01.txt>

 -- Initially 7 carriers polled, open to others
 -- Also surveys GMPLS control plane deployment
 -- 1 has deployed, 3 within 2-3 years, 3 with no current plans
 -- Concerns with stability, signaling storms
 -- Asking for feedback, new carrier input
Richard: review slides, recommend for CCAMP WG to begin work on shared
mesh restoration performance

18. Milestone and Charter discussion - Kireeti

 -- Current activities winding down, esp. P&R, ASON
 -- Others underway, esp. multi-domain
 -- New: migration, VPNs, control plane resilience, addressing,
    implementation experience, GTTP (?)
 -- Migration
    - GMPLS supersets MPLS, but some objects are different - label
      request, label, upstream label
    - Need BCP on smooth migration, what issues may occur
 -- L1 VPN
    - Should IETF do this?  Should it be in CCAMP?  Tied to UNI and
      Interdomain signaling
 -- Control plane resilience - includes graceful restart but also more
 -- Addressing - transport networks use different kinds of addresses
    - need decoder ring for mapping transport network address types to
      IP addresses
    - Kireeti considers this useful
 -- Interop results
    - note that addressing pops up there as well.  BCPs would be helpful
 -- Send out request for new work items, replies due Friday 11/19.
 -- Send out checks for consensus on each item, replies due Friday 12/3
 -- Send resulting list to A-Ds, trimmed if necessary, add appropriate
    milestones
 -- Consensus is a requirement but not a guarantee.
Lou: how about dropping something from the existing charter
Kireeti: maybe GTTP
Lou: should note on the list also things that may be dropped if no
support
Alex Zinin: about L1 VPNs - is this research work, or practical?  Need
at least one implementation - is anyone implementing this within a year
or two?
Dimitri: Solutions exist provided by vendors today, but no common
framework.  Timeframe for implementation is 18-24 months.
Alex: remind the group of the need for running code.
Adrian: what about informational draft on how to use existing functions
to do the service?  Is there any interest from the research groups or
the real carrier deployment groups?
Tomonori Takeda: NTT has interest, but not sure of protocols.  Timeframe
cannot say.  Testing is done.
Yakov Rekhter: vendors cannot disclose future product plans...
Deborah Brungard: carriers also cannot disclose plans, will see interest
by number of co-authors.
Kireeti: have had carriers ask for this technology.  We don't have all
the pieces, but have implemented many of them, and as a vendor would
like to see a solution on how to do. Answer to Alex is yes.
Richard Rabbat: could add this to his survey.
Kireeti: supports this.

MEETING IS ADJOURNED.

------=_NextPart_000_02BB_01C4DB91.204D1540--

Delivery-date: Sun, 05 Dec 2004 12:14:47 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Dimitri Papadimitriou" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Cc: <[email-masked]>
Subject: Node ID Hello [Was: Re: Draft minutes from Tove]
Date: Sun, 5 Dec 2004 12:12:57 -0000

Hi,

You're right. It was published on 26th October, but that means it must have been submitted
before then.

Can you remind me? This revision was to address all of the WG last call comments; yes?

Can you summarise the changes you made for the list, please.

Thanks,
Adrian
----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, December 04, 2004 9:20 PM
Subject: Re: Draft minutes from Tove

> hi adrian,
>
> a small comment:
>
> > Adrian - Note: Node_Id based Hello has not been updated before
> > deadline
>
> i mentioned that the update of the Node_Id based Hello document has been
> effectively submitted before the deadline
>
> thanks,
> - dimitri.
>
> Adrian Farrel wrote:
>
> > Hi ccamp!
> > Thanks to Lyndon Ong, Deborah Brungard, and Dimitri Papadimitriou we
> > can now read about the ccamp meeting, IETF61.
> > Please provide your comments no later than 3rd December if you miss any
> > important wording (or you like to change the complete meeting;-)
> > / Tove
> > Tove Madsen
> > Acreo AB
> > [email-masked]
> > ===
> > 61st IETF CCAMP Minutes
> > 11/11/2004
> > Minutes taken by
> > Lyndon Ong, Deborah Brungard, Dimitri Papadimitriou
> >
> > 1. Admin and agenda bash - Chairs (5 min)
> > Agenda bashing - no changes
> > 2. Status of WG drafts - Adrian (10 min)
> > Drafts - now unblocked, however the removal of the MPLS bundling draft has
> > caused another snag. We have got two new RFCs, Architecture (3945) and
> > SONET/SDH Extensions (3946).  Six drafts are in the queue.  Five are in
> > IETF
> > Last Call, two are in IESG review.  15 active drafts - if you want a draft
> > adopted as WG draft, let's finish these first!  Tunnel trace in particular
> > seems to have very little interest - will be discussed wrt to rechartering.
> > Overall status: almost all milestones completed, should recharter or close
> > in March '04!
> > Lou - slide does not list all 15 drafts - others are still active? In
> > particular Alarm_Spec
> > Adrian said no intention to exclude, asked if implementation on alarm
> > draft,
> > Lou said at least one, possibly two, Kireeti said only need one, so Ok
> > to go
> > forward.
> > Adrian - Note: Node_Id based Hello has not been updated before deadline
> > Adrian - Milestones and re-chartering will be covered at the end of the
> > meeting.
> > 3. Link Bundling - Zafar Ali
> > -- Issues with current RFCs and drafts
> > -- Draft removed from the RFC editor's queue
> > -- Issues with scooping type 4/5 TLVs for IF_ID_RSVP_HOP and
> > IF_ID_ERROR_SPEC, also recording of route
> > -- Plan to address first two issues in an updated draft but component link
> > recording will remain outside the scope of the bundling draft.  Will allow
> > but recommend against use of types 4/5.
> > -- Work on recording/explicit control will be done in a separate ID.  Home
> > in MPLS or CCAMP?
> > -> see slides
> > -- Plans
> > Pulled from queue (reviewed slides)
> > -- Adrian: procedure -> MPLS WG own document. Do review on what happens in
> > this WG
> > Note: speed is really important as we have multiple blocking documents in
> > the CCAMP WG queue.
> > -- Kireeti - this is not free for all on the bundling draft - change to be
> > proposed and to be sent on the list (delta only)
> > George: as MPLS chair, MPLS group plans to do updates quickly - considered
> > as last call comments
> >
> > 4. ASON Signaling Solutions - Dimitri P (5min)
> > <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.
> >
> > txt>
> > <http://www.olddog.co.uk/draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt>
> >
> > -- Mention OIF response is on the way
> > -- ASON signaling - no updates but lots of thinking esp. call setup message
> > naming (Notify vs. specialized message), desire not to "piggyback" call
> > information in the connection message.  Expect finalized draft around
> > Christmas time.
> > -- ASON routing solutions design team
> > - Evaluation of common "pattern" has taken time, evaluation document should
> > be issued by end- November.
> > - Model shown - use of terminology - what is TE Router ID, what is OSPF
> > Router ID?
> > - Further considerations - control plane does not transport the actual
> > transport plane ids, but its view of the transport plane, using an
> > associated IP addressing space.
> > - No internal structure is associated with an abstract node.
> > - Hierarchy focus is on exchange of information between peers.
> > - Representation of bandwidth needs further thought.
> > -- Adrian - it seems the DT has been making good progress, CCAMP WG has
> > unfortunately not been aware of the progress, progress must be shown to the
> > group by either sending status or updating the draft.
> > -- Dimitri - will mail to the list.
> > -- Zafar - how does this work relate to the OSPF and ISIS groups?
> > -- DP - we are evaluating what may be missing, after this evaluation we can
> > address protocol-specific issues.
> > -- Zafar - Are you looking at existing mechanisms?
> > -- Dimitri - global applicability is next step, currently looking at what
> > info is exchanged
> >
> > 5. ITU Liaison - Lyndon Ong
> > -- ITU continues to be interested in converging the work on signaling and
> > routing
> > -- ITU thanks CCAMP for its liaisons, and esp. Adrian for attending the
> > last
> > Q14 meeting
> > -- ITU is currently working on ASON management specifications and thanks
> > CCAMP for its liaison of the GMPLS MIB work for its review
> > -- Zafar - can we also have a report of OIF status?  Chairs and LO;
> > there is
> > nothing formal to report at this time that's why it was not scheduled on
> > the
> > agenda.  However, liaisons will be sent to the mailing list for everyone's
> > review, and if something formal is made available, it will be scheduled.
> > -- Lyndon - there is ongoing discussion and communication just sent back to
> > IETF
> > -- Adrian - but not there yet (not available)
> > -- Lyndon - is there a need for a permanent liaison from the OIF at the
> > CCAMP meeting?
> > -- Adrian - if there is something to be discussed it will be considered
> > on a
> > per-request/per-case basis
> > 6. Graceful Shutdown - Zafar Ali (10 min)
> > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-0
> >
> > 0.txt
> > -- Intention is to support a planned shutdown, e.g., for maintenance
> > purposes
> > -- IGP based solution does not cover Inter-AS/Area scenarios
> > -- RSVP-based solution does not convey information to all nodes in the
> > network.
> > -- Both mechanisms must complement each other
> > -- Use existing sub-code of the Path Error message, then perform
> > make-before-break for the LSP. Proposed changes are minor and based on
> > existing framework.
> > -- Would like to propose this ID as a WG document
> > Rahul- is this intra or inter?  inter-domain can use hierarchy of LSPs
> > (nesting/stitching) to achieve this isolation.
> > -- Zafar - though recognize two mechanisms
> > -- Rahul- we should clarify these aspects, as well as inter-domain TE
> > aspects.
> > -- Zafar - can add these aspects in the document
> > -- Richard Rabbat - why is this GMPLS rather than MPLS?
> > Zafar - could be shutting down any type of link.
> > -- Adrian - in terms of problem space it is needed in both cases
> > -- Igor Bryskin - this is a data plane problem followed by rerouting - why
> > don't we use existing mechanisms such as propagating alarms?
> > Zafar - distinguish this from alarms as this is not something that requires
> > an immediate reroute. This is not intended to tackle data plane alarms
> > -- Kireeti - maintenance of the link/node - out-of-service issue is to get
> > traffic out of the link
> > Igor- alarms do not only mean "failure". Could it use alarm severity?
> > -- Kireeti - not an alarm situation.
> > -- Adrian - this is maintenance alarm => requires to scope the work
> > -- Igor - Tools already exist to trigger the same thing, the existing tools
> > are more powerful than this proposed one
> > -- Zafar - point to the capability of the mechanism having the
> > indication to
> > perform make-before-break - also suggest put on the list what you think are
> > alternative mechanisms
> > -- Lou Berger - says if we do this, we should use existing mechanisms such
> > as admin status or alarm (Arthi's suggested one, Igor's alarm admin
> > status).
> > -- Zafar - this mechanism is already in the spec - JP's re-optimization
> > draft
> > -- Lou - other mechanisms are in RFCs. We should decide on mechanisms
> > before
> > we accept as a WG draft.
> > -- Kireeti - step back from the solution, so the point is to write down
> > what
> > is to be achieved (take things out gracefully) -> need first to look at
> > requirements for what want to do.
> > -- Zafar - agreement
> > 7. Interdomain Framework - Adrian (5min)
> > <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework
> >
> > -00.txt>
> > -- Minor changes since last time, but published as WG draft
> > -- Applies to both MPLS and GMPLS, but currently limited to simpler
> > functions for initial work
> > -- Realize need more discussion on definition of "domain" e.g. Nested
> > domains, ensure GMPLS included. Will take to list for discussion.
> > -- This covers "simple" functions, what about "advanced" functions such as
> > diverse paths, mapping domain-specific constraints such as DiffServ,
> > pt-to-mpt, etc.?
> > -- Adrian's suggestion is to keep this separate for convenience.
> > -- Rahul - MPLS OAM - building blocks are in place, so it can go in this
> > document; P2MP is considerably less well understood.
> > -- Kireeti - what about GMPLS OAM?
> > -- Dimitri - need to understand what we mean by GMPLS OAM. Suggest phased
> > approach.
> > 8. Interdomain TE Requirements - Tomohiro Otani (5min)
> > <http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-01.t
> >
> > xt>
> > -- Joint proposal from NTT/KDDI, can be used for L1VPN, MPLS-TE
> > -- Changes:  added section identifying the following general requirements
> > - EGP extensions for GMPLS
> > - GMPLS Inter-AS signaling, path calculation and recovery
> > - GMPLS interdomain TE management
> > -- Remaining issues:
> > - Investigate added load created by EGP extensions
> > - Investigate L1VPN, use of SRLG for consistency, rechartering impacts
> > - Propose WG document
> > - Zafar - recommended would be a good basis for inter-domain TE framework
> > -- Arthi- support effort, but has too many solutions-related aspects in it.
> > Also suggest separating requirements into signaling, routing and path
> > computation. Need to clarify what is meant by domain - refer to framework
> > document.
> > -- Dimitri - what about reachability information exchange?  Not addressed,
> > but will be an important aspect.
> > -- Adrian- this is solution, not requirements. Suggest to separate
> > requirements and solutions. General approval of the work, but need to
> > remove
> > solutions. Should consider reachability as well as TE aspects.  Restructure
> > as Arthi suggests.
> > -- Otani- agree, will separate
> > -- Kireeti summarizing: separate requirements from solution and structure:
> > signaling from routing (in part. reachability)
> > 9. Summarize Status and plans of PCE BOF (JP Vasseur) (5 minutes)
> > -- Scope issues
> > - No intent to come up with new interdomain routing paradigm
> > - Scoped applicability to a limited number of TE LSPs
> > - Scoped to a "simple" topology of ASes or areas
> > -- Previous BOF - clear requirements from many SPs and common theme of
> > problem - MPLS TE LSP path computation
> > -- Architecture - comments noted global picture needed, but no
> > standardization of architecture.  New revision to be submitted soon in the
> > meantime please comments!
> > -- Note agreed no intention to extend LDP, but possibly other protocols.
> > -- Agreed on proposed charter and milestones, proposal to be sent out early
> > next week.
> > -- Many in favor of new WG, none against - need IESG review and work on
> > charter
> > -- Bijan Jabbari - what scale of LSPs?
> > -- JP - no specific number, not full mesh - does this mean no scalability
> > concerns?
> > -- Adrian - need to make the problem manageable, at least initially.
> > -- Bijan - will WG be open to new architectures?
> > -- Kireeti - take this to the list.
> > -- Peter Toms - support this, lots of requests for this.
> > 10. Inter-Domain RSVP-TE extensions - Arthi Ayyangar (5min)
> > <http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-
> >
> > te-00.txt>
> > -- Changes - include separate section on stitching and required extensions,
> > clarifications for non-packet LSPs.
> > -- Request to make it a WG document - none against, but limited number
> > agreeing (note: not many read the draft)- list.
> > -- Adrian - stitching has wider applicability - should we pull it out
> > into a
> > separate draft?
> > 11. Diverse Inter-region Setup - D'Achille - presented by Adrian (5 min)
> > <http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-
> >
> > 04.txt>
> > -- Adrian not that familiar with this draft. Flags one slide on message
> > exchange where the head end is in the center rather than at the end. Notes
> > several claim, explicitly claim of no new protocol seems questionable as
> > new
> > objects are defined. Need further feedback.
> > Can't take questions as no authors present to discuss - take to list
> > 12. Related to 11.  Protection for Inter-AS tunnels - Decnodder - Cristel
> > Pelsser
> > <http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas-protectio
> >
> > n-00.txt>
> > -- Differs from 11, addresses requirements from TEWG draft
> > -- Uses RSVP-TE and FRR
> > -- Adds clarifications on SRLG scope, assumed to correspond to a single AS
> > -- Looking for feedback, how to generalize to GMPLS
> > -- Adrian - need to apply to GMPLS if you want the draft to be in this
> > group.
> > -- Zafar - SRLG issue - need to solve the scooping issue, applies in a
> > number of places.
> > -- Adrian - WG should look at a framework for diverse paths, including PCE.
> > -- Zafar - needs more discussion to understand, and already work in MPLS WG
> > on ABR protection.
> > -- Adrian - authors can continue draft, would also like for CCAMP to
> > evaluate if PCE is appropriate, or something else
> > -- JP - should include the PCE mailing list on this.
> > -- Adrian - need discussion on the ccamp list.
> > 13. Requirements for multi-region - Kohei Shiomoto
> > <http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-requirem
> >
> > ents-00.txt>
> > -- Region defined based on switching capability - note region is control
> > plane, layer is data plane
> > -- Addresses pre-provisioned FA, triggered FA and no FA cases.  Plain and
> > hybrid type nodes.
> > -- Architecture has generated requirements and solutions drafts
> > -- Virtual network topology, application example
> > -- Propose as WG document.
> > -- Adrian - handling regions are in scope of CCAMP.
> > -- Adrian - asks Dimitri to immediately present the extensions then we will
> > take questions
> > <http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-extensio
> >
> > ns-00.txt>
> > -- TE metric inheritance - how to inherit or map metrics
> > -- How is recovery abstracted for an FA - e.g., end2end vs. span protected?
> > -- Reconvergence of VNT
> > -- Handling multiple switching and adaptation capabilities
> > -- Zafar - is this a good idea from TE point of view - dynamic FA
> > creation -
> > need applicability statement - potential bandwidth segmentation issues -
> > may
> > lose aggregation that you would normally get at the boundary - could add
> > oscillation.  If still considered a good idea, should it be triggered by
> > signaling or some other mechanism?  Document needs to list concerns.
> > -- Arthi - some parts of requirements still not clear - what is needed
> > outside of the LSP hierarchy draft?  Need to clarify what is missing from
> > the existing, and reference where it's covered by existing documents.
> > Don't
> > want to reinvent terminology.  Regarding virtual FA setup can be
> > pre-provisioned or on demand - hierarchy draft already says this, should
> > not
> > be in the requirements document but only in the solutions document.
> > Regarding protection - more work needs to be done in the requirements.
> > -- Igor - region, layer, hierarchy level are treated interchangeably in the
> > draft, confusing.  Regarding stitching, this is a very general capability
> > and should be in LSP hierarchy instead. Kireeti - thinks this should have a
> > separate document.
> > -- Adrian - more clarification would be good on layer/region
> > -- Jonathan Sadler - good stuff in general, agree with the goal.
> > Concern is
> > that IETF framework is not well aligned to ITU concept of layered network
> > (G.805).  It would be good to take into account the ITU framework.  Work on
> > extensions is premature at this time.
> > -- Deborah Brungard - authors intended to handle multiple layers as in ITU
> > (e.g. G.805) - limited to single domain for now, should be addressed to
> > GMPLS RFCs. Not intended to discuss data plane concepts. Request for more
> > specific comments.
> >
> > 14. MPLS-to-GMPLS Migration - Kohei Shiomoto
> > <http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-0
> >
> > 4.txt>
> > -- Evolution from legacy MPLS to GMPLS -
> > -- Differences: architecture (C/D separation, bidirectionality, P&R);
> > routing (opaque LSA); signaling (new objects, messages)
> > -- Propose WG document
> > -- Kireeti - question on whether this is in scope - address on charter
> > -- Zafar - multi-layer comments also apply here.
> > -- Richard Rabbat - supports the work, suggests looking at odd numbers
> > rather than even.
> > -- Ping Pan - how does this differ from the overlay model?
> > -- Kireeti - different, take this to the list.
> > 15. L1 VPN - Tomonori Takeda (10 Min)
> > <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt>
> > <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt
> >
> >
> >>
> > <http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05
> >
> > .txt>
> > <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt>
> > -- Mailing list - www1.ietf.org/mailman/listinfo/l1vpn
> > -- Two drafts applicable, ouldbrahim and overlay - guidelines for
> > enhancement, deployment scenaros - added terminology refinement, security
> > considerations, service models
> > -- Further comments solicited, planning further liaison to SG13.
> > -- Applicability draft examines existing GMPLS protocols for L1 VPN
> > services. Has added Deborah as co-author.
> > -- Concept - set up FA LSP between PEs, use stitching to connect this to
> > CEs.
> > -- Propose to adopt as CCAMP charter item.
> > -- Kireeti - supports applicability draft.  Liaison with ITU is very
> > important - we need to be responsive.  We will discuss this item as part of
> > the extension of the CCAMP charter
> > 16. Signaling for L2 LSPs - Dimitri Papadimitriou (10 minutes)
> > <http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-ls
> >
> > p-03.txt>
> > -- ATM, FR, ETH, etc.  Defines label request processing, label semantics,
> > added security section.
> > -- Security - threats analysis, attacks on the data plane, L2 LSP
> > signaling,
> > attacks on control plane
> > -- Ask for WG draft, no plan to respin
> > -- Dave Allan - Question on Ethernet VLAN tag swapping - not defined in
> > IEEE.
> > -- Dimitri- intended to cover GMPLS scope, not data plane.  Should not
> > assume tag is per port unique.
> > -- Don Fedyk - is this P2P?
> > -- Dimitri - Yes (as starting point).
> > -- Kireeti - ok, we have a fair consensus, so I would say it's a rough
> > consensus point. We will take this to the list, Dave and Dimitri to work
> > out
> > VLAN issue.
> > -- Note that an MPLS group draft on L2 has come up
> > 17. Mesh Carrier Survey - Richard Rabbat (5 min)
> > <http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-01.tx
> >
> > t>
> > -- Initially 7 carriers polled, open to others
> > -- Also surveys GMPLS control plane deployment
> > -- 1 has deployed, 3 within 2-3 years, 3 with no current plans
> > -- Concerns with stability, signaling storms
> > -- Asking for feedback, new carrier input
> > -- Richard - review slides, recommend for CCAMP WG to begin work on shared
> > mesh restoration performance
> > 18. Milestone and Charter discussion - Kireeti
> > -- Current activities winding down, esp. P&R, ASON
> > -- Others underway, esp. multi-domain
> > -- New: migration, VPNs, control plane resilience, addressing,
> > implementation experience, GTTP (?)
> > -- Migration
> > - GMPLS supersets MPLS, but some objects are different - label request,
> > label, upstream label
> > - Need BCP on smooth migration, what issues may occur
> > -- L1 VPN
> > - Should IETF do this?  Should it be in CCAMP?  Tied to UNI and Interdomain
> > signaling
> > -- Control plane resilience - includes graceful restart but also more
> > -- Addressing - transport networks use different kinds of addresses - need
> > decoder ring for mapping transport network address types to IP addresses -
> > Kireeti considers this useful
> > -- Interop results - note that addressing pops up there as well.  BCPs
> > would
> > be helpful.
> > -- Send out request for new work items, replies due Friday 11/19.
> > -- Send out checks for consensus on each item, replies due Friday 12/3
> > -- Send resulting list to A-Ds, trimmed if necessary, add appropriate
> > milestones
> > -- Consensus is a requirement but not a guarantee.
> > -- Lou - how about dropping something from the existing charter -
> > -- Kireeti - maybe GTTP - Lou - should note on the list also things that
> > may
> > be dropped if no support.
> > -- Alex - about L1 VPNs - is this research work, or practical?  Need at
> > least one implementation - is anyone implementing this within a year or
> > two?
> > -- Dimitri - Solutions exist provided by vendors today, but no common
> > framework.  Timeframe for implementation is 18-24 months.
> > -- Alex reminds the group of the need for running code.
> > -- Adrian - what about informational draft on how to use existing functions
> > to do the service?  Is there any interest from the research groups or the
> > real carrier deployment groups?
> > -- Tomonori Takeda - NTT has interest, but not sure of protocols.
> > Timeframe
> > - cannot say.  Testing is done.
> > -- Yakov Rekhter- vendors cannot disclose future product plans...
> > -- Deborah Brungard - carriers also cannot disclose plans, will see
> > interest
> > by number of co-authors.
> > -- Kireeti - have had carriers ask for this technology.  We don't have all
> > the pieces, but have implemented many of them, and as a vendor would
> > like to
> > see a solution on how to do. Answer to Alex is yes.
> > -- Richard Rabbat - could add this to his survey.
> > -- Kireeti supports this.
> > MEETING IS ADJOURNED.
> >
> >
> > .
> >
>
>
>
>

Delivery-date: Sat, 04 Dec 2004 21:22:16 +0000
Date: Sat, 04 Dec 2004 22:20:28 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked],  [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC:  [email-masked]
Subject: Re: Draft minutes from Tove

hi adrian,

a small comment:

> Adrian - Note: Node_Id based Hello has not been updated before
> deadline

i mentioned that the update of the Node_Id based Hello document has been 
effectively submitted before the deadline

thanks,
- dimitri.

Adrian Farrel wrote:

> Hi ccamp!
> Thanks to Lyndon Ong, Deborah Brungard, and Dimitri Papadimitriou we
> can now read about the ccamp meeting, IETF61.
> Please provide your comments no later than 3rd December if you miss any
> important wording (or you like to change the complete meeting;-)
> / Tove
> Tove Madsen
> Acreo AB
> [email-masked]
> ===
> 61st IETF CCAMP Minutes
> 11/11/2004
> Minutes taken by
> Lyndon Ong, Deborah Brungard, Dimitri Papadimitriou
> 
> 1. Admin and agenda bash - Chairs (5 min)
> Agenda bashing - no changes
> 2. Status of WG drafts - Adrian (10 min)
> Drafts - now unblocked, however the removal of the MPLS bundling draft has
> caused another snag. We have got two new RFCs, Architecture (3945) and
> SONET/SDH Extensions (3946).  Six drafts are in the queue.  Five are in 
> IETF
> Last Call, two are in IESG review.  15 active drafts - if you want a draft
> adopted as WG draft, let's finish these first!  Tunnel trace in particular
> seems to have very little interest - will be discussed wrt to rechartering.
> Overall status: almost all milestones completed, should recharter or close
> in March '04!
> Lou - slide does not list all 15 drafts - others are still active? In
> particular Alarm_Spec
> Adrian said no intention to exclude, asked if implementation on alarm 
> draft,
> Lou said at least one, possibly two, Kireeti said only need one, so Ok 
> to go
> forward.
> Adrian - Note: Node_Id based Hello has not been updated before deadline
> Adrian - Milestones and re-chartering will be covered at the end of the
> meeting.
> 3. Link Bundling - Zafar Ali
> -- Issues with current RFCs and drafts
> -- Draft removed from the RFC editor's queue
> -- Issues with scooping type 4/5 TLVs for IF_ID_RSVP_HOP and
> IF_ID_ERROR_SPEC, also recording of route
> -- Plan to address first two issues in an updated draft but component link
> recording will remain outside the scope of the bundling draft.  Will allow
> but recommend against use of types 4/5.
> -- Work on recording/explicit control will be done in a separate ID.  Home
> in MPLS or CCAMP?
> -> see slides
> -- Plans
> Pulled from queue (reviewed slides)
> -- Adrian: procedure -> MPLS WG own document. Do review on what happens in
> this WG
> Note: speed is really important as we have multiple blocking documents in
> the CCAMP WG queue.
> -- Kireeti - this is not free for all on the bundling draft - change to be
> proposed and to be sent on the list (delta only)
> George: as MPLS chair, MPLS group plans to do updates quickly - considered
> as last call comments
> 
> 4. ASON Signaling Solutions - Dimitri P (5min)
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02. 
> 
> txt>
> <http://www.olddog.co.uk/draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt> 
> 
> -- Mention OIF response is on the way
> -- ASON signaling - no updates but lots of thinking esp. call setup message
> naming (Notify vs. specialized message), desire not to "piggyback" call
> information in the connection message.  Expect finalized draft around
> Christmas time.
> -- ASON routing solutions design team
> - Evaluation of common "pattern" has taken time, evaluation document should
> be issued by end- November.
> - Model shown - use of terminology - what is TE Router ID, what is OSPF
> Router ID?
> - Further considerations - control plane does not transport the actual
> transport plane ids, but its view of the transport plane, using an
> associated IP addressing space.
> - No internal structure is associated with an abstract node.
> - Hierarchy focus is on exchange of information between peers.
> - Representation of bandwidth needs further thought.
> -- Adrian - it seems the DT has been making good progress, CCAMP WG has
> unfortunately not been aware of the progress, progress must be shown to the
> group by either sending status or updating the draft.
> -- Dimitri - will mail to the list.
> -- Zafar - how does this work relate to the OSPF and ISIS groups?
> -- DP - we are evaluating what may be missing, after this evaluation we can
> address protocol-specific issues.
> -- Zafar - Are you looking at existing mechanisms?
> -- Dimitri - global applicability is next step, currently looking at what
> info is exchanged
> 
> 5. ITU Liaison - Lyndon Ong
> -- ITU continues to be interested in converging the work on signaling and
> routing
> -- ITU thanks CCAMP for its liaisons, and esp. Adrian for attending the 
> last
> Q14 meeting
> -- ITU is currently working on ASON management specifications and thanks
> CCAMP for its liaison of the GMPLS MIB work for its review
> -- Zafar - can we also have a report of OIF status?  Chairs and LO; 
> there is
> nothing formal to report at this time that's why it was not scheduled on 
> the
> agenda.  However, liaisons will be sent to the mailing list for everyone's
> review, and if something formal is made available, it will be scheduled.
> -- Lyndon - there is ongoing discussion and communication just sent back to
> IETF
> -- Adrian - but not there yet (not available)
> -- Lyndon - is there a need for a permanent liaison from the OIF at the
> CCAMP meeting?
> -- Adrian - if there is something to be discussed it will be considered 
> on a
> per-request/per-case basis
> 6. Graceful Shutdown - Zafar Ali (10 min)
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-0 
> 
> 0.txt
> -- Intention is to support a planned shutdown, e.g., for maintenance
> purposes
> -- IGP based solution does not cover Inter-AS/Area scenarios
> -- RSVP-based solution does not convey information to all nodes in the
> network.
> -- Both mechanisms must complement each other
> -- Use existing sub-code of the Path Error message, then perform
> make-before-break for the LSP. Proposed changes are minor and based on
> existing framework.
> -- Would like to propose this ID as a WG document
> Rahul- is this intra or inter?  inter-domain can use hierarchy of LSPs
> (nesting/stitching) to achieve this isolation.
> -- Zafar - though recognize two mechanisms
> -- Rahul- we should clarify these aspects, as well as inter-domain TE
> aspects.
> -- Zafar - can add these aspects in the document
> -- Richard Rabbat - why is this GMPLS rather than MPLS?
> Zafar - could be shutting down any type of link.
> -- Adrian - in terms of problem space it is needed in both cases
> -- Igor Bryskin - this is a data plane problem followed by rerouting - why
> don't we use existing mechanisms such as propagating alarms?
> Zafar - distinguish this from alarms as this is not something that requires
> an immediate reroute. This is not intended to tackle data plane alarms
> -- Kireeti - maintenance of the link/node - out-of-service issue is to get
> traffic out of the link
> Igor- alarms do not only mean "failure". Could it use alarm severity?
> -- Kireeti - not an alarm situation.
> -- Adrian - this is maintenance alarm => requires to scope the work
> -- Igor - Tools already exist to trigger the same thing, the existing tools
> are more powerful than this proposed one
> -- Zafar - point to the capability of the mechanism having the 
> indication to
> perform make-before-break - also suggest put on the list what you think are
> alternative mechanisms
> -- Lou Berger - says if we do this, we should use existing mechanisms such
> as admin status or alarm (Arthi's suggested one, Igor's alarm admin 
> status).
> -- Zafar - this mechanism is already in the spec - JP's re-optimization
> draft
> -- Lou - other mechanisms are in RFCs. We should decide on mechanisms 
> before
> we accept as a WG draft.
> -- Kireeti - step back from the solution, so the point is to write down 
> what
> is to be achieved (take things out gracefully) -> need first to look at
> requirements for what want to do.
> -- Zafar - agreement
> 7. Interdomain Framework - Adrian (5min)
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework 
> 
> -00.txt>
> -- Minor changes since last time, but published as WG draft
> -- Applies to both MPLS and GMPLS, but currently limited to simpler
> functions for initial work
> -- Realize need more discussion on definition of "domain" e.g. Nested
> domains, ensure GMPLS included. Will take to list for discussion.
> -- This covers "simple" functions, what about "advanced" functions such as
> diverse paths, mapping domain-specific constraints such as DiffServ,
> pt-to-mpt, etc.?
> -- Adrian's suggestion is to keep this separate for convenience.
> -- Rahul - MPLS OAM - building blocks are in place, so it can go in this
> document; P2MP is considerably less well understood.
> -- Kireeti - what about GMPLS OAM?
> -- Dimitri - need to understand what we mean by GMPLS OAM. Suggest phased
> approach.
> 8. Interdomain TE Requirements - Tomohiro Otani (5min)
> <http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-01.t 
> 
> xt>
> -- Joint proposal from NTT/KDDI, can be used for L1VPN, MPLS-TE
> -- Changes:  added section identifying the following general requirements
> - EGP extensions for GMPLS
> - GMPLS Inter-AS signaling, path calculation and recovery
> - GMPLS interdomain TE management
> -- Remaining issues:
> - Investigate added load created by EGP extensions
> - Investigate L1VPN, use of SRLG for consistency, rechartering impacts
> - Propose WG document
> - Zafar - recommended would be a good basis for inter-domain TE framework
> -- Arthi- support effort, but has too many solutions-related aspects in it.
> Also suggest separating requirements into signaling, routing and path
> computation. Need to clarify what is meant by domain - refer to framework
> document.
> -- Dimitri - what about reachability information exchange?  Not addressed,
> but will be an important aspect.
> -- Adrian- this is solution, not requirements. Suggest to separate
> requirements and solutions. General approval of the work, but need to 
> remove
> solutions. Should consider reachability as well as TE aspects.  Restructure
> as Arthi suggests.
> -- Otani- agree, will separate
> -- Kireeti summarizing: separate requirements from solution and structure:
> signaling from routing (in part. reachability)
> 9. Summarize Status and plans of PCE BOF (JP Vasseur) (5 minutes)
> -- Scope issues
> - No intent to come up with new interdomain routing paradigm
> - Scoped applicability to a limited number of TE LSPs
> - Scoped to a "simple" topology of ASes or areas
> -- Previous BOF - clear requirements from many SPs and common theme of
> problem - MPLS TE LSP path computation
> -- Architecture - comments noted global picture needed, but no
> standardization of architecture.  New revision to be submitted soon in the
> meantime please comments!
> -- Note agreed no intention to extend LDP, but possibly other protocols.
> -- Agreed on proposed charter and milestones, proposal to be sent out early
> next week.
> -- Many in favor of new WG, none against - need IESG review and work on
> charter
> -- Bijan Jabbari - what scale of LSPs?
> -- JP - no specific number, not full mesh - does this mean no scalability
> concerns?
> -- Adrian - need to make the problem manageable, at least initially.
> -- Bijan - will WG be open to new architectures?
> -- Kireeti - take this to the list.
> -- Peter Toms - support this, lots of requests for this.
> 10. Inter-Domain RSVP-TE extensions - Arthi Ayyangar (5min)
> <http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp- 
> 
> te-00.txt>
> -- Changes - include separate section on stitching and required extensions,
> clarifications for non-packet LSPs.
> -- Request to make it a WG document - none against, but limited number
> agreeing (note: not many read the draft)- list.
> -- Adrian - stitching has wider applicability - should we pull it out 
> into a
> separate draft?
> 11. Diverse Inter-region Setup - D'Achille - presented by Adrian (5 min)
> <http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup- 
> 
> 04.txt>
> -- Adrian not that familiar with this draft. Flags one slide on message
> exchange where the head end is in the center rather than at the end. Notes
> several claim, explicitly claim of no new protocol seems questionable as 
> new
> objects are defined. Need further feedback.
> Can't take questions as no authors present to discuss - take to list
> 12. Related to 11.  Protection for Inter-AS tunnels - Decnodder - Cristel
> Pelsser
> <http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas-protectio 
> 
> n-00.txt>
> -- Differs from 11, addresses requirements from TEWG draft
> -- Uses RSVP-TE and FRR
> -- Adds clarifications on SRLG scope, assumed to correspond to a single AS
> -- Looking for feedback, how to generalize to GMPLS
> -- Adrian - need to apply to GMPLS if you want the draft to be in this
> group.
> -- Zafar - SRLG issue - need to solve the scooping issue, applies in a
> number of places.
> -- Adrian - WG should look at a framework for diverse paths, including PCE.
> -- Zafar - needs more discussion to understand, and already work in MPLS WG
> on ABR protection.
> -- Adrian - authors can continue draft, would also like for CCAMP to
> evaluate if PCE is appropriate, or something else
> -- JP - should include the PCE mailing list on this.
> -- Adrian - need discussion on the ccamp list.
> 13. Requirements for multi-region - Kohei Shiomoto
> <http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-requirem 
> 
> ents-00.txt>
> -- Region defined based on switching capability - note region is control
> plane, layer is data plane
> -- Addresses pre-provisioned FA, triggered FA and no FA cases.  Plain and
> hybrid type nodes.
> -- Architecture has generated requirements and solutions drafts
> -- Virtual network topology, application example
> -- Propose as WG document.
> -- Adrian - handling regions are in scope of CCAMP.
> -- Adrian - asks Dimitri to immediately present the extensions then we will
> take questions
> <http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-extensio 
> 
> ns-00.txt>
> -- TE metric inheritance - how to inherit or map metrics
> -- How is recovery abstracted for an FA - e.g., end2end vs. span protected?
> -- Reconvergence of VNT
> -- Handling multiple switching and adaptation capabilities
> -- Zafar - is this a good idea from TE point of view - dynamic FA 
> creation -
> need applicability statement - potential bandwidth segmentation issues - 
> may
> lose aggregation that you would normally get at the boundary - could add
> oscillation.  If still considered a good idea, should it be triggered by
> signaling or some other mechanism?  Document needs to list concerns.
> -- Arthi - some parts of requirements still not clear - what is needed
> outside of the LSP hierarchy draft?  Need to clarify what is missing from
> the existing, and reference where it's covered by existing documents.  
> Don't
> want to reinvent terminology.  Regarding virtual FA setup can be
> pre-provisioned or on demand - hierarchy draft already says this, should 
> not
> be in the requirements document but only in the solutions document.
> Regarding protection - more work needs to be done in the requirements.
> -- Igor - region, layer, hierarchy level are treated interchangeably in the
> draft, confusing.  Regarding stitching, this is a very general capability
> and should be in LSP hierarchy instead. Kireeti - thinks this should have a
> separate document.
> -- Adrian - more clarification would be good on layer/region
> -- Jonathan Sadler - good stuff in general, agree with the goal.  
> Concern is
> that IETF framework is not well aligned to ITU concept of layered network
> (G.805).  It would be good to take into account the ITU framework.  Work on
> extensions is premature at this time.
> -- Deborah Brungard - authors intended to handle multiple layers as in ITU
> (e.g. G.805) - limited to single domain for now, should be addressed to
> GMPLS RFCs. Not intended to discuss data plane concepts. Request for more
> specific comments.
> 
> 14. MPLS-to-GMPLS Migration - Kohei Shiomoto
> <http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-0 
> 
> 4.txt>
> -- Evolution from legacy MPLS to GMPLS -
> -- Differences: architecture (C/D separation, bidirectionality, P&R);
> routing (opaque LSA); signaling (new objects, messages)
> -- Propose WG document
> -- Kireeti - question on whether this is in scope - address on charter
> -- Zafar - multi-layer comments also apply here.
> -- Richard Rabbat - supports the work, suggests looking at odd numbers
> rather than even.
> -- Ping Pan - how does this differ from the overlay model?
> -- Kireeti - different, take this to the list.
> 15. L1 VPN - Tomonori Takeda (10 Min)
> <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt>
> <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt 
> 
> 
>>
> <http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05 
> 
> .txt>
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt>
> -- Mailing list - www1.ietf.org/mailman/listinfo/l1vpn
> -- Two drafts applicable, ouldbrahim and overlay - guidelines for
> enhancement, deployment scenaros - added terminology refinement, security
> considerations, service models
> -- Further comments solicited, planning further liaison to SG13.
> -- Applicability draft examines existing GMPLS protocols for L1 VPN
> services. Has added Deborah as co-author.
> -- Concept - set up FA LSP between PEs, use stitching to connect this to
> CEs.
> -- Propose to adopt as CCAMP charter item.
> -- Kireeti - supports applicability draft.  Liaison with ITU is very
> important - we need to be responsive.  We will discuss this item as part of
> the extension of the CCAMP charter
> 16. Signaling for L2 LSPs - Dimitri Papadimitriou (10 minutes)
> <http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-ls 
> 
> p-03.txt>
> -- ATM, FR, ETH, etc.  Defines label request processing, label semantics,
> added security section.
> -- Security - threats analysis, attacks on the data plane, L2 LSP 
> signaling,
> attacks on control plane
> -- Ask for WG draft, no plan to respin
> -- Dave Allan - Question on Ethernet VLAN tag swapping - not defined in
> IEEE.
> -- Dimitri- intended to cover GMPLS scope, not data plane.  Should not
> assume tag is per port unique.
> -- Don Fedyk - is this P2P?
> -- Dimitri - Yes (as starting point).
> -- Kireeti - ok, we have a fair consensus, so I would say it's a rough
> consensus point. We will take this to the list, Dave and Dimitri to work 
> out
> VLAN issue.
> -- Note that an MPLS group draft on L2 has come up
> 17. Mesh Carrier Survey - Richard Rabbat (5 min)
> <http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-01.tx 
> 
> t>
> -- Initially 7 carriers polled, open to others
> -- Also surveys GMPLS control plane deployment
> -- 1 has deployed, 3 within 2-3 years, 3 with no current plans
> -- Concerns with stability, signaling storms
> -- Asking for feedback, new carrier input
> -- Richard - review slides, recommend for CCAMP WG to begin work on shared
> mesh restoration performance
> 18. Milestone and Charter discussion - Kireeti
> -- Current activities winding down, esp. P&R, ASON
> -- Others underway, esp. multi-domain
> -- New: migration, VPNs, control plane resilience, addressing,
> implementation experience, GTTP (?)
> -- Migration
> - GMPLS supersets MPLS, but some objects are different - label request,
> label, upstream label
> - Need BCP on smooth migration, what issues may occur
> -- L1 VPN
> - Should IETF do this?  Should it be in CCAMP?  Tied to UNI and Interdomain
> signaling
> -- Control plane resilience - includes graceful restart but also more
> -- Addressing - transport networks use different kinds of addresses - need
> decoder ring for mapping transport network address types to IP addresses -
> Kireeti considers this useful
> -- Interop results - note that addressing pops up there as well.  BCPs 
> would
> be helpful.
> -- Send out request for new work items, replies due Friday 11/19.
> -- Send out checks for consensus on each item, replies due Friday 12/3
> -- Send resulting list to A-Ds, trimmed if necessary, add appropriate
> milestones
> -- Consensus is a requirement but not a guarantee.
> -- Lou - how about dropping something from the existing charter -
> -- Kireeti - maybe GTTP - Lou - should note on the list also things that 
> may
> be dropped if no support.
> -- Alex - about L1 VPNs - is this research work, or practical?  Need at
> least one implementation - is anyone implementing this within a year or 
> two?
> -- Dimitri - Solutions exist provided by vendors today, but no common
> framework.  Timeframe for implementation is 18-24 months.
> -- Alex reminds the group of the need for running code.
> -- Adrian - what about informational draft on how to use existing functions
> to do the service?  Is there any interest from the research groups or the
> real carrier deployment groups?
> -- Tomonori Takeda - NTT has interest, but not sure of protocols.  
> Timeframe
> - cannot say.  Testing is done.
> -- Yakov Rekhter- vendors cannot disclose future product plans...
> -- Deborah Brungard - carriers also cannot disclose plans, will see 
> interest
> by number of co-authors.
> -- Kireeti - have had carriers ask for this technology.  We don't have all
> the pieces, but have implemented many of them, and as a vendor would 
> like to
> see a solution on how to do. Answer to Alex is yes.
> -- Richard Rabbat - could add this to his survey.
> -- Kireeti supports this.
> MEETING IS ADJOURNED.
> 
> 
> .
> 

Delivery-date: Sat, 04 Dec 2004 19:07:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ugo Monaco" <[email-masked]>
Cc: <[email-masked]>, "Vishal Sharma" <[email-masked]>, "Alessio D'Achille" <[email-masked]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[email-masked]>, "Marco Listanti" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: Re: Draft minutes from Tove
Date: Sat, 4 Dec 2004 18:39:50 -0000

Hi Ugo,

Thanks for your comments.

> Hi Adrian and all,
> just some notes about the minutes from Tove:
>
>  > 11. Diverse Inter-region Setup - D'Achille - presented by Adrian (5 min)
>  >
> <http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-
>  > 04.txt>
>  > -- Adrian not that familiar with this draft. Flags one slide on message
>  > exchange where the head end is in the center rather than at the end.
>
> In the presentation
>
(http://home.clara.net/olddog/61/draft-achille-diverse-inter-region-path-setup-01-v3.ppt)
> slide 3 the figure is actually correct because it illustrates the same
> node (head-end) on two sides of the source, to show how the ARO can be
> flipped to become the ERO.

Noted. In fact, my comment at the meeting was not to claim that there was an error in the
slide, but to draw people's attention to what was going on in the slide.

>  > 12. Related to 11.  Protection for Inter-AS tunnels - Decnodder - Cristel
>  > Pelsser
>  >
> <http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas-protectio
>  > n-00.txt>
>  > -- Differs from 11, addresses requirements from TEWG draft
>
> We want stress that ARO addresses requirements from the TEWG draft too

OK. This is a punctuation error in the minutes.

"-- Differs from 11, addresses requirements from TEWG draft"

should read

"-- Differs from 11
 --Addresses requirements from TEWG draft"

We will update the minutes.

> (draft-ietf-tewg-interas-mpls-te-req-09.txt), in particular is in
> accordance with Section:
>
> 5.1.1. Inter-AS MPLS TE Operations and Interoperability
> 5.1.5.  Re-optimization
> 5.1.8. Scalability and Hierarchical LSP Support
> 5.1.11. Extensibility
> 6. Security Considerations
>
> This was also the basis on which we got some good feedback
> from the service provider community in the extensive discussions
> before, during, and after Seoul.
> May be we need to better point out this issue in the next version of the
> draft.
>
> Finally the phrase "need further feedback" looks not clear, who needs
> feedback? -the list or the authors ?-

Despite the fact that both drafts have been around for some while, the level of discussion
on the ccamp list has been quite low. I also have the impression that the interest in
implementation is not (yet) very strong. As the working group moves on to specify the
problem space that we are trying to resolve, I hope that we will see more debate about the
possible solutions with a view to arriving at a single set of protocol extensions.

Adrian

Delivery-date: Sat, 04 Dec 2004 18:43:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>, <[email-masked]>
Subject: Re: New Submission : Requirement for (G)MPLS implantation over Ethernet
Date: Sat, 4 Dec 2004 18:25:42 -0000

Hi Jaihyung,

I can see this draft in the repository at
http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lserequirement-00.txt

Adrian

> I am presenting a proposal for GMPLS implementation for Ethernet.
> The issue we are raising here is important to our industry.
> Your comments and contribution is valuable to us.
>
> Attached individual draft is submitted to ccamp many weeks ago.
> However, there has been some problem in submission process and
> it has never been fixed even after I raised problem tickets.

> I hope this problem be fixed and the document be stored in IETF
> web-site.
>
> Submission of this issue in CCAMP was discussed with chairs of MPLS
> and GMPLS several weeks ago. I believe this work is relevant to CCAMP
> scope.
>
> I am looking forward your comments.

Delivery-date: Sat, 04 Dec 2004 10:12:53 +0000
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>
From: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>
To: <[email-masked]>
Cc: 
Bcc: 
Date: Sat, 4 Dec 2004 19:10:51 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCC9w726xdu8s7DoxsAsILTjtOc=?=
Subject: New Submission : Requirement for (G)MPLS implantation over Ethernet
content-class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_0517_01C4DA34.4A7F2E60
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0518_01C4DA34.4A819F60"

------=_NextPart_001_0518_01C4DA34.4A819F60
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_001_0518_01C4DA34.4A819F60
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

<DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =B1=BC=B8=B2">
<DIV>&nbsp;</DIV>
<DIV>Dear All</DIV>
<DIV>&nbsp;</DIV>
<DIV>I am presenting a proposal for GMPLS implementation for =
Ethernet.</DIV>
<DIV>The issue we are raising here is important to our industry.</DIV>
<DIV>Your comments and contribution is valuable to us.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Attached individual draft is submitted to ccamp many weeks =
ago.</DIV>
<DIV>However, there has been some problem in submission process =
and</DIV>
<DIV>it has never been fixed even after I raised problem =
tickets.<BR></DIV>
<DIV>I hope this problem be fixed and the document be stored in IETF =
web-site.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Submission of this issue in CCAMP&nbsp;was discussed with chairs of =
MPLS</DIV>
<DIV>and GMPLS several weeks ago. I believe this work is relevant to =
CCAMP</DIV>
<DIV>scope.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I am looking forward your comments.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thank you</DIV>
<DIV>&nbsp;</DIV>
<DIV>Sincerely</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>
<DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =B1=BC=B8=B2">
<DIV>
<DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =B1=BC=B8=B2">
<DIV>Jaihyung Cho</DIV>
<DIV>ETRI, Korea</DIV>
<DIV>phone :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 042) 860-5514</DIV>
<DIV>oversea: +82-42-860-5514</DIV>
<DIV>fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+82-42-861=
-5550</DIV>
<DIV>&nbsp;</DIV>
<DIV>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</DIV>
<DIV>&nbsp;</DIV>
<DIV>Requirement for (G)MPLS implantation over Ethernet</DIV>
<DIV>&nbsp;</DIV>
<DIV>Abstract</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp; In this draft, we propose requirement to =
implement MPLS technology<BR>&nbsp;&nbsp;&nbsp;&nbsp; for Ethernet =
switched network. Ethernet has become major =
building<BR>&nbsp;&nbsp;&nbsp;&nbsp; block in local area network and the =
area of deployment is quickly<BR>&nbsp;&nbsp;&nbsp;&nbsp; expanding to =
core network. While there have been industry needs =
to<BR>&nbsp;&nbsp;&nbsp;&nbsp; overcome weakness of Ethernet, MPLS has =
not been considered as key<BR>&nbsp;&nbsp;&nbsp;&nbsp; technology to =
improve Ethernet. Currently MPLS [RFC3031] and =
GMPLS<BR>&nbsp;&nbsp;&nbsp;&nbsp; [GARCH] architecture do not define =
label-switching function on<BR>&nbsp;&nbsp;&nbsp;&nbsp; L2SC interface, =
i.e. over LAN media. Hence, it is necessary =
to<BR>&nbsp;&nbsp;&nbsp;&nbsp; discuss lightweight implementation of =
(G)MPLS for Ethernet. Since<BR>&nbsp;&nbsp;&nbsp;&nbsp; the requirements =
may different according to hierarchy of =
Ethernet,<BR>&nbsp;&nbsp;&nbsp;&nbsp; it is appropriate to separate =
solutions in Customer Premise Network<BR>&nbsp;&nbsp;&nbsp;&nbsp; (CPN), =
Access Network (AN) and Core Network (CN). Some candidate =
<BR>&nbsp;&nbsp;&nbsp;&nbsp; methods to consider for label encoding for =
Ethernet are discussed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></DIV></DIV></DIV></DIV></DIV><img =
style=3D"display:none" width=3D0 height=3D0 =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3Dccamp@ops.=
ietf.org&name=3Dccamp%40ops.ietf.org&fromemail=[email-masked]&mess=
ageid=[email-masked]%3E">
------=_NextPart_001_0518_01C4DA34.4A819F60--

------=_NextPart_000_0517_01C4DA34.4A7F2E60
Content-Type: application/octet-stream;
	name="draft-jaihyung-ccamp-lserequirement-00.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="draft-jaihyung-ccamp-lserequirement-00.txt"

------=_NextPart_000_0517_01C4DA34.4A7F2E60--

Delivery-date: Fri, 03 Dec 2004 23:16:43 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>
Subject: RE: New charter
Date: Fri, 3 Dec 2004 15:15:26 -0800

In no particular order:

1) MPLS-GMPLS migration
2) GMPLS interoperability issues & 6) Decoder ring for addresses
3a) should the IETF take on L1VPNs? Yes
3b) if yes to 3a, should this be done in CCAMP? Yes
8) PCE requirements
--
Thanks,
Richard.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kireeti Kompella
> Sent: Tuesday, November 23, 2004 10:22 PM
> To: [email-masked]
> Subject: New charter
> 
> 
> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
> 
> > If you have suggested charter updates, please send them to Adrian
> > and me.
> 
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
> 
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
> 
> 1) MPLS-GMPLS migration
> 2) GMPLS interoperability issues
> 3a) should the IETF take on L1VPNs?
> 3b) if yes to 3a, should this be done in CCAMP?
> 4) Waveband switching
> 5) Control plane work
> 6) Decoder ring for addresses
> 7) Deployment considerations for GMPLS
> 8) PCE requirements
> 9) QoS control
> 
> A rough idea of what each of the above entails follows.
> 
> 1) MPLS-GMPLS migration
> 	implementation shift from "MPLS" objects to "GMPLS" objects
> 	BCP on deployment migration for the same
> 
> 2) GMPLS interoperability issues
> 	what addresses to use where
> 	nits/clarifications of the specs
> 	guidelines for path computation & constraints
> 	survay
> 
> 3) L1VPN work items
> 	identify protocol extensions needed
> 	state what can already be done with what we have
> 	do the actual protocol work for requirements that are not met
> 	liaisons to SG13 as needed
> 
> 5) Control plane work
> 	resiliency
> 	graceful shutdown
> 
> 6) Decoder ring for addresses
> 	for each address field, identify its nature and ITU equivalent
> 	(may overlap with part of (2))
> 
> 
> 4, 7-9 are obvious or have been elaborated on the mailing list.
> 
> Kireeti.
> -------
> 
> PS: The topic of GTTP has carefully been avoided.  More later.
> 
> 

Delivery-date: Fri, 03 Dec 2004 22:46:10 +0000
From: Payam Torab <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, [email-masked]
Subject: RE: New charter
Date: Fri, 3 Dec 2004 17:38:18 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4D988.C87F4982
Content-Type: text/plain;
	charset="iso-8859-1"

Kireeti-

In priority order,

2) GMPLS interoperability issues
1) MPLS-GMPLS migration
3) L1VPN
8) PCE requirements

Payam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Kireeti Kompella
Sent: Wednesday, November 24, 2004 1:22 AM
To: [email-masked]
Subject: New charter

On Mon, 15 Nov 2004, Kireeti Kompella wrote:

> If you have suggested charter updates, please send them to Adrian
> and me.

Thanks all for your input.  I have the following items; for each,
please say "Yes" (should be added to CCAMP charter), "No" (should not
be added) or "-" (don't care).  I'll remind you once again that not
all items will make it onto the new charter.

Please keep this subject line (simply reply to this mail).  The
deadline is Friday Dec 3, 17:00 PST.

1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3a) should the IETF take on L1VPNs?
3b) if yes to 3a, should this be done in CCAMP?
4) Waveband switching
5) Control plane work
6) Decoder ring for addresses
7) Deployment considerations for GMPLS
8) PCE requirements
9) QoS control

A rough idea of what each of the above entails follows.

1) MPLS-GMPLS migration
	implementation shift from "MPLS" objects to "GMPLS" objects
	BCP on deployment migration for the same

2) GMPLS interoperability issues
	what addresses to use where
	nits/clarifications of the specs
	guidelines for path computation & constraints
	survay

3) L1VPN work items
	identify protocol extensions needed
	state what can already be done with what we have
	do the actual protocol work for requirements that are not met
	liaisons to SG13 as needed

5) Control plane work
	resiliency
	graceful shutdown

6) Decoder ring for addresses
	for each address field, identify its nature and ITU equivalent
	(may overlap with part of (2))

4, 7-9 are obvious or have been elaborated on the mailing list.

Kireeti.
-------

PS: The topic of GTTP has carefully been avoided.  More later.

------_=_NextPart_001_01C4D988.C87F4982
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>RE: New charter</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Kireeti-</FONT>
</P>

<P><FONT SIZE=3D2>In priority order,</FONT>
</P>

<P><FONT SIZE=3D2>2) GMPLS interoperability issues</FONT>
<BR><FONT SIZE=3D2>1) MPLS-GMPLS migration</FONT>
<BR><FONT SIZE=3D2>3) L1VPN</FONT>
<BR><FONT SIZE=3D2>8) PCE requirements</FONT>
</P>

<P><FONT SIZE=3D2>Payam</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]On</FONT>
<BR><FONT SIZE=3D2>Behalf Of Kireeti Kompella</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, November 24, 2004 1:22 AM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: New charter</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>On Mon, 15 Nov 2004, Kireeti Kompella wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; If you have suggested charter updates, please =
send them to Adrian</FONT>
<BR><FONT SIZE=3D2>&gt; and me.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks all for your input.&nbsp; I have the following =
items; for each,</FONT>
<BR><FONT SIZE=3D2>please say &quot;Yes&quot; (should be added to CCAMP =
charter), &quot;No&quot; (should not</FONT>
<BR><FONT SIZE=3D2>be added) or &quot;-&quot; (don't care).&nbsp; I'll =
remind you once again that not</FONT>
<BR><FONT SIZE=3D2>all items will make it onto the new charter.</FONT>
</P>

<P><FONT SIZE=3D2>Please keep this subject line (simply reply to this =
mail).&nbsp; The</FONT>
<BR><FONT SIZE=3D2>deadline is Friday Dec 3, 17:00 PST.</FONT>
</P>

<P><FONT SIZE=3D2>1) MPLS-GMPLS migration</FONT>
<BR><FONT SIZE=3D2>2) GMPLS interoperability issues</FONT>
<BR><FONT SIZE=3D2>3a) should the IETF take on L1VPNs?</FONT>
<BR><FONT SIZE=3D2>3b) if yes to 3a, should this be done in =
CCAMP?</FONT>
<BR><FONT SIZE=3D2>4) Waveband switching</FONT>
<BR><FONT SIZE=3D2>5) Control plane work</FONT>
<BR><FONT SIZE=3D2>6) Decoder ring for addresses</FONT>
<BR><FONT SIZE=3D2>7) Deployment considerations for GMPLS</FONT>
<BR><FONT SIZE=3D2>8) PCE requirements</FONT>
<BR><FONT SIZE=3D2>9) QoS control</FONT>
</P>

<P><FONT SIZE=3D2>A rough idea of what each of the above entails =
follows.</FONT>
</P>

<P><FONT SIZE=3D2>1) MPLS-GMPLS migration</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>implementation shift from &quot;MPLS&quot; objects to =
&quot;GMPLS&quot; objects</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>BCP on =
deployment migration for the same</FONT>
</P>

<P><FONT SIZE=3D2>2) GMPLS interoperability issues</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>what =
addresses to use where</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>nits/clarifications of the specs</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>guidelines for path computation &amp; constraints</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>survay</FONT>
</P>

<P><FONT SIZE=3D2>3) L1VPN work items</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>identify =
protocol extensions needed</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>state =
what can already be done with what we have</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>do the =
actual protocol work for requirements that are not met</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>liaisons =
to SG13 as needed</FONT>
</P>

<P><FONT SIZE=3D2>5) Control plane work</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>resiliency</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>graceful =
shutdown</FONT>
</P>

<P><FONT SIZE=3D2>6) Decoder ring for addresses</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>for each =
address field, identify its nature and ITU equivalent</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>(may =
overlap with part of (2))</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>4, 7-9 are obvious or have been elaborated on the =
mailing list.</FONT>
</P>

<P><FONT SIZE=3D2>Kireeti.</FONT>
<BR><FONT SIZE=3D2>-------</FONT>
</P>

<P><FONT SIZE=3D2>PS: The topic of GTTP has carefully been =
avoided.&nbsp; More later.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4D988.C87F4982--

Delivery-date: Fri, 03 Dec 2004 10:11:28 +0000
Date: Fri, 03 Dec 2004 11:09:26 +0100
From: Ugo Monaco <[email-masked]>
To:  [email-masked]
CC:  [email-masked], Vishal Sharma <[email-masked]>,  "Alessio D'Achille" <[email-masked]>, =?ISO-8859-1?Q?Daniele_Al=EC?= <[email-masked]>,  Marco Listanti <[email-masked]>
Subject: Re: Draft minutes from Tove

Hi Adrian and all,
just some notes about the minutes from Tove:

 > 11. Diverse Inter-region Setup - D'Achille - presented by Adrian (5 min)
 > 
<http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-
 > 04.txt>
 > -- Adrian not that familiar with this draft. Flags one slide on message
 > exchange where the head end is in the center rather than at the end.

In the presentation
(http://home.clara.net/olddog/61/draft-achille-diverse-inter-region-path-setup-01-v3.ppt)
slide 3 the figure is actually correct because it illustrates the same 
node (head-end) on two sides of the source, to show how the ARO can be
flipped to become the ERO.

WRT
 > 12. Related to 11.  Protection for Inter-AS tunnels - Decnodder - Cristel
 > Pelsser
 > 
<http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas-protectio
 > n-00.txt>
 > -- Differs from 11, addresses requirements from TEWG draft

We want stress that ARO addresses requirements from the TEWG draft too
(draft-ietf-tewg-interas-mpls-te-req-09.txt), in particular is in
accordance with Section:

5.1.1. Inter-AS MPLS TE Operations and Interoperability
5.1.5.  Re-optimization
5.1.8. Scalability and Hierarchical LSP Support
5.1.11. Extensibility
6. Security Considerations

This was also the basis on which we got some good feedback
from the service provider community in the extensive discussions
before, during, and after Seoul.
May be we need to better point out this issue in the next version of the
draft.

Finally the phrase "need further feedback" looks not clear, who needs
feedback? -the list or the authors ?-

Best Regards
Ugo Monaco

-- 
*********************************************************************
Ugo Monaco                                              INFOCOM Dept.
Ph.D. Student                                      Via Eudossiana, 18
Phone: +39-06-47825184                             00184 Roma (Italy)
E-mail: [email-masked]               Fax: +39-06-48930606
*********************************************************************

Delivery-date: Fri, 03 Dec 2004 07:17:18 +0000
Date: Fri, 03 Dec 2004 15:45:15 +0900
To: Kireeti Kompella <[email-masked]>
From: "[email-masked]" <[email-masked]>
Subject: Re: New charter
Cc: [email-masked]

Hello, here is my list.

1) MPLS-GMPLS migration, including 7) Deployment considerations for GMPLS

3a&b) both Yes

8) PCE requirements

2) GMPLS interoperability issues, maybe including 6) Decoder ring for addresses

If fifth is OK, 5) Control plane work

Thank you very much.

(Fax number has changed since Nov. 1st.)
************************************************
Ichiro Inoue (NTT NS $B8&(B $B%M%*(BG$B!!0f>e0lO:(B)
Senior Research Engineer, Supervisor
NTT Network Service Systems Labs
tel: +81-422-59-6076, fax: +81-422-59-3787
$B")(B180-8585$B!!IpB"Ln;TNPD.(B3-9-11 H11F
************************************************ 

Delivery-date: Thu, 02 Dec 2004 22:24:27 +0000
Date: Thu, 02 Dec 2004 10:12:02 -0500
To: "Kireeti Kompella" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: New charter
Cc: <[email-masked]>

Kireeti,
         In priority order:

0) Completion of existing work
    Including GMPLS ITU/ASON work

2&6) GMPLS interoperability issues
    (excludes "survay" as I have no idea what this is)
    Also note that (6) is also required by the ITU/ASON work

8) PCE requirements

3&9) L1VPNs (in ccamp or elsewhere)
    Also I suspect that the "QoS Control" problem is
    really just an aspect of L1VPNs.

"below the line items:"
>5) Control plane work
>1) MPLS-GMPLS migration
>7) Deployment considerations for GMPLS
     (BTW how does this differ from 1?)

Lou

Envelope-to: [email-masked]
Delivery-date: Wed, 01 Dec 2004 00:19:16 +0000
Message-ID: <B258A372CEA20246A363BB86753DB5360102F2EA@zrtphxm2>
From: "Don Fedyk" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: New charter
Date: Tue, 30 Nov 2004 19:17:28 -0500

Hi Kireeti

My top 4 (after improving the moral values of the Internet of course :)

1) MPLS-GMPLS migration 
2) GMPLS interoperability issues
3) L1VPNS
4) Decoder ring for addresses

Don