Re: [mpls-tp] Query on MPLS-TP lsp ping extensions

[Nitin Bahadur <[e-mail]>]

Hi Mukund,


On 5/8/10 6:08 AM, "Mukund Mani" <[e-mail]> wrote:

Hi Nitin

Thanks for the reply....

Indeed i too thought we are referring to the IP Channel type of 0x21, but then that means that the ACH header should be present
to indicate the control channel type. The draft does not mention that in LSP Ping with IP encapsulation section, though it does so
specifically in the non-IP section. Why do we really need the ACH in this case because the host stack has Ip addressing capability and the reply can be IP addressed to the source (forwarded via MPLS labels)

NB> You don’t need ACH per-se. However, MPLS-TP requires that OAM requests be sent in-band....so ACH channel is needed. You will not be against any guidelines if you send the OAM packet without ACH. Such a form of OAM should be fine as long as sender and receiver both support it.


Also i agree both Source Address TLV and MEP ID is not required but the draft mentions MAY for both. Thus the confusion.
Either one is a MUST to identify the source. Maybe this can be clarified.

NB> Either one is not a MUST. If IP addressing is used, then no src-addr tlv or MEP tlv is needed

In the same context when i refer to Section 2.3 of the draft, it mentions that

"When sending LSP-Ping packets using ACH, there MAY be a need to identify the maintenance end point (MEP) and/or the maintenance intermediate point (MIP) being monitored"

which implies that the MEP of the destination of that LSP or MIP for which ping is sent, is being carried whereas in the Source Address TLV we carry the Source MEP IP which initiates the operation (ping in this case).

Basically am trying to understand some scenarios as to when and why i would have the following in my packets and what will be my processing actions in the control plane....


 1.  Source Address TLV present.

NB> Receiver verifies that the LSP over the packet was sent has an ingress of the “src address tlv”.

2. MEP - ID of the end point/ MIP ID for which the ping request is being sent.

3. MEP - ID of the source that initiated the ping request.

As per draft-ietf-mpls-tp-identifiers-01,
              A MPLS-TP LSP_MEP_ID is:
                  Src-Node_ID::Src-Tunnel_Num::LSP_Num

Thus, a MEP ID will always identify the src. Your option 2) above seems like an invalid option.


Indeed this draft does not request for a new TLV type and the text is also clear. But I was referring to the actual
definition of the source address TLV in the draft ach-tlv. There the Source Address TLV contains the IPv4 address iso the TP identifier format...

NB> I did not understand this part....we can take this offline if you need further clarification.

Regards
Nitin

On Fri, May 7, 2010 at 10:46 AM, Nitin Bahadur <[e-mail]> wrote:

Hi Mukund,

  See inline below to answers to your queries.

On 5/6/10 12:56 PM, "Mukund Mani" <[e-mail]> wrote:

Hi Nitin

Wrt the draft-nitinb-mpls-tp-lsp-ping-extensions-01,  Section 3.1 refers to LSP Ping with IP encapsulation.
It is mentioned that the LSP-Ping reply mode in the LSP Ping echo request MUST
be set to 4 (Reply via application level control channel)
What IP application control channels are we referring to here?

NB> We are referring to the IP channel type of 0x21 (RFC 5085).

Also Section 3.2 (Non-IP based LSP Ping) mentions that the
ingress node MAY attach a Source Address TLV.
In MPLS-TP environment wouldn't this always be required?

NB> No. One can use either MEP-ID or Src-addr tlv to perform connectivity verification. Both are not needed and
hence the draft does not say it’s a MUST for src-addr tlv.

Irrespective, if one may use this TLV, as per the draft-ietf-mpls-tp-ach-tlv-02
it contains the IPv4 address. Shouldnt we have the TP identifier format instead?

NB> The draft is proposing to use the TLV described in ach-tlv draft. No new TLV is being added. If you look at the IANA section
of this draft, there is no request for a new tlv type for src-addr-tlv. Section 2.2 of the draft clarifies some of this. If you feel the
text is unclear, please propose alternative text and we can consider that.

Thanks
Nitin