[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CCAMP drafts for adoption
Attila,
Very well put. I think I-Ds in question should become working group
drafts.
Thanks,
John
>-----Original Message-----
>From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]
>Sent: Wednesday, December 03, 2008 7:28 AM
>To: Nitin Bahadur; ccamp@ops.ietf.org
>Subject: 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
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>