RE: A new ID is available on the repository draft-caviglia-ccamp- pc-and-sc-reqs-00

["Pandian, Vijay" <[e-mail]>]

Adrian and Dimitri,

Not sure why we need extra requirements to handle this case. Also not sure
why CP needs to guarantee identical states at [a] and [b]. May be I am not
understanding the case that is being pictured here.

The way I read the requirements, once the control is transferred to MP
(i.e., CP[a] -> MP), CP should forget everything about this LSP, Isn't it? 

If this is true, then MP -> CP[b] should be treated as the ONLY general case
of MP -> CP conversion, right?

Regards,
Vijay


-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Wednesday, May 31, 2006 7:18 PM
To: [e-mail]
Cc: [e-mail]; Diego Caviglia; Dino Bramanti
Subject: Re: A new ID is available on the repository
draft-caviglia-ccamp-pc-and-sc-reqs-00


Interesting question.

It would certainly be the case that the picture you draw could arise. I 
guess we would describe this in terms of SPCs. Is it necessary that 
identical state is held at [a] and [b]. In particular, the question of 
Session ID and LSP ID spring to mind.

Yes, we need clear requirements for this type of situation.  Want to suggest

some?

Adrian

----- Original Message ----- 
From: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "Diego Caviglia" <[e-mail]>; 
"Dino Bramanti" <[e-mail]>
Sent: Wednesday, May 31, 2006 7:44 PM
Subject: Re: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00


> agreed -
>
> question: in case of move CP->MP who guarantees that the CP at state [b]
> retrieves its states it had at [a] e.g.
>
> MP->CP[a]->MP->CP[b]?
>
> do we need a specific requirement for this case ?
>
>
>
>
>
>
> "Adrian Farrel" <[e-mail]>
> Sent by: [e-mail]
> 25/05/2006 19:53
> Please respond to "Adrian Farrel"
>
>        To:     <[e-mail]>, "Diego Caviglia"
> <[e-mail]>
>        cc:     "Dan Li <danli", "Dino Bramanti"
> <[e-mail]>
>        Subject:        Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Hi Diego,
>
> Thanks for putting this I-D together. I think it gives a much clearer
> picture of what you are trying to achieve with your discussion of moving
> control of an LSP between the management plane and the control plane.
>
> This seems like a reasonable set of requirements to me, and I would like
> to
> see some discussion from folk on whether they think this is valuable work,
>
> and whether we should start to look for protocol solutions.
>
> Thanks,
> Adrian
>
> ----- Original Message ----- 
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
> <[e-mail]>
> Sent: Wednesday, May 24, 2006 8:48 AM
> Subject: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
>>A new ID is available on the ID repository
>>
>
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.t
xt
> .
>>
>> The ID states some basic requrements for the possibility of turning a
>> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and
> vice
>> versa, without actually affecting Data Plane traffic, no solutions are
>> proposed in the ID.
>>
>> Abstract
>>
>>   From a Carrier perspective, the possibility of turning a Permanent
>>   Connection (PC) into a Soft Permanent Connection (SPC) and vice
>>   versa, without actually affecting Data Plane traffic being carried
>>   over it, is a valuable option. In other terms, such operation can be
>>   seen as a way of transferring the ownership and control of an
>>   existing and in-use Data Plane connection between the Management
>>   Plane and the Control Plane, leaving its Data Plane state untouched.
>>   This memo sets out the requirements for such procedures within a
>>   Generalized Multiprotocol Label Switching (GMPLS) network.
>>
>>
>> Comments and suggestions are very welcome sxpecially from the carrier
>> community.
>>
>> Regards
>>
>> Diego
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
> 







Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 23:18:48 +0000
Message-ID: <0f1401c68508$8b29e8d0$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Diego Caviglia" <[e-mail]>, "Dino Bramanti" <[e-mail]>
Subject: Re: A new ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
Date: Thu, 1 Jun 2006 00:18:10 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Interesting question.

It would certainly be the case that the picture you draw could arise. I 
guess we would describe this in terms of SPCs. Is it necessary that 
identical state is held at [a] and [b]. In particular, the question of 
Session ID and LSP ID spring to mind.

Yes, we need clear requirements for this type of situation.  Want to suggest 
some?

Adrian

----- Original Message ----- 
From: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "Diego Caviglia" <[e-mail]>; 
"Dino Bramanti" <[e-mail]>
Sent: Wednesday, May 31, 2006 7:44 PM
Subject: Re: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00


> agreed -
>
> question: in case of move CP->MP who guarantees that the CP at state [b]
> retrieves its states it had at [a] e.g.
>
> MP->CP[a]->MP->CP[b]?
>
> do we need a specific requirement for this case ?
>
>
>
>
>
>
> "Adrian Farrel" <[e-mail]>
> Sent by: [e-mail]
> 25/05/2006 19:53
> Please respond to "Adrian Farrel"
>
>        To:     <[e-mail]>, "Diego Caviglia"
> <[e-mail]>
>        cc:     "Dan Li <danli", "Dino Bramanti"
> <[e-mail]>
>        Subject:        Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Hi Diego,
>
> Thanks for putting this I-D together. I think it gives a much clearer
> picture of what you are trying to achieve with your discussion of moving
> control of an LSP between the management plane and the control plane.
>
> This seems like a reasonable set of requirements to me, and I would like
> to
> see some discussion from folk on whether they think this is valuable work,
>
> and whether we should start to look for protocol solutions.
>
> Thanks,
> Adrian
>
> ----- Original Message ----- 
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti"
> <[e-mail]>
> Sent: Wednesday, May 24, 2006 8:48 AM
> Subject: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
>>A new ID is available on the ID repository
>>
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.txt
> .
>>
>> The ID states some basic requrements for the possibility of turning a
>> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and
> vice
>> versa, without actually affecting Data Plane traffic, no solutions are
>> proposed in the ID.
>>
>> Abstract
>>
>>   From a Carrier perspective, the possibility of turning a Permanent
>>   Connection (PC) into a Soft Permanent Connection (SPC) and vice
>>   versa, without actually affecting Data Plane traffic being carried
>>   over it, is a valuable option. In other terms, such operation can be
>>   seen as a way of transferring the ownership and control of an
>>   existing and in-use Data Plane connection between the Management
>>   Plane and the Control Plane, leaving its Data Plane state untouched.
>>   This memo sets out the requirements for such procedures within a
>>   Generalized Multiprotocol Label Switching (GMPLS) network.
>>
>>
>> Comments and suggestions are very welcome sxpecially from the carrier
>> community.
>>
>> Regards
>>
>> Diego
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 23:16:20 +0000
Message-ID: <0f0901c68508$2a6b1050$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "WALTER ROTHKEGEL" <[e-mail]>
Subject: Re: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
Date: Thu, 1 Jun 2006 00:15:04 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Dimitri,

> adrian - what does the term "broadcast" connection refers to in the below
> message ?

Well, Walter is the best person to ask since it was his message.

> afaik in the context of MPLS-TE/GMPLS: p2p, and p2mp TE LSPs are
> considered isn'it ?

Some parsing problems on your sentence, but I think you are saying what I 
thought when I read this.

Effectively, I assumed that "broadcast connection" and "multicast 
connection" were intended to be synonyms for P2MP LSP (possibly with slight 
differences in usage maybe through label stacking).

Adrian

> "Adrian Farrel" <[e-mail]>
> Sent by: [e-mail]
> 31/05/2006 19:13
> Please respond to "Adrian Farrel"
>
>        To:     "WALTER ROTHKEGEL" <[e-mail]>
>        cc:     <[e-mail]>, "Diego Caviglia"
> <[e-mail]>, "Dan Li <danli", "Dino Bramanti"
> <[e-mail]>
>        Subject:        Re: A nerw ID is available on the repository
> draft-caviglia-ccamp-pc-and-sc-reqs-00
>
>
> Hi Walter,
>
> Thanks for your thoughts.
>
> May I restate them to make sure that I understand?
>
>> While I think these requirements are real, I can not imagine that they
>> can be solved by some protocol extensions.
>
> If I am interpretting you correctly, you are saying that you agree with
> the
> requirements. This means that *if* they can be solved, you would be quite
> pleased. And even if they could only be solved in certain control
> situations, you would also think that a good thing.
>
> On the other hand, you are skeptical that a solution can be developed.
> Presumably, this means that you would not want to spend your time
> attempting
> to develop one, or see the WG expend much bandwidth on trying to find a
> way
> to meet the requirements. But I don't suppose you would object if the
> authors of this I-D spent their own time trying to hatch a solution and
> then
> brought it to the working group for discussion.
>
>> One reason is, as it is stated in the I_D, that "ownership by the
>> Management
>> and Control Planes is strictly an implementation issue", which we can
> not
>> solve by a protocol alone.
>
> Hmmm. Yeah I guess it could be a problem if a device determined that it
> would not allow resources to be exchanged between the two planes. Handling
>
> (or, more precisely, not handling) NEs that do not support these funcitons
>
> certainly has to be discussed. I suppose there are two situations:
> 1. As you describe, the LSP cannot be shifted. I.e. the LSR understands
>  the request but is unable or unwilling to comply.
> 2. The LSR does not understand the request. I.e. it has not been
>  upgraded to handle the protocol solution.
>
> I think this is actually business as usual for protocol work, isn't it?
>
>> Secondly, the MP and CP typically store additional data associated with
>> the
>> connection, which is implementation specific, but needs also appropriate
>> conversion, or the conversion must at least ensure data integrity.
>
> I'd be intrigued to know what additional informaiton a standard GMPLS
> control plane is going to store over and above what is signaled by the
> protocol. So the problem you describe is lopsided - if the MP and CP are
> capable of storing the additional information then I think there is no
> issue
> (and presumably everything is the same implementation-specific stuff). But
>
> if there are differences in implmentations in the CP, then they must be
> running some common set of protocol extensions and it is this that needs
> to
> be converted to/from the MP.
>
> Note that if the MP offers the ability to configure things on an NE that
> cannot be carried in signaling then those things cannot bve carried in
> signaling, period. That is, you cannot consider provisioning an LSP in the
>
> CP at all if you need to carry this information. Fortunately, we are not
> having a discussion on the relative merits of using a control plane - the
> situation we are examining is one where the operator (the customer!) has
> decided to move ownership of an LSP between planes, and wants to know how
> to
> do it. That means that the operator has already accepted that the LSP can
> be
> managed by both planes and wishes to make the transfer without turning the
>
> service down.
>
>> Finally, need to look, what is convertible at all. E.g., the MP may have
>> implemented certain broadcast or multicast connections, or special
>> protection
>> schemes, which are not (yet) supported by the CP.
>
> Yes, there is the possiblity that certain services in the MP cannot be
> achieved in the CP (although it would be interesting to discuss which,
> because if there is a need, the control plane is surely in need of
> enhancement). So you are right, there may be some LSPs that cannot be
> migrated in this way. But what about those that can? Do you think we
> should
> at least consider these requirements for those LSPs that can be migrated?
>
> Many thanks,
> Adrian
>
>
>
>
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 23:05:38 +0000
Message-ID: <0edb01c68506$7bc3df10$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Thomas D. Nadeau" <[e-mail]>, <[e-mail]>
Subject: Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt 
Date: Thu, 1 Jun 2006 00:00:46 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We have put together a first cut of a MIB module for P2MP MPLS-TE.

This is intended to also work for P2MP GMPLS so please review it and 
comment. Comments would best be made on the MPLS mailing list so that all 
discussion of the document are kept in one place.

Cheers,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, May 31, 2006 8:50 PM
Subject: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt


>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
> Title : Point-to-Multipoint Multiprotocol Label
>                          Switching (MPLS) Traffic Engineering (TE)
>                          Management Information Base (MIB) module
> Author(s) : A. Farrel, et al.
> Filename : draft-farrel-mpls-p2mp-te-mib-00.txt
> Pages : 36
> Date : 2006-5-31
>
>   This memo defines a portion of the Management Information Base
>   for use with network management protocols in the Internet community.
>   In particular, it describes managed objects for point-to-multipoint
>   Multiprotocol Label Switching-based traffic engineering.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-mpls-p2mp-te-mib-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] with the word unsubscribe in the body of the 
> message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-farrel-mpls-p2mp-te-mib-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-farrel-mpls-p2mp-te-mib-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>


--------------------------------------------------------------------------------


> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 19:49:42 +0000
Date: Wed, 31 May 2006 14:48:24 -0500
From: Young Lee <[e-mail]>
Subject: a new internet draft
To: [e-mail], [e-mail]
Cc: "James.Zhu" <[e-mail]>
Message-id: <000a01c684eb$2dba4180$[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_ZqT/i4M9/90b0oq8d4LvsQ)"
Thread-index: AcaE6y1AxIyUUwPdRviXO83vBvWlOA==

This is a multi-part message in MIME format.

--Boundary_(ID_ZqT/i4M9/90b0oq8d4LvsQ)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

Hi all,

 

A new internet draft is available on the ID repository. 

 

http://www.ietf.org/internet-drafts/draft-lee-ccamp-pce-policy-recovery-00.t
xt

 

Abstract: 

 

This document describes a framework for policy-based protection/ restoration
mechanism 
in GMPLS network.  This document provides the definition for recovery
policy, architecture 
framework and the protocol requirements to be able to support policy-based
recovery 
mechanism.

 

Comments and suggestions will be appreciated. 

 

Best regards,

 

Young Lee

Huawei Technologies (USA)


--Boundary_(ID_ZqT/i4M9/90b0oq8d4LvsQ)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:&#23435;&#20307;;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Arial Unicode MS";
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:"\@&#23435;&#20307;";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"\@Arial Unicode MS";
	panose-1:2 11 6 4 2 2 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:&#23435;&#20307;;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=ZH-CN link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>Hi all,</span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>A new internet draft is available on the ID repository.
</span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'><a
href="http://www.ietf.org/internet-drafts/draft-lee-ccamp-pce-policy-recovery-00.txt">http://www.ietf.org/internet-drafts/draft-lee-ccamp-pce-policy-recovery-00.txt</a></span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>Abstract: </span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<pre><font size=3 face=Arial><span lang=EN-US style='font-size:12.0pt;
font-family:Arial'>This document describes a framework for policy-based protection/ restoration mechanism </span></font></pre><pre><font
size=3 face=Arial><span lang=EN-US style='font-size:12.0pt;font-family:Arial'>in GMPLS network.&nbsp; This document provides the definition for recovery policy, architecture </span></font></pre><pre><font
size=3 face=Arial><span lang=EN-US style='font-size:12.0pt;font-family:Arial'>framework and the protocol requirements to be able to support policy-based recovery </span></font></pre><pre><font
size=3 face=Arial><span lang=EN-US style='font-size:12.0pt;font-family:Arial'>mechanism.</span></font></pre>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>Comments and suggestions will be appreciated. </span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>Best regards,</span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=EN-US style='font-size:
12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=DE style='font-size:12.0pt;
font-family:Arial'>Young Lee</span></font></p>

<p class=MsoNormal><font size=3 face=Arial><span lang=DE style='font-size:12.0pt;
font-family:Arial'>Huawei Technologies (USA)</span></font></p>

</div>

</body>

</html>

--Boundary_(ID_ZqT/i4M9/90b0oq8d4LvsQ)--



Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 18:45:12 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], "Diego Caviglia" <[e-mail]>, "Dino Bramanti" <[e-mail]>
Subject: Re: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 31 May 2006 20:44:54 +0200
Content-Type: text/plain; charset="US-ASCII"

agreed -

question: in case of move CP->MP who guarantees that the CP at state [b] 
retrieves its states it had at [a] e.g.

MP->CP[a]->MP->CP[b]? 

do we need a specific requirement for this case ?






"Adrian Farrel" <[e-mail]>
Sent by: [e-mail]
25/05/2006 19:53
Please respond to "Adrian Farrel"
 
        To:     <[e-mail]>, "Diego Caviglia" 
<[e-mail]>
        cc:     "Dan Li <danli", "Dino Bramanti" 
<[e-mail]>
        Subject:        Re: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00


Hi Diego,

Thanks for putting this I-D together. I think it gives a much clearer 
picture of what you are trying to achieve with your discussion of moving 
control of an LSP between the management plane and the control plane.

This seems like a reasonable set of requirements to me, and I would like 
to 
see some discussion from folk on whether they think this is valuable work, 

and whether we should start to look for protocol solutions.

Thanks,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[e-mail]>
To: <[e-mail]>
Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti" 
<[e-mail]>
Sent: Wednesday, May 24, 2006 8:48 AM
Subject: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00


>A new ID is available on the ID repository
> 
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.txt
.
>
> The ID states some basic requrements for the possibility of turning a
> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and 
vice
> versa, without actually affecting Data Plane traffic, no solutions are
> proposed in the ID.
>
> Abstract
>
>   From a Carrier perspective, the possibility of turning a Permanent
>   Connection (PC) into a Soft Permanent Connection (SPC) and vice
>   versa, without actually affecting Data Plane traffic being carried
>   over it, is a valuable option. In other terms, such operation can be
>   seen as a way of transferring the ownership and control of an
>   existing and in-use Data Plane connection between the Management
>   Plane and the Control Plane, leaving its Data Plane state untouched.
>   This memo sets out the requirements for such procedures within a
>   Generalized Multiprotocol Label Switching (GMPLS) network.
>
>
> Comments and suggestions are very welcome sxpecially from the carrier
> community.
>
> Regards
>
> Diego
>
>
>
>
>
> 








Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 18:38:19 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], "Diego Caviglia" <[e-mail]>, "Dino Bramanti" <[e-mail]>, [e-mail], "WALTER ROTHKEGEL" <[e-mail]>, "Diego Caviglia" <[e-mail]>
Subject: Re: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 31 May 2006 20:37:45 +0200
Content-Type: text/plain; charset="US-ASCII"

adrian - what does the term "broadcast" connection refers to in the below 
message ?

afaik in the context of MPLS-TE/GMPLS: p2p, and p2mp TE LSPs are 
considered isn'it ?





"Adrian Farrel" <[e-mail]>
Sent by: [e-mail]
31/05/2006 19:13
Please respond to "Adrian Farrel"
 
        To:     "WALTER ROTHKEGEL" <[e-mail]>
        cc:     <[e-mail]>, "Diego Caviglia" 
<[e-mail]>, "Dan Li <danli", "Dino Bramanti" 
<[e-mail]>
        Subject:        Re: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00


Hi Walter,

Thanks for your thoughts.

May I restate them to make sure that I understand?

> While I think these requirements are real, I can not imagine that they
> can be solved by some protocol extensions.

If I am interpretting you correctly, you are saying that you agree with 
the 
requirements. This means that *if* they can be solved, you would be quite 
pleased. And even if they could only be solved in certain control 
situations, you would also think that a good thing.

On the other hand, you are skeptical that a solution can be developed. 
Presumably, this means that you would not want to spend your time 
attempting 
to develop one, or see the WG expend much bandwidth on trying to find a 
way 
to meet the requirements. But I don't suppose you would object if the 
authors of this I-D spent their own time trying to hatch a solution and 
then 
brought it to the working group for discussion.

> One reason is, as it is stated in the I_D, that "ownership by the 
> Management
> and Control Planes is strictly an implementation issue", which we can 
not
> solve by a protocol alone.

Hmmm. Yeah I guess it could be a problem if a device determined that it 
would not allow resources to be exchanged between the two planes. Handling 

(or, more precisely, not handling) NEs that do not support these funcitons 

certainly has to be discussed. I suppose there are two situations:
1. As you describe, the LSP cannot be shifted. I.e. the LSR understands
  the request but is unable or unwilling to comply.
2. The LSR does not understand the request. I.e. it has not been
  upgraded to handle the protocol solution.

I think this is actually business as usual for protocol work, isn't it?

> Secondly, the MP and CP typically store additional data associated with 
> the
> connection, which is implementation specific, but needs also appropriate
> conversion, or the conversion must at least ensure data integrity.

I'd be intrigued to know what additional informaiton a standard GMPLS 
control plane is going to store over and above what is signaled by the 
protocol. So the problem you describe is lopsided - if the MP and CP are 
capable of storing the additional information then I think there is no 
issue 
(and presumably everything is the same implementation-specific stuff). But 

if there are differences in implmentations in the CP, then they must be 
running some common set of protocol extensions and it is this that needs 
to 
be converted to/from the MP.

Note that if the MP offers the ability to configure things on an NE that 
cannot be carried in signaling then those things cannot bve carried in 
signaling, period. That is, you cannot consider provisioning an LSP in the 

CP at all if you need to carry this information. Fortunately, we are not 
having a discussion on the relative merits of using a control plane - the 
situation we are examining is one where the operator (the customer!) has 
decided to move ownership of an LSP between planes, and wants to know how 
to 
do it. That means that the operator has already accepted that the LSP can 
be 
managed by both planes and wishes to make the transfer without turning the 

service down.

> Finally, need to look, what is convertible at all. E.g., the MP may have
> implemented certain broadcast or multicast connections, or special 
> protection
> schemes, which are not (yet) supported by the CP.

Yes, there is the possiblity that certain services in the MP cannot be 
achieved in the CP (although it would be interesting to discuss which, 
because if there is a need, the control plane is surely in need of 
enhancement). So you are right, there may be some LSPs that cannot be 
migrated in this way. But what about those that can? Do you think we 
should 
at least consider these requirements for those LSPs that can be migrated?

Many thanks,
Adrian 








Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 17:44:54 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 May 2006 18:00:13 +0200
From: WALTER ROTHKEGEL <[e-mail]>
Organization: Lucent Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail], Diego Caviglia <[e-mail]>, "Dan Li <danli" <[e-mail]>, Dino Bramanti <[e-mail]>
Subject: Re: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Adrian,

some thoughts:

While I think these requirements are real, I can not imagine that they
can be solved by some protocol extensions.

One reason is, as it is stated in the I_D, that "ownership by the Management
and Control Planes is strictly an implementation issue", which we can not
solve by a protocol alone.

Secondly, the MP and CP typically store additional data associated with the
connection, which is implementation specific, but needs also appropriate
conversion, or the conversion must at least ensure data integrity.

Finally, need to look, what is convertible at all. E.g., the MP may have
implemented certain broadcast or multicast connections, or special protection
schemes, which are not (yet) supported by the CP.

Regards

Walter

On 25.05.2006 19:53, Adrian Farrel wrote:
> Hi Diego,
> 
> Thanks for putting this I-D together. I think it gives a much clearer 
> picture of what you are trying to achieve with your discussion of moving 
> control of an LSP between the management plane and the control plane.
> 
> This seems like a reasonable set of requirements to me, and I would like to 
> see some discussion from folk on whether they think this is valuable work, 
> and whether we should start to look for protocol solutions.
> 
> Thanks,
> Adrian
> 
> ----- Original Message ----- 
> From: "Diego Caviglia" <[e-mail]>
> To: <[e-mail]>
> Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti" 
> <[e-mail]>
> Sent: Wednesday, May 24, 2006 8:48 AM
> Subject: A nerw ID is available on the repository 
> draft-caviglia-ccamp-pc-and-sc-reqs-00
> 
> 
> 
>>A new ID is available on the ID repository
>>http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.txt.
>>
>>The ID states some basic requrements for the possibility of turning a
>>Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice
>>versa, without actually affecting Data Plane traffic, no solutions are
>>proposed in the ID.
>>
>>Abstract
>>
>>  From a Carrier perspective, the possibility of turning a Permanent
>>  Connection (PC) into a Soft Permanent Connection (SPC) and vice
>>  versa, without actually affecting Data Plane traffic being carried
>>  over it, is a valuable option. In other terms, such operation can be
>>  seen as a way of transferring the ownership and control of an
>>  existing and in-use Data Plane connection between the Management
>>  Plane and the Control Plane, leaving its Data Plane state untouched.
>>  This memo sets out the requirements for such procedures within a
>>  Generalized Multiprotocol Label Switching (GMPLS) network.
>>
>>
>>Comments and suggestions are very welcome sxpecially from the carrier
>>community.
>>
>>Regards
>>
>>Diego
>>
>>
>>
>>
>>
>>
> 
> 
> 
> 


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




Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 17:15:50 +0000
Message-ID: <0e4101c684d5$9ea67f50$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "WALTER ROTHKEGEL" <[e-mail]>
Cc: <[e-mail]>, "Diego Caviglia" <[e-mail]>, "Dan  Li <danli" <[e-mail]>, "Dino Bramanti" <[e-mail]>
Subject: Re: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
Date: Wed, 31 May 2006 18:13:53 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Walter,

Thanks for your thoughts.

May I restate them to make sure that I understand?

> While I think these requirements are real, I can not imagine that they
> can be solved by some protocol extensions.

If I am interpretting you correctly, you are saying that you agree with the 
requirements. This means that *if* they can be solved, you would be quite 
pleased. And even if they could only be solved in certain control 
situations, you would also think that a good thing.

On the other hand, you are skeptical that a solution can be developed. 
Presumably, this means that you would not want to spend your time attempting 
to develop one, or see the WG expend much bandwidth on trying to find a way 
to meet the requirements. But I don't suppose you would object if the 
authors of this I-D spent their own time trying to hatch a solution and then 
brought it to the working group for discussion.

> One reason is, as it is stated in the I_D, that "ownership by the 
> Management
> and Control Planes is strictly an implementation issue", which we can not
> solve by a protocol alone.

Hmmm. Yeah I guess it could be a problem if a device determined that it 
would not allow resources to be exchanged between the two planes. Handling 
(or, more precisely, not handling) NEs that do not support these funcitons 
certainly has to be discussed. I suppose there are two situations:
1. As you describe, the LSP cannot be shifted. I.e. the LSR understands
  the request but is unable or unwilling to comply.
2. The LSR does not understand the request. I.e. it has not been
  upgraded to handle the protocol solution.

I think this is actually business as usual for protocol work, isn't it?

> Secondly, the MP and CP typically store additional data associated with 
> the
> connection, which is implementation specific, but needs also appropriate
> conversion, or the conversion must at least ensure data integrity.

I'd be intrigued to know what additional informaiton a standard GMPLS 
control plane is going to store over and above what is signaled by the 
protocol. So the problem you describe is lopsided - if the MP and CP are 
capable of storing the additional information then I think there is no issue 
(and presumably everything is the same implementation-specific stuff). But 
if there are differences in implmentations in the CP, then they must be 
running some common set of protocol extensions and it is this that needs to 
be converted to/from the MP.

Note that if the MP offers the ability to configure things on an NE that 
cannot be carried in signaling then those things cannot bve carried in 
signaling, period. That is, you cannot consider provisioning an LSP in the 
CP at all if you need to carry this information. Fortunately, we are not 
having a discussion on the relative merits of using a control plane - the 
situation we are examining is one where the operator (the customer!) has 
decided to move ownership of an LSP between planes, and wants to know how to 
do it. That means that the operator has already accepted that the LSP can be 
managed by both planes and wishes to make the transfer without turning the 
service down.

> Finally, need to look, what is convertible at all. E.g., the MP may have
> implemented certain broadcast or multicast connections, or special 
> protection
> schemes, which are not (yet) supported by the CP.

Yes, there is the possiblity that certain services in the MP cannot be 
achieved in the CP (although it would be interesting to discuss which, 
because if there is a need, the control plane is surely in need of 
enhancement). So you are right, there may be some LSPs that cannot be 
migrated in this way. But what about those that can? Do you think we should 
at least consider these requirements for those LSPs that can be migrated?

Many thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 14:45:57 +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: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt 
Date: Wed, 31 May 2006 10:44:38 -0400
Message-ID: <[e-mail]>
Thread-Topic: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt 
Thread-Index: AcZ/R9v0YpaSjq2CSj6YNicpNTtUbwFb2knA
From: "Zafar Ali \(zali\)" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>, "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>, "ccamp" <[e-mail]>, "George Swallow \(swallow\)" <[e-mail]>, "Adrian Farrel" <[e-mail]>, "Deborah Brungard" <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=2644; t=1149086679; x=1149950679; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=[e-mail]; z=From:=22Zafar=20Ali=20\(zali\)=22=20<[e-mail]> |Subject:RE=3A=20working=20group=20last=20call=20on=20draft-ietf-mpls-rsvp-te-p2m p-05.txt=20; X=v=3Dcisco.com=3B=20h=3Ds2QdIjLYxjuMwjYE13iS3QN8AeY=3D; b=OvWUVFPHo4d3vBy7Ihd/pYGvkC5+0fcO8DMzhf7ZgtAXWFtc2d0O939jk324kN61S79ZDKtz NxjpWCkNj7dwt7TP1EkQ2hEwLvxGoO1ZpHaUGzBUIaYyIwYTxa9jw2WF;
Authentication-Results: sj-dkim-1.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; );

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Yakov Rekhter
> Sent: Wednesday, May 24, 2006 11:35 AM
> To: Loa Andersson
> Cc: [e-mail]; ccamp; George Swallow (swallow); Adrian=20
> Farrel; Deborah Brungard; Ross Callon; Bill Fenner
> Subject: Re: working group last call on=20
> draft-ietf-mpls-rsvp-te-p2mp-05.txt=20
>=20
> Loa and George,
>=20
> > Working Group,
> >=20
> > this initiates a two week working group last call on=20
> > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> >=20
> > please send comments to the MPLS working group mailling list and/or=20
> > working co-chairs.
> >=20
> > The last call ends eob May 28th.
> >=20
> > The ccamp mailing list copied as this is a work that has an overlap=20
> > between the working groups.
> >=20
> > Loa and George
>=20
> Few observations and suggestions...
>=20
> (a) <Ingress LSR IP address, P2MP ID> tuple is both necessary=20
> and sufficient to unambiguously identify a P2MP Tunnel.
>=20

Yakov, et al

I would ask to add extended tunnel ID as part of this, unless we force
is to be equal to the Ingress LSR IP address (at least in P2MP draft),
as suggested by George.=20

> (b) Further <Ingress LSR IP address, P2MP ID, LSP ID> is both=20
> necessary and sufficient to identify a P2MP LSP.

Following the above comment, a FEC for P2MP is identified by <Ingress
LSR IP address, P2MP ID, LSP ID, extended tunnel ID>.=20

Thanks

Regards... Zafar=20

>=20
> Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt
> should say the following:
>=20
> 1. A P2MP tunnel is identified by a tuple <root node IP address,
> index>, where the index value is unique within the scope of the IP
> address of the root node.  The P2MP tunnel identifier <root=20
> node IP address, index> is unique within the same scope as=20
> the root node IP address.
>=20
> 2. Both the Extended Tunnel ID and the Tunnel Sender Address=20
> fields carry the root node IP address (both fields carry the=20
> same value).
> The index is carried in the P2MP ID.
>=20
> 3. Tunnel ID field should be set to all zeros, and be ignored=20
> on receipt.
>=20
> 4. A P2MP LSP is identified by a combination of tunnel=20
> identifier (<root node IP address, index>), and LSP ID.
>=20
> With this in mind sections 4.1, 4.2, 19.1 and 19.2 should be=20
> modified to clarify the following:
>=20
> (a) SESSION identifier;
> (b) semantics of Extended Tunnel ID; semantics of the P2MP ID;
> (c) semantics of the Tunnel ID IP address in the SENDER_TEMPLATE.
>=20
> Yakov.
>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 14:45:49 +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: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt 
Date: Wed, 31 May 2006 10:44:33 -0400
Message-ID: <[e-mail]>
Thread-Topic: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt 
Thread-Index: AcaCdrAJDW5rhHgmRqe9wJN4uwqxQgCPwGEg
From: "Zafar Ali \(zali\)" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: "Loa Andersson" <[e-mail]>, <[e-mail]>, "ccamp" <[e-mail]>, "George Swallow \(swallow\)" <[e-mail]>, "Deborah Brungard" <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=3534; t=1149086674; x=1149950674; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=22Zafar=20Ali=20\(zali\)=22=20<[e-mail]> |Subject:RE=3A=20working=20group=20last=20call=20on=20draft-ietf-mpls-rsvp-te-p2m p-05.txt=20; X=v=3Dcisco.com=3B=20h=3Dz4HV9KCTBmcbjG78hTn1772rpGI=3D; b=lv9/7NPEJ8zlf8JfH4i5L9n5v4je6xklQqf3ebhH+UhL/RKLs3WGpdZGkLTEnrT1rtqvsjim ck61ChFC4FScbqJECpkHNX4rT/aLGb9ChbhFqoo43OD0MbbBNycfeIhS;
Authentication-Results: sj-dkim-2.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; );

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Yakov Rekhter
> Sent: Sunday, May 28, 2006 12:47 PM
> To: Adrian Farrel
> Cc: Loa Andersson; [e-mail]; ccamp; George Swallow=20
> (swallow); Deborah Brungard; Ross Callon; Bill Fenner
> Subject: Re: working group last call on=20
> draft-ietf-mpls-rsvp-te-p2mp-05.txt=20
>=20
> Adrian,
>=20
> > >> > Few observations and suggestions...
> > >> >
> > >> > (a) <Ingress LSR IP address, P2MP ID> tuple is both=20
> necessary and=20
> > >> > sufficient to unambiguously identify a P2MP Tunnel.
> > >> >
> > >> > (b) Further <Ingress LSR IP address, P2MP ID, LSP ID> is both=20
> > >> > necessary and sufficient to identify a P2MP LSP.
> > >>
> > >> Clearly these two statements depend on the definition of=20
> "P2MP ID"=20
> > >> as you pointed out below.
> > >>
> > >> As the I-D says...
> > >>    The P2MP ID provides an identifier for the set of=20
> destinations of the
> > >>    P2MP TE Tunnel.
> > >
> > > Does this identifier have a globally unique scope, or=20
> only the scope=20
> > > of the root ? If the former, then what are the procedures for=20
> > > assigning such identifiers ?
> >=20
> > Good questions.
> >=20
> > Presumably, if we want to retain the concept of Session (which=20
> > appeared to be the case in discussion amongst the authors) then the=20
> > P2MP ID has to have global scope.
> >=20
> > Not sure whether the procedures for assigning the=20
> identifiers has to=20
> > be in scope of this document. The procedure for assigning=20
> IP addresses=20
> > to P2P tunnel destinations does not appear to be in scope=20
> for RFC3209.
> >=20
> > It is worth looking at RFC4461 for more information on the P2MP ID.=20
> > This gives us:
> >       A unique identifier of a P2MP TE LSP, which is=20
> constant for the
> >       whole LSP regardless of the number of branches and/or leaves.
> > which is not as hepful as it could have been :-(
> >=20
> > I think you are right to try to flush this sort of thing out now=20
> > rather than let us get into the ambiguity mess that we got=20
> to with RFC3209.
>=20
> There is a difference between IP addresses used for P2P=20
> tunnel destinations, and identifiers used for P2MP ID. The=20
> former are unicast addresses (each address identifies a=20
> *single* node/interface).
> The latter are *group* addresses (each address identifies a=20
> *group* of nodes). There are well-established procedures for=20
> assigining unicast IP addresses, but not for group addresses.
>=20
> If some folks would like to retain the ability of the P2MP ID=20
> to have global scope, then at the minimum the spec (a) should=20
> have this as *an option*, with P2MP ID having the scope of=20
> the root node being another option documented in the spec,=20
> and (b) spell out the procedures for assigining such globally=20
> unique P2MP IDs.

Yakov, Adrian, et al

I think global scoping will be a bad idea. Furthermore, we cannot force
it to come from multicast IP address space. So Ingress node scoping is
quite obvious and IMHO suffices.=20

I also don't see an issue in sharing 2^16 space for both P2MP and P2P
tunnels. Does anyone see an issue here? I think having said that P2MP ID
has Ingress node scope, an implementation MAY choose to make P2MP ID =3D
tunnel ID, or has flexibility otherwise.=20

My $0.02.=20

Thanks

Regards... Zafar =20

>=20
> Yakov.
>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 07:24:21 +0000
Message-ID: <00ae01c68483$01801030$[e-mail]>
From: "wjq" <[e-mail]>
To: <[e-mail]>, "\"Adrian Farrel\"" <[e-mail]>
Cc: "\"Diego Caviglia\"" <[e-mail]>, "\"Dino Bramanti\"" <[e-mail]>
Subject: reply
Date: Wed, 31 May 2006 15:22:42 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01C684C6.0F98A1D0"

This is a multi-part message in MIME format.

------=_NextPart_000_00AB_01C684C6.0F98A1D0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

SGkgQWxsLA0KDQpXZSBoYXZlIGNhcmVmdWxseSBjb25zaWRlcmVkIHRoZSByZXF1aXJtZW50cyB3
aGljaCBoYXZlIGJlZW4gbmljZWx5IGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LCBhbmQgdGhpbmsg
dGhlIHJlcXVpcmVtZW50cyBhcmUgdXNlZnVsIGFuZCBuZWNlc3NhcnkuIFRoZSBQQy9TQ1NQQyBt
aWdyYXRpb24gZnVuY3Rpb24gaXMgbmVjZXNzYXJ5IGFmdGVyIHRoZSBjb250cm9sIHBsYW5lIGhh
cyBiZWVuIGRlcGxveWVkLCBpdCBnaXZlcyB0aGUgb3BlcmF0b3JzIGEgdXNlZnVsIHRvb2wgdG8g
bWFpbnRhaW4gdGhlIFBDL1NDL1NQQyBjb25uZWN0aW9ucywgYW5kIGl0IGFjY2VsZXJhdGVzIHRo
ZSBjb252ZW5nZW5jZSBiZXR3ZWVuIHRyYW5zcG9ydCBsYXllciBhbmQgY2FycnlpbmcgbGF5ZXIg
d2hpY2ggaXMgdGhlIHRyZW5kIG9mIG5leHQgZ2VuZXJhdGlvbiBuZXR3b3Jrcy4NCg0KV2Ugc3Vw
cG9ydCB0aGlzIHdvcmsgaW4gSUVURiBDQ0FNUCBXRy4NCg0KVGhhbmtzLA0KDQoNClNpbmNlcmVs
eSBZb3Vycw0KV2FuZyBKaWFucXVhbg0KQXNzb2NpYXRlIFByb2Zlc3Nvcg0KRW5naW5lZXJpbmcg
VGVjaG5vbG9neSBEaXZpc2lvbg0KTmV0d29ya3MgQ29uc3RydWN0aW9uIERlcGFydG1lbnQsDQpD
aGluYSBVbmljb20sDQpOby4xMzNBLFhpZGFuIE5vcnRoIFN0cmVldCxYaWNoZW5nIERpc3RyaWN0
LEJlaWppbmcsIDEwMDAzMixDaGluYQ0KVGVsOiAgKzg2IDEwIDY2NTA1NzM5DQpNb2JpbGWjuis4
NiAxMzMzMTAxNjYwNg0KRmF4OiAgICArODYgMTAgNjY1MDU4NDQNCkVtYWlsOiAgd2FuZ2pxQGNo
aW5hdW5pY29tLmNvbS5jbg0K

------=_NextPart_000_00AB_01C684C6.0F98A1D0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w
MC4yOTAwLjI4NzMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8
Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBzaXplPTM+SGkg
QWxsLDxCUj48QlI+V2UgaGF2ZSBjYXJlZnVsbHkgY29uc2lkZXJlZCB0aGUgDQpyZXF1aXJtZW50
cyB3aGljaCBoYXZlIGJlZW4gbmljZWx5IGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LCBhbmQgdGhp
bmsgdGhlIA0KcmVxdWlyZW1lbnRzIGFyZSB1c2VmdWwgYW5kIG5lY2Vzc2FyeS4gVGhlIFBDL1ND
U1BDIG1pZ3JhdGlvbiBmdW5jdGlvbiBpcyANCm5lY2Vzc2FyeSBhZnRlciB0aGUgY29udHJvbCBw
bGFuZSBoYXMgYmVlbiBkZXBsb3llZCwgaXQgZ2l2ZXMgdGhlIG9wZXJhdG9ycyBhIA0KdXNlZnVs
IHRvb2wgdG8gbWFpbnRhaW4gdGhlIFBDL1NDL1NQQyBjb25uZWN0aW9ucywgYW5kIGl0IGFjY2Vs
ZXJhdGVzIHRoZSANCmNvbnZlbmdlbmNlIGJldHdlZW4gdHJhbnNwb3J0IGxheWVyIGFuZCBjYXJy
eWluZyBsYXllciB3aGljaCBpcyB0aGUgdHJlbmQgb2YgDQpuZXh0IGdlbmVyYXRpb24gbmV0d29y
a3MuPEJSPjxCUj5XZSBzdXBwb3J0IHRoaXMgd29yayBpbiBJRVRGIENDQU1QIA0KV0cuPEJSPjxC
Uj5UaGFua3MsPC9GT05UPjxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP
TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5TaW5jZXJlbHkgWW91cnM8QlI+V2Fu
ZyBKaWFucXVhbjxCUj5Bc3NvY2lhdGUgDQpQcm9mZXNzb3I8QlI+RW5naW5lZXJpbmcgVGVjaG5v
bG9neSBEaXZpc2lvbjxCUj5OZXR3b3JrcyBDb25zdHJ1Y3Rpb24gDQpEZXBhcnRtZW50LDxCUj5D
aGluYSBVbmljb20sPEJSPk5vLjEzM0EsWGlkYW4gTm9ydGggU3RyZWV0LFhpY2hlbmcgDQpEaXN0
cmljdCxCZWlqaW5nLCAxMDAwMzIsQ2hpbmE8QlI+VGVsOiZuYnNwOyArODYgMTAgNjY1MDU3Mzk8
QlI+TW9iaWxlo7orODYgDQoxMzMzMTAxNjYwNjxCUj5GYXg6Jm5ic3A7Jm5ic3A7Jm5ic3A7ICs4
NiAxMCA2NjUwNTg0NDxCUj5FbWFpbDombmJzcDsgPEEgDQpocmVmPSJtYWlsdG86d2FuZ2pxQGNo
aW5hdW5pY29tLmNvbS5jbiI+d2FuZ2pxQGNoaW5hdW5pY29tLmNvbS5jbjwvQT48QlI+PC9GT05U
PjwvRElWPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_000_00AB_01C684C6.0F98A1D0--




Envelope-to: [e-mail]
Delivery-date: Wed, 31 May 2006 06:47:26 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 May 2006 08:44:56 +0200
From: [e-mail]
To: [e-mail]
Subject: RE: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.0

Hi All,

>From my point of view as a carrier, this draft clearly describes the carrier's 
requirements for deploying GMPLS/ASON based transport. This is a useful 
feature, and I would like to support this work. 

Best regards,

Ruiquan Jing
China Telecom Beijing Research Institute Beijing, China

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of 
Adrian Farrel
Sent: Friday, May 26, 2006 1:53 AM
To: [e-mail]; Diego Caviglia
Cc: Dan Li <danli; Dino Bramanti
Subject: Re: A nerw ID is available on the repository draft-caviglia-ccamp-pc-
and-sc-reqs-00

Hi Diego,

Thanks for putting this I-D together. I think it gives a much clearer picture 
of what you are trying to achieve with your discussion of moving control of an 
LSP between the management plane and the control plane.

This seems like a reasonable set of requirements to me, and I would like to 
see some discussion from folk on whether they think this is valuable work, and 
whether we should start to look for protocol solutions.

Thanks,
Adrian

----- Original Message -----
From: "Diego Caviglia" <[e-mail]>
To: <[e-mail]>
Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti" 
<[e-mail]>
Sent: Wednesday, May 24, 2006 8:48 AM
Subject: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-
sc-reqs-00


>A new ID is available on the ID repository 
>http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.
txt.
>
> The ID states some basic requrements for the possibility of turning a 
> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and 
> vice versa, without actually affecting Data Plane traffic, no 
> solutions are proposed in the ID.
>
> Abstract
>
>   From a Carrier perspective, the possibility of turning a Permanent
>   Connection (PC) into a Soft Permanent Connection (SPC) and vice
>   versa, without actually affecting Data Plane traffic being carried
>   over it, is a valuable option. In other terms, such operation can be
>   seen as a way of transferring the ownership and control of an
>   existing and in-use Data Plane connection between the Management
>   Plane and the Control Plane, leaving its Data Plane state untouched.
>   This memo sets out the requirements for such procedures within a
>   Generalized Multiprotocol Label Switching (GMPLS) network.
>
>
> Comments and suggestions are very welcome sxpecially from the carrier 
> community.
>
> Regards
>
> Diego
>
>
>
>
>
> 








Envelope-to: [e-mail]
Delivery-date: Tue, 30 May 2006 19:41:11 +0000
To: Yakov Rekhter <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Loa Andersson" <[e-mail]>, [e-mail], "ccamp" <[e-mail]>, "Deborah Brungard" <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>
Cc: [e-mail]
Subject: Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt 
From: George Swallow <[e-mail]>
Date: Tue, 30 May 2006 15:40:49 -0400
Message-Id: <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=1292; t=1149017995; x=1149881995; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:George=20Swallow=20<[e-mail]> |Subject:Re=3A=20working=20group=20last=20call=20on=20draft-ietf-mpls-rsvp-te-p2m p-05.txt=20; X=v=3Dcisco.com=3B=20h=3DwFMJg3I82ycME///RDDbDBO07Mc=3D; b=awGqbJ0mEWD20IRdiItzOpbP9l3g5COBKIP8VmmR5V+gZncbEhkw3JVCBpn8vokRV8D/TCrL A7vHg9SNbousbSh/eEvDw5UajHiyA62N3+u0Ap+7LMYsAmDb/IfFiRAh;
Authentication-Results: sj-dkim-7.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; );

> What are exactly the (practical) problems with carrying the root
> node IP address both in the Extended Tunnel ID and in the Tunnel
> Sender Address fields ?

If you wish to use bypass FRR, you will do exactly this.  The Extended
Tunnel ID is meant to provide a means of making the Session globally
unique.  An intermediate node that wishes to merge back into an existing
tunnel over a bypass tunnel uses it's own IP address in the sender field
and the existant Session Object.  If the session object were not unique
then this would be very hit or miss!

Personally I would like to see the text with ^^^^ removed from the
draft.  It was carried over from 3209 which was written prior to the FRR
draft.

>          A 32-bit identifier used in the SESSION that remains constant
>          over the life of the tunnel.  Normally set to all zeros.
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^

If we ever get around to pushing 3209 to Draft Standard I'll take it out
of there as well.

...George

========================================================================
George Swallow             Cisco Systems                  [phone]
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719



Envelope-to: [e-mail]
Delivery-date: Tue, 30 May 2006 15:49:12 +0000
Date: Tue, 30 May 2006 08:47:58 -0700 (PDT)
From: Rahul Aggarwal <[e-mail]>
To: Loa Andersson <[e-mail]>
cc: [e-mail], Bill Fenner <[e-mail]>,  ccamp <[e-mail]>, Ross Callon <[e-mail]>
Subject: Re: [mpls] Closed: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Loa,

On Mon, 29 May 2006, Loa Andersson wrote:

> All,
>
> this closes the working group Last Call on
> draft-ietf-mpls-rsvp-te-p2mp-05.txt
>
> Could the authors/editors please summarize the comments and
> document how they will be addressed.
>

We will plan to do this by end of the week.

Thanks,
Editors

> Loa and George
>
>
>
> Loa Andersson wrote:
> > Working Group,
> >
> > this initiates a two week working group last call on
> > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> >
> > please send comments to the MPLS working group mailling
> > list and/or working co-chairs.
> >
> > The last call ends eob May 28th.
> >
> > The ccamp mailing list copied as this is a work that has
> > an overlap between the working groups.
> >
> > Loa and George
> >
> >
> >
>
>
> --
> 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, 29 May 2006 21:24:49 +0000
Message-ID: <[e-mail]>
Date: Mon, 29 May 2006 23:22:44 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Loa Andersson <[e-mail]>
CC:  [e-mail], ccamp <[e-mail]>,  George Swallow <[e-mail]>, Adrian Farrel <[e-mail]>,  Deborah Brungard <[e-mail]>, Ross Callon <[e-mail]>, Bill Fenner <[e-mail]>
Subject: Closed: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

this closes the working group Last Call on
draft-ietf-mpls-rsvp-te-p2mp-05.txt

Could the authors/editors please summarize the comments and
document how they will be addressed.

Loa and George



Loa Andersson wrote:
> Working Group,
> 
> this initiates a two week working group last call on
> draft-ietf-mpls-rsvp-te-p2mp-05.txt
> 
> please send comments to the MPLS working group mailling
> list and/or working co-chairs.
> 
> The last call ends eob May 28th.
> 
> The ccamp mailing list copied as this is a work that has
> an overlap between the working groups.
> 
> Loa and George
> 
> 
> 


-- 
Loa Andersson

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



Envelope-to: [e-mail]
Delivery-date: Sun, 28 May 2006 16:49:18 +0000
Message-Id: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
cc: "Loa Andersson" <[e-mail]>, [e-mail], "ccamp" <[e-mail]>, "George Swallow" <[e-mail]>, "Deborah Brungard" <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sun, 28 May 2006 09:46:49 -0700
From: Yakov Rekhter <[e-mail]>

Adrian,

> >> > Few observations and suggestions...
> >> >
> >> > (a) <Ingress LSR IP address, P2MP ID> tuple is both necessary and
> >> > sufficient to unambiguously identify a P2MP Tunnel.
> >> >
> >> > (b) Further <Ingress LSR IP address, P2MP ID, LSP ID> is both
> >> > necessary and sufficient to identify a P2MP LSP.
> >>
> >> Clearly these two statements depend on the definition of "P2MP ID" as you
> >> pointed out below.
> >>
> >> As the I-D says...
> >>    The P2MP ID provides an identifier for the set of destinations of the
> >>    P2MP TE Tunnel.
> >
> > Does this identifier have a globally unique scope, or only the scope
> > of the root ? If the former, then what are the procedures for
> > assigning such identifiers ?
> 
> Good questions.
> 
> Presumably, if we want to retain the concept of Session (which appeared to 
> be the case in discussion amongst the authors) then the P2MP ID has to have 
> global scope.
> 
> Not sure whether the procedures for assigning the identifiers has to be in 
> scope of this document. The procedure for assigning IP addresses to P2P 
> tunnel destinations does not appear to be in scope for RFC3209.
> 
> It is worth looking at RFC4461 for more information on the P2MP ID. This 
> gives us:
>       A unique identifier of a P2MP TE LSP, which is constant for the
>       whole LSP regardless of the number of branches and/or leaves.
> which is not as hepful as it could have been :-(
> 
> I think you are right to try to flush this sort of thing out now rather than 
> let us get into the ambiguity mess that we got to with RFC3209.

There is a difference between IP addresses used for P2P tunnel
destinations, and identifiers used for P2MP ID. The former are
unicast addresses (each address identifies a *single* node/interface).
The latter are *group* addresses (each address identifies a *group*
of nodes). There are well-established procedures for assigining
unicast IP addresses, but not for group addresses.

If some folks would like to retain the ability of the P2MP ID to
have global scope, then at the minimum the spec (a) should have
this as *an option*, with P2MP ID having the scope of the root node
being another option documented in the spec, and (b) spell out the 
procedures for assigining such globally unique P2MP IDs.

Yakov.



Envelope-to: [e-mail]
Delivery-date: Thu, 25 May 2006 17:59:37 +0000
Message-ID: <005b01c68024$d56630e0$08849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Diego Caviglia" <[e-mail]>
Cc: "Dan Li <danli" <[e-mail]>, "Dino Bramanti" <[e-mail]>
Subject: Re: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
Date: Thu, 25 May 2006 18:53:12 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Diego,

Thanks for putting this I-D together. I think it gives a much clearer 
picture of what you are trying to achieve with your discussion of moving 
control of an LSP between the management plane and the control plane.

This seems like a reasonable set of requirements to me, and I would like to 
see some discussion from folk on whether they think this is valuable work, 
and whether we should start to look for protocol solutions.

Thanks,
Adrian

----- Original Message ----- 
From: "Diego Caviglia" <[e-mail]>
To: <[e-mail]>
Cc: "Dan Li <danli" <[e-mail]>; "Dino Bramanti" 
<[e-mail]>
Sent: Wednesday, May 24, 2006 8:48 AM
Subject: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00


>A new ID is available on the ID repository
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.txt.
>
> The ID states some basic requrements for the possibility of turning a
> Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice
> versa, without actually affecting Data Plane traffic, no solutions are
> proposed in the ID.
>
> Abstract
>
>   From a Carrier perspective, the possibility of turning a Permanent
>   Connection (PC) into a Soft Permanent Connection (SPC) and vice
>   versa, without actually affecting Data Plane traffic being carried
>   over it, is a valuable option. In other terms, such operation can be
>   seen as a way of transferring the ownership and control of an
>   existing and in-use Data Plane connection between the Management
>   Plane and the Control Plane, leaving its Data Plane state untouched.
>   This memo sets out the requirements for such procedures within a
>   Generalized Multiprotocol Label Switching (GMPLS) network.
>
>
> Comments and suggestions are very welcome sxpecially from the carrier
> community.
>
> Regards
>
> Diego
>
>
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Thu, 25 May 2006 16:43:08 +0000
Message-ID: <052c01c68019$fdd7e4c0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Update: Draft response to OIF on 1:n protection
Date: Thu, 25 May 2006 17:35:32 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Hi,

Jim Jones has been in touch to ask that we hold off responding for a while. 
it appears that having read this draft response, some OIF folk would like to 
spend some time clarifying the questions.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Monday, May 22, 2006 8:50 PM
Subject: Draft response to OIF on 1:n protection


> Hi,
>
> Thanks to those who have sent me off-list comments.
>
> Here is a draft response to the OIF on 1:n protection. Please send me (or
> the list) your comments.
>
> Thanks,
> Adrian
>
> ===
> Dear Jim,
>
> Thank you for your communication to CCAMP on the use of GMPLS to provide
> 1:n protection at the OIF UNI and the OIF E-NNI.
>
> We are grateful for this opportunity to comment, but we note that this
> type of communication requesting clarifications is better suited to a
> mailing list discussion than to official communications that, by their
> nature, have a slow turn-around. The appropriate place for
> discussions of GMPLS protocols is the CCAMP working group
> mailing list. Details of how to subscribe to the mailing list can be found 
> at http://www.ietf.org/html.charters/ccamp-charter.html
>
>> Future updates to OIF UNI and E-NNI signaling may include a feature
>> for 1:N connection protection. The attached document presents
>> requirements for these features. Recently a review was completed
>> of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
>> implement this function (including draft-ietf-ccamp-gmpls-recovery-
>> e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
>> It appears that the abstract messages from RFC 4426 provide much
>> of this functionality, however several questions resulted from this
>> review. OIF would appreciate review and comments from IETF
>>CCAMP on the following items.
>>
>> 1.) OIF would appreciate knowing if there are protocol features in
>> other IETF documents relevant to 1:N protection .
>
> We would like to suggest that, in order to utilize advanced features of
> the GMPLS control plane protocol, engineers should be familiar with
> the full set of GMPLS RFCs and Internet-Drafts. These are listed on
> the CCAMP charter page and can be downloaded free of charge by
> clicking on the links.
>
> Although not all of this work is directly related to protection and
> restoration, it should be noted that any protocol aspect present for a
> working path may also be required for a protection path. Protocol
> engineers must, therefore, be familiar with the details of the protocol
> before attempting to provide advanced functions like protection.
>
>> 2.) RFC 4426 section 2.5.2 says "it MAY be possible for the LSPs
>> on the working link to be mapped to the protection link without
>> re-signaling each individual LSP" and "it MAY be possible to change
>> the component links without needing to re-signal each individual LSP".
>> OIF would like to know what signaling messages and objects can be
>> used to accomplish this.
>
> Your question is confusing in the light of the referenced section.
> The section describes the messages required to achieve span protection.
> Clearly, if a span is protected, then all LSPs carried over that span
> may be transparently protected. This is how normal link protection
> operates and there is nothing clever going on.
>
> Recall that section 2.5.2 is a subsection of section 2, and this is
> entirely dedicated to span protection.
>
> Further, if the bundling example is followed, the referenced RFC
> (RFC4201) explains the signaling necessary to achieve bundling.
>
> You may find it easier to consider this as a layering architecture. The
> span (link) that is protected is a lower layer commodity and its
> protection may be, therefore, transparent to the higher layer.
>
> If you have a specific question we would be happy to answer.
>
>> 3.) It is suggested that the Failure Indication Message (or
>> equivalent) from RFC 4426 can be triggered not only from a
>> failure but also a command from a management system.
>
> You have not asked a specific question here so it is hard to give any
> answer except for "yes".
>
> Management systems are usually regarded as supreme. A management
> system can instruct an implementation to do anything, and this may be
> useful for forced or controlled switch-over. You may want to refer to
> RFC4427 section 4.13.
>
>> 4.) A goal of the 1:N protection is to use a bulk notification and
>> recovery procedure, based on RFC 4427 section 4.15. However, that RFC
>> states the corresponding recovery switching actions are performed at
>> the LSP level. It would be useful to know if bulk processing could be
>> applied to recovery of individual connection segments on the failed span,
>> not entire LSPs.
>
> We do not understand your question. Each LSP has its own entry in the
> switching matrix. Any switching recovery action that is required can
> only be applied to this individual entry. Implementations may have some
> optimisations (such as back-up, pre-programmed matrices, or magic matrix
> re-program commands), but this is clearly out of scope of a control
> plane specification.
>
> Please note that recovery switching actions are not signaling actions.
>
> We are also confused as to the meaning of "It would be useful to know if
> bulk processing could be applied to recovery of individual connection
> segments on the failed span, not entire LSPs." To process it further, we
> probably need to deconstruct the term Connection Segment. As you may be
> aware, the term 'connection segment' is not widely used in the ASON
> Recommendations and does not find a definition there. The reference from
> G.8081 is to an ATM forum document.
>
> We assume that you are concerned to provide end-to-end data transfer.
> Presumably you are interested in a variety of symmetrical cases such as
> client-layer connectivity, UNI-C to UNI-C connectivity, UNI-N to UNI-N
> connectivity, or UNI-N/E-NNI to E-NNI/UNI-N connectivity. The path
> between these points is an LSP (it may be a hierarchical LSP through which
> other LSPs are tunneled) and it is this path that you wish to protect.
> Whether you perform span, segment, or end-to-end protection, you are still
> protecting the LSP.
>
>> 5.) RFC 4426 refers to three abstract messages involved in the
>> reversion sequence:
>>
>> - A Bridge and Switch Request message from the source node after it
>> has bridged traffic back to both working and protection links.
>>
>> - A Bridge and Switch Response message from the destination node after
>> it has bridged traffic back to both working and protection links and
>> changed its selector to the working link.
>>
>> - A Bridge and Switch Completed message from the source node after it
>> has changed its selector to the working link and stopped sending traffic
>> on the protection link (so the destination can stop transmitting on
>> protection).
>>
>> Since RFC 4426 covers these Bridge and Switch messages briefly, more
>> details should be specified on the operation and behavior in this
>> reversion process.
>
> If you have specific questions, we would be happy to answer them. If you
> believe that additional documentation is required, we would welcome your
> contributions as an Internet-Draft.
>
>> Further, it would be helpful to understand why the actions are
>> performed by source and destination nodes rather than master and
>> slave nodes. It may be appropriate to reuse the master/slave roles
>> in the reversion process just as is done in the switchover process.
>
> There is a distinction between the node that invokes a switchover
> process (the master) and a node that performs the process. For
> example, a Bridge and Switch Request message is sent by the source
> node after it has bridged traffic back to both working and protection
> links simply because the source node has performed the bridging and
> is the only node that can know this fact.
>
>> In addition, RFC 4426 does not include an abstract message similar to
>> the Failure Indication Message to request the beginning of the reversion
>> procedure. It may be beneficial to include a message from the slave
>> device to initiate reversion, just as there is a Failure Indication
>> Message
>> to initiate switchover. (RFC 4426 states that the Failure Indication
>> Message may not be needed when the transport plane technology
>> itself provides such a notification. The same may apply when a failure
>> is cleared; however, there should still be an optional message to
>> trigger the reversion process.)
>
> Reversion is described as an administrative procedure quite
> deliberately. In our view it should not be a rapid response to a
> specific situation triggered through the control plane by the 'master',
> but should be a considered operation under the control of administrative
> policy. The trigger is, therefore, outside the scope of the control plane.
> This is in section 4.13 of RFC4427.
>
> We hope this answers your questions, and we would be happy to enter into
> further dialog on these topics.
>
> Best regards,
> Adrian Farrel and Deborah Brungard
> CCAMP co-chairs
>
>
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Thu, 25 May 2006 11:10:51 +0000
Message-ID: <049901c67feb$a21c8ce0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>
Cc: "Loa Andersson" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, <[e-mail]>, "ccamp" <[e-mail]>, "George Swallow" <[e-mail]>, "Deborah Brungard" <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt 
Date: Thu, 25 May 2006 12:08:50 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Yakov,

>> > Few observations and suggestions...
>> >
>> > (a) <Ingress LSR IP address, P2MP ID> tuple is both necessary and
>> > sufficient to unambiguously identify a P2MP Tunnel.
>> >
>> > (b) Further <Ingress LSR IP address, P2MP ID, LSP ID> is both
>> > necessary and sufficient to identify a P2MP LSP.
>>
>> Clearly these two statements depend on the definition of "P2MP ID" as you
>> pointed out below.
>>
>> As the I-D says...
>>    The P2MP ID provides an identifier for the set of destinations of the
>>    P2MP TE Tunnel.
>
> Does this identifier have a globally unique scope, or only the scope
> of the root ? If the former, then what are the procedures for
> assigning such identifiers ?

Good questions.

Presumably, if we want to retain the concept of Session (which appeared to 
be the case in discussion amongst the authors) then the P2MP ID has to have 
global scope.

Not sure whether the procedures for assigning the identifiers has to be in 
scope of this document. The procedure for assigning IP addresses to P2P 
tunnel destinations does not appear to be in scope for RFC3209.

It is worth looking at RFC4461 for more information on the P2MP ID. This 
gives us:
      A unique identifier of a P2MP TE LSP, which is constant for the
      whole LSP regardless of the number of branches and/or leaves.
which is not as hepful as it could have been :-(

I think you are right to try to flush this sort of thing out now rather than 
let us get into the ambiguity mess that we got to with RFC3209.

>> And this means that there is not a one-to-one relationship between P2MP 
>> ID
>> and P2MP Tunnel even within the scope of a single ingress.
>>
>> Although this was debated (the ingress could uniquely assign one ID per
>> tunnel) we recognized:
>>
>> i. The Tunnel ID field already performs this function
>> ii. It may be desirable to identify common sets of destinations
>>
>> The best example of ii. that was discussed would allow you to place a
>> multicast IP address in the P2MP ID field. This is not mandatory (and 
>> some
>> people think it is a bad idea :-), but the specification was designed to
>> allow it.
>>
>> If an implementation chose to set P2MP ID = Tunnel ID, I guess that would 
>> be
>> very fine with everyone.
>
> For one thing, this would limit the number of tunnels that could be
> originated by a particular root node to 2^16.
>
> It would also rule out the ability to place a multicast IP address in
> the P2MP ID field.

Well, we already have the 2^16 limit for P2P tunnels. Are people running up 
against this limit?
This can easily be seen as a separate set of 2^16 tunnels because a 
different object is used to encode the information, but this is a point that 
should definitely be clarified in the I-D: what is the relationship between 
the Tunnel IDs in P2P and P2MP Sessions?

You're right that an implementation that sets P2MP ID = Tunnel ID cannot 
also set P2MP ID = multicast IP address.
Whether this discussion is even meaningful depends on whether the scope of 
the P2MP ID uniqueness is global (can't use Tunnel ID) or ingress (can use 
Tunnel ID, or multicast address, or timestamp, or anything).

>> > Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt
>> > should say the following:
>> >
>> > 1. A P2MP tunnel is identified by a tuple <root node IP address,
>> > index>, where the index value is unique within the scope of the IP
>> > address of the root node.  The P2MP tunnel identifier <root node
>> > IP address, index> is unique within the same scope as the root node
>> > IP address.
>> >
>> > 2. Both the Extended Tunnel ID and the Tunnel Sender Address fields
>> > carry the root node IP address (both fields carry the same value).
>> > The index is carried in the P2MP ID.
>>
>> I don't believe we should force the Extended Tunnel ID like this when an
>> existing RFC defines another use albeit in the P2P context.
>
> What are exactly the (practical) problems with carrying the root
> node IP address both in the Extended Tunnel ID and in the Tunnel
> Sender Address fields ?

You cannot do Session-based resource sharing across multiple sources.
If you recall, RFC3209 says:
   To uniquely
   identify a TE tunnel, we use the combination of the destination IP
   address (an address of the node which is the egress of the tunnel), a
   Tunnel ID, and the tunnel ingress node's IP address, which is placed
   in the Extended Tunnel ID field.
which supports what you say, but also:
      Extended Tunnel ID
         A 32-bit identifier used in the SESSION that remains constant
         over the life of the tunnel.  Normally set to all zeros.
         Ingress nodes that wish to narrow the scope of a SESSION to the
         ingress-egress pair may place their IPv4 address here as a
         globally unique identifier.

Is there any *practical* impact? Well, *if* the two fields are always going 
to carry the same information, clearly the second field is redundant. If the 
field is redundant, it can be used for other purposes if and when they are 
found. If that is the case, don't force it to be set to an irrelevant value 
in this I-D.

Cheers,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Wed, 24 May 2006 21:28:36 +0000
Message-Id: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
cc: "Loa Andersson" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, [e-mail], "ccamp" <[e-mail]>, "George Swallow" <[e-mail]>, "Deborah Brungard" <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 24 May 2006 14:28:11 -0700
From: Yakov Rekhter <[e-mail]>

Adrian,

> > Few observations and suggestions...
> >
> > (a) <Ingress LSR IP address, P2MP ID> tuple is both necessary and
> > sufficient to unambiguously identify a P2MP Tunnel.
> >
> > (b) Further <Ingress LSR IP address, P2MP ID, LSP ID> is both
> > necessary and sufficient to identify a P2MP LSP.
> 
> Clearly these two statements depend on the definition of "P2MP ID" as you 
> pointed out below.
> 
> As the I-D says...
>    The P2MP ID provides an identifier for the set of destinations of the
>    P2MP TE Tunnel.

Does this identifier have a globally unique scope, or only the scope
of the root ? If the former, then what are the procedures for
assigning such identifiers ?

> And this means that there is not a one-to-one relationship between P2MP ID 
> and P2MP Tunnel even within the scope of a single ingress.
> 
> Although this was debated (the ingress could uniquely assign one ID per 
> tunnel) we recognized:
> 
> i. The Tunnel ID field already performs this function
> ii. It may be desirable to identify common sets of destinations
> 
> The best example of ii. that was discussed would allow you to place a 
> multicast IP address in the P2MP ID field. This is not mandatory (and some 
> people think it is a bad idea :-), but the specification was designed to 
> allow it.
> 
> If an implementation chose to set P2MP ID = Tunnel ID, I guess that would be 
> very fine with everyone.

For one thing, this would limit the number of tunnels that could be
originated by a particular root node to 2^16. 

It would also rule out the ability to place a multicast IP address in
the P2MP ID field.

> > Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt
> > should say the following:
> >
> > 1. A P2MP tunnel is identified by a tuple <root node IP address,
> > index>, where the index value is unique within the scope of the IP
> > address of the root node.  The P2MP tunnel identifier <root node
> > IP address, index> is unique within the same scope as the root node
> > IP address.
> >
> > 2. Both the Extended Tunnel ID and the Tunnel Sender Address fields
> > carry the root node IP address (both fields carry the same value).
> > The index is carried in the P2MP ID.
> 
> I don't believe we should force the Extended Tunnel ID like this when an 
> existing RFC defines another use albeit in the P2P context.

What are exactly the (practical) problems with carrying the root
node IP address both in the Extended Tunnel ID and in the Tunnel
Sender Address fields ?

Yakov.



Envelope-to: [e-mail]
Delivery-date: Wed, 24 May 2006 20:59:48 +0000
Message-ID: <034501c67f74$c42e2450$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Loa Andersson" <[e-mail]>, "Yakov Rekhter" <[e-mail]>
Cc: <[e-mail]>, "ccamp" <[e-mail]>, "George Swallow" <[e-mail]>, "Deborah Brungard" <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt 
Date: Wed, 24 May 2006 18:47:19 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Yakov,

> Few observations and suggestions...
>
> (a) <Ingress LSR IP address, P2MP ID> tuple is both necessary and
> sufficient to unambiguously identify a P2MP Tunnel.
>
> (b) Further <Ingress LSR IP address, P2MP ID, LSP ID> is both
> necessary and sufficient to identify a P2MP LSP.

Clearly these two statements depend on the definition of "P2MP ID" as you 
pointed out below.

As the I-D says...
   The P2MP ID provides an identifier for the set of destinations of the
   P2MP TE Tunnel.

And this means that there is not a one-to-one relationship between P2MP ID 
and P2MP Tunnel even within the scope of a single ingress.

Although this was debated (the ingress could uniquely assign one ID per 
tunnel) we recognized:

i. The Tunnel ID field already performs this function
ii. It may be desirable to identify common sets of destinations

The best example of ii. that was discussed would allow you to place a 
multicast IP address in the P2MP ID field. This is not mandatory (and some 
people think it is a bad idea :-), but the specification was designed to 
allow it.

If an implementation chose to set P2MP ID = Tunnel ID, I guess that would be 
very fine with everyone.

> Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt
> should say the following:
>
> 1. A P2MP tunnel is identified by a tuple <root node IP address,
> index>, where the index value is unique within the scope of the IP
> address of the root node.  The P2MP tunnel identifier <root node
> IP address, index> is unique within the same scope as the root node
> IP address.
>
> 2. Both the Extended Tunnel ID and the Tunnel Sender Address fields
> carry the root node IP address (both fields carry the same value).
> The index is carried in the P2MP ID.

I don't believe we should force the Extended Tunnel ID like this when an 
existing RFC defines another use albeit in the P2P context.

> 3. Tunnel ID field should be set to all zeros, and be ignored on
> receipt.
>
> 4. A P2MP LSP is identified by a combination of tunnel identifier
> (<root node IP address, index>), and LSP ID.
>
> With this in mind sections 4.1, 4.2, 19.1 and 19.2 should be modified
> to clarify the following:
>
> (a) SESSION identifier;
> (b) semantics of Extended Tunnel ID; semantics of the P2MP ID;
> (c) semantics of the Tunnel ID IP address in the SENDER_TEMPLATE.

Cheers,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Wed, 24 May 2006 16:35:56 +0000
Date: Wed, 24 May 2006 09:34:26 -0700 (PDT)
From: Rahul Aggarwal <[e-mail]>
To: Yakov Rekhter <[e-mail]>
cc: Loa Andersson <[e-mail]>, [e-mail], ccamp <[e-mail]>,  George Swallow <[e-mail]>, Adrian Farrel <[e-mail]>,  Deborah Brungard <[e-mail]>, Ross Callon <[e-mail]>,  Bill Fenner <[e-mail]>
Subject: Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Yakov,

Thanks for the comments. Please see below:

On Wed, 24 May 2006, Yakov Rekhter wrote:

> Loa and George,
>
> > Working Group,
> >
> > this initiates a two week working group last call on
> > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> >
> > please send comments to the MPLS working group mailling
> > list and/or working co-chairs.
> >
> > The last call ends eob May 28th.
> >
> > The ccamp mailing list copied as this is a work that has
> > an overlap between the working groups.
> >
> > Loa and George
>
> Few observations and suggestions...
>
> (a) <Ingress LSR IP address, P2MP ID> tuple is both necessary and
> sufficient to unambiguously identify a P2MP Tunnel.
>
> (b) Further <Ingress LSR IP address, P2MP ID, LSP ID> is both
> necessary and sufficient to identify a P2MP LSP.
>

Agreed.

> Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt
> should say the following:
>
> 1. A P2MP tunnel is identified by a tuple <root node IP address,
> index>, where the index value is unique within the scope of the IP
> address of the root node.  The P2MP tunnel identifier <root node
> IP address, index> is unique within the same scope as the root node
> IP address.
>

Ok.

> 2. Both the Extended Tunnel ID and the Tunnel Sender Address fields
> carry the root node IP address (both fields carry the same value).
> The index is carried in the P2MP ID.
>

Ok.

> 3. Tunnel ID field should be set to all zeros, and be ignored on
> receipt.
>

Ok.

> 4. A P2MP LSP is identified by a combination of tunnel identifier
> (<root node IP address, index>), and LSP ID.
>

Ok.

> With this in mind sections 4.1, 4.2, 19.1 and 19.2 should be modified
> to clarify the following:
>
> (a) SESSION identifier;
> (b) semantics of Extended Tunnel ID; semantics of the P2MP ID;
> (c) semantics of the Tunnel ID IP address in the SENDER_TEMPLATE.
>

How about the following rephrasing:

1.

Section 4.1:

" A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
   identified by a P2MP SESSION object. This object contains the
   identifier of the P2MP Session which includes the P2MP ID, a tunnel
   ID and an extended tunnel ID.

   The fields of a P2MP SESSION object are identical to those of the
   SESSION object defined in [RFC3209] except that the Tunnel Endpoint
   Address field is replaced by the P2MP Identifier (P2MP ID) field.

   The P2MP ID provides an identifier for the set of destinations of the
   P2MP TE Tunnel."

to

" A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
identified by a P2MP SESSION object. This object contains the
identifier of the P2MP Session which includes a tuple
<Ingress LSR IP address, P2MP Identifier>, where the P2MP Identifier (P2MP
ID) is unique within the scope of the IP address of the ingress LSR. The
Ingress LSR IP address is encoded in the Extended Tunnel ID. Th P2MP
Tunnel identifier, carried in the P2MP SESSION object, is unique within
the same scope as the ingress LSR IP address.

The fields of the P2MP SESSION object are identical to those of the
SESSION object defined in [RFC3209] except that the Tunnel Endpoint
Address field is replaced by the P2MP ID field."

2.

Section 4.2.

"   A P2MP LSP is identified by the combination of the P2MP ID, Tunnel
   ID, and Extended Tunnel ID that are part of the P2MP SESSION object,
   and the tunnel sender address and LSP ID fields of the P2MP
   SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
   defined in section 20.2."

to

"   A P2MP LSP is identified by the combination of the P2MP ID,
Extended Tunnel ID that are part of the P2MP SESSION object,
and the tunnel sender address and LSP ID fields of the P2MP
SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
defined in section 20.2."

3.

19.1.1

"P2MP ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It encodes the
      P2MP ID and identifies the set of destinations of the P2MP
      Tunnel."

to

"P2MP ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It encodes the
      P2MP Identifier that is unique within the scope of the Ingress LSR
      IP address carried in the Extended Tunnel ID.

4.
19.1.1

"Tunnel ID

      A 16-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel."

to

"Tunnel ID

      A 16-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It SHOULD be set to 0
      by the ingress LSR and be ignored on receipt."


5.

"Extended Tunnel ID

 A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel.  Normally set to
      all zeros. Ingress nodes that wish to narrow the scope of a
      SESSION to the ingress-PID pair may place their IPv4 address
      here as a globally unique identifier [RFC3209]."

to

"Extended Tunnel ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. This identifier
      MUST be set to the ingress LSR's IPv4 address."

6.

19.1.2

"This is same as the P2MP IPv4 LSP SESSION Object with the difference
   that the extended tunnel ID may be set to a 16 byte identifier
   [RFC3209]."

to

"This is same as the P2MP IPv4 LSP SESSION Object with the difference
   that the extended tunnel ID MUST be set to a 16 byte identifier that is
the ingress LSR's IPv6 address."

7.

19.2.1

" IPv4 tunnel sender address
            See [RFC3209]"

to"

"IPv4 tunnel sender address. This address MUST be the same as the address
in the Extended Tunnel ID field of the SESSION object."

8.

19.2.2

"IPv6 tunnel sender address
           See [RFC3209]"

to

"IPv6 tunnel sender address. This address MUST be the same as the address
in the Extended Tunnel ID field of the SESSION object."

Thanks,
rahul

> Yakov.
>



Envelope-to: [e-mail]
Delivery-date: Wed, 24 May 2006 15:35:59 +0000
Message-Id: <[e-mail]>
To: Loa Andersson <[e-mail]>
cc: [e-mail], ccamp <[e-mail]>, George Swallow <[e-mail]>, Adrian Farrel <[e-mail]>, Deborah Brungard <[e-mail]>, Ross Callon <[e-mail]>, Bill Fenner <[e-mail]>
Subject: Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 24 May 2006 08:34:52 -0700
From: Yakov Rekhter <[e-mail]>

Loa and George,

> Working Group,
> 
> this initiates a two week working group last call on
> draft-ietf-mpls-rsvp-te-p2mp-05.txt
> 
> please send comments to the MPLS working group mailling
> list and/or working co-chairs.
> 
> The last call ends eob May 28th.
> 
> The ccamp mailing list copied as this is a work that has
> an overlap between the working groups.
> 
> Loa and George

Few observations and suggestions...

(a) <Ingress LSR IP address, P2MP ID> tuple is both necessary and
sufficient to unambiguously identify a P2MP Tunnel.

(b) Further <Ingress LSR IP address, P2MP ID, LSP ID> is both
necessary and sufficient to identify a P2MP LSP.

Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt
should say the following:

1. A P2MP tunnel is identified by a tuple <root node IP address,
index>, where the index value is unique within the scope of the IP
address of the root node.  The P2MP tunnel identifier <root node
IP address, index> is unique within the same scope as the root node
IP address.

2. Both the Extended Tunnel ID and the Tunnel Sender Address fields
carry the root node IP address (both fields carry the same value).
The index is carried in the P2MP ID.

3. Tunnel ID field should be set to all zeros, and be ignored on
receipt.

4. A P2MP LSP is identified by a combination of tunnel identifier
(<root node IP address, index>), and LSP ID.

With this in mind sections 4.1, 4.2, 19.1 and 19.2 should be modified
to clarify the following:

(a) SESSION identifier; 
(b) semantics of Extended Tunnel ID; semantics of the P2MP ID; 
(c) semantics of the Tunnel ID IP address in the SENDER_TEMPLATE.

Yakov.



Envelope-to: [e-mail]
Delivery-date: Wed, 24 May 2006 07:50:55 +0000
Sensitivity: 
Subject: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00
To: [e-mail]
Cc: "Dan Li <danli" <[e-mail]>, "Dino Bramanti" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 24 May 2006 09:48:25 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

A new ID is available on the ID repository
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-00.txt.

The ID states some basic requrements for the possibility of turning a
Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice
versa, without actually affecting Data Plane traffic, no solutions are
proposed in the ID.

Abstract

   From a Carrier perspective, the possibility of turning a Permanent
   Connection (PC) into a Soft Permanent Connection (SPC) and vice
   versa, without actually affecting Data Plane traffic being carried
   over it, is a valuable option. In other terms, such operation can be
   seen as a way of transferring the ownership and control of an
   existing and in-use Data Plane connection between the Management
   Plane and the Control Plane, leaving its Data Plane state untouched.
   This memo sets out the requirements for such procedures within a
   Generalized Multiprotocol Label Switching (GMPLS) network.


Comments and suggestions are very welcome sxpecially from the carrier
community.

Regards

Diego





Envelope-to: [e-mail]
Delivery-date: Tue, 23 May 2006 17:52:04 +0000
Message-ID: <024a01c67e91$6ecd16d0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "MEURIC Julien RD-CORE-LAN" <[e-mail]>, <[e-mail]>
Subject: Re: Draft response to OIF on 1:n protection
Date: Tue, 23 May 2006 18:50:31 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

OK, Thanks.

I can fold that in with a bit more clarity on the master/slave thing.

Adrian
----- Original Message ----- 
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Tuesday, May 23, 2006 2:35 PM
Subject: RE: Draft response to OIF on 1:n protection


Hi Adrian, hi all.

I have the feeling that the OIF may have prefered to ask CCAMP instead of 
taking into account the mentioned 
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03 and 
draft-ietf-ccamp-gmpls-segment-recovery-02 -- which seem to answer several 
of their questions. That might be due to the fact they are not RFCs yet, so 
it may be useful to inform the OIF of the current status of these and 
reassure about their significance.

A few more comments in line.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf 
Of Adrian Farrel

[...]

> 5.) RFC 4426 refers to three abstract messages involved in the
> reversion sequence:
>
> - A Bridge and Switch Request message from the source node after it
> has bridged traffic back to both working and protection links.
>
> - A Bridge and Switch Response message from the destination node after
> it has bridged traffic back to both working and protection links and
> changed its selector to the working link.
>
> - A Bridge and Switch Completed message from the source node after it
> has changed its selector to the working link and stopped sending traffic
> on the protection link (so the destination can stop transmitting on
> protection).
>
> Since RFC 4426 covers these Bridge and Switch messages briefly, more
> details should be specified on the operation and behavior in this
> reversion process.

If you have specific questions, we would be happy to answer them. If you
believe that additional documentation is required, we would welcome your
contributions as an Internet-Draft.

[JM] This could be a good place to pinpoint the IDs named above.


> Further, it would be helpful to understand why the actions are
> performed by source and destination nodes rather than master and
> slave nodes. It may be appropriate to reuse the master/slave roles
> in the reversion process just as is done in the switchover process.

There is a distinction between the node that invokes a switchover
process (the master) and a node that performs the process. For
example, a Bridge and Switch Request message is sent by the source
node after it has bridged traffic back to both working and protection
links simply because the source node has performed the bridging and
is the only node that can know this fact.

[JM] I may not really get the intial issue here but I'm also confused by the 
answer. My understanding was about the wording "source/destination" vs 
"master/slave"; in that case we should rather restate why "source" and 
"destination" are relevant here. But maybe I need a coffee... ;-)

[...]


Regards,

Julien








Envelope-to: [e-mail]
Delivery-date: Tue, 23 May 2006 13:37:16 +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 response to OIF on 1:n protection
Date: Tue, 23 May 2006 15:35:35 +0200
Message-ID: <[e-mail]>
Thread-Topic: Draft response to OIF on 1:n protection
Thread-Index: AcZ92rrllH3TeHH8SvuO3kjZPhyXFwAgseFg
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, <[e-mail]>

Hi Adrian, hi all.

I have the feeling that the OIF may have prefered to ask CCAMP instead =
of taking into account the mentioned =
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03 and =
draft-ietf-ccamp-gmpls-segment-recovery-02 -- which seem to answer =
several of their questions. That might be due to the fact they are not =
RFCs yet, so it may be useful to inform the OIF of the current status of =
these and reassure about their significance.

A few more comments in line.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On =
Behalf Of Adrian Farrel

[...]

> 5.) RFC 4426 refers to three abstract messages involved in the
> reversion sequence:
>
> - A Bridge and Switch Request message from the source node after it
> has bridged traffic back to both working and protection links.
>
> - A Bridge and Switch Response message from the destination node after
> it has bridged traffic back to both working and protection links and
> changed its selector to the working link.
>
> - A Bridge and Switch Completed message from the source node after it
> has changed its selector to the working link and stopped sending =
traffic
> on the protection link (so the destination can stop transmitting on
> protection).
>
> Since RFC 4426 covers these Bridge and Switch messages briefly, more
> details should be specified on the operation and behavior in this
> reversion process.

If you have specific questions, we would be happy to answer them. If you
believe that additional documentation is required, we would welcome your
contributions as an Internet-Draft.

[JM] This could be a good place to pinpoint the IDs named above.


> Further, it would be helpful to understand why the actions are
> performed by source and destination nodes rather than master and
> slave nodes. It may be appropriate to reuse the master/slave roles
> in the reversion process just as is done in the switchover process.

There is a distinction between the node that invokes a switchover
process (the master) and a node that performs the process. For
example, a Bridge and Switch Request message is sent by the source
node after it has bridged traffic back to both working and protection
links simply because the source node has performed the bridging and
is the only node that can know this fact.

[JM] I may not really get the intial issue here but I'm also confused by =
the answer. My understanding was about the wording "source/destination" =
vs "master/slave"; in that case we should rather restate why "source" =
and "destination" are relevant here. But maybe I need a coffee... ;-)

[...]


Regards,

Julien




Envelope-to: [e-mail]
Delivery-date: Mon, 22 May 2006 23:13:38 +0000
Message-ID: <019101c67df5$359efff0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Wataru Imajuku" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Draft response to OIF on 1:n protection
Date: Tue, 23 May 2006 00:12:27 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Wataru,

Thanks for your mail. I wonder if you could clarify precisely which proposal
you are referring to in the OIF communication and how you believe it should
be taken forward.

Thanks,
Adrian

----- Original Message ----- 
From: "Wataru Imajuku" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, May 22, 2006 11:03 PM
Subject: Re: Draft response to OIF on 1:n protection


> Hi, Adrian and all
>
>  Thank you for introducing proposal from OIF.
>
>  I think this proposal is valuable to add specification
> in RFC 4426/4427/4428 and related drafts.
>  The proposed functionality can enhances applicability of GMPLS protocols
> to enhance the reliability of networks.
>
> Best Regards
> Wataru@NTT
>
>
> At 04:50 06/05/23, Adrian Farrel wrote:
> >Hi,
> >
> >Thanks to those who have sent me off-list comments.
> >
> >Here is a draft response to the OIF on 1:n protection. Please send me (or
> >the list) your comments.
> >
> >Thanks,
> >Adrian
> >
> >===
> >Dear Jim,
> >
> >Thank you for your communication to CCAMP on the use of GMPLS to provide
> >1:n protection at the OIF UNI and the OIF E-NNI.
> >
> >We are grateful for this opportunity to comment, but we note that this
> >type of communication requesting clarifications is better suited to a
> >mailing list discussion than to official communications that, by their
> >nature, have a slow turn-around. The appropriate place for
> >discussions of GMPLS protocols is the CCAMP working group
> >mailing list. Details of how to subscribe to the mailing list can be
> found at http://www.ietf.org/html.charters/ccamp-charter.html
> >
> >> Future updates to OIF UNI and E-NNI signaling may include a feature
> >> for 1:N connection protection. The attached document presents
> >> requirements for these features. Recently a review was completed
> >> of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
> >> implement this function (including draft-ietf-ccamp-gmpls-recovery-
> >> e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
> >> It appears that the abstract messages from RFC 4426 provide much
> >> of this functionality, however several questions resulted from this
> >> review. OIF would appreciate review and comments from IETF
> >>CCAMP on the following items.
> >>
> >> 1.) OIF would appreciate knowing if there are protocol features in
> >> other IETF documents relevant to 1:N protection .
> >
> >We would like to suggest that, in order to utilize advanced features of
> >the GMPLS control plane protocol, engineers should be familiar with
> >the full set of GMPLS RFCs and Internet-Drafts. These are listed on
> >the CCAMP charter page and can be downloaded free of charge by
> >clicking on the links.
> >
> >Although not all of this work is directly related to protection and
> >restoration, it should be noted that any protocol aspect present for a
> >working path may also be required for a protection path. Protocol
> >engineers must, therefore, be familiar with the details of the protocol
> >before attempting to provide advanced functions like protection.
> >
> >> 2.) RFC 4426 section 2.5.2 says "it MAY be possible for the LSPs
> >> on the working link to be mapped to the protection link without
> >> re-signaling each individual LSP" and "it MAY be possible to change
> >> the component links without needing to re-signal each individual LSP".
> >> OIF would like to know what signaling messages and objects can be
> >> used to accomplish this.
> >
> >Your question is confusing in the light of the referenced section.
> >The section describes the messages required to achieve span protection.
> >Clearly, if a span is protected, then all LSPs carried over that span
> >may be transparently protected. This is how normal link protection
> >operates and there is nothing clever going on.
> >
> >Recall that section 2.5.2 is a subsection of section 2, and this is
> >entirely dedicated to span protection.
> >
> >Further, if the bundling example is followed, the referenced RFC
> >(RFC4201) explains the signaling necessary to achieve bundling.
> >
> >You may find it easier to consider this as a layering architecture. The
> >span (link) that is protected is a lower layer commodity and its
> >protection may be, therefore, transparent to the higher layer.
> >
> >If you have a specific question we would be happy to answer.
> >
> >> 3.) It is suggested that the Failure Indication Message (or
> >> equivalent) from RFC 4426 can be triggered not only from a
> >> failure but also a command from a management system.
> >
> >You have not asked a specific question here so it is hard to give any
> >answer except for "yes".
> >
> >Management systems are usually regarded as supreme. A management
> >system can instruct an implementation to do anything, and this may be
> >useful for forced or controlled switch-over. You may want to refer to
> >RFC4427 section 4.13.
> >
> >> 4.) A goal of the 1:N protection is to use a bulk notification and
> >> recovery procedure, based on RFC 4427 section 4.15. However, that RFC
> >> states the corresponding recovery switching actions are performed at
> >> the LSP level. It would be useful to know if bulk processing could be
> >> applied to recovery of individual connection segments on the failed
> >> span,
> >> not entire LSPs.
> >
> >We do not understand your question. Each LSP has its own entry in the
> >switching matrix. Any switching recovery action that is required can
> >only be applied to this individual entry. Implementations may have some
> >optimisations (such as back-up, pre-programmed matrices, or magic matrix
> >re-program commands), but this is clearly out of scope of a control
> >plane specification.
> >
> >Please note that recovery switching actions are not signaling actions.
> >
> >We are also confused as to the meaning of "It would be useful to know if
> >bulk processing could be applied to recovery of individual connection
> >segments on the failed span, not entire LSPs." To process it further, we
> >probably need to deconstruct the term Connection Segment. As you may be
> >aware, the term 'connection segment' is not widely used in the ASON
> >Recommendations and does not find a definition there. The reference from
> >G.8081 is to an ATM forum document.
> >
> >We assume that you are concerned to provide end-to-end data transfer.
> >Presumably you are interested in a variety of symmetrical cases such as
> >client-layer connectivity, UNI-C to UNI-C connectivity, UNI-N to UNI-N
> >connectivity, or UNI-N/E-NNI to E-NNI/UNI-N connectivity. The path
> >between these points is an LSP (it may be a hierarchical LSP through
> >which
> >other LSPs are tunneled) and it is this path that you wish to protect.
> >Whether you perform span, segment, or end-to-end protection, you are
> >still
> >protecting the LSP.
> >
> >> 5.) RFC 4426 refers to three abstract messages involved in the
> >> reversion sequence:
> >>
> >> - A Bridge and Switch Request message from the source node after it
> >> has bridged traffic back to both working and protection links.
> >>
> >> - A Bridge and Switch Response message from the destination node after
> >> it has bridged traffic back to both working and protection links and
> >> changed its selector to the working link.
> >>
> >> - A Bridge and Switch Completed message from the source node after it
> >> has changed its selector to the working link and stopped sending
> >> traffic
> >> on the protection link (so the destination can stop transmitting on
> >> protection).
> >>
> >> Since RFC 4426 covers these Bridge and Switch messages briefly, more
> >> details should be specified on the operation and behavior in this
> >> reversion process.
> >
> >If you have specific questions, we would be happy to answer them. If you
> >believe that additional documentation is required, we would welcome your
> >contributions as an Internet-Draft.
> >
> >> Further, it would be helpful to understand why the actions are
> >> performed by source and destination nodes rather than master and
> >> slave nodes. It may be appropriate to reuse the master/slave roles
> >> in the reversion process just as is done in the switchover process.
> >
> >There is a distinction between the node that invokes a switchover
> >process (the master) and a node that performs the process. For
> >example, a Bridge and Switch Request message is sent by the source
> >node after it has bridged traffic back to both working and protection
> >links simply because the source node has performed the bridging and
> >is the only node that can know this fact.
> >
> >> In addition, RFC 4426 does not include an abstract message similar to
> >> the Failure Indication Message to request the beginning of the
> >> reversion
> >> procedure. It may be beneficial to include a message from the slave
> >> device to initiate reversion, just as there is a Failure Indication
> >> Message
> >> to initiate switchover. (RFC 4426 states that the Failure Indication
> >> Message may not be needed when the transport plane technology
> >> itself provides such a notification. The same may apply when a failure
> >> is cleared; however, there should still be an optional message to
> >> trigger the reversion process.)
> >
> >Reversion is described as an administrative procedure quite
> >deliberately. In our view it should not be a rapid response to a
> >specific situation triggered through the control plane by the 'master',
> >but should be a considered operation under the control of administrative
> >policy. The trigger is, therefore, outside the scope of the control
> >plane.
> >This is in section 4.13 of RFC4427.
> >
> >We hope this answers your questions, and we would be happy to enter into
> >further dialog on these topics.
> >
> >Best regards,
> >Adrian Farrel and Deborah Brungard
> >CCAMP co-chairs
> >
> >
> >
> >
> >
>
> -------------------------------------
> Wataru Imajuku@NTT Network Innovation Labs
> TEL: [phone]
> FAX: [phone]
>
>
>
>
>





Envelope-to: [e-mail]
Delivery-date: Mon, 22 May 2006 22:03:57 +0000
Message-Id: <[e-mail]>
Date: Tue, 23 May 2006 07:03:14 +0900
To: "Adrian Farrel" <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: Re: Draft response to OIF on 1:n protection
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Adrian and all

  Thank you for introducing proposal from OIF.

  I think this proposal is valuable to add specification
in RFC 4426/4427/4428 and related drafts.
  The proposed functionality can enhances applicability of GMPLS protocols
to enhance the reliability of networks.

Best Regards
Wataru@NTT


At 04:50 06/05/23, Adrian Farrel wrote:
 >Hi,
 >
 >Thanks to those who have sent me off-list comments.
 >
 >Here is a draft response to the OIF on 1:n protection. Please send me (or
 >the list) your comments.
 >
 >Thanks,
 >Adrian
 >
 >===
 >Dear Jim,
 >
 >Thank you for your communication to CCAMP on the use of GMPLS to provide
 >1:n protection at the OIF UNI and the OIF E-NNI.
 >
 >We are grateful for this opportunity to comment, but we note that this
 >type of communication requesting clarifications is better suited to a
 >mailing list discussion than to official communications that, by their
 >nature, have a slow turn-around. The appropriate place for
 >discussions of GMPLS protocols is the CCAMP working group
 >mailing list. Details of how to subscribe to the mailing list can be 
found at http://www.ietf.org/html.charters/ccamp-charter.html
 >
 >> Future updates to OIF UNI and E-NNI signaling may include a feature
 >> for 1:N connection protection. The attached document presents
 >> requirements for these features. Recently a review was completed
 >> of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
 >> implement this function (including draft-ietf-ccamp-gmpls-recovery-
 >> e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
 >> It appears that the abstract messages from RFC 4426 provide much
 >> of this functionality, however several questions resulted from this
 >> review. OIF would appreciate review and comments from IETF
 >>CCAMP on the following items.
 >>
 >> 1.) OIF would appreciate knowing if there are protocol features in
 >> other IETF documents relevant to 1:N protection .
 >
 >We would like to suggest that, in order to utilize advanced features of
 >the GMPLS control plane protocol, engineers should be familiar with
 >the full set of GMPLS RFCs and Internet-Drafts. These are listed on
 >the CCAMP charter page and can be downloaded free of charge by
 >clicking on the links.
 >
 >Although not all of this work is directly related to protection and
 >restoration, it should be noted that any protocol aspect present for a
 >working path may also be required for a protection path. Protocol
 >engineers must, therefore, be familiar with the details of the protocol
 >before attempting to provide advanced functions like protection.
 >
 >> 2.) RFC 4426 section 2.5.2 says "it MAY be possible for the LSPs
 >> on the working link to be mapped to the protection link without
 >> re-signaling each individual LSP" and "it MAY be possible to change
 >> the component links without needing to re-signal each individual LSP".
 >> OIF would like to know what signaling messages and objects can be
 >> used to accomplish this.
 >
 >Your question is confusing in the light of the referenced section.
 >The section describes the messages required to achieve span protection.
 >Clearly, if a span is protected, then all LSPs carried over that span
 >may be transparently protected. This is how normal link protection
 >operates and there is nothing clever going on.
 >
 >Recall that section 2.5.2 is a subsection of section 2, and this is
 >entirely dedicated to span protection.
 >
 >Further, if the bundling example is followed, the referenced RFC
 >(RFC4201) explains the signaling necessary to achieve bundling.
 >
 >You may find it easier to consider this as a layering architecture. The
 >span (link) that is protected is a lower layer commodity and its
 >protection may be, therefore, transparent to the higher layer.
 >
 >If you have a specific question we would be happy to answer.
 >
 >> 3.) It is suggested that the Failure Indication Message (or
 >> equivalent) from RFC 4426 can be triggered not only from a
 >> failure but also a command from a management system.
 >
 >You have not asked a specific question here so it is hard to give any
 >answer except for "yes".
 >
 >Management systems are usually regarded as supreme. A management
 >system can instruct an implementation to do anything, and this may be
 >useful for forced or controlled switch-over. You may want to refer to
 >RFC4427 section 4.13.
 >
 >> 4.) A goal of the 1:N protection is to use a bulk notification and
 >> recovery procedure, based on RFC 4427 section 4.15. However, that RFC
 >> states the corresponding recovery switching actions are performed at
 >> the LSP level. It would be useful to know if bulk processing could be
 >> applied to recovery of individual connection segments on the failed span,
 >> not entire LSPs.
 >
 >We do not understand your question. Each LSP has its own entry in the
 >switching matrix. Any switching recovery action that is required can
 >only be applied to this individual entry. Implementations may have some
 >optimisations (such as back-up, pre-programmed matrices, or magic matrix
 >re-program commands), but this is clearly out of scope of a control
 >plane specification.
 >
 >Please note that recovery switching actions are not signaling actions.
 >
 >We are also confused as to the meaning of "It would be useful to know if
 >bulk processing could be applied to recovery of individual connection
 >segments on the failed span, not entire LSPs." To process it further, we
 >probably need to deconstruct the term Connection Segment. As you may be
 >aware, the term 'connection segment' is not widely used in the ASON
 >Recommendations and does not find a definition there. The reference from
 >G.8081 is to an ATM forum document.
 >
 >We assume that you are concerned to provide end-to-end data transfer.
 >Presumably you are interested in a variety of symmetrical cases such as
 >client-layer connectivity, UNI-C to UNI-C connectivity, UNI-N to UNI-N
 >connectivity, or UNI-N/E-NNI to E-NNI/UNI-N connectivity. The path
 >between these points is an LSP (it may be a hierarchical LSP through which
 >other LSPs are tunneled) and it is this path that you wish to protect.
 >Whether you perform span, segment, or end-to-end protection, you are still
 >protecting the LSP.
 >
 >> 5.) RFC 4426 refers to three abstract messages involved in the
 >> reversion sequence:
 >>
 >> - A Bridge and Switch Request message from the source node after it
 >> has bridged traffic back to both working and protection links.
 >>
 >> - A Bridge and Switch Response message from the destination node after
 >> it has bridged traffic back to both working and protection links and
 >> changed its selector to the working link.
 >>
 >> - A Bridge and Switch Completed message from the source node after it
 >> has changed its selector to the working link and stopped sending traffic
 >> on the protection link (so the destination can stop transmitting on
 >> protection).
 >>
 >> Since RFC 4426 covers these Bridge and Switch messages briefly, more
 >> details should be specified on the operation and behavior in this
 >> reversion process.
 >
 >If you have specific questions, we would be happy to answer them. If you
 >believe that additional documentation is required, we would welcome your
 >contributions as an Internet-Draft.
 >
 >> Further, it would be helpful to understand why the actions are
 >> performed by source and destination nodes rather than master and
 >> slave nodes. It may be appropriate to reuse the master/slave roles
 >> in the reversion process just as is done in the switchover process.
 >
 >There is a distinction between the node that invokes a switchover
 >process (the master) and a node that performs the process. For
 >example, a Bridge and Switch Request message is sent by the source
 >node after it has bridged traffic back to both working and protection
 >links simply because the source node has performed the bridging and
 >is the only node that can know this fact.
 >
 >> In addition, RFC 4426 does not include an abstract message similar to
 >> the Failure Indication Message to request the beginning of the reversion
 >> procedure. It may be beneficial to include a message from the slave
 >> device to initiate reversion, just as there is a Failure Indication
 >> Message
 >> to initiate switchover. (RFC 4426 states that the Failure Indication
 >> Message may not be needed when the transport plane technology
 >> itself provides such a notification. The same may apply when a failure
 >> is cleared; however, there should still be an optional message to
 >> trigger the reversion process.)
 >
 >Reversion is described as an administrative procedure quite
 >deliberately. In our view it should not be a rapid response to a
 >specific situation triggered through the control plane by the 'master',
 >but should be a considered operation under the control of administrative
 >policy. The trigger is, therefore, outside the scope of the control plane.
 >This is in section 4.13 of RFC4427.
 >
 >We hope this answers your questions, and we would be happy to enter into
 >further dialog on these topics.
 >
 >Best regards,
 >Adrian Farrel and Deborah Brungard
 >CCAMP co-chairs
 >
 >
 >
 >
 >

-------------------------------------
Wataru Imajuku@NTT Network Innovation Labs
TEL: [phone]
FAX: [phone]





Envelope-to: [e-mail]
Delivery-date: Mon, 22 May 2006 19:57:18 +0000
Message-ID: <015b01c67dd9$af1ac420$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Draft response to OIF on 1:n protection
Date: Mon, 22 May 2006 20:50:32 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Thanks to those who have sent me off-list comments.

Here is a draft response to the OIF on 1:n protection. Please send me (or
the list) your comments.

Thanks,
Adrian

===
Dear Jim,

Thank you for your communication to CCAMP on the use of GMPLS to provide
1:n protection at the OIF UNI and the OIF E-NNI.

We are grateful for this opportunity to comment, but we note that this
type of communication requesting clarifications is better suited to a
mailing list discussion than to official communications that, by their
nature, have a slow turn-around. The appropriate place for
discussions of GMPLS protocols is the CCAMP working group
mailing list. Details of how to subscribe to the mailing list can be found 
at http://www.ietf.org/html.charters/ccamp-charter.html

> Future updates to OIF UNI and E-NNI signaling may include a feature
> for 1:N connection protection. The attached document presents
> requirements for these features. Recently a review was completed
> of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
> implement this function (including draft-ietf-ccamp-gmpls-recovery-
> e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
> It appears that the abstract messages from RFC 4426 provide much
> of this functionality, however several questions resulted from this
> review. OIF would appreciate review and comments from IETF
>CCAMP on the following items.
>
> 1.) OIF would appreciate knowing if there are protocol features in
> other IETF documents relevant to 1:N protection .

We would like to suggest that, in order to utilize advanced features of
the GMPLS control plane protocol, engineers should be familiar with
the full set of GMPLS RFCs and Internet-Drafts. These are listed on
the CCAMP charter page and can be downloaded free of charge by
clicking on the links.

Although not all of this work is directly related to protection and
restoration, it should be noted that any protocol aspect present for a
working path may also be required for a protection path. Protocol
engineers must, therefore, be familiar with the details of the protocol
before attempting to provide advanced functions like protection.

> 2.) RFC 4426 section 2.5.2 says "it MAY be possible for the LSPs
> on the working link to be mapped to the protection link without
> re-signaling each individual LSP" and "it MAY be possible to change
> the component links without needing to re-signal each individual LSP".
> OIF would like to know what signaling messages and objects can be
> used to accomplish this.

Your question is confusing in the light of the referenced section.
The section describes the messages required to achieve span protection.
Clearly, if a span is protected, then all LSPs carried over that span
may be transparently protected. This is how normal link protection
operates and there is nothing clever going on.

Recall that section 2.5.2 is a subsection of section 2, and this is
entirely dedicated to span protection.

Further, if the bundling example is followed, the referenced RFC
(RFC4201) explains the signaling necessary to achieve bundling.

You may find it easier to consider this as a layering architecture. The
span (link) that is protected is a lower layer commodity and its
protection may be, therefore, transparent to the higher layer.

If you have a specific question we would be happy to answer.

> 3.) It is suggested that the Failure Indication Message (or
> equivalent) from RFC 4426 can be triggered not only from a
> failure but also a command from a management system.

You have not asked a specific question here so it is hard to give any
answer except for "yes".

Management systems are usually regarded as supreme. A management
system can instruct an implementation to do anything, and this may be
useful for forced or controlled switch-over. You may want to refer to
RFC4427 section 4.13.

> 4.) A goal of the 1:N protection is to use a bulk notification and
> recovery procedure, based on RFC 4427 section 4.15. However, that RFC
> states the corresponding recovery switching actions are performed at
> the LSP level. It would be useful to know if bulk processing could be
> applied to recovery of individual connection segments on the failed span,
> not entire LSPs.

We do not understand your question. Each LSP has its own entry in the
switching matrix. Any switching recovery action that is required can
only be applied to this individual entry. Implementations may have some
optimisations (such as back-up, pre-programmed matrices, or magic matrix
re-program commands), but this is clearly out of scope of a control
plane specification.

Please note that recovery switching actions are not signaling actions.

We are also confused as to the meaning of "It would be useful to know if
bulk processing could be applied to recovery of individual connection
segments on the failed span, not entire LSPs." To process it further, we
probably need to deconstruct the term Connection Segment. As you may be
aware, the term 'connection segment' is not widely used in the ASON
Recommendations and does not find a definition there. The reference from
G.8081 is to an ATM forum document.

We assume that you are concerned to provide end-to-end data transfer.
Presumably you are interested in a variety of symmetrical cases such as
client-layer connectivity, UNI-C to UNI-C connectivity, UNI-N to UNI-N
connectivity, or UNI-N/E-NNI to E-NNI/UNI-N connectivity. The path
between these points is an LSP (it may be a hierarchical LSP through which
other LSPs are tunneled) and it is this path that you wish to protect.
Whether you perform span, segment, or end-to-end protection, you are still
protecting the LSP.

> 5.) RFC 4426 refers to three abstract messages involved in the
> reversion sequence:
>
> - A Bridge and Switch Request message from the source node after it
> has bridged traffic back to both working and protection links.
>
> - A Bridge and Switch Response message from the destination node after
> it has bridged traffic back to both working and protection links and
> changed its selector to the working link.
>
> - A Bridge and Switch Completed message from the source node after it
> has changed its selector to the working link and stopped sending traffic
> on the protection link (so the destination can stop transmitting on
> protection).
>
> Since RFC 4426 covers these Bridge and Switch messages briefly, more
> details should be specified on the operation and behavior in this
> reversion process.

If you have specific questions, we would be happy to answer them. If you
believe that additional documentation is required, we would welcome your
contributions as an Internet-Draft.

> Further, it would be helpful to understand why the actions are
> performed by source and destination nodes rather than master and
> slave nodes. It may be appropriate to reuse the master/slave roles
> in the reversion process just as is done in the switchover process.

There is a distinction between the node that invokes a switchover
process (the master) and a node that performs the process. For
example, a Bridge and Switch Request message is sent by the source
node after it has bridged traffic back to both working and protection
links simply because the source node has performed the bridging and
is the only node that can know this fact.

> In addition, RFC 4426 does not include an abstract message similar to
> the Failure Indication Message to request the beginning of the reversion
> procedure. It may be beneficial to include a message from the slave
> device to initiate reversion, just as there is a Failure Indication
> Message
> to initiate switchover. (RFC 4426 states that the Failure Indication
> Message may not be needed when the transport plane technology
> itself provides such a notification. The same may apply when a failure
> is cleared; however, there should still be an optional message to
> trigger the reversion process.)

Reversion is described as an administrative procedure quite
deliberately. In our view it should not be a rapid response to a
specific situation triggered through the control plane by the 'master',
but should be a considered operation under the control of administrative
policy. The trigger is, therefore, outside the scope of the control plane.
This is in section 4.13 of RFC4427.

We hope this answers your questions, and we would be happy to enter into
further dialog on these topics.

Best regards,
Adrian Farrel and Deborah Brungard
CCAMP co-chairs





Envelope-to: [e-mail]
Delivery-date: Sun, 21 May 2006 10:37:43 +0000
Message-ID: <006501c67cc2$5668b480$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Communication from OIF on GMPLS for Ethernet
Date: Sun, 21 May 2006 11:35:40 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We have received a further communication from the OIF on the use of GMPLS to 
support Ethernet access.

Again, this communication requests a response, and the chairs will draft 
something with your contributions.

The full liaison can be seen at www.olddog.co.uk/incoming.htm

Thanks,
Adrian

To: Adrian Farrel and Deborah Brungard, IETF CCAMP WG Co-Chairs
From: Jim Jones, OIF TC Chair
Copy: Ross Callon and Bill Fenner, IETF Routing Area Directors
Subject: Use of RSVP to support Ethernet Access

Dear Adrian and Deborah,

During our discussion of protocol requirements to support Ethernet services 
over optical networks, we identified some issues where application of the 
GMPLS specifications were not clear to us. We request CCAMP's views on the 
following issues:

1. Use of parameters to distinguish port-based vs. VLAN-tag-based forwarding 
of Ethernet frames

We have identified two variations on support of Ethernet services at the 
network access point:

a) in the first variation, received frames are forwarded into a specific 
SONET/SDH path based on the incoming port, without processing the header 
information in the Ethernet frame; and

b) in the second variation, received frames are forwarded into specific 
SONET/SDH paths based on header information, esp. the VLAN tag.

It is not fully clear to us how these are distinguished in GMPLS signaling, 
especially forwarding behavior (a) above. The closest match that was 
identified was to use the following approach:
- use the Switching Type value of "FSC" to indicate forwarding based on 
port; and
- use the Switching Type value of "L2SC" to indicate forwarding based on the 
L2 protocol header of received frames.

However, we feel that neither FSC nor L2SC exactly expresses behavior (a) 
above. In particular, "FSC" can also be interpreted as meaning that the 
signal received on the fiber is forwarded exactly as received, in its 
entirety, independent of the signal type (SONET, Ethernet, or other).

We request CCAMP comment on whether this approach is the correct 
interpretation of the specifications or if an alternative and/or 
supplemental mechanism should be considered.

2. Use of Label for these cases

In addition to the question on the use of Switching Capability, it was not 
clear what value should be used as the Generalized Label for these cases.

For case (a) above, our current assumption is that the Label reflects the 
affected port, however it was noted that this may duplicate information in 
the RSVP_HOP Interface Index sub-TLV.

For case (b) above it seems logical that the Label reflect the affected VLAN 
tags. We are investigating label formats to represent a list or range of 
VLAN identifiers, as used in MEF.11 bundling. In the case where a large 
number of non-consecutive VLAN identifiers is used for the same connection, 
we would like to keep the label to a reasonable size. In the case of 
bi-directional connections, the UPSTREAM_LABEL is used to indicate the 
connection is bi-directional. The LABEL_SET is then used if there is a need 
for the labels to be identical in both directions. In that case, there is a 
redundancy of labels. That is problematic with large label formats. We would 
appreciate your advice regarding the possibility to reduce the number of 
labels required in the case of bi-directional connections where the label is 
the same in both directions.

OIF requests CCAMP's comment on the use of Labels in these cases.

Best regards,
Jim Jones
OIF Technical Committee Chair 





Envelope-to: [e-mail]
Delivery-date: Sat, 20 May 2006 14:22:56 +0000
Message-ID: <0b7a01c67c18$6ffd2c00$36849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Liaison from the OIF
Date: Sat, 20 May 2006 15:15:35 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We have received a communication from the OIF about the use of GMPLS 
protocols to provide 1:n protection. This includes a lot of questions for 
clarification and, although my first response is to suggest more careful 
reading of the associated RFCs and I-Ds, we should, nevertheless put 
together a more detailed reply pointing to the relevant sections and 
explaining how the protocols work

Deborah and I (ha! welcome to the world of work, Deborah ;-) will put 
together a response for your review, but we would welcome input from all 
interested parties.

The text of the communication is included below. It can be found in its 
original form (PDF) together with an attachment (PPT) at 
www.olddog.co.uk/incoming.htm

Thanks,
Adrian
----- Original Message ----- 
From: "Lisa Daugherty" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; "'Jim Jones'" 
<[e-mail]>; "'Trey Malpass'" <[e-mail]>
Sent: Friday, May 19, 2006 7:17 PM
Subject: Liaison from the OIF

> Dear Adrian and Deborah,
>
> On behalf of OIF Technical Committee Chair, Jim Jones, attached please 
> find
> a liaison letter and related OIF presentation (oif2006.031.01).
>
> Kind regards,
> Lisa
>
> Lisa Daugherty/ Association Coordinator / OIF
> 39355 California Street, Suite 307/ Fremont, CA 94538
> Phone: [phone] (direct) / 510.608.5928 (main)
> Fax: [phone]
> Email: [e-mail]
> http://www.oiforum.com
>
> Managed by Association Management Solutions (AMS);
> Forum Management, Meeting and Event Planning
> http://www.amsl.com

======
To: Adrian Farrel and Deborah Brungard, IETF CCAMP WG Co-Chairs
From: Jim Jones, OIF TC Chair
Copy: Ross Callon and Bill Fenner, IETF Routing Area Directors
Subject: Liaison to IETF CCAMP WG on 1:N Protection

Dear Adrian and Deborah,

Future updates to OIF UNI and E-NNI signaling may include a feature for 1:N 
connection protection. The attached document presents requirements for these 
features. Recently a review was completed of RFCs 4426, 4427 and 4428 and 
IETF drafts that may be able to implement this function (including 
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03 and 
draft-ietf-ccamp-gmpls-segment-recovery-02). It appears that the abstract 
messages from RFC 4426 provide much of this functionality, however several 
questions resulted from this review. OIF would appreciate review and 
comments from IETF CCAMP on the following items.

1.) OIF would appreciate knowing if there are protocol features in other 
IETF documents relevant to 1:N protection .

2.) RFC 4426 section 2.5.2 says "it MAY be possible for the LSPs on the 
working link to be mapped to the protection link without re-signaling each 
individual LSP" and "it MAY be possible to change the component links 
without needing to re-signal each individual LSP". OIF would like to know 
what signaling messages and objects can be used to accomplish this.

3.) It is suggested that the Failure Indication Message (or equivalent) from 
RFC 4426 can be triggered not only from a failure but also a command from a 
management system.

4.) A goal of the 1:N protection is to use a bulk notification and recovery 
procedure, based on RFC 4427 section 4.15. However, that RFC states the 
corresponding recovery switching actions are performed at the LSP level. It 
would be useful to know if bulk processing could be applied to recovery of 
individual connection segments on the failed span, not entire LSPs.

5.) RFC 4426 refers to three abstract messages involved in the reversion 
sequence:

- A Bridge and Switch Request message from the source node after it has 
bridged traffic back to both working and protection links.

- A Bridge and Switch Response message from the destination node after it 
has bridged traffic back to both working and protection links and changed 
its selector to the working link.

- A Bridge and Switch Completed message from the source node after it has 
changed its selector to the working link and stopped sending traffic on the 
protection link (so the destination can stop transmitting on protection).

Since RFC 4426 covers these Bridge and Switch messages briefly, more details 
should be specified on the operation and behavior in this reversion process. 
Further, it would be helpful to understand why the actions are performed by 
source and destination nodes rather than master and slave nodes. It may be 
appropriate to reuse the master/slave roles in the reversion process just as 
is done in the switchover process.

In addition, RFC 4426 does not include an abstract message similar to the 
Failure Indication Message to request the beginning of the reversion 
procedure. It may be beneficial to include a message from the slave device 
to initiate reversion, just as there is a Failure Indication Message to 
initiate switchover. (RFC 4426 states that the Failure Indication Message 
may not be needed when the transport plane technology itself provides such a 
notification. The same may apply when a failure is cleared; however, there 
should still be an optional message to trigger the reversion process.)

The OIF would appreciate the review and feedback of the CCAMP working group 
on these items.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments
1.) Update for 1:N Protection capability: Control Plane assisted 1:N link 
connection protection (oif2006.031.01) 





Envelope-to: [e-mail]
Delivery-date: Fri, 19 May 2006 10:00:07 +0000
Message-ID: <098d01c67b2a$bb50dec0$36849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada 
Date: Fri, 19 May 2006 09:18:38 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 7bit

FYI
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Friday, May 19, 2006 5:00 AM
Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting 
in Montreal, Quebec, Canada


>
> There are two (2) Internet-Draft cutoff dates for the 66th
> IETF Meeting in Montreal, Quebec, Canada:
>
> June 19th: Cutoff Date for Initial (i.e., version -00)
> Internet-Draft Submissions
>
> All initial Internet-Drafts (version -00) must be submitted by Monday,
> June 19th at 9:00 AM ET. As always, all initial submissions with a
> filename beginning with "draft-ietf" must be approved by the
> appropriate WG Chair before they can be processed or announced.  The
> Secretariat would appreciate receiving WG Chair approval by Monday,
> June 12th at 9:00 AM ET.
>
> June 26th: Cutoff Date for Revised (i.e., version -01 and higher)
> Internet-Draft Submissions
>
> All revised Internet-Drafts (version -01 and higher) must be submitted
> by Monday, June 26th at 9:00 AM ET.
>
> Initial and revised Internet-Drafts received after their respective
> cutoff dates will not be made available in the Internet-Drafts
> directory or announced until on or after Monday, July 10th at 9:00
> AM ET, when Internet-Draft posting resumes.  Please do not wait until
> the last minute to submit.
>
> Thank you for your understanding and cooperation. If you have any
> questions or concerns, then please send a message to
> [e-mail].
>
> The IETF Secretariat
>
> FYI: The Internet-Draft cutoff dates as well as other significant dates
> for the 66th IETF Meeting can be found at 
> http://www.ietf.org/meetings/cutoff_dates_66.html.
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 17 May 2006 18:53:54 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 May 2006 20:49:58 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Greg Jones greg.jones"@itu.int
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], pwe3 <[e-mail]>, Ross Callon <[e-mail]>
Subject: Response to your liaison on T-MPLS of May 4 and April 2 2006
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

To: ITU-T Study Group 15
      Greg Jones [e-mail]


Cc: IETF [e-mail]
      Stephen Trowbridge [e-mail]
      Ghani Abbas [e-mail]
      Mark Jones [e-mail]
      Malcolm Betts [e-mail]
      Yoichi Maeda [e-mail]
      Ross Callon [e-mail]
      Bill Fenner [e-mail]
      Scott Bradner [e-mail]
      George Swallow [e-mail]
      MPLS mailing list [e-mail]
      CCAMP mailing list [e-mail]

From: IETF MPLS Working Group

Response contact: Loa Andersson [e-mail]

Technical contact: Loa Andersson [e-mail]

Purpose: Information

Subject: Response to your liaison on T-MPLS of May 4 and April 2 2006


Thanks for your liaisons of May 4 and April 2 and for the kind
invitation to the interim meeting that 19-23 June in Ottawa.

We have studied the consented documents from the April liaison
and the further clarifications in the May liaisons.

We have ensured that IETF technical experts will participate
in the Ottawa meeting.

This response represents the consensus of the MPLS Working
Group at the IETF.  Other working groups,
such as the PWE3 Working Group may also send responses.

We do not consider that the comments we sent in our preliminary
response have been addressed satisfactorily. We also understand
that at least one new parameter has been introduced late in the
discussion - the design decision that T-MPLS will be initially
scoped to 802.3 clients (Ethernet interfaces), with future
consideration for MPLS LSR clients.

There are three major issues that we need to understand:

  1. The requirements

        We have not seen any documentation of the problem that T-MPLS
        solves.

  2. The reserved labels

        As this is a compatibility issue, we are very concerned. We
        request that you document any requirements for reserved labels
        and bring those requirements to the MPLS Working Group in the
        IETF. There is a (G)MPLS change process that can be used for
        this "draft-andersson-rtg-gmpls-change-02.txt"

  3. MPLS functionality equipment T-MPLS networks.

        Since we still incompatibilities between the MPLS and
        T-MPLS specifications we are concerned that existing
        MPLS equipment, even though T-MPLS is said to to be a true
        subset of MPLS, won't be possible to use in T-MPLS
        networks.

The recently introduced design with Ethernet EVCs will help to
get around some of the issues we pointed out. Equipment in
the T-MPLS network will not have to negotiate labels with
equipment in MPLS enabled IP networks. However, we are still
concerned about what "future consideration for IP/MPLS clients"
might entail.


Loa Andersson and George Swallow
IETF MPLS Working Group Co-Chairs

-- 
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: Mon, 15 May 2006 22:56:22 +0000
Date: Mon, 15 May 2006 15:54:50 -0700 (PDT)
From: Rahul Aggarwal <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: RE: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Ben,

Thanks for the comments. Please see inline:

On Mon, 15 May 2006 [e-mail] wrote:

> [e-mail] <> wrote:
> > Working Group,
> >
> > this initiates a two week working group last call on
> > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> >
> > please send comments to the MPLS working group mailling list and/or
> > working co-chairs.
>
> Section 4.3, paragraph 1 states "The two most notable differences are
> that a P2MP LSP comprises multiple S2L Sub-LSPs and that, as a result of
> this, it may not be possible to represent full state in a single IP
> packet and even more likely that it can't fit into a single IP packet."
>
> Which appears to repeat itself.
>

Will reword the following:

"As with all other RSVP controlled LSPs, P2MP LSP state is managed
   using RSVP messages. While use of RSVP messages is the same, P2MP LSP
   state differs from P2P LSP state in a number of ways. The two most
   notable differences are that a P2MP LSP comprises multiple S2L Sub-
   LSPs and that, as a result of this, it may not be possible to
   represent full state in a single IP packet and even more likely that
   it can't fit into a single IP packet. It must also be possible to
   efficiently add and remove endpoints to and from P2MP TE LSPs. An
   additional issue is that the P2MP LSP must also handle the state
   "remerge" problem, see [RFC4461]."

to

"As with all other RSVP controlled LSPs, P2MP LSP state is managed
   using RSVP messages. While use of RSVP messages is the same, P2MP LSP
   state differs from P2P LSP state in a number of ways. A P2MP LSP
comprises multiple S2L Sub-LSPs and as a result of this it may not be
possible to represent full state in a single IP packet. It must also be
possible to efficiently add and remove endpoints to and from P2MP TE LSPs. An
additional issue is that the P2MP LSP must also handle the state
"remerge" problem, see [RFC4461]."



> Section 5.2.4, paragraph 2 states "The ingress LSP may request 'LSP
> integrity' by setting bit (TBA) of the Attributes Flags TLV. The bit is
> set if LSP integrity is required."
>
> Should the bit that needs setting be defined here (rather than TBA) or
> is that down to IANA?
>

The editors will request a specific bit.

> Section 18, paragraph 1 "This section is currently under discussion
> between the authors and will be updated in the next revision."
>
> Is this paragraph appropriate?
>

No. Thanks for catching it. Will remove it.

Thanks,
rahul

> Ben
>
>



Envelope-to: [e-mail]
Delivery-date: Mon, 15 May 2006 19:12:16 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>, ccamp chair <[e-mail]>
Subject: Protocol Action: 'Link Management Protocol (LMP) Management  Information Base (MIB)' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Mon, 15 May 2006 15:12:06 -0400

The IESG has approved the following document:

- 'Link Management Protocol (LMP) Management Information Base (MIB) '
   <draft-ietf-ccamp-rfc4327bis-01.txt> as a Proposed Standard

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Bill Fenner and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4327bis-01.txt

Technical Summary
 
  This memo defines a portion of the Management Information Base (MIB)
  for use with network management protocols in the Internet community.
  In particular, it describes managed objects for modeling the Link
  Management Protocol (LMP).  It updates RFC 4327 to correct incorrect
  numerical values for the values of the TruthValue TC.  These numbers
  were all in text such as DESCRIPTIONs or examples; the MIB itself is
  unchanged from the one in RFC 4327.
 
Working Group Summary
 
  The Working Group has consensus to publish this document as an RFC
  at Proposed Standard level.
 
Protocol Quality
 
  This document was reviewed for the IESG by Bill Fenner.




Envelope-to: [e-mail]
Delivery-date: Mon, 15 May 2006 19:12:10 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>, ccamp chair <[e-mail]>
Subject: Document Action: 'Evaluation of existing Routing Protocols  against ASON routing requirements' to Informational RFC 
Message-Id: <[e-mail]>
Date: Mon, 15 May 2006 15:10:40 -0400

The IESG has approved the following document:

- 'Evaluation of existing Routing Protocols against ASON routing requirements '
   <draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt> as an Informational RFC

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Ross Callon and Bill Fenner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt

Technical Summary
 
 This is an informational document that could be thought of as serving a
liaision function, since it discusses how IETF routing protocols (particularly
OSPF and IS-IS) can support the ASON work that is being done in the ITU.
 
Working Group Summary
 
 No dissent. 
 
Protocol Quality
 
 Ross Callon has reviewed this for the IESG. Also reviewed by Deborah Brungard
at Ross's request. Document has a good set of authors across CCAMP, IGP WGs,
ITU-T and OSPF. Also reviewed closely by ITU-T SG15 (with liaisons exchanged).




Envelope-to: [e-mail]
Delivery-date: Mon, 15 May 2006 15:43:45 +0000
Message-ID: <017a01c67836$3dea9a30$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: [OSPF] draft-ietf-ccamp-automesh-01.txt
Date: Mon, 15 May 2006 11:42:58 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Kireeti,

Good to hear from you.

Please, see in-line.

Igor

----- Original Message ----- 
From: "Kireeti Kompella" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Monday, May 15, 2006 10:12 AM
Subject: Re: [OSPF] draft-ietf-ccamp-automesh-01.txt


> Hi Adrian,
>
> On Sat, 13 May 2006, Adrian Farrel wrote:
>
> > There is a draft in CCAMP that I want to bounce off the OSPF working
group.
> ...
> > My questions to you:
> > 1. Is it a concern that P-routers are being used to store and forward
> >  opaque information only needed by a small subset of the routers
> >  in the network?
>
> Necessary evil (i.e., No; see below)
>
> (I would reconsider the use of the word "small" -- in most networks I
> have seen, the number of PE routers vastly outnumber the number of P
> routers.)

IB>> I think it is even more true in the context of L1 networks which in
most of the cases are bunch of interconnected rings of PEs with zero or very
few Ps.

>
> > 2. Is there a scaling concern that there is no control on the number of
> >  mesh groups that may exist, nor the number of mesh groups to
> >  which any router can belong?
>
> I guess an implementation could go berserk and advertise 65536 bytes
> worth of mesh groups, but no, this doesn't concern me too much.
>
> > Context:
> > This question arises in the context of
> > draft-bryskin-l1vpn-ospf-auto-discovery-01.txt that is being discussed
in the
> > L1VPN working group. This I-D proposes to use the IGPs (specifically
OSPF) to
> > distribute information about which VPNs can be accessed through the PEs
(not
> > general VPN membership or reachability information, but just a list of
VPN
> > IDs and the link I-Ds that are used to reach them). Loud voices have
been
> > raised in L1VPN about the scalability and appropriateness of such an
idea,
> > and since it seems to be very similar to automesh, I want to see whether
you
> > all think there is a problem with automesh.
>
> I have the same issues with using ISIS/OSPF for auto-mesh as I do for
> autodiscovery in L1VPNs -- OSPF and ISIS are not ideal vehicles for
> such information.  However, there are two very important differences
> in these two cases:
>
> 1) BGP is often not present on "interior" routers (consider the case
>     of "P" routers fully meshed with TE LSPs, and PEs running LDP; and
>     BGP running only on PEs -- "BGP-free core")
>
> 2) It is vital for VPNs that a good policy mechanism be available to
>     control the distribution of information -- otherwise, there could
>     be serious breaches of privacy.

IB>> Note, that what we are suggesting to advertise in L1VPN opaque LSAs are
locally configured CE-PE links and their association with VPNs. I am sure
that I am missing something, so could you help me understand:
a) what scenarios of "serious breaches of privacy" you have in mind?
b) how the BGP approach can help in this regard?

Thanks,
Igor

>
> That said, I would like to see automesh information carried in BGP,
> to be used in preference to ISIS/OSPF whenever possible.
>
> Kireeti.
> -------
>




Envelope-to: [e-mail]
Delivery-date: Mon, 15 May 2006 14:12:46 +0000
Date: Mon, 15 May 2006 07:12:14 -0700 (PDT)
From: Kireeti Kompella <[e-mail]>
To: Adrian Farrel <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: [OSPF] draft-ietf-ccamp-automesh-01.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Hi Adrian,

On Sat, 13 May 2006, Adrian Farrel wrote:

> There is a draft in CCAMP that I want to bounce off the OSPF working group.
...
> My questions to you:
> 1. Is it a concern that P-routers are being used to store and forward
>  opaque information only needed by a small subset of the routers
>  in the network?

Necessary evil (i.e., No; see below)

(I would reconsider the use of the word "small" -- in most networks I 
have seen, the number of PE routers vastly outnumber the number of P 
routers.)

> 2. Is there a scaling concern that there is no control on the number of
>  mesh groups that may exist, nor the number of mesh groups to
>  which any router can belong?

I guess an implementation could go berserk and advertise 65536 bytes 
worth of mesh groups, but no, this doesn't concern me too much.

> Context:
> This question arises in the context of 
> draft-bryskin-l1vpn-ospf-auto-discovery-01.txt that is being discussed in the 
> L1VPN working group. This I-D proposes to use the IGPs (specifically OSPF) to 
> distribute information about which VPNs can be accessed through the PEs (not 
> general VPN membership or reachability information, but just a list of VPN 
> IDs and the link I-Ds that are used to reach them). Loud voices have been 
> raised in L1VPN about the scalability and appropriateness of such an idea, 
> and since it seems to be very similar to automesh, I want to see whether you 
> all think there is a problem with automesh.

I have the same issues with using ISIS/OSPF for auto-mesh as I do for 
autodiscovery in L1VPNs -- OSPF and ISIS are not ideal vehicles for 
such information.  However, there are two very important differences 
in these two cases:

1) BGP is often not present on "interior" routers (consider the case
    of "P" routers fully meshed with TE LSPs, and PEs running LDP; and
    BGP running only on PEs -- "BGP-free core")

2) It is vital for VPNs that a good policy mechanism be available to
    control the distribution of information -- otherwise, there could
    be serious breaches of privacy.

That said, I would like to see automesh information carried in BGP, 
to be used in preference to ISIS/OSPF whenever possible.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Mon, 15 May 2006 13:36:45 +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: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt
Date: Mon, 15 May 2006 14:36:21 +0100
Message-ID: <[e-mail]>
Thread-Topic: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt
Thread-Index: AcZ2e1powyNpiR5aTI23+4rohWlX8wBpnppw
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

[e-mail] <> wrote:
> Working Group,
>=20
> this initiates a two week working group last call on
> draft-ietf-mpls-rsvp-te-p2mp-05.txt
>=20
> please send comments to the MPLS working group mailling list and/or
> working co-chairs.=20

Section 4.3, paragraph 1 states "The two most notable differences are
that a P2MP LSP comprises multiple S2L Sub-LSPs and that, as a result of
this, it may not be possible to represent full state in a single IP
packet and even more likely that it can't fit into a single IP packet."

Which appears to repeat itself.

Section 5.2.4, paragraph 2 states "The ingress LSP may request 'LSP
integrity' by setting bit (TBA) of the Attributes Flags TLV. The bit is
set if LSP integrity is required."

Should the bit that needs setting be defined here (rather than TBA) or
is that down to IANA?

Section 18, paragraph 1 "This section is currently under discussion
between the authors and will be updated in the next revision."

Is this paragraph appropriate?

Ben



Envelope-to: [e-mail]
Delivery-date: Sun, 14 May 2006 19:58:55 +0000
Message-ID: <024001c67790$73986140$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: New Liaison Statement from ITU-T SG15, "ASON control plane session security" 
Date: Sun, 14 May 2006 20:49:24 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We received a copy of a liaison statement from Study Group 15 of the ITU-T 
to the Security Area Directors with regard the security aspects of the ASON 
control plane.

CAMP is not requested to perform any action, although I am sure that the 
Security ADs would welcome any input that you have on the subject.

You can see the liaison in the IETF repository at 
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=220

All incoming CCAMP liaisons are tracked at http://www.olddog.co.uk/ccamp.htm

Cheers,
Adrian

----- Original Message ----- 
From: "Greg Jones (ITU-T SG 15)" <[e-mail]>
To: "Russ Housley" <[e-mail]>; "Sam Hartman" 
<[e-mail]>; "Adrian Farrel" <[e-mail]>; "Deborah 
Brungard" <[e-mail]>; <[e-mail]>
Cc: "Scott Bradner" <[e-mail]>; "Yoichi Maeda" 
<[e-mail]>; "Ross Callon" <[e-mail]>; "Bill Fenner" 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Friday, May 05, 2006 3:14 PM
Subject: New Liaison Statement, "ASON control plane session security"


>
> Title: ASON control plane session security
> Submission Date: 2006-05-05
> URL of the IETF Web page: 
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=220
> Please reply by 2006-06-26
>
> From: Greg Jones(ITU-T SG 15) <[e-mail]>
> To: IETF Security Area Directors, CC: IETF CCAMP WG(Russ Housley 
> <[e-mail]>, Sam Hartman <[e-mail]>, Adrian Farrel 
> <[e-mail]>, Deborah Brungard <[e-mail]>, 
> [e-mail])
> Cc: Scott Bradner <[e-mail]>
> Yoichi Maeda <[e-mail]>
> Ross Callon <[e-mail]>
> Bill Fenner <[e-mail]>
> [e-mail]
> [e-mail]
> Reponse Contact: [e-mail]
> [e-mail]
> Technical Contact: [e-mail]
> Purpose: For action
> Body:
> In the context of the ASON Control Plane work, Q14 is starting work
> on the operations and procedures required during Control plane
> initialisation, reconfiguration and recovery (G.7716).
>
> These procedures require that authentication and general security
> issues are properly addressed, and we therefore ask your advice
> with respect to state of the art techniques that are available to
> us to progress our work.
>
> The action deadline that we are requesting will make your response
> available in time for our next interim meeting in June. If you are
> unable to respond in time for that meeting, we still look forward
> to a response some time in the future. Our next meeting after June
> will start on October 30th, 2006.
>
> An electronic copy of this liaison statement is available at:
> ftp://ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html
> Attachment(s):
> ASON control plane session security - this liaison in original
> WinWord format
> (https://datatracker.ietf.org/documents/LIAISON/file313.doc)





Envelope-to: [e-mail]
Delivery-date: Sat, 13 May 2006 18:48:40 +0000
Message-ID: <00e401c676bc$fa61f210$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "'Jean Philippe Vasseur'" <[e-mail]>, <[e-mail]>, "Hamid Ould-Brahim" <[e-mail]>
Subject: draft-ietf-ccamp-automesh-01.txt
Date: Sat, 13 May 2006 15:25:48 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

There is a draft in CCAMP that I want to bounce off the OSPF working group.

draft-ietf-ccamp-automesh-01.txt uses the new opaque LSA defined in 
draft-ietf-ospf-cap-08.txt in order to carry information about "mesh 
groups". Members of mesh groups would be connected together by tunnels to 
provide a sub-mesh across the network.

There are many applicabilities of this feature, but it is wanted in CCAMP to 
allow the construction of a mesh of MPLS-TE tunnels between a set of MPLS 
label switching routers (LSRs) within the network. This set might be a 
sub-set of the PEs, or might be a sub-set of the P-routers used to build a 
hierarchical network.

The management of the mesh membership information is not the responsibility 
of the IGP. Rather, this is opaque information that is delivered to an 
application. Thus, SPF is acting as a transport for routing-related 
information.

Any router may be a member of more than one mesh group, and many routers 
might not be in any mesh group (consider the PE mesh case where all 
P-routers are not in the group).

My questions to you:
1. Is it a concern that P-routers are being used to store and forward
   opaque information only needed by a small subset of the routers
   in the network?
2. Is there a scaling concern that there is no control on the number of
   mesh groups that may exist, nor the number of mesh groups to
   which any router can belong?

Context:
This question arises in the context of 
draft-bryskin-l1vpn-ospf-auto-discovery-01.txt that is being discussed in 
the L1VPN working group. This I-D proposes to use the IGPs (specifically 
OSPF) to distribute information about which VPNs can be accessed through the 
PEs (not general VPN membership or reachability information, but just a list 
of VPN IDs and the link I-Ds that are used to reach them). Loud voices have 
been raised in L1VPN about the scalability and appropriateness of such an 
idea, and since it seems to be very similar to automesh, I want to see 
whether you all think there is a problem with automesh.

many thanks,
Adrian







Envelope-to: [e-mail]
Delivery-date: Sat, 13 May 2006 10:52:28 +0000
Message-ID: <[e-mail]>
Date: Sat, 13 May 2006 12:48:18 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: [e-mail]
CC: ccamp <[e-mail]>, George Swallow <[e-mail]>, Adrian Farrel <[e-mail]>, Deborah Brungard <[e-mail]>, Ross Callon <[e-mail]>, Bill Fenner <[e-mail]>
Subject: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Working Group,

this initiates a two week working group last call on
draft-ietf-mpls-rsvp-te-p2mp-05.txt

please send comments to the MPLS working group mailling
list and/or working co-chairs.

The last call ends eob May 28th.

The ccamp mailing list copied as this is a work that has
an overlap between the working groups.

Loa and George



-- 
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, 12 May 2006 14:15:36 +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: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt
Date: Fri, 12 May 2006 16:14:17 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt
Thread-Index: AcZ1o+LWLEe9u8LSS7KVnhmt1hD3TQAKSlWw
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>
Cc: "<ccamp" <[e-mail]>

Hi Diego.

It looks like you're requiring some requirements! As a matter of fact,
I'm thinking about it, but it should not overlap with what's addressed
in the addressing draft...

Regards,

Julien


-----Original Message-----
From: Diego Caviglia [mailto:[e-mail]]=20

Hi Julien,
           as a Carrier representative do you think that from your
prespective some ERO implementations are better than other?

E.g. from a carrier prespective having the possibility to use explicit
ERO
with component link and label specification is nice_to_have, mandatory
or
useless?

The above is just an example I'm not pushing a solution that include
component link and label.

Regards

Diego



"MEURIC Julien RD-CORE-LAN"
<[e-mail]>@ops.ietf.org
on 12/05/2006 10.49.21

Sent by:    [e-mail]


To:    <[e-mail]>
cc:    <[e-mail]>

Subject:    RE: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt

Hi Adrian.

Let me quote:

"  individual who, although (or perhaps because) he is a working group
   chair, cannot necessarily be trusted. Thus, the IETF process is
   open to an attack by this individual."

I'm inclined to ask the following question: should the IETF stop
allowing
such attack, or should we modify the chair implementation so as to
inhibit
such behaviour? ;-)

For the chair's sake, I'd rather change the receiving side to handle as
many behaviours as possible, but I feel reducing sender's options will
ease
interoperability. As a result, I agree with your proposed actions,
especially about making implementations converge on really required
options.

Cheers,

Julien


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf
Of Adrian Farrel

Hi,

Here are the results of the anonymous survey of ERO usage that was
triggered
by the Dallas discussion of the GMPLS Addressing I-D.

I have drawn some preliminary conclusions and included my advice in
section

5.

Please have a look at the whole and make your comments to the list.

Thanks,
Adrian

PS If there is a bunch of other folk who suddenly feel the need to
respond,

I can always produce a revised I-D.


----- Original Message -----
From: <[e-mail]>

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
> Title : Informal Survey into Explicit Route Object Implementations in
> Generalized Multiprotocol Labels Switching Signaling Implementations
> Author(s) : A. Farrel
> Filename : draft-farrel-ccamp-ero-survey-00.txt
> Pages : 12
> Date : 2006-5-11
>
>   During discussions of a document to provide guidance on the use of
>   addressing fields within the Resource Reservation Protocol Traffic
>   Engineering (RSVP-TE) signaling protocol used in Generalized
>   Multiprotocol Label Switching (GMPLS), it was determined that there
>   was considerable variation in the implementation of options for the
>   Explicit Route Object (ERO).
>
>   Since there was a proposal to deprecate some of the options, it was
>   felt necessary to conduct a survey of the existing and planned
>   implementations.
>
>   This document summarizes the survey questions and captures the
>   results. Some conclusions are also presented.
>
>   This survey was informal and conducted via email. Responses were
>   collected and anonymized by the CCAMP working group chair.
>
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ero-survey-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] with the word unsubscribe in the body of
the
> message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-farrel-ccamp-ero-survey-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-farrel-ccamp-ero-survey-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>


------------------------------------------------------------------------
--------



> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>












Envelope-to: [e-mail]
Delivery-date: Fri, 12 May 2006 09:10:38 +0000
Sensitivity: 
Subject: RE: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt
To: [e-mail]
Cc: "<adrian" <[e-mail]>, "<ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Fri, 12 May 2006 11:10:06 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Julien,
           as a Carrier representative do you think that from your
prespective some ERO implementations are better than other?

E.g. from a carrier prespective having the possibility to use explicit ERO
with component link and label specification is nice_to_have, mandatory or
useless?

The above is just an example I'm not pushing a solution that include
component link and label.

Regards

Diego



"MEURIC Julien RD-CORE-LAN" <[e-mail]>@ops.ietf.org
on 12/05/2006 10.49.21

Sent by:    [e-mail]


To:    <[e-mail]>
cc:    <[e-mail]>

Subject:    RE: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt

Hi Adrian.

Let me quote:

"  individual who, although (or perhaps because) he is a working group
   chair, cannot necessarily be trusted. Thus, the IETF process is
   open to an attack by this individual."

I'm inclined to ask the following question: should the IETF stop allowing
such attack, or should we modify the chair implementation so as to inhibit
such behaviour? ;-)

For the chair's sake, I'd rather change the receiving side to handle as
many behaviours as possible, but I feel reducing sender's options will ease
interoperability. As a result, I agree with your proposed actions,
especially about making implementations converge on really required
options.

Cheers,

Julien


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Adrian Farrel

Hi,

Here are the results of the anonymous survey of ERO usage that was
triggered
by the Dallas discussion of the GMPLS Addressing I-D.

I have drawn some preliminary conclusions and included my advice in section

5.

Please have a look at the whole and make your comments to the list.

Thanks,
Adrian

PS If there is a bunch of other folk who suddenly feel the need to respond,

I can always produce a revised I-D.


----- Original Message -----
From: <[e-mail]>

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
> Title : Informal Survey into Explicit Route Object Implementations in
> Generalized Multiprotocol Labels Switching Signaling Implementations
> Author(s) : A. Farrel
> Filename : draft-farrel-ccamp-ero-survey-00.txt
> Pages : 12
> Date : 2006-5-11
>
>   During discussions of a document to provide guidance on the use of
>   addressing fields within the Resource Reservation Protocol Traffic
>   Engineering (RSVP-TE) signaling protocol used in Generalized
>   Multiprotocol Label Switching (GMPLS), it was determined that there
>   was considerable variation in the implementation of options for the
>   Explicit Route Object (ERO).
>
>   Since there was a proposal to deprecate some of the options, it was
>   felt necessary to conduct a survey of the existing and planned
>   implementations.
>
>   This document summarizes the survey questions and captures the
>   results. Some conclusions are also presented.
>
>   This survey was informal and conducted via email. Responses were
>   collected and anonymized by the CCAMP working group chair.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ero-survey-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] with the word unsubscribe in the body of
the
> message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-farrel-ccamp-ero-survey-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-farrel-ccamp-ero-survey-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>


--------------------------------------------------------------------------------



> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>












Envelope-to: [e-mail]
Delivery-date: Fri, 12 May 2006 08:50:58 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt 
Date: Fri, 12 May 2006 10:49:21 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt 
Thread-Index: AcZ1U2/5vFedGxF5Sce2tnSfgFuj7QASNY+Q
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

Hi Adrian.

Let me quote:

"  individual who, although (or perhaps because) he is a working group
   chair, cannot necessarily be trusted. Thus, the IETF process is
   open to an attack by this individual."

I'm inclined to ask the following question: should the IETF stop =
allowing such attack, or should we modify the chair implementation so as =
to inhibit such behaviour? ;-)

For the chair's sake, I'd rather change the receiving side to handle as =
many behaviours as possible, but I feel reducing sender's options will =
ease interoperability. As a result, I agree with your proposed actions, =
especially about making implementations converge on really required =
options.

Cheers,

Julien


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On =
Behalf Of Adrian Farrel

Hi,

Here are the results of the anonymous survey of ERO usage that was =
triggered=20
by the Dallas discussion of the GMPLS Addressing I-D.

I have drawn some preliminary conclusions and included my advice in =
section=20
5.

Please have a look at the whole and make your comments to the list.

Thanks,
Adrian

PS If there is a bunch of other folk who suddenly feel the need to =
respond,=20
I can always produce a revised I-D.


----- Original Message -----=20
From: <[e-mail]>

>A New Internet-Draft is available from the on-line Internet-Drafts=20
>directories.
>
>
> Title : Informal Survey into Explicit Route Object Implementations in=20
> Generalized Multiprotocol Labels Switching Signaling Implementations
> Author(s) : A. Farrel
> Filename : draft-farrel-ccamp-ero-survey-00.txt
> Pages : 12
> Date : 2006-5-11
>
>   During discussions of a document to provide guidance on the use of
>   addressing fields within the Resource Reservation Protocol Traffic
>   Engineering (RSVP-TE) signaling protocol used in Generalized
>   Multiprotocol Label Switching (GMPLS), it was determined that there
>   was considerable variation in the implementation of options for the
>   Explicit Route Object (ERO).
>
>   Since there was a proposal to deprecate some of the options, it was
>   felt necessary to conduct a survey of the existing and planned
>   implementations.
>
>   This document summarizes the survey questions and captures the
>   results. Some conclusions are also presented.
>
>   This survey was informal and conducted via email. Responses were
>   collected and anonymized by the CCAMP working group chair.
>
>
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ero-survey-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] with the word unsubscribe in the body of =
the=20
> message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the=20
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-farrel-ccamp-ero-survey-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-farrel-ccamp-ero-survey-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>


-------------------------------------------------------------------------=
-------


> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>=20






Envelope-to: [e-mail]
Delivery-date: Thu, 11 May 2006 23:23:42 +0000
Message-ID: <022901c67551$a48f8df0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt 
Date: Fri, 12 May 2006 00:20:29 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Here are the results of the anonymous survey of ERO usage that was triggered 
by the Dallas discussion of the GMPLS Addressing I-D.

I have drawn some preliminary conclusions and included my advice in section 
5.

Please have a look at the whole and make your comments to the list.

Thanks,
Adrian

PS If there is a bunch of other folk who suddenly feel the need to respond, 
I can always produce a revised I-D.


----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Thursday, May 11, 2006 8:50 PM
Subject: I-D ACTION:draft-farrel-ccamp-ero-survey-00.txt


>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
> Title : Informal Survey into Explicit Route Object Implementations in 
> Generalized Multiprotocol Labels Switching Signaling Implementations
> Author(s) : A. Farrel
> Filename : draft-farrel-ccamp-ero-survey-00.txt
> Pages : 12
> Date : 2006-5-11
>
>   During discussions of a document to provide guidance on the use of
>   addressing fields within the Resource Reservation Protocol Traffic
>   Engineering (RSVP-TE) signaling protocol used in Generalized
>   Multiprotocol Label Switching (GMPLS), it was determined that there
>   was considerable variation in the implementation of options for the
>   Explicit Route Object (ERO).
>
>   Since there was a proposal to deprecate some of the options, it was
>   felt necessary to conduct a survey of the existing and planned
>   implementations.
>
>   This document summarizes the survey questions and captures the
>   results. Some conclusions are also presented.
>
>   This survey was informal and conducted via email. Responses were
>   collected and anonymized by the CCAMP working group chair.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-ccamp-ero-survey-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] with the word unsubscribe in the body of the 
> message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-farrel-ccamp-ero-survey-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-farrel-ccamp-ero-survey-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>


--------------------------------------------------------------------------------


> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 





Envelope-to: [e-mail]
Delivery-date: Thu, 11 May 2006 20:35:42 +0000
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Tom Petch <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Content-Transfer-Encoding: 7bit
From: "Thomas D. Nadeau" <[e-mail]>
Subject: Re: Freeform labels
Date: Thu, 11 May 2006 16:34:44 -0400
To: [e-mail]

On May 11, 2006, at 10:29 AM, [e-mail] wrote:

>
>
> -----Original Message-----
>> From: Tom Petch <[e-mail]>
>> Sent: May 9, 2006 3:43 AM
>> To: Adrian Farrel <[e-mail]>, [e-mail],  
>> [e-mail]
>> Cc: joan cucchiara <[e-mail]>
>> Subject: Freeform labels
>
> Hi Tom,
>
>>
>> I am confused about freeform labels.  I am not familiar with them  
>> from other
>> contexts and so am not clear how significant they are but ...
>>
>> (draft-ietf-ccamp-gmpls-)tc-mib under GmplsFreeformLabelTC  
>> references RFC3471
>> which would be a good place to read about them except I can see no  
>> mention of
>> them there.  They appear in tc-mib, lsr-mib and te-mib - they are  
>> used as worked
>> examples which is what attracted my attention - but I cannot find  
>> them anywhere
>> else in the (G)MPLS library.  I think that more description is  
>> needed somewhere.
>
> The  GmplsFreeformLabelTC is also used in the GMPLS-LABEL-STD-MIB  
> (gmplsLabelFreeform in the
> gmplsLabelTable).  I believe given the purpose of this particular
> MIB table and also within the context of the other objects in this
> table, that the intent of GmplsFreeformLabelTC is fairly well  
> described.
>
>>
>> Why does GmplsFreeformLabelTC give size limits of 0 and 64?  Can  
>> they really be
>> 0-length?  I have no problem with an SMI object having zero length  
>> as long as
>> the entity being modeled by it can have zero length but is that  
>> meaningful here?
>> And why 64? ok, a lot more than 32-bit but 64 sounds arbitrary (in  
>> which case, I
>> think that worth saying); or does 64 octet relate to some other  
>> well known
>> address formats (IPv6 anyone?).
>>
>
> The length of 64 was thought by the authors to be more than enough  
> for the purpose
> of this label.   I also questioned this during the MIB Dr. review,  
> but currently label
> lengths in the MPLS/GMPLS wgs are 4 octets, so 64 seems reasonable.
>
> 0 length is used if this object does not contain a label, so it is  
> not the actual label
> that is 0 length, but when the object has not label.
>
>
>> When GmplsFreeformLabelTC says 'not defined in any RFC',  I think  
>> it sums it up
>> too well:-(
>>
>
> Yes, this is a MIB convention only.
>
>> So the use of gmplsFreeformLabel(3) everywhere except in the  
>> formal definition
>> where it appears (I assume) as gmplsFreeformGeneralizedLabel(3)  
>> seems about
>> right as does the descripttion
>>
>
> Good catch.  I probably should have caught this during the MIB Dr.  
> reviews.
> Tom N. could you change this during the IESG/RFC reviews.

	Will do.

>
>
> -Joan
>
>
>> "The label is any form of label
>> encoded as an OCTET STRING using
>> the Textual Convention GmplsFreeformLabel"
>>
>> Well no, the Textual Convention is GmplsFreeformLabelTC and I  
>> would rather say
>> that the label is encoded using the Textual Convention  
>> GmplsFreeformLabelTC
>> (even though that is a redefinition of an OCTET STRING).
>>
>> I think more should be said somewhere, ideally in RFC3471, but, more
>> realistically, in tc-mib.
>>
>> Tom Petch
>>
>>
>>
>



Envelope-to: [e-mail]
Delivery-date: Thu, 11 May 2006 15:54:16 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AY8GVa7jfolOi/T5tURKHI0NBc8HuXhqwk/D5/XeXpIaQ+5LckgP+mvQDtglSjU7; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Message-ID: <[e-mail]>
Date: Thu, 11 May 2006 10:29:38 -0400 (GMT-04:00)
From: [e-mail]
Reply-To: [e-mail]
To: Tom Petch <[e-mail]>, Adrian Farrel <[e-mail]>,  [e-mail], [e-mail]
Subject: Re: Freeform labels
Cc: joan cucchiara <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-----Original Message-----
>From: Tom Petch <[e-mail]>
>Sent: May 9, 2006 3:43 AM
>To: Adrian Farrel <[e-mail]>, [e-mail], [e-mail]
>Cc: joan cucchiara <[e-mail]>
>Subject: Freeform labels

Hi Tom,

>
>I am confused about freeform labels.  I am not familiar with them from other
>contexts and so am not clear how significant they are but ...
>
>(draft-ietf-ccamp-gmpls-)tc-mib under GmplsFreeformLabelTC references RFC3471
>which would be a good place to read about them except I can see no mention of
>them there.  They appear in tc-mib, lsr-mib and te-mib - they are used as worked
>examples which is what attracted my attention - but I cannot find them anywhere
>else in the (G)MPLS library.  I think that more description is needed somewhere.

The  GmplsFreeformLabelTC is also used in the GMPLS-LABEL-STD-MIB (gmplsLabelFreeform in the
gmplsLabelTable).  I believe given the purpose of this particular
MIB table and also within the context of the other objects in this
table, that the intent of GmplsFreeformLabelTC is fairly well described.

>
>Why does GmplsFreeformLabelTC give size limits of 0 and 64?  Can they really be
>0-length?  I have no problem with an SMI object having zero length as long as
>the entity being modeled by it can have zero length but is that meaningful here?
>And why 64? ok, a lot more than 32-bit but 64 sounds arbitrary (in which case, I
>think that worth saying); or does 64 octet relate to some other well known
>address formats (IPv6 anyone?).
>

The length of 64 was thought by the authors to be more than enough for the purpose
of this label.   I also questioned this during the MIB Dr. review, but currently label
lengths in the MPLS/GMPLS wgs are 4 octets, so 64 seems reasonable. 

0 length is used if this object does not contain a label, so it is not the actual label
that is 0 length, but when the object has not label.


>When GmplsFreeformLabelTC says 'not defined in any RFC',  I think it sums it up
>too well:-(
>

Yes, this is a MIB convention only.

>So the use of gmplsFreeformLabel(3) everywhere except in the formal definition
>where it appears (I assume) as gmplsFreeformGeneralizedLabel(3) seems about
>right as does the descripttion
>

Good catch.  I probably should have caught this during the MIB Dr. reviews.
Tom N. could you change this during the IESG/RFC reviews.


-Joan


>"The label is any form of label
>encoded as an OCTET STRING using
>the Textual Convention GmplsFreeformLabel"
>
>Well no, the Textual Convention is GmplsFreeformLabelTC and I would rather say
>that the label is encoded using the Textual Convention GmplsFreeformLabelTC
>(even though that is a redefinition of an OCTET STRING).
>
>I think more should be said somewhere, ideally in RFC3471, but, more
>realistically, in tc-mib.
>
>Tom Petch
>
>
>






Envelope-to: [e-mail]
Delivery-date: Wed, 10 May 2006 20:55:25 +0000
To: [e-mail]
Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 10 May 2006 22:53:20 +0200
Content-Type: text/plain; charset="US-ASCII"

folks

this revision includes

- editorial review

- complete security section

much thanks to the reviewers (in part. deborah, ross, GEN-ART reviewers)

- d.
----- Forwarded by Dimitri PAPADIMITRIOU/BE/ALCATEL on 10/05/2006 22:50 
-----


[e-mail]
09/05/2006 21:50
Please respond to internet-drafts
 
        To:     [e-mail]
        cc:     [e-mail]
        Subject:        I-D 
ACTION:draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane 
Working Group of the IETF.

                 Title                           : Evaluation of existing 
Routing Protocols against ASON routing requirements
                 Author(s)               : D. Papadimitriou, et al.
                 Filename                : 
draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt
                 Pages                           : 0
                 Date                            : 2006-5-9
 
The Generalized MPLS (GMPLS) suite of protocols has been defined to 
   control different switching technologies as well as different 
   applications. These include support for requesting TDM connections 
   including SONET/SDH and Optical Transport Networks (OTNs). 
 
   This document provides an evaluation of the IETF Routing Protocols 
   against the routing requirements for an Automatically Switched 
   Optical Network (ASON) as defined by ITU-T.

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


To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the 
message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the 
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
                 "get draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
                 [e-mail].
In the body type:
                 "FILE 
/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt".
 
NOTE:            The mail server at ietf.org can return the document in
                 MIME-encoded form by using the "mpack" utility.  To use 
this
                 feature, insert the command "ENCODING mime" before the 
"FILE"
                 command.  To decode the response(s), you will need 
"munpack" or
                 a MIME-compliant mail reader.  Different MIME-compliant 
mail readers
                 exhibit different behavior, especially when dealing with
                 "multipart" MIME messages (i.e. documents which have been 
split
                 up into multiple messages), so check your local 
documentation on
                 how to manipulate these messages.
 
 
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[e-mail]/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt
_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce




Envelope-to: [e-mail]
Delivery-date: Tue, 09 May 2006 19:51:35 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt 
Message-Id: <[e-mail]>
Date: Tue, 09 May 2006 15:50:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Evaluation of existing Routing Protocols against ASON routing requirements
	Author(s)	: D. Papadimitriou, et al.
	Filename	: draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt
	Pages		: 0
	Date		: 2006-5-9
	
The Generalized MPLS (GMPLS) suite of protocols has been defined to 
   control different switching technologies as well as different 
   applications. These include support for requesting TDM connections 
   including SONET/SDH and Optical Transport Networks (OTNs). 
    
   This document provides an evaluation of the IETF Routing Protocols 
   against the routing requirements for an Automatically Switched 
   Optical Network (ASON) as defined by ITU-T.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Tue, 09 May 2006 13:08:16 +0000
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail], Cucchiara Joan <[e-mail]>, Bill Fenner <[e-mail]>
Content-Transfer-Encoding: 7bit
From: "Thomas D. Nadeau" <[e-mail]>
Subject: Re: Freeform labels
Date: Tue, 9 May 2006 09:06:47 -0400
To: Tom Petch <[e-mail]>

	Tom,

	If you have specific suggestions for
changes, please propose them.

	--Tom


> I am confused about freeform labels.  I am not familiar with them  
> from other
> contexts and so am not clear how significant they are but ...
>
> (draft-ietf-ccamp-gmpls-)tc-mib under GmplsFreeformLabelTC  
> references RFC3471
> which would be a good place to read about them except I can see no  
> mention of
> them there.  They appear in tc-mib, lsr-mib and te-mib - they are  
> used as worked
> examples which is what attracted my attention - but I cannot find  
> them anywhere
> else in the (G)MPLS library.  I think that more description is  
> needed somewhere.
>
> Why does GmplsFreeformLabelTC give size limits of 0 and 64?  Can  
> they really be
> 0-length?  I have no problem with an SMI object having zero length  
> as long as
> the entity being modeled by it can have zero length but is that  
> meaningful here?
> And why 64? ok, a lot more than 32-bit but 64 sounds arbitrary (in  
> which case, I
> think that worth saying); or does 64 octet relate to some other  
> well known
> address formats (IPv6 anyone?).
>
> When GmplsFreeformLabelTC says 'not defined in any RFC',  I think  
> it sums it up
> too well:-(
>
> So the use of gmplsFreeformLabel(3) everywhere except in the formal  
> definition
> where it appears (I assume) as gmplsFreeformGeneralizedLabel(3)  
> seems about
> right as does the descripttion
>
> "The label is any form of label
> encoded as an OCTET STRING using
> the Textual Convention GmplsFreeformLabel"
>
> Well no, the Textual Convention is GmplsFreeformLabelTC and I would  
> rather say
> that the label is encoded using the Textual Convention  
> GmplsFreeformLabelTC
> (even though that is a redefinition of an OCTET STRING).
>
> I think more should be said somewhere, ideally in RFC3471, but, more
> realistically, in tc-mib.
>
> Tom Petch



Envelope-to: [e-mail]
Delivery-date: Tue, 09 May 2006 08:49:34 +0000
Message-ID: <000d01c6733c$781657c0$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "joan cucchiara" <[e-mail]>
Subject: Freeform labels
Date: Tue, 9 May 2006 09:43:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I am confused about freeform labels.  I am not familiar with them from other
contexts and so am not clear how significant they are but ...

(draft-ietf-ccamp-gmpls-)tc-mib under GmplsFreeformLabelTC references RFC3471
which would be a good place to read about them except I can see no mention of
them there.  They appear in tc-mib, lsr-mib and te-mib - they are used as worked
examples which is what attracted my attention - but I cannot find them anywhere
else in the (G)MPLS library.  I think that more description is needed somewhere.

Why does GmplsFreeformLabelTC give size limits of 0 and 64?  Can they really be
0-length?  I have no problem with an SMI object having zero length as long as
the entity being modeled by it can have zero length but is that meaningful here?
And why 64? ok, a lot more than 32-bit but 64 sounds arbitrary (in which case, I
think that worth saying); or does 64 octet relate to some other well known
address formats (IPv6 anyone?).

When GmplsFreeformLabelTC says 'not defined in any RFC',  I think it sums it up
too well:-(

So the use of gmplsFreeformLabel(3) everywhere except in the formal definition
where it appears (I assume) as gmplsFreeformGeneralizedLabel(3) seems about
right as does the descripttion

"The label is any form of label
encoded as an OCTET STRING using
the Textual Convention GmplsFreeformLabel"

Well no, the Textual Convention is GmplsFreeformLabelTC and I would rather say
that the label is encoded using the Textual Convention GmplsFreeformLabelTC
(even though that is a redefinition of an OCTET STRING).

I think more should be said somewhere, ideally in RFC3471, but, more
realistically, in tc-mib.

Tom Petch





Envelope-to: [e-mail]
Delivery-date: Mon, 08 May 2006 23:22:00 +0000
Message-ID: <003601c672f5$f7fe7400$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Loa Andersson" <[e-mail]>, "George Swallow" <[e-mail]>, <[e-mail]>
Subject: draft-farrel-mpls-iana-rsvp-session-flags-00.txt 
Date: Tue, 9 May 2006 00:18:23 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

During IESG review of draft-ietf-mpls-rsvpte-attributes we removed the 
"suggestion" that IANA should track the flags bits in the Session-Attributes 
object, because there was no explicit requirement in that draft to create a 
new registry for those bits.

During IESG review of draft-ietf-ccamp-loose-path-reopt we noticed that yet 
another bit from that flags field is being assigned, and that draft asked 
IANA to assign the bit from the registry (that has not been created).

So...

I have written draft-farrel-mpls-iana-rsvp-session-flags-00.txt to request 
IANA to create a registry. I would welcome review from the MPLS and CCAMP 
working groups.

If the MPLS WG chairs want to adopt this I-D as a working group document and 
move it to immediate WG last call, that would be great. Otherwise I will 
take it to the ADs as a personal draft and ask for it to be made into an 
RFC.

Thanks,
Adrian

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Monday, May 08, 2006 11:50 PM
Subject: I-D ACTION:draft-farrel-mpls-iana-rsvp-session-flags-00.txt


>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
> Title : Codepoint Registry for The Flags Field in the Resource Reservation 
> Protocol Traffic Engineering (RSVP-TE) Session Attribute Object
> Author(s) : A. Farrel
> Filename : draft-farrel-mpls-iana-rsvp-session-flags-00.txt
> Pages : 5
> Date : 2006-5-8
>
> This document provides instructions to IANA for the creation of a new
> codepoint registry for the flags field in the Session Attribute
> object of the Resource Reservation Protocol Traffic Engineeging
> (RSVP-TE) signaling messages used in Multiprotocol Label Switching
> (MPLS) and Generalized MPLS (GMPLS) signaling.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-mpls-iana-rsvp-session-flags-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] with the word unsubscribe in the body of the 
> message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-farrel-mpls-iana-rsvp-session-flags-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-farrel-mpls-iana-rsvp-session-flags-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>


--------------------------------------------------------------------------------


> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 





Envelope-to: [e-mail]
Delivery-date: Mon, 08 May 2006 19:51:01 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-14.txt 
Message-Id: <[e-mail]>
Date: Mon, 08 May 2006 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base
	Author(s)	: T. Nadeau, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-14.txt
	Pages		: 42
	Date		: 2006-5-8
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects to configure and/or
   monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
   Switching Router (LSR).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-14.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-lsr-mib-14.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-14.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-14.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-lsr-mib-14.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Mon, 08 May 2006 19:14:10 +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: How to announce ethernet capabilities in GMPLS
Date: Mon, 8 May 2006 21:13:14 +0200
Message-ID: <[e-mail]>
Thread-Topic: How to announce ethernet capabilities in GMPLS
Thread-Index: AcZyu9sA9ndTJVEnQkaMWOvJdoCuNgAFp6og
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

=20
>=20
> I'm currently mostly interested in the former case.
> Am I correct that this would typically involve two LSPs at the link
> layer (L2 switch to PXC and PXC to anoother L2 switch) and a third LSP
> at the ethernet layer.
>=20
>=20

If I understand your setup correctly (switch <--> pxc <--> switch) this
would be one LSP between the switches and through (switched by) the PXC.
This LSP instantiates a 'link' between two ports on the Ethernet
switches.

/Eduard









Envelope-to: [e-mail]
Delivery-date: Mon, 08 May 2006 16:45:53 +0000
To: Freek Dijkstra <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: How to announce ethernet capabilities in GMPLS
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 8 May 2006 18:45:17 +0200
Content-Type: text/plain; charset="US-ASCII"

hi - 

> Is the G-PID decided during the signaling, or announced by the routing 
> and taken into account during the path computation?

the former.

thanks,
- dimitri.





Freek Dijkstra <[e-mail]>
Sent by: [e-mail]
08/05/2006 18:24
 
        To:     [e-mail]
        cc:     [e-mail]
        Subject:        Re: How to announce ethernet capabilities in GMPLS


Hi Eduard,

Thanks for your response! I vary much appreciate that!

> I think there are two separate issues here:
> - The definition of an LSP in the LSC switching region between 2
> Ethernet switches (through the PXC), and
> - The definition of LSP in the L2SC switching regions through a number
> of Ethernet switches.
> 
[...]
> Which is your concern? (Note, to me, both appear to be areas of
> development)

I'm currently mostly interested in the former case.
Am I correct that this would typically involve two LSPs at the link
layer (L2 switch to PXC and PXC to anoother L2 switch) and a third LSP
at the ethernet layer.


> For the former, the WAN-PHY / LAN-PHY question seems relevant. I'd say
> this is (should be) somehow part of the G-PID for the LSP between the
> switches.
> 
> An overview of GMPLS parameters can be found at:
> http://www.iana.org/numbers.html#G

Thanks! I did not realize that the Internet Draft on G709 did define a
few new G-PID parameters.

However, I fear I'm now slightly confused how the G-PID are announced.
They don't seem to be included in the OSPF routing messages (neither RFC
4203 not 4204 seem to mention them). Is the G-PID decided during the
signaling, or announced by the routing and taken into account during the
 path computation?

Regards,
Freek






Envelope-to: [e-mail]
Delivery-date: Mon, 08 May 2006 16:24:36 +0000
Message-ID: <[e-mail]>
Date: Mon, 08 May 2006 18:24:09 +0200
From: Freek Dijkstra <[e-mail]>
User-Agent: Mail/News 1.5.0.2 (Macintosh/20060401)
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: How to announce ethernet capabilities in GMPLS
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Eduard,

Thanks for your response! I vary much appreciate that!

> I think there are two separate issues here:
> - The definition of an LSP in the LSC switching region between 2
> Ethernet switches (through the PXC), and
> - The definition of LSP in the L2SC switching regions through a number
> of Ethernet switches.
> 
[...]
> Which is your concern? (Note, to me, both appear to be areas of
> development)

I'm currently mostly interested in the former case.
Am I correct that this would typically involve two LSPs at the link
layer (L2 switch to PXC and PXC to anoother L2 switch) and a third LSP
at the ethernet layer.


> For the former, the WAN-PHY / LAN-PHY question seems relevant. I'd say
> this is (should be) somehow part of the G-PID for the LSP between the
> switches.
> 
> An overview of GMPLS parameters can be found at:
> http://www.iana.org/numbers.html#G

Thanks! I did not realize that the Internet Draft on G709 did define a
few new G-PID parameters.

However, I fear I'm now slightly confused how the G-PID are announced.
They don't seem to be included in the OSPF routing messages (neither RFC
4203 not 4204 seem to mention them). Is the G-PID decided during the
signaling, or announced by the routing and taken into account during the
 path computation?

Regards,
Freek



Envelope-to: [e-mail]
Delivery-date: Mon, 08 May 2006 15:46:36 +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: How to announce ethernet capabilities in GMPLS
Date: Mon, 8 May 2006 17:45:30 +0200
Message-ID: <[e-mail]>
Thread-Topic: How to announce ethernet capabilities in GMPLS
Thread-Index: AcZuyOYpxfOgt5U4SsaHGEemr51mMwD6O0kA
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

Hi Freek,=20

I think there are two separate issues here:
- The definition of an LSP in the LSC switching region between 2
Ethernet switches (through the PXC), and
- The definition of LSP in the L2SC switching regions through a number
of Ethernet switches.

For the former, the WAN-PHY / LAN-PHY question seems relevant. I'd say
this is (should be) somehow part of the G-PID for the LSP between the
switches.

For the latter, the VLAN/no-VLAN question seems relevant (this belongs
to the GELS work I think). Although you could argue that also for the
inter-switch LSP this information might be relevant; you may not want to
cross-connect a trunk port with a non-trunk port. If the encoding do not
match, you may not be able to setup 'Ethernet' LSPs.

Which is your concern? (Note, to me, both appear to be areas of
development)

An overview of GMPLS parameters can be found at:
http://www.iana.org/numbers.html#G

cheers,
	Eduard


> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Freek Dijkstra
> Sent: woensdag 3 mei 2006 17:46
> To: [e-mail]
> Subject: How to announce ethernet capabilities in GMPLS
>=20
> Hi,
>=20
> I have a question about GMPLS.
>=20
> My interest is mostly scientific in nature; and after reading a few
> RFC's and internet drafts, I still found no satisfying answer. I may
> have overlooked it.
>=20
> How would you specify the encoding type for a link with IEEE=20
> 802.1q VLAN
> tags versus a link which can not do that?
> And related, how to distinguish between WAN PHY and LAN PHY encoding?
>=20
> Imagine a small network with 3 or 4 layer 2 switches, with all
> interfaces connected to one central photonic cross connect (MEMS
> device). In such a case, it is useful to know the above details.
>=20
>=20
> If I'm correct, a Layer 2 switch announces the capabilities of each
> interface using a link state advertisement (LSA).
>=20
> A LSA seems to contain at least
> - "LSP encoding type" and
> - "switching type".
>=20
> In all cases, the parameters seem to be "Ethernet" and "L2SC"=20
> respectively.
>=20
> At least draft-papadimitriou-enhanced-lsps-04 explictly says that WAN
> PHY and LAN PHY both fall in the Ethernet "LSP Encoding Type".
>=20
> draft-dimitri-gels-framework-00 seems to suggest that perhaps new
> encoding types must be invented. I take it that I misunderstood, and
> this will be defined in the "Switching Capability-Specific=20
> Information"
> part of the LSA.
>=20
> I tried looking, and Adrian's excellent Internet and it's protocols
> lists that the "Switching Capability-Specific Information" for L2SC
> only lists "minimum bandwidth" and "MTU".
>=20
> Am I correct that the GELS working group will look into extensions for
> this purpose? I'm currently not interested (yet) in the specific
> details, but mostly in the general idea here. Is there by any chance a
> list of already defined "Switching Capability-Specific Information"
> parameters for other layers? Perhaps a list of internet drafts to go
> through.
>=20
> I might be wrong here somewhere -- somehow WAN/LAN PHY and IEEE 802.1q
> VLAN or not capable seem other type of parameters to me then "MTU"
> (which is currently defined for L2SC). If so -- what am I missing?
>=20
> Regards,
> Freek
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 08 May 2006 11:38:20 +0000
Message-ID: <002d01c6728a$f0dce6e0$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: draft-ietf-ccamp-gmpls-lsr-mib-13.txt
Date: Mon, 8 May 2006 12:31:35 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

A stray doubt or so on this:-(

1) RFC2434 is referenced in the IANA considerations but not in the list of
references.

2) p.2   ..advandtage ...

3) I am confused by the enumeration gmplsFreeformLabel(3); this also appears in
the DESCRIPTION of GmplsLabelTypeTC in draft-ietf-ccamp-gmpls-tc-mib-10.txt but
I see no such enumeration defined.  Should this be
gmplsFreeformGeneralizedLabel(3)?

4) p.8 ...  accsesible ...
Presumably, this will always be gmplsLabelType(4) for mplsInSegmentLabelPtr and
mplsOutSegmentLabelPtr

5) I think that on p.23,
     ::= { mplsStdMIB XXX }
should be
     ::= { mplsStdMIB ZZZ }
in order to conform to the instructions to the RFC Editor (I know, they are
intelligent enough to get it right but I do like things to be as simple as
possible)

6) Likewise, I think that on p.12,
     ::= { mplsStdMIB XXX }
should be
     ::= { mplsStdMIB YYY }
in order to conform to the instructions to the RFC editor

7) I notice that references to the tc-mib are variously to it as its
to-be-assigned RFC number - eg p.22 - or to it as [GMPLSTCMIB] - eg p.21; not a
problem, I
assume that this is a matter of style.

Tom Petch




Envelope-to: [e-mail]
Delivery-date: Mon, 08 May 2006 02:44:01 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:subject:mime-version:content-type; b=p7LsTGR49ZtLFfttfMG64UTxB7sQlO0lOooXNQN9dQ50S4Dd8N9SFkYtnv8MC/9mBAFseBw8FVMG2lUgQba4WyDhG3pob31+WnoZazcFf5Ui3TVfYf9jFB8xseh9olEllwsCcy5wyX4sYIlcnLxBTDtsfBX0voOPjWrzjp7YClU=
Message-ID: <[e-mail]>
Date: Mon, 8 May 2006 09:38:35 +0700
From: "stephen kwaku" <[e-mail]>
Subject: DEAR FRIEND
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1392_27499254.1147055915677"

------=_Part_1392_27499254.1147055915677
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Mr. Steven Kwaku
Address : United Nation Refugee Camp. Thailand.

Dear Sir,

With due respect trust and humanity. I write you this letter which I believ=
e
wouldbe of great interest to you. I got your contact from a business
directory here in Thailand chamber of commerce and industry, I decided to
unfold my investment plan to you of which I am convince as to solicit for
your support and assistance after reading your profile.

I am Mr. Steven Kwaku the son of late brigadier Johnson Kwaku of Congo . My
late father was in charge of arms and ammunition procurement for the Congo
Amry under President Joseph Kabila. He was arrested and shot in the current
crises in my country by the rebel forces. Before his death he was able to
confirm personally to us of an existence deposit of $12.5M (Twelve Million
five hundred thousand United state dollars only) which he deposited in a
private security company here in Thailand for safekeeping.

After the death of my father, I was able to escape along with my mother to
Thailand where we seek asylum as refugee but unfortunately my mother was
killed in Phuket in southern Thailand on 26th December 2004 by tsunami wave
and her body was never found as she was flushed away by the sea. Her death
turned my life to an orphan with unbearable condition. Now I have certified
the existence of the fund in the security vault with all the appropriate
documents of the fund in my hand as the next of kin/ beneficiary of the
fund.

Now I have concluded arrangement to clear the trunk box containing the mone=
y
out from the security company so that I can transfer the fund out of
Thailand for investment partnership because due to my current status as a
political refugee here I am limited to handle such huge amount of cash as I
am also limited from operating a bank account as a refugee here in Thailand=
.


For the above reason, I have decided to seek for an assistance and help fro=
m
you as a foreign partner to enable us reach a contract joint venture
partnership agreement to transfer and invest the fund in a profitable
business orientation in your country under long time joint venture
partnership to enable us entrust the investment in your care and management
as soon as it is cleared from the security vault here in Thailand.

(1) I will offer a 35% reasonable percentage from the total fund as a rewar=
d
for all your help in transferring of the fund to your Bank account in your
country.

(2) I will map out 5% of the total fund to meet up any expenses made by bot=
h
parties during the transaction.

(3) To enable me relocate and settle in your country as soon as the fund is
successfully transferred to your account.

(4) To reach a long-term partnership agreement to entrust the investment in
your management.

Please, go to the below site so you can understand the present situation in
my country.

http://news.bbc.co.uk/2/hi/africa/country_profiles/1076794.stm

Note this transaction is 100% risk free from both sides, So you should not
entertain any fear. For the interest of this transaction do not hesitate to
contact me on my direct email:


Yours Sincerely.

Mr. Steven Kwaku

------=_Part_1392_27499254.1147055915677
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<p>Mr. Steven Kwaku<br>Address : United Nation Refugee Camp. Thailand.</p>
<p>Dear Sir,</p>
<p>With due respect trust and humanity. I write you this letter which I bel=
ieve wouldbe of great interest to you. I got your contact from a business d=
irectory here in Thailand chamber of commerce and industry, I decided to un=
fold my investment plan to you of which I am convince as to solicit for you=
r support and assistance after reading your profile.=20
</p>
<p>I am Mr. Steven Kwaku the son of late brigadier Johnson Kwaku of Congo .=
 My late father was in charge of arms and ammunition procurement for the Co=
ngo Amry under President Joseph Kabila. He was arrested and shot in the cur=
rent crises in my country by the rebel forces. Before his death he was able=
 to confirm personally to us of an existence deposit of $12.5M (Twelve Mill=
ion five hundred thousand United state dollars only) which he deposited in =
a private security company here in Thailand for safekeeping.=20
</p>
<p>After the death of my father, I was able to escape along with my mother =
to Thailand where we seek asylum as refugee but unfortunately my mother was=
 killed in Phuket in southern Thailand on 26th December 2004 by tsunami wav=
e and her body was never found as she was flushed away by the sea. Her deat=
h turned my life to an orphan with unbearable condition. Now I have certifi=
ed the existence of the fund in the security vault with all the appropriate=
 documents of the fund in my hand as the next of kin/ beneficiary of the fu=
nd.=20
</p>
<p>Now I have concluded arrangement to clear the trunk box containing the m=
oney out from the security company so that I can transfer the fund out of T=
hailand for investment partnership because due to my current status as a po=
litical refugee here I am limited to handle such huge amount of cash as I a=
m also limited from operating a bank account as a refugee here in Thailand.=
=20
</p>
<p>For the above reason, I have decided to seek for an assistance and help =
from you as a foreign partner to enable us reach a contract joint venture p=
artnership agreement to transfer and invest the fund in a profitable busine=
ss orientation in your country under long time joint venture partnership to=
 enable us entrust the investment in your care and management as soon as it=
 is cleared from the security vault here in Thailand.=20
</p>
<p>(1) I will offer a 35% reasonable percentage from the total fund as a re=
ward for all your help in transferring of the fund to your Bank account in =
your country.</p>
<p>(2) I will map out 5% of the total fund to meet up any expenses made by =
both parties during the transaction. </p>
<p>(3) To enable me relocate and settle in your country as soon as the fund=
 is successfully transferred to your account.</p>
<p>(4) To reach a long-term partnership agreement to entrust the investment=
 in your management. </p>
<p>Please, go to the below site so you can understand the present situation=
 in my country.</p>
<p><a href=3D"http://news.bbc.co.uk/2/hi/africa/country_profiles/1076794.st=
m">http://news.bbc.co.uk/2/hi/africa/country_profiles/1076794.stm</a> </p>
<p>Note this transaction is 100% risk free from both sides, So you should n=
ot entertain any fear. For the interest of this transaction do not hesitate=
 to contact me on my direct email:</p>
<p><br>Yours Sincerely. </p>
<p>Mr. Steven Kwaku</p>
<p>&nbsp;<br></p>

------=_Part_1392_27499254.1147055915677--


Envelope-to: [e-mail]
Delivery-date: Fri, 05 May 2006 19:07:50 +0000
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: multipart/mixed; boundary=Apple-Mail-19-1045133920
Message-Id: <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail], Wijnen Bert <[e-mail]>, "Dan ((E-mail)) Romascanu" <[e-mail]>, Cucchiara Joan <[e-mail]>, Kireeti Kompella <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>
From: "Thomas D. Nadeau" <[e-mail]>
Subject: draft-ietf-ccamp-gmpls-lsr-mib-14.txt
Date: Fri, 5 May 2006 15:07:38 -0400
To: [e-mail]

--Apple-Mail-19-1045133920
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed



	Adrian/Deborah,

	I have updated draft-ietf-ccamp-gmpls-lsr-mib-14.txt
as per Joan's last MIB Doctor review comment. This draft
and the corresponding CCAMP MIB modules are ready now
to go to the IESG.

	--Tom



--Apple-Mail-19-1045133920
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	x-unix-mode=0644;
	name="draft-ietf-ccamp-gmpls-lsr-mib-14.txt"
Content-Disposition: attachment;
	filename=draft-ietf-ccamp-gmpls-lsr-mib-14.txt


Network Working Group                              Thomas D. Nadeau, Ed.
Internet Draft                                       Cisco Systems, Inc.
Proposed Status: Standards Track
Expires: September 2006                               Adrian Farrel, Ed.
                                                      Old Dog Consulting

                                                              April 2006

         Generalized Multiprotocol Label Switching (GMPLS)
      Label Switching Router (LSR) Management Information Base

              draft-ietf-ccamp-gmpls-lsr-mib-14.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects to configure and/or
   monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
   Switching Router (LSR).


Table of Contents

   1. Introduction ..................................... 2
   1.1. Migration Strategy ............................. 3



Nadeau and Farrel            Expires October 2006            [Page 1]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   2. Terminology ...................................... 3
   3. The Internet-Standard Management Framework ....... 4
   4. Outline .......................................... 5
   4.1 MIB Modules ..................................... 5
   4.1.1 Summary of the GMPLS-LSR-STD-MIB Module ....... 5
   4.1.2 Summary of the GMPLS-LABEL-STD-MIB Module ..... 5
   4.2. Configuring Statically Provisioned LSPs ........ 6
   5. Bidirectional LSPs ............................... 6
   6. Example of LSP Setup ............................. 7
   7. GMPLS Label Switching Router MIB Definitions .... 11
   8. GMPLS Label MIB Definitions ..................... 22
   9. Security Considerations ......................... 37
   10. Acknowledgments ................................ 38
   11. IANA Considerations ............................ 38
   11.1. IANA Considerations for GMPLS-LSR-STD-MIB .... 38
   11.2. IANA Considerations for GMPLS-LABEL-STD-MIB .. 39
   12. References ..................................... 39
   12.1. Normative References ......................... 39
   12.2. Informative References ....................... 40
   13. Contact Information ............................ 41
   14. Intellectual Property Considerations ........... 42
   15. Full Copyright Statement ....................... 42

1. Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for modeling a
   Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] Label
   Switching Router (LSR).

   Comments should be made directly to the CCAMP mailing list at
   [e-mail].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119,
   reference [RFC2119].

1.1. Migration Strategy

   MPLS LSRs may be modeled and managed using the MPLS-LSR-STD-MIB
   module [RFC3813].

   LSRs may be migrated to be modeled and managed using the MIB modules
   in this document in order to migrate the LSRs to GMPLS support, or to
   take advandtage of additional MIB objects defined in these MIB
   modules that are applicable to MPLS-TE.



Nadeau and Farrel            Expires October 2006            [Page 2]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   The GMPLS LSR MIB module (GMPLS-LSR-STD-MIB) defined in this document
   extends the MPLS-LSR-STD-MIB module [RFC3813] through a series of
   sparse augmentations of the MIB tables. The only additions are for
   support of GMPLS or to support the increased complexity of MPLS and
   GMPLS systems.

   In order to migrate from MPLS-LSR-STD-MIB support to
   GMPLS-LSR-STD-MIB support an implementation needs only to add support
   for the additional tables and objects defined in GMPLS-LSR-STD-MIB.
   The gmplsInterfaceSignalingCaps object allows an implementation to
   use the objects and tables of GMPLS-LSR-STD-MIB without supporting
   the GMPLS protocols.

   The GMPLS Label MIB module (GMPLS-LABEL-STD-MIB) also defined in this
   document allows labels to be configured and examined, and supports
   more varieties of label as appropriate for GMPLS. Labels may be
   referenced using a row pointer from objects within the
   GMPLS-LSR-STD-MIB module. MPLS implementations (MPLS-LSR-STD-MIB) may
   also reference labels held in the GMPLS-LABEL-STD-MIB module through
   the various label pointer objects in the MPLS-LSR-STD-MIB module
   (such as mplsInSegmentLabelPtr), and may do so without implementing
   the GMPLS-LSR-STD-MIB module.

   The companion document modeling and managing GMPLS based traffic
   engineering [GMPLSTEMIB] extends the MPLS-TE-STD-MIB module [RFC3812]
   with the same intentions.

   Textual conventions are defined in [GMPLSTCMIB] which extends the=20
   set of textual conventions originally defined in [RFC3811].

2. Terminology

   This document uses terminology from the document describing the MPLS
   architecture [RFC3031] and the GMPLS architecture [RFC3945].

   A label switched path (LSP) is modeled as a connection consisting of
   one or more incoming segments (in-segments) and/or one or more
   outgoing segments (out-segments) at an LSR. The association or
   interconnection of the in-segments and out-segments is accomplished
   by using a cross-connect. We use the terminology "connection" and
   "LSP" interchangeably where the meaning is clear from the context.

   in-segment     This is analogous to a GMPLS label on an interface.
   out-segment    This is analogous to a GMPLS label on an interface.
   cross-connect  This describes the conceptual connection between a
                  set of in-segments and out-segments. Note that either
                  set may be empty; for example, a cross-connect may



Nadeau and Farrel            Expires October 2006            [Page 3]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



                  connect only out-segments together with no in-segments
                  in the case where an LSP originates on an LSR.

   The terms 'ingress' and 'head-end' (or 'head') are used in this
   document to indicate the signaling source of an LSP. This is
   sometimes also referred to as the 'sender'.

   The terms 'egress' and 'tail-end' (or 'tail') are used in this
   document to indicate the signaling destination of an LSP.

   The term 'upstream' is used in this document to refer to the part of
   an LSP closer to the ingress than the current point of reference.

   The term 'downstream' is used in this document to refer to the part
   of an LSP closer to the egress than the current point of reference.

   The term 'forward' is used in this document to indicate the direction
   of data flow from the ingress toward the egress.

   The term 'reverse' is used in this document to indicate the direction
   of data flow from the egress toward the ingress.

3. The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB. MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI). This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

4. Outline

4.1 MIB Modules

   There are two MIB modules defined in this document.

   The GMPLS-LSR-STD-MIB module contains tables that sparse augment
   tables defined in the MPLS-LSR-STD-MIB module [RFC3813]. This MIB
   module is used in conjunction with the MPLS-LSR-STD-MIB module
   [RFC3813] in systems that support GMPLS.




Nadeau and Farrel            Expires October 2006            [Page 4]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   The GMPLS-LABEL-STD-MIB module contains objects for managing GMPLS
   labels when they cannot be represented using the textual conventions
   of the MPLS-TC-STD-MIB module [RFC3811], or when more detailed access
   to the sub-fields of the labels is required.

4.1.1 Summary of the GMPLS-LSR-STD-MIB Module

   The MIB tables in the GMPLS-LSR-STD-MIB module are as follows.

   - The interface configuration table (gmplsInterfaceTable), which
     sparse augments the mplsInterfaceTable [RFC3813] to enable the
     GMPLS protocol on MPLS-capable interfaces.

   - The in-segment (gmplsInSegmentTable) and out-segment
     (gmplsOutSegmentTable) tables sparse augment mplsInSegmentTable and
     mplsOutSegmentTable [RFC3813] to enable configuration of
     GMPLS-specific parameters for LSP segments at an LSR.

   These tables are described in the subsequent sections.

4.1.2 Summary of the GMPLS-LABEL-STD-MIB Module

   There is one MIB table in the GMPLS-LABEL-STD-MIB module as follows.

   - The gmplsLabelTable allows Generalized
     Labels to be defined and managed in a central location.
     Generalized Labels can be of variable length and have distinct
     bit-by-bit interpretations depending upon how they are defined
     for the specific technology in which they are used. For example,
     labels used for MPLS packet switching are different in length
     and content from labels used in TDM timeslot switching.


4.2. Configuring Statically Provisioned LSPs

   Configuring statically provisioned GMPLS LSPs through an LSR involves
   the following steps:

   - Configuring an interface using the MPLS-LSR-STD-MIB module
     [RFC3813].

   - Enabling GMPLS on GMPLS capable interfaces using the
     GMPLS-LSR-STD-MIB module in this document.

   - Configuring in and out-segments using the MPLS-LSR-STD-MIB module
     [RFC3813].

   - Configuring GMPLS extensions to the in-segments and out-segments



Nadeau and Farrel            Expires October 2006            [Page 5]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     using the GMPLS-LSR-STD-MIB module in this document.

   - Setting up the cross-connect table in the MPLS-LSR-STD-MIB module
     [RFC3813] to associate segments and/or to indicate connection
     origination and termination.

   - Optionally setting up labels in the label table in the
     GMPLS-LABEL-STD-MIB module in this document if the textual
     convention MplsLabel [RFC3811] is not capable of holding the
     required label (for example, if the label requires more than 32
     bits to encode it), or if the operator wishes to disambiguate GMPLS
     label types.

   - Optionally specifying label stack actions in the MPLS-LSR-STD-MIB
     module [RFC3813].

   - Optionally specifying segment traffic parameters in the
     MPLS-LSR-STD-MIB module [RCF3813].

5. Bidirectional LSPs

   The GMPLS-LSR-STD-MIB module supports bidirectional LSPs as required
   for GMPLS. A single value of mplsXCIndex is shared by all of the
   segments for the entire bidirectional LSP. This facilitates a simple
   reference from [RFC3812] and [GMPLSTEMIB], and makes fate-sharing
   more obvious.

   It is, however, important that the direction of segments is
   understood to avoid connecting all in-segments to all out-segments.
   This is achieved by an object in each segment that indicates the
   direction of the segment with respect to data flow.

   A segment that is marked as 'forward' carries data from the 'head' of
   the LSP to the 'tail'. A segment marked as 'reverse' carries data in
   the reverse direction.

   Where an LSP is signaled using a conventional signaling protocol, the
   'head' of the LSP is the source of the signaling (also known as the
   ingress) and the 'tail' is the destination (also known as the
   egress). For manually configured LSPs an arbitrary decision must be
   made about which segments are 'forward' and which 'reverse'. For
   consistency this decision should be made across all LSRs that
   participate in the LSP by assigning 'head' and 'tail' ends to the
   LSP.

6. Example of LSP Setup

   In this section we provide a brief example of using the MIB objects



Nadeau and Farrel            Expires October 2006            [Page 6]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   described in sections 7 and 8 to set up an LSP. While this example is
   not meant to illustrate every nuance of the MIB modules, it is
   intended as an aid to understanding some of the key concepts. It is
   meant to be read after going through the MIB modules themselves. A
   prerequisite is an understanding of the MPLS-LSR-STD-MIB [RFC3813].

   Suppose that one would like to manually create a best-effort,
   bi-directional LSP. Assume that, in the forward direction, the LSP
   enters the LSR via MPLS interface A with ifIndex 12 and exits the LSR
   via MPLS interface B with ifIndex 13. For the reverse direction, we
   assume the LSP enters via interface B and leaves via interface A
   (i.e. the forward and reverse directions use the same bi-directional
   interfaces). Let us also assume that we do not wish to have a label
   stack beneath the top label on the outgoing labeled packets. The
   following example illustrates which rows and corresponding objects
   might be created to accomplish this.

   We must first create rows in the gmplsLabelTable corresponding to the
   labels required for each of the forward and reverse direction in- and
   out-segments. For the purpose of this example the forward and
   reverse labels on each interface will be the same, hence we need to
   create just two rows in the gmplsLabelTable - one for each interface.

   In gmplsLabelTable:
   {
     gmplsLabelInterface           =3D 12,
     gmplsLabelIndex               =3D 1,
     gmplsLabelSubindex            =3D 0,
     gmplsLabelType                =3D gmplsFreeformLabel(3),
     gmplsLabelFreeform            =3D 0x123456789ABCDEF0
     gmplsLabelRowStatus           =3D createAndGo(4)
   }

   In gmplsLabelTable:
   {
     gmplsLabelInterface           =3D 13,
     gmplsLabelIndex               =3D 1,
     gmplsLabelSubindex            =3D 0,
     gmplsLabelType                =3D gmplsFreeformLabel(3),
     gmplsLabelFreeform            =3D 0xFEDCBA9876543210
     gmplsLabelRowStatus           =3D createAndGo(4)
   }

   We must next create the appropriate in-segment and out-segment
   entries. These are done in [RFC3813] using the mplsInSegmentTable and
   mplsOutSegmentTable. Note that we use a row pointer to the two rows
   in the gmplsLabelTable rather than specifying the labels explicitly
   in the in- and out-segment tables. Also note that the row status for



Nadeau and Farrel            Expires October 2006            [Page 7]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   each row is set to createAndWait(5) to allow corresponding entries in
   the gmplsInSegmentTable and gmplsOutSegmentTable to be created.

   For the forward direction.

   In mplsInSegmentTable:
   {
      mplsInSegmentIndex           =3D 0x00000015
      mplsInSegmentLabel           =3D 0, -- incoming label in label =
table
      mplsInSegmentNPop            =3D 1,
      mplsInSegmentInterface       =3D 12, -- incoming interface
      -- RowPointer MUST point to the first accsesible column.
      mplsInSegmentTrafficParamPtr    =3D 0.0,
      mplsInSegmentLabelPtr           =3D gmplsLabelTable (12, 1, 0)
      mplsInSegmentRowStatus          =3D createAndWait(5)
   }

   In mplsOutSegmentTable:
   {
      mplsOutSegmentIndex          =3D 0x00000012,
      mplsOutSegmentInterface      =3D 13, -- outgoing interface
      mplsOutSegmentPushTopLabel   =3D true(1),
      mplsOutSegmentTopLabel       =3D 0, -- outgoing label in label =
table

      -- RowPointer MUST point to the first accessible column.
      mplsOutSegmentTrafficParamPtr   =3D 0.0,
      mplsOutSegmentLabelPtr          =3D gmplsLabelTable (13, 1, 0)
      mplsOutSegmentRowStatus         =3D createAndWait(5)
   }

   For the reverse direction.

   In mplsInSegmentTable:
   {
      mplsInSegmentIndex           =3D 0x00000016

      mplsInSegmentLabel           =3D 0, -- incoming label in label =
table
      mplsInSegmentNPop            =3D 1,
      mplsInSegmentInterface       =3D 13, -- incoming interface

      -- RowPointer MUST point to the first accessible column.
      mplsInSegmentTrafficParamPtr    =3D 0.0,
      mplsInSegmentLabelPtr           =3D gmplsLabelTable (13, 1, 0)

      mplsInSegmentRowStatus          =3D createAndWait(5)
   }

   In mplsOutSegmentTable:



Nadeau and Farrel            Expires October 2006            [Page 8]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   {
      mplsOutSegmentIndex          =3D 0x00000013,
      mplsOutSegmentInterface      =3D 12, -- outgoing interface
      mplsOutSegmentPushTopLabel   =3D true(1),
      mplsOutSegmentTopLabel       =3D 0, -- outgoing label in label =
table

      -- RowPointer MUST point to the first accessible column.
      mplsOutSegmentTrafficParamPtr   =3D 0.0,
      mplsOutSegmentLabelPtr          =3D gmplsLabelTable (12, 1, 0)

      mplsOutSegmentRowStatus         =3D createAndWait(5)
   }

   These table entries are extended by entries in gmplsInSegmentTable
   and gmplsOutSegmentTable. Note that the nature of the 'extends'
   relationship is a sparse augmentation so that the entry in
   gmplsInSegmentTable has the same index values as the entry in
   mplsInSegmentTable. Similarly, the entry in gmplsOutSegmentTable has
   the same index values as the entry in mplsOutSegmentTable.

   First for the forward direction:

   In gmplsInSegmentTable(0x00000015)
   {
     gmplsInSegmentDirection          =3D forward (1)
   }

   In gmplsOutSegmentTable(0x00000012)
   {
     gmplsOutSegmentDirection         =3D forward (1)
   }

   Next for the reverse direction:

   In gmplsInSegmentTable(0x00000016)
   {
     gmplsInSegmentDirection          =3D reverse (2)
   }

   In gmplsOutSegmentTable(0x00000013)
   {
     gmplsOutSegmentDirection         =3D reverse (2)
   }

   Next, two cross-connect entries are created in the mplsXCTable of the
   MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created
   segments together.




Nadeau and Farrel            Expires October 2006            [Page 9]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   In mplsXCTable:
   {
      mplsXCIndex                =3D 0x01,
      mplsXCInSegmentIndex       =3D 0x00000015,
      mplsXCOutSegmentIndex      =3D 0x00000012,
      mplsXCLspId                =3D 0x0102 -- unique ID
      mplsXCLabelStackIndex      =3D 0x00, -- only a single outgoing =
label
      mplsXCRowStatus            =3D createAndGo(4)
   }

   In mplsXCTable:
   {
      mplsXCIndex                =3D 0x02,
      mplsXCInSegmentIndex       =3D 0x00000016,
      mplsXCOutSegmentIndex      =3D 0x00000013,
      mplsXCLspId                =3D 0x0102 -- unique ID
      mplsXCLabelStackIndex      =3D 0x00, -- only a single outgoing =
label
      mplsXCRowStatus            =3D createAndGo(4)
   }

   Finally, the in-segments and out-segments are activated.

   In mplsInSegmentTable(0x00000015):
   {
      mplsInSegmentRowStatus          =3D active(1)
   }
   In mplsInSegmentTable(0x00000016):
   {
      mplsInSegmentRowStatus          =3D active(1)
   }

   In mplsOutSegmentTable(0x00000012):
   {
      mplsOutSegmentRowStatus         =3D active(1)
   }

   In mplsOutSegmentTable(0x00000013):
   {
      mplsOutSegmentRowStatus         =3D active(1)
   }


7. GMPLS Label Switching Router MIB Definitions

   This MIB module makes references to the following documents.
   [RFC2578], [RFC2579], [RFC2580], [GMPLSTCMIB], [RFC3811],
   [RFC2863] and [RFC3813].




Nadeau and Farrel            Expires October 2006           [Page 10]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   GMPLS-LSR-STD-MIB DEFINITIONS ::=3D BEGIN

   IMPORTS
     MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, zeroDotZero
       FROM SNMPv2-SMI                                   -- RFC2578
     MODULE-COMPLIANCE, OBJECT-GROUP
       FROM SNMPv2-CONF                                  -- RFC2580
     RowPointer
       FROM SNMPv2-TC                                    -- RFC2579
     GmplsSegmentDirectionTC
       FROM GMPLS-TC-STD-MIB                             -- GMPLSTCMIB
-- RFC-Editor please resolve the reference above to GMPLSTCMIB
-- using the assigned RFC number and remove this note
     mplsInterfaceIndex, mplsInSegmentIndex, mplsOutSegmentIndex,
     mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup,
     mplsXCGroup, mplsPerfGroup, mplsLsrNotificationGroup
       FROM MPLS-LSR-STD-MIB                             -- RFC3813
     ifGeneralInformationGroup, ifCounterDiscontinuityGroup
       FROM IF-MIB                                       -- RFC2863
     mplsStdMIB
       FROM MPLS-TC-STD-MIB                              -- RFC3811
   ;

   gmplsLsrStdMIB MODULE-IDENTITY
     LAST-UPDATED
       "200604060001Z" -- 06 April 2006 00:00:01 GMT
     ORGANIZATION
       "IETF Common Control And Measurement Plane (CCAMP) Working Group"
     CONTACT-INFO
       "       Thomas D. Nadeau
               Cisco Systems, Inc.
        Email: [e-mail]
               Adrian Farrel
               Old Dog Consulting
        Email: [e-mail]
        Comments about this document should be emailed direct to the
        CCAMP working group mailing list at [e-mail]"

     DESCRIPTION
       "Copyright (C) The Internet Society (2006).  This version of
        this MIB module is part of RFC XXX; see the RFC itself for
        full legal notices.
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

        This MIB module contains managed object definitions for the
        Generalized Multiprotocol (GMPLS) Label Switching Router as
        defined in: Generalized Multi-Protocol Label Switching (GMPLS)



Nadeau and Farrel            Expires October 2006           [Page 11]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        Architecture, Mannie et al., RFC 3945, October 2004."

     REVISION
       "200604060001Z" -- 06 April 2006 00:00:01 GMT
     DESCRIPTION
       "Initial version issued as part of RFC XXX."
     ::=3D { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note

   -- no notifications are currently defined.
   gmplsLsrObjects       OBJECT IDENTIFIER ::=3D { gmplsLsrStdMIB 1 }
   gmplsLsrConformance   OBJECT IDENTIFIER ::=3D { gmplsLsrStdMIB 2 }

   gmplsInterfaceTable OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsInterfaceEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "This table specifies per-interface GMPLS capability and
        associated information. It extends the information in
        mplsInterfaceTable of the MPLS-LSR-STD-MIB through a
        sparse augmentation relationship."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
     ::=3D { gmplsLsrObjects 1 }

   gmplsInterfaceEntry OBJECT-TYPE
     SYNTAX        GmplsInterfaceEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "A conceptual row in this table is created automatically by an
        LSR for each interface that is both capable of supporting
        GMPLS and that is configured to support GMPLS. Note that
        support of GMPLS is not limited to control plane signaling,
        but may include data-plane only function configured through
        SNMP SET commands performed on this MIB module.

        A conceptual row in this table may also be created via SNMP
        SET commands or automatically by the LSR to supplement a
        conceptual row in the mplsInterfaceTable where the interface
        is not capable of GMPLS but where the other objects carried




Nadeau and Farrel            Expires October 2006           [Page 12]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        in this row provide useful additional information for an
        MPLS interface.

        A conceptual row in this table will exist if and only if a
        corresponding entry in mplsInterfaceTable exists, and a
        corresponding entry in ifTable exists with ifType =3D mpls(166).
        If the associated entry in ifTable is operationally disabled
        (thus removing the GMPLS capabilities on the interface) or the
        entry in mplsInterfaceTable is deleted, the corresponding entry
        in this table MUST be deleted shortly thereafter.

        The indexes are the same as for mplsInterfaceTable. Thus, the
        entry with index 0 represents the per-platform label space and
        contains parameters that apply to all interfaces that
        participate in the per-platform label space."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
     INDEX { mplsInterfaceIndex }
   ::=3D { gmplsInterfaceTable 1 }

   GmplsInterfaceEntry ::=3D SEQUENCE {
     gmplsInterfaceSignalingCaps      BITS,
     gmplsInterfaceRsvpHelloPeriod    Unsigned32
   }

   gmplsInterfaceSignalingCaps OBJECT-TYPE
     SYNTAX  BITS {
       unknown (0),
       rsvpGmpls (1),
       crldpGmpls (2), -- note the use of CR-LDP is deprecated
       otherGmpls (3)
     }
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Defines the signaling capabilities on this interface. Multiple
        bits may legitimately be set at once, but if 'unknown' is set
        then no other bit may be set. Setting no bits implies that GMPLS
        signaling cannot be performed on this interface and all LSPs
        must be manually provisioned or that this table entry is only
        present to supplement an entry in the mplsInterfaceTable by
        providing the information carried in other objects in this row."
     REFERENCE
       "1. Generalized MPLS Signaling - CR-LDP Extensions, RFC 3472.
        2. The Multiprotocol Label Switching (MPLS) Working Group
           decision on MPLS signaling protocols, RFC 3468.
        3. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473.



Nadeau and Farrel            Expires October 2006           [Page 13]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        "
     DEFVAL { { rsvpGmpls } }
   ::=3D { gmplsInterfaceEntry 1 }

   gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE
     SYNTAX       Unsigned32
     UNITS        "milliseconds"
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Period, in milliseconds, between sending RSVP Hello messages on
        this interface. A value of 0 indicates that no Hello messages
        should be sent on this interface.

        This object is only valid if gmplsInterfaceSignalingCaps has no
        bits set or includes the rsvpGmpls bit."
     REFERENCE
       "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209,
           section 5.
        2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473,
           section 9.3."
     DEFVAL { 3000 }
   ::=3D { gmplsInterfaceEntry 2 }

   gmplsInSegmentTable  OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsInSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "This table sparse augments the mplsInSegmentTable of the
        MPLS-LSR-STD-MIB to provide GMPLS-specific information about
        incoming segments to an LSR."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
   ::=3D { gmplsLsrObjects 2 }

   gmplsInSegmentEntry  OBJECT-TYPE
     SYNTAX        GmplsInSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "An entry in this table extends the representation of an incoming
        segment represented by an entry in mplsInSegmentTable in the
        MPLS-LSR-STD-MIB through a sparse augmentation. An entry can be
        created by a network administrator via SNMP SET commands, or in
        response to signaling protocol events.




Nadeau and Farrel            Expires October 2006           [Page 14]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        Note that the storage type for this entry is given by the value
        of mplsInSegmentStorageType in the corresponding entry of the
        mplsInSegmentTable."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."

     INDEX { mplsInSegmentIndex }
   ::=3D { gmplsInSegmentTable 1 }

   GmplsInSegmentEntry ::=3D SEQUENCE {
     gmplsInSegmentDirection        GmplsSegmentDirectionTC,
     gmplsInSegmentExtraParamsPtr   RowPointer
   }

   gmplsInSegmentDirection OBJECT-TYPE
     SYNTAX        GmplsSegmentDirectionTC
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This object indicates the direction of data flow on this
        segment. This object cannot be modified if
        mplsInSegmentRowStatus for the corresponding entry in the
        mplsInSegmentTable is active(1)."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
     DEFVAL        { forward }
   ::=3D { gmplsInSegmentEntry 1 }

   gmplsInSegmentExtraParamsPtr  OBJECT-TYPE
     SYNTAX       RowPointer
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Some Tunnels will run over transports that can usefully support
        technology-specific additional parameters (for example, SONET
        resource usage). Such can be supplied from an external table and
        referenced from here. A value of zeroDotzero in this attribute
        indicates that there is no such additional information."
     DEFVAL      { zeroDotZero }
     ::=3D { gmplsInSegmentEntry 2 }

   gmplsOutSegmentTable  OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsOutSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION



Nadeau and Farrel            Expires October 2006           [Page 15]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



       "This table sparse augments the mplsOutSegmentTable of the
        MPLS-LSR-STD-MIB to provide GMPLS-specific information about
        outgoing segments from an LSR."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
   ::=3D { gmplsLsrObjects 3 }

   gmplsOutSegmentEntry  OBJECT-TYPE
     SYNTAX        GmplsOutSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "An entry in this table extends the representation of an outgoing
        segment represented by an entry in mplsOutSegmentTable of the
        MPLS-LSR-STD-MIB through a sparse augmentation. An entry can be
        created by a network administrator via SNMP SET commands, or in
        response to signaling protocol events.

        Note that the storage type for this entry is given by the value
        of mplsOutSegmentStorageType in the corresponding entry of the
        mplsOutSegmentTable."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
     INDEX  { mplsOutSegmentIndex }
   ::=3D { gmplsOutSegmentTable 1 }

   GmplsOutSegmentEntry ::=3D SEQUENCE {
     gmplsOutSegmentDirection       GmplsSegmentDirectionTC,
     gmplsOutSegmentTTLDecrement    Unsigned32,
     gmplsOutSegmentExtraParamsPtr  RowPointer
   }

   gmplsOutSegmentDirection OBJECT-TYPE
     SYNTAX        GmplsSegmentDirectionTC
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This object indicates the direction of data flow on this
        segment. This object cannot be modified if
        mplsOutSegmentRowStatus for the corresponding entry in the
        mplsOutSegmentTable is active(1)."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
     DEFVAL  { forward }
   ::=3D { gmplsOutSegmentEntry 1 }



Nadeau and Farrel            Expires October 2006           [Page 16]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   gmplsOutSegmentTTLDecrement OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This object indicates the amount by which to decrement the TTL
        of any payload packets forwarded on this segment if per-hop
        decrementing is being done.

        A value of zero indicates that no decrement should be made or
        that per-hop decrementing is not in use.

        See the gmplsTunnelTTLDecrement object in the gmplsTunnelTable
        of GMPLS-TE-STD-MIB for a value by which to decrement the TTL
        for the whole of a tunnel.

        This object cannot be modified if mplsOutSegmentRowStatus for
        the associated entry in the mplsOutSegmentTable is active(1)."
     REFERENCE
       "1. Time To Live (TTL) Processing in Multi-Protocol Label
           Switching (MPLS) Networks, RFC 3443.
        2. Generalized Multiprotocol Label Switching (GMPLS) Traffic
           Engineering Management Information Base, RFC XXX."
-- RFC Editor. Please insert the correct RFC number and remove this note
     DEFVAL  { 0 }
   ::=3D { gmplsOutSegmentEntry 2 }

   gmplsOutSegmentExtraParamsPtr  OBJECT-TYPE
     SYNTAX       RowPointer
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Some Tunnels will run over transports that can usefully support
        technology-specific additional parameters (for example, SONET
        resource usage). Such can be supplied from an external table and
        referenced from here.

        A value of zeroDotzero in this attribute indicates that there is
        no such additional information."
     DEFVAL      { zeroDotZero }
     ::=3D { gmplsOutSegmentEntry 3 }

   gmplsLsrGroups
     OBJECT IDENTIFIER ::=3D { gmplsLsrConformance 1 }

   gmplsLsrCompliances
     OBJECT IDENTIFIER ::=3D { gmplsLsrConformance 2 }



Nadeau and Farrel            Expires October 2006           [Page 17]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   -- Compliance requirement for fully compliant implementations.

   gmplsLsrModuleFullCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance statement for agents that provide full support for
        GMPLS-LSR-STD-MIB.

         The mandatory group has to be implemented by all LSRs that
         originate, terminate or act as transit for TE-LSPs/tunnels.
         In addition, depending on the type of tunnels supported, other
         groups become mandatory as explained below."

     MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.

     MANDATORY-GROUPS {
       ifGeneralInformationGroup,
       ifCounterDiscontinuityGroup
     }

     MODULE MPLS-LSR-STD-MIB -- The MPLS-LSR-STD-MIB, RFC3813

     MANDATORY-GROUPS {
       mplsInterfaceGroup,
       mplsInSegmentGroup,
       mplsOutSegmentGroup,
       mplsXCGroup,
       mplsPerfGroup,
       mplsLsrNotificationGroup
     }

     MODULE -- this module

     MANDATORY-GROUPS    {
       gmplsInterfaceGroup,
       gmplsInSegmentGroup,
       gmplsOutSegmentGroup
     }

     OBJECT      gmplsInSegmentDirection
     SYNTAX      GmplsSegmentDirectionTC
     MIN-ACCESS  read-only
     DESCRIPTION
       "The only valid value for unidrectional LSPs is forward(1)."

     OBJECT      gmplsOutSegmentDirection
     SYNTAX      GmplsSegmentDirectionTC



Nadeau and Farrel            Expires October 2006           [Page 18]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     MIN-ACCESS  read-only
     DESCRIPTION
       "The only valid value for unidrectional LSPs is forward(1)."

     OBJECT      gmplsOutSegmentTTLDecrement
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsInSegmentExtraParamsPtr
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsOutSegmentExtraParamsPtr
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   ::=3D { gmplsLsrCompliances 1 }

   -- Compliance requirement for implementations that provide read-only
   -- access.

   gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance requirement for implementations that only provide
        read-only support for GMPLS-LSR-STD-MIB. Such devices can then
        be monitored but cannot be configured using this MIB module."

     MODULE IF-MIB -- The interfaces Group MIB, RFC 2863

     MANDATORY-GROUPS {
       ifGeneralInformationGroup,
       ifCounterDiscontinuityGroup
     }

     MODULE MPLS-LSR-STD-MIB

     MANDATORY-GROUPS {
       mplsInterfaceGroup,
       mplsInSegmentGroup,
       mplsOutSegmentGroup,
       mplsXCGroup,
       mplsPerfGroup
     }




Nadeau and Farrel            Expires October 2006           [Page 19]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     MODULE -- this module

     MANDATORY-GROUPS {
       gmplsInterfaceGroup,
       gmplsInSegmentGroup,
       gmplsOutSegmentGroup
     }

     OBJECT      gmplsInterfaceSignalingCaps
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsInterfaceRsvpHelloPeriod
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsInSegmentDirection
     SYNTAX      GmplsSegmentDirectionTC
     MIN-ACCESS  read-only
     DESCRIPTION
       "The only valid value for unidrectional LSPs is forward(1)."

     OBJECT      gmplsInSegmentExtraParamsPtr
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsOutSegmentDirection
     MIN-ACCESS  read-only
     DESCRIPTION
       "The only valid value for unidrectional LSPs is forward(1)."

     OBJECT      gmplsOutSegmentTTLDecrement
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsOutSegmentExtraParamsPtr
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   ::=3D { gmplsLsrCompliances 2 }

   gmplsInterfaceGroup OBJECT-GROUP
     OBJECTS {



Nadeau and Farrel            Expires October 2006           [Page 20]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



       gmplsInterfaceSignalingCaps,
       gmplsInterfaceRsvpHelloPeriod
     }
     STATUS  current
     DESCRIPTION
      "Collection of objects which provide additional=20
       information for an MPLS interface and are needed=20
       for GMPLS interface configuration and performance=20
       information."
   ::=3D { gmplsLsrGroups 1 }

   gmplsInSegmentGroup  OBJECT-GROUP
     OBJECTS {
       gmplsInSegmentDirection,
       gmplsInSegmentExtraParamsPtr
     }
     STATUS  current
     DESCRIPTION
       "Collection of objects which provide additional=20
        information for an MPLS in-segment and are needed=20
        for GMPLS in-segment configuration and performance=20
        information."
   ::=3D { gmplsLsrGroups 2 }

   gmplsOutSegmentGroup  OBJECT-GROUP
     OBJECTS {
       gmplsOutSegmentDirection,
       gmplsOutSegmentTTLDecrement,
       gmplsOutSegmentExtraParamsPtr
     }
     STATUS  current
     DESCRIPTION
       "Collection of objects which provide additional=20
        information for an MPLS out-segment and are needed=20
        for GMPLS out-segment configuration and performance=20
        information."
   ::=3D { gmplsLsrGroups 3 }
   END


8. GMPLS Label MIB Definitions

   This MIB module makes references to the following documents.
   [RFC2578], [RFC2579], [RFC2580], [GMPLSTCMIB], [RFC3811],
   [RFC2863], [RFC3289], [RFC3813], and [RFC3471].
  =20

   GMPLS-LABEL-STD-MIB DEFINITIONS ::=3D BEGIN



Nadeau and Farrel            Expires October 2006           [Page 21]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   IMPORTS
     MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Integer32
       FROM SNMPv2-SMI                                   -- RFC2578
     MODULE-COMPLIANCE, OBJECT-GROUP
       FROM SNMPv2-CONF                                  -- RFC2580
     RowStatus, StorageType
       FROM SNMPv2-TC                                    -- RFC2579
     InterfaceIndexOrZero
       FROM IF-MIB                                       -- RFC2863
     IndexIntegerNextFree
       FROM DIFFSERV-MIB                                 -- RFC3289
     MplsLabel, mplsStdMIB
       FROM MPLS-TC-STD-MIB                              -- RFC3811
     GmplsLabelTypeTC, GmplsFreeformLabelTC
       FROM GMPLS-TC-STD-MIB                             -- GMPLSTCMIB
-- RFC-Editor. Please resolve the reference above to GMPLSTCMIB=20
-- to use the assigned RFC number and remove this note
   ;

   gmplsLabelStdMIB MODULE-IDENTITY
     LAST-UPDATED
       "200604060001Z" -- 06 April 2006 00:00:01 GMT
     ORGANIZATION
       "IETF Common Control And Measurement Plane (CCAMP) Working Group"
     CONTACT-INFO
       "       Thomas D. Nadeau
               Cisco Systems, Inc.
        Email: [e-mail]

               Adrian Farrel
               Old Dog Consulting
        Email: [e-mail]

        Comments about this document should be emailed direct to the
        CCAMP working group mailing list at [e-mail]"

     DESCRIPTION
       "Copyright (C) The Internet Society (2006).  This version of
        this MIB module is part of RFC XXX; see the RFC itself for
        full legal notices.
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

        This MIB module contains managed object definitions for labels
        within GMPLS systems as defined in:
        Generalized Multi-Protocol Label Switching (GMPLS) Signaling
        Functional Description, Berger, L. (Editor), RFC 3471,



Nadeau and Farrel            Expires October 2006           [Page 22]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        January 2003."
     REVISION
       "200604060001Z" -- 06 April 2006 00:00:01 GMT
     DESCRIPTION
       "Initial version issued as part of RFC XXX."
     ::=3D { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace ZZZ above with the OID assigned by IANA
-- and remove this note

   -- no notifications are currently defined.

   gmplsLabelObjects        OBJECT IDENTIFIER ::=3D { gmplsLabelStdMIB 1 =
}
   gmplsLabelConformance    OBJECT IDENTIFIER ::=3D { gmplsLabelStdMIB 2 =
}

   gmplsLabelIndexNext OBJECT-TYPE
     SYNTAX        IndexIntegerNextFree
     MAX-ACCESS    read-only
     STATUS        current
     DESCRIPTION
         "This object contains an unused value for gmplsLabelIndex,
          or a zero to indicate that no unused value exists or is
          available.

          A management application wishing to create a row in the
          gmplsLabelTable may read this object and then attempt to
          create a row in the table. If row creation fails (because
          another application has already created a row with the
          supplied index) the management application should read this
          object again to get a new index value.

          When a row is created in the gmplsLabelTable with the
          gmplsLabelIndex value held by this object, an implementation
          MUST change the value in this object."
     ::=3D { gmplsLabelObjects 1 }

   gmplsLabelTable OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsLabelEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "Table of GMPLS Labels. This table allows the representation
        of the more complex label forms required for GMPLS which cannot
        be held within the textual convention MplsLabel. That is labels
        that cannot be encoded within 32 bits. It is, nevertheless also
        capable of holding 32 bit labels or regular MPLS labels if



Nadeau and Farrel            Expires October 2006           [Page 23]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        desired.

        Each entry in this table represents an individual GMPLS label
        value. Labels in the tables in other MIB modules may be referred
        to using a row pointer into this table. The indexing of this=20
        table provides for arbitrary indexing and also for=20
        concatenation of labels.

        For an example of label concatenation see RFC3945 section 7.1.
        In essence, a GMPLS label may be composite in order to identify
        a set of resources in the data plane. Practical examples are
        timeslots and wavelength sets (which are not contiguous like
        wavebands).

        The indexing mechanism allows multiple entries in this table to
        be seen as a sequence of labels that should be concatenated.
        Ordering is potentially very sensitive for concatenation."
      REFERENCE
        "1. Generalized Multiprotocol Label Switching (GMPLS)
            Architecture, RFC 3945, section 7.1,"
   ::=3D { gmplsLabelObjects 2 }

   gmplsLabelEntry OBJECT-TYPE
     SYNTAX        GmplsLabelEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "An entry in this table represents a single label value. There
        are three indexes into the table.
        -  The interface index may be helpful to distinguish which
           labels are in use on which interfaces or to handle cases
           where there are a very large number of labels in use in the
           system. When label representation is desired to apply to the
           whole system or when it is not important to distinguish
           labels by their interfaces, this index MAY be set to zero.

        -  The label index provides a way of identifying the label.
        -  The label sub-index is only used for concatenated labels. It
           identifies each component label. When non-concatenated labels
           are used, this index SHOULD be set to zero.
        A storage type object is supplied to control the storage type
        for each entry, but implementations should note that the storage
        type of conceptual rows in other tables that include row
        pointers to an entry in this table SHOULD dictate the storage
        type of the rows in this table where the row in the other table
        is more persistent."

     INDEX {



Nadeau and Farrel            Expires October 2006           [Page 24]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



       gmplsLabelInterface,
       gmplsLabelIndex,
       gmplsLabelSubindex }
   ::=3D { gmplsLabelTable 1 }

   GmplsLabelEntry ::=3D SEQUENCE {
     gmplsLabelInterface           InterfaceIndexOrZero,
     gmplsLabelIndex               Unsigned32,
     gmplsLabelSubindex            Unsigned32,
     gmplsLabelType                GmplsLabelTypeTC,
     gmplsLabelMplsLabel           MplsLabel,
     gmplsLabelPortWavelength      Unsigned32,
     gmplsLabelFreeform            GmplsFreeformLabelTC,
     gmplsLabelSonetSdhSignalIndex Integer32,
     gmplsLabelSdhVc               Integer32,
     gmplsLabelSdhVcBranch         Integer32,
     gmplsLabelSonetSdhBranch      Integer32,
     gmplsLabelSonetSdhGroupBranch Integer32,
     gmplsLabelWavebandId          Unsigned32,
     gmplsLabelWavebandStart       Unsigned32,
     gmplsLabelWavebandEnd         Unsigned32,
     gmplsLabelStorageType         StorageType,
     gmplsLabelRowStatus           RowStatus
   }

   gmplsLabelInterface OBJECT-TYPE
     SYNTAX        InterfaceIndexOrZero
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "The interface on which this label is used. If this object is set
        to zero, the label MUST have applicability across the
        whole system and is not limited to a single interface."
   ::=3D { gmplsLabelEntry 1 }

   gmplsLabelIndex OBJECT-TYPE
     SYNTAX        Unsigned32 (0..4294967295)
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "An arbitrary index into the table to identify a label.

        Note that implementations that are representing 32 bit labels
        within this table MAY choose to align this index with the value
        of the label and this may result in the use of the value zero
        since it represents a valid label value.  Such implementation=20
        should be aware of the implications of sparsely populated=20
        tables.



Nadeau and Farrel            Expires October 2006           [Page 25]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




        A management application may read the gmplsLabelIndexNext
        object to find a suitable value for this object."
   ::=3D { gmplsLabelEntry 2 }

   gmplsLabelSubindex OBJECT-TYPE
     SYNTAX        Unsigned32 (0..4294967295)
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "In conjunction with gmplsLabelInterface and gmplsLabelIndex,
        this object uniquely identifies this row. This sub-index allows
        a single GMPLS label to be defined as a concatenation of labels.
        This is particularly useful in TDM.

        The ordering of sub-labels is strict with the sub-label with
        lowest gmplsLabelSubindex appearing first. Note that all
        sub-labels of a single GMPLS label must share the same
        gmplsLabelInterface and gmplsLabelIndex values. For labels that
        are not composed of concatenated sub-labels, this value SHOULD
        be set to zero."
   ::=3D { gmplsLabelEntry 3 }

   gmplsLabelType OBJECT-TYPE
     SYNTAX        GmplsLabelTypeTC
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "Identifies the type of this label. Note that this object does
        not determine whether MPLS or GMPLS signaling is in use: a value
        of gmplsMplsLabel (1) denotes that an MPLS packet label is
        present in the gmplsLabelMplsLabel object and encoded using the
        MplsLabel textual convention (may be a 20-bit MPLS label, a 10-
        or 23-bit Frame Relay label, or an ATM label), but does not
        describe whether this is signaled using MPLS or GMPLS.

        The value of this object helps determine which of the following
        objects are valid. This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
      REFERENCE
        "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
            Functional Description, RFC 3471, section 3."
   ::=3D { gmplsLabelEntry 4 }

   gmplsLabelMplsLabel OBJECT-TYPE
     SYNTAX         MplsLabel
     MAX-ACCESS     read-create
     STATUS         current



Nadeau and Farrel            Expires October 2006           [Page 26]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     DESCRIPTION
       "The value of an MPLS label (that is a packet label) if this
        table is used to store it. This may be used in MPLS systems even

        though the label values can be adequately stored in the MPLS MIB
        modules (MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB). Further, in
        mixed MPLS and GMPLS systems it may be advantageous to store all
        labels in a single label table. Lastly, in GMPLS systems where
        packet labels are used (that is in systems that use GMPLS
        signaling and GMPLS labels for packet switching) it may be
        desirable to use this table.

        This object is only valid if gmplsLabelType is set
        to gmplsMplsLabel (1). This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. MPLS Label Stack Encoding, RFC 3032."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 5 }

   gmplsLabelPortWavelength OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The value of a Port or Wavelength Label when carried as a
        Generalized Label. Only valid if gmplsLabelType is set to
        gmplsPortWavelengthLabel(2). This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
           Functional Description, RFC 3471, section 3.2.1.1."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 6 }

   gmplsLabelFreeform OBJECT-TYPE
     SYNTAX        GmplsFreeformLabelTC
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The value of a freeform Generalized Label that does not conform
        to one of the standardized label encoding or that an
        implementation chooses to represent as an octet string without
        further decoding. Only valid if gmplsLabelType is set to
        gmplsFreeformLabel(3). This object cannot be modified
        if gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling



Nadeau and Farrel            Expires October 2006           [Page 27]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



           Functional Description, RFC 3471, section 3.2."
     DEFVAL { '00'h }
   ::=3D { gmplsLabelEntry 7 }

   gmplsLabelSonetSdhSignalIndex OBJECT-TYPE
     SYNTAX        Integer32 (0..4095)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The Signal Index value (S) of a SONET or SDH Generalized Label.
        Zero indicates that this field is not significant. Only valid if
        gmplsLabelType is set to gmplsSonetLabel(4) or gmplsSdhLabel(5).
        This object cannot be modified if gmplsLabelRowStatus is
        active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
           for Synchronous Optical Network (SONET) and Synchronous
           Digital Hierarchy (SDH) Control, RFC 3946, section 3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 8 }

   gmplsLabelSdhVc OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The VC Indicator (U) of an SDH Generalized Label. Zero indicates
        that this field is non-significant.
        Only valid if gmplsLabelType is set to gmplsSdhLabel(5).
        This object cannot be modified if gmplsLabelRowStatus is
        active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
           for Synchronous Optical Network (SONET) and Synchronous
           Digital Hierarchy (SDH) Control, RFC 3946, section 3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 9 }

   gmplsLabelSdhVcBranch OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The VC Branch Indicator (K) of an SDH Generalized Label. Zero
        indicates that this field is non-significant.
        Only valid if gmplsLabelType is set to gmplsSdhLabel(5). This
        object cannot be modified if gmplsLabelRowStatus is active(1)."
     REFERENCE



Nadeau and Farrel            Expires October 2006           [Page 28]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



       "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
           for Synchronous Optical Network (SONET) and Synchronous
           Digital Hierarchy (SDH) Control, RFC 3946, section 3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 10 }

   gmplsLabelSonetSdhBranch OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The Branch Indicator (L) of a SONET or SDH Generalized Label.
        Zero indicates that this field is non-significant.
        Only valid gmplsLabelType is set to gmplsSonetLabel(4) or
        gmplsSdhLabel(5). This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
           for Synchronous Optical Network (SONET) and Synchronous
           Digital Hierarchy (SDH) Control, RFC 3946, section 3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 11 }

   gmplsLabelSonetSdhGroupBranch OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The Group Branch Indicator (M) of a SONET or SDH Generalized
        Label.
        Zero indicates that this field is non-significant.
        Only valid if gmplsLabelType is set to gmplsSonetLabel(4) or
        gmplsSdhLabel(5). This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
           for Synchronous Optical Network (SONET) and Synchronous
           Digital Hierarchy (SDH) Control, RFC 3946, section 3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 12 }

   gmplsLabelWavebandId OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The waveband identifier component of a waveband label. Only
        valid if gmplsLabelType is set to gmplsWavebandLabel(6). This



Nadeau and Farrel            Expires October 2006           [Page 29]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        object cannot be modified if gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
           Functional Description, RFC 3471, section 3.3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 13 }

   gmplsLabelWavebandStart OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The starting label component of a waveband label.
        Only valid if gmplsLabelType is set to gmplsWavebandLabel(6).
        This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
           Functional Description, RFC 3471, section 3.3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 14 }

   gmplsLabelWavebandEnd OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The end label component of a waveband label. Only valid if
        gmplsLabelType is set to gmplsWavebandLabel(6). This object
        cannot be modified if gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
           Functional Description, RFC 3471, section 3.3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 15 }

   gmplsLabelStorageType OBJECT-TYPE
     SYNTAX        StorageType
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This variable indicates the storage type for this object. The
        agent MUST ensure that this object's value remains consistent
        with the storage type of any rows in other tables that contain
        pointers to this row. In particular, the storage type of this
        row must be at least as permanent as that of any row that point
        to it.




Nadeau and Farrel            Expires October 2006           [Page 30]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        Conceptual rows having the value 'permanent' need not
        allow write-access to any columnar objects in the row."
     REFERENCE
       "1. Textual Conventions for SMIv2, STD 58, RFC 2579, section 2."
     DEFVAL { volatile }
   ::=3D { gmplsLabelEntry 16 }


   gmplsLabelRowStatus OBJECT-TYPE
     SYNTAX        RowStatus
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This variable is used to create, modify, and/or delete a row in
        this table. When a row in this table has a row in the active(1)
        state, no objects in this row can be modified except the
        gmplsLabelRowStatus and gmplsLabelStorageType.

        The gmplsLabelType object does not have a default and must be
        set before a row can become active. The corresponding label
        objects (dependent on the value of gmplsLabelType) should also
        be set unless they happen to need to use the specified default
        values as follows:

        gmplsLabelType setting             objects to be set
        --------------------------------------------------------------
        gmplsMplsLabel(1)                  gmplsLabelMplsLabel

        gmplsPortWavelengthLabel(2)        gmplsLabelPortWavelength

        gmplsFreeformLabel(3)              gmplsLabelFreeform

        gmplsSonetLabel(4)                 gmplsLabelSonetSdhSignalIndex
                                           gmplsLabelSdhVc
                                           gmplsLabelSdhVcBranch
                                           gmplsLabelSonetSdhBranch
                                           gmplsLabelSonetSdhGroupBranch

        gmplsSdhLabel(5)                   gmplsLabelSonetSdhSignalIndex
                                           gmplsLabelSdhVc
                                           gmplsLabelSdhVcBranch
                                           gmplsLabelSonetSdhBranch
                                           gmplsLabelSonetSdhGroupBranch

        gmplsWavebandLabel(6)              gmplsLabelWavebandId
                                           gmplsLabelWavebandStart
                                           gmplsLabelWavebandEnd"
   ::=3D { gmplsLabelEntry 17 }



Nadeau and Farrel            Expires October 2006           [Page 31]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   gmplsLabelGroups
     OBJECT IDENTIFIER ::=3D { gmplsLabelConformance 1 }

   gmplsLabelCompliances
     OBJECT IDENTIFIER ::=3D { gmplsLabelConformance 2 }

   gmplsLabelModuleReadOnlyCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance requirement for implementations that only provide
        read-only support for GMPLS-LABEL-STD-MIB. Such devices can then
        be monitored but cannot be configured using this MIB module."

     MODULE -- this module

     -- The mandatory groups have to be implemented by LSRs claiming
     -- support for this MIB module. This MIB module is, however, not
     -- mandatory for a working implementation of a GMPLS LSR with full
     -- MIB support if the GMPLS labels in use can be represented within
     -- a 32 bit quantity.

     MANDATORY-GROUPS {
       gmplsLabelTableGroup
     }

     GROUP gmplsLabelPacketGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for implementations that
        support packet labels. It is optional for implementations that
        do not support packet labels."

     GROUP gmplsLabelPortWavelengthGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for implementations that
        support port and wavelength labels. It is optional for
        implementations that do not support wavelength labels."

     GROUP gmplsLabelFreeformGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for implementations that
        support freeform labels. It is optional for implementations that
        do not support freeform labels."

     GROUP gmplsLabelSonetSdhGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for implementations that
        support SONET or SDH labels. It is optional for implementations



Nadeau and Farrel            Expires October 2006           [Page 32]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        that do not support SONET or SDH labels."

     GROUP gmplsLabelWavebandGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for implementations that
        support Waveband labels. It is optional for implementations that
        do not support Waveband labels."

     OBJECT      gmplsLabelType
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelMplsLabel
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelPortWavelength
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelFreeform
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSonetSdhSignalIndex
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSdhVc
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSdhVcBranch
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSonetSdhBranch
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."




Nadeau and Farrel            Expires October 2006           [Page 33]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     OBJECT      gmplsLabelSonetSdhGroupBranch
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelWavebandId
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelWavebandStart
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelWavebandEnd
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelStorageType
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT       gmplsLabelRowStatus
     SYNTAX       RowStatus { active(1) }
     MIN-ACCESS   read-only
     DESCRIPTION
       "Write access is not required, and active(1) is=20
        the only status that needs to be supported."

   ::=3D { gmplsLabelCompliances 1 }

   gmplsLabelModuleFullCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance statement for agents that support the complete
        GMPLS-LABEL-STD-MIB module.

       The mandatory groups have to be implemented by GMPLS LSRs
       claiming support for this MIB module. This MIB module is,
       however, not mandatory for a working implementation of a GMPLS
       LSR with full MIB support if the GMPLS labels in use can be
       represented within a 32 bit quantity."


     MODULE -- this module



Nadeau and Farrel            Expires October 2006           [Page 34]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




     MANDATORY-GROUPS {
       gmplsLabelTableGroup
     }

   ::=3D { gmplsLabelCompliances 2 }

   gmplsLabelTableGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelIndexNext,
       gmplsLabelType,
       gmplsLabelStorageType,
       gmplsLabelRowStatus
     }

     STATUS  current
     DESCRIPTION
       "Necessary, but not sufficient, set of objects to implement label
        table support. In addition, depending on the type of labels
        supported, the following other groups defined below are=20
        mandatory:

          gmplsLabelWavebandGroup and/or
          gmplsLabelPacketGroup and/or
          gmplsLabelPortWavelengthGroup and/or
          gmplsLabelFreeformGroup and/or
          gmplsLabelSonetSdhGroup."
   ::=3D { gmplsLabelGroups 1 }

   gmplsLabelPacketGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelMplsLabel
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Packet (MPLS) labels."
   ::=3D { gmplsLabelGroups 2 }

   gmplsLabelPortWavelengthGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelPortWavelength
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Port and Wavelength labels."
   ::=3D { gmplsLabelGroups 3 }

   gmplsLabelFreeformGroup OBJECT-GROUP



Nadeau and Farrel            Expires October 2006           [Page 35]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     OBJECTS {
       gmplsLabelFreeform
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Freeform labels."
   ::=3D { gmplsLabelGroups 4 }

   gmplsLabelSonetSdhGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelSonetSdhSignalIndex,
       gmplsLabelSdhVc,
       gmplsLabelSdhVcBranch,
       gmplsLabelSonetSdhBranch,
       gmplsLabelSonetSdhGroupBranch
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement SONET and SDH labels."
   ::=3D { gmplsLabelGroups 5 }

   gmplsLabelWavebandGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelWavebandId,
       gmplsLabelWavebandStart,
       gmplsLabelWavebandEnd
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Waveband labels."
   ::=3D { gmplsLabelGroups 6 }
   END




9. Security Considerations

   It is clear that the MIB modules described in this document in
   association with the MPLS-LSR-STD-MIB [RFC3813] are potentially
   useful for monitoring of GMPLS LSRs. These MIB modules can also be
   used for configuration of certain objects, and anything that can be
   configured can be incorrectly configured, with potentially disastrous
   results.

   There are a number of management objects defined in these MIB modules
   with a MAX-ACCESS clause of read-write and/or read-create. Such
   objects may be considered sensitive or vulnerable in some network



Nadeau and Farrel            Expires October 2006           [Page 36]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   environments. The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations. These are the tables and objects and their
   sensitivity/vulnerability:

   o  the gmplsInterfaceTable, gmplsInSegmentTable, gmplsOutSegmentTable
      and gmplsLabelTable collectively contain objects to provision
      GMPLS interfaces, LSPs and their associated parameters on a Label
      Switching Router (LSR). Unauthorized write access to objects in
      these tables, could result in disruption of traffic on the
      network. This is especially true if an LSP has already been
      established.

   Some of the readable objects in these MIB modules (i.e., objects with
   a MAX-ACCESS other than not-accessible) may be considered sensitive
   or vulnerable in some network environments. It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP. These are the tables and objects and their
   sensitivity/vulnerability:

   o  the gmplsInterfaceTable, gmplsInSegmentTable, gmplsOutSegmentTable
      and gmplsLabelTable collectively show the LSP network topology and
      its capabilities. If an Administrator does not want to reveal this
      information, then these tables should be considered
      sensitive/vulnerable.

   SNMP versions prior to SNMPv3 did not include adequate security. Even
   if the network itself is secure (for example by using IPSec), even
   then, there is no control as to who on the secure network is allowed
   to access and GET/SET (read/change/create/delete) the objects in
   these MIB modules.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security. It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module, is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

10. Acknowledgments




Nadeau and Farrel            Expires October 2006           [Page 37]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   This document is a product of the CCAMP Working Group.

   This document extends [RFC3813]. The authors would like to express
   their gratitude to all those who worked on that earlier MIB document.

   The authors would like to express their thanks to Dan Joyle for his
   careful review and comments on early versions of the Label Table.
   Special thanks to Joan Cucchiara and Len Nieman for their help with
   compilation issues. Tom Petch and Bert Wijnen provided useful input
   in the final stages of review.

   Joan Cucchiara provided a helpful and very thorough MIB Doctor
   review.

11. IANA Considerations

-- (Note to RFC-Editor:)
-- We request that you assign contiguous RFC numbers to the three GMPLS
-- MIB documents.
-- The first number to draft-ietf-ccamp-gmpls-tc-mib, the second to
-- draft-ietf-ccamp-gmpls-lsr-mib, and the third to
-- draft-ietf-ccamp-gmpls-te-mib.
-- (Please remove this note prior to publication.)

   IANA is requested to root MIB objects in the two MIB modules
   contained in this document under the mplsStdMIB subtree.

   In the future, GMPLS related standards track MIB modules should be
   rooted under the mplsStdMIB (sic) subtree. IANA has been requested to
   manage that namespace in the SMI Numbers registry [RFC3811]. New
   assignments can only be made via a Standards Action as specified in
   [RFC2434].

11.1. IANA Considerations for GMPLS-LSR-STD-MIB

   The IANA is requested to assign { mplsStdMIB YYY } to the
   GMPLS-LSR-STD-MIB module specified in this document, and to record
   the assignment in the SMI Numbers registry.
-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note

11.2. IANA Considerations for GMPLS-LABEL-STD-MIB

   The IANA is requested to assign { mplsStdMIB ZZZ } to the
   GMPLS-LABEL-STD-MIB module specified in this document, and to record
   the assignment in the SMI Numbers registry.

-- RFC Editor. Please replace ZZZ above with the OID assigned by IANA



Nadeau and Farrel            Expires October 2006           [Page 38]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



-- and remove this note

12. References

12.1. Normative References

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirements Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]    McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                J., Rose, M., and S. Waldbusser, "Structure of
                Management Information Version 2 (SMIv2)", STD 58, RFC
                2578, April 1999.

   [RFC2579]    McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                J., Rose, M., and S. Waldbusser, "Textual Conventions
                for SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]    McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                J., Rose, M., and S. Waldbusser, "Conformance Statements
                for SMIv2", STD 58, RFC 2580, April 1999.

   [RFC2863]    McCloghrie, K. and F. Kastenholz, "The Interfaces Group
                MIB", RFC 2863, June 2000.

   [RFC3031]    Rosen, E., Viswanathan, A., and R. Callon,
                "Multiprotocol Label Switching Architecture", RFC 3031,
                January 2001.

   [RFC3032]    Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
                Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
                Encoding", RFC 3032, January 2001.

   [RFC3209]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", RFC 3209, December 2001.

   [RFC3289]    Baker, F., Chan, K., and A. Smith, "Management
                Information Base for the Differentiated Services
                Architecture", RFC 3289, May 2002.

   [RFC3443]    Agarwal, P. and Akyol, B., "Time To Live (TTL)
                Processing in Multi-Protocol Label Switching (MPLS)
                Networks", RFC 3443, January 2003.

   [RFC3471]    Berger, L., "Generalized Multi-Protocol Label Switching
                (GMPLS) Signaling Functional Description", RFC 3471,
                January 2003.



Nadeau and Farrel            Expires October 2006           [Page 39]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   [RFC3473]    Berger, L., "Generalized Multi-Protocol Label Switching
                (GMPLS) Signaling Resource ReserVation Protocol-Traffic
                Engineering (RSVP-TE) Extensions", RFC 3473, January
                2003.

   [RFC3811]    Nadeau, T. and J. Cucchiara, "Definition of Textual
                Conventions and for Multiprotocol Label Switching (MPLS)
                Management", RFC 3811, June 2004.

   [RFC3813]    Srinivasan, C., Viswanathan, A., and T.  Nadeau,
                "Multiprotocol Label Switching (MPLS) Label Switching
                (LSR) Router Management Information Base (MIB)", RFC
                3813, June 2004.

   [RFC3945]    Mannie, E., Ed., "Generalized Multiprotocol Label
                Switching (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC3946]    Mannie, E. and D. Papadimitriou, "Generalized Multi-
                Protocol Label Switching (GMPLS) Extensions for
                Synchronous Optical Network (SONET) and Synchronous
                Digital Hierarchy (SDH) Control", RFC 3946, October
                2004.

   [GMPLSTCMIB] Nadeau, T. and A. Farrel, "Definitions of Textual
                Conventions for Multiprotocol Label Switching (MPLS)
                Management", draft-ietf-ccamp-gmpls-tc-mib, work in
                progress.

   [GMPLSTEMIB] Nadeau, T. and A. Farrel, "Generalized Multiprotocol
                Label Switching (GMPLS) Traffic Engineering Management
                Information Base", draft-ietf-ccamp-gmpls-te-mib, work
                in progress.

12.2. Informative References

   [RFC3410]    Case, J., Mundy, R., Partain, D., and B. Stewart,
                "Introduction and Applicability Statements for
                Internet-Standard Management Framework", RFC 3410,
                December 2002.

   [RFC3468]    Andersson, L., and Swallow, G., "The Multiprotocol=20
                Label Switching (MPLS) Working Group decision on=20
                MPLS signaling protocols", RFC 3468, February 2003.

   [RFC3472]    Ashwood-Smith, P. and L. Berger, "Generalized
                Multi-Protocol Label Switching (MPLS) Signaling
                - Constraint-based Routed Label Distribution Protocol



Nadeau and Farrel            Expires October 2006           [Page 40]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



                (CR-LDP) Extensions", RFC 3472, January 2003.

   [RFC3812]    Srinivasan, C., Viswanathan, A., and T. Nadeau,
                "Multiprotocol Label Switching (MPLS) Traffic
                Engineering (TE) Management Information Base (MIB)",
                RFC 3812, June 2004.

13. Contact Information

   Thomas D. Nadeau
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA 01719
   Email: [e-mail]

   Adrian Farrel
   Old Dog Consulting
   Phone: [phone]
   Email: [e-mail]

   Cheenu Srinivasan
   Bloomberg L.P.
   731 Lexington Ave.
   New York, NY 10022
   Phone: [phone]
   Email: [e-mail]

   Tim Hall
   Data Connection Ltd.
   100 Church Street
   Enfield, Middlesex, EN2 6BQ, UK
   Phone: [phone]
   Email: [e-mail]

   Ed Harrison
   Data Connection Ltd.
   100 Church Street
   Enfield, Middlesex, EN2 6BQ, UK
   Phone: [phone]
   Email: [e-mail]











Nadeau and Farrel            Expires October 2006           [Page 41]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006











14. Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   [e-mail].



15. Full Copyright Statement

   Copyright (C) The Internet Society (2006). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




Nadeau and Farrel            Expires October 2006           [Page 42]

--Apple-Mail-19-1045133920
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed




--Apple-Mail-19-1045133920--



Envelope-to: [e-mail]
Delivery-date: Fri, 05 May 2006 19:04:27 +0000
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: multipart/mixed; boundary=Apple-Mail-17-1044836305
Message-Id: <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail], Wijnen Bert <[e-mail]>, "Dan ((E-mail)) Romascanu" <[e-mail]>, Cucchiara Joan <[e-mail]>, Kireeti Kompella <[e-mail]>
From: "Thomas D. Nadeau" <[e-mail]>
Subject: draft-ietf-ccamp-gmpls-lsr-mib-14.txt
Date: Fri, 5 May 2006 15:02:40 -0400
To: [e-mail]

--Apple-Mail-17-1044836305
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


	Please update draft-ietf-ccamp-gmpls-lsr-mib-13.txt
with draft-ietf-ccamp-gmpls-lsr-mib-14.txt and update
the CCAMP WG's web page.

	--Tom


--Apple-Mail-17-1044836305
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	x-unix-mode=0644;
	name="draft-ietf-ccamp-gmpls-lsr-mib-14.txt"
Content-Disposition: attachment;
	filename=draft-ietf-ccamp-gmpls-lsr-mib-14.txt


Network Working Group                              Thomas D. Nadeau, Ed.
Internet Draft                                       Cisco Systems, Inc.
Proposed Status: Standards Track
Expires: September 2006                               Adrian Farrel, Ed.
                                                      Old Dog Consulting

                                                              April 2006

         Generalized Multiprotocol Label Switching (GMPLS)
      Label Switching Router (LSR) Management Information Base

              draft-ietf-ccamp-gmpls-lsr-mib-14.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects to configure and/or
   monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
   Switching Router (LSR).


Table of Contents

   1. Introduction ..................................... 2
   1.1. Migration Strategy ............................. 3



Nadeau and Farrel            Expires October 2006            [Page 1]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   2. Terminology ...................................... 3
   3. The Internet-Standard Management Framework ....... 4
   4. Outline .......................................... 5
   4.1 MIB Modules ..................................... 5
   4.1.1 Summary of the GMPLS-LSR-STD-MIB Module ....... 5
   4.1.2 Summary of the GMPLS-LABEL-STD-MIB Module ..... 5
   4.2. Configuring Statically Provisioned LSPs ........ 6
   5. Bidirectional LSPs ............................... 6
   6. Example of LSP Setup ............................. 7
   7. GMPLS Label Switching Router MIB Definitions .... 11
   8. GMPLS Label MIB Definitions ..................... 22
   9. Security Considerations ......................... 37
   10. Acknowledgments ................................ 38
   11. IANA Considerations ............................ 38
   11.1. IANA Considerations for GMPLS-LSR-STD-MIB .... 38
   11.2. IANA Considerations for GMPLS-LABEL-STD-MIB .. 39
   12. References ..................................... 39
   12.1. Normative References ......................... 39
   12.2. Informative References ....................... 40
   13. Contact Information ............................ 41
   14. Intellectual Property Considerations ........... 42
   15. Full Copyright Statement ....................... 42

1. Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for modeling a
   Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] Label
   Switching Router (LSR).

   Comments should be made directly to the CCAMP mailing list at
   [e-mail].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119,
   reference [RFC2119].

1.1. Migration Strategy

   MPLS LSRs may be modeled and managed using the MPLS-LSR-STD-MIB
   module [RFC3813].

   LSRs may be migrated to be modeled and managed using the MIB modules
   in this document in order to migrate the LSRs to GMPLS support, or to
   take advandtage of additional MIB objects defined in these MIB
   modules that are applicable to MPLS-TE.



Nadeau and Farrel            Expires October 2006            [Page 2]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   The GMPLS LSR MIB module (GMPLS-LSR-STD-MIB) defined in this document
   extends the MPLS-LSR-STD-MIB module [RFC3813] through a series of
   sparse augmentations of the MIB tables. The only additions are for
   support of GMPLS or to support the increased complexity of MPLS and
   GMPLS systems.

   In order to migrate from MPLS-LSR-STD-MIB support to
   GMPLS-LSR-STD-MIB support an implementation needs only to add support
   for the additional tables and objects defined in GMPLS-LSR-STD-MIB.
   The gmplsInterfaceSignalingCaps object allows an implementation to
   use the objects and tables of GMPLS-LSR-STD-MIB without supporting
   the GMPLS protocols.

   The GMPLS Label MIB module (GMPLS-LABEL-STD-MIB) also defined in this
   document allows labels to be configured and examined, and supports
   more varieties of label as appropriate for GMPLS. Labels may be
   referenced using a row pointer from objects within the
   GMPLS-LSR-STD-MIB module. MPLS implementations (MPLS-LSR-STD-MIB) may
   also reference labels held in the GMPLS-LABEL-STD-MIB module through
   the various label pointer objects in the MPLS-LSR-STD-MIB module
   (such as mplsInSegmentLabelPtr), and may do so without implementing
   the GMPLS-LSR-STD-MIB module.

   The companion document modeling and managing GMPLS based traffic
   engineering [GMPLSTEMIB] extends the MPLS-TE-STD-MIB module [RFC3812]
   with the same intentions.

   Textual conventions are defined in [GMPLSTCMIB] which extends the=20
   set of textual conventions originally defined in [RFC3811].

2. Terminology

   This document uses terminology from the document describing the MPLS
   architecture [RFC3031] and the GMPLS architecture [RFC3945].

   A label switched path (LSP) is modeled as a connection consisting of
   one or more incoming segments (in-segments) and/or one or more
   outgoing segments (out-segments) at an LSR. The association or
   interconnection of the in-segments and out-segments is accomplished
   by using a cross-connect. We use the terminology "connection" and
   "LSP" interchangeably where the meaning is clear from the context.

   in-segment     This is analogous to a GMPLS label on an interface.
   out-segment    This is analogous to a GMPLS label on an interface.
   cross-connect  This describes the conceptual connection between a
                  set of in-segments and out-segments. Note that either
                  set may be empty; for example, a cross-connect may



Nadeau and Farrel            Expires October 2006            [Page 3]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



                  connect only out-segments together with no in-segments
                  in the case where an LSP originates on an LSR.

   The terms 'ingress' and 'head-end' (or 'head') are used in this
   document to indicate the signaling source of an LSP. This is
   sometimes also referred to as the 'sender'.

   The terms 'egress' and 'tail-end' (or 'tail') are used in this
   document to indicate the signaling destination of an LSP.

   The term 'upstream' is used in this document to refer to the part of
   an LSP closer to the ingress than the current point of reference.

   The term 'downstream' is used in this document to refer to the part
   of an LSP closer to the egress than the current point of reference.

   The term 'forward' is used in this document to indicate the direction
   of data flow from the ingress toward the egress.

   The term 'reverse' is used in this document to indicate the direction
   of data flow from the egress toward the ingress.

3. The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB. MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI). This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

4. Outline

4.1 MIB Modules

   There are two MIB modules defined in this document.

   The GMPLS-LSR-STD-MIB module contains tables that sparse augment
   tables defined in the MPLS-LSR-STD-MIB module [RFC3813]. This MIB
   module is used in conjunction with the MPLS-LSR-STD-MIB module
   [RFC3813] in systems that support GMPLS.




Nadeau and Farrel            Expires October 2006            [Page 4]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   The GMPLS-LABEL-STD-MIB module contains objects for managing GMPLS
   labels when they cannot be represented using the textual conventions
   of the MPLS-TC-STD-MIB module [RFC3811], or when more detailed access
   to the sub-fields of the labels is required.

4.1.1 Summary of the GMPLS-LSR-STD-MIB Module

   The MIB tables in the GMPLS-LSR-STD-MIB module are as follows.

   - The interface configuration table (gmplsInterfaceTable), which
     sparse augments the mplsInterfaceTable [RFC3813] to enable the
     GMPLS protocol on MPLS-capable interfaces.

   - The in-segment (gmplsInSegmentTable) and out-segment
     (gmplsOutSegmentTable) tables sparse augment mplsInSegmentTable and
     mplsOutSegmentTable [RFC3813] to enable configuration of
     GMPLS-specific parameters for LSP segments at an LSR.

   These tables are described in the subsequent sections.

4.1.2 Summary of the GMPLS-LABEL-STD-MIB Module

   There is one MIB table in the GMPLS-LABEL-STD-MIB module as follows.

   - The gmplsLabelTable allows Generalized
     Labels to be defined and managed in a central location.
     Generalized Labels can be of variable length and have distinct
     bit-by-bit interpretations depending upon how they are defined
     for the specific technology in which they are used. For example,
     labels used for MPLS packet switching are different in length
     and content from labels used in TDM timeslot switching.


4.2. Configuring Statically Provisioned LSPs

   Configuring statically provisioned GMPLS LSPs through an LSR involves
   the following steps:

   - Configuring an interface using the MPLS-LSR-STD-MIB module
     [RFC3813].

   - Enabling GMPLS on GMPLS capable interfaces using the
     GMPLS-LSR-STD-MIB module in this document.

   - Configuring in and out-segments using the MPLS-LSR-STD-MIB module
     [RFC3813].

   - Configuring GMPLS extensions to the in-segments and out-segments



Nadeau and Farrel            Expires October 2006            [Page 5]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     using the GMPLS-LSR-STD-MIB module in this document.

   - Setting up the cross-connect table in the MPLS-LSR-STD-MIB module
     [RFC3813] to associate segments and/or to indicate connection
     origination and termination.

   - Optionally setting up labels in the label table in the
     GMPLS-LABEL-STD-MIB module in this document if the textual
     convention MplsLabel [RFC3811] is not capable of holding the
     required label (for example, if the label requires more than 32
     bits to encode it), or if the operator wishes to disambiguate GMPLS
     label types.

   - Optionally specifying label stack actions in the MPLS-LSR-STD-MIB
     module [RFC3813].

   - Optionally specifying segment traffic parameters in the
     MPLS-LSR-STD-MIB module [RCF3813].

5. Bidirectional LSPs

   The GMPLS-LSR-STD-MIB module supports bidirectional LSPs as required
   for GMPLS. A single value of mplsXCIndex is shared by all of the
   segments for the entire bidirectional LSP. This facilitates a simple
   reference from [RFC3812] and [GMPLSTEMIB], and makes fate-sharing
   more obvious.

   It is, however, important that the direction of segments is
   understood to avoid connecting all in-segments to all out-segments.
   This is achieved by an object in each segment that indicates the
   direction of the segment with respect to data flow.

   A segment that is marked as 'forward' carries data from the 'head' of
   the LSP to the 'tail'. A segment marked as 'reverse' carries data in
   the reverse direction.

   Where an LSP is signaled using a conventional signaling protocol, the
   'head' of the LSP is the source of the signaling (also known as the
   ingress) and the 'tail' is the destination (also known as the
   egress). For manually configured LSPs an arbitrary decision must be
   made about which segments are 'forward' and which 'reverse'. For
   consistency this decision should be made across all LSRs that
   participate in the LSP by assigning 'head' and 'tail' ends to the
   LSP.

6. Example of LSP Setup

   In this section we provide a brief example of using the MIB objects



Nadeau and Farrel            Expires October 2006            [Page 6]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   described in sections 7 and 8 to set up an LSP. While this example is
   not meant to illustrate every nuance of the MIB modules, it is
   intended as an aid to understanding some of the key concepts. It is
   meant to be read after going through the MIB modules themselves. A
   prerequisite is an understanding of the MPLS-LSR-STD-MIB [RFC3813].

   Suppose that one would like to manually create a best-effort,
   bi-directional LSP. Assume that, in the forward direction, the LSP
   enters the LSR via MPLS interface A with ifIndex 12 and exits the LSR
   via MPLS interface B with ifIndex 13. For the reverse direction, we
   assume the LSP enters via interface B and leaves via interface A
   (i.e. the forward and reverse directions use the same bi-directional
   interfaces). Let us also assume that we do not wish to have a label
   stack beneath the top label on the outgoing labeled packets. The
   following example illustrates which rows and corresponding objects
   might be created to accomplish this.

   We must first create rows in the gmplsLabelTable corresponding to the
   labels required for each of the forward and reverse direction in- and
   out-segments. For the purpose of this example the forward and
   reverse labels on each interface will be the same, hence we need to
   create just two rows in the gmplsLabelTable - one for each interface.

   In gmplsLabelTable:
   {
     gmplsLabelInterface           =3D 12,
     gmplsLabelIndex               =3D 1,
     gmplsLabelSubindex            =3D 0,
     gmplsLabelType                =3D gmplsFreeformLabel(3),
     gmplsLabelFreeform            =3D 0x123456789ABCDEF0
     gmplsLabelRowStatus           =3D createAndGo(4)
   }

   In gmplsLabelTable:
   {
     gmplsLabelInterface           =3D 13,
     gmplsLabelIndex               =3D 1,
     gmplsLabelSubindex            =3D 0,
     gmplsLabelType                =3D gmplsFreeformLabel(3),
     gmplsLabelFreeform            =3D 0xFEDCBA9876543210
     gmplsLabelRowStatus           =3D createAndGo(4)
   }

   We must next create the appropriate in-segment and out-segment
   entries. These are done in [RFC3813] using the mplsInSegmentTable and
   mplsOutSegmentTable. Note that we use a row pointer to the two rows
   in the gmplsLabelTable rather than specifying the labels explicitly
   in the in- and out-segment tables. Also note that the row status for



Nadeau and Farrel            Expires October 2006            [Page 7]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   each row is set to createAndWait(5) to allow corresponding entries in
   the gmplsInSegmentTable and gmplsOutSegmentTable to be created.

   For the forward direction.

   In mplsInSegmentTable:
   {
      mplsInSegmentIndex           =3D 0x00000015
      mplsInSegmentLabel           =3D 0, -- incoming label in label =
table
      mplsInSegmentNPop            =3D 1,
      mplsInSegmentInterface       =3D 12, -- incoming interface
      -- RowPointer MUST point to the first accsesible column.
      mplsInSegmentTrafficParamPtr    =3D 0.0,
      mplsInSegmentLabelPtr           =3D gmplsLabelTable (12, 1, 0)
      mplsInSegmentRowStatus          =3D createAndWait(5)
   }

   In mplsOutSegmentTable:
   {
      mplsOutSegmentIndex          =3D 0x00000012,
      mplsOutSegmentInterface      =3D 13, -- outgoing interface
      mplsOutSegmentPushTopLabel   =3D true(1),
      mplsOutSegmentTopLabel       =3D 0, -- outgoing label in label =
table

      -- RowPointer MUST point to the first accessible column.
      mplsOutSegmentTrafficParamPtr   =3D 0.0,
      mplsOutSegmentLabelPtr          =3D gmplsLabelTable (13, 1, 0)
      mplsOutSegmentRowStatus         =3D createAndWait(5)
   }

   For the reverse direction.

   In mplsInSegmentTable:
   {
      mplsInSegmentIndex           =3D 0x00000016

      mplsInSegmentLabel           =3D 0, -- incoming label in label =
table
      mplsInSegmentNPop            =3D 1,
      mplsInSegmentInterface       =3D 13, -- incoming interface

      -- RowPointer MUST point to the first accessible column.
      mplsInSegmentTrafficParamPtr    =3D 0.0,
      mplsInSegmentLabelPtr           =3D gmplsLabelTable (13, 1, 0)

      mplsInSegmentRowStatus          =3D createAndWait(5)
   }

   In mplsOutSegmentTable:



Nadeau and Farrel            Expires October 2006            [Page 8]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   {
      mplsOutSegmentIndex          =3D 0x00000013,
      mplsOutSegmentInterface      =3D 12, -- outgoing interface
      mplsOutSegmentPushTopLabel   =3D true(1),
      mplsOutSegmentTopLabel       =3D 0, -- outgoing label in label =
table

      -- RowPointer MUST point to the first accessible column.
      mplsOutSegmentTrafficParamPtr   =3D 0.0,
      mplsOutSegmentLabelPtr          =3D gmplsLabelTable (12, 1, 0)

      mplsOutSegmentRowStatus         =3D createAndWait(5)
   }

   These table entries are extended by entries in gmplsInSegmentTable
   and gmplsOutSegmentTable. Note that the nature of the 'extends'
   relationship is a sparse augmentation so that the entry in
   gmplsInSegmentTable has the same index values as the entry in
   mplsInSegmentTable. Similarly, the entry in gmplsOutSegmentTable has
   the same index values as the entry in mplsOutSegmentTable.

   First for the forward direction:

   In gmplsInSegmentTable(0x00000015)
   {
     gmplsInSegmentDirection          =3D forward (1)
   }

   In gmplsOutSegmentTable(0x00000012)
   {
     gmplsOutSegmentDirection         =3D forward (1)
   }

   Next for the reverse direction:

   In gmplsInSegmentTable(0x00000016)
   {
     gmplsInSegmentDirection          =3D reverse (2)
   }

   In gmplsOutSegmentTable(0x00000013)
   {
     gmplsOutSegmentDirection         =3D reverse (2)
   }

   Next, two cross-connect entries are created in the mplsXCTable of the
   MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created
   segments together.




Nadeau and Farrel            Expires October 2006            [Page 9]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   In mplsXCTable:
   {
      mplsXCIndex                =3D 0x01,
      mplsXCInSegmentIndex       =3D 0x00000015,
      mplsXCOutSegmentIndex      =3D 0x00000012,
      mplsXCLspId                =3D 0x0102 -- unique ID
      mplsXCLabelStackIndex      =3D 0x00, -- only a single outgoing =
label
      mplsXCRowStatus            =3D createAndGo(4)
   }

   In mplsXCTable:
   {
      mplsXCIndex                =3D 0x02,
      mplsXCInSegmentIndex       =3D 0x00000016,
      mplsXCOutSegmentIndex      =3D 0x00000013,
      mplsXCLspId                =3D 0x0102 -- unique ID
      mplsXCLabelStackIndex      =3D 0x00, -- only a single outgoing =
label
      mplsXCRowStatus            =3D createAndGo(4)
   }

   Finally, the in-segments and out-segments are activated.

   In mplsInSegmentTable(0x00000015):
   {
      mplsInSegmentRowStatus          =3D active(1)
   }
   In mplsInSegmentTable(0x00000016):
   {
      mplsInSegmentRowStatus          =3D active(1)
   }

   In mplsOutSegmentTable(0x00000012):
   {
      mplsOutSegmentRowStatus         =3D active(1)
   }

   In mplsOutSegmentTable(0x00000013):
   {
      mplsOutSegmentRowStatus         =3D active(1)
   }


7. GMPLS Label Switching Router MIB Definitions

   This MIB module makes references to the following documents.
   [RFC2578], [RFC2579], [RFC2580], [GMPLSTCMIB], [RFC3811],
   [RFC2863] and [RFC3813].




Nadeau and Farrel            Expires October 2006           [Page 10]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   GMPLS-LSR-STD-MIB DEFINITIONS ::=3D BEGIN

   IMPORTS
     MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, zeroDotZero
       FROM SNMPv2-SMI                                   -- RFC2578
     MODULE-COMPLIANCE, OBJECT-GROUP
       FROM SNMPv2-CONF                                  -- RFC2580
     RowPointer
       FROM SNMPv2-TC                                    -- RFC2579
     GmplsSegmentDirectionTC
       FROM GMPLS-TC-STD-MIB                             -- GMPLSTCMIB
-- RFC-Editor please resolve the reference above to GMPLSTCMIB
-- using the assigned RFC number and remove this note
     mplsInterfaceIndex, mplsInSegmentIndex, mplsOutSegmentIndex,
     mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup,
     mplsXCGroup, mplsPerfGroup, mplsLsrNotificationGroup
       FROM MPLS-LSR-STD-MIB                             -- RFC3813
     ifGeneralInformationGroup, ifCounterDiscontinuityGroup
       FROM IF-MIB                                       -- RFC2863
     mplsStdMIB
       FROM MPLS-TC-STD-MIB                              -- RFC3811
   ;

   gmplsLsrStdMIB MODULE-IDENTITY
     LAST-UPDATED
       "200604060001Z" -- 06 April 2006 00:00:01 GMT
     ORGANIZATION
       "IETF Common Control And Measurement Plane (CCAMP) Working Group"
     CONTACT-INFO
       "       Thomas D. Nadeau
               Cisco Systems, Inc.
        Email: [e-mail]
               Adrian Farrel
               Old Dog Consulting
        Email: [e-mail]
        Comments about this document should be emailed direct to the
        CCAMP working group mailing list at [e-mail]"

     DESCRIPTION
       "Copyright (C) The Internet Society (2006).  This version of
        this MIB module is part of RFC XXX; see the RFC itself for
        full legal notices.
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

        This MIB module contains managed object definitions for the
        Generalized Multiprotocol (GMPLS) Label Switching Router as
        defined in: Generalized Multi-Protocol Label Switching (GMPLS)



Nadeau and Farrel            Expires October 2006           [Page 11]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        Architecture, Mannie et al., RFC 3945, October 2004."

     REVISION
       "200604060001Z" -- 06 April 2006 00:00:01 GMT
     DESCRIPTION
       "Initial version issued as part of RFC XXX."
     ::=3D { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note

   -- no notifications are currently defined.
   gmplsLsrObjects       OBJECT IDENTIFIER ::=3D { gmplsLsrStdMIB 1 }
   gmplsLsrConformance   OBJECT IDENTIFIER ::=3D { gmplsLsrStdMIB 2 }

   gmplsInterfaceTable OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsInterfaceEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "This table specifies per-interface GMPLS capability and
        associated information. It extends the information in
        mplsInterfaceTable of the MPLS-LSR-STD-MIB through a
        sparse augmentation relationship."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
     ::=3D { gmplsLsrObjects 1 }

   gmplsInterfaceEntry OBJECT-TYPE
     SYNTAX        GmplsInterfaceEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "A conceptual row in this table is created automatically by an
        LSR for each interface that is both capable of supporting
        GMPLS and that is configured to support GMPLS. Note that
        support of GMPLS is not limited to control plane signaling,
        but may include data-plane only function configured through
        SNMP SET commands performed on this MIB module.

        A conceptual row in this table may also be created via SNMP
        SET commands or automatically by the LSR to supplement a
        conceptual row in the mplsInterfaceTable where the interface
        is not capable of GMPLS but where the other objects carried




Nadeau and Farrel            Expires October 2006           [Page 12]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        in this row provide useful additional information for an
        MPLS interface.

        A conceptual row in this table will exist if and only if a
        corresponding entry in mplsInterfaceTable exists, and a
        corresponding entry in ifTable exists with ifType =3D mpls(166).
        If the associated entry in ifTable is operationally disabled
        (thus removing the GMPLS capabilities on the interface) or the
        entry in mplsInterfaceTable is deleted, the corresponding entry
        in this table MUST be deleted shortly thereafter.

        The indexes are the same as for mplsInterfaceTable. Thus, the
        entry with index 0 represents the per-platform label space and
        contains parameters that apply to all interfaces that
        participate in the per-platform label space."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
     INDEX { mplsInterfaceIndex }
   ::=3D { gmplsInterfaceTable 1 }

   GmplsInterfaceEntry ::=3D SEQUENCE {
     gmplsInterfaceSignalingCaps      BITS,
     gmplsInterfaceRsvpHelloPeriod    Unsigned32
   }

   gmplsInterfaceSignalingCaps OBJECT-TYPE
     SYNTAX  BITS {
       unknown (0),
       rsvpGmpls (1),
       crldpGmpls (2), -- note the use of CR-LDP is deprecated
       otherGmpls (3)
     }
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Defines the signaling capabilities on this interface. Multiple
        bits may legitimately be set at once, but if 'unknown' is set
        then no other bit may be set. Setting no bits implies that GMPLS
        signaling cannot be performed on this interface and all LSPs
        must be manually provisioned or that this table entry is only
        present to supplement an entry in the mplsInterfaceTable by
        providing the information carried in other objects in this row."
     REFERENCE
       "1. Generalized MPLS Signaling - CR-LDP Extensions, RFC 3472.
        2. The Multiprotocol Label Switching (MPLS) Working Group
           decision on MPLS signaling protocols, RFC 3468.
        3. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473.



Nadeau and Farrel            Expires October 2006           [Page 13]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        "
     DEFVAL { { rsvpGmpls } }
   ::=3D { gmplsInterfaceEntry 1 }

   gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE
     SYNTAX       Unsigned32
     UNITS        "milliseconds"
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Period, in milliseconds, between sending RSVP Hello messages on
        this interface. A value of 0 indicates that no Hello messages
        should be sent on this interface.

        This object is only valid if gmplsInterfaceSignalingCaps has no
        bits set or includes the rsvpGmpls bit."
     REFERENCE
       "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209,
           section 5.
        2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473,
           section 9.3."
     DEFVAL { 3000 }
   ::=3D { gmplsInterfaceEntry 2 }

   gmplsInSegmentTable  OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsInSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "This table sparse augments the mplsInSegmentTable of the
        MPLS-LSR-STD-MIB to provide GMPLS-specific information about
        incoming segments to an LSR."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
   ::=3D { gmplsLsrObjects 2 }

   gmplsInSegmentEntry  OBJECT-TYPE
     SYNTAX        GmplsInSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "An entry in this table extends the representation of an incoming
        segment represented by an entry in mplsInSegmentTable in the
        MPLS-LSR-STD-MIB through a sparse augmentation. An entry can be
        created by a network administrator via SNMP SET commands, or in
        response to signaling protocol events.




Nadeau and Farrel            Expires October 2006           [Page 14]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        Note that the storage type for this entry is given by the value
        of mplsInSegmentStorageType in the corresponding entry of the
        mplsInSegmentTable."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."

     INDEX { mplsInSegmentIndex }
   ::=3D { gmplsInSegmentTable 1 }

   GmplsInSegmentEntry ::=3D SEQUENCE {
     gmplsInSegmentDirection        GmplsSegmentDirectionTC,
     gmplsInSegmentExtraParamsPtr   RowPointer
   }

   gmplsInSegmentDirection OBJECT-TYPE
     SYNTAX        GmplsSegmentDirectionTC
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This object indicates the direction of data flow on this
        segment. This object cannot be modified if
        mplsInSegmentRowStatus for the corresponding entry in the
        mplsInSegmentTable is active(1)."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
     DEFVAL        { forward }
   ::=3D { gmplsInSegmentEntry 1 }

   gmplsInSegmentExtraParamsPtr  OBJECT-TYPE
     SYNTAX       RowPointer
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Some Tunnels will run over transports that can usefully support
        technology-specific additional parameters (for example, SONET
        resource usage). Such can be supplied from an external table and
        referenced from here. A value of zeroDotzero in this attribute
        indicates that there is no such additional information."
     DEFVAL      { zeroDotZero }
     ::=3D { gmplsInSegmentEntry 2 }

   gmplsOutSegmentTable  OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsOutSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION



Nadeau and Farrel            Expires October 2006           [Page 15]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



       "This table sparse augments the mplsOutSegmentTable of the
        MPLS-LSR-STD-MIB to provide GMPLS-specific information about
        outgoing segments from an LSR."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
   ::=3D { gmplsLsrObjects 3 }

   gmplsOutSegmentEntry  OBJECT-TYPE
     SYNTAX        GmplsOutSegmentEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "An entry in this table extends the representation of an outgoing
        segment represented by an entry in mplsOutSegmentTable of the
        MPLS-LSR-STD-MIB through a sparse augmentation. An entry can be
        created by a network administrator via SNMP SET commands, or in
        response to signaling protocol events.

        Note that the storage type for this entry is given by the value
        of mplsOutSegmentStorageType in the corresponding entry of the
        mplsOutSegmentTable."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
     INDEX  { mplsOutSegmentIndex }
   ::=3D { gmplsOutSegmentTable 1 }

   GmplsOutSegmentEntry ::=3D SEQUENCE {
     gmplsOutSegmentDirection       GmplsSegmentDirectionTC,
     gmplsOutSegmentTTLDecrement    Unsigned32,
     gmplsOutSegmentExtraParamsPtr  RowPointer
   }

   gmplsOutSegmentDirection OBJECT-TYPE
     SYNTAX        GmplsSegmentDirectionTC
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This object indicates the direction of data flow on this
        segment. This object cannot be modified if
        mplsOutSegmentRowStatus for the corresponding entry in the
        mplsOutSegmentTable is active(1)."
     REFERENCE
       "1. Multiprotocol Label Switching (MPLS) Label Switching (LSR)
           Router Management Information Base (MIB), RFC 3813."
     DEFVAL  { forward }
   ::=3D { gmplsOutSegmentEntry 1 }



Nadeau and Farrel            Expires October 2006           [Page 16]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   gmplsOutSegmentTTLDecrement OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This object indicates the amount by which to decrement the TTL
        of any payload packets forwarded on this segment if per-hop
        decrementing is being done.

        A value of zero indicates that no decrement should be made or
        that per-hop decrementing is not in use.

        See the gmplsTunnelTTLDecrement object in the gmplsTunnelTable
        of GMPLS-TE-STD-MIB for a value by which to decrement the TTL
        for the whole of a tunnel.

        This object cannot be modified if mplsOutSegmentRowStatus for
        the associated entry in the mplsOutSegmentTable is active(1)."
     REFERENCE
       "1. Time To Live (TTL) Processing in Multi-Protocol Label
           Switching (MPLS) Networks, RFC 3443.
        2. Generalized Multiprotocol Label Switching (GMPLS) Traffic
           Engineering Management Information Base, RFC XXX."
-- RFC Editor. Please insert the correct RFC number and remove this note
     DEFVAL  { 0 }
   ::=3D { gmplsOutSegmentEntry 2 }

   gmplsOutSegmentExtraParamsPtr  OBJECT-TYPE
     SYNTAX       RowPointer
     MAX-ACCESS   read-create
     STATUS       current
     DESCRIPTION
       "Some Tunnels will run over transports that can usefully support
        technology-specific additional parameters (for example, SONET
        resource usage). Such can be supplied from an external table and
        referenced from here.

        A value of zeroDotzero in this attribute indicates that there is
        no such additional information."
     DEFVAL      { zeroDotZero }
     ::=3D { gmplsOutSegmentEntry 3 }

   gmplsLsrGroups
     OBJECT IDENTIFIER ::=3D { gmplsLsrConformance 1 }

   gmplsLsrCompliances
     OBJECT IDENTIFIER ::=3D { gmplsLsrConformance 2 }



Nadeau and Farrel            Expires October 2006           [Page 17]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   -- Compliance requirement for fully compliant implementations.

   gmplsLsrModuleFullCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance statement for agents that provide full support for
        GMPLS-LSR-STD-MIB.

         The mandatory group has to be implemented by all LSRs that
         originate, terminate or act as transit for TE-LSPs/tunnels.
         In addition, depending on the type of tunnels supported, other
         groups become mandatory as explained below."

     MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.

     MANDATORY-GROUPS {
       ifGeneralInformationGroup,
       ifCounterDiscontinuityGroup
     }

     MODULE MPLS-LSR-STD-MIB -- The MPLS-LSR-STD-MIB, RFC3813

     MANDATORY-GROUPS {
       mplsInterfaceGroup,
       mplsInSegmentGroup,
       mplsOutSegmentGroup,
       mplsXCGroup,
       mplsPerfGroup,
       mplsLsrNotificationGroup
     }

     MODULE -- this module

     MANDATORY-GROUPS    {
       gmplsInterfaceGroup,
       gmplsInSegmentGroup,
       gmplsOutSegmentGroup
     }

     OBJECT      gmplsInSegmentDirection
     SYNTAX      GmplsSegmentDirectionTC
     MIN-ACCESS  read-only
     DESCRIPTION
       "The only valid value for unidrectional LSPs is forward(1)."

     OBJECT      gmplsOutSegmentDirection
     SYNTAX      GmplsSegmentDirectionTC



Nadeau and Farrel            Expires October 2006           [Page 18]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     MIN-ACCESS  read-only
     DESCRIPTION
       "The only valid value for unidrectional LSPs is forward(1)."

     OBJECT      gmplsOutSegmentTTLDecrement
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsInSegmentExtraParamsPtr
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsOutSegmentExtraParamsPtr
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   ::=3D { gmplsLsrCompliances 1 }

   -- Compliance requirement for implementations that provide read-only
   -- access.

   gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance requirement for implementations that only provide
        read-only support for GMPLS-LSR-STD-MIB. Such devices can then
        be monitored but cannot be configured using this MIB module."

     MODULE IF-MIB -- The interfaces Group MIB, RFC 2863

     MANDATORY-GROUPS {
       ifGeneralInformationGroup,
       ifCounterDiscontinuityGroup
     }

     MODULE MPLS-LSR-STD-MIB

     MANDATORY-GROUPS {
       mplsInterfaceGroup,
       mplsInSegmentGroup,
       mplsOutSegmentGroup,
       mplsXCGroup,
       mplsPerfGroup
     }




Nadeau and Farrel            Expires October 2006           [Page 19]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     MODULE -- this module

     MANDATORY-GROUPS {
       gmplsInterfaceGroup,
       gmplsInSegmentGroup,
       gmplsOutSegmentGroup
     }

     OBJECT      gmplsInterfaceSignalingCaps
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsInterfaceRsvpHelloPeriod
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsInSegmentDirection
     SYNTAX      GmplsSegmentDirectionTC
     MIN-ACCESS  read-only
     DESCRIPTION
       "The only valid value for unidrectional LSPs is forward(1)."

     OBJECT      gmplsInSegmentExtraParamsPtr
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsOutSegmentDirection
     MIN-ACCESS  read-only
     DESCRIPTION
       "The only valid value for unidrectional LSPs is forward(1)."

     OBJECT      gmplsOutSegmentTTLDecrement
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsOutSegmentExtraParamsPtr
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

   ::=3D { gmplsLsrCompliances 2 }

   gmplsInterfaceGroup OBJECT-GROUP
     OBJECTS {



Nadeau and Farrel            Expires October 2006           [Page 20]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



       gmplsInterfaceSignalingCaps,
       gmplsInterfaceRsvpHelloPeriod
     }
     STATUS  current
     DESCRIPTION
      "Collection of objects which provide additional=20
       information for an MPLS interface and are needed=20
       for GMPLS interface configuration and performance=20
       information."
   ::=3D { gmplsLsrGroups 1 }

   gmplsInSegmentGroup  OBJECT-GROUP
     OBJECTS {
       gmplsInSegmentDirection,
       gmplsInSegmentExtraParamsPtr
     }
     STATUS  current
     DESCRIPTION
       "Collection of objects which provide additional=20
        information for an MPLS in-segment and are needed=20
        for GMPLS in-segment configuration and performance=20
        information."
   ::=3D { gmplsLsrGroups 2 }

   gmplsOutSegmentGroup  OBJECT-GROUP
     OBJECTS {
       gmplsOutSegmentDirection,
       gmplsOutSegmentTTLDecrement,
       gmplsOutSegmentExtraParamsPtr
     }
     STATUS  current
     DESCRIPTION
       "Collection of objects which provide additional=20
        information for an MPLS out-segment and are needed=20
        for GMPLS out-segment configuration and performance=20
        information."
   ::=3D { gmplsLsrGroups 3 }
   END


8. GMPLS Label MIB Definitions

   This MIB module makes references to the following documents.
   [RFC2578], [RFC2579], [RFC2580], [GMPLSTCMIB], [RFC3811],
   [RFC2863], [RFC3289], [RFC3813], and [RFC3471].
  =20

   GMPLS-LABEL-STD-MIB DEFINITIONS ::=3D BEGIN



Nadeau and Farrel            Expires October 2006           [Page 21]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   IMPORTS
     MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Integer32
       FROM SNMPv2-SMI                                   -- RFC2578
     MODULE-COMPLIANCE, OBJECT-GROUP
       FROM SNMPv2-CONF                                  -- RFC2580
     RowStatus, StorageType
       FROM SNMPv2-TC                                    -- RFC2579
     InterfaceIndexOrZero
       FROM IF-MIB                                       -- RFC2863
     IndexIntegerNextFree
       FROM DIFFSERV-MIB                                 -- RFC3289
     MplsLabel, mplsStdMIB
       FROM MPLS-TC-STD-MIB                              -- RFC3811
     GmplsLabelTypeTC, GmplsFreeformLabelTC
       FROM GMPLS-TC-STD-MIB                             -- GMPLSTCMIB
-- RFC-Editor. Please resolve the reference above to GMPLSTCMIB=20
-- to use the assigned RFC number and remove this note
   ;

   gmplsLabelStdMIB MODULE-IDENTITY
     LAST-UPDATED
       "200604060001Z" -- 06 April 2006 00:00:01 GMT
     ORGANIZATION
       "IETF Common Control And Measurement Plane (CCAMP) Working Group"
     CONTACT-INFO
       "       Thomas D. Nadeau
               Cisco Systems, Inc.
        Email: [e-mail]

               Adrian Farrel
               Old Dog Consulting
        Email: [e-mail]

        Comments about this document should be emailed direct to the
        CCAMP working group mailing list at [e-mail]"

     DESCRIPTION
       "Copyright (C) The Internet Society (2006).  This version of
        this MIB module is part of RFC XXX; see the RFC itself for
        full legal notices.
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

        This MIB module contains managed object definitions for labels
        within GMPLS systems as defined in:
        Generalized Multi-Protocol Label Switching (GMPLS) Signaling
        Functional Description, Berger, L. (Editor), RFC 3471,



Nadeau and Farrel            Expires October 2006           [Page 22]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        January 2003."
     REVISION
       "200604060001Z" -- 06 April 2006 00:00:01 GMT
     DESCRIPTION
       "Initial version issued as part of RFC XXX."
     ::=3D { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace ZZZ above with the OID assigned by IANA
-- and remove this note

   -- no notifications are currently defined.

   gmplsLabelObjects        OBJECT IDENTIFIER ::=3D { gmplsLabelStdMIB 1 =
}
   gmplsLabelConformance    OBJECT IDENTIFIER ::=3D { gmplsLabelStdMIB 2 =
}

   gmplsLabelIndexNext OBJECT-TYPE
     SYNTAX        IndexIntegerNextFree
     MAX-ACCESS    read-only
     STATUS        current
     DESCRIPTION
         "This object contains an unused value for gmplsLabelIndex,
          or a zero to indicate that no unused value exists or is
          available.

          A management application wishing to create a row in the
          gmplsLabelTable may read this object and then attempt to
          create a row in the table. If row creation fails (because
          another application has already created a row with the
          supplied index) the management application should read this
          object again to get a new index value.

          When a row is created in the gmplsLabelTable with the
          gmplsLabelIndex value held by this object, an implementation
          MUST change the value in this object."
     ::=3D { gmplsLabelObjects 1 }

   gmplsLabelTable OBJECT-TYPE
     SYNTAX        SEQUENCE OF GmplsLabelEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "Table of GMPLS Labels. This table allows the representation
        of the more complex label forms required for GMPLS which cannot
        be held within the textual convention MplsLabel. That is labels
        that cannot be encoded within 32 bits. It is, nevertheless also
        capable of holding 32 bit labels or regular MPLS labels if



Nadeau and Farrel            Expires October 2006           [Page 23]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        desired.

        Each entry in this table represents an individual GMPLS label
        value. Labels in the tables in other MIB modules may be referred
        to using a row pointer into this table. The indexing of this=20
        table provides for arbitrary indexing and also for=20
        concatenation of labels.

        For an example of label concatenation see RFC3945 section 7.1.
        In essence, a GMPLS label may be composite in order to identify
        a set of resources in the data plane. Practical examples are
        timeslots and wavelength sets (which are not contiguous like
        wavebands).

        The indexing mechanism allows multiple entries in this table to
        be seen as a sequence of labels that should be concatenated.
        Ordering is potentially very sensitive for concatenation."
      REFERENCE
        "1. Generalized Multiprotocol Label Switching (GMPLS)
            Architecture, RFC 3945, section 7.1,"
   ::=3D { gmplsLabelObjects 2 }

   gmplsLabelEntry OBJECT-TYPE
     SYNTAX        GmplsLabelEntry
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "An entry in this table represents a single label value. There
        are three indexes into the table.
        -  The interface index may be helpful to distinguish which
           labels are in use on which interfaces or to handle cases
           where there are a very large number of labels in use in the
           system. When label representation is desired to apply to the
           whole system or when it is not important to distinguish
           labels by their interfaces, this index MAY be set to zero.

        -  The label index provides a way of identifying the label.
        -  The label sub-index is only used for concatenated labels. It
           identifies each component label. When non-concatenated labels
           are used, this index SHOULD be set to zero.
        A storage type object is supplied to control the storage type
        for each entry, but implementations should note that the storage
        type of conceptual rows in other tables that include row
        pointers to an entry in this table SHOULD dictate the storage
        type of the rows in this table where the row in the other table
        is more persistent."

     INDEX {



Nadeau and Farrel            Expires October 2006           [Page 24]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



       gmplsLabelInterface,
       gmplsLabelIndex,
       gmplsLabelSubindex }
   ::=3D { gmplsLabelTable 1 }

   GmplsLabelEntry ::=3D SEQUENCE {
     gmplsLabelInterface           InterfaceIndexOrZero,
     gmplsLabelIndex               Unsigned32,
     gmplsLabelSubindex            Unsigned32,
     gmplsLabelType                GmplsLabelTypeTC,
     gmplsLabelMplsLabel           MplsLabel,
     gmplsLabelPortWavelength      Unsigned32,
     gmplsLabelFreeform            GmplsFreeformLabelTC,
     gmplsLabelSonetSdhSignalIndex Integer32,
     gmplsLabelSdhVc               Integer32,
     gmplsLabelSdhVcBranch         Integer32,
     gmplsLabelSonetSdhBranch      Integer32,
     gmplsLabelSonetSdhGroupBranch Integer32,
     gmplsLabelWavebandId          Unsigned32,
     gmplsLabelWavebandStart       Unsigned32,
     gmplsLabelWavebandEnd         Unsigned32,
     gmplsLabelStorageType         StorageType,
     gmplsLabelRowStatus           RowStatus
   }

   gmplsLabelInterface OBJECT-TYPE
     SYNTAX        InterfaceIndexOrZero
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "The interface on which this label is used. If this object is set
        to zero, the label MUST have applicability across the
        whole system and is not limited to a single interface."
   ::=3D { gmplsLabelEntry 1 }

   gmplsLabelIndex OBJECT-TYPE
     SYNTAX        Unsigned32 (0..4294967295)
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "An arbitrary index into the table to identify a label.

        Note that implementations that are representing 32 bit labels
        within this table MAY choose to align this index with the value
        of the label and this may result in the use of the value zero
        since it represents a valid label value.  Such implementation=20
        should be aware of the implications of sparsely populated=20
        tables.



Nadeau and Farrel            Expires October 2006           [Page 25]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




        A management application may read the gmplsLabelIndexNext
        object to find a suitable value for this object."
   ::=3D { gmplsLabelEntry 2 }

   gmplsLabelSubindex OBJECT-TYPE
     SYNTAX        Unsigned32 (0..4294967295)
     MAX-ACCESS    not-accessible
     STATUS        current
     DESCRIPTION
       "In conjunction with gmplsLabelInterface and gmplsLabelIndex,
        this object uniquely identifies this row. This sub-index allows
        a single GMPLS label to be defined as a concatenation of labels.
        This is particularly useful in TDM.

        The ordering of sub-labels is strict with the sub-label with
        lowest gmplsLabelSubindex appearing first. Note that all
        sub-labels of a single GMPLS label must share the same
        gmplsLabelInterface and gmplsLabelIndex values. For labels that
        are not composed of concatenated sub-labels, this value SHOULD
        be set to zero."
   ::=3D { gmplsLabelEntry 3 }

   gmplsLabelType OBJECT-TYPE
     SYNTAX        GmplsLabelTypeTC
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "Identifies the type of this label. Note that this object does
        not determine whether MPLS or GMPLS signaling is in use: a value
        of gmplsMplsLabel (1) denotes that an MPLS packet label is
        present in the gmplsLabelMplsLabel object and encoded using the
        MplsLabel textual convention (may be a 20-bit MPLS label, a 10-
        or 23-bit Frame Relay label, or an ATM label), but does not
        describe whether this is signaled using MPLS or GMPLS.

        The value of this object helps determine which of the following
        objects are valid. This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
      REFERENCE
        "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
            Functional Description, RFC 3471, section 3."
   ::=3D { gmplsLabelEntry 4 }

   gmplsLabelMplsLabel OBJECT-TYPE
     SYNTAX         MplsLabel
     MAX-ACCESS     read-create
     STATUS         current



Nadeau and Farrel            Expires October 2006           [Page 26]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     DESCRIPTION
       "The value of an MPLS label (that is a packet label) if this
        table is used to store it. This may be used in MPLS systems even

        though the label values can be adequately stored in the MPLS MIB
        modules (MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB). Further, in
        mixed MPLS and GMPLS systems it may be advantageous to store all
        labels in a single label table. Lastly, in GMPLS systems where
        packet labels are used (that is in systems that use GMPLS
        signaling and GMPLS labels for packet switching) it may be
        desirable to use this table.

        This object is only valid if gmplsLabelType is set
        to gmplsMplsLabel (1). This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. MPLS Label Stack Encoding, RFC 3032."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 5 }

   gmplsLabelPortWavelength OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The value of a Port or Wavelength Label when carried as a
        Generalized Label. Only valid if gmplsLabelType is set to
        gmplsPortWavelengthLabel(2). This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
           Functional Description, RFC 3471, section 3.2.1.1."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 6 }

   gmplsLabelFreeform OBJECT-TYPE
     SYNTAX        GmplsFreeformLabelTC
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The value of a freeform Generalized Label that does not conform
        to one of the standardized label encoding or that an
        implementation chooses to represent as an octet string without
        further decoding. Only valid if gmplsLabelType is set to
        gmplsFreeformLabel(3). This object cannot be modified
        if gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling



Nadeau and Farrel            Expires October 2006           [Page 27]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



           Functional Description, RFC 3471, section 3.2."
     DEFVAL { '00'h }
   ::=3D { gmplsLabelEntry 7 }

   gmplsLabelSonetSdhSignalIndex OBJECT-TYPE
     SYNTAX        Integer32 (0..4095)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The Signal Index value (S) of a SONET or SDH Generalized Label.
        Zero indicates that this field is not significant. Only valid if
        gmplsLabelType is set to gmplsSonetLabel(4) or gmplsSdhLabel(5).
        This object cannot be modified if gmplsLabelRowStatus is
        active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
           for Synchronous Optical Network (SONET) and Synchronous
           Digital Hierarchy (SDH) Control, RFC 3946, section 3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 8 }

   gmplsLabelSdhVc OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The VC Indicator (U) of an SDH Generalized Label. Zero indicates
        that this field is non-significant.
        Only valid if gmplsLabelType is set to gmplsSdhLabel(5).
        This object cannot be modified if gmplsLabelRowStatus is
        active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
           for Synchronous Optical Network (SONET) and Synchronous
           Digital Hierarchy (SDH) Control, RFC 3946, section 3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 9 }

   gmplsLabelSdhVcBranch OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The VC Branch Indicator (K) of an SDH Generalized Label. Zero
        indicates that this field is non-significant.
        Only valid if gmplsLabelType is set to gmplsSdhLabel(5). This
        object cannot be modified if gmplsLabelRowStatus is active(1)."
     REFERENCE



Nadeau and Farrel            Expires October 2006           [Page 28]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



       "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
           for Synchronous Optical Network (SONET) and Synchronous
           Digital Hierarchy (SDH) Control, RFC 3946, section 3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 10 }

   gmplsLabelSonetSdhBranch OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The Branch Indicator (L) of a SONET or SDH Generalized Label.
        Zero indicates that this field is non-significant.
        Only valid gmplsLabelType is set to gmplsSonetLabel(4) or
        gmplsSdhLabel(5). This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
           for Synchronous Optical Network (SONET) and Synchronous
           Digital Hierarchy (SDH) Control, RFC 3946, section 3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 11 }

   gmplsLabelSonetSdhGroupBranch OBJECT-TYPE
     SYNTAX        Integer32 (0..15)
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The Group Branch Indicator (M) of a SONET or SDH Generalized
        Label.
        Zero indicates that this field is non-significant.
        Only valid if gmplsLabelType is set to gmplsSonetLabel(4) or
        gmplsSdhLabel(5). This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Extensions
           for Synchronous Optical Network (SONET) and Synchronous
           Digital Hierarchy (SDH) Control, RFC 3946, section 3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 12 }

   gmplsLabelWavebandId OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The waveband identifier component of a waveband label. Only
        valid if gmplsLabelType is set to gmplsWavebandLabel(6). This



Nadeau and Farrel            Expires October 2006           [Page 29]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        object cannot be modified if gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
           Functional Description, RFC 3471, section 3.3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 13 }

   gmplsLabelWavebandStart OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The starting label component of a waveband label.
        Only valid if gmplsLabelType is set to gmplsWavebandLabel(6).
        This object cannot be modified if
        gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
           Functional Description, RFC 3471, section 3.3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 14 }

   gmplsLabelWavebandEnd OBJECT-TYPE
     SYNTAX        Unsigned32
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The end label component of a waveband label. Only valid if
        gmplsLabelType is set to gmplsWavebandLabel(6). This object
        cannot be modified if gmplsLabelRowStatus is active(1)."
     REFERENCE
       "1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling
           Functional Description, RFC 3471, section 3.3."
     DEFVAL { 0 }
   ::=3D { gmplsLabelEntry 15 }

   gmplsLabelStorageType OBJECT-TYPE
     SYNTAX        StorageType
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This variable indicates the storage type for this object. The
        agent MUST ensure that this object's value remains consistent
        with the storage type of any rows in other tables that contain
        pointers to this row. In particular, the storage type of this
        row must be at least as permanent as that of any row that point
        to it.




Nadeau and Farrel            Expires October 2006           [Page 30]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        Conceptual rows having the value 'permanent' need not
        allow write-access to any columnar objects in the row."
     REFERENCE
       "1. Textual Conventions for SMIv2, STD 58, RFC 2579, section 2."
     DEFVAL { volatile }
   ::=3D { gmplsLabelEntry 16 }


   gmplsLabelRowStatus OBJECT-TYPE
     SYNTAX        RowStatus
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "This variable is used to create, modify, and/or delete a row in
        this table. When a row in this table has a row in the active(1)
        state, no objects in this row can be modified except the
        gmplsLabelRowStatus and gmplsLabelStorageType.

        The gmplsLabelType object does not have a default and must be
        set before a row can become active. The corresponding label
        objects (dependent on the value of gmplsLabelType) should also
        be set unless they happen to need to use the specified default
        values as follows:

        gmplsLabelType setting             objects to be set
        --------------------------------------------------------------
        gmplsMplsLabel(1)                  gmplsLabelMplsLabel

        gmplsPortWavelengthLabel(2)        gmplsLabelPortWavelength

        gmplsFreeformLabel(3)              gmplsLabelFreeform

        gmplsSonetLabel(4)                 gmplsLabelSonetSdhSignalIndex
                                           gmplsLabelSdhVc
                                           gmplsLabelSdhVcBranch
                                           gmplsLabelSonetSdhBranch
                                           gmplsLabelSonetSdhGroupBranch

        gmplsSdhLabel(5)                   gmplsLabelSonetSdhSignalIndex
                                           gmplsLabelSdhVc
                                           gmplsLabelSdhVcBranch
                                           gmplsLabelSonetSdhBranch
                                           gmplsLabelSonetSdhGroupBranch

        gmplsWavebandLabel(6)              gmplsLabelWavebandId
                                           gmplsLabelWavebandStart
                                           gmplsLabelWavebandEnd"
   ::=3D { gmplsLabelEntry 17 }



Nadeau and Farrel            Expires October 2006           [Page 31]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   gmplsLabelGroups
     OBJECT IDENTIFIER ::=3D { gmplsLabelConformance 1 }

   gmplsLabelCompliances
     OBJECT IDENTIFIER ::=3D { gmplsLabelConformance 2 }

   gmplsLabelModuleReadOnlyCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance requirement for implementations that only provide
        read-only support for GMPLS-LABEL-STD-MIB. Such devices can then
        be monitored but cannot be configured using this MIB module."

     MODULE -- this module

     -- The mandatory groups have to be implemented by LSRs claiming
     -- support for this MIB module. This MIB module is, however, not
     -- mandatory for a working implementation of a GMPLS LSR with full
     -- MIB support if the GMPLS labels in use can be represented within
     -- a 32 bit quantity.

     MANDATORY-GROUPS {
       gmplsLabelTableGroup
     }

     GROUP gmplsLabelPacketGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for implementations that
        support packet labels. It is optional for implementations that
        do not support packet labels."

     GROUP gmplsLabelPortWavelengthGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for implementations that
        support port and wavelength labels. It is optional for
        implementations that do not support wavelength labels."

     GROUP gmplsLabelFreeformGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for implementations that
        support freeform labels. It is optional for implementations that
        do not support freeform labels."

     GROUP gmplsLabelSonetSdhGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for implementations that
        support SONET or SDH labels. It is optional for implementations



Nadeau and Farrel            Expires October 2006           [Page 32]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



        that do not support SONET or SDH labels."

     GROUP gmplsLabelWavebandGroup
     DESCRIPTION
       "This group extends gmplsLabelTableGroup for implementations that
        support Waveband labels. It is optional for implementations that
        do not support Waveband labels."

     OBJECT      gmplsLabelType
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelMplsLabel
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelPortWavelength
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelFreeform
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSonetSdhSignalIndex
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSdhVc
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSdhVcBranch
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelSonetSdhBranch
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."




Nadeau and Farrel            Expires October 2006           [Page 33]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     OBJECT      gmplsLabelSonetSdhGroupBranch
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelWavebandId
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelWavebandStart
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelWavebandEnd
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT      gmplsLabelStorageType
     MIN-ACCESS  read-only
     DESCRIPTION
       "Write access is not required."

     OBJECT       gmplsLabelRowStatus
     SYNTAX       RowStatus { active(1) }
     MIN-ACCESS   read-only
     DESCRIPTION
       "Write access is not required, and active(1) is=20
        the only status that needs to be supported."

   ::=3D { gmplsLabelCompliances 1 }

   gmplsLabelModuleFullCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance statement for agents that support the complete
        GMPLS-LABEL-STD-MIB module.

       The mandatory groups have to be implemented by GMPLS LSRs
       claiming support for this MIB module. This MIB module is,
       however, not mandatory for a working implementation of a GMPLS
       LSR with full MIB support if the GMPLS labels in use can be
       represented within a 32 bit quantity."


     MODULE -- this module



Nadeau and Farrel            Expires October 2006           [Page 34]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




     MANDATORY-GROUPS {
       gmplsLabelTableGroup
     }

   ::=3D { gmplsLabelCompliances 2 }

   gmplsLabelTableGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelIndexNext,
       gmplsLabelType,
       gmplsLabelStorageType,
       gmplsLabelRowStatus
     }

     STATUS  current
     DESCRIPTION
       "Necessary, but not sufficient, set of objects to implement label
        table support. In addition, depending on the type of labels
        supported, the following other groups defined below are=20
        mandatory:

          gmplsLabelWavebandGroup and/or
          gmplsLabelPacketGroup and/or
          gmplsLabelPortWavelengthGroup and/or
          gmplsLabelFreeformGroup and/or
          gmplsLabelSonetSdhGroup."
   ::=3D { gmplsLabelGroups 1 }

   gmplsLabelPacketGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelMplsLabel
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Packet (MPLS) labels."
   ::=3D { gmplsLabelGroups 2 }

   gmplsLabelPortWavelengthGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelPortWavelength
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Port and Wavelength labels."
   ::=3D { gmplsLabelGroups 3 }

   gmplsLabelFreeformGroup OBJECT-GROUP



Nadeau and Farrel            Expires October 2006           [Page 35]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



     OBJECTS {
       gmplsLabelFreeform
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Freeform labels."
   ::=3D { gmplsLabelGroups 4 }

   gmplsLabelSonetSdhGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelSonetSdhSignalIndex,
       gmplsLabelSdhVc,
       gmplsLabelSdhVcBranch,
       gmplsLabelSonetSdhBranch,
       gmplsLabelSonetSdhGroupBranch
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement SONET and SDH labels."
   ::=3D { gmplsLabelGroups 5 }

   gmplsLabelWavebandGroup OBJECT-GROUP
     OBJECTS {
       gmplsLabelWavebandId,
       gmplsLabelWavebandStart,
       gmplsLabelWavebandEnd
     }
     STATUS  current
     DESCRIPTION
       "Object needed to implement Waveband labels."
   ::=3D { gmplsLabelGroups 6 }
   END




9. Security Considerations

   It is clear that the MIB modules described in this document in
   association with the MPLS-LSR-STD-MIB [RFC3813] are potentially
   useful for monitoring of GMPLS LSRs. These MIB modules can also be
   used for configuration of certain objects, and anything that can be
   configured can be incorrectly configured, with potentially disastrous
   results.

   There are a number of management objects defined in these MIB modules
   with a MAX-ACCESS clause of read-write and/or read-create. Such
   objects may be considered sensitive or vulnerable in some network



Nadeau and Farrel            Expires October 2006           [Page 36]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   environments. The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations. These are the tables and objects and their
   sensitivity/vulnerability:

   o  the gmplsInterfaceTable, gmplsInSegmentTable, gmplsOutSegmentTable
      and gmplsLabelTable collectively contain objects to provision
      GMPLS interfaces, LSPs and their associated parameters on a Label
      Switching Router (LSR). Unauthorized write access to objects in
      these tables, could result in disruption of traffic on the
      network. This is especially true if an LSP has already been
      established.

   Some of the readable objects in these MIB modules (i.e., objects with
   a MAX-ACCESS other than not-accessible) may be considered sensitive
   or vulnerable in some network environments. It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP. These are the tables and objects and their
   sensitivity/vulnerability:

   o  the gmplsInterfaceTable, gmplsInSegmentTable, gmplsOutSegmentTable
      and gmplsLabelTable collectively show the LSP network topology and
      its capabilities. If an Administrator does not want to reveal this
      information, then these tables should be considered
      sensitive/vulnerable.

   SNMP versions prior to SNMPv3 did not include adequate security. Even
   if the network itself is secure (for example by using IPSec), even
   then, there is no control as to who on the secure network is allowed
   to access and GET/SET (read/change/create/delete) the objects in
   these MIB modules.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security. It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module, is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

10. Acknowledgments




Nadeau and Farrel            Expires October 2006           [Page 37]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



   This document is a product of the CCAMP Working Group.

   This document extends [RFC3813]. The authors would like to express
   their gratitude to all those who worked on that earlier MIB document.

   The authors would like to express their thanks to Dan Joyle for his
   careful review and comments on early versions of the Label Table.
   Special thanks to Joan Cucchiara and Len Nieman for their help with
   compilation issues. Tom Petch and Bert Wijnen provided useful input
   in the final stages of review.

   Joan Cucchiara provided a helpful and very thorough MIB Doctor
   review.

11. IANA Considerations

-- (Note to RFC-Editor:)
-- We request that you assign contiguous RFC numbers to the three GMPLS
-- MIB documents.
-- The first number to draft-ietf-ccamp-gmpls-tc-mib, the second to
-- draft-ietf-ccamp-gmpls-lsr-mib, and the third to
-- draft-ietf-ccamp-gmpls-te-mib.
-- (Please remove this note prior to publication.)

   IANA is requested to root MIB objects in the two MIB modules
   contained in this document under the mplsStdMIB subtree.

   In the future, GMPLS related standards track MIB modules should be
   rooted under the mplsStdMIB (sic) subtree. IANA has been requested to
   manage that namespace in the SMI Numbers registry [RFC3811]. New
   assignments can only be made via a Standards Action as specified in
   [RFC2434].

11.1. IANA Considerations for GMPLS-LSR-STD-MIB

   The IANA is requested to assign { mplsStdMIB YYY } to the
   GMPLS-LSR-STD-MIB module specified in this document, and to record
   the assignment in the SMI Numbers registry.
-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note

11.2. IANA Considerations for GMPLS-LABEL-STD-MIB

   The IANA is requested to assign { mplsStdMIB ZZZ } to the
   GMPLS-LABEL-STD-MIB module specified in this document, and to record
   the assignment in the SMI Numbers registry.

-- RFC Editor. Please replace ZZZ above with the OID assigned by IANA



Nadeau and Farrel            Expires October 2006           [Page 38]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



-- and remove this note

12. References

12.1. Normative References

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirements Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]    McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                J., Rose, M., and S. Waldbusser, "Structure of
                Management Information Version 2 (SMIv2)", STD 58, RFC
                2578, April 1999.

   [RFC2579]    McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                J., Rose, M., and S. Waldbusser, "Textual Conventions
                for SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]    McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                J., Rose, M., and S. Waldbusser, "Conformance Statements
                for SMIv2", STD 58, RFC 2580, April 1999.

   [RFC2863]    McCloghrie, K. and F. Kastenholz, "The Interfaces Group
                MIB", RFC 2863, June 2000.

   [RFC3031]    Rosen, E., Viswanathan, A., and R. Callon,
                "Multiprotocol Label Switching Architecture", RFC 3031,
                January 2001.

   [RFC3032]    Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
                Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
                Encoding", RFC 3032, January 2001.

   [RFC3209]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", RFC 3209, December 2001.

   [RFC3289]    Baker, F., Chan, K., and A. Smith, "Management
                Information Base for the Differentiated Services
                Architecture", RFC 3289, May 2002.

   [RFC3443]    Agarwal, P. and Akyol, B., "Time To Live (TTL)
                Processing in Multi-Protocol Label Switching (MPLS)
                Networks", RFC 3443, January 2003.

   [RFC3471]    Berger, L., "Generalized Multi-Protocol Label Switching
                (GMPLS) Signaling Functional Description", RFC 3471,
                January 2003.



Nadeau and Farrel            Expires October 2006           [Page 39]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006




   [RFC3473]    Berger, L., "Generalized Multi-Protocol Label Switching
                (GMPLS) Signaling Resource ReserVation Protocol-Traffic
                Engineering (RSVP-TE) Extensions", RFC 3473, January
                2003.

   [RFC3811]    Nadeau, T. and J. Cucchiara, "Definition of Textual
                Conventions and for Multiprotocol Label Switching (MPLS)
                Management", RFC 3811, June 2004.

   [RFC3813]    Srinivasan, C., Viswanathan, A., and T.  Nadeau,
                "Multiprotocol Label Switching (MPLS) Label Switching
                (LSR) Router Management Information Base (MIB)", RFC
                3813, June 2004.

   [RFC3945]    Mannie, E., Ed., "Generalized Multiprotocol Label
                Switching (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC3946]    Mannie, E. and D. Papadimitriou, "Generalized Multi-
                Protocol Label Switching (GMPLS) Extensions for
                Synchronous Optical Network (SONET) and Synchronous
                Digital Hierarchy (SDH) Control", RFC 3946, October
                2004.

   [GMPLSTCMIB] Nadeau, T. and A. Farrel, "Definitions of Textual
                Conventions for Multiprotocol Label Switching (MPLS)
                Management", draft-ietf-ccamp-gmpls-tc-mib, work in
                progress.

   [GMPLSTEMIB] Nadeau, T. and A. Farrel, "Generalized Multiprotocol
                Label Switching (GMPLS) Traffic Engineering Management
                Information Base", draft-ietf-ccamp-gmpls-te-mib, work
                in progress.

12.2. Informative References

   [RFC3410]    Case, J., Mundy, R., Partain, D., and B. Stewart,
                "Introduction and Applicability Statements for
                Internet-Standard Management Framework", RFC 3410,
                December 2002.

   [RFC3468]    Andersson, L., and Swallow, G., "The Multiprotocol=20
                Label Switching (MPLS) Working Group decision on=20
                MPLS signaling protocols", RFC 3468, February 2003.

   [RFC3472]    Ashwood-Smith, P. and L. Berger, "Generalized
                Multi-Protocol Label Switching (MPLS) Signaling
                - Constraint-based Routed Label Distribution Protocol



Nadeau and Farrel            Expires October 2006           [Page 40]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006



                (CR-LDP) Extensions", RFC 3472, January 2003.

   [RFC3812]    Srinivasan, C., Viswanathan, A., and T. Nadeau,
                "Multiprotocol Label Switching (MPLS) Traffic
                Engineering (TE) Management Information Base (MIB)",
                RFC 3812, June 2004.

13. Contact Information

   Thomas D. Nadeau
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA 01719
   Email: [e-mail]

   Adrian Farrel
   Old Dog Consulting
   Phone: [phone]
   Email: [e-mail]

   Cheenu Srinivasan
   Bloomberg L.P.
   731 Lexington Ave.
   New York, NY 10022
   Phone: [phone]
   Email: [e-mail]

   Tim Hall
   Data Connection Ltd.
   100 Church Street
   Enfield, Middlesex, EN2 6BQ, UK
   Phone: [phone]
   Email: [e-mail]

   Ed Harrison
   Data Connection Ltd.
   100 Church Street
   Enfield, Middlesex, EN2 6BQ, UK
   Phone: [phone]
   Email: [e-mail]











Nadeau and Farrel            Expires October 2006           [Page 41]
=0C
         draft-ietf-ccamp-gmpls-lsr-mib-14.txt         April 28, 2006











14. Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   [e-mail].



15. Full Copyright Statement

   Copyright (C) The Internet Society (2006). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




Nadeau and Farrel            Expires October 2006           [Page 42]

--Apple-Mail-17-1044836305
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed




--Apple-Mail-17-1044836305--



Envelope-to: [e-mail]
Delivery-date: Thu, 04 May 2006 19:28:24 +0000
Message-ID: <042d01c66fb1$8be5de30$020210ac@youref3aa80866>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: IETF Meeting Survey
Date: Thu, 4 May 2006 20:03:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Hi,

In case you haven't seen this and feel moved to complete it.

Only if you give them can the Secretariat take your opinions into account.

Thanks,
Adrian
----- Original Message ----- 
From: "Ray Pelletier" <[e-mail]>
To: <[e-mail]>
Sent: Monday, May 01, 2006 4:24 PM
Subject: IETF Meeting Survey


> All;
> It has been suggested that if I really wanted to get feedback on the 
> Meeting Survey (and I do)  I should have it forwarded by the WG Chairs 
> to the working groups - so this is a request that you ask members of the 
> working groups to complete a short survey that focuses primarily, but 
> not exclusively, on their meeting experience in Dallas. 
> 
> I truly want the info to make the changes members of the community want, 
> if possible and greatly appreciate your assistance in this regard.
> 
> Those interested in taking the survey can find it at:
> http://www.surveymonkey.com/s.asp?u=649182049947
> 
> Thanks
> Ray Pelletier
> IETF Admininstrative Director
> 
> 
> 
> 
> 
>




Envelope-to: [e-mail]
Delivery-date: Wed, 03 May 2006 15:47:15 +0000
Message-ID: <[e-mail]>
Date: Wed, 03 May 2006 17:46:05 +0200
From: Freek Dijkstra <[e-mail]>
User-Agent: Mail/News 1.5.0.2 (Macintosh/20060401)
MIME-Version: 1.0
To: [e-mail]
Subject: How to announce ethernet capabilities in GMPLS
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

I have a question about GMPLS.

My interest is mostly scientific in nature; and after reading a few
RFC's and internet drafts, I still found no satisfying answer. I may
have overlooked it.

How would you specify the encoding type for a link with IEEE 802.1q VLAN
tags versus a link which can not do that?
And related, how to distinguish between WAN PHY and LAN PHY encoding?

Imagine a small network with 3 or 4 layer 2 switches, with all
interfaces connected to one central photonic cross connect (MEMS
device). In such a case, it is useful to know the above details.


If I'm correct, a Layer 2 switch announces the capabilities of each
interface using a link state advertisement (LSA).

A LSA seems to contain at least
- "LSP encoding type" and
- "switching type".

In all cases, the parameters seem to be "Ethernet" and "L2SC" respectively.

At least draft-papadimitriou-enhanced-lsps-04 explictly says that WAN
PHY and LAN PHY both fall in the Ethernet "LSP Encoding Type".

draft-dimitri-gels-framework-00 seems to suggest that perhaps new
encoding types must be invented. I take it that I misunderstood, and
this will be defined in the "Switching Capability-Specific Information"
part of the LSA.

I tried looking, and Adrian's excellent Internet and it's protocols
lists that the "Switching Capability-Specific Information" for L2SC
only lists "minimum bandwidth" and "MTU".

Am I correct that the GELS working group will look into extensions for
this purpose? I'm currently not interested (yet) in the specific
details, but mostly in the general idea here. Is there by any chance a
list of already defined "Switching Capability-Specific Information"
parameters for other layers? Perhaps a list of internet drafts to go
through.

I might be wrong here somewhere -- somehow WAN/LAN PHY and IEEE 802.1q
VLAN or not capable seem other type of parameters to me then "MTU"
(which is currently defined for L2SC). If so -- what am I missing?

Regards,
Freek




Envelope-to: [e-mail]
Delivery-date: Wed, 03 May 2006 10:33:46 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New working group chair
Date: Wed, 3 May 2006 12:33:08 +0200
Message-ID: <[e-mail]>
Thread-Topic: New working group chair
Thread-Index: AcZuBUsaEpXHmSR4QxGvvnmE84A73AAlY+SQ
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>
Cc: <[e-mail]>

Goodbye Kireeti, thanks for the accomplished work.
Hi Deborah, welcome on board! :-)

Julien

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Kireeti Kompella

On Tue, 2 May 2006, Adrian Farrel wrote:

> After a period of discussion, the ADs have appointed Deborah Brungard
as our=20
> new co-chair.
> She can be reached at [e-mail]

Great choice!  Congratulations, Deborah!

Kireeti.
-------




Envelope-to: [e-mail]
Delivery-date: Wed, 03 May 2006 09:46:23 +0000
Date: Wed, 03 May 2006 17:30:10 +0800
From: lidan 37133 <[e-mail]>
Subject: =?gb2312?B?u9i4tA==?=:New working group chair
To: Adrian Farrel <[e-mail]>
Cc: [e-mail], Ross Callon <[e-mail]>, [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: quoted-printable
Content-disposition: inline

Hi=2C

Thanks Kireeti for your hard work to this community!

Congratulations=2C Deborah!


Dan Li

----- =D4=AD=D3=CA=BC=FE -----
=B7=A2=BC=FE=C8=CB=3A Adrian Farrel =3Cadrian=40olddog=2Eco=2Euk=3E
=C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CE=E5=D4=C2 2=C8=D5=2C 2006 =CF=C2=
=CE=E77=3A37
=D6=F7=CC=E2=3A New working group chair

=3E Hi=2C
=3E =

=3E After a period of discussion=2C the ADs have appointed Deborah =

=3E Brungard as our =

=3E new co-chair=2E
=3E She can be reached at dbrungard=40att=2Ecom
=3E =

=3E I=27m sure you=27ll all join me in thanking Kireeti for his long =

=3E service to the =

=3E working group=2C and in welcoming Deborah=2E
=3E =

=3E Thanks=2C
=3E Adrian =

=3E =

=3E =

=3E =

=3E 




Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 18:11:06 +0000
Message-ID: <[e-mail]>
Date: Tue, 02 May 2006 11:10:32 -0700
From: Richard Rabbat <[e-mail]>
Organization: Fujitsu Labs of America
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail], Ross Callon <[e-mail]>, [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, Richard Rabbat <[e-mail]>
Subject: Re: New working group chair
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for all the hard work Kireeti.

A round of martinis on me in Montreal to celebrate Deborah's starting tenure

Richard.

Adrian Farrel wrote:
> Hi,
>
> After a period of discussion, the ADs have appointed Deborah Brungard 
> as our new co-chair.
> She can be reached at [e-mail]
>
> I'm sure you'll all join me in thanking Kireeti for his long service 
> to the working group, and in welcoming Deborah.
>
> Thanks,
> Adrian
>
>



Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 18:01:58 +0000
Message-ID: <013a01c66e12$7deb7f10$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: Re: New working group chair
Date: Tue, 2 May 2006 14:01:52 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hey Deborah, congrats!
Thanks, Kireeti for the hard work. I hope will still see you at IETFs.

Igor

----- Original Message ----- 
From: "Kireeti Kompella" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "Ross Callon" <[e-mail]>; "Bill Fenner"
<[e-mail]>; "Brungard, Deborah A, ALABS" <[e-mail]>
Sent: Tuesday, May 02, 2006 12:17 PM
Subject: Re: New working group chair


> On Tue, 2 May 2006, Adrian Farrel wrote:
>
> > After a period of discussion, the ADs have appointed Deborah Brungard as
our
> > new co-chair.
> > She can be reached at [e-mail]
>
> Great choice!  Congratulations, Deborah!
>
> Kireeti.
> -------
>




Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 18:00:15 +0000
Date: Tue, 02 May 2006 12:58:24 -0500
From: Lucy Yong <[e-mail]>
Subject: RE: New working group chair
To: [e-mail], 'Adrian Farrel' <[e-mail]>, [e-mail]
Cc: 'Ross Callon' <[e-mail]>, [e-mail], "'Brungard, Deborah A, ALABS'" <[e-mail]>
Message-id: <000701c66e12$056bb7d0$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

Many thanks to Kireeti and a kind welcome to Deborah.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Vishal Sharma
Sent: Tuesday, May 02, 2006 12:52 PM
To: 'Adrian Farrel'; [e-mail]
Cc: 'Ross Callon'; [e-mail]; 'Brungard, Deborah A, ALABS'
Subject: RE: New working group chair

Adrian, Kireeti,

First, a heartfelt thanks to Kireeti for his service to our
community and the WG, and a warm welcome to Deborah.

-Vishal 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, May 02, 2006 4:37 AM
> To: [e-mail]
> Cc: Ross Callon; [e-mail]; Brungard, Deborah A,
ALABS
> Subject: New working group chair
> 
> Hi,
> 
> After a period of discussion, the ADs have appointed Deborah 
> Brungard as our new co-chair.
> She can be reached at [e-mail]
> 
> I'm sure you'll all join me in thanking Kireeti for his long 
> service to the working group, and in welcoming Deborah.
> 
> Thanks,
> Adrian 
> 
> 
> 
> 








Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 17:50:21 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Cc: "'Ross Callon'" <[e-mail]>, <[e-mail]>, "'Brungard, Deborah A, ALABS'" <[e-mail]>
Subject: RE: New working group chair
Date: Tue, 2 May 2006 10:51:54 -0700
Organization: Metanoia, Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcZt3oxC/+/zqtwcTkmASNzvI14E2AAMkMdw
Message-Id: <[e-mail]>

Adrian, Kireeti,

First, a heartfelt thanks to Kireeti for his service to our
community and the WG, and a warm welcome to Deborah.

-Vishal 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, May 02, 2006 4:37 AM
> To: [e-mail]
> Cc: Ross Callon; [e-mail]; Brungard, Deborah A,
ALABS
> Subject: New working group chair
> 
> Hi,
> 
> After a period of discussion, the ADs have appointed Deborah 
> Brungard as our new co-chair.
> She can be reached at [e-mail]
> 
> I'm sure you'll all join me in thanking Kireeti for his long 
> service to the working group, and in welcoming Deborah.
> 
> Thanks,
> Adrian 
> 
> 
> 
> 





Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 16:58:01 +0000
User-Agent: Microsoft-Entourage/11.2.3.060209
Date: Tue, 02 May 2006 12:57:42 -0400
Subject: Re: New working group chair 
From: Monique Morrow <[e-mail]>
To: George Swallow <[e-mail]>, Kireeti Kompella <[e-mail]>
CC: Adrian Farrel <[e-mail]>, <[e-mail]>, Ross Callon <[e-mail]>, Bill Fenner <[e-mail]>, "Brungard, Deborah A,     ALABS" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: New working group chair 
Thread-Index: AcZuCYauxVGA7Nn8EdqVEAANk8LkKg==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

Echo the hearty congrats!

/monique


On 2/5/06 12:46 pm, "George Swallow" <[e-mail]> wrote:

>> Great choice!  Congratulations, Deborah!
> 
> Hear, hear!
> 
> ...George
> 
> ========================================================================
> George Swallow             Cisco Systems                  [phone]
>                            1414 Massachusetts Avenue
>                            Boxborough, MA 01719



Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 16:47:07 +0000
To: Kireeti Kompella <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail], Ross Callon <[e-mail]>, Bill Fenner <[e-mail]>, "Brungard, Deborah A,     ALABS" <[e-mail]>
Cc: [e-mail]
Subject: Re: New working group chair 
From: George Swallow <[e-mail]>
Date: Tue, 02 May 2006 12:46:51 -0400
Message-Id: <[e-mail]>

> Great choice!  Congratulations, Deborah!

Hear, hear!

...George

========================================================================
George Swallow             Cisco Systems                  [phone]
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719



Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 16:29:18 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New working group chair
Date: Tue, 2 May 2006 12:28:59 -0400
Message-ID: <[e-mail]>
Thread-Topic: New working group chair
Thread-Index: AcZuBCm6IbjjyYWFRpurovTCYwN24AAAK7PA
From: "Zafar Ali \(zali\)" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, "Ross Callon" <[e-mail]>, "Bill Fenner" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Kireeti Kompella
> Sent: Tuesday, May 02, 2006 12:18 PM
> To: Adrian Farrel
> Cc: [e-mail]; Ross Callon; Bill Fenner; Brungard,=20
> Deborah A, ALABS
> Subject: Re: New working group chair
>=20
> On Tue, 2 May 2006, Adrian Farrel wrote:
>=20
> > After a period of discussion, the ADs have appointed=20
> Deborah Brungard=20
> > as our new co-chair.
> > She can be reached at [e-mail]
>=20
> Great choice!  Congratulations, Deborah!
>=20

I would second that. Congrat Deborah.=20

I would also like to Thank Kireeti for his hard work as CCAMP chair over
the last many years.=20

Thanks

Regards... Zafar=20

> Kireeti.
> -------
>=20



Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 16:19:10 +0000
Date: Tue, 2 May 2006 09:17:38 -0700 (PDT)
From: Kireeti Kompella <[e-mail]>
To: Adrian Farrel <[e-mail]>
cc: [e-mail], Ross Callon <[e-mail]>, Bill Fenner <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: Re: New working group chair
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 2 May 2006, Adrian Farrel wrote:

> After a period of discussion, the ADs have appointed Deborah Brungard as our 
> new co-chair.
> She can be reached at [e-mail]

Great choice!  Congratulations, Deborah!

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 11:32:48 +0000
Message-ID: <025201c66ddc$f57a8d40$020210ac@youref3aa80866>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ross Callon" <[e-mail]>, <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: New working group chair
Date: Tue, 2 May 2006 12:37:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

After a period of discussion, the ADs have appointed Deborah Brungard as our 
new co-chair.
She can be reached at [e-mail]

I'm sure you'll all join me in thanking Kireeti for his long service to the 
working group, and in welcoming Deborah.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 07:35:20 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66DBA.C15B30C1"
Subject: RE: Question about relationship between control channels and TE links(?)
Date: Tue, 2 May 2006 09:34:03 +0200
Message-ID: <[e-mail]>
Thread-Topic: Question about relationship between control channels and TE links(?)
Thread-Index: AcZtkHboHZlS2oZmQeWdnnimvtMygwAKi8Nw
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Kim Young Hwa" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C66DBA.C15B30C1
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Kim,
=20
You should have a look at RFC 4204
=20
Regards
=20
JL


________________________________

	De : [e-mail] [mailto:[e-mail]] De la =
part de Kim Young Hwa
	Envoy=E9 : mardi 2 mai 2006 04:31
	=C0 : [e-mail]
	Objet : Question about relationship between control channels and TE =
links(?)
=09
=09
	Hi,
	I've a question of the relationship between control channels and TE =
links.
	All links with the same TE characteristics bewteen two adjacent nodes, =
maybe called a TE link, are grouped together.
	If we have multiple TE links due to different physical interface types =
and only one common control channel between these nodes, how can we get =
the result of neighbor discoveries between these nodes?
	I know that  a TE link between a pair of LSRs doesn't imply the =
existence of a routing adjacency between LSRs. But, I think that a IGP =
should perform Hello protocols to identify their neighbors about the =
different physical interfaces over the single control channel. Then, in =
a GMPLS domain under the separation of control channels, I do not know =
well that a Hello protocol of a IGP carried over the control channel =
works for the neighbor discovery?
	Looking at OSPFv2(rfc2178] and GMPLS-OSPF(rfc4203), I could not see a =
content that my question is resolved.
	Could someone help me to find out the answer?
	=20
	 =
<http://umail.etri.re.kr/External_ReadCheck.aspx?email=[e-mail].o=
rg&name=3Dccamp%40ops.ietf.org&fromemail=[e-mail]&messageid=3D=
[e-mail]%3E>=20


------_=_NextPart_001_01C66DBA.C15B30C1
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.2900.2802" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D251043307-02052006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Kim,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D251043307-02052006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D251043307-02052006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>You should have a look at RFC =
4204</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D251043307-02052006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D251043307-02052006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Regards</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D251043307-02052006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D251043307-02052006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>JL</FONT></SPAN></DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Dfr dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>De&nbsp;:</B> [e-mail] =

  [mailto:[e-mail]] <B>De la part de</B> Kim Young=20
  Hwa<BR><B>Envoy=E9&nbsp;:</B> mardi 2 mai 2006 =
04:31<BR><B>=C0&nbsp;:</B>=20
  [e-mail]<BR><B>Objet&nbsp;:</B> Question about relationship =
between=20
  control channels and TE links(?)<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: System">
  <DIV>Hi,</DIV>
  <DIV>I've a question of the relationship between control channels and =
TE=20
  links.</DIV>
  <DIV>All links with the same TE characteristics bewteen two adjacent =
nodes,=20
  maybe called a TE link, are grouped together.</DIV>
  <DIV>
  <DIV>If we have multiple TE links due to different physical interface =
types=20
  and only one common control channel between these nodes, how can we =
get the=20
  result of neighbor discoveries between these nodes?</DIV>
  <DIV>I know that&nbsp; <SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 20pt; mso-fareast-font-family: ??; =
mso-hansi-font-family: Arial; mso-fareast-language: KO"><FONT=20
  size=3D2>a TE link between a pair of LSRs doesn't imply the existence =
of a=20
  routing adjacency between LSRs. But, I think that a IGP should perform =
Hello=20
  protocols to identify&nbsp;their neighbors about the different =
physical=20
  interfaces over the single control channel. Then, in a GMPLS domain =
under the=20
  separation of control channels, I do not know well that a Hello =
protocol of a=20
  IGP carried over the control channel works for the neighbor=20
  discovery?</FONT></SPAN></DIV>
  <DIV><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 20pt; mso-fareast-font-family: ??; =
mso-hansi-font-family: Arial; mso-fareast-language: KO"><FONT=20
  size=3D2>Looking at&nbsp;OSPFv2(rfc2178] and GMPLS-OSPF(rfc4203), I =
could not=20
  see a content that my question is resolved.</FONT></SPAN></DIV>
  <DIV><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 20pt; mso-fareast-font-family: ??; =
mso-hansi-font-family: Arial; mso-fareast-language: KO"><FONT=20
  size=3D2>Could someone help me to find out the =
answer?</FONT></SPAN></DIV>
  <DIV><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 20pt; mso-fareast-font-family: ??; =
mso-hansi-font-family: Arial; mso-fareast-language: KO"><FONT=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></DIV></DIV><IMG style=3D"DISPLAY: =
none"=20
  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=[e-mail]%3E" =

  width=3D0 NOSEND=3D"1"></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C66DBA.C15B30C1--



Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 02:29:36 +0000
Thread-Topic: Question about relationship between control channels and TE links(?)
Thread-Index: AcZtkHboHZlS2oZmQeWdnnimvtMygw==
Content-Transfer-Encoding: 7bit
Reply-To: "Kim Young Hwa" <[e-mail]>
From: "Kim Young Hwa" <[e-mail]>
To: <[e-mail]>
Cc: 
Bcc: 
Subject: Question about relationship between control channels and TE links(?)
Date: Tue, 2 May 2006 11:31:06 +0900
Comment: GQ19@|@ZEk=E?,18?x, ASON1b<zF@, 4c4g
Message-ID: <4e4501c66d90$76eb05f0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_4E46_01C66DDB.E6D2ADF0"
Content-class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_4E46_01C66DDB.E6D2ADF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: base64


------=_NextPart_000_4E46_01C66DDB.E6D2ADF0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: base64

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0
ZW0iPg0KPERJVj5IaSw8L0RJVj4NCjxESVY+SSd2ZSBhIHF1ZXN0aW9uIG9mIHRoZSByZWxhdGlv
bnNoaXAgYmV0d2VlbiBjb250cm9sIGNoYW5uZWxzIGFuZCBURSBsaW5rcy48L0RJVj4NCjxESVY+
QWxsIGxpbmtzIHdpdGggdGhlIHNhbWUgVEUgY2hhcmFjdGVyaXN0aWNzIGJld3RlZW4gdHdvIGFk
amFjZW50IG5vZGVzLCBtYXliZSBjYWxsZWQgYSBURSBsaW5rLCBhcmUgZ3JvdXBlZCB0b2dldGhl
ci48L0RJVj4NCjxESVY+DQo8RElWPklmIHdlIGhhdmUgbXVsdGlwbGUgVEUgbGlua3MgZHVlIHRv
IGRpZmZlcmVudCBwaHlzaWNhbCBpbnRlcmZhY2UgdHlwZXMgYW5kIG9ubHkgb25lIGNvbW1vbiBj
b250cm9sIGNoYW5uZWwgYmV0d2VlbiB0aGVzZSBub2RlcywgaG93IGNhbiB3ZSBnZXQgdGhlIHJl
c3VsdCBvZiBuZWlnaGJvciBkaXNjb3ZlcmllcyBiZXR3ZWVuIHRoZXNlIG5vZGVzPzwvRElWPg0K
PERJVj5JIGtub3cgdGhhdCZuYnNwOyA8U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6
IDIwcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiA/PzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5
OiBBcmlhbDsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj48Rk9OVCBzaXplPTI+YSBURSBsaW5r
IGJldHdlZW4gYSBwYWlyIG9mIExTUnMgZG9lc24ndCBpbXBseSB0aGUgZXhpc3RlbmNlIG9mIGEg
cm91dGluZyBhZGphY2VuY3kgYmV0d2VlbiBMU1JzLiBCdXQsIEkgdGhpbmsgdGhhdCBhIElHUCBz
aG91bGQgcGVyZm9ybSBIZWxsbyBwcm90b2NvbHMgdG8gaWRlbnRpZnkmbmJzcDt0aGVpciBuZWln
aGJvcnMgYWJvdXQgdGhlIGRpZmZlcmVudCBwaHlzaWNhbCBpbnRlcmZhY2VzIG92ZXIgdGhlIHNp
bmdsZSBjb250cm9sIGNoYW5uZWwuIFRoZW4sIGluIGEgR01QTFMgZG9tYWluIHVuZGVyIHRoZSBz
ZXBhcmF0aW9uIG9mIGNvbnRyb2wgY2hhbm5lbHMsIEkgZG8gbm90IGtub3cgd2VsbCB0aGF0IGEg
SGVsbG8gcHJvdG9jb2wgb2YgYSBJR1AgY2FycmllZCBvdmVyIHRoZSBjb250cm9sIGNoYW5uZWwg
d29ya3MgZm9yIHRoZSBuZWlnaGJvciBkaXNjb3Zlcnk/PC9GT05UPjwvU1BBTj48L0RJVj4NCjxE
SVY+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAyMHB0OyBtc28tZmFyZWFzdC1m
b250LWZhbWlseTogPz87IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1mYXJlYXN0
LWxhbmd1YWdlOiBLTyI+PEZPTlQgc2l6ZT0yPkxvb2tpbmcgYXQmbmJzcDtPU1BGdjIocmZjMjE3
OF0gYW5kIEdNUExTLU9TUEYocmZjNDIwMyksIEkgY291bGQgbm90IHNlZSBhIGNvbnRlbnQgdGhh
dCBteSBxdWVzdGlvbiBpcyByZXNvbHZlZC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BB
TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDIwcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFt
aWx5OiA/PzsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6IEtPIj48Rk9OVCBzaXplPTI+Q291bGQgc29tZW9uZSBoZWxwIG1lIHRvIGZpbmQgb3V0IHRo
ZSBhbnN3ZXI/PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gbGFuZz1FTi1VUyBzdHls
ZT0iRk9OVC1TSVpFOiAyMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogPz87IG1zby1oYW5z
aS1mb250LWZhbWlseTogQXJpYWw7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+PEZPTlQgc2l6
ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+PC9ESVY+PC9ESVY+PGltZyBzdHlsZT0iZGlz
cGxheTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0iaHR0cDovL3VtYWlsLmV0cmkucmUua3Iv
RXh0ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9Y2NhbXBAb3BzLmlldGYub3JnJm5hbWU9Y2Nh
bXAlNDBvcHMuaWV0Zi5vcmcmZnJvbWVtYWlsPXlod2tpbUBldHJpLnJlLmtyJm1lc3NhZ2VpZD0l
M0NhZTYwZTU0Yi0xNGFjLTQ1N2ItYjhhZi1mYzNlNDQ1M2MwNjRAZXRyaS5yZS5rciUzRSI+

------=_NextPart_000_4E46_01C66DDB.E6D2ADF0--



Envelope-to: [e-mail]
Delivery-date: Tue, 02 May 2006 00:23:59 +0000
To: Richard Rabbat <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail], dimitri papadimitriou <[e-mail]>, [e-mail]
Subject: Re: Question about carrying the call id
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 2 May 2006 02:23:16 +0200
Content-Type: text/plain; charset="US-ASCII"

hi richard

association object associates by definition LSPs (using per-sender node 
identifier and address) on the other side a call creates an association 
between end-points by which subsequent LSPs may be made (call ids are 
unique within the context of the pair of addresses that are the call 
source and destination)
 
thanks,
- dimitri.
 





Richard Rabbat <[e-mail]>
Sent by: [e-mail]
27/04/2006 19:56
 
        To:     Adrian Farrel <[e-mail]>, dimitri papadimitriou 
<[e-mail]>
        cc:     [e-mail]
        Subject:        Question about carrying the call id


< Attachment richard.vcf removed >


Hi Adrian, Dimitri,

In your slides regarding ASON, you mentioned in slide 7
http://www3.ietf.org/proceedings/06mar/slides/ccamp-4/sld7.htm
that the current proposal is to match the session object but that an
alternative may be using the association object.
has there been a decision either way and what was the rationale?
thanks,
Richard.






Envelope-to: [e-mail]
Delivery-date: Mon, 01 May 2006 23:33:27 +0000
Message-ID: <01cd01c66d78$559159d0$020210ac@youref3aa80866>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "JP Vasseur" <[e-mail]>, "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: [Pce] Comparison of Encryption vs. Path Key Solutions for theCPSID.
Date: Mon, 1 May 2006 17:51:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Sorry that I haven't been following this too closely.

Jean Louis made a couple of interesting points...

>>PCE WG members: thanks to provide your feedback on whether:
>>(1) You think that there is a need for such solution,
>
>Yes definitely, confidentiality is a key requirements in an inter-provider 
>context.
>
>>(2) You would prefer one solution (which one and why ?)
>>(3) You think that there is a need for both
>
>Answer to (2) and (3):
>
>It seems to me that we should end-up with a single solution so as to ease 
>interworking.

Of course, interworking is important and options are generally a Bad Thing 
(TM), but if the different solutions are beneficial in different 
environments then we can easily specify support for both options as 
mandatory. There will, in any case, be a policy decision at an domain border 
router to say how (and if) to process and encryption/path key.

So, for me, the question is whether there are different environments under 
which each of the options is preferable.

> IMO in an inter-AS MPLS-TE environment without PCEs, the paths
> will be loose anyway, so there will not be any confidentiality issue.

I am not sure. The point we are trying to make is that, in order to 
determine a viable (not to mention optimal) end-to-end path, it will have 
been necessary to compute the entire path. This may have been achieved 
privately by independent (albeit cooperating) PCEs.

In this case I think we are agreed that the full path would not be passed 
back to the ingress PCC for signaling, and so loose hops or strict abstract 
nodes would be used. But the question is what to do with the computed 
information so that it is not necessary to recompute when the signaling 
message enters the domain. One option, as you suggest, is to send it out to 
the domain border routers in anticipation of a signaling message (and 
potentially use a key to unlock it), a second option is to retain the 
information on the PCE and look it up using a key. The third option is to 
encrypt the path.

It seems to me that the first option requires the second to handle races, 
memory over-load, etc. So, in fact, the first option is an implementation 
optimization (but we may still need to make protocol changes to ensure that 
it is supported).

And my question reduces to:
Are there any circmstances under which ERO encryption is of value to us?

> If have some concerns regarding the cost of encryption, particularly for
> large paths (we need to think about future P2MP applications with a
> large number of hops...).

I am not so sure that the encryption of an ERO is so significant using 
today's technology. Indeed, one might equally argue that the cost of 
distributing a large number of paths for multiple destinations to several 
domain entry points could also be high.

> By the way, encryption approaches are really vulnerable
> to DoS attacks.

This sounds really important.
What you mean is presumably that we could waste a lot of CPU decrypting an 
ERO that is bogus.
But why is this more of a problem than receiving a bogus LSP setup request 
that causes us to do extra computation?
Or a Path message with a bogus path key that causes us to consult the local 
PCE for a non-existent path?

> Hence I would strongly favor the PKS solution. The optimization
> suggested, which consists of sending the computed path segment
> to the LSR in an unsolicited manner, just after the computation,
> sounds relevant and should be further investigated.

I think this is a valid application, but I would not want to see it made 
*the* standard technique since it gives me scaling worries for the future.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Mon, 01 May 2006 21:48:08 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>
Subject: Document Action: 'Reoptimization of Multiprotocol Label  Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch  Path (LSP)' to Informational RFC 
Message-Id: <[e-mail]>
Date: Mon, 01 May 2006 17:46:28 -0400

The IESG has approved the following document:

- 'Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering 
   (TE) loosely routed Label Switch Path (LSP) '
   <draft-ietf-ccamp-loose-path-reopt-02.txt> as an Informational RFC

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Ross Callon and Bill Fenner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-02.txt

Technical Summary
 
   This document defines a mechanism for the reoptimization of loosely
   routed MPLS and GMPLS (Generalized Multiprotocol Label Switching)
   Traffic Engineering (TE) LSPs signaled with RSVP-TE.
 
Working Group Summary
 
   As far as I know there was no dissent. I am concerned that the 
   document might not have had as many people seriously interested in
   it as might be optimal to make sure that all options are considered
   in detail. 
 
Protocol Quality
 
   This has been approved as "informational".  

   There are very minor editorial sub-optimal use of English words. 
   For example, at the beginning of section 3: "The aim of this section
   is purely to remind the mechanisms involved in...". Here the word 
   "remind" should be "summarize". There are only a small number of these, 
   and thus they can be corrected by the RFC editor prior to publication. 

Note to RFC Editor
 
There are a few minor nits to be corrected prior to publication:

nit1>> The first paragraph of section 3 current says: 

    The aim of this section is purely to remind the mechanisms
    involved in the establishment of a loosely routed TE LSP (in
    line with [RFC3209]) and does not introduce any new protocol
    extensions or mechanisms.

This should be corrected to say:

    The aim of this section is purely to summarize the mechanisms
    involved in the establishment of a loosely routed TE LSP, as
    specified in [RFC3209]. The reader should see RFC3209 for a
    more detailed description of these mechanisms.

nit2>>In the first paragraph of section 4, there is a sentence that says:

    Since a preferable (e.g. shorter) path might not be visible from the 
    head-end LSR by means  of the IGP if the head-end LSR does not belong
    to the head-end IGP area...".

This should say: 

    Since a preferable (e.g. shorter) path might not be visible from the 
    head-end LSR by means of the IGP if the head-end LSR does not belong
    to the same IGP area where the associated topology change occurred...".

nit3>> in section 7 there is the sentence:

    Such a procedure would not be in conflict with any mechanisms
    not already documented in [RFC3209] and [RFC3473].

this should say: 

    Such a procedure would not be in conflict with any mechanisms
    already documented in [RFC3209] and [RFC3473].

In addition, the following changes should be made to the IANA
Considerations section:

REMOVE:
   IANA will assign a new flag named "Path re-evaluation request" in the
   SESSION-ATTRIBUTE object (C-Type 1 and 7) specified in [RFC3209].
   Suggested value is (to be confirmed by IANA) 0x20.

Change:
OLD:
   IANA will also assign three new error sub-code values for the RSVP

NEW:
   IANA will assign three new error sub-code values for the RSVP


And in Section 5.1 change:

OLD:
   The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and
   7) is defined (suggested value to be confirmed by IANA):

NEW:
   The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and
   7) is defined:

IANA Note

   The SESSION ATTRIBUTE flag request has been removed via RFC Editor
   note, as that registry has not yet been created.  The assignments for
   the RSVP PErr error subcodes are still requested.  A document will
   follow to create the SESSION ATTRIBUTE flag registry.