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.

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 

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)

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

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.

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

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

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

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

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