Response to ITU-T liaison on LMP transport terminology

["Adrian Farrel" <[e-mail]>]

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
([e-mail]) before 16th January so that he can take them as
contributions to the meeting.

Happy New Year,
Adrian





Envelope-to: [e-mail]
Delivery-date: Fri, 31 Dec 2004 21:35:08 +0000
Message-ID: <1c0a01c4ef80$5dbf0a70$9a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Response to ITU-T liaison on LMP transport terminology
Date: Fri, 31 Dec 2004 21:32:45 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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
([e-mail]) before 16th January so that he can take them as
contributions to the meeting.

Happy New Year,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 28 Dec 2004 16:58:27 +0000
Message-ID: <[e-mail]>
From: "Lam, Hing-Kam (Kam)" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, [e-mail]
Subject: RE: Meeting about ASON/GMPLS terminology
Date: Tue, 28 Dec 2004 11:56:39 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

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:[e-mail]/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:[e-mail]/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:[e-mail]/tsg15opticaltransport/wp3/q14/0501/wd/logistic.doc. 

Regards,
Kam

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Monday, December 27, 2004 3:11 PM
> To: [e-mail]; 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 
> ([e-mail]) 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
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 27 Dec 2004 21:29:50 +0000
Message-ID: <0a1801c4ec5a$0cc07dd0$9a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Lam, Hing-Kam (Kam)" <[e-mail]>
Subject: Meeting about ASON/GMPLS terminology
Date: Mon, 27 Dec 2004 20:11:07 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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 ([e-mail]) 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




Envelope-to: [e-mail]
Delivery-date: Fri, 24 Dec 2004 19:21:47 +0000
Message-Id: <6.1.2.0.2.20041222171104.03512db8@mo-ex1>
Date: Wed, 22 Dec 2004 17:17:52 -0500
To: "Loa Andersson" <[e-mail]>
From: Lou Berger <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: [e-mail], Bill Fenner <[e-mail]>, [e-mail], [e-mail]
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls



Envelope-to: [e-mail]
Delivery-date: Fri, 24 Dec 2004 19:21:38 +0000
Message-Id: <6.1.2.0.2.20041222171104.03512db8@mo-ex1>
Date: Wed, 22 Dec 2004 17:17:52 -0500
To: "Loa Andersson" <[e-mail]>
From: Lou Berger <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: [e-mail], Bill Fenner <[e-mail]>, [e-mail], [e-mail]
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls



Envelope-to: [e-mail]
Delivery-date: Thu, 23 Dec 2004 13:41:08 +0000
Message-ID: <045201c4e8f3$9a55aea0$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Mack-Crane, T. Benjamin" <[e-mail]>
Cc: <[e-mail]>, "Stephen J Trowbridge" <[e-mail]>
Subject: Re: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Thu, 23 Dec 2004 13:25:40 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Wed, 22 Dec 2004 22:26:44 +0000
Message-Id: <6.1.2.0.2.20041222171917.03e5c990@mo-ex1>
Date: Wed, 22 Dec 2004 17:26:11 -0500
To: <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-02.txt
Cc: "Igor Bryskin" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>, [e-mail], "Adrian Farrel" <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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)




Envelope-to: [e-mail]
Delivery-date: Wed, 22 Dec 2004 22:18:48 +0000
Message-Id: <6.1.2.0.2.20041222171104.03512db8@mo-ex1>
Date: Wed, 22 Dec 2004 17:17:52 -0500
To: "Loa Andersson" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: MPLS wg last call on re-spun bundling draft - ended
Cc: "Loa Andersson" <[e-mail]>, <[e-mail]>, "George Swallow" <[e-mail]>, "Alex Zinin" <[e-mail]>, "Bill Fenner" <[e-mail]>, <[e-mail]>, "Kireeti Kompella" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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)





Envelope-to: [e-mail]
Delivery-date: Wed, 22 Dec 2004 21:07:59 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Wed, 22 Dec 2004 15:06:00 -0600
Message-ID: <[e-mail]>
Thread-Topic: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
thread-index: AcTneP8uUv534h2eTmGHgf8O903F0AA6+KSA
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Stephen J Trowbridge" <[e-mail]>, <[e-mail]>

Adrian,

Please see comments in-line.

Regards,
Ben

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Tuesday, December 21, 2004 8:45 AM
> To: Mack-Crane, T. Benjamin; Stephen J Trowbridge; [e-mail]
> 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" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>; "Stephen J Trowbridge"
> <[e-mail]>; <[e-mail]>
> Cc: "Don Fedyk" <[e-mail]>;
<[e-mail]>;
> "Brungard, Deborah A, ALABS" <[e-mail]>; "Jonathan Lang"
> <[e-mail]>; "Dimitri Papadimitriou"
> <[e-mail]>
> 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,
> [e-mail]) by 10th January 2005."
>=20
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Adrian Farrel
> Sent: Friday, December 17, 2004 1:48 PM
> To: Stephen J Trowbridge; [e-mail]
> Cc: Don Fedyk; [e-mail]; 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" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>; "Don Fedyk" <[e-mail]>;
> <[e-mail]>; "Brungard, Deborah A, ALABS"
> <[e-mail]>; "Jonathan Lang" <[e-mail]>;
"Dimitri
> Papadimitriou" <[e-mail]>
> 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:[e-mail]/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



Envelope-to: [e-mail]
Delivery-date: Tue, 21 Dec 2004 17:27:01 +0000
Message-ID: <033401c4e77f$1d5a8170$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Incoming liaison (3) from ITU-T SG15
Date: Tue, 21 Dec 2004 16:36:56 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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:[e-mail]/tsg15opticaltransport/COMMUNICATIONS/index.html

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




Envelope-to: [e-mail]
Delivery-date: Tue, 21 Dec 2004 17:05:30 +0000
Message-ID: <033301c4e77f$11411fc0$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Incoming liaison (2) from ITU-T SG15
Date: Tue, 21 Dec 2004 16:27:20 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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, [e-mail])
by 10th January 2005.

An electronic copy of this liaison and the attachments can be found at
<ftp://sg15opticalt:[e-mail]/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]




Envelope-to: [e-mail]
Delivery-date: Tue, 21 Dec 2004 17:05:17 +0000
Message-ID: <033501c4e77f$260ff7a0$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Incoming liaison (4) from ITU-T SG15
Date: Tue, 21 Dec 2004 16:39:49 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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:[e-mail]/tsg15opticaltransport/COMMUNICATIONS/index.html




Envelope-to: [e-mail]
Delivery-date: Tue, 21 Dec 2004 17:05:05 +0000
Message-ID: <033201c4e77f$0722f1d0$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Incoming liaison (1) from ITU-T SG15
Date: Tue, 21 Dec 2004 16:17:44 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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:[e-mail]/tsg15opticaltransport/COMMUNICAT
IONS/index.html >





Envelope-to: [e-mail]
Delivery-date: Tue, 21 Dec 2004 16:22:43 +0000
Message-ID: <02cf01c4e776$c4831a60$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Mack-Crane, T. Benjamin" <[e-mail]>, "Stephen J Trowbridge" <[e-mail]>, <[e-mail]>
Subject: Re: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Tue, 21 Dec 2004 14:44:34 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; "Stephen J Trowbridge"
<[e-mail]>; <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>; <[e-mail]>;
"Brungard, Deborah A, ALABS" <[e-mail]>; "Jonathan Lang"
<[e-mail]>; "Dimitri Papadimitriou"
<[e-mail]>
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,
[e-mail]) by 10th January 2005."

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Friday, December 17, 2004 1:48 PM
To: Stephen J Trowbridge; [e-mail]
Cc: Don Fedyk; [e-mail]; 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" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "Don Fedyk" <[e-mail]>;
<[e-mail]>; "Brungard, Deborah A, ALABS"
<[e-mail]>; "Jonathan Lang" <[e-mail]>; "Dimitri
Papadimitriou" <[e-mail]>
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:[e-mail]/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
============================================================






Envelope-to: [e-mail]
Delivery-date: Mon, 20 Dec 2004 21:37:01 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Mon, 20 Dec 2004 15:35:29 -0600
Message-ID: <[e-mail]>
Thread-Topic: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
thread-index: AcTkcXrOtt8V4SElSmSs3XgwXzXgtACaAwZw
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Stephen J Trowbridge" <[e-mail]>, <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Jonathan Lang" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>

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,
[e-mail]) by 10th January 2005."

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Friday, December 17, 2004 1:48 PM
To: Stephen J Trowbridge; [e-mail]
Cc: Don Fedyk; [e-mail]; 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" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "Don Fedyk" <[e-mail]>;
<[e-mail]>; "Brungard, Deborah A, ALABS"
<[e-mail]>; "Jonathan Lang" <[e-mail]>; "Dimitri
Papadimitriou" <[e-mail]>
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:[e-mail]/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



Envelope-to: [e-mail]
Delivery-date: Mon, 20 Dec 2004 13:30:38 +0000
Message-ID: <[e-mail]>
Date: Mon, 20 Dec 2004 14:16:32 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Loa Andersson <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Cc: [e-mail], Bill Fenner <[e-mail]>, [e-mail]
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:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                            [e-mail]
> 

-- 
Loa Andersson

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

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



Envelope-to: [e-mail]
Delivery-date: Mon, 20 Dec 2004 13:30:32 +0000
Message-ID: <[e-mail]>
Date: Mon, 20 Dec 2004 14:16:32 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Loa Andersson <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Cc: [e-mail], Bill Fenner <[e-mail]>, [e-mail]
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:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                            [e-mail]
> 

-- 
Loa Andersson

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

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



Envelope-to: [e-mail]
Delivery-date: Mon, 20 Dec 2004 13:21:49 +0000
Message-ID: <[e-mail]>
Date: Mon, 20 Dec 2004 14:16:32 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Loa Andersson <[e-mail]>
CC: [e-mail], George Swallow <[e-mail]>, Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>, [e-mail]
Subject: MPLS wg last call on re-spun bundling draft - ended
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                            [e-mail]
> 

-- 
Loa Andersson

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



Envelope-to: [e-mail]
Delivery-date: Fri, 17 Dec 2004 19:48:49 +0000
Message-ID: <011d01c4e471$73e632c0$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Stephen J Trowbridge" <[e-mail]>, <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Jonathan Lang" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Subject: Re: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Fri, 17 Dec 2004 19:48:12 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "Don Fedyk" <[e-mail]>;
<[e-mail]>; "Brungard, Deborah A, ALABS"
<[e-mail]>; "Jonathan Lang" <[e-mail]>; "Dimitri
Papadimitriou" <[e-mail]>
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:[e-mail]/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).
> >
> >
> >
> >
> >
> >
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 17 Dec 2004 19:30:51 +0000
Message-ID: <011001c4e46e$e051cfd0$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>
Cc: "'Jean Philippe Vasseur'" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: Re: Stitching and inter-domain signaling
Date: Fri, 17 Dec 2004 19:30:09 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> > 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




Envelope-to: [e-mail]
Delivery-date: Fri, 17 Dec 2004 18:54:34 +0000
Message-ID: <[e-mail]>
Date: Fri, 17 Dec 2004 11:53:15 -0700
From: Stephen J Trowbridge <[e-mail]>
Organization: Lucent Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail], Don Fedyk <[e-mail]>, [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, Jonathan Lang <[e-mail]>, Dimitri Papadimitriou <[e-mail]>
Subject: Re: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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:[e-mail]/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).
> 
> 
> 
> 
> 
> 





Envelope-to: [e-mail]
Delivery-date: Fri, 17 Dec 2004 18:29:10 +0000
Message-ID: <00f901c4e466$443fb740$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Jonathan Lang" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Subject: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt
Date: Fri, 17 Dec 2004 18:22:41 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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).








Envelope-to: [e-mail]
Delivery-date: Fri, 17 Dec 2004 17:17:44 +0000
Message-ID: <00d801c4e45c$16df8cd0$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Jonathan Lang" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Subject: Chair review of draft-ietf-ccamp-tranport-lmp-00.txt
Date: Fri, 17 Dec 2004 17:13:11 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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









Envelope-to: [e-mail]
Delivery-date: Fri, 17 Dec 2004 14:34:58 +0000
Message-ID: <00c501c4e445$65c433d0$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Jonathan Lang" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Subject: id-nits output for draft-ietf-ccamp-tranport-lmp-00.txt
Date: Fri, 17 Dec 2004 14:07:03 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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.




Envelope-to: [e-mail]
Delivery-date: Fri, 17 Dec 2004 13:23:11 +0000
Message-ID: <00ba01c4e43b$6f04de90$4a849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Jonathan Lang" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Subject: Re: Working group last call on draft-ietf-ccamp-tranport-lmp-00.txt
Date: Fri, 17 Dec 2004 13:21:10 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: <[e-mail]>
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
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 16 Dec 2004 19:41:57 +0000
Date: Thu, 16 Dec 2004 11:38:21 -0800 (PST)
From: Arthi Ayyangar <[e-mail]>
To: Adrian Farrel <[e-mail]>
cc: "'Jean Philippe Vasseur'" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, [e-mail]
Subject: Re: Stitching and inter-domain signaling
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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
>



Envelope-to: [e-mail]
Delivery-date: Thu, 16 Dec 2004 16:00:00 +0000
Message-ID: <047001c4e388$2258d140$4f919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>, "'Jean Philippe Vasseur'" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: Stitching and inter-domain signaling
Date: Thu, 16 Dec 2004 15:54:27 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Fri, 10 Dec 2004 21:51:54 +0000
Message-Id: <[e-mail]>
From: "Baktha Muralidharan" <[e-mail]>
To: "'Bradford, Richard'" <[e-mail]>, "'Baktha Muralidharan'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Question on LMP Fault Localization
Date: Fri, 10 Dec 2004 16:50:31 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BB_01C4DED8.5C941F90"
Thread-Index: AcTe7yCt/M+Z+Q6rQ0CqlOKGfa3RGgAEGYOA

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Bradford, Richard
Sent: Friday, December 10, 2004 2:32 PM
To: Baktha Muralidharan
Cc: [e-mail]
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> [e-mail]=20
[mailto:[e-mail]] <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> [e-mail]<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--



Envelope-to: [e-mail]
Delivery-date: Fri, 10 Dec 2004 19:32:35 +0000
Message-Id: <[e-mail]>
Date: Fri, 10 Dec 2004 14:31:31 -0500
To: "Baktha Muralidharan" <[e-mail]>
From: "Bradford, Richard" <[e-mail]>
Subject: Re: Question on LMP Fault Localization
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_77757429==_.ALT"

--=====================_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--



Envelope-to: [e-mail]
Delivery-date: Fri, 10 Dec 2004 17:46:14 +0000
Message-Id: <[e-mail]>
From: "Baktha Muralidharan" <[e-mail]>
To: <[e-mail]>
Subject: Question on LMP Fault Localization
Date: Fri, 10 Dec 2004 12:44:38 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcTe3+t7LBeXrDBeQ4medva7kpvvXQ==

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.



Envelope-to: [e-mail]
Delivery-date: Fri, 10 Dec 2004 08:22:45 +0000
Content-Transfer-Encoding: 7bit
Thread-Topic: Addition to my question on LMP Adjacency
Thread-Index: AcTekUHjVDUFOaKmSg+/D5k+nd5Jmw==
Reply-To: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
From: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
To: <[e-mail]>
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=?=
Message-ID: <2071501c4de91$6186e0b0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_20716_01C4DEDC.D16E88B0"
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=[e-mail]&messag=
eid=3D%3C2071501c4de91$6186e0b0$[e-mail]%3E">
------=_NextPart_000_20716_01C4DEDC.D16E88B0--



Envelope-to: [e-mail]
Delivery-date: Fri, 10 Dec 2004 08:02:55 +0000
Message-ID: <009601c4de8e$aa7ce290$4f919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "=?ks_c_5601-1987?B?ob5loq+l7EWhqQ==?=" <[e-mail]>, <[e-mail]>
Subject: Re: Question on LMP Adjacency
Date: Fri, 10 Dec 2004 08:00:47 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01C4DE8E.5BC18CF0"

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" <[e-mail]>
To: "=A1=BEe=A2=AF=A5=ECE=A1=A9" <[e-mail]>; =
<[e-mail]>
Sent: Friday, December 10, 2004 7:29 AM
Subject: RE: Question on LMP Adjacency


> Question is not clear.
>=20
>  -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On =
Behalf Of
> =B1=E8=BF=B5=C8=AD
> Sent: Friday, December 10, 2004 12:37 PM
> To: [e-mail]
> 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:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>=20
[mailto:[e-mail]]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:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</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--




Envelope-to: [e-mail]
Delivery-date: Fri, 10 Dec 2004 07:53:09 +0000
Date: Fri, 10 Dec 2004 13:29:01 +0530
From: Harish M <[e-mail]>
Subject: RE: RE: Question on LMP Adjacency
To: =?iso-8859-1?B?sei/tcit?= <[e-mail]>, [e-mail]
Reply-to: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_ms8EbzYvxEPRPWPRq0zq4g)"

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:[e-mail]]
  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" <[e-mail]>
  ?? ??: 2004-12-10 ?? 4:29:21
  ?? ??: "±e¿?E­" <[e-mail]>, "[e-mail]"
<[e-mail]>
  ??:
  ??: RE: Question on LMP Adjacency


  Question is not clear.
   -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]On Behalf
Of ???
  Sent: Friday, December 10, 2004 12:37 PM
  To: [e-mail]
  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:[e-mail]]<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;[e-mail]&gt;<BR><B>?? ??:</B> =
2004-12-10 ??=20
  4:29:21<BR><B>?? ??:</B> "=B1e=BF?E&shy;" &lt;[e-mail]&gt;,=20
  "[e-mail]" &lt;[e-mail]&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> [e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of =
</B>???<BR><B>Sent:</B>=20
  Friday, December 10, 2004 12:37 PM<BR><B>To:</B>=20
  [e-mail]<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=
=[e-mail]&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=[e-mail].k=
r&amp;messageid=3D%3C1f04e01c4de86$e6d291c0$[e-mail]%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=[e-mail]&amp;messag=
eid=3D%3C1f64c01c4de8a$d8457420$[e-mail]%3E"=20
  width=3D0 NOSEND=3D"1"></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_ms8EbzYvxEPRPWPRq0zq4g)--



Envelope-to: [e-mail]
Delivery-date: Fri, 10 Dec 2004 07:23:42 +0000
Date: Fri, 10 Dec 2004 12:59:21 +0530
From: Harish M <[e-mail]>
Subject: RE: Question on LMP Adjacency
To: =?ks_c_5601-1987?B?ob5loq+l7EWhqQ==?= <[e-mail]>, [e-mail]
Reply-to: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_d9vC5O9cBhNsUS8WAR8QWw)"

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: [e-mail] [mailto:[e-mail]]On Behalf Of
±è¿µÈ­
Sent: Friday, December 10, 2004 12:37 PM
To: [e-mail]
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
[e-mail] [mailto:[e-mail]]<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
[e-mail]<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=
=[e-mail]&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=[e-mail].k=
r&amp;messageid=3D%3C1f04e01c4de86$e6d291c0$[e-mail]%3E"=20
  width=3D0 NOSEND=3D"1"></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_d9vC5O9cBhNsUS8WAR8QWw)--



Envelope-to: [e-mail]
Delivery-date: Fri, 10 Dec 2004 07:09:11 +0000
Content-Transfer-Encoding: 7bit
Thread-Topic: Question on LMP Adjacency
Thread-Index: AcTehubQSorDtZx4TqSA2fbmQ6v0zA==
Reply-To: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
From: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
To: <[e-mail]>
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=?=
Message-ID: <1f04e01c4de86$e6d291c0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_1F04F_01C4DED2.56BA39C0"
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=
=[e-mail]&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=[e-mail]&messag=
eid=3D%3C1f04e01c4de86$e6d291c0$[e-mail]%3E">
------=_NextPart_000_1F04F_01C4DED2.56BA39C0--



Envelope-to: [e-mail]
Delivery-date: Thu, 09 Dec 2004 12:38:48 +0000
Message-ID: <[e-mail]>
Date: Thu, 09 Dec 2004 13:36:40 +0100
From: [e-mail]
Reply-To: [e-mail]
Organization: Alcatel CTO/R&I
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
Cc: [e-mail], Kireeti Kompella <[e-mail]>, Arthi Ayyangar <[e-mail]>, JP Vasseur <[e-mail]>
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

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
>
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Wed, 08 Dec 2004 19:27:43 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Wed, 8 Dec 2004 13:26:00 -0600
Message-ID: <[e-mail]>
Thread-Topic: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Thread-Index: AcTca1DWMQ9Lm9UMQKmiKMiTZ4RtRAA8BuaA
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "JP Vasseur" <[e-mail]>

Answers below-
Deborah=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Tuesday, December 07, 2004 9:43 AM
To: [e-mail]
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






Envelope-to: [e-mail]
Delivery-date: Wed, 08 Dec 2004 14:32:41 +0000
Message-ID: <[e-mail]>
Date: Wed, 8 Dec 2004 09:32:12 -0500 (EST)
Subject: Re: Starting a discussion on graceful shutdown
From: [e-mail]
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail]
User-Agent: SquirrelMail/1.4.1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 08 Dec 2004 14:21:11 +0000
Message-ID: <[e-mail]>
Date: Wed, 08 Dec 2004 15:18:59 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: Dimitri Papadimitriou <[e-mail]>,  [e-mail]
Subject: Re: Node ID Hello [Was: Re: Draft minutes from Tove]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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" <[e-mail]> To: "Adrian Farrel"
> <[e-mail]> Cc: <[e-mail]> 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 [e-mail] === 
>>> 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.
>>> 
>>> 
>>> .
>>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 08 Dec 2004 12:25:55 +0000
Date: Wed, 08 Dec 2004 18:00:14 +0530
From: Harish M <[e-mail]>
Subject: FW: LMP Related Questions - 2
To: [e-mail], [e-mail]
Cc: [e-mail]
Reply-to: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_63UqUQb4TTmGRdYI5uLlnw)"

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:[e-mail]]
Sent: Wednesday, December 08, 2004 5:40 PM
To: [e-mail]
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: [e-mail] [mailto:[e-mail]]On
Behalf Of Kim Young Hwa
    Sent: Wednesday, December 08, 2004 1:59 PM
    To: [e-mail]
    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:[e-mail]]<BR><B>Sent:</B> Wednesday, December 08, 2004 5:40 
PM<BR><B>To:</B> [e-mail]<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> [e-mail] [<A 
    href="mailto:[e-mail]%5DOn" 
    eudora="autourl">mailto:[e-mail]]</A><A 
    href="mailto:[e-mail]%5DOn" eudora="autourl">On</A> Behalf 
    Of </B>Kim Young Hwa 
    <DD>Sent:</B> Wednesday, December 08, 2004 1:59 PM 
    <DD>To:</B> [e-mail] 
    <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)--



Envelope-to: [e-mail]
Delivery-date: Wed, 08 Dec 2004 10:14:00 +0000
Date: Wed, 08 Dec 2004 15:49:18 +0530
From: Harish M <[e-mail]>
Subject: RE: LMP Related Questions - 2
To: Kim Young Hwa <[e-mail]>, [e-mail]
Reply-to: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_1UaM5Db0gQ2mudilLq8CWw)"

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: [e-mail] [mailto:[e-mail]]On Behalf
Of Kim Young Hwa
  Sent: Wednesday, December 08, 2004 1:59 PM
  To: [e-mail]
  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> [e-mail] 
  [mailto:[e-mail]]<B>On Behalf Of </B>Kim Young 
  Hwa<BR><B>Sent:</B> Wednesday, December 08, 2004 1:59 PM<BR><B>To:</B> 
  [e-mail]<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=[e-mail]&amp;name=ccamp%40ops.ietf.org&amp;fromemail=[e-mail]&amp;messageid=%3Ca6c201c4dcff$fea27f50$[e-mail]%3E" 
  width=0 NOSEND="1"></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_1UaM5Db0gQ2mudilLq8CWw)--



Envelope-to: [e-mail]
Delivery-date: Wed, 08 Dec 2004 08:30:06 +0000
Content-Transfer-Encoding: 7bit
Thread-Topic: LMP Related Questions - 2
Thread-Index: AcTc//6gVHVmQLJ1RqGj1N85GqbiTQ==
Reply-To: "Kim Young Hwa" <[e-mail]>
From: "Kim Young Hwa" <[e-mail]>
To: <[e-mail]>
Cc: 
Bcc: 
Subject: LMP Related Questions - 2
Date: Wed, 8 Dec 2004 17:29:12 +0900
Comment: =?ISO-8859-1?B?x9GxucD8wNrF673Fv6yxuL/4LCCxpMD8tN64wcGmvu7GwCwgtOO05w==?=
Message-ID: <a6c201c4dcff$fea27f50$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_A6C3_01C4DD4B.6E8A2750"
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=[e-mail]&messag=
eid=3D%3Ca6c201c4dcff$fea27f50$[e-mail]%3E">
------=_NextPart_000_A6C3_01C4DD4B.6E8A2750--



Envelope-to: [e-mail]
Delivery-date: Wed, 08 Dec 2004 04:27:47 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "JP Vasseur" <[e-mail]>
Subject: RE: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Tue, 7 Dec 2004 20:26:25 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 6:43 AM
> To: [e-mail]
> 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



Envelope-to: [e-mail]
Delivery-date: Wed, 08 Dec 2004 02:31:53 +0000
From: "Zafar Ali" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "'Arthi Ayyangar'" <[e-mail]>, "'JP Vasseur'" <[e-mail]>
Subject: RE: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Tue, 7 Dec 2004 21:30:49 -0500
Message-ID: <000401c4dccd$f0aafa80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Adrian Farrel
>Sent: Tuesday, December 07, 2004 9:43 AM
>To: [e-mail]
>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
>
>



Envelope-to: [e-mail]
Delivery-date: Wed, 08 Dec 2004 00:34:31 +0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: <[e-mail]>
From: JP Vasseur <[e-mail]>
Subject: Re: Starting a discussion on graceful shutdown
Date: Tue, 7 Dec 2004 19:32:50 -0500
To: "Adrian Farrel" <[e-mail]>

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
>
>
>



Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 20:38:52 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, "Kireeti Kompella" <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "JP Vasseur" <[e-mail]>
From: [e-mail]
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
MIME-Version: 1.0
Date: Tue, 7 Dec 2004 21:35:42 +0100
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

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





Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 19:13:44 +0000
Message-ID: <[e-mail]>
From: John Drake <[e-mail]>
To: Adrian Farrel <[e-mail]>, [e-mail]
Cc: Kireeti Kompella <[e-mail]>, Arthi Ayyangar <[e-mail]>, JP Vasseur <[e-mail]>
Subject: RE: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status ?
Date: Tue, 7 Dec 2004 11:12:25 -0800 
MIME-Version: 1.0
Content-Type: text/plain

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Tuesday, December 07, 2004 6:43 AM
> To: [e-mail]
> 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




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 17:28:01 +0000
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 2004 18:26:31 +0100
From: Gert Grammel <[e-mail]>
Organization: Alcatel OND
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail], Kireeti Kompella <[e-mail]>, Arthi Ayyangar <[e-mail]>, JP Vasseur <[e-mail]>
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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
>
>
>  
>



Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 16:37:34 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, "Fabio Ricciato" <[e-mail]>, "Ugo Monaco" <[e-mail]>, "Alessio D'Achille" <[e-mail]>, "Daniele Ali" <[e-mail]>, "Marco Listanti" <[e-mail]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 08:36:39 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 8:06 AM
> To: [e-mail]
> Cc: [e-mail]
> 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
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 16:31:57 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 08:31:01 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Adrian,

A few last comments on your note ...

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: [e-mail]; Ugo Monaco
> Cc: [e-mail]; 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




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 16:31:49 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 08:30:58 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Adrian,

Continuing on ...

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: [e-mail]; Ugo Monaco
> Cc: [e-mail]; 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




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 16:13:20 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Tue, 7 Dec 2004 10:13:09 -0600
Message-ID: <[e-mail]>
Thread-Topic: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Thread-Index: AcTca1IPaFJrU42cT56QZwBDZdp0XgACkTOQ
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>, "Kireeti Kompella" <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "JP Vasseur" <[e-mail]>

> 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



Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 16:09:54 +0000
Message-ID: <045701c4dc76$eccf3270$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 16:05:41 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 16:05:25 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 08:04:31 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Hi Adrian,

A bit more discussion ...

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: [e-mail]; Ugo Monaco
> Cc: [e-mail]; 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.)





Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 15:57:00 +0000
Message-ID: <[e-mail]>
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: [e-mail]
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], "Kireeti Kompella" <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "JP Vasseur" <[e-mail]>
User-Agent: SquirrelMail/1.4.1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

I believe 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
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 15:54:24 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 07:53:30 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Adrian,

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Tuesday, December 07, 2004 4:25 AM
> To: [e-mail]; Ugo Monaco
> Cc: [e-mail]; 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





Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 15:54:16 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 07:53:33 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

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: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: [e-mail]; Ugo Monaco
> Cc: [e-mail]; 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?





Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 15:54:08 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 07:53:26 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

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:[e-mail]]
> Sent: Tuesday, December 07, 2004 3:39 AM
> To: [e-mail]; Ugo Monaco
> Cc: [e-mail]; 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.




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 15:54:01 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 07:53:37 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

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: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: [e-mail]; Ugo Monaco
> Cc: [e-mail]; 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).





Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 15:45:40 +0000
Message-ID: <044301c4dc73$07260b20$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Starting a discussion on graceful shutdown
Date: Tue, 7 Dec 2004 15:38:55 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 15:45:32 +0000
Message-ID: <044201c4dc73$03e3b160$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-02.txt
Date: Tue, 7 Dec 2004 15:12:32 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 15:43:39 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Tue, 7 Dec 2004 16:40:38 +0100
Message-ID: <[e-mail]>
Thread-Topic: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
thread-index: AcTca6dlkK7SRIdoQ4WcNp4qczWlgQAALbtg
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "JP Vasseur" <[e-mail]>

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 : [e-mail]=20
>[mailto:[e-mail]] De la part de Adrian Farrel
>Envoy=E9 : mardi 7 d=E9cembre 2004 15:43
>=C0 : [e-mail]
>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
>
>
>



Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 15:33:15 +0000
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 2004 16:30:38 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail], Kireeti Kompella <[e-mail]>, Arthi Ayyangar <[e-mail]>, JP Vasseur <[e-mail]>
Subject: Re: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 14:43:38 +0000
Message-ID: <03f801c4dc6b$1a5efa60$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "JP Vasseur" <[e-mail]>
Subject: draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt to WG status?
Date: Tue, 7 Dec 2004 14:43:02 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 14:23:07 +0000
Message-Id: <[e-mail]>
From: "Baktha Muralidharan" <[e-mail]>
To: <[e-mail]>, "'Adrian Farrel'" <[e-mail]>
Cc: "'???'" <[e-mail]>, <[e-mail]>
Subject: RE: LMP Related Questions
Date: Tue, 7 Dec 2004 09:21:48 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcTcYF95D5ycAUfCTHmj1cvhdy8fhAABpT1A

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: [e-mail] [mailto:[e-mail]] On Behalf
Of [e-mail]
Sent: Tuesday, December 07, 2004 8:24 AM
To: Adrian Farrel
Cc: ???; [e-mail]
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









Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 13:25:04 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: =?euc-kr?B?sei/tcit?= <[e-mail]>, <[e-mail]>
From: [e-mail]
Subject: Re: LMP Related Questions
MIME-Version: 1.0
Date: Tue, 7 Dec 2004 14:24:25 +0100
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

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








Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 12:56:53 +0000
Message-ID: <03bf01c4dc59$3eb50fb0$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: Re: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 12:24:49 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> 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



Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 12:51:28 +0000
Message-ID: <03c901c4dc5a$9e706570$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
Cc: <[e-mail]>
Subject: Re: LMP Related Questions
Date: Tue, 7 Dec 2004 12:45:04 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit

> 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




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 12:39:18 +0000
Message-ID: <03be01c4dc59$3d125c30$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>
Subject: Re: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 12:19:01 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 12:39:10 +0000
Message-ID: <03bd01c4dc59$38b543a0$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: Re: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Tue, 7 Dec 2004 11:39:28 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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.




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 07:34:58 +0000
Content-Transfer-Encoding: 7bit
Thread-Topic: LMP Related Questions
Thread-Index: AcTcLytC8PkMl0FWReSVFEpESgAmnQ==
Reply-To: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
From: =?ks_c_5601-1987?B?sei/tcit?= <[e-mail]>
To: <[e-mail]>
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=?=
Message-ID: <1634901c4dc2f$2b448160$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_1634A_01C4DC7A.9B2C2960"
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=[e-mail]&messag=
eid=3D%3C1634901c4dc2f$2b448160$[e-mail]%3E">
------=_NextPart_000_1634A_01C4DC7A.9B2C2960--



Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 06:27:53 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Mon, 6 Dec 2004 22:27:22 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

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:[e-mail]]
> Sent: Monday, December 06, 2004 10:22 PM
> To: Adrian Farrel; Ugo Monaco
> Cc: [e-mail]; 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:[e-mail]]
> > Sent: Saturday, December 04, 2004 10:40 AM
> > To: Ugo Monaco
> > Cc: [e-mail]; 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?
>




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 06:23:47 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Mon, 6 Dec 2004 22:21:48 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Hi Adrian,

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

Here's the second ...

-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Saturday, December 04, 2004 10:40 AM
> To: Ugo Monaco
> Cc: [e-mail]; 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?




Envelope-to: [e-mail]
Delivery-date: Tue, 07 Dec 2004 06:23:39 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: RE: Draft minutes from Tove: draft-dachille-inter-region-path-setup-04.txt
Date: Mon, 6 Dec 2004 22:21:45 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Hi Adrian,

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

Here's the first.

-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Saturday, December 04, 2004 10:40 AM
> To: Ugo Monaco
> Cc: [e-mail]; 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.





Envelope-to: [e-mail]
Delivery-date: Mon, 06 Dec 2004 12:47:39 +0000
Message-ID: <02c301c4db91$77036ab0$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "Tove Madsen" <[e-mail]>, <[e-mail]>
Subject: IETF 61 : CCAMP Minutes
Date: Mon, 6 Dec 2004 12:43:03 -0000
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_02BB_01C4DB91.204D1540"

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--




Envelope-to: [e-mail]
Delivery-date: Sun, 05 Dec 2004 12:14:47 +0000
Message-ID: <00d001c4dac3$c6880f60$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Dimitri Papadimitriou" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Cc: <[e-mail]>
Subject: Node ID Hello [Was: Re: Draft minutes from Tove]
Date: Sun, 5 Dec 2004 12:12:57 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
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
> > [e-mail]
> > ===
> > 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.
> >
> >
> > .
> >
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Sat, 04 Dec 2004 21:22:16 +0000
Message-ID: <[e-mail]>
Date: Sat, 04 Dec 2004 22:20:28 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail],  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail]
Subject: Re: Draft minutes from Tove
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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
> [e-mail]
> ===
> 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.
> 
> 
> .
> 





Envelope-to: [e-mail]
Delivery-date: Sat, 04 Dec 2004 19:07:37 +0000
Message-ID: <007801c4da30$ee31c120$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ugo Monaco" <[e-mail]>
Cc: <[e-mail]>, "Vishal Sharma" <[e-mail]>, "Alessio D'Achille" <[e-mail]>, =?iso-8859-1?Q?Daniele_Al=EC?= <[e-mail]>, "Marco Listanti" <[e-mail]>, "Tove Madsen" <[e-mail]>
Subject: Re: Draft minutes from Tove
Date: Sat, 4 Dec 2004 18:39:50 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Sat, 04 Dec 2004 18:43:27 +0000
Message-ID: <006e01c4da30$46aacaa0$fd919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>, <[e-mail]>
Subject: Re: New Submission : Requirement for (G)MPLS implantation over Ethernet
Date: Sat, 4 Dec 2004 18:25:42 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit

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.




Envelope-to: [e-mail]
Delivery-date: Sat, 04 Dec 2004 10:12:53 +0000
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>
From: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>
To: <[e-mail]>
Cc: 
Bcc: 
Date: Sat, 4 Dec 2004 19:10:51 +0900
Thread-Index: AcTZ6NqSs7UtbK5YT+iGbU141K/TgA==
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCC9w726xdu8s7DoxsAsILTjtOc=?=
Thread-Topic: New Submission : Requirement for (G)MPLS implantation over Ethernet
Message-ID: <052501c4d9e9$88a3a590$[e-mail]>
Subject: New Submission : Requirement for (G)MPLS implantation over Ethernet
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0517_01C4DA34.4A7F2E60"
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: [phone]</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=[e-mail]&mess=
ageid=3D%3C052501c4d9e9$88a3a590$[e-mail]%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"

CgoKCgoKQ0NBTVAgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgSmFpaHl1bmcgQ2hvCklOVEVSTkVUIERSQUZUICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRVRSSQpFeHBpcmVzOiBKdW5lIDIwMDUg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERlY2VtYmVyIDIwMDQKCgog
ICAgICAgICAgIFJlcXVpcmVtZW50IGZvciAoRylNUExTIGltcGxhbnRhdGlvbiBvdmVyIEV0aGVy
bmV0CiAgICAgICAgICAgICAgPGRyYWZ0LWphaWh5dW5nLWNjYW1wLWxzZXJlcXVpcmVtZW50LTAw
LnR4dD4KClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVy
bmV0LURyYWZ0LCBJIGNlcnRpZnkgdGhhdCBhbnkgYXBwbGljYWJsZQogICAgIHBhdGVudCBvciBv
dGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIEkgYW0gYXdhcmUgaGF2ZSBiZWVuIGRpc2Nsb3NlZCwK
ICAgICBhbmQgYW55IG9mIHdoaWNoIEkgYmVjb21lIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBp
biBhY2NvcmRhbmNlCiAgICAgd2l0aCBSRkMgMzY2OC4KCiAgICAgSW50ZXJuZXQtRHJhZnRzIGFy
ZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgICBUYXNr
IEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0
aGF0CiAgICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVu
dHMgYXMgSW50ZXJuZXQtCiAgICAgRHJhZnRzLgoKICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRy
YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeAogICAgIG1vbnRocyBhbmQg
bWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdS0KICAg
ICBtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0
LURyYWZ0cyBhcwogICAgIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIg
dGhhbiBhcyAid29yayBpbiBwcm8tCiAgICAgZ3Jlc3MuIgoKICAgICBUaGUgbGlzdCBvZiBjdXJy
ZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgICBodHRwOi8vd3d3Lmll
dGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuCgogICAgIFRoZSBsaXN0IG9mIEludGVybmV0
LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgICBodHRwOi8v
d3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwg
ZXhwaXJlIG9uIEZlYnJ1YXJ5IDIwMDUuCgoKQWJzdHJhY3QKCiAgICAgSW4gdGhpcyBkcmFmdCwg
d2UgcHJvcG9zZSByZXF1aXJlbWVudCB0byBpbXBsZW1lbnQgTVBMUyB0ZWNobm9sb2d5CiAgICAg
Zm9yIEV0aGVybmV0IHN3aXRjaGVkIG5ldHdvcmsuIEV0aGVybmV0IGhhcyBiZWNvbWUgbWFqb3Ig
YnVpbGRpbmcKICAgICBibG9jayBpbiBsb2NhbCBhcmVhIG5ldHdvcmsgYW5kIHRoZSBhcmVhIG9m
IGRlcGxveW1lbnQgaXMgcXVpY2tseQogICAgIGV4cGFuZGluZyB0byBjb3JlIG5ldHdvcmsuIFdo
aWxlIHRoZXJlIGhhdmUgYmVlbiBpbmR1c3RyeSBuZWVkcyB0bwogICAgIG92ZXJjb21lIHdlYWtu
ZXNzIG9mIEV0aGVybmV0LCBNUExTIGhhcyBub3QgYmVlbiBjb25zaWRlcmVkIGFzIGtleQogICAg
IHRlY2hub2xvZ3kgdG8gaW1wcm92ZSBFdGhlcm5ldC4gQ3VycmVudGx5IE1QTFMgW1JGQzMwMzFd
IGFuZCBHTVBMUwogICAgIFtHQVJDSF0gYXJjaGl0ZWN0dXJlIGRvIG5vdCBkZWZpbmUgbGFiZWwt
c3dpdGNoaW5nIGZ1bmN0aW9uIG9uCiAgICAgTDJTQyBpbnRlcmZhY2UsIGkuZS4gb3ZlciBMQU4g
bWVkaWEuIEhlbmNlLCBpdCBpcyBuZWNlc3NhcnkgdG8KICAgICBkaXNjdXNzIGxpZ2h0d2VpZ2h0
IGltcGxlbWVudGF0aW9uIG9mIChHKU1QTFMgZm9yIEV0aGVybmV0LiBTaW5jZQogICAgIHRoZSBy
ZXF1aXJlbWVudHMgbWF5IGRpZmZlcmVudCBhY2NvcmRpbmcgdG8gaGllcmFyY2h5IG9mIEV0aGVy
bmV0LAogICAgIGl0IGlzIGFwcHJvcHJpYXRlIHRvIHNlcGFyYXRlIHNvbHV0aW9ucyBpbiBDdXN0
b21lciBQcmVtaXNlIE5ldHdvcmsKICAgICAoQ1BOKSwgQWNjZXNzIE5ldHdvcmsgKEFOKSBhbmQg
Q29yZSBOZXR3b3JrIChDTikuIFNvbWUgY2FuZGlkYXRlIAogICAgIG1ldGhvZHMgdG8gY29uc2lk
ZXIgZm9yIGxhYmVsIGVuY29kaW5nIGZvciBFdGhlcm5ldCBhcmUgZGlzY3Vzc2VkLgoKCgoKCkph
aWh5dW5nIENobyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMjAwNSAgICAgICAgICAgICAg
ICAgICBbUGFnZSAxXQoMCgogIFJlcXVpcmVtZW50IGZvciAoRylNUExTIGltcGxhbnRhdGlvbiBv
dmVyIEV0aGVybmV0ICAgICAgIERlY2VtYmVyIDIwMDQKCgpUYWJsZSBvZiBDb250ZW50czoKCiAg
ICAgMS4gSW50cm9kdWN0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uMgogICAgIDIuIENhbmRpZGF0ZSBNZXRob2RzIGZvciBMYWJlbCBFbmNvZGluZyBp
biBFdGhlcm5ldC4uLi4uLi4uLi4uLjMKICAgICAzLiBJc3N1ZXMgYXQgRWFjaCBIaWVyYXJjaHkg
b2YgRXRoZXJuZXQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40CiAgICAgNC4gQ29uY2x1c2lvbiAu
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNQogICAgIDUu
IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLjUKICAgICA2LiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi41CiAgICAgQXV0aG9yJ3MgQWRkcmVzc2VzLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNgoKCgoxLiBJbnRyb2R1Y3Rpb24KCiAgICAg
SW4gdGhlIGxhc3Qgc2V2ZXJhbCB5ZWFycywgRXRoZXJuZXQgaGFzIGJlY29tZSBhIHByZXZhbGVu
dAogICAgIHRlY2hub2xvZ3kgaW4gdGhlIGFyZWEgb2YgYm90aCBwcml2YXRlIG5ldHdvcmsgYW5k
IG1ldHJvIGFjY2VzcwogICAgIG5ldHdvcmsuIFNvbWUgbmV0d29yayBzZXJ2aWNlIHByb3ZpZGVy
cyBub3cgZGVzaXJlIHRvIHB1c2ggRXRoZXJuZXQKICAgICBiZXlvbmQgdGhlIHJhbmdlIG9mIE1B
Ti9XQU5zIHdoZXJlIGxvbmctaGF1bCB0ZWNobm9sb2dpZXMsIHN1Y2ggYXMKICAgICBTT05FVCwg
YXJlIHN0aWxsIGRvbWluYW50LiBUaGUgaG9wZSB0aGUgbmV0d29yayBjb3VsZCBiZSBiYXNlZAog
ICAgIGVudGlyZWx5IG9uIEV0aGVybmV0IHNpbXBsaWZ5IG5ldHdvcmsgbWFuYWdlbWVudCBhcyB3
ZWxsIGFzIG1ha2UKICAgICBvcGVyYXRpb25zIG1vcmUgZWZmaWNpZW50IGFuZCBsZXNzIGV4cGVu
c2l2ZSBieSBlbGltaW5hdGluZwogICAgIG92ZXJoZWFkIGZvciBjb252ZXJ0aW5nIGJldHdlZW4g
RXRoZXJuZXQgYW5kIG90aGVyIHRlY2hub2xvZ2llcy4KICAgICBIb3dldmVyLCBpbmR1c3RyeSBl
eHBlcnRzIG5vdGUgdGhhdCBFdGhlcm5ldCBkb2Vzbid0IG9mZmVyIHRoZQogICAgIHNjYWxhYmls
aXR5LCByZWxpYWJpbGl0eSBhbmQgcXVhbGl0eSBvZiBzZXJ2aWNlIHRoYXQgQVRNIGFuZCBNUExT
CiAgICAgcHJvdmlkZS4KCiAgICAgVGhlcmUgaGF2ZSBiZWVuIGFwcHJvYWNoZXMgdG8gb3ZlcmNv
bWUgdGhlIGxpbWl0YXRpb25zIGFuZCB0bwogICAgIGV4dGVuZCBzZXJ2aWNlIG9mIEV0aGVybmV0
IGFjcm9zcyBNQU4vV0FOcywgc3VjaCBhcyBbTDJWUE5dLAogICAgIFByb3ZpZGVyIEJyaWRnZSBb
UEJSSURHRV0sIGhvd2V2ZXIsIE1QTFMgaGFzIG5vdCBiZWVuIGNvbnNpZGVyZWQgCiAgICAgZm9y
IHNjYWxhYmxlIGNvbnRyb2wgcGxhbmUgb2YgRXRoZXJuZXQuIEluIGN1cnJlbnQgc3BlY2lmaWNh
dGlvbgogICAgIG9mIE1QTFMgYXJjaGl0ZWN0dXJlIFtSRkMzMDMxXSwgc3VjaCBmdW5jdGlvbmFs
aXR5IGFzIGxhYmVsCiAgICAgc3dpdGNoaW5nIGFuZCB0cmFmZmljIGNvbnRyb2wgaXMgb25seSBh
dmFpbGFibGUgaW4gSVAgbGV2ZWwgd2hlcmUKICAgICBFdGhlcm5ldCBzZXJ2aWNlIGlzIHRlcm1p
bmF0ZWQuIFdoZW4gdHdvIE1QTFMgbm9kZXMgYXJlIGNvbm5lY3RlZAogICAgIHZpYSBFdGhlcm5l
dCBzd2l0Y2hlcywgRXRoZXJuZXQgbm9kZXMgZG8gbm90IHRha2UgYSByb2xlIGluCiAgICAgZGVs
aXZlcmluZyBsYWJlbGVkIHBhY2tldHMsIGFsdGhvdWdoIHRoZSBhY3R1YWwgcGVyZm9ybWFuY2UK
ICAgICBib3R0bGVuZWNrIG1heSBiZSBpbiBFdGhlcm5ldCBzd2l0Y2hlcy4gR01QTFMgYXJjaGl0
ZWN0dXJlIFtHQVJDSF0KICAgICBhbHNvIGRvZXMgbm90IGNvbnNpZGVyIG9uIEwyU0MgaW50ZXJm
YWNlIGF0IHRoZSBtb21lbnQuIEdpdmVuIHRoZQogICAgIGltcG9ydGFuY2Ugb2YgRXRoZXJuZXQg
c3dpdGNoZXMgaW4gbW9kZXJuIG5ldHdvcmssIHdlIHRoZXJlZm9yZQogICAgIHByb3Bvc2UgaXQg
aXMgbmVjZXNzYXJ5IHRvIGNvbnNpZGVyIGltcGxlbWVudGF0aW9uIG9mIChHKU1QTFMKICAgICB0
ZWNobm9sb2d5IGZvciBFdGhlcm5ldCBzd2l0Y2hlZCBuZXR3b3JrLgoKICAgICBUaGUgKEcpTVBM
UyBpbXBsZW1lbnRhdGlvbiBmb3IgRXRoZXJuZXQgd2lsbCBiZSBicm9hZGx5CiAgICAgY2hhcmFj
dGVyaXplZCBhcyBlbXBsb3ltZW50IG9mIGxpZ2h0d2VpZ2h0IEludGVybmV0IHByb3RvY29sIGZv
cgogICAgIGNvbnRyb2wgb2YgRXRoZXJuZXQgZGF0YSBmbG93cy4gSW4gdW5kZXJseWluZyBoYXJk
d2FyZSBsYXllciwgbW9zdAogICAgIGRhdGEgbGluayBmZWF0dXJlIGFuZCBpbnRlcmZhY2UgZGVm
aW5lZCBpbiBJRUVFIDgwMi4zIHNoYWxsIG5vdCBiZQogICAgIGFsdGVyZWQuIEhvd2V2ZXIsIGlu
dGVsbGlnZW50IHNpZ25hbGluZyBhbmQgcm91dGluZyBjb250cm9sIHRoYXQKICAgICB1bmRlcnN0
YW5kcyBJUCBwcm90b2NvbHMgd2lsbCBiZSBuZWNlc3NhcnkgaW4gcmVwbGFjZW1lbnQgdG8gc2lt
cGxlCiAgICAgYnJpZGdlIGNvbnRyb2wgYWxnb3JpdGhtcyBbU1RQXVtNU1RQXS4gTmV2ZXJ0aGVs
ZXNzLCB0aGlzIGRvZXMgbm90CiAgICAgbmVjZXNzYXJpbHkgbWVhbiB0aGF0IEV0aGVybmV0IHN3
aXRjaGVzIG11c3QgcnVuIGFsbCBlc3NlbnRpYWwgc2V0CiAgICAgb2YgTVBMUyBwcm90b2NvbHMu
IEdpdmVuIHRoZSBuYXR1cmUgb2Ygc2ltcGxpY2l0eSBhbmQgb3BlcmF0aW9uYWwKICAgICBlbnZp
cm9ubWVudCwgbXVjaCBsaWdodHdlaWdodCBhbmQgY29tcGF0aWJsZSBtZXRob2QgdG8gbGVnYWN5
IExBTgogICAgIGVudmlyb25tZW50IHdpbGwgYmUgbmVjZXNzYXJ5LgoKCgoKSmFpaHl1bmcgQ2hv
ICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAyMDA1ICAgICAgICAgICAgICAgICAgIFtQYWdl
IDJdCgwKCiAgICBSZXF1aXJlbWVudCBmb3IgKEcpTVBMUyBpbXBsYW50YXRpb24gb3ZlciBFdGhl
cm5ldCAgICAgIERlY2VtYmVyIDIwMDQKCgogICAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVT
VCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgICAiU0hPVUxEIiwg
IlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4KICAg
ICB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JG
QyAyMTE5XS4KCgoKMi4gQ2FuZGlkYXRlIE1ldGhvZHMgZm9yIExhYmVsIEVuY29kaW5nIGluIEV0
aGVybmV0CgogICAgIEluIGN1cnJlbnQgc3BlY2lmaWNhdGlvbiBvZiBNUExTIGxhYmVsIGVuY29k
aW5nIFtSRkMzMDMyXSwgTVBMUwogICAgIHNoaW0gaGVhZGVyIGRvZXMgbm90IGhhdmUgZWZmZWN0
IG9uIHVuZGVybHlpbmcgTEFOIG1lZGlhLiBBCiAgICAgcHJvcHJpZXRhcnkgaW1wbGVtZW50YXRp
b24gZXhpc3RzIHRoYXQgRXRoZXJuZXQgc3dpdGNoIGRlY29kZXMgdGhlCiAgICAgc2hpbSBoZWFk
ZXIgYW5kIGZvcndhcmQgZnJhbWVzIGFjY29yZGluZyB0byBsYWJlbCBpbmZvcm1hdGlvbgogICAg
IFtBVFJJQ0FdLiBXaGlsZSB0aGlzIGNhbiBiZSBhIHNvbHV0aW9uIHRvIGVtcGxveSBNUExTIG92
ZXIKICAgICBFdGhlcm5ldCwgb3ZlcmhlYWQgdG8gaW1wbGVtZW50IGFsbCBwcm9jZXNzaW5nIGZ1
bmN0aW9uIG9mIGxhYmVsLQogICAgIHN0YWNrcyBtYXkgZGltaW5pc2ggY29zdGVmZmVjdGl2ZW5l
c3Mgb2YgRXRoZXJuZXQuCgogICAgIEFub3RoZXIgb3B0aW9uIHRvIGNvbnNpZGVyIGlzIHVzaW5n
IDQ4Yml0cyBvZiBkZXN0aW5hdGlvbiBhZGRyZXNzCiAgICAgZmllbGQgKGFuZCBhbHNvIHNvdXJj
ZSBhZGRyZXNzIGZpZWxkLCBpZiBuZWNlc3NhcnkpIGluIEV0aGVybmV0CiAgICAgaGVhZGVyIGZv
ciBsYWJlbHMuIFRoaXMgbWV0aG9kIHdhcyBwcm9wb3NlZCBpbiBbU1JJTklWQVNBTl0gYW5kCiAg
ICAgW0VUSFJFQUwxXSBpbmRlcGVuZGVudGx5LiBTLiBWYXJhZGFyYWphbiBkZW1vbnN0cmF0ZWQg
ZXhjZWxsZW50CiAgICAgY2FwYWJpbGl0eSBvZiBNQUMgYWRkcmVzcyBzd2FwcGluZyB0aGF0IHJl
YWwtdGltZSBhcHBsaWNhdGlvbnMKICAgICByZWNlaXZlIGd1YXJhbnRlZWQgc2VydmljZSB3aXRo
b3V0IHJlbHlpbmcgb24gcHJpb3JpdHkgZmllbGRzCiAgICAgW0VUSFJFQUwyXVtFVEhSRUFMM10u
IEluIGhpcyBtZXRob2QsIEV0aGVybmV0IHN3aXRjaGVzIHN3YXAKICAgICBkZXN0aW5hdGlvbiBh
ZGRyZXNzIGFzIHRoZXkgZm9yd2FyZCBmcmFtZXMuIEFzIGEgcmVzdWx0LCBhZGRyZXNzIGluCiAg
ICAgTUFDIGhlYWRlciBvbmx5IGhhcyBsb2NhbCBtZWFuaW5nIGJldHdlZW4gdHdvIG5vZGVzLCBh
bmQgaW5mb3JtYXRpb24KICAgICBuZWNlc3NhcnkgZm9yIHBlci1mbG93IGZvcndhcmRpbmcgZGVj
aXNpb24sIHRyYWZmaWMgY2xhc3NlcyBmb3IKICAgICBRb1MsIGFuZCBvdGhlcnMgY2FuIGJlIG9i
dGFpbmVkIGZyb20gc2ltcGxlIE1BQyBhZGRyZXNzIGxvb2t1cC4KCiAgICAgVGhlIG1ldGhvZCBl
eGhpYml0cyBzZXZlcmFsIHVuaXF1ZSBjaGFyYWN0ZXJpc3RpY3MuIEZvciBleGFtcGxlLCBpdAog
ICAgIHJlcXVpcmVzIHJlbGF0aXZlbHkgc2ltcGxlIG1vZGlmaWNhdGlvbiB0byBFdGhlcm5ldCBo
YXJkd2FyZSB0bwogICAgIHN1cHBvcnQgTVBMUyBmdW5jdGlvbi4gSXQgYWxzbyBtaW5pbWl6ZXMg
Y2hhbmdlcyBpbiB1c2VyIHRlcm1pbmFsCiAgICAgaW4gb3JkZXIgdG8gcHJvdmlkZSByZWFsLXRp
bWUgc2VydmljZS4gSG93ZXZlciwgVmFyYWRhcmFqYW4gdXNlZAogICAgIHByb3ByaWV0YXJ5IHBy
b3RvY29sIHRvIGVzdGFibGlzaCBzd2l0Y2hlZCBkYXRhIHBhdGggYW5kIGRpc3RyaWJ1dGUKICAg
ICBsYWJlbCBpbmZvcm1hdGlvbi4gSGlzIHdvcmsgbmVlZHMgZnVydGhlciBzb3BoaXN0aWNhdGlv
biB0byBpbXByb3ZlCiAgICAgaW50ZXItb3BlcmFiaWxpdHkuCgogICAgIEZpbmFsbHksIGFwcHJv
YWNoZXMgdGhhdCB1dGlsaXplIFZMQU4gdGFnIG9yIHN0YWNrIG9mIHRhZ3MgY2FuIGJlCiAgICAg
Zm91bmQgaW4gW0tBV0FLQU1JXSBhbmQgW1BCUklER0VdLiBUaGUgcHJvcG9zYWxzIHByZXNlbnQg
c29tZQogICAgIHBvdGVudGlhbCBiZW5lZml0IGluIHRoYXQgdGhleSBtYWtlIHVzZSBvZiB3ZWxs
LWRlZmluZWQgZmVhdHVyZSBvZgogICAgIFZMQU4uIEhvd2V2ZXIsIGNvbXBsZXhpdHkgYW5kIGVm
ZmljaWVuY3kgb2YgdGhlIHByb3RvY29scywgYW5kCiAgICAgbWVyaXRzIGFnYWluc3QgdGhlIG1l
dGhvZCB1c2luZyBNUExTIHNoaW0gaGVhZGVyIGV4cGxhaW5lZCBhYm92ZQogICAgIG11c3QgYmUg
Y2FsY3VsYXRlLgoKICAgICBJbiBjb25jbHVzaW9uLCB0aGVyZSBjYW4gYmUgbnVtZXJvdXMgbWV0
aG9kcyBmb3IgZW5jb2RpbmcgbGFiZWwKICAgICBpbmZvcm1hdGlvbiBpbiBFdGhlcm5ldC4gV2hp
Y2hldmVyIG1ldGhvZCBpcyBmYXZvcmVkLCB0aGUgbGV2ZWwgb2YKICAgICBzb3BoaXN0aWNhdGlv
biByZXF1aXJlZCB0byBpbXByb3ZlIG11c3Qgbm90IGhhcm0gc2ltcGxlIGFuZAogICAgIGVjb25v
bWljIGZlYXR1cmUgb2YgRXRoZXJuZXQuCgoKCgoKCgoKCkphaWh5dW5nIENobyAgICAgICAgICAg
ICAgICBFeHBpcmVzIEp1bmUgMjAwNSAgICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCgogICBS
ZXF1aXJlbWVudCBmb3IgKEcpTVBMUyBpbXBsYW50YXRpb24gb3ZlciBFdGhlcm5ldCAgICAgRGVj
ZW1iZXIgMjAwNAoKCjMuIElzc3VlcyBhdCBFYWNoIEhpZXJhcmNoeSBvZiBFdGhlcm5ldAoKICAg
ICBUaGUgaXNzdWUgb2YgKEcpTVBMUyBpbXBsZW1lbnRhdGlvbiBmb3IgRXRoZXJuZXQgY2FuIGJl
IGNvbnNpZGVyZWQKICAgICBzZXBhcmF0ZWx5IGluIHRocmVlIGRpZmZlcmVudCBsZXZlbCBvZiBo
aWVyYXJjaHk7IEN1c3RvbWVyIFByZW1pc2UKICAgICBOZXR3b3JrIChDUE4pLCBBY2Nlc3MgTmV0
d29yayAoQU4pIGFuZCBDb3JlIE5ldHdvcmsgKENOKS4KCiAgICAgQ1BOIGlzIGEgbG9jYWwgYXJl
YSBuZXR3b3JrIGFkbWluaXN0ZXJlZCBieSBwcml2YXRlIG93bmVyLiBUaGUKICAgICBzY2FsZSBv
ZiBDUE4gaXMgZGl2ZXJzZTsgZnJvbSBlbnRlcnByaXNlIHNjYWxlIHRvIHNtYWxsIHJlc2lkZW50
aWFsCiAgICAgbmV0d29yay4gRGVwbG95bWVudCBvZiBFdGhlcm5ldCBpcyBkb21pbmFudCBpbiBD
UE4uIE5ldHdvcmsKICAgICBjb25nZXN0aW9uIGlzIGhhcmRseSBhIHByb2JsZW0gaW4gQ1BOIGJl
Y2F1c2UgQ1BOIGlzIHVzdWFsbHkgb3Zlci0KICAgICBwcm92aXNpb25lZC4gSG93ZXZlciBzZXJ2
aWNlIGRpZmZlcmVudGlhdGlvbiBpcyBzdGlsbCBuZWNlc3NhcnkgaW4KICAgICBvcmRlciB0byBw
cm92aWRlIHNlY3VyZSBhbmQgc3RhYmxlIGNvbW1lcmNpYWwgc2VydmljZS4gVkxBTiB0YWdnaW5n
CiAgICAgaXMgb2Z0ZW4gY29uc2lkZXJlZCBhcyBtZWFucyBmb3IgZmxvdyBzZWdyZWdhdGlvbi4g
SG93ZXZlciwKICAgICBjb21tZXJjaWFsIHNlcnZpY2UgcHJvdmlkZXJzIGRvIG5vdCB0cnVzdCB1
c2VyIHRhZ2dpbmcgb2YgVkxBTgogICAgIGZpZWxkIGJlY2F1c2UgVkxBTiB0YWcgaXMgZWFzeSB0
byBiZSBtb2RpZmllZCBieSBtYWxpY2lvdXMgdXNlci4KICAgICBGdXJ0aGVybW9yZSwgc3RhdGVs
ZXNzIGFwcHJvYWNoZXMgdGhhdCB1c2UgcHJpb3JpdHkgZmllbGQsIHN1Y2ggYXMKICAgICBEaWZm
U2VydmUsIGFyZSB2dWxuZXJhYmxlIHRvIHRoZWZ0IG9mIHNlcnZpY2UgY2xhc3MgaW4gc29tZQog
ICAgIGVudmlyb25tZW50IHN1Y2ggYXMgVW5pdmVyc2l0eSBjYW1wdXMuIEEgc2VjdXJlIG1ldGhv
ZCB0byBwcm90ZWN0CiAgICAgdmFsdWUtYWRkZWQgdHJhZmZpYyBpbiBDUE4gaXMgbmVjZXNzYXJ5
LgoKICAgICBNUExTIHByb3ZpZGVzIGdvb2QgcHJvdGVjdGlvbiBhbmQgc2VydmljZSBndWFyYW50
ZWUgdG8gY3VzdG9tZXIgaW4KICAgICByb3V0ZXIgbmV0d29yayBbTDJWUE5dLiBTaW1pbGFybHks
IHRoZSBNQUMgYWRkcmVzcyBzd2FwcGluZyBtZXRob2QKICAgICBvZiBbRVRIUkVBTDFdIGFsc28g
c2hvd3Mgc2V2ZXJhbCBnb29kIHByb3BlcnRpZXMgdG8gcHJvdGVjdCByZWFsLQogICAgIHRpbWUg
c2VydmljZSBmbG93cyBpbiBDUE4uIEhvd2V2ZXIsIE1QTFMgYW5kIFtFVEhSRUFMMV0gYm90aAog
ICAgIHJlcXVpcmUgYXNzaXN0YW5jZSBvZiBzaWduYWxpbmcgcHJvdG9jb2wgYW5kIGV4cGxpY2l0
IHBhdGggc2V0dXAgb2YKICAgICB3aGljaCBub25lIG9mIHRoZSBraW5kcyBoYXMgYmVlbiBzdWNj
ZXNzZnVsbHkgZGVwbG95ZWQgaW4gbG9jYWwKICAgICBhcmVhIG5ldHdvcmsuCgogICAgIFRoZXJl
IGhhdmUgYmVlbiBhcHByb2FjaGVzIHVzaW5nIFJTVlAgZm9yIHByb2FjdGl2ZSBzaWduYWxpbmcg
aW4KICAgICBMQU4gZW52aXJvbm1lbnQgW1JGQzI4MTRdIFtSRkMyODE1XSBbUkZDMjgxNl0gW1JG
QzI5OThdLgogICAgIE1vZGlmaWNhdGlvbiBvZiB0aGUgcHJvcG9zYWxzIGNhbiBiZSBjb25zaWRl
cmVkLCBob3dldmVyLCB0aGUgc2V0CiAgICAgb2YgcHJvdG9jb2xzIHJlcXVpcmVkIHRvIHN1cHBv
cnQgUlNWUCBjb3VsZCBiZSB1bmFjY2VwdGFibHkgaGVhdnkKICAgICBpbiBzb21lIHJlc2lkZW50
aWFsIGVudmlyb25tZW50LiBVc2VyIGJ1cmRlbiBpbiBjb25maWd1cmluZyBuZXR3b3JrCiAgICAg
YWxzbyBtdXN0IGJlIGNhcmVmdWxseSBleGFtaW5lZC4gQSBzaW1wbGUgcHJvdG9jb2wgdGhhdCBy
ZXF1aXJlCiAgICAgbmVhci16ZXJvIGNvbmZpZ3VyYXRpb24gbWF5IGJlIG5lY2Vzc2FyeSBpbiBD
UE4uCgogICAgIEluIHRoZSBsZXZlbCBvZiBhY2Nlc3MgbmV0d29yayAoQU4pLCBkZXBsb3ltZW50
IG9mIEV0aGVybmV0IGZvciAKICAgICBjb3N0LWVmZmVjdGl2ZSBhZ2dyZWdhdGlvbiBvZiBzdWJz
Y3JpYmVyIGxpbmVzIGlzIG5vdyBhIGNvbW1vbiAKICAgICBwcmFjdGljZSBpbiBwcm92aWRlciBu
ZXR3b3JrLiBBTiBpcyBpbXByb3RhbnQgdG8gcHJvdmlkZXJzIGJlY2F1c2UgCiAgICAgdGhpcyBp
cyB0aGUgcGxhY2Ugd2hlcmUgdHJhZmZpYyBpcyBmcmVxdWVudGx5IGNvbmdlc3RlZCwgcmVzb3Vy
Y2UgCiAgICAgaXMgc2NhcmNlLCBhbmQgbW9zdCBjYXBpdGFsIGludmVzdG1lbnQgaXMgY29uY2Vu
dHJhdGVkLiBIb3dldmVyLAogICAgIG9uY2UgYSBuZXR3b3JrIGlzIGJ1aWx0IHVwLCBpdCBpcyBo
YXJkIHRvIGNoYW5nZSB0aGFuIGNvcmUgCiAgICAgbmV0d29yay4gQ2FyZWZ1bCBkZXNpZ24gb2Yg
UW9TIGFyY2hpdGVjdHVyZSBhbmQgc29sdXRpb24gdG8gcHJvdmlkZSAKICAgICBhcHByb3ByaWF0
ZSBmbG93IHNlZ3JlZ2F0aW9uIGluIEV0aGVybmV0IGJhc2VkIEFOIGlzIG5lY3Jlc3NhcnkuCgog
ICAgIEluIG9yZGVyIHRvIGNsYXNzaWZ5IHVzZXIgdHJhZmZpYyBhbmQgaW1wb3NlIHBlci1mbG93
IGFkbWlzc2lvbiAKICAgICBjb250cm9sIGF0IHRoZSBlbnRyYW5jZSBvZiBBTiwgc2V2ZXJhbCB0
ZWNobmlxdWVzIGNhbiBiZSBjb25zaWRlcmVkLgogICAgIFNvbWUgUW9TIHNvbHV0aW9ucywgc3Vj
aCBhcyBbRmxPV1JPVVRFUl0sIHJlcXVpcmUgYWNjZXNzIHN3aXRjaGVzCiAgICAgb3IgZWRnZSBy
b3V0ZXJzIHRvIGhhdmUgY2FwYWJpbGl0eSBvZiBUQ1AvSVAgaGVhZGVyIGxvb2t1cC4gSG93ZXZl
ciwKICAgICBvdmVyaGVhZCBmb3IgZGVlcCBwYWNrZXQgcHJvY2Vzc2luZyBpbiBhY2Nlc3Mgc3dp
dGNoIGlzIHVuYWNjZXB0YWJseSAKICAgICBoaWdoLgoKCgoKSmFpaHl1bmcgQ2hvICAgICAgICAg
ICAgICAgIEV4cGlyZXMgSnVuZSAyMDA1ICAgICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKCiAg
UmVxdWlyZW1lbnQgZm9yIChHKU1QTFMgaW1wbGFudGF0aW9uIG92ZXIgRXRoZXJuZXQgICAgICBE
ZWNlbWJlciAyMDA0CgoKCiAgICAgQW4gZXhwbGljaXQgZmxvdy1zdGF0ZSBhbGxvY2F0aW9uIHVz
aW5nIFVOSSBzaWduYWxpbmcgcHJvdG9jb2wgbWF5CiAgICAgcHJvdmlkZSBzaW1wbGUgYW5kIGNs
ZWFyIHNvbHV0aW9uIGZvciBwZXItZmxvdyBwb2xpY2luZyBpbiBhY2Nlc3MKICAgICBzd2l0Y2gu
IEl0IHdpbGwgYWxzbyByZWR1Y2UgYnVyZGVuIGluIG1pZC1lbmQgc3dpdGNoZXMgaWYgdHJhZmZp
YwogICAgIGFnZ3JlZ2F0ZXMgYXJlIHByb3Blcmx5IG1hcmtlZCBhdCBhY2Nlc3Mgc3dpdGNoZXMu
IEhlbmNlLCAoRylNUExTCiAgICAgaW1wbGVtZW50YXRpb24gZm9yIEV0aGVybmV0IGFjY2VzcyBz
d2l0Y2hlcyBuZWVkIHRvIHNlZWsgc29sdXRpb24KICAgICBmb3IgbGlnaHQtd2VpZ2h0IFVOSSBz
aWduYWxpbmcgYW5kIGZvcmVmcm9udCB0YWdnaW5nIG9mIE1QTFMgbGFiZWxzCiAgICAgaW4gb3Jk
ZXIgdG8gZmFjaWxpdGF0ZSBlZmZpY2llbnQgbGFiZWwgc3dpdGNoaW5nIGluIGNvcmUgbmV0d29y
ay4KCiAgICAgTWVhbndoaWxlIGluIGNvcmUgbmV0d29yaywgaXQgaXMgZW52aXNhZ2VkIHRoYXQg
aGlnaC1wZXJmb3JtYW5jZQogICAgIEV0aGVybmV0IHN3aXRjaGVzIG1heSB0YWtlb3ZlciB0aGUg
cm9sZSBvZiBzb3BoaXN0aWNhdGVkIHJvdXRlcnMgaW4KICAgICBzb21lIHByb3ZpZGVyIG5ldHdv
cmsuIEluIG5ldHdvcmsgd2hlcmUgbGF5ZXItMiBzd2l0Y2hlcyBjb25zdGl0dXRlCiAgICAgY29y
ZSwgZGlmZmVyZW50IHNldCBvZiByZXF1aXJlbWVudHMgbXVzdCBiZSBzYXRpc2ZpZWQuIFJlbGlh
YmlsaXR5LAogICAgIHNjYWxhYmlsaXR5IGFuZCBxdWFsaXR5IG9mIHNlcnZpY2UgYXJlIHRoZSBp
c3N1ZXMgZnJlcXVlbnRseQogICAgIHJhaXNlZC4gVGhlIG1haW4gY29uY2VwdCBhbmQgZmVhdHVy
ZXMgZGV2ZWxvcGVkIGZvciBNUExTIHJvdXRlcnMKICAgICBjYW4gYmUgbW9kaWZpZWQgYW5kIGVt
cGxveWVkIGZvciBFdGhlcm5ldC4gSG93ZXZlciBzb21lCiAgICAgc2ltcGxpZmljYXRpb24gaXMg
bmVjZXNzYXJ5IGR1ZSB0byBsaW1pdGF0aW9uIGluIGV4cHJlc3NpbmcgZGl2ZXJzCiAgICAgZnVu
Y3Rpb25zIHVzaW5nIE1BQyBoZWFkZXIuCgoKCjQuIENvbmNsdXNpb24KCiAgICAgSW4gb3ZlcmFs
bCwgd2hpbGUgdGhlIHNvbHV0aW9ucyBmb3IgKEcpTVBMUyBpbXBsZW1lbnRhdGlvbiBhdCBlYWNo
CiAgICAgaGllcmFyY2h5IG9mIEV0aGVybmV0IG1heSBpbmRlcGVuZGVudGx5IGJlIGRldmVsb3Bl
ZCwgdGhlIHNvbHV0aW9ucwogICAgIG11c3QgcHJvdmlkZSBpbnRlci1vcGVyYWJpbGl0eSB3aXRo
IE1QTFMgbmV0d29yay4KCiAgICAgSXQgaXMgYWxzbyBub3RlZCB0aGF0IGVmZmljaWVuY3kgaXMg
dXN1YWxseSBub3QgdGhlIHByaW1lIGNvbmNlcm4KICAgICB0aGFuIHNpbXBsaWNpdHkgYmVjYXVz
ZSBFdGhlcm5ldCB3aWxsIGxvc2UgY29tcGV0aXRpdmVuZXNzIHRvCiAgICAgcm91dGVycyBpZiBh
bnkgYWRkZWQgY29tcGxleGl0eSBvdmVycmlkZXMgZWNvbm9taWMgbWVyaXQuCgoKCjUuIFNlY3Vy
aXR5IENvbnNpZGVyYXRpb25zCgogICAgIFRoZSBpc3N1ZXMgYXJlIGFkZHJlc3NlZCBpbiBzZWN0
aW9uIDMKCgoKNi4gUmVmZXJlbmNlcwoKCgogW1JGQzMwMzFdICAgRS4gUm9zZW4sIEEuIFZpc3dh
bmF0aGFuLCBSLiBDYWxsb24sCiAgICAgICAgICAgICAgICJNdWx0aXByb3RvY29sIExhYmVsIFN3
aXRjaGluZyBBcmNoaXRlY3R1cmUiLCBSRkMgMzAzMSwKICAgICAgICAgICAgIEphbi4gMjAwMQog
W0dBUkNIXSAgICAgRXJpYyBNYW5uaWUsICJHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2NvbAogICAg
ICAgICAgICAgTGFiZWwgU3dpdGNoaW5nIEFyY2hpdGVjdHVyZSIsIElFVEYgZHJhZnQtaWV0Zi1j
Y2FtcC0KICAgICAgICAgICAgIGdtcGxzLWFyY2hpdGVjdHVyZS0wNy50eHQsIE1heSAyMDAzCiBb
TDJWUE5dICAgICBMb2EgQW5kZXJzc29uLCBFcmljIEMuIFJvc2VuLCAiTDJWUE4gRnJhbWV3b3Jr
IiwKICAgICAgICAgICAgIGRyYWZ0LWlldGYtbDJ2cG4tbDItZnJhbWV3b3JrLTAzLnR4dCwgT2N0
LiAyMDAzCgoKCgpKYWloeXVuZyBDaG8gICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDIwMDUg
ICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDAoKICBSZXF1aXJlbWVudCBmb3IgKEcpTVBMUyBp
bXBsYW50YXRpb24gb3ZlciBFdGhlcm5ldCAgICAgIERlY2VtYmVyIDIwMDQKCgogW1BCUklER0Vd
ICAgSUVFRSwgIlByb3ZpZGVyIEJyaWRnZXMiLCA4MDIuMWFkLCB3b3JrIGluIHByb2dyZXNzCiBb
S0FXQUtBTUldICBULiBLYXdha2FtaSBldCBhbC4sICJNZXRob2QgdG8gU2V0dXAgTFNQIHVzaW5n
CiAgICAgICAgICAgICBWTEFOIFRhZyBTd2l0Y2hpbmciLCBkcmFmdC1rYXdha2FtaS1tcGxzLWxz
cC0KICAgICAgICAgICAgIHZsYW4tMDAudHh0LCBGZWIuIDIwMDMKIFtTVFBdICAgICAgIElFRUUs
ICJNZWRpYSBBY2Nlc3MgQ29udHJvbCAoTUFDKSBCcmlkZ2VzIiw4MDIuMUQsCiAgICAgICAgICAg
ICBBTlNJL0lFRUUgU3RhbmRhcmQgRG9jdW1lbnQsIDE5OTgKIFtNU1RQXSAgICAgIElFRUUgIk11
bHRpcGxlIFNwYW5uaW5nIFRyZWVzIiwgODAyLjFzLCAyMDAyCiBbUkZDMjgxNF0gICBSLiBZYXZh
dGthciwgRC4gSG9mZm1hbiwgWS4gQmVybmV0LCBGLiBCYWtlciwKICAgICAgICAgICAgIE0uIFNw
ZWVyLCAiU0JNIChTdWJuZXQgQmFuZHdpZHRoIE1hbmFnZXIpOiBBIFByb3RvY29sCiAgICAgICAg
ICAgICBmb3IgUlNWUC1iYXNlZCBBZG1pc3Npb24gQ29udHJvbCBvdmVyIElFRUUgODAyLXN0eWxl
CiAgICAgICAgICAgICBuZXR3b3JrcyIsIFJGQyAyODE0LCBNYXkgMjAwMAogW1JGQzI4MTVdICAg
TS4gU2VhbWFuLCBBLiBTbWl0aCwgRS4gQ3Jhd2xleSwgSi4gV3JvY2xhd3NraSwKICAgICAgICAg
ICAgICJJbnRlZ3JhdGVkIFNlcnZpY2UgTWFwcGluZ3Mgb24gSUVFRSA4MDIgTmV0d29ya3MiLAog
ICAgICAgICAgICAgUkZDIDI4MTUsIE1heSAyMDAwCiBbUkZDMjgxNl0gICBBLiBHaGFud2FuaSwg
Vy4gUGFjZSwgVi4gU3Jpbml2YXNhbiwgQS4gU21pdGgsCiAgICAgICAgICAgICBNLiBTZWFtYW4s
ICJBIEZyYW1ld29yayBmb3IgSW50ZWdyYXRlZCBTZXJ2aWNlcwogICAgICAgICAgICAgT3ZlciBT
aGFyZWQgYW5kIFN3aXRjaGVkIElFRUUgODAyIExBTiBUZWNobm9sb2dpZXMiLAogICAgICAgICAg
ICAgUkZDIDI4MTYsIE1heSAyMDAwCiBbUkZDMjk5OF0gICBZLiBCZXJuZXQsIGV0LiBhbCwgQSBG
cmFtZXdvcmsgZm9yIEludGVncmF0ZWQKICAgICAgICAgICAgIFNlcnZpY2VzIE9wZXJhdGlvbiBv
dmVyIERpZmZzZXJ2IE5ldHdvcmtzIiwKICAgICAgICAgICAgIFJGQyAyOTk4LCBOb3YuIDIwMDAK
IFtSRkMzMDMyXSAgIEUuIFJvc2VuLCBELiBUYXBwYW4sIEcuIEZlZG9ya293LCBZLiBSZWtodGVy
LAogICAgICAgICAgICAgRC4gRmFyaW5hY2NpLCBULiBMaSwgQS4gQ29udGEsICJNUExTIExhYmVs
IFN0YWNrCiAgICAgICAgICAgICBFbmNvZGluZyIsIFJGQyAzMDMyLCBKYW4uIDIwMDEKIFtBVFJJ
Q0FdICAgIEF0cmljYSwgaHR0cDovL3d3dy5hdHJpY2EuY29tCiBbU1JJTklWQVNBTl0gRC4gQnVz
c2llcmUsIEguIEVzYWtpLCBBLiBHaGFud2FuaSwgUy4gTWF0c3V6YXdhLAogICAgICAgICAgICAg
IEouVy5QYWNlLFYuU3Jpbml2YXNhbiwiTGFiZWxzIGZvciBNUExTIG92ZXIgTEFOCiAgICAgICAg
ICAgICAgTWVkaWEiLCAgZHJhZnQtc3Jpbml2YXNhbi1tcGxzLWxhbnMtbGFiZWwtMDAudHh0LAog
ICAgICAgICAgICAgIEF1Zy4xOTk3CiBbRVRIUkVBTDFdICBTLiBWYXJhZGFyYWphbiwgVC4gQ2hp
dWVoLCAiRXRoZVJlYWw6IGEKICAgICAgICAgICAgIGhvc3QtdHJhbnNwYXJlbnQgcmVhbC10aW1l
IEZhc3QgRXRoZXJuZXQgc3dpdGNoIiwKICAgICAgICAgICAgIFNpeHRoIEludGVybmF0aW9uYWwg
Q29uZmVyZW5jZSBvbiBOZXR3b3JrIFByb3RvY29scywKICAgICAgICAgICAgIHAxMi0yMSwxOTk4
CiBbRVRIUkVBTDJdICBTLiBWYXJhZGFyYWphbiwgIkV4cGVyaWVuY2VzIHdpdGggRXRoZVJlYWw6
CiAgICAgICAgICAgICBhIGZhdWx0LXRvbGVyYW50IHJlYWwtdGltZSBFdGhlcm5ldCBzd2l0Y2gi
LCBFVEZBCiAgICAgICAgICAgICAyMDAxLiA4dGggSW50ZXJuYXRpb25hbCBDb25mZXJlbmNlIG9u
IEVtZXJnaW5nCiAgICAgICAgICAgICBUZWNobm9sb2dpZXMgYW5kIEZhY3RvcnkgQXV0b21hdGlv
biwgUHJvY2VlZGluZ3MsIAoJICAgICB2b2wuMSwgcDE4My0xOTQsIDIwMDEKIFtFVEhSRUFMM10g
IFMuIFZhcmFkYXJhamFuLCBULiBDaGl1ZWgsICJBdXRvbWF0aWMgZmF1bHQgZGV0ZWN0aW9uCiAg
ICAgICAgICAgICBhbmQgcmVjb3ZlcnkgaW4gcmVhbCB0aW1lIHN3aXRjaGVkIEV0aGVybmV0CiAg
ICAgICAgICAgICBuZXR3b3JrcyIsIElFRUUgSU5GT0NPTSAnOTksIHZvbC4xLCBwMTYxLTE2OSwg
MTk5OQogW0ZMT1dST1VURVJdIEouIFcuIFJvYmVydHMsICJJbnRlcm5ldCBUcmFmZmljLCBRb1Ms
IGFuZCBQcmljaW5nIiwKICAgICAgICAgICAgIFByb2NlZWRpbmdzIG9mIHRoZSBJRUVFLCB2b2wu
OTIsIG5vLiA5LCBwMTM4OS0xMzk5LAogICAgICAgICAgICAgc2VwLiAyMDA0CgoKQXV0aG9ycycg
QWRkcmVzc2VzCgogICAgICAgSmFpaHl1bmcgQ2hvCiAgICAgICBCY04gTGFiLgogICAgICAgRVRS
SQogICAgICAgMTYxIEdhamVvbmctRG9uZywgWXVzZW9uZy1HdSwgRGFlamVvbiAzMDUtMzUwLCBL
b3JlYQoKCgoKSmFpaHl1bmcgQ2hvICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAyMDA1ICAg
ICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKCiAgIFJlcXVpcmVtZW50IGZvciAoRylNUExTIGlt
cGxhbnRhdGlvbiBvdmVyIEV0aGVybmV0ICAgICAgRGVjZW1iZXIgMjAwNAoKCiAgICAgICBQaG9u
ZTogKzgyIDQyIDg2MCA1NTE0CiAgICAgICBFbWFpbDogamFpaHl1bmdAZXRyaS5yZS5rcgoKCklu
dGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQKCiAgICAgVGhlIElFVEYgdGFrZXMgbm8gcG9z
aXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkKICAgICBJbnRlbGxl
Y3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWlt
ZWQKICAgICB0byBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRl
Y2hub2xvZ3kgZGVzY3JpYmVkCiAgICAgaW4gdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRv
IHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2gKICAgICByaWdodHMgbWlnaHQgb3IgbWlnaHQg
bm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQKICAgICBpdCBoYXMg
bWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4K
ICAgICBJbmZvcm1hdGlvbiBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRz
IGluIFJGQwogICAgIGRvY3VtZW50cyBjYW4gYmUgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzku
CgogICAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRh
cmlhdCBhbmQgYW55CiAgICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWls
YWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbgogICAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBn
ZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZQogICAgIG9mIHN1Y2ggcHJv
cHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzCiAgICAgc3Bl
Y2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBv
c2l0b3J5CiAgICAgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuCgogICAgIFRoZSBJRVRGIGlu
dml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkK
ICAgICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVy
IHByb3ByaWV0YXJ5CiAgICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBt
YXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50CiAgICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBh
ZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdAogICAgIGlldGYtaXByQGlldGYu
b3JnLgoKCkRpc2NsYWltZXIgb2YgVmFsaWRpdHkKCiAgICAgVGhpcyBkb2N1bWVudCBhbmQgdGhl
IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uCiAgICAgYW4gIkFT
IElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRQog
ICAgIFJFUFJFU0VOVFMgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQg
U09DSUVUWSBBTkQKICAgICBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVND
TEFJTSBBTEwgV0FSUkFOVElFUywKICAgICBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORyBC
VVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQKICAgICBUSEUgVVNFIE9GIFRIRSBJ
TkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUgogICAgIEFO
WSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEK
ICAgICBQQVJUSUNVTEFSIFBVUlBPU0UuCgoKQ29weXJpZ2h0IFN0YXRlbWVudAoKICAgICBDb3B5
cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4gIFRoaXMgZG9jdW1lbnQgaXMK
ICAgICBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29u
dGFpbmVkIGluIEJDUAogICAgIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0
aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyCiAgICAgcmlnaHRzLgoKCgoKCgoKCkphaWh5dW5n
IENobyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMjAwNSAgICAgICAgICAgICAgICAgICBb
UGFnZSA3XQoMCg==

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



Envelope-to: [e-mail]
Delivery-date: Fri, 03 Dec 2004 23:16:43 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: RE: New charter
Date: Fri, 3 Dec 2004 15:15:26 -0800
Message-ID: <009401c4d98d$f9264ef0$453ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Kireeti Kompella
> Sent: Tuesday, November 23, 2004 10:22 PM
> To: [e-mail]
> 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.
> 
> 




Envelope-to: [e-mail]
Delivery-date: Fri, 03 Dec 2004 22:46:10 +0000
Message-ID: <[e-mail]>
From: Payam Torab <[e-mail]>
To: 'Kireeti Kompella' <[e-mail]>, [e-mail]
Subject: RE: New charter
Date: Fri, 3 Dec 2004 17:38:18 -0500 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D988.C87F4982"

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: [e-mail] [mailto:[e-mail]]On
Behalf Of Kireeti Kompella
Sent: Wednesday, November 24, 2004 1:22 AM
To: [e-mail]
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: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</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: [e-mail]</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--



Envelope-to: [e-mail]
Delivery-date: Fri, 03 Dec 2004 10:11:28 +0000
Message-ID: <[e-mail]>
Date: Fri, 03 Dec 2004 11:09:26 +0100
From: Ugo Monaco <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To:  [e-mail]
CC:  [e-mail], Vishal Sharma <[e-mail]>,  "Alessio D'Achille" <[e-mail]>, =?ISO-8859-1?Q?Daniele_Al=EC?= <[e-mail]>,  Marco Listanti <[e-mail]>
Subject: Re: Draft minutes from Tove
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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: [phone]                             00184 Roma (Italy)
E-mail: [e-mail]               Fax: [phone]
*********************************************************************



Envelope-to: [e-mail]
Delivery-date: Fri, 03 Dec 2004 07:17:18 +0000
Message-Id: <6.0.0.20.2.20041203154327.0394b830@129.60.5.226>
Date: Fri, 03 Dec 2004 15:45:15 +0900
To: Kireeti Kompella <[e-mail]>
From: "[e-mail]" <[e-mail]>
Subject: Re: New charter
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

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: [phone], fax: [phone]
$B")(B180-8585$B!!IpB"Ln;TNPD.(B3-9-11 H11F
************************************************ 





Envelope-to: [e-mail]
Delivery-date: Thu, 02 Dec 2004 22:24:27 +0000
Message-Id: <6.1.2.0.2.20041202095529.03de4fc0@mo-ex1>
Date: Thu, 02 Dec 2004 10:12:02 -0500
To: "Kireeti Kompella" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: New charter
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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: [e-mail]
Delivery-date: Wed, 01 Dec 2004 00:19:16 +0000
Message-ID: <B258A372CEA20246A363BB86753DB5360102F2EA@zrtphxm2>
From: "Don Fedyk" <[e-mail]>
To: Kireeti Kompella <[e-mail]>, [e-mail]
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