RE: CCAMP drafts for adoption

["Don Fedyk" <dwfedyk@nortel.com>]

Hi Tom
Please see inline, 

>On 12/2/08 5:32 PM, "Don Fedyk" <dwfedyk@nortel.com> wrote:
>
>> Hi Nitin 
>> 
>>> -----Original Message-----
>>> From: owner-ccamp@ops.ietf.org
>>> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur
>>> 
>>> 
>>>>> draft-takacs-ccamp-oam-configuration-fwk-01.txt
>>>>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
>>> 
>>> Do not support either of these.
>>> 
>>> From the oam-config-fwk draft:
>>>> A new useful application of RSVP-TE is OAM configuration
>>>> and control for transport networks.
>>> 
>>> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why
>>> do we need
>>> another mechanism? What are the limitations of lsp-ping that warrant
>>> this new mechanism?
>> 
>> These drafts support configuration of data plane OAM functions when
you
>> are using RSVP-TE to setup the paths.  The alternative is operator
>> configuration. It has nothing to do with LSP Ping.
>> 
>>> 
>>>> When RSVP-TE is used for LSP establishment it is desirable to bind
>>>> OAM setup to connection establishment signalling to avoid two
>>>> separate management/configuration steps
>>> 
>>> draft-ietf-bfd-mpls specifies how to use LSP-Ping for
>>> automatic setup of
>>> BFD-based OAM.
>> 
>> So LSP Ping sets up BFD? Interesting.  While I can see this might be
>> useful in the case of LDP when debugging a problem you do have issues
>> with LSP-Ping reaching all path combinations and certain error
>> scenarios. I don't think this is a comprehensive mechanism.
>
>    Don,
>
>    LSP ping is used to "bootstrap" BFD for MPLS networks. It is a
perfectly
>sound method of solving the problem it sought to solve. Please take a
look
>at this draft-ietf-bfd-mpls-07 for a description of how this works if
you
>are unfamiliar.   

Tom,

When I read this draft what I read is that an MPLS LSP may take one or 
more paths and that a BFD session is set up for one or more of these
paths. 
Since the network may change, the MPLS LSP may vary the number of paths 
it takes from time to time (ECMP may come and go). So if you have a 
problem you may fined you have not set up the BFD session on a LSP path 
or there may well be even 2 BFD sessions running on what is now a single

LSP path.  In a big network I think this may be a bit of an issue. 

>
>> This is clearly different than what we are specifying in the Ethernet
>> OAM case. 
>
>    While not a comprehensive mechanism for doing Ethernet OAM, don't
you
>think that defining how Ethernet OAM works (or is configured) should be
done
>by the IEEE?  What you are proposing here by combining these different
>things together is what at least smells like what was thrown out in
L2VPN a
>number of years ago due to a layer violation when it was tried for
>Ethernet/VPLS PWs. 

We absolutely have left OAM for the IEEE. In fact the whole data plane 
and OAM is specified in the IEEE. All we are proposing is to optionally 
signal a IEEE OAM profile of the type of MIPs and MEPs on the
connection. 
This is the point of GMPLS. Generalized control of other technologies.

RSVP-TE sessions that don't use these objects would use normal RSVP-TE 
processing. That is why we have extensible protocols.  As Attila points 
out OAM for other technologies such as optical could also use these 
GMPLS mechanisms. 

When you setup paths and CCM in this manner there is no doubt it is 
protecting the traffic path. 

Regards,
Don 

>
>    --Tom