PAPADIMITRIOU Dimitri | 2 Dec 13:49 2007
Picon

comment on draft-otani-ccamp-gmpls-routing-interlink-01.txt

hi - 

reading this doc. it seems that two additional elements of analysis
should be taken into account

o) setting up unidirectional PSC LSP (or even other type) leads to an
asymmetric bw counting that comes in addition to the setup bidirectional
LSP

o) ougoing information knowledge poses also the problem of the SC value
at the other end of the link e.g. [LS2C;PSC] link

note: there is a metric setting to be addressed when correlating
information at such boundary

thanks,
-d.

Adrian Farrel | 2 Dec 20:55 2007
Picon

Slides on line

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 

(Continue reading)

Weiqiang Sun | 3 Dec 05:20 2007
Picon

RE: Slides on line

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: owner-ccamp <at> ops.ietf.org [mailto:owner-ccamp <at> ops.ietf.org] On Behalf
Of Adrian Farrel
Sent: Sunday, December 02, 2007 2:56 PM
To: ccamp <at> ops.ietf.org
Cc: Brungard, Deborah A, ALABS
Subject: Slides on line

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)
(Continue reading)

Adrian Farrel | 4 Dec 04:53 2007
Picon

Fw: [mpls] working group early review ofdraft-ietf-mpls-mpls-and-gmpls-security-framework-01.txt

Hi CCAMP,

Please keep an eye on this work being done in the MPLS working group. It 
directly affects your protocol work.

Thanks,
Adrian
----- Original Message ----- 
From: "Loa Andersson" <loa <at> pi.se>
To: <mpls <at> ietf.org>
Sent: Tuesday, December 04, 2007 12:46 AM
Subject: [mpls] working group early review 
ofdraft-ietf-mpls-mpls-and-gmpls-security-framework-01.txt

> Working Group,
>
> at the working group meeting today we agreed that it is time for
> a *working group early review* of the
>
> draft-ietf-mpls-mpls-and-gmpls-security-framework-01.txt
>
> We want the working group participants to take the time to
> carefully read and comment on the draft.
>
> Please send your comments to the working group mailing list.
>
> Loa and George
>
> -- 
> Loa Andersson
(Continue reading)

Thomas Nadeau | 4 Dec 14:42 2007

draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt


	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.

(Continue reading)

Thomas Nadeau | 4 Dec 14:57 2007

draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt



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

Attila Takacs | 4 Dec 19:51 2007
Picon

RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

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

From: Thomas Nadeau [mailto:tnadeau <at> lucidvision.com]
Sent: Tuesday, December 04, 2007 2:58 PM
To: ccamp <at> ops.ietf.org
Cc: Attila Takacs; balazs.gero <at> ericsson.com
Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt



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

3) This document does not cover E-LMI. Why not?
E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within a network.
 

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?
Well, GELS is done in CCAMP...this seems to be the right place.
 

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
See the note to your point #1. There is no relation to the gmpls-LSP-ping draft. 
 
 
Loa Andersson | 4 Dec 20:26 2007
Picon

Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

Tom,

Thomas Nadeau wrote:
> 
> 
>     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 

did mean to say layering violation ???

/Loa

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

--

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson <at> acreo.se
                                           loa <at> pi.se

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

Thomas Nadeau | 4 Dec 20:28 2007

Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt


On Dec 4, 2007, at 2:26 PM, Loa Andersson wrote:

> Tom,
>
> Thomas Nadeau wrote:
>>
>>
>>    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
>
> did mean to say layering violation ???

	Yep. Typing too fast! *)

	--Tom

>
>
> /Loa
>
> 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
>>
>>
>
>
> -- 
> Loa Andersson
>
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  loa.andersson <at> acreo.se
>                                           loa <at> pi.se
>
> This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
>
>

Thomas Nadeau | 4 Dec 20:30 2007

Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt


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

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

From: Thomas Nadeau [mailto:tnadeau <at> lucidvision.com]
Sent: Tuesday, December 04, 2007 2:58 PM
To: ccamp <at> ops.ietf.org
Cc: Attila Takacs; balazs.gero <at> ericsson.com
Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt



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

3) This document does not cover E-LMI. Why not?
E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within a network.
 

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?
Well, GELS is done in CCAMP...this seems to be the right place.
 

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



 
 


Gmane