Re: [mpls-tp] [mpls] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document

[Nitin Bahadur <[e-mail]>]

Hi Muralidhar,

Please see NB> below for responses to your queries....

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Muralidhar Annabathula
Sent: Wednesday, June 23, 2010 12:47 AM
To: [e-mail]
Cc: [e-mail]; MPLS-TP ad hoc team
Subject: Re: [mpls-tp] [mpls] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document

Dear Authors,

1) Referring to sections 1.3, 3.3 and 4.2. LSP-Ping for MPLS-TP LSPs using non-IP encapsulation. It is mentioned that in certian deployment scenarios it might be required that LSP Ping (or for that matter any other MPLS-TP OAM) might be run without IP addressing. In such cases the ingress node MAY attach a source address TLV.

# My question is that since source address TLV itself is of IPv4 or IPv6 format (as defined in draft-ietf-mpls-tp-ach-tlv-02) how can a sink node identify the source node in non-ip scenario ? Can we use source address TLV in non-ip scenario?
NB> The src addr tlv can be anything. ietf-mpls-tp-ach-tlv is supposed to define any new address format types.
2) Referring to scetion 3.3. "If a node receives an MPLS echo request packet over ACH, without IP/UDP headers and if that node does not have a return MPLS LSP path to the echo request source, then the node MUST drop the echo request packet and not attempt to send a response."

# In case there is no LSP based return path and the received MPLS echo request packet had an IPv4/IPv6 source ACH TLV and the node receiving the MPLS echo has IP addressing/routing capabilities, in which case shouldn't it still be able send the response over IPv4 or IPv6?
NB> If there is no LSP-based return path, then your bi-directional LSP is down in some sense. If you never configured a
LSP return path, then it's the same as a uni-directional LSP. For uni-directional LSPs, it's best to apply Section 3.2 of
this draft and use a reply mode of 2 (reply using IP/UDP). I probably should clarify this in the draft.

3) Referring to section 4. "This section specifies how LSP-Ping traceroute can be used in the context of MPLS-TP LSPs.  The LSP-Ping traceroute function meets the Adjacency and Route Tracing requirement specified in [RFC5860].  This function SHOULD be performed on-demand.This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs and Sections."

# For a MPLS section, traceroute may not be applicable as the nodes will always be adjacent at the corresponding layer.

NB> It's not applicable per se....but there's no reason to say that one cannot attempt to do traceroute between
adjacent nodes.

Thanks
Nitin