Dave,
As an operator with a very big deployment of MPLS and a lot of money
invested in OSS to manage said network, I do not want a different mechanism
to the one that has been deployed today to control OAM for any MPLS
networks, MPLS-TP included.
--Tom
On 12/2/08 6:01 PM, "David Allan" <dallan@nortel.com> wrote:
> HI Nitin:
>
> Thanks for replying....
> <snipped>
>
>> 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.
>
> But this still requires implementing a new protocol where it does not
> already exist, which also requires a *new* bare bones definition...
>
>> 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).
>
> Isn't that CCAMPs mandate?
>
> <snipped>
>
>> 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.
>
> I think the point was GMPLS applies to a lot of technologies that cannot
> do LSP-PING in the first place, which means such a signalling extension
> will be required nonetheless...
>
> <snipped>
>> 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).
>
> OK, I can see that such an approach could be made to work and would be
> desirable to some. On that basis, can I suggest you withdraw your
> objections to the Eth-Oam draft and move the TP parts of this discussion
> over to the MPLS list? That would seem appropriate...
>
> Cheers
> Dave
>
>