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

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Tue, 1 Jun 2010 07:20:31 -0500

Hi Shiv, Nitin,

I will updated the P2MP OAM draft to reflect the PHP scenario. 

So does PHP always happen before bud node? Consider the following
topology:

  H - M1 - B - M2 - T

Here:
 H: Head
 M1, M2: Two mid-point nodes
 B: Bud
 T: Tail

So will both M1 and M2 send out unlabelled packets? Will the TTL of the
packet cause any different behavior from M1 and M2?

Also, your suggestion applies to only packets with T bit turned on,
correct? If it is for all ping/trace packets, then I foresee some
issues, where certain nodes will never respond.

Thanks,
Shaleen

> -----Original Message-----
> From: Shivakumar Channalli [mailto:[email-masked]]
> Sent: Saturday, May 29, 2010 11:13 AM
> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
> (ssaxena)
> Cc: [email-masked]
> Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> 
> 
> |> 1. precluding bud node support
> Another way is to try to solve bud node issue in case of PHP
> 
> |> 2. bud node receiving duplicate traffic (label and unlabeled)
> |> Cheers.
> Receiving unlabelled packet in case of PHP can be solved by following
a
> simple rule.
> 
> "In p2mp LSP case, if a node (other than pure egress) receives a +MPLS
> LSP trace packet+, without any label, then we should drop the packet
> without processing"
> 
> Reason: In trace route mode we want packets to reach control plane due
> to TTL expiry, but in PHP p2mp mode packets are also received by bud
> nodes due the PHP. As a result we can make an assumption that, the
> packet received by control plane is not due to TTL expiry, and drop
the
> packets.
> 
> 
> ...$hiv
> 
> 
> 
> |-----Original Message-----
> |From: Santiago Alvarez (saalvare) [mailto:[email-masked]]
> |Sent: Saturday, May 29, 2010 6:03 AM
> |To: Nitin Bahadur; Shaleen Saxena (ssaxena); Shivakumar Channalli
> |Cc: [email-masked]; Santiago Alvarez (saalvare)
> |Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> |
> |It seems to me that, in order to find PHP acceptable for P2MP LSPs,
> one
> |the these two need to be acceptable:
> |1. precluding bud node support
> |2. bud node receiving duplicate traffic (label and unlabeled)
> |Cheers.
> |
> |SA
> |--
> |> -----Original Message-----
> |> From: [email-masked] [mailto:[email-masked]] On
Behalf
> |Of
> |> Nitin Bahadur
> |> Sent: Friday, May 28, 2010 4:52 PM
> |> To: Shaleen Saxena (ssaxena); Shivakumar Channalli
> |> Cc: [email-masked]
> |> Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> |>
> |>
> |> Shaleen,
> |>
> |> > I was referring to
> |> > http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-no-php-oob-
> |> > mapping-04
> |>
> |> This draft does not say that PHP *must not* be used ever for RSVP
> |P2MP.
> |> This draft specifies a requirement for non-PHP behavior and solves
> |that
> |> problem.
> |>
> |> > . Do you have an application where you use PHP? Is P2MP TE
> |> > with PHP going to be deployed in service provider networks?
> |>
> |> Yes...we have customers (in deployment) using P2MP with PHP.
> |>
> |> nitin
> |> _______________________________________________
> |> mpls mailing list
> |> [email-masked]
> |> https://www.ietf.org/mailman/listinfo/mpls

---

From: Shivakumar Channalli <[email-masked]>
Date: Tue, 1 Jun 2010 18:17:08 +0530

|I will updated the P2MP OAM draft to reflect the PHP scenario.
|
|So does PHP always happen before bud node? Consider the following
|topology:
|
|  H - M1 - B - M2 - T
|
|Here:
| H: Head
| M1, M2: Two mid-point nodes
| B: Bud
| T: Tail

PHP will happen before tail (T i.e pure egress) also.
In the example T is pure egress, so packet should be processed by T, but
in case of B (bud node) it should be dropped.

That's why it should be clearly specified as 

"In p2mp LSP case, if a node (other than ++pure egress++) receives a
+MPLS
LSP trace packet+, without any label, then it should drop the packet
without processing"

In other words, "if a bud node receives a unlabelled packets , then it
should be dropped"

|
|So will both M1 and M2 send out unlabelled packets? Will the TTL of the
|packet cause any different behavior from M1 and M2?

I guess, there should not be any problems as such.

|Also, your suggestion applies to only packets with T bit turned on,
|correct? If it is for all ping/trace packets, then I foresee some
|issues, where certain nodes will never respond.

That's correct. The packets should be dropped only if T bit is set.
Other wise in ping mode of operation, we may not get reply at all if we
apply this rule to all packets.

...$hiv

|-----Original Message-----
|From: Shaleen Saxena (ssaxena) [mailto:[email-masked]]
|Sent: Tuesday, June 01, 2010 5:51 PM
|To: Shivakumar Channalli; Santiago Alvarez (saalvare); Nitin Bahadur
|Cc: [email-masked]; Shaleen Saxena (ssaxena)
|Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
|
|Hi Shiv, Nitin,
|
|I will updated the P2MP OAM draft to reflect the PHP scenario.
|
|So does PHP always happen before bud node? Consider the following
|topology:
|
|  H - M1 - B - M2 - T
|
|Here:
| H: Head
| M1, M2: Two mid-point nodes
| B: Bud
| T: Tail
|
|So will both M1 and M2 send out unlabelled packets? Will the TTL of the
|packet cause any different behavior from M1 and M2?
|
|Also, your suggestion applies to only packets with T bit turned on,
|correct? If it is for all ping/trace packets, then I foresee some
|issues, where certain nodes will never respond.
|
|Thanks,
|Shaleen
|
|
|> -----Original Message-----
|> From: Shivakumar Channalli [mailto:[email-masked]]
|> Sent: Saturday, May 29, 2010 11:13 AM
|> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
|> (ssaxena)
|> Cc: [email-masked]
|> Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
|>
|>
|> |> 1. precluding bud node support
|> Another way is to try to solve bud node issue in case of PHP
|>
|> |> 2. bud node receiving duplicate traffic (label and unlabeled)
|> |> Cheers.
|> Receiving unlabelled packet in case of PHP can be solved by following
|a
|> simple rule.
|>
|> "In p2mp LSP case, if a node (other than pure egress) receives a
+MPLS
|> LSP trace packet+, without any label, then we should drop the packet
|> without processing"
|>
|> Reason: In trace route mode we want packets to reach control plane
due
|> to TTL expiry, but in PHP p2mp mode packets are also received by bud
|> nodes due the PHP. As a result we can make an assumption that, the
|> packet received by control plane is not due to TTL expiry, and drop
|the
|> packets.
|>
|>
|> ...$hiv
|>
|>
|>
|> |-----Original Message-----
|> |From: Santiago Alvarez (saalvare) [mailto:[email-masked]]
|> |Sent: Saturday, May 29, 2010 6:03 AM
|> |To: Nitin Bahadur; Shaleen Saxena (ssaxena); Shivakumar Channalli
|> |Cc: [email-masked]; Santiago Alvarez (saalvare)
|> |Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
|> |
|> |It seems to me that, in order to find PHP acceptable for P2MP LSPs,
|> one
|> |the these two need to be acceptable:
|> |1. precluding bud node support
|> |2. bud node receiving duplicate traffic (label and unlabeled)
|> |Cheers.
|> |
|> |SA
|> |--
|> |> -----Original Message-----
|> |> From: [email-masked] [mailto:[email-masked]] On
|Behalf
|> |Of
|> |> Nitin Bahadur
|> |> Sent: Friday, May 28, 2010 4:52 PM
|> |> To: Shaleen Saxena (ssaxena); Shivakumar Channalli
|> |> Cc: [email-masked]
|> |> Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS
Map
|> |>
|> |>
|> |> Shaleen,
|> |>
|> |> > I was referring to
|> |> > http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-no-php-oob-
|> |> > mapping-04
|> |>
|> |> This draft does not say that PHP *must not* be used ever for RSVP
|> |P2MP.
|> |> This draft specifies a requirement for non-PHP behavior and solves
|> |that
|> |> problem.
|> |>
|> |> > . Do you have an application where you use PHP? Is P2MP TE
|> |> > with PHP going to be deployed in service provider networks?
|> |>
|> |> Yes...we have customers (in deployment) using P2MP with PHP.
|> |>
|> |> nitin
|> |> _______________________________________________
|> |> mpls mailing list
|> |> [email-masked]
|> |> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 10 Jun 2010 16:53:10 -0500

Dear all,
below are my comments on draft-ietf-mpls-p2mp-lsp-ping-10.txt prepended with "MA>".

I will be sending comments on the other draft shortly.

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

1. Section 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs

MA> The detailed procedures for a MP2MP LSP Ping are missing in this document.

2. Section 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs

The IPv4 or IPv6 Egress Address P2MP Responder Identifier Sub-TLVs
MAY be used in an echo request carrying RSVP P2MP Session Sub-TLV.
They SHOULD NOT be used with an echo request carrying Multicast LDP
FEC Stack Sub-TLV.

MA> We need to describe the behaviour of a receiver of an echo request message if it receives this sub-TLV with a Multicast LDP FEC stack TLV. I assume the receiver will ignore it and reply as if this was not received.

We also need to explicitly state that a single leaf tracing for a P2MP/MP2MP LDP FEC is not supported because of that.

3. Section 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs
<...>

A node that receives an echo request with this Sub-TLV present MUST
respond only if the node lies on the path to the address in the
Sub-TLV.

MA> I think this paragraph should read as follows:

"

A node that receives an echo request with this Sub-TLV present MUST respond only if **it validated the FEC stack TLV and the address specified in Egress Address P2MP Responder Identifier Sub-TLV is local to this node or is reachable from this node over the P2MP LSP path**.

"

4. Section 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs

<...>

A node that receives an echo request with this Sub-TLV present MUST
respond only if the address in the Sub-TLV corresponds to any address
that is local to the node. This address in the Sub-TLV may be of any
physical interface or may be the router id of the node itself.

MA> I think this paragraph should read as follows:

"

A node that receives an echo request with this Sub-TLV present MUST respond only if **it validated the FEC stack TLV and the address in the Node Address P2MP Responder Identifier Sub-TLV corresponds to any address that is local to the node**.

The address in the Sub-TLV may be of any physical interface or may be the router id of the node itself.

"

5. Section 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs

MA> We need to add text that describes the behaviour when both the a single Egress Address P2MP Responder Identifier Sub-TLV and a single Node Address P2MP Responder Identifier Sub-TLV are received. I assume this is an AND function. In other words, only if the address in the Node Address P2MP Responder Identifier Sub-TLV matches an address of this node that the response for the requested leaf for the address in the Egress Address P2MP Responder Identifier Sub-TLV is possible.

6. Section 3.4. Respond Only If TTL Expired Flag

MA> What is the use case for this flag? It is already the case that a node in the path of P2MP LSP, other than the egress LER, will only process the echo request message if the TTL of the outer label expires. The egress LER is the only node which does not care about the setting of the TTL.

7. Section 4.2.1.3. Responses from Bud Nodes

MA> See my comment (5) about the behaviour for when both a single Egress Address P2MP Responder Identifier Sub-TLV and a single Node Address P2MP Responder Identifier Sub-TLV are received.

8. Section 4.3.1. End of Processing for Traceroutes

MA> I am having trouble with the text in this section. A traceroute can only be performed for a single single Egress Address P2MP Responder Identifier Sub-TLV. It does not work if you allowed more than one sub-TLV since you do not support the Multipath information, which by the way was removed from Version 7 of the draft.

9. Section 4.3.2. Multiple responses from Bud and Egress Nodes

The P2MP traceroute may continue even after it has received a valid
response from a bud or egress node, as there may be more nodes at
deeper levels. Hence for subsequent TTL values, a bud or egress node
that has previously replied would continue to get new echo requests.
Since each echo request is handled independently from previous
requests, these bud and egress nodes will keep on responding to the
traceroute echo requests. This can cause extra processing burden for
the initiating router and these bud or egress routers.

MA> I failt to see how it is possible that a BUD LSR will respond again to an echo request message which has a higher TTL to the one which caused the first response. Remember, you can only trace a single egress leaf at a time since only a single Egress Address P2MP Responder Identifier Sub-TLV is processed by the receiver. There is no way the BUD LSR will send multiple responses.

10. Section 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request

As described in section 4.6 of [RFC4379], an initiating router,
during traceroute, SHOULD copy the Downstream Mapping(s) into its
next echo request(s). However for P2MP LSPs, the intiating router
will receive multiple sets of Downstream Detailed Mapping TLV from
different nodes. It is not practical to copy all of them into the
next echo request. Hence this behavior is being modified for P2MP
LSPs. In the echo request packet, the "Downstream IP Address" field,
of the Downstream Detailed Mapping TLV, SHOULD be set to the
ALLROUTERS multicast address.

MA> I think you are trying to describe a tree trace capability which is not supported in the draft as is. What you describe here gives you the nodes which are in the P2MP tree but will not tell you how they are connected with the P2MP LSP since you do not have the Multipath information in the DDMAP.

I suggest we remove this and explicitly state that tree trace capability is not supported. Only tracing of a single leaf is possible with what is defined in this document.

=====================================

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of George Swallow
Sent: Thursday, May 27, 2010 6:43 PM
To: [email-masked]
Subject: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

This begins a two week last call on the follow two drafts.

Mechanism for performing LSP-Ping over MPLS tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-05
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-enhanced-dsmap-05.txt

and

Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS)
- Extensions to LSP Ping
draft-ietf-mpls-p2mp-lsp-ping-10.txt
http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-10.txt

The last call ends June 10, 2010 24:00 UTC

George & Loa

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 11 Jun 2010 13:07:33 -0700

Hi Mustapha,

This functionality will be useful to ping leaves at TTL=x.
You can do a rough trace of multiple egresses using node responder tlv. In such a case, the bud lsr should not be
responding for the egress functionality (if the bud is at TTL - 2).

gives you the nodes which are in the P2MP tree but will not tell you how they are connected with the P2MP LSP since you do not have the Multipath information in the DDMAP.

=====================================
NB> You can do a tree build-up without (label-stack/upstream-neighbor) validations using the
node responder tlv. You cannot do a real parallel tree trace (with all validations). I don't see too much
benefit in writing complex specs to enable that.

Thanks
nitin

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 11 Jun 2010 17:25:38 -0500

I have one more comment:

11. Section 3.5. Downstream Detailed Mapping TLV

  <...>
  When responding to an RSVP IPv4/IPv6 P2MP Session FEC Type
  or a Multicast P2MP/MP2MP LDP FEC Type, a node MUST ignore any
  Downstream Mapping TLV it receives in the echo request.
MA> We need to clarify what is meant by "ignore". I assume this meant continue processing and do not include a DSMAP or a DDMAP in the echo reply message.

Mustapha.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Thursday, June 10, 2010 5:53 PM
To: George Swallow; [email-masked]
Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

Dear all,

Regards,
Mustapha.

"

"

<...>

"

"

and

George & Loa

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 11 Jun 2010 17:44:02 -0500

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?

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.

"

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?

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.

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.

and

George & Loa

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Fri, 11 Jun 2010 22:34:54 -0500

Hi Mustapha,

Thank you very much for your valuable comments. My responses are inline.

MA> The detailed procedures for a MP2MP LSP Ping are missing in this
document.

[Shaleen Saxena (ssaxena): ] The MP2MP LSP Ping is similar to the P2MP
LSP Ping. One difference is that the MP2MP ping or trace can be started
from a leaf nodes as well.  Operationally, the ping and trace would
behave same as a P2MP ping from any head. Hence no separate procedures
are required.

MA> We need to describe the behaviour of a receiver of an echo request
message if it receives this sub-TLV with a Multicast LDP FEC stack TLV.
I assume the receiver will ignore it and reply as if this was not
received.

We also need to explicitly state that a single leaf tracing for a
P2MP/MP2MP LDP FEC is not supported because of that. 

[Shaleen Saxena (ssaxena): ] I will add the following to the
description: If a router receives these TLVs in an echo request carrying
Multicast LDP then it SHOULD ignore these sub-TLVs and respond as if
they are not present. Hence these TLVs cannot be used to traceroute to a
single egress or bud node when Multicast LDP FEC is used.

"

A node that receives an echo request with this Sub-TLV present MUST
respond only if **it validated the FEC stack TLV and the address
specified in Egress Address P2MP Responder Identifier Sub-TLV is local
to this node or is reachable from this node over the P2MP LSP path**.

"

[Shaleen Saxena (ssaxena): ] The description in this paragraph is only
for the behavior as it relates to this TLV. For complete determination
of whether to respond or not, other TLV also play a part.  The draft
already states that the procedures are in addition to RFC 4379
procedures. Hence proper FEC Validation,  value of Reply Mode, etc. will
control above and beyond the Responder Identifier TLV. I am hesitant to
include the phrase about FEC validation since it does not provide a
complete picture.

<...>

"

A node that receives an echo request with this Sub-TLV present MUST
respond only if **it validated the FEC stack TLV and the address in the
Node Address P2MP Responder Identifier Sub-TLV corresponds to any
address that is local to the node**. 

The address in the Sub-TLV may be of any physical interface or may be
the router id of the node itself.

"

[Shaleen Saxena (ssaxena): ] Same as above.

MA> We need to add text that describes the behaviour when both the a
single Egress Address P2MP Responder Identifier Sub-TLV and a single
Node Address P2MP Responder Identifier Sub-TLV are received. I assume
this is an AND function. In other words, only if the address in the Node
Address P2MP Responder Identifier Sub-TLV matches an address of this
node that the response for the requested leaf for the address in the
Egress Address P2MP Responder Identifier Sub-TLV is possible.

[Shaleen Saxena (ssaxena): ] Section 3.2 already states: 

        If more than one sub-TLV is present the first MUST

        be processed as described in this document, and subsequent

        sub-TLVs SHOULD be ignored.

MA> What is the use case for this flag? It is already the case that a
node in the path of P2MP LSP, other than the egress LER, will only
process the echo request message if the TTL of the outer label expires.
The egress LER is the only node which does not care about the setting of
the TTL.

[Shaleen Saxena (ssaxena): ] The use case for this flag is explained in
Seciton 4.3.2. "Multiple responses from Bud and Egress Nodes". Please
take a look at 4.3.1 as well. Basically if no Responder Identifier TLV
is present, then all egress and bud nodes will respond to traceroute.
The bud and egress nodes that are closer to the head end will respond
multiple times while nodes further downstream are being probed.

MA> See my comment (5) about the behaviour for when both a single Egress
Address P2MP Responder Identifier Sub-TLV and a single Node Address P2MP
Responder Identifier Sub-TLV are received.

[Shaleen Saxena (ssaxena): ] What is the use case for having both Egress
and Node Address P2MP? Why would a head end send both?

MA> I am having trouble with the text in this section. A traceroute can
only be performed for a single single Egress Address P2MP Responder
Identifier Sub-TLV. It does not work if you allowed more than one
sub-TLV since you do not support the Multipath information, which by the
way was removed from Version 7 of the draft.

[Shaleen Saxena (ssaxena): ] The traceroute can also be performed for
the entire tree. If no responder identifier TLV is used, then all nodes
in the tree will respond. This is the likely scenario for the Multicast
LDP trees. 

MA> I failt to see how it is possible that a BUD LSR will respond again
to an echo request message which has a higher TTL to the one which
caused the first response. Remember, you can only trace a single egress
leaf at a time since only a single Egress Address P2MP Responder
Identifier Sub-TLV is processed by the receiver. There is no way the BUD
LSR will send multiple responses.

[Shaleen Saxena (ssaxena): ] A bud node will always punt any echo
request packet it receives (and will also forward it if the TTL allows).
So if a responder identifier TLV is not present, then the Bud LSR will
respond to every echo request that reaches it. Even if an Egress Address
sub-TLV is present, any bud node that is on path to the specified egress
will end up responding multiple times.

10. Section 4.3.4. Use of Downstream Detailed Mapping TLV in Echo
Request

MA> I think you are trying to describe a tree trace capability which is
not supported in the draft as is. What you describe here gives you the
nodes which are in the P2MP tree but will not tell you how they are
connected with the P2MP LSP since you do not have the Multipath
information in the DDMAP.

I suggest we remove this and explicitly state that tree trace capability
is not supported. Only tracing of a single leaf is possible with what is
defined in this document.

[Shaleen Saxena (ssaxena): ] No, I am not describing tree trace
capability. Moreover the document allows for tracing the entire tree. So
the trace is either for the entire tree or a single egress/bud. We had
debated about allowing trace to multiple egress/bud nodes. But
operationally it will be complicated; hence we restricted the number of
valid Responder Identifier sub-TLVs to only one. If a user needs to
trace to multiple egresses then multiple traceroute to individual
egresses would have to be used.

Regards,

Shaleen

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of George Swallow
	Sent: Thursday, May 27, 2010 6:43 PM
	To: [email-masked]
	Subject: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

	
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-enhanced-ds
map-05.txt 

	and

	Detecting Data Plane Failures in Point-to-Multipoint
Multiprotocol Label Switching (MPLS) 
	- Extensions to LSP Ping
	draft-ietf-mpls-p2mp-lsp-ping-10.txt

	
	
	George & Loa

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Fri, 11 Jun 2010 22:36:27 -0500

Hi Mustapha,

I will add your suggested clarification to the draft.

Regards,

Shaleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Aissaoui, Mustapha (Mustapha)
Sent: Friday, June 11, 2010 6:26 PM
To: [email-masked]
Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

I have one more comment:

  <...>

  When responding to an RSVP IPv4/IPv6 P2MP Session FEC Type
  or a Multicast P2MP/MP2MP LDP FEC Type, a node MUST ignore any
  Downstream Mapping TLV it receives in the echo request.
MA> We need to clarify what is meant by "ignore". I assume this meant
continue processing and do not include a DSMAP or a DDMAP in the echo
reply message.

Mustapha.

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Aissaoui, Mustapha (Mustapha)
	Sent: Thursday, June 10, 2010 5:53 PM
	To: George Swallow; [email-masked]
	Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS
Map

	Dear all,

	below are my comments on draft-ietf-mpls-p2mp-lsp-ping-10.txt
prepended with "MA>".

	Regards,

	Mustapha.

	1. Section 3.1.2.2. Applicability to Multipoint-to-Multipoint
LSPs

	MA> The detailed procedures for a MP2MP LSP Ping are missing in
this document.

	2. Section 3.2.1. Egress Address P2MP Responder Identifier
Sub-TLVs
	
	The IPv4 or IPv6 Egress Address P2MP Responder Identifier
Sub-TLVs
	MAY be used in an echo request carrying RSVP P2MP Session
Sub-TLV.
	They SHOULD NOT be used with an echo request carrying Multicast
LDP
	FEC Stack Sub-TLV.

	MA> We need to describe the behaviour of a receiver of an echo
request message if it receives this sub-TLV with a Multicast LDP FEC
stack TLV. I assume the receiver will ignore it and reply as if this was
not received.

	We also need to explicitly state that a single leaf tracing for
a P2MP/MP2MP LDP FEC is not supported because of that. 

	3. Section 3.2.1. Egress Address P2MP Responder Identifier
Sub-TLVs
	<...> 

	A node that receives an echo request with this Sub-TLV present
MUST
	respond only if the node lies on the path to the address in the
	Sub-TLV.

	"

	A node that receives an echo request with this Sub-TLV present
MUST respond only if **it validated the FEC stack TLV and the address
specified in Egress Address P2MP Responder Identifier Sub-TLV is local
to this node or is reachable from this node over the P2MP LSP path**.

	"

	4. Section 3.2.2. Node Address P2MP Responder Identifier
Sub-TLVs
	
	<...>
	
	A node that receives an echo request with this Sub-TLV present
MUST
	respond only if the address in the Sub-TLV corresponds to any
address
	that is local to the node. This address in the Sub-TLV may be of
any
	physical interface or may be the router id of the node itself.

	"

	A node that receives an echo request with this Sub-TLV present
MUST respond only if **it validated the FEC stack TLV and the address in
the Node Address P2MP Responder Identifier Sub-TLV corresponds to any
address that is local to the node**. 

	The address in the Sub-TLV may be of any physical interface or
may be the router id of the node itself.

	"

	5. Section 3.2.2. Node Address P2MP Responder Identifier
Sub-TLVs

	MA> We need to add text that describes the behaviour when both
the a single Egress Address P2MP Responder Identifier Sub-TLV and a
single Node Address P2MP Responder Identifier Sub-TLV are received. I
assume this is an AND function. In other words, only if the address in
the Node Address P2MP Responder Identifier Sub-TLV matches an address of
this node that the response for the requested leaf for the address in
the Egress Address P2MP Responder Identifier Sub-TLV is possible.

	MA> What is the use case for this flag? It is already the case
that a node in the path of P2MP LSP, other than the egress LER, will
only process the echo request message if the TTL of the outer label
expires. The egress LER is the only node which does not care about the
setting of the TTL.

	MA> See my comment (5) about the behaviour for when both a
single Egress Address P2MP Responder Identifier Sub-TLV and a single
Node Address P2MP Responder Identifier Sub-TLV are received.

	MA> I am having trouble with the text in this section. A
traceroute can only be performed for a single single Egress Address P2MP
Responder Identifier Sub-TLV. It does not work if you allowed more than
one sub-TLV since you do not support the Multipath information, which by
the way was removed from Version 7 of the draft.

	The P2MP traceroute may continue even after it has received a
valid
	response from a bud or egress node, as there may be more nodes
at
	deeper levels. Hence for subsequent TTL values, a bud or egress
node
	that has previously replied would continue to get new echo
requests.
	Since each echo request is handled independently from previous
	requests, these bud and egress nodes will keep on responding to
the
	traceroute echo requests. This can cause extra processing burden
for
	the initiating router and these bud or egress routers.

	MA> I failt to see how it is possible that a BUD LSR will
respond again to an echo request message which has a higher TTL to the
one which caused the first response. Remember, you can only trace a
single egress leaf at a time since only a single Egress Address P2MP
Responder Identifier Sub-TLV is processed by the receiver. There is no
way the BUD LSR will send multiple responses.

	10. Section 4.3.4. Use of Downstream Detailed Mapping TLV in
Echo Request
	
	As described in section 4.6 of [RFC4379], an initiating router,
	during traceroute, SHOULD copy the Downstream Mapping(s) into
its
	next echo request(s). However for P2MP LSPs, the intiating
router
	will receive multiple sets of Downstream Detailed Mapping TLV
from
	different nodes. It is not practical to copy all of them into
the
	next echo request. Hence this behavior is being modified for
P2MP
	LSPs. In the echo request packet, the "Downstream IP Address"
field,
	of the Downstream Detailed Mapping TLV, SHOULD be set to the
	ALLROUTERS multicast address.

	MA> I think you are trying to describe a tree trace capability
which is not supported in the draft as is. What you describe here gives
you the nodes which are in the P2MP tree but will not tell you how they
are connected with the P2MP LSP since you do not have the Multipath
information in the DDMAP.

	I suggest we remove this and explicitly state that tree trace
capability is not supported. Only tracing of a single leaf is possible
with what is defined in this document.

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of George Swallow
		Sent: Thursday, May 27, 2010 6:43 PM
		To: [email-masked]
		Subject: [mpls] Last Calls on P2MP LSP Ping and Enhanced
DS Map

		This begins a two week last call on the follow two
drafts.

		and

		
		
		George & Loa

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 15 Jun 2010 16:47:43 -0700

Hi Mustapha,

    Thanks for looking at the draft with a fine comb.
Please see NB> below for some responses.
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Friday, June 11, 2010 3:44 PM
To: George Swallow; [email-masked]
Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

Dear all,

Regards,
Mustapha.

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.

"

"

NB> Good catch. Fixed.

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.

   <...>

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.

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

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

Thanks

Nitin