[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CCAMP drafts for adoption
> > 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
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
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).