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

[Muralidhar Annabathula <[e-mail]>]

Thanks for your response.
Inline comments

Regards,
Murali

On Wed, Jun 23, 2010 at 3:46 PM, Nitin Bahadur <[e-mail]> wrote:

>  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.
>
> [Murali] Agreed.

>
> 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.
>
> [Murali] Sounds good. But should the operator still be allowed to do a
non-ip encapsulated LSP Ping on a uni-LSP with Source address TLV with reply
more 2?

>
> 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.
>
> [Murali] Ok

>
>
>
> Thanks
> Nitin
>
>