Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

From: babu s <[email-masked]>
Date: Wed, 16 Jun 2010 13:41:07 +0530

Hi Nitin,
I have a query based on your response. Please see BS> below for that query.

Thanks
Babu

Title: *Last Calls on P2MP LSP Ping and Enhanced DS Map*
Hi Mustapha,

    Thanks for looking at the draft with a fine comb.
Please see NB> below for some responses.

 ------------------------------
*From:* mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] *On
Behalf Of *Aissaoui, Mustapha (Mustapha)
*Sent:* Friday, June 11, 2010 3:44 PM
*To:* George Swallow; mpls at ietf.org
*Subject:* Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

 Dear all,
below are my comments on draft-ietf-mpls-lsp-ping-enhanced-dsmap-05 prepended
with "MA>".

Regards,
Mustapha.
=====================================

1. Section 3.2.1.  Return code per downstream

   A new Return Code is being defined "See DDM TLV for Return Code and
   Return SubCode" (Section 6.3) to indicate that the Return Code is per
   Downstream Detailed Mapping TLV (Section 3.3).  This Return Code MUST
   be used only in the message header and MUST be set only in the echo
   response message.  If the Return Code is set in the echo request
   message, then it SHOULD be ignored.  When this Return Code is set,
   each Downstream Detailed Mapping TLV MUST have an appropriate Return
   Code and Return SubCode.  This Return Code is to be used when there
   are multiple downstreams for a given node (such as P2MP or ECMP), and
   the node wants to return a different Return Code/Return SubCode for
   each downstream.
MA> I see an issue with the applicability of this return code. This return
code can only be used in the main message header while the other new return
code "Label switched with FEC change" can only be used inside the DDMAP.
Should we not have a separate space to draw the code points for the main
message header and for the DDMAP?

NB> Most of the codes that can appear in main header are applicable to DDMAP
as well. It would seem like we will end up duplicating a lot of code values.

2. Section 3.2.2.  Return code for stitched LSPs

   When a traceroute is being performed on stitched LSPs Figure 10, the
   stitching point SHOULD indicate the stitching action to the node
   performing the trace.  This is done by setting the Return Code to
   "Label switched with FEC change" (Section 6.3).  If a node is
   performing FEC hiding, then it MAY choose to set the Return Code to a
   value other than "Label switched with FEC change".  This Return Code
   MUST NOT be used if no Label Stack sub-TLVs (Section 3.3.3) are
   present in the Downstream Detailed Mapping TLV(s).

MA> I believe the last sentece meant to read as follows:

"

This Return Code MUST NOT be used if no FEC stack Change sub-TLV (Section
3.3.3) is present in the Downstream Detailed Mapping TLV.

"

NB> Good catch. Fixed.

3. Section 3.2.2.  Return code for stitched LSPs
MA> What is the need to include the new return code "Label switched with FEC
change" when the FEC stack Change sub-TLV is explicit about the FEC
manipulation?

NB> To make the return code explicitly spell out that there was a FEC
change. An implementation may choose

to ignore the contents of the  Fec stack change sub-tlv.

4. Section 4.3.  Handling deprecated Downstream Mapping TLV

   <...>
   o  If the echo request contains a Downstream Detailed Mapping TLV and
      the corresponding echo response contains an Return Code of 2 (one
      or more of the TLVs was not understood), then the sender of the
      echo request MAY resend the echo request with the Downstream
      Mapping TLV (instead of the Downstream Detailed Mapping TLV).  In
      cases where a detailed response is needed, the sender can choose
      to ignore the router that does not support the Downstream Detailed
      Mapping TLV.
MA> I do not think we should even suggest that. There is no way the sender
can determine the which TLV caused the return code 2 to be sent by the
responder node.

NB> I agree that the ingress cannot make a determination which TLV was not
understood by a transit. The main reason for adding this text was to provide
some way to discover the old nodes (with software that doesn't understand
DDMAP) in the network. No service provider is going to upgrade the entire
network in one shot (esp in multi-vendor scenarios). In such a case, the
more information one can get from a trace, the better it is.

BS> The ingress should be able to determine the TLVs that was not understood
by the responder from Errored  TLV. As per section 4.4 in RFC 4379, the
responder will include the Misunderstood TLVs in Errored TLV in the reply.
But this contradicts the explanation given above. Please correct me if am
wrong.

5. Section Handling deprecated Downstream Mapping TLV
   o  If the echo request contains a Downstream Mapping TLV, then a
      Downstream Detailed Mapping TLV MUST NOT be sent in the echo
      response.  This is to handle the case that the sender of the echo
      request does not support the new TLV.
MA> I think we need to be more explicit about the behaviour of the responder
node in this case. The responder will reply and will not include a DDMAP but
MAY include a DSMAP.

NB> Agreed. How about addition of the following line at the end.

"The echo response MAY contain Downstream Mapping TLV(s).

Thanks

Nitin