[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CCAMP drafts for adoption
Hi Nitin,
>
> 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).
>
There are some options here.
First it has clear benefits to have the OAM config bound to the Path
message and so to the actual LSP establishment as this ensures that the
connection and its OAM is coupled. This is something you cannot ensure
with LSP Ping.
Alternatively, if one just wants to configure MEPs one may carry the
proposed TLVs as part of Call establishment, this way only the endpoints
will take part in signaling.
On the other hand, if one needs to configure MIPs, the signaling needs
to pass intermediate nodes hence the need to use the Path message is
obvious.
> 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.
>
How would you configure MIPs with LSP Ping? I assume you would need to
use at least as many transactions (and as such have as many failure
scenarios) as many intermediate nodes the LSP has. (Not to mention that
you need to get the list of intermediate nodes and the info on the
success/failure of LSP establishment from another protocol.)
Compare this to a single Path message in the case of RSVP-TE.
Best regards,
Attila
> > 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
> > > > >
> > > > >
> > > >
> > >
> >
>