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

[Loa Andersson <loa@pi.se>]

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@acreo.se
                                           loa@pi.se

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