Subject: Slides on line

From: Adrian Farrel <[email-masked]>
Date: Sun, 02 Dec 2007 19:55:53 +0000

Hi,

A good number of slide sets are already on line. Go to the agenda at 
http://www3.ietf.org/proceedings/07dec/agenda/ccamp.htm and follow the 
links.

Thanks to all who have made the effort to get their slides out early.

Still looking for material for...

Tuesday
- Requirements for GMPLS Inter-Domain Routing (Tomohiro)
- BGP Traffic Engineering Attribute (Yakov, Don, Hamid)
- GMPLS Ethernet Label Switching Architecture and Framework (Don)
- GMPLS control of Ethernet PBB-TE (Don)

Thursday
- ITU-T and OIF progress report (Lyndon)
- ARP For GMPLS controlled PSC Ethernet Interfaces (Zafar)
- OAM Requirements for GMPLS Networks (Tomohiro)
- Ping and Traceroute for GMPLS LSPs in Non-Packet Switched Networks (Zafar)
- GMPLS RSVP-TE Ethernet OAM Extensions (Attila)
- VCAT/LCAS (Greg)
- Lambda labels (Tomohiro)

Apologies if you have already sent slides. Please e-kick me.

Cheers,
Adrian

---

From: "Weiqiang Sun" <[email-masked]>
Date: Sun, 2 Dec 2007 23:20:59 -0500

Hi Adrian,

Would you please change the presenter of the lsp-ddpm draft scheduled last
in the Thursday meeting? I will be presenting the draft this time. :)
Thanks for your help and see you in Vancouver.

Weiqiang Sun

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Sunday, December 02, 2007 2:56 PM
To: [email-masked]
Cc: Brungard, Deborah A, ALABS
Subject: Slides on line

Hi,

Tuesday

Thursday

Cheers,
Adrian

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 4 Dec 2007 08:42:55 -0500

I have some questions/comments about this draft.
	
	0) The draft needs to be organized a bit better so that it is
		clear what you are trying to achieve.  For example,
		some of the introductory text is unclear as to whether
		or not you are verifying the control or data planes (or
		both). At least to my reading.

	1) This solution seems tightly coupled between RFCs 4204 and 4379.
		Is it reasonable to assume that all implementations
		will support 4204?  This also seems to beg the question
		of "are there too many moving parts here?" for this
		to ultimately work and interoperate between 2 vendors.

	2) Which packet formats are to be used in this approach? All I see
		are statements like "send Test messages", but no details of
		that.

	3) Can this approach guarantee that the data plane is checked
		completely, and if not, what percentage of coverage is
		given?

	4) In section 2.2, you stipulate:

	To limit the scope of LSP Verification to a
         particular LSP, LSP-id is used in LOCAL_LINK_ID or
         REMOTE_LINK_ID fields of the LMP message exchanges during
         verification.

	Something similar has been proposed as an addition to lsp ping for
	the multi-cast case. Please check into this to see if this is
	similar enough to reuse that object.

	5) Is the link verification actually sent over the LMP control  
channel or
		the actual data path? Your text is unclear on this:

		        To initiate the link verification procedure, the Ingress
         (Egress) node MUST send a BeginVerify message over a control
         channel with IP address of the destination (source) node of
         the LSP.  To limit the scope of LSP Verification to a
         particular LSP, LSP-id is used in LOCAL_LINK_ID or
         REMOTE_LINK_ID fields of the LMP message exchanges during
         verification. If the LINK_ID field is zero, the verification
         can span multiple LSPs between the set of Ingress/Egress nodes
         involved in the verification process. The rest of the details
         for LSP verification follow the LMP link verification
         procedure [RFC4204].

	RFC4204 states that the link verify messages are NOT to be sent
	over the control channel, and since you want to verify the
	data plane you should follow its rules for this:

	12.5.6.  Test Message (Msg Type = 10)

	   The Test message is transmitted over the data link and is used to
	   verify its physical connectivity.  Unless explicitly stated, these
	   messages MUST be transmitted over UDP like all other LMP messages.
	   The format of the Test messages is as follows:

	   <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>

	   The above transmission order SHOULD be followed.

	   Note that this message is sent over a data link and NOT over the
  	  control channel.  The transport mechanism for the Test message is
  	  negotiated using the Verify Transport Mechanism field of the
  	  BEGIN_VERIFY object and the Verify Transport Response field of the
  	  BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).

	6) I suggest passing this document by the MPLS WG and the LSP ping co- 
authors
		to ensure that your desire to reuse that protocol will indeed
		work, and that if this is eventually adopted as a CCAMP work item
		that it not pass WG last call until the MPLS WG has reviewed it.

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 4 Dec 2007 08:57:43 -0500

After reading this draft, I have some questions/comments.

	1) Overall, I am concerned that the definition of a new TLV and these  
procedures represent
		what amounts to a laying violation and ask that the ADs take a look  
at this
		approach closely. This is similar to the now-rejected approach that  
was proposed
		in the l2vpn WG about munging CFM + PWs.  To my reading, this is  
essentially
		the same thing. If you want to run CFM, run it natively over the  
ethernet interfaces and
		have no regard for the underlying topology (GMPLS, PWs, etc...)  
otherwise you
		will be creating a mess for implementations and interoperability.

	2) The introductory sections in this draft give a lot of discussion  
about fast fault detection. I
		am puzzled by this given that GMPLS networks tend to run over  
quickly self-healing
		optical infrastructures. Is it therefore truly necessary to motivate  
this work by
		requiring fast CFMs?

	3) This document does not cover E-LMI. Why not?

		For the purposes of this document, we only discuss Ethernet OAM
		   [IEEE-CFM] aspects that are relevant for the connectivity  
monitoring
		   of bidirectional point-to-point PBB-TE connections.

	4) Is this the right place to define this document or should this be  
done in GELS?

	5)   In section 2 you make the following statement:

		2.  GMPLS RSVP-TE Extensions

	 	  To simplify the configuration of connectivity monitoring, when an
		   Ethernet LSP is signalled the associated MEPs should be  
automatically
	 	  established.  Further more, GMPLS signalling should be able to
		  enable/disable connectivity monitoring of a particular Ethernet LSP.

		To my point in #1 above, you should use the native CFM functionality  
over the ethernet interface and signal
		those capabilities to the bridges at both ends using the IEEE CFM  
signaling procedures (when and if they
		are created).  If you want to test the underlying GMPLS LSP(s), then  
you should use some
		other mechanism defined for that layer such as the work stated in  
draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

---

From: "Attila Takacs" <[email-masked]>
Date: Tue, 4 Dec 2007 19:51:54 +0100

Hi Thomas,
 
Thank you for the comments!
Please see answers inline.
 
Best regards,
Attila

________________________________

	From: Thomas Nadeau [mailto:[email-masked]] 
	Sent: Tuesday, December 04, 2007 2:58 PM
	To: [email-masked]
	Cc: Attila Takacs; [email-masked]
	Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

	

	1) Overall, I am concerned that the definition of a new TLV and
these procedures represent 
	what amounts to a laying violation and ask that the ADs take a
look at this
	
	approach closely. This is similar to the now-rejected approach
that was proposed

	
	will be creating a mess for implementations and
interoperability.  

The application of the draft is exactly for what you are calling out:
when CFM is run natively over the Ethernet interfaces. The document
focuses on GELS and Ethernet LSPs. That is, to establish CFM entities
for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer
violation issue.

	2) The introductory sections in this draft give a lot of
discussion about fast fault detection. I

	optical infrastructures. Is it therefore truly necessary to
motivate this work by
	
	requiring fast CFMs?

It is right that frequent CCMs are not required if the layers below
Ethernet handle protection. However, the ID focuses on Ethernet LSPs
where Ethernet is not just a single hop above a transport LSP. In this
case Ethernet layer (for clarity GELS) may provide protection for
Ethernet LSPs. In any case,  the whole point of the ID is to allow for
the appropriate configuration of CFM for Ethernet LSPs with GMPLS.

E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within a
network.

	4) Is this the right place to define this document or should
this be done in GELS?

Well, GELS is done in CCAMP...this seems to be the right place.

	

	    To simplify the configuration of connectivity monitoring,
when an
	   Ethernet LSP is signalled the associated MEPs should be
automatically
	    established.  Further more, GMPLS signalling should be able
to
	  enable/disable connectivity monitoring of a particular
Ethernet LSP.

	
	To my point in #1 above, you should use the native CFM
functionality over the ethernet interface and signal
	those capabilities to the bridges at both ends using the IEEE
CFM signaling procedures (when and if they
	
	are created).  If you want to test the underlying GMPLS LSP(s),
then you should use some
	other mechanism defined for that layer such as the work stated
in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

See the note to your point #1. There is no relation to the
gmpls-LSP-ping draft.

---

From: Loa Andersson <[email-masked]>
Date: Tue, 04 Dec 2007 20:26:23 +0100

Tom,

Thomas Nadeau wrote:
>         what amounts to a laying violation 

did mean to say layering violation ???

/Loa

and ask that the ADs take a

-- 
Loa Andersson

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

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 4 Dec 2007 14:28:54 -0500

> did mean to say layering violation ???

	Yep. Typing too fast! *)

	--Tom

>> this be

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 4 Dec 2007 14:30:00 -0500

On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:

> The application of the draft is exactly for what you are calling  
> out: when CFM is run natively over the Ethernet interfaces. The  
> document focuses on GELS and Ethernet LSPs. That is, to establish  
> CFM entities for GMPLS controlled Ethernet LSPs. Hence, I think  
> there is no layer violation issue.

	This solution specifically only works for GMPLS ethernet LSPs, right?
What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and do  
CFM over those? Oh,
that is a different solution, right?  Then what do I do if I want to  
run CFM over some new type of
ethernet LSP in the future? More protocol hacks?  The point is to use  
CFM over an ethernet interface
without the underlying layers knowing. This is good networking  
architecture design, that simplifies
implementations and makes them more robust, as well as makes using  
them operationally much
easier.
> where Ethernet is not just a single hop above a transport LSP. In  
> this case Ethernet layer (for clarity GELS) may provide protection  
> for Ethernet LSPs. In any case,  the whole point of the ID is to  
> allow for the appropriate configuration of CFM for Ethernet LSPs  
> with GMPLS.
>
> E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs  
> within a network.
>
>
> See the note to your point #1. There is no relation to the gmpls-LSP- 
> ping draft.

	The point I am making is that perhaps it should.

	--Tom

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 5 Dec 2007 01:33:41 +0100

Hi Thomas,

                 My understanding of the ID was that RSVP-TE can be used to 'piggyback' CFM set-up, otherwise the scenario is: usage of RSVP-TE to set-up the LSP and NMS (meaning everything that is not control plane) to enable to CFM for the LSP.

From your comment I see that you're not happy with the fact the ID is so technology specific am I right?  If yes do you agree with the fact that could be useful in general to use the same signaling 'session' to set-up the LSP and to enable the CFM?

Best Regards

Diego

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: martedì 4 dicembre 2007 11.30
To: Attila Takacs
Cc: [email-masked]; [email-masked]
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

Hi Thomas,

Best regards,
Attila

	 

	1) Overall, I am concerned that the definition of a new TLV and these procedures represent 

	what amounts to a laying violation and ask that the ADs take a look at this

	approach closely. This is similar to the now-rejected approach that was proposed

	in the l2vpn WG about munging CFM + PWs.  To my reading, this is essentially

	the same thing. If you want to run CFM, run it natively over the ethernet interfaces and

	have no regard for the underlying topology (GMPLS, PWs, etc...) otherwise you 

The application of the draft is exactly for what you are calling out: when CFM is run natively over the Ethernet interfaces. The document focuses on GELS and Ethernet LSPs. That is, to establish CFM entities for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer violation issue.

What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and do CFM over those? Oh,

that is a different solution, right?  Then what do I do if I want to run CFM over some new type of

ethernet LSP in the future? More protocol hacks?  The point is to use CFM over an ethernet interface

without the underlying layers knowing. This is good networking architecture design, that simplifies

implementations and makes them more robust, as well as makes using them operationally much

easier. 

		2) The introductory sections in this draft give a lot of discussion about fast fault detection. I

		am puzzled by this given that GMPLS networks tend to run over quickly self-healing

		optical infrastructures. Is it therefore truly necessary to motivate this work by

		requiring fast CFMs?

	It is right that frequent CCMs are not required if the layers below Ethernet handle protection. However, the ID focuses on Ethernet LSPs where Ethernet is not just a single hop above a transport LSP. In this case Ethernet layer (for clarity GELS) may provide protection for Ethernet LSPs. In any case,  the whole point of the ID is to allow for the appropriate configuration of CFM for Ethernet LSPs with GMPLS.

	E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within a network.

		   [IEEE-CFM] aspects that are relevant for the connectivity monitoring

		4) Is this the right place to define this document or should this be done in GELS?

		 

		   Ethernet LSP is signalled the associated MEPs should be automatically

		 

		To my point in #1 above, you should use the native CFM functionality over the ethernet interface and signal

		those capabilities to the bridges at both ends using the IEEE CFM signaling procedures (when and if they

		are created).  If you want to test the underlying GMPLS LSP(s), then you should use some

		other mechanism defined for that layer such as the work stated in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

	See the note to your point #1. There is no relation to the gmpls-LSP-ping draft. 

          --Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 4 Dec 2007 20:19:03 -0500

On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:

> Hi Thomas,
>                  My understanding of the ID was that RSVP-TE can be  
> used to ‘piggyback’ CFM set-up, otherwise the scenario is: usage of  
> RSVP-TE to set-up the LSP and NMS (meaning everything that is not  
> control plane) to enable to CFM for the LSP.

	As I understand it, the IEEE is working on set-up of CFM (and MEPs),  
as are some vendors I know. *)
This to me seems like the right way to do this.

> From your comment I see that you’re not happy with the fact the ID  
> is so technology specific am I right?

	Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.

> If yes do you agree with the fact that could be useful in general to  
> use the same signaling ‘session’ to set-up the LSP and to enable the  
> CFM?

	No, I do not agree.  Again, if CFM is to be set-up e2e, let the IEEE  
define this. Leave GMPLS to CCAMP.

	--Tom

>> Ethernet handle protection. However, the ID focuses on Ethernet  
>> LSPs where Ethernet is not just a single hop above a transport LSP.  
>> In this case Ethernet layer (for clarity GELS) may provide  
>> protection for Ethernet LSPs. In any case,  the whole point of the  
>> ID is to allow for the appropriate configuration of CFM for  
>> Ethernet LSPs with GMPLS.
>>

---

From: "Attila Takacs" <[email-masked]>
Date: Wed, 5 Dec 2007 03:03:26 +0100

Hi Tom,
please see inline.
Best regards,
Attila

	From: Thomas Nadeau [mailto:[email-masked]] 
	Sent: Wednesday, December 05, 2007 2:19 AM
	To: Diego Caviglia
	Cc: Attila Takacs; [email-masked]; [email-masked]
	Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

	

		Hi Thomas,

	As I understand it, the IEEE is working on set-up of CFM (and MEPs), as are some vendors I know. *)
	This to me seems like the right way to do this.

IEEE specified CFM and MIBs to setup CFM. 
Diego's summary is correct: one can use an NMS or a control plane to setup the data plane. In this case we propose to use GMPLS to setup the data plane: both forwarding + OAM.

		
		From your comment I see that you're not happy with the fact the ID is so technology specific am I right?  

I do not see your point with gluing. What do you mean by "as transport"? GMPLS is just controlling OAM, CFM is run solely in the data plane.

		If yes do you agree with the fact that could be useful in general to use the same signaling 'session' to set-up the LSP and to enable the CFM?

	No, I do not agree.  Again, if CFM is to be set-up e2e, let the IEEE define this. Leave GMPLS to CCAMP.

 
Sorry, I cannot follow.

	
	--Tom

	

		 Best Regards
		
		Diego

		
		Hi Thomas,

		Best regards,
		Attila

			

				

				

		
		          --Tom

---

From: <[email-masked]>
Date: Wed, 5 Dec 2007 06:55:15 -0000

I'm puzzled.  I read the draft and thought it was excellent.  It is addressing an important operational issue, ie a critical operational OAM requirement is to ensure that whatever mechanism (MP or CP) is used to set-up/tear-down a connection (so this only applies to co-cs or co-ps modes....the cl-ps mode does not have connections of course) is harmonised to the activation/deactivation of the OAM.....specifically a CV/CC flow.   If we don't ensure this then there will be obvious operational problems.  This is essentially what the draft is about.
 
Further, GMPLS is a generic OOB CP technique.....it is not a specific layer network technology per se (but it is specific in it's choice of signalling and routing components).  So one can apply a largely similar (GMPLS) CP technique to all co-cs mode technologies (whether they are partitioning a space, freq or time resource - see Note) and co-ps mode technologies (which only applies to partitioning a time resource - see Note) on the assumption that the technology is correctly architected in the DP for the mode considered.  It's pretty hard not to correctly architect the co-cs mode, but it's quite easy to incorrectly architect the co-ps mode, eg one can't violate the rules of a connection in the co-cs mode but one can in the co-ps mode.
 
Note - When we partition a time resource in regular time-slices we create a co-cs mode layer network.  When we partition a time resource in irregular time-slices we create a co-ps mode layer network.  More information on labelling and resource partitioning can be found in the work on unified modelling (of networks) in G.800.
 
regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Attila Takacs
Sent: 05 December 2007 02:03
To: Thomas Nadeau; Diego Caviglia
Cc: [email-masked]
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

Hi Tom,
please see inline.
Best regards,
Attila

  _____  

Hi Thomas,

 
 
Sorry, I cannot follow.

--Tom

 Best Regards

Diego

  _____  

Hi Thomas,

Best regards,
Attila

  _____  

          --Tom

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 5 Dec 2007 05:33:11 -0500

Hi Tom- 

Thanks for your review; please see comments in-line.  

Thanks

Regards... Zafar 

> Sent: Tuesday, December 04, 2007 8:43 AM
> To: [email-masked]
> Cc: Otani Tomohiro; Zafar Ali (zali)
> Subject: draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt 
> 
> 
> 		clear what you are trying to achieve.  

Sure we will spend efforts to clarify the text further. 

> For example,
> 		both). 

Data plane. 

> At least to my reading.
> 		will support 4204?  

Yes, LMP is already widely implemented (for GMPLS) and already provides
lots of GMPLS OAM solutions. I don't see any reason not to reuse it. 

> This also seems to beg the question

No, I don't think so. Reusing existing protocol/ tool further helps this
cause. 

> 		are statements like "send Test messages", but 

All encoding methods for TEST message that are defined in LMP
specification are assumed to be permissible. We can add a more elaborate
text to state the same. 

> 		completely, and if not, what percentage of coverage is

Yes, it does guarantee data plane connectivity. We can chat more
off-line on this. 

> 	similar enough to reuse that object.

Sure, we will look into this. 

> 	5) Is the link verification actually sent over the LMP 
> control channel or

Control messages to setup link/ LSP verification, e.g., BeginVerify,
etc. are sent via control channel and "Test" message is sent in-band of
LSP. Think of LSP as a TE link. 

> 	over the control channel, 

You meant "Test" message is not sent over the control channel, right.
Yes, this is also the case of this draft. 

> and since you want to verify the
> 	6) I suggest passing this document by the MPLS WG and 
> the LSP ping co- authors

Most certainly. We will send a private email to LSP Ping co-authors and
MPLS WG Chairs (w/ CCAMP WG Chair cc'ed).

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Dec 2007 08:09:38 -0500

>> 		or not you are verifying the control or data planes (or

	Can you explain in the document how this works? That, how do  
intermediate
nodes use LMP to check the data plane along the path. It seems to me  
for instance,
that since you are using LMP, you are testing each "segment" of the  
optical path.
This is certainly not end2end testing, so please be clear on this.   
Also the procedures
for how this works need to be clear. Take a look at RFC4379 for  
examples of how
they (we) specified this. The clearest form IMHO is to use pseudo-code/ 
algorithmic
descriptions of all the steps. This way everyone can clearly see what  
is going on
here.

> No, I don't think so. Reusing existing protocol/ tool further helps  

	See below.

> specification are assumed to be permissible. We can add a more  

	Cool. I think the document needs far more details for others to  
implement/understand
it for sure.

> Yes, it does guarantee data plane connectivity. We can chat more

	OK.

> LSP. Think of LSP as a TE link.
	
	This gets to my point about "too many moving parts". What concerns me
about this is not the re-use of LMP per se; thats a good idea in the  
sense of
code/protocol re-use; however, what worries me is one protocol  
stimulating
actions in another like this. There are security implications here  
that need to
be addressed. Also, how certain are you that the implementations of  
LMP out there
will all behave the same way once you initiate the generation of these  
messages?

> Yes, this is also the case of this draft.

	This needs to be clarified.

> MPLS WG Chairs (w/ CCAMP WG Chair cc'ed).

	Thanks.

	--Tom

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 5 Dec 2007 17:27:44 +0100

Hi Neil,

           Yes I totally agree with your analysis.

The is not going to redefine or reinvent the OAM that, as Thomas as pointed out, is done by IEEE, the ID just specify how to use a control plane mechanism (GMPLS) set-up at the same time data plane circuit and the related OAM.

Frankly specking I don't see any layer violation here.

BR

Diego

From: [email-masked] [mailto:[email-masked]] 
Sent: martedì 4 dicembre 2007 22.55
To: Attila Takacs; [email-masked]; Diego Caviglia
Cc: [email-masked]
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

regards, Neil

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On Behalf Of Attila Takacs
	Sent: 05 December 2007 02:03
	To: Thomas Nadeau; Diego Caviglia
	Cc: [email-masked]
	Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

	Hi Tom,

	please see inline.

	Best regards,

	Attila

		

		Hi Thomas,

			

	 

	 

	Sorry, I cannot follow.

		 

		--Tom

		

		 Best Regards

		Diego

		

		Hi Thomas,

		Best regards,
		Attila

		easier. 

				requiring fast CFMs?

		          --Tom

---

From: Dan Li <[email-masked]>
Date: Thu, 06 Dec 2007 01:00:41 +0800

MessageHi,

I think there is a misunderstanding with respect to the objective of this draft. 

As I read this draft, it describes how to extend the RSVP protocol to support the configuration/enable the OAM function of Ethernet LSP, which I think is a good thing to do, it is not saying to use signaling protocol to do the OAM work. But anyway, it may be necessary to clarify the objective at the beginning of this draft.

Regards,

Dan

  ----- Original Message ----- 
  From: Diego Caviglia 
  To: [email-masked] ; Attila Takacs ; [email-masked] 
  Cc: [email-masked] 
  Sent: Thursday, December 06, 2007 12:27 AM
  Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

  Hi Neil,

  BR

  Diego

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

  regards, Neil

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] On Behalf Of Attila Takacs
    Sent: 05 December 2007 02:03
    To: Thomas Nadeau; Diego Caviglia
    Cc: [email-masked]
    Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

    Hi Tom,

    please see inline.

    Best regards,

    Attila

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

      Hi Thomas,

     

     

    Sorry, I cannot follow.

       

      --Tom

       Best Regards

      Diego

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

      Hi Thomas,

      Best regards,
      Attila

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

      easier. 

          requiring fast CFMs?

                --Tom

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 5 Dec 2007 17:52:41 +0100

Hi Thomas,

                  Please see some more comment in line.

BR

Diego

From: Thomas Nadeau [mailto:[email-masked]] 
Sent: martedì 4 dicembre 2007 17.19
To: Diego Caviglia
Cc: Attila Takacs; [email-masked]; [email-masked]
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

Hi Thomas,

[DC] no doubt about this and in fact I don't think the ID was about defining the CFM is was just about the usage of GMPLS to enable it.

[DC] I think that we have a total agreement on this, no one is saying that CCAMP has to define the or re-define the CFM as no one redefined g707 or other SDH ITU-T spec when we developed GMPLS for SONET/SDH.

          --Tom

 Best Regards

Diego

 

Hi Thomas,

Best regards,
Attila

	 

easier. 

		requiring fast CFMs?

	 

		 

		 

          --Tom

---

From: "Attila Takacs" <[email-masked]>
Date: Wed, 5 Dec 2007 20:37:16 +0100

Hi all,
 
Neil's and Dan's summary are exact. Thanks for your comments!
 
Maybe the title of the ID caused the misunderstanding, it would say more if it would read: "GMPLS RSVP-TE Extensions to *Control* Ethernet OAM".
Nevertheless, when updating the ID we will clarify our point even more.
 
Best regards,
Attila

	From: Dan Li [mailto:[email-masked]] 
	Sent: Wednesday, December 05, 2007 6:01 PM
	To: Diego Caviglia; [email-masked]; Attila Takacs; [email-masked]
	Cc: [email-masked]
	Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

	Hi,

	 
	Regards,
	 
	Dan

		----- Original Message ----- 
		From: Diego Caviglia <mailto:[email-masked]>  
		To: [email-masked] ; Attila Takacs <mailto:[email-masked]>  ; [email-masked] 
		Cc: [email-masked] 
		Sent: Thursday, December 06, 2007 12:27 AM
		Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

		Hi Neil,

		BR

		Diego

		regards, Neil

			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] On Behalf Of Attila Takacs
			Sent: 05 December 2007 02:03
			To: Thomas Nadeau; Diego Caviglia
			Cc: [email-masked]
			Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

			Hi Tom,

			please see inline.

			Best regards,

			Attila

				

				Hi Thomas,

					

			 

			 

			Sorry, I cannot follow.

				 

				--Tom

				

				 Best Regards

				Diego

				

				Hi Thomas,

				Best regards,
				Attila

				easier. 

					requiring fast CFMs?

				          --Tom

---

From: Loa Andersson <[email-masked]>
Date: Wed, 05 Dec 2007 21:36:54 +0100

All,

I'm normally a bit careful with models "layer networks" that seems
to be a rather cumbersome way of explaining the obvious; however
in this case when it is used demonstrate that no layer violation
is at hand I is inclined to accept that result.

I also agree with Dan that it seems to be a good idea to use
RSVP-TE to provision OAM functionality is a good idea.

With that it we should just go ahead and accept this as a
ccamp work item.

/Loa

Dan Li wrote:
> As I read this draft, it describes how to extend the RSVP protocol 

to support the configuration/enable the OAM function of Ethernet LSP,

which I think is a good thing to do, it is not saying to use signaling

protocol to do the OAM work. But anyway, it may be necessary to clarify

the objective at the beginning of this draft.

-- 
Loa Andersson

---

From: Wataru Imajuku <[email-masked]>
Date: Thu, 06 Dec 2007 05:52:45 +0900

Hi, Attila

I understand this proposal automates manual configuration to set
CFM interval in data plane.

Control of CFM interval is new issue which GMPLS signaling
mechanism has not covered.

Although you outline Ethernet OAM functionality in section 2, I
think it is better to describe what is difference and what is common in
OAM functionality compared to circuit switched technologies

which GMPLS has been covered.

On the other hand, I could not understand why do you need M bit in
Admin Status Object.

Why do not use A=1 ?

Is the objective of M bit to stop sending CCM temporally
?

Best Regards

Wataru

At 04:37 07/12/06, Attila Takacs wrote:

"urn:schemas-microsoft-com:vml" xmlns:o =
"urn:schemas-microsoft-com:office:office" xmlns:w =
"urn:schemas-microsoft-com:office:word" xmlns:st1 =
"urn:schemas-microsoft-com:office:smarttags">

Hi all,

Neil's and Dan's summary are
exact. Thanks for your comments!

Maybe the title of the ID
caused the misunderstanding, it would say more if it would read:
"GMPLS RSVP-TE Extensions to *Control* Ethernet OAM".

Nevertheless, when updating the ID we will clarify our point even
more.

Best regards,

Attila

From: Dan Li
[mailto:[email-masked]]

To: Diego Caviglia; [email-masked]; Attila Takacs;
[email-masked]

Cc: [email-masked]

Hi,

I think there is a misunderstanding with respect to the objective of
this draft.

As I read this draft, it describes how to extend the RSVP protocol to
support the configuration/enable the OAM function of Ethernet LSP, which
I think is a good thing to do, it is not saying to use signaling protocol
to do the OAM work. But anyway, it may be necessary to clarify the
objective at the beginning of this draft.

Regards,

Dan

----- Original Message -----

From: Diego
Caviglia

To:
[email-masked] ; Attila Takacs ; [email-masked]

Cc: [email-masked]

Hi Neil,

Frankly specking I don$BCU(B see any layer violation here.

BR

Diego

Sent: marted$Bw(B4 dicembre 2007 22.55

Cc: [email-masked]

regards, Neil

-----Original Message-----

Cc: [email-masked]

Hi Tom,

please see inline.

Best regards,

Attila

To: Diego Caviglia

Hi Thomas,

My understanding of the ID was that RSVP-TE can be used to $BAQ(Biggyback$BC(BCFM set-up, otherwise the scenario is: usage of RSVP-TE to set-up the LSP and NMS (meaning everything that is not control plane) to enable to CFM for the LSP.

From your comment I see that you$BCS(Be not happy with the fact the ID is so technology specific am I right?

If yes do you agree with the fact that could be useful in general to use the same signaling $BAT(Bession$BC(Bto set-up the LSP and to enable the CFM?

Sorry, I cannot follow.

--Tom

Best Regards

Diego

Sent: marted$Bw(B4 dicembre 2007 11.30

To: Attila Takacs

Hi Thomas,

Best regards,

Attila

To: [email-masked]

easier.

requiring fast CFMs?

--Tom

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

Wataru Imajuku, Ph.D.@NTT Network Innovation Labs

TEL: +81-46-859-4315

FAX: +81-46-859-5541

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 Dec 2007 21:28:09 -0000

Hi Wataru,

> On the other hand, I could not understand why do you need M bit in Admin 
> Status Object.
> Why do not use A=1 ?
> Is the objective of M bit to stop sending CCM temporally ?

The A bit is already defined as:
         When set, indicates that the local actions related to the
         "administratively down" state should be taken.

The I bit is additionally defined as:
         When set, indicates that alarm communication is disabled for
         the LSP and that nodes SHOULD NOT add local alarm information.

Neither of these is the same as the proposed M bit
        When this bit is set the connectivity monitoring of the LSP is 
disabled.

So, yes, the proposal is that the M bit adds new function to turn off OAM 
processing on an LSP reqgardless of the administrative status of the LSP. 
Whether that is a useful function is up for discussion.

Adrian

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Dec 2007 17:12:20 -0500

What do we do for the other signaling protocols outside of CCAMP?
Do we now extend BGP, RSVP-TE (for MPLS), and LDP to control OAM there
as well?

	--Tom

>>  The is not going to redefine or reinvent the OAM that, as Thomas  
>> as pointed out, is done by IEEE, the ID just specify how to use a  
>> control plane mechanism (GMPLS) set-up at the same time data plane  
>> circuit and the related OAM.
>>
>>
>>
>>  I'm puzzled.  I read the draft and thought it was excellent.  It  
>> is addressing an important operational issue, ie a critical  
>> operational OAM requirement is to ensure that whatever mechanism  
>> (MP or CP) is used to set-up/tear-down a connection (so this only  
>> applies to co-cs or co-ps modes....the cl-ps mode does not have  
>> connections of course) is harmonised to the activation/deactivation  
>> of the OAM.....specifically a CV/CC flow.   If we don't ensure this  
>> then there will be obvious operational problems.  This is  
>> essentially what the draft is about.
>>
>>
>>
>>  Further, GMPLS is a generic OOB CP technique.....it is not a  
>> specific layer network technology per se (but it is specific in  
>> it's choice of signalling and routing components).  So one can  
>> apply a largely similar (GMPLS) CP technique to all co-cs mode  
>> technologies (whether they are partitioning a space, freq or time  
>> resource - see Note) and co-ps mode technologies (which only  
>> applies to partitioning a time resource - see Note) on the  
>> assumption that the technology is correctly architected in the DP  
>> for the mode considered.  It's pretty hard not to correctly  
>> architect the co-cs mode, but it's quite easy to incorrectly  
>> architect the co-ps mode, eg one can't violate the rules of a  
>> connection in the co-cs mode but one can in the co-ps mode.
>>
>>
>>
>>  Note - When we partition a time resource in regular time-slices we  
>> create a co-cs mode layer network.  When we partition a time  
>> resource in irregular time-slices we create a co-ps mode layer  
>> network.  More information on labelling and resource partitioning  
>> can be found in the work on unified modelling (of networks) in G.800.
>>
>>
>>
>>  regards, Neil
>>
>>                       My understanding of the ID was that RSVP-TE  
>> can be used to 'piggyback' CFM set-up, otherwise the scenario is:  
>> usage of RSVP-TE to set-up the LSP and NMS (meaning everything that  
>> is not control plane) to enable to CFM for the LSP.
>>
>>
>>
>>    Diego's summary is correct: one can use an NMS or a control  
>> plane to setup the data plane. In this case we propose to use GMPLS  
>> to setup the data plane: both forwarding + OAM.
>>
>>        From your comment I see that you're not happy with the fact  
>> the ID is so technology specific am I right?
>>
>>
>>
>>    I do not see your point with gluing. What do you mean by "as  
>> transport"? GMPLS is just controlling OAM, CFM is run solely in the  
>> data plane.
>>
>>
>>
>>
>>
>>        If yes do you agree with the fact that could be useful in  
>> general to use the same signaling 'session' to set-up the LSP and  
>> to enable the CFM?
>>
>>
>>
>>      No, I do not agree.  Again, if CFM is to be set-up e2e, let  
>> the IEEE define this. Leave GMPLS to CCAMP.
>>
>>
>>
>>
>>
>>    Sorry, I cannot follow.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>      --Tom
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>       Best Regards
>>
>>
>>      Diego
>>
>>
>>      From: [email-masked] [mailto:owner- 
>> [email-masked]] On Behalf Of Thomas Nadeau
>>      The application of the draft is exactly for what you are  
>> calling out: when CFM is run natively over the Ethernet interfaces.  
>> The document focuses on GELS and Ethernet LSPs. That is, to  
>> establish CFM entities for GMPLS controlled Ethernet LSPs. Hence, I  
>> think there is no layer violation issue.
>>
>>        It is right that frequent CCMs are not required if the  
>> layers below Ethernet handle protection. However, the ID focuses on  
>> Ethernet LSPs where Ethernet is not just a single hop above a  
>> transport LSP. In this case Ethernet layer (for clarity GELS) may  
>> provide protection for Ethernet LSPs. In any case,  the whole point  
>> of the ID is to allow for the appropriate configuration of CFM for  
>>          those capabilities to the bridges at both ends using the  
>> IEEE CFM signaling procedures (when and if they
>>
>>          other mechanism defined for that layer such as the work  
>> stated in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
>>

---

From: "Attila Takacs" <[email-masked]>
Date: Thu, 6 Dec 2007 04:07:37 +0100

Hi Wataru,
 
Just adding to Adrian's points...
 
I think it is useful to separate A and M bits. When the LSP is put in administratively down, e.g.,  to avoid it is carrying traffic for any reason, it would be still useful to run data plane OAM so one knows the data plane is in tact when the LSP is put back operational. That is,  A=1, M=0. On the other hand, e.g., in the case of planed maintenance, one might want to turn data plane OAM off as well, having A=1, M=1.
 
Regarding the I bit, I think even if GMPLS alarm communication is disabled, the actual monitoring of data plane connectivity is needed, again to have the up to date status of the data plane.
 
In summary, I think having a separate M bit is useful, and accounts for flexibility.
 
Best regards,
Attila

	From: Wataru Imajuku [mailto:[email-masked]] 
	Sent: Wednesday, December 05, 2007 9:53 PM
	To: Attila Takacs
	Cc: [email-masked]
	Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

	Hi, Attila
	
	 I understand this proposal automates manual configuration to set CFM interval in data plane.
	 Control of CFM interval is new issue which GMPLS signaling mechanism has not covered.
	 Although you outline Ethernet OAM functionality in section 2, I think it is better to describe what is difference and what is common in OAM functionality compared to circuit switched technologies 
	which GMPLS has been covered.
	
	 On the other hand, I could not understand why do you need M bit in Admin Status Object.
	 Why do not use A=1 ?
	 Is the objective of M bit to stop sending CCM temporally ?
	
	Best Regards
	Wataru

		"urn:schemas-microsoft-com:vml" xmlns:o = "urn:schemas-microsoft-com:office:office" xmlns:w = "urn:schemas-microsoft-com:office:word" xmlns:st1 = "urn:schemas-microsoft-com:office:smarttags"> 
		Hi all,

		 
		Best regards,
		Attila

			

			Cc: [email-masked]

			Hi,

			  

			Regards,

			Dan

			----- Original Message ----- 

			
			Cc: [email-masked] 

			Hi Neil,

			

			

			Frankly specking I don稚 see any layer violation here.

			BR

			Diego

			

			Sent: marted・4 dicembre 2007 22.55

			Cc: [email-masked]

			

			

			

			

			regards, Neil

			-----Original Message-----

			
			
			Cc: [email-masked]

			Hi Tom,

			please see inline.

			Best regards,

			Attila

			

			
			To: Diego Caviglia

			

			
			
			Hi Thomas,

			                 My understanding of the ID was that RSVP-TE can be used to 叢iggyback？CFM set-up, otherwise the scenario is: usage of RSVP-TE to set-up the LSP and NMS (meaning everything that is not control plane) to enable to CFM for the LSP.

			

				From your comment I see that you池e not happy with the fact the ID is so technology specific am I right?  

			

		

				If yes do you agree with the fact that could be useful in general to use the same signaling 壮ession？to set-up the LSP and to enable the CFM?

			

		
		Sorry, I cannot follow.

			

			

			--Tom

			

			  
			 Best Regards

			Diego

			
			Sent: marted・4 dicembre 2007 11.30
			
			To: Attila Takacs

			

			Hi Thomas,

			Best regards,
			
			Attila

			
			
			To: [email-masked]

		

		

		
		easier. 

				requiring fast CFMs?

		
		         --Tom

---

From: <[email-masked]>
Date: Thu, 6 Dec 2007 09:55:04 -0000

Hi Tom,

You asked 05 December 2007 22:12
> 	What do we do for the other signaling protocols outside
> of CCAMP? Do we now extend BGP, RSVP-TE (for MPLS), and LDP 
> to control OAM there as well?
> 
> 	--Tom

The principle I gave stands....this behaviour is required irrespective of what mechanism (CP signalling or MP provisioning) is responsible for setting-up/tearing-down a *connection*.  This is not a new requirement. I've mentioned this requirement several times in posts to various WGs over the years and you will find this requirement mentioned in Y.1711.  We also stated this as a requirement in the now expired draft 'draft-willis-pwe3-requirements-00.txt (which can still be found at http://www2.tools.ietf.org/html/draft-willis-pwe3-requirements-00) when attempting to provide guidance to PWE3 on OAM requirements back in 2004. In section 1.2 therein we gave some background wrt to the different OAM required for the 3 network modes of cl-ps, co-ps and co-cs (as the OAM required is not the same in all 3 cases)....here is the relevant extract wrt to the activation/deactivation topic of this thread:

".....the OAM activation/deactivation must be harmonized with the set-up/tear-down of the path.  Failure to harmonize OAM activation/deactivation with PW set-up/tear-down will lead to either:
- lack of OAM protection when the PW is set-up, or false alarms
  when the PW is torn-down;  or
- OAM being activated prior to PW set-up and significant problems due
  to operator error."

You'll note I highlighted the word *connection* above....this is rather important.  One can't activate/deactivate OAM in concert with connection set-up/tear-down if one does not have a connection, eg cl-ps mode.  There are also no problems when dealing with the co-cs mode as this is forced to respect the requirements of a connection (which, to summarise are: (i) single source (ii) no re-ordering of traffic units).  However, the LDP form of MPLS does not respect the requirements of a connection as it creates a mp2p merging construct.....PHP has a similar merging behaviour on the last hop on an LSP. So the activation/deactivation of OAM in concert with such constructs has no meaning.....indeed, one can't even say we have a proper layer network here, and this is not simply due to violating the rules of a connection but results from the fact that an MPLS traffic unit does not provide consistent characteristic information, eg the label field can take on at least 4 different semantics (and this list is still growing, eg fat PWs). If not obvious what the problem is here, if traffic gets misdirected then the receiving node could misinterpret the meaning of the label.  

So, we can't apply the requirement MPLS LDP/PHP networks.....these can only use 'on-demand' OAM mechanisms.....just the nature of the beast. 

However, when we have a co-cs or co-ps mode network that does respect the requirements of a connection then it makes a huge amount of operational sense to make sure one activates/deactivates the OAM in conjunction with the connection set-up/tear-down.

And this is not simply a matter of 'good housekeeping' for the service provider, including things like the ability to provide a protection-switching capability, there is a security issue here......which is especially germane in the case of a co-ps mode technology based on label-swapping.  That is, if one has a defect that causes misdirected traffic it is important to be able to proactively detect such a case and take appropriate action, eg squelch the traffic, in order to protect the integrity of the affected client traffic.

This issue is not a problem for networks that have network unique and non-swapped labelling, ie all cl-ps mode technologies and PBB-TE in the co-ps mode, ie these network are inherently robust to misconnectivity defects without any OAM at all (since each traffic unit essentially carries it own CV function due to presence of the SA).  However, in the case of PBB-TE we still require the OAM activation/deactivation in concert with the connection set-up/tear-down as we need to distinguish the cases of 'quiescent client traffic' from 'simple break'.  Moreover, as I already noted, we also need the OAM for protection-switching requirements.

regards, Neil 
> 
> 	
> > All,
> >
> > I'm normally a bit careful with models "layer networks"
> that seems to
> > be a rather cumbersome way of explaining the obvious;
> however in this
> > case when it is used demonstrate that no layer violation is
> at hand I
> > is inclined to accept that result.
> >
> > I also agree with Dan that it seems to be a good idea to
> use RSVP-TE
> > to provision OAM functionality is a good idea.
> >
> ccamp work
> > item.

---

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Thu, 6 Dec 2007 11:33:56 +0100

Hi Tom.

Good question, but I guess this can already find some pieces of answers. Quoting the BFD base draft: "For example, an OSPF implementation may request a BFD session to be established to a neighbor discovered using the OSPF Hello protocol."

Personally, I believe it is useful to have a signaling mechanism to configure OAM in a distributed environment. Considering a GMPLS context, RSVP-TE is just there between end points. What is more, when establishing an LSP, I am concerned with recovery aspects (already there thanks to the Protection object) and obviously with the OAM allowing this recovery to happen (and OAM is not implicit in case of packet-switched connection).

Regards,

Julien

-----Original Message-----

	--Tom

---

From: <[email-masked]>
Date: Thu, 6 Dec 2007 19:14:17 -0000

Loa,
> With that it we should just go ahead and accept this as a
If you are asking whether this should be adopted as a WG item then I am in favour.

regards, neil

> From: Loa Andersson [mailto:[email-masked]] 
> Sent: 05 December 2007 20:37
> To: Dan Li
> Cc: Diego Caviglia; Harrison,N,Neil,DMN R; Attila Takacs; 
> [email-masked]; [email-masked]
> I'm normally a bit careful with models "layer networks" that 
> seems to be a rather cumbersome way of explaining the 
> obvious; however in this case when it is used demonstrate 
> that no layer violation is at hand I is inclined to accept 
> that result.
> 
> >   The is not going to redefine or reinvent the OAM that, as 
> Thomas as 
> > pointed out, is done by IEEE, the ID just specify how to 
> use a control 
> > plane mechanism (GMPLS) set-up at the same time data plane 
> circuit and 
> > the related OAM.
> > 
> >    
> > 
> >   I'm puzzled.  I read the draft and thought it was 
> excellent.  It is addressing an important operational issue, 
> ie a critical operational OAM requirement is to ensure that 
> whatever mechanism (MP or CP) is used to set-up/tear-down a 
> connection (so this only applies to co-cs or co-ps 
> modes....the cl-ps mode does not have connections of course) 
> is harmonised to the activation/deactivation of the 
> OAM.....specifically a CV/CC flow.   If we don't ensure this 
> > specific layer network technology per se (but it is 
> specific in it's 
> > choice of signalling and routing components).  So one can apply a 
> > largely similar (GMPLS) CP technique to all co-cs mode technologies 
> > (whether they are partitioning a space, freq or time resource - see 
> > Note) and co-ps mode technologies (which only applies to 
> partitioning 
> > a time resource - see Note) on the assumption that the 
> technology is 
> > correctly architected in the DP for the mode considered.  
> It's pretty 
> > hard not to correctly architect the co-cs mode, but it's 
> quite easy to 
> > incorrectly architect the co-ps mode, eg one can't violate 
> the rules 
> > of a connection in the co-cs mode but one can in the co-ps mode.
> > 
> >    
> > 
> > create a co-cs mode layer network.  When we partition a 
> time resource 
> > in irregular time-slices we create a co-ps mode layer 
> network.  More 
> > information on labelling and resource partitioning can be 
> found in the 
> > work on unified modelling (of networks) in G.800.
> > 
> >    
> > 
> >   regards, Neil
> > 
> >     From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Attila Takacs
> >                        My understanding of the ID was that 
> RSVP-TE can 
> > be used to 'piggyback' CFM set-up, otherwise the scenario 
> is: usage of 
> >     Diego's summary is correct: one can use an NMS or a 
> control plane 
> > to setup the data plane. In this case we propose to use 
> GMPLS to setup 
> > the data plane: both forwarding + OAM.
> > 
> > general to use the same signaling 'session' to set-up the 
> LSP and to 
> > enable the CFM?
> > 
> >        
> > 
> >       No, I do not agree.  Again, if CFM is to be set-up 
> e2e, let the 
> > IEEE define this. Leave GMPLS to CCAMP.
> > 
> >      
> > 
> >      
> > 
> >     Sorry, I cannot follow.
> > 
> >      
> > 
> >      
> > 
> >        
> > 
> >        
> > 
> >        
> > 
> >       --Tom
> > 
> >        
> > 
> >        
> > 
> > 
> > 
> > 
> > 
> >        Best Regards
> > 
> > 
> >       Diego
> > 
> > 
> > 
> >       From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
> >         in the l2vpn WG about munging CFM + PWs.  To my 
> reading, this 
> > is essentially
> > 
> >         the same thing. If you want to run CFM, run it 
> natively over 
> > the ethernet interfaces and
> > 
> > document focuses on GELS and Ethernet LSPs. That is, to 
> establish CFM 
> > entities for GMPLS controlled Ethernet LSPs. Hence, I think 
> there is 
> >       What do I do if I want to set up MPLS ethernet LSPs 
> (i.e.: PWs) 
> > and do CFM over those? Oh,
> > 
> >       ethernet LSP in the future? More protocol hacks?  The 
> point is 
> > to use CFM over an ethernet interface
> > 
> >         It is right that frequent CCMs are not required if 
> the layers 
> > below Ethernet handle protection. However, the ID focuses 
> on Ethernet 
> > LSPs where Ethernet is not just a single hop above a 
> transport LSP. In 
> > this case Ethernet layer (for clarity GELS) may provide 
> protection for 
> >           For the purposes of this document, we only 
> discuss Ethernet 
> > OAM
> > 
> >               established.  Further more, GMPLS signalling 
> should be 
> > able to
> >

---

From: Loa Andersson <[email-masked]>
Date: Thu, 06 Dec 2007 20:23:05 +0100

yes - that was what I asked :)

/Loa

-- 
Loa Andersson