RE: CCAMP drafts for adoption

I like your clear explanation (no pun intended). I understand your view-point....my views are as below...

> The difference is that GMPLS is a control plane, while OAM is supposed to work in the data plane. In transport

> networks control plane and data plane are separated. In fact, OAM should work without and should not depend upon

> control plane at all. You can not send Ping messages over lambda layer network connection, can you?

> On the other hand, you can use GMPLS to consistently configire OAM function on the connection NEs, and that's what

> these drafts as I understand are about.

I understand the motivation of these drafts and I totally agree with that.

> In other words, in MPLS , LSP Ping is OAM, while GMPLS can only automate OAM configuration, it can not relalize

I agree that LSP-Ping may not be the OAM mechanism for GMPLS LSPs. All I am saying is that LSP-Ping can be used to automate the OAM configuration. There is enough machinery available in lsp-ping to enable that. So why re-invent a new protocol? One could send lsp-ping messages (control-plane routed) containing the information needed to automate OAM.

Question: Isn't it simpler to use RSVP path messages to automate this ?

Answer: Yes it looks simpler.

Question: Then why is Nitin opposed ?

Answer: Because as this draft progresses, you will end up adding a whole bunch of TLVs/sub-TLVs and related error codes. And all these have nothing to do with a RSVP path message. The draft already has 3-4 sub-TLVs. In effect, the 2 drafts are defining a mini-OAM-boot-strapping protocol on top of RSVP path message.

From: Nitin Bahadur <nitinb@juniper.net>
To: Attila Takacs <Attila.Takacs@ericsson.com>; Adrian Farrel <adrian@olddog.co.uk>; ccamp@ops.ietf.org
Sent: Tuesday, December 2, 2008 5:01:11 PM
Subject: RE: CCAMP drafts for adoption

Hi Attlia,

What is the limitation of lsp-ping that prevents it from being
applied to GMPLS?
If an existing mechanism can be applied, then why not? If lsp-ping needs
extensions to support GMPLS LSPs, feel free to make/specify those
extensions.

Thanks
Nitin

> -----Original Message-----
> From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]
> Sent: Tuesday, December 02, 2008 1:52 PM
> To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org
> Subject: RE: CCAMP drafts for adoption
>
> Hi Nitin,
>
> Please note that these mechanisms are proposed for GMPLS and
> as such to provide support for any data plane technology
> specific OAM mechanism. As you noted LSP Ping is for MPLS and
> BFD only.
>
> Best regards,
> Attila
>
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur
> > Sent: Tuesday, December 02, 2008 10:35 PM
> > To: Adrian Farrel; ccamp@ops.ietf.org
> > Subject: RE: CCAMP drafts for adoption
> >
> >
> >
> > > > 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?
> >
> > > 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.
> > We should go along the same path for Ethernet OAM.
> >
> > Thanks
> > Nitin
> >
> >
>