RE: CCAMP drafts for adoption

[Nitin Bahadur <nitinb@juniper.net>]

> > 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? <snipped> We 
> should go along
> the same path for Ethernet OAM.
> 
> It is not applicable to either a PBB-TE switched path or, if 
> you are of that persuasion, an MPLS-TP switched path...as it 
> stands today. And it only goes downhill from there....

David, all that I am asking is that one can use the basic-bare-bones
definitions 
in lsp-ping to setup the Ethernet OAM params. I am not talking about
applicability nor I am
saying that one needs to use ping and trace based off lsp-ping for
PBB-TE LSPs. 

We have a whole bunch of stuff defined in RSVP. Obviously some of them
are not applicable for GMPLS LSPs. But that does not mean that we go
define G-RSVP (for GMPLS LSPs).
 
> I would think the inappropriateness of applying LSP-PING to 
> Ethernet OAM would be self evident...Ethernet OAM already has 
> it's own LB/LT functionality so mandating another loopback 
> exclusively for OAM configuration is gratuitously complex.

I am not asking you to use lsp-ping for LB/LT. I agree that ethernet OAM
already has that and indeed once should use that. I am just saying that
the setup can be done using lsp-ping.
 
> As for MPLS-TP, LSP-PING would need recasting as a "non-IP" 
> protocol to fit the mandated profile from the joint design 
> team and likely would benefit from a trip to the fat farm to 
> shed the other features it did not need within said profile...

LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping has
a reply-mode of *application channel* which can be used for things like
bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies would go
on the LSP reverse path (label-switched and not IP forwarded).

Thanks
Nitin