RE: CCAMP drafts for adoption

[Nitin Bahadur <nitinb@juniper.net>]

> I would formulate this form the other way around. If we 
> already have a technology agnostic solution, read GMPLS, it 
> seems to be straightforward to continue using it. Then why not? :-)
> 
> One key benefit of using RSVP-TE is that OAM configuration is 
> bound to the actual LSP establishment this simplifies 
> management and avoids misconfiguration. With LSP Ping we 
> would need one mechanism to setup the LSPs (read *not* just 
> MPLS) using GMPLS and then apply another solution say 
> Generalized-LSP Ping to configure OAM; if I understand your 
> proposal right.

Yes...your understanding of my proposal is correct. 
But it would solve your issue of manual 
OAM configuration. Agreed, it's a 2-step control-plane process.
 
> From another perspective, what would be the use of LSP Ping 
> over, e.g., an optical network or Ethernet using CFM?

Just for setup of the OAM parameters. Ethernet OAM provides a bunch of
capabilities
(like LT/LB) and you would use them as-is. The advantage of using
lsp-ping is that only the LSP egress sees the OAM parmeters. 

If you add a new-TLV to the PATH msg, then you need to send it on every
PATH msg...
You really need to signal the parameters once during LSP-setup time (and
perhaps when the parameters are changed).

LSP-Ping has a whole bunch of stuff defined. Most of it is not
needed/applicable in various scenarios. But the advantage is that it's
all there. As you go ahead with defining a new mechanism, you will
gradually see other requirements/needs and you might end up re-inventing
lsp-ping in another form.

> Best regards,
> Attila
> 
> 
> 
> 
> > -----Original Message-----
> > From: Nitin Bahadur [mailto:nitinb@juniper.net]
> > Sent: Tuesday, December 02, 2008 11:01 PM
> > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org
> > 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
> > > > 
> > > > 
> > > 
> > 
>