Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Tue, 12 Jan 2010 14:54:47 +0530

Hello,

Need following clarifications in the below mentioned draft.

1. In the page 8 it is mentioned that
   "The transit LSR also returns information on an echo response that helps
verify the control plane against the data plane.  That
   is, the information is used by the *ingress* to check that the data plane
forwarding, matches what is signaled by the control plane"

  The ingress referes to what? The ingress lsr or the ingress interface of
the transit lsr? Its not very clear from the above statement.
   I think it should be ingress interface?

2. Section 3.5 page 15 of the draft sates
   "Downstream Detailed Mapping TLV is described in [DDMT].  A transit,
  branch or bud node *can use* the Downstream Detailed Mapping TLV to
  return multiple Return Codes" ...
  "As per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in
  [RFC4379] is being deprecated"
"  Therefore for P2MP, a node MUST support Downstream Detailed Mapping
  TLV.  The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP
  traceroute functionality and SHOULD NOT be included in an Echo Request
  message"

  Does this mean that the p2mp ingress node can still receive Downstream
Mapping TLV? If so should the ingress process it?
  Or is it that the responding node MUST reply back with DDMT?

3.  Section 7.2 New TLV's refers to Section 3.2.4 which doesn't exist.

4.
    Say   A is ingress and D and F are 2 egresses of the p2mp lsp.

            A ------------ B --------------C --------- D
                              \----------------E ---------- F

When A sends a echo request with TTL 1, B replies back with 2 instances of
DDMT depicitng interface BC and BE.
Now at node A we know that there are 2 outgoing links to egress.

 4.1 How does A distinguish whether the BC and BE are ECMP paths or path for
2 different egresses?
 4.2 How does node A, corelate the links BC and BE to egress D or F?
(Basically how does the topology formed at ingress)
       In the above topology, B is transit for both C & E, where as C is
part of only D and E is part of only F.
 4.3 How should the node A's next mpls echo request (TTL 2) look like?
      If A is adding the DDMT in its echo Request then should it contain
both the links received BC and BE?
      If so, then how does C or E verify which link is upstream?
     The draft mentions in some place that the interface address can be
multicast address. But with this way we will be skipping
      the interface validation altogether.
     I am considering the fact that we are not adding the Responder
Indentifier TLV.

4.4 Do we need B to send back more information such as the egress to which
the downstream link is being added.
      Also do we need B to differentiate between a ECMP path with the path
to multiple egress?
     May be adding a egress address in DDMT will solve these? Or is it that
it is taken care in some other ways.

Please let me know.

Thanks,
Ashwin

On Tue, Dec 15, 2009 at 3:45 AM, <[email-masked]> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Multiprotocol Label Switching Working
> Group of the IETF.
>
>
>        Title           : Detecting Data Plane Failures in
> Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP
> Ping
>        Author(s)       : S. Yasukawa, et al.
>        Filename        : draft-ietf-mpls-p2mp-lsp-ping-09.txt
>        Pages           : 28
>        Date            : 2009-12-14
>
> Recent proposals have extended the scope of Multiprotocol Label
> Switching (MPLS) Label Switched Paths (LSPs) to encompass
> point-to-multipoint (P2MP) LSPs.
>
> The requirement for a simple and efficient mechanism that can be used
> to detect data plane failures in point-to-point (P2P) MPLS LSPs has
> been recognized and has led to the development of techniques for
> fault detection and isolation commonly referred to as "LSP Ping".
>
> The scope of this document is fault detection and isolation for P2MP
> MPLS LSPs.  This documents does not replace any of the mechanisms of
> LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and
> extends the techniques and mechanisms of LSP Ping to the MPLS P2MP
> environment.Copyright Notice
>
> Copyright (c) 2009 IETF Trust and the persons identified as the
> document authors.  All rights reserved.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-09.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 12 Jan 2010 10:43:53 -0800

Hi Ashwin,

  See responses to some of your questions below...

On 1/12/10 1:24 AM, "Ashwin C. Prabhu" <[email-masked]> wrote:
4.
    Say   A is ingress and D and F are 2 egresses of the p2mp lsp.

When A sends a echo request with TTL 1, B replies back with 2 instances of DDMT depicitng interface BC and BE.
Now at node A we know that there are 2 outgoing links to egress.

NB>       you can trace each sub-tree at a time using the "Node Address P2MP Responder Identifier Sub-TLV"
    and increasing ttl. So for TTL=2, A will send 2 messages: 1 with DDMT for C and one for DDMT for E.
    This approach is similar to how you do tracert for LDP ECMP (wherein we use different dest-ip).

If you want to trace paths in parallel....there is a way ...at expense of reduced functionality....
         Each pkt that ingress A sends, it's DDMT always sets  the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered.
          For IPv4, it MUST set the Downstream IP Address to 224.0.0.2. As per RFC 4379

          "If an LSR receives an Echo Request packet with the all-routers
           multicast address, then this indicates that it MUST bypass both
            interface and label stack validation, but return Downstream
           Mapping TLVs using the information provided."

           For TTL=1, B will respond with 2 DDMT TLV (one for C and one for E). A can now
create a tree containing A, B, C, E. Now on TTL=2, A will get a response from C and E. Based on IP addr of
 responding node, A will know if it's C or E and can graft the information regarding D or F into the tree.

 4.1 How does A distinguish whether the BC and BE are ECMP paths or path for 2 different egresses?

NB> Ingress "does not care". A is building a topology during the trace and it will realize which nodes are
egresses when the topology build-up completes. Note that for P2MP RSVP-TE, there is no concept of ECMP. For
  mLDP, there is ECMP...but  "A" can do post-tree-computation analysis to determine ECMP paths.

 4.2 How does node A, corelate the links BC and BE to egress D or F? (Basically how does the topology formed at ingress)
       In the above topology, B is transit for both C & E, where as C is part of only D and E is part of only F.

NB> See above.

 4.3 How should the node A's next mpls echo request (TTL 2) look like?
      If A is adding the DDMT in its echo Request then should it contain both the links received BC and BE?
      If so, then how does C or E verify which link is upstream?
     The draft mentions in some place that the interface address can be multicast address. But with this way we will be skipping
      the interface validation altogether.
     I am considering the fact that we are not adding the Responder Indentifier TLV.

4.4 Do we need B to send back more information such as the egress to which the downstream link is being added.
      Also do we need B to differentiate between a ECMP path with the path to multiple egress?
     May be adding a egress address in DDMT will solve these? Or is it that it is taken care in some other ways.

NB> I don't think any of this is needed.

Thanks
Nitin

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 12 Jan 2010 11:09:28 -0800

NNB> There is no ECMP for mLDP either....

---

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Wed, 13 Jan 2010 17:56:12 +0530

Hello Nitin,

Thanks a lot for the reply.

I still have some more clarifications;

1. In the case of tracing node by node using the node address responder id
TLV, only way to map C to node B would be to take the help of the IGP.
    I am assuming that the node C's address is going to be a loopback
address.
   Do we need to consider the case of a lsp spanning accross the Autonomous
System? Does the p2mp lsp span across different AS? Or can we have
   lsp stitching for the p2mp lsp? If we already support any of these at
present or in future then we may not be able to map node C to its upstream
node
   B.

2. I still didn't get how the tree is formed for tracing parallely,
    Extending the above topology adding a node G and H in the previous
topology.

           A ------------ B --------------C ----------- G -------------- D
                             \----------------E ---------- H --------------
F

   Now considering that there is no DDMT in label request message or DDMT
with unnumbered type (interface address is multicast address)
   With TTL 1  Node B replies back
   Wih TTL 2 Node C and E replies back,
   With TTL 3 Node G and H replies back
   With TTL 4 Node D and F replies with return code.

  So say at instance with TTL 3 replies received, the tree could be  A ----
B ----- C --- G or A----- B ------C --- H or A----B---E --- G or A --- B
----E--- H
  The sender address of G or H doesn't indicate who is upstream?
  I think i am missing something here.

 By attaching something similar to "Node address responder id TLV" to each
instance of DDMT in the echo Request message can we not do the interface
validation even in the case of parallel trace? Basically instead of sending
multiple messages for each node i am sugesting to club those messages and
the corresponding node will pick only required information.

Best Regds,
Ashwin

On Wed, Jan 13, 2010 at 12:13 AM, Nitin Bahadur <[email-masked]> wrote:

>         Each pkt that ingress A sends, it's DDMT always sets  the Address
> Type to either IPv4 Unnumbered or IPv6 Unnumbered.

---

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Wed, 13 Jan 2010 18:04:07 +0530

Hi,

I think i got the part of the answer for question 2, i was assuming the echo
reply too contains DDMT with 224.0.0.2, i think the reply should contain the

appropriate values.
So i got further questions, how do the ingress form topology if DDMT is not
added in the echo request (Is this a valid case?)
How do we support this for the unnumbered interface case (Where the echo
reply actually contains the 224.0.0.2) ?

Best Regds
Ashwin

On Wed, Jan 13, 2010 at 5:56 PM, Ashwin C. Prabhu
<[email-masked]>wrote:

> On Wed, Jan 13, 2010 at 12:13 AM, Nitin Bahadur <[email-masked]>wrote:
>
>> Hi Ashwin,
>>

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Wed, 13 Jan 2010 11:36:32 -0600

Hi Ashwin,

I could not get to this yesterday. My answers are inline.

   "The transit LSR also returns information on an echo response that
helps verify the control plane against the data plane.  That 

   is, the information is used by the ingress to check that the data
plane forwarding, matches what is signaled by the control plane"

  The ingress referes to what? The ingress lsr or the ingress interface
of the transit lsr? Its not very clear from the above statement.

[Shaleen Saxena (ssaxena): ] This section comes from the version 0 of
the draft. The original intent was to verify forwarding from one hop to
next. I think paragraphs needs to be updated as follows:

  In "traceroute" mode (fault isolation), the echo request is sent to

  the control plane at each transit LSR, and the control plane checks

  that it is indeed a transit LSR for this P2MP MPLS LSP.  The transit

    LSR returns information about the outgoing paths. This

    information can be used by ingress router to build topology or 

    downstream routers to do extra verification.

Please note that the motivation section gives a high level overview of
the design goals and not the actual implementation.

   "Downstream Detailed Mapping TLV is described in [DDMT].  A transit,
  branch or bud node can use the Downstream Detailed Mapping TLV to
  return multiple Return Codes" ...

  "As per Section 4.3 of [DDMT], the Downstream Mapping TLV as described
in
  [RFC4379] is being deprecated"

[Shaleen Saxena (ssaxena): ] In general, if a node receives DSMAP TLV,
it should not respond with DDMAP. That is, in general, a node must
respond with the same TLV. So DSMAP in echo request will cause DSMAP TLV
to be returned. Similarly DDMAP in echo request will cause DDMAP to be
returned. 

However, for P2MP MPLS OAM, DDMAP is a better choice than DSMAP; hence
DDMAP SHOULD be used for traceroute. If an ingress node still sends
DSMAP then the responding node can ignore it. The responding node should
not convert a DSMAP into DDMAP.

[Shaleen Saxena (ssaxena): ] Yes, 3.2.4 should change to just 3.2 and
similarly 3.2.5 should change to 3.3.

4.  

When A sends a echo request with TTL 1, B replies back with 2 instances
of DDMT depicitng interface BC and BE.

 4.1 How does A distinguish whether the BC and BE are ECMP paths or path
for 2 different egresses?

[Shaleen Saxena (ssaxena): ] There is no ECMP in P2MP LSPs. So two DDMAP
TLV imply two separate outgoing paths.

[Shaleen Saxena (ssaxena): ] Node A will have to build the topology step
by step. For each TTL, node A will figure out the routers at that level.
By continuing the process, node A will have the complete topology.

[Shaleen Saxena (ssaxena): ] If there is no Responder Identifier TLV,
then interface validation will have to be skipped. For the reasons you
mention, it is not possible for node A to combine all the incoming DDMAP
into one single outgoing DDMAP. Hence, if no Responder Identifier TLV,
is present, then node A will have to use the wildcard DDMAP always.

If Egress Address Responder Identifier TLV  is being used for
traceroute, then it is possible to reuse the incoming DDMAP.

4.4 Do we need B to send back more information such as the egress to
which the downstream link is being added.

      Also do we need B to differentiate between a ECMP path with the
path to multiple egress? 

     May be adding a egress address in DDMT will solve these? Or is it
that it is taken care in some other ways.

[Shaleen Saxena (ssaxena): ] For P2MP RSVP TE Tree, a node may be aware
of the downstream addresses. However for mLDP Tree, a midpoint node will
not know the egress address. So it is not always feasible to send egress
information. Even in P2MP RSVP TE tree, the scaling must be considered.
Each outgoing interface can have hundreds of egress nodes. This is
especially true for nodes near the head. So creating an OAM packet with
this much information and parsing it  will create large processing power
for both the responding and initiating nodes.

Also, there is no ECMP in P2MP trees. 

Thanks,

Shaleen

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Wed, 13 Jan 2010 11:42:34 -0600

Hi Nitin, 

Thanks for your response. One correction: Node Address Responder
Identifier is intended for ping and Egress Address Responder Identifier
TLV is intended for traceroute.

If Node Address Responder Identifier is used for tracing, then the
head-end needs to have an a priori knowledge of the topology. 

Regards,
Shaleen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Nitin Bahadur
> Sent: Tuesday, January 12, 2010 1:44 PM
> To: Ashwin C. Prabhu; [email-masked]
> Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt
> 
> Hi Ashwin,
> 
> NB>       you can trace each sub-tree at a time using the "Node
Address
> P2MP Responder Identifier Sub-TLV"
>          Each pkt that ingress A sends, it's DDMT always sets  the
> Address Type to either IPv4 Unnumbered or IPv6 Unnumbered.
>           For IPv4, it MUST set the Downstream IP Address to
224.0.0.2.
> As per RFC 4379
>            For TTL=1, B will respond with 2 DDMT TLV (one for C and
one
> for E). A can now
> create a tree containing A, B, C, E. Now on TTL=2, A will get a
> response from C and E. Based on IP addr of
>  responding node, A will know if it's C or E and can graft the
> information regarding D or F into the tree.
> 
> egresses when the topology build-up completes. Note that for P2MP
RSVP-
> TE, there is no concept of ECMP. For
>        In the above topology, B is transit for both C & E, where as C
> is part of only D and E is part of only F.
> 
> NB> See above.
> 
>       If A is adding the DDMT in its echo Request then should it
> contain both the links received BC and BE?

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 13 Jan 2010 10:59:07 -0800

I don't see why Node Responder cannot be used to do traceroute. The draft does not prohibit it.

A - B - C - D
      |
      +----E ---F

At ttl=1, B will respond with a DDMAPs of C and E
Now A can set the node responder TLV to address of C and send a pkt with TTL=2.
At this point E should drop the packet and only C should process the packet.

Is my understanding incorrect?

Thanks
NItin

On 1/13/10 9:42 AM, "Shaleen Saxena (ssaxena)" <[email-masked]> wrote:

Hi Nitin,

Regards,
Shaleen

Of
Address
224.0.0.2.
one
RSVP-

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Wed, 13 Jan 2010 13:33:55 -0600

1. In the case of tracing node by node using the node address responder
id TLV, only way to map C to node B would be to take the help of the
IGP.

[Shaleen Saxena (ssaxena): ] That is why Egress Address Responder
Identifier TLV is the intended way for tracing.

   Do we need to consider the case of a lsp spanning accross the
Autonomous System? Does the p2mp lsp span across different AS? Or can we
have 

   lsp stitching for the p2mp lsp? If we already support any of these at
present or in future then we may not be able to map node C to its
upstream node 

   B. 

[Shaleen Saxena (ssaxena): ] I don't think we will have stitching in
P2MP LSPs.

[Shaleen Saxena (ssaxena): ] Creating a tree topology using traceroute
is going to be hard. Correlating responses from one TTL to next is not
easy. We can use the Downstream IP/Interface Address fields in DDMAP and
match it to source IP of the next response. However this may not work
under multiple circumstances. 

One scenario is when the router id is put in Downstream IP/Interface
Address fields and the next hop responds with interface address. Then
matching will not be possible. (A possible solution would be to have the
responding node return the Router ID in some new TLV.) 

Another scenario is if a router does not respond or does not give DDMAP
back. Then the topology will have holes in it and creating an overall
tree would not be possible.

Regards,

Shaleen

           A ------------ B --------------C ----------- G --------------
D
                             \----------------E ---------- H
-------------- F

   Now considering that there is no DDMT in label request message or
DDMT with unnumbered type (interface address is multicast address)

  So say at instance with TTL 3 replies received, the tree could be  A
---- B ----- C --- G or A----- B ------C --- H or A----B---E --- G or A
--- B ----E--- H

 By attaching something similar to "Node address responder id TLV" to
each instance of DDMT in the echo Request message can we not do the
interface validation even in the case of parallel trace? Basically
instead of sending multiple messages for each node i am sugesting to
club those messages and the corresponding node will pick only required
information.

Best Regds,

Ashwin

On Wed, Jan 13, 2010 at 12:13 AM, Nitin Bahadur <[email-masked]>
wrote:

Hi Ashwin,

NB>       you can trace each sub-tree at a time using the "Node Address
P2MP Responder Identifier Sub-TLV"
   and increasing ttl. So for TTL=2, A will send 2 messages: 1 with DDMT
for C and one for DDMT for E.
   This approach is similar to how you do tracert for LDP ECMP (wherein
we use different dest-ip).

If you want to trace paths in parallel....there is a way ...at expense
of reduced functionality....
        Each pkt that ingress A sends, it's DDMT always sets  the
Address Type to either IPv4 Unnumbered or IPv6 Unnumbered.
         For IPv4, it MUST set the Downstream IP Address to 224.0.0.2.
As per RFC 4379

         "If an LSR receives an Echo Request packet with the all-routers
          multicast address, then this indicates that it MUST bypass
both
           interface and label stack validation, but return Downstream
          Mapping TLVs using the information provided."

          For TTL=1, B will respond with 2 DDMT TLV (one for C and one
for E). A can now
create a tree containing A, B, C, E. Now on TTL=2, A will get a response
from C and E. Based on IP addr of
 responding node, A will know if it's C or E and can graft the
information regarding D or F into the tree.

NB> Ingress "does not care". A is building a topology during the trace
and it will realize which nodes are
egresses when the topology build-up completes. Note that for P2MP
RSVP-TE, there is no concept of ECMP. For
 mLDP, there is ECMP...but  "A" can do post-tree-computation analysis to
determine ECMP paths.

NB> See above.

Thanks
Nitin

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Wed, 13 Jan 2010 13:50:31 -0600

Hi:

Your understanding is correct. I have purposely kept the draft open on
which TLV to use for ping or trace. Section 4.1.1:

   These sub-TLVs limit the responses either to the specified router
   only or to any router on the path to the specified router.  The
   former capability is generally useful for ping mode, while the latter
   is more suited to traceroute mode.  An initiating router may indicate
   that it wishes all egresses to respond to an echo request by omitting
   the P2MP Responder Identifier TLV.

So this paragraph does not limit one or other use. The way you are
recommending is certainly possible and allowed. 

However the way I see is that a user would try to trace to some
particular egress. Now if Node Address sub-TLV is used then the
initiating node needs to know a priori on how to get there. So in your
example:

A - B - C - D
      |
      +----E ---F

If a user is trying to trace to F only, then initiating routers should
know (either via user config or from RSVP) that E is the next-hop node
to F.

Also if a mid-point node misbehaves (i.e. does not respond at all or
does not return a DDMAP), then you may not have the required information
for the next echo request.

Thanks,
Shaleen

> From: Nitin Bahadur [mailto:[email-masked]]
> Sent: Wednesday, January 13, 2010 1:59 PM
> To: Shaleen Saxena (ssaxena); Ashwin C. Prabhu; [email-masked]
> >   mLDP, there is ECMP...but  "A" can do post-tree-computation
> analysis
> > to determine ECMP paths.
> >

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 13 Jan 2010 12:15:58 -0800

Ashwin,

 1. In the case of tracing node by node using the node address responder id TLV, only way to map C to node B would be to take the help of the IGP.
    I am assuming that the node C's address is going to be a loopback address.

NB> Cannot guarantee....implementation specific.

   Do we need to consider the case of a lsp spanning accross the Autonomous System?

NB> No. Inter-as lsp-ping draft has expired.

 Does the p2mp lsp span across different AS?
 Or can we have lsp stitching for the p2mp lsp? If we already support any of these at present or in future then we may not be able to map node C to its upstream node
   B.

NB> You can always *have* lsp-stitching for p2mp lsp via some configuration...not sure how you would
do it with signaling.

2. I still didn't get how the tree is formed for tracing parallely,
    Extending the above topology adding a node G and H in the previous topology.

           A ------------ B --------------C ----------- G -------------- D
                             \----------------E ---------- H -------------- F

   Now considering that there is no DDMT in label request message

NB> Traceroute will not work if there is no DDMT in label request msg. Traceroute requires DDMT msg in
echo request.

  or DDMT with unnumbered type (interface address is multicast address)

NB> Traceroute with unnumbered interface is tricky....

  So say at instance with TTL 3 replies received, the tree could be  A ---- B ----- C --- G or A----- B ------C --- H or A----B---E --- G or A --- B ----E--- H
  The sender address of G or H doesn't indicate who is upstream?
  I think i am missing something here.

NB> Yes...you are missing the fact that DDMT is required for tracert. B would need to send the DDMTs for C & E.
Only then can A co-relate the responses from C & E.

 By attaching something similar to "Node address responder id TLV" to each instance of DDMT in the echo Request message can we not do the interface validation even in the case of parallel trace? Basically instead of sending multiple messages for each node i am sugesting to club those messages and the corresponding node will pick only required information.

NB> The draft does not support that. Echo request can contain only 1 DDMT (as of today). Also, adding multiple
DDMTs is not scalalbe. It will make the packet much bigger and increase the processing load on the transits, esp
if the packet contains a large number of DDMTs.

Nitin

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 Jan 2010 11:35:23 -0500

Shaleen,

    Please see in-line below...

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shaleen Saxena (ssaxena)
Sent: Wednesday, January 13, 2010 12:37 PM
To: Ashwin C. Prabhu; [email-masked]
Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

Hi Ashwin,

1. In the page 8 it is mentioned that
   "The transit LSR also returns information on an echo response that helps verify the control plane against the data plane.  That
   is, the information is used by the ingress to check that the data plane forwarding, matches what is signaled by the control plane"

  The ingress referes to what? The ingress lsr or the ingress interface of the transit lsr? Its not very clear from the above statement.
   I think it should be ingress interface?

[Shaleen Saxena (ssaxena): ] This section comes from the version 0 of the draft. The original intent was to verify forwarding from one hop to next. I think paragraphs needs to be updated as follows:

Please note that the motivation section gives a high level overview of the design goals and not the actual implementation.

Since this is an LSP Ping technique, the ingress in question MUST be an LSR, not a router.

  Does this mean that the p2mp ingress node can still receive Downstream Mapping TLV? If so should the ingress process it?
  Or is it that the responding node MUST reply back with DDMT?

[Shaleen Saxena (ssaxena): ] In general, if a node receives DSMAP TLV, it should not respond with DDMAP. That is, in general, a node must respond with the same TLV. So DSMAP in echo request will cause DSMAP TLV to be returned. Similarly DDMAP in echo request will cause DDMAP to be returned.

However, for P2MP MPLS OAM, DDMAP is a better choice than DSMAP; hence DDMAP SHOULD be used for traceroute. If an ingress node still sends DSMAP then the responding node can ignore it. The responding node should not convert a DSMAP into DDMAP.

 Then the wording needs to reflect this.  Currently, the choice of SHOULD in this case leaves
the implementer the choice - irrespective of whether the implementation receives a DSMAP
or a DDMAP echo request - of always returning a DSMAP echo response (if there is a good
reason to do so - where a good reason needs to be explained, or it defaults to "I felt like doing
it that way").  The wording needs to make what you say above explicit by - for example - saying
that a DDMAP TLV MUST be sent in response to a DDMAP TLV in an echo request.

[Shaleen Saxena (ssaxena): ] Yes, 3.2.4 should change to just 3.2 and similarly 3.2.5 should change to 3.3.

It would also help if the name of the TLV were consistent in usage.

4.

[Shaleen Saxena (ssaxena): ] There is no ECMP in P2MP LSPs. So two DDMAP TLV imply two separate outgoing paths.

 4.2 How does node A, corelate the links BC and BE to egress D or F? (Basically how does the topology formed at ingress)
       In the above topology, B is transit for both C & E, where as C is part of only D and E is part of only F.
[Shaleen Saxena (ssaxena): ] Node A will have to build the topology step by step. For each TTL, node A will figure out the routers at that level. By continuing the process, node A will have the complete topology.

[Shaleen Saxena (ssaxena): ] If there is no Responder Identifier TLV, then interface validation will have to be skipped. For the reasons you mention, it is not possible for node A to combine all the incoming DDMAP into one single outgoing DDMAP. Hence, if no Responder Identifier TLV, is present, then node A will have to use the wildcard DDMAP always.

If Egress Address Responder Identifier TLV  is being used for traceroute, then it is possible to reuse the incoming DDMAP.

[Shaleen Saxena (ssaxena): ] For P2MP RSVP TE Tree, a node may be aware of the downstream addresses. However for mLDP Tree, a midpoint node will not know the egress address. So it is not always feasible to send egress information. Even in P2MP RSVP TE tree, the scaling must be considered. Each outgoing interface can have hundreds of egress nodes. This is especially true for nodes near the head. So creating an OAM packet with this much information and parsing it  will create large processing power for both the responding and initiating nodes.

Thanks,
Shaleen

---

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Fri, 15 Jan 2010 16:36:41 +0530

Hi,

Thanks to Nitin, Shaleen and Eric for the replies and helping with my
queries.

I understand that the number of nodes could be very large and clubbing
multiple DDMT instances in to single reply might increase the message size.
Tracing node at a time may be time consuming, atlest in the error cases.
I think the draft should have provision of clubbing multiple DDMT instances
and it is left to implementor as how they make use of this and solve the
problem of large messages. This will be atleast useful in tracing the tree
where the tree has bigger depth rather than the breadth.

If the mLDP doesn't know the egress at the transit then can we add the
incoming_interface address so that the ingress knows where to link it to?
Instead of depending on co relating the routerID and the interface address.

Thanks
Ashwin

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Fri, 15 Jan 2010 12:38:17 -0600

Hi Ashwin:

Your first point: Can you explain your clubbing multiple DDMT instances
idea a bit more, with some example topology?

Your second point: If I understand correctly, you are trying to build
the topology by matching the DDMAP information with the next hop
information, correct? So a DDMAP has the "Downstream IP Address"  and
"Downstream Interface Address". Their values are defined in RFC4379:

      If the interface to the downstream LSR is numbered, then the

      Address Type MUST be set to IPv4 or IPv6, the Downstream IP

      Address MUST be set to either the downstream LSR's Router ID or

      the interface address of the downstream LSR, and the Downstream

      Interface Address MUST be set to the downstream LSR's interface

      address.

      If the interface to the downstream LSR is unnumbered, the Address

      Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP

      Address MUST be the downstream LSR's Router ID, and the Downstream

      Interface Address MUST be set to the index assigned by the

      upstream LSR to the interface.

So depending on the interface being numbered or unnumbered, you may or
may not have the downstream interface address. In that case only the
router-id can be matched. So to do an effective match, you need both
interface address and router-id. And this is covered by the "Interface
and Label Stack TLV" of RFC 4379, section 3.6. You can set the I bit in
DS Flag to get this information.

Now this will work as long as every LSR in the network can return these
values. If a LSR does not return a response or does not return the DDMAP
or the downstream one does not return the ILS TLV, then matching won't
work.  Also I wonder how TE FRR would figure in this picture. If a link
is protected via FRR, then will you be able to do correct matching?

Regards,

Shaleen

From: Ashwin C. Prabhu [mailto:[email-masked]] 
Sent: Friday, January 15, 2010 6:07 AM
To: Eric Gray
Cc: Shaleen Saxena (ssaxena); [email-masked]
Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

Hi, 

I understand that the number of nodes could be very large and clubbing
multiple DDMT instances in to single reply might increase the message
size. 

I think the draft should have provision of clubbing multiple DDMT
instances and it is left to implementor as how they make use of this and
solve the 

problem of large messages. This will be atleast useful in tracing the
tree where the tree has bigger depth rather than the breadth. 

If the mLDP doesn't know the egress at the transit then can we add the
incoming_interface address so that the ingress knows where to link it
to? Instead of depending on co relating the routerID and the interface
address.

Thanks

Ashwin

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Fri, 15 Jan 2010 12:56:00 -0600

Hi Eric:

1.       I will change the paragraph to use LSR. BTW, I researched
Ashwin's original comment on the motivation for 'traceroute mode'. That
paragraph has survived intact from the version 00 of the draft and seems
to be derived from the RFC4379 motivation. To quote RFC4379:

   In "traceroute" mode (fault

   isolation), the packet is sent to the control plane of each transit

   LSR, which performs various checks that it is indeed a transit LSR

   for this path; this LSR also returns further information that helps

   check the control plane against the data plane, i.e., that forwarding

   matches what the routing protocols determined as the path

       The original paragraph in
http://tools.ietf.org/html/draft-ietf-mpls-p2mp-lsp-ping-00: 

   In "traceroute" mode (fault isolation), the echo request is sent to
   the control plane at each transit LSR, and the control plane checks
   that it is indeed a transit LSR for this P2MP MPLS TE LSP. The
   transit LSR also returns information on an echo response that helps
   verify the control plane against the data plane. That is, the
   information is used by the ingress to check that the data plane
   forwarding matches what is signaled by the control plane.

I can see how the paragraph was derived from RFC4379. I will change it
following:

   In "traceroute" mode (fault isolation), the echo request is sent to
   the control plane at each transit LSR, and the control plane checks
   that it is indeed a transit LSR for this P2MP MPLS LSP.  The transit
   LSR returns information about the outgoing paths. This
   information can be used by ingress LSR to build topology or 
   downstream LSRs to do extra label verification.

2.       DSMAP versus DDMAP: We have had a lot of discussion on how
deprecation of DSMAP should be handled. Initially (version 08) it was
set to DDMAP MUST be used, but after feedback from other vendors,
authors and the WG chairs, it was decided to use SHOULD.

3.       Inconsistent naming in 7.2. It was an oversight, I will fix the
names.

Thanks for the comments.

Shaleen

From: Eric Gray [mailto:[email-masked]] 
Sent: Thursday, January 14, 2010 11:35 AM
To: Shaleen Saxena (ssaxena)
Cc: Ashwin C. Prabhu; [email-masked]
Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

Shaleen,

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shaleen Saxena (ssaxena)
Sent: Wednesday, January 13, 2010 12:37 PM
To: Ashwin C. Prabhu; [email-masked]
Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

Hi Ashwin,

 

Since this is an LSP Ping technique, the ingress in question MUST be an
LSR, not a router. 

Then the wording needs to reflect this.  Currently, the choice of SHOULD
in this case leaves 
the implementer the choice - irrespective of whether the implementation
receives a DSMAP 

or a DDMAP echo request - of always returning a DSMAP echo response (if
there is a good

reason to do so - where a good reason needs to be explained, or it
defaults to "I felt like doing

it that way"). The wording needs to make what you say above explicit by
- for example - saying

that a DDMAP TLV MUST be sent in response to a DDMAP TLV in an
echorequest.

 

4.  

 

 

 

Thanks,

Shaleen

---

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Mon, 18 Jan 2010 16:32:15 +0530

Hello Shaleen,

 What i was thinking was, Say if i have following topology and i want to
initiate a trace from the ingress node A.
        A --------------- B --------------C --------- D
          \----------------E -------------- F--------- G

1. If all the connections are fine then trace might reutrn the o/p fast
enough.
2. If Say link BC & CD is down then A will wait for the timeout and tracing
AEFG might take long time in node by node tracing.
3. The present parallel tracing skips the interface validation all together.

4.
Instead if A can send multiple instance of DDMT then we can as well do the
validation of the interface.
Say
A sends MPLS echo Request with TTL 1.
B & E replies back with DDMT
In the next iteration A can send MPLS echo Request with TTL 2 with
DDMT (From B) with Egress Address TLV D  + DDMT (From E) with Egress Address
TLV G packed in the single message.
Then node C which is in the path to Egress TLV D can validate the BC
interface, similary F.
As already told by you this might work only for RSVP-TE case?
With this approach we can trace the nodes parallely with lesser number of
OAM packets alogn with interface validation check.
Coming back to the problem of large message size, the
configuration/implementation can limit the number of parallel paths it
wanted to club it to. Say if we have 10 egresses then we might want to trace
5 paths first and then next 5 paths, by clubbig them together.

Let me know if you see any short comings of doing this way.

Thanks for answering the other question in my previous mail.

Thanks
Ashwin

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Tue, 19 Jan 2010 16:55:00 -0600

Hi Ashwin:

1.       If BC link is down and B is aware  of it, then B should be able
to respond to the trace quickly. If B is not aware that C is down and
still forwards to C then you will have to wait for timeout. Won't  you
have to wait for the timeout in your proposal? Will you send the next
echo request as soon as any echo response is received?

2.       The limitation that there is only one DDMAP in the Echo Request
comes from draft-ietf-mpls-lsp-ping-enhanced-dsmap
<http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-enhanced-dsmap-04>
and it mirrors RFC4379 having a similar requirement for DSMAP.

3.       You are proposing the ability to send multiple Responder
Identifier TLV and DDMAP in an Echo Request message. Also you would need
some method to match the DDMAP to its corresponding Egress Address;
otherwise you will not be able to do the correct interface validation
check. The ability to have multiple Responder Identifier TLV (or Egress
Address sub-TLV) in one message was debated extensively and rejected. If
multiple of these are allowed, then there are different scenarios where
the required behavior is ambiguous. Hence having only one Responder
Identifier TLV with only one sub-TLV makes the behavior clearly defined.

4.       The advantage of your proposal is that it will reduce the
number of Echo Requests sent. However it will not reduce the number of
Echo Responses being sent/received. Moreover it will increase the amount
of processing at the mid or tail LSRs.

5.       You can achieve the desired interface validation by two
different methods:

Method 1: Start parallel echo requests at LSR A. So if there are 10
different destinations, then you can send 10 different echo requests
simultaneously. Your basic packet will be same and you need to just
change egress address TLV and DDMAP before each send. The cost of
sending these 10 echo requests is only incrementally higher than
clubbing multiple Egress Address sub-TLV and DDMAP into one. 

Method 2: Ask each router for the ILS TLV and match the previously
received  DDMAPs. This is an extension of my solution in the previous
email. You need to match the interface address to build the tree, and
you might as well do label validation.

Both solutions  will not involve any changes to the draft and hence no
changes to behavior of the responding routers. Also all extra processing
burden will be at the head-end LSR and not on the mid or tail LSR.
Therefore it will be easier to have vendor interoperability with these
two methods

Thanks,

Shaleen

From: Ashwin C. Prabhu [mailto:[email-masked]] 
Sent: Monday, January 18, 2010 6:02 AM
To: Shaleen Saxena (ssaxena)
Cc: [email-masked]
Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

Hello Shaleen,

2. If Say link BC & CD is down then A will wait for the timeout and
tracing AEFG might take long time in node by node tracing.

3. The present parallel tracing skips the interface validation all
together. 

4.

Instead if A can send multiple instance of DDMT then we can as well do
the validation of the interface.

Say

DDMT (From B) with Egress Address TLV D  + DDMT (From E) with Egress
Address TLV G packed in the single message.

With this approach we can trace the nodes parallely with lesser number
of OAM packets alogn with interface validation check.

Coming back to the problem of large message size, the
configuration/implementation can limit the number of parallel paths it
wanted to club it to. Say if we have 10 egresses then we might want to
trace 5 paths first and then next 5 paths, by clubbig them together. 

 

Thanks

Ashwin

---

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Thu, 21 Jan 2010 18:39:51 +0530

Hello Shaleen,

Thanks for clarifying the doubts. I was not aware that the multiple
responder id TLV was previously discussed.
forgive my ignorance, i should have searched the archives. Other replies see
inline with tag [Ashwin]

One more question.
Say i have a dataplane error(bug) where it is able to forward only a single
copy and not multiple copies to its multiple nexthops then tracing
node-by-node may not detect these errors?

So shouldn't the trace follow the way the actual data flows in the p2mp case
instead of node by node?
What is the gurantee that the packet from ingress reaches multiple
destination.

I understand we have a provision for this but i was just thinking of the
short comings of the node-by-node trace.

Thanks
Ashwin

On Wed, Jan 20, 2010 at 4:25 AM, Shaleen Saxena (ssaxena) <[email-masked]

> to respond to the trace quickly. If B is not aware that C is down and still
> forwards to C then you will have to wait for timeout. Won’t  you have to
> wait for the timeout in your proposal? Will you send the next echo request
> as soon as any echo response is received?
>
[Ashwin] Yes it will wait for the timeout and hence i was thinking node by
node trace may not be good option and thought we can have some improovements
by sugeesting above.

> comes from draft-ietf-mpls-lsp-ping-enhanced-dsmap<http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-enhanced-dsmap-04>and it mirrors RFC4379 having a similar requirement for DSMAP.
>
[Ashwin] At the time of writing RFC 4379 may be the p2mp was not forseen or
considered. If it is beneficial then changing this might be a option.

> otherwise you will not be able to do the correct interface validation check.
> The ability to have multiple Responder Identifier TLV (or Egress Address
> sub-TLV) in one message was debated extensively and rejected. If multiple of
> these are allowed, then there are different scenarios where the required
> behavior is ambiguous. Hence having only one Responder Identifier TLV with
> only one sub-TLV makes the behavior clearly defined.
>
[Ashwin] Ok i didn't knew that it is previously disussed, i didn't get which
scenarios the behavior is ambguous, i will search the archives for the
discussion thread. Thanks for pointing me this.

>
>
> 4.       The advantage of your proposal is that it will reduce the number
> of Echo Requests sent. However it will not reduce the number of Echo
> Responses being sent/received. Moreover it will increase the amount of
> processing at the mid or tail LSRs.
>
[Ashwin] Yes that's right,

>
>
> 5.       You can achieve the desired interface validation by two different
> methods:
>
>
>
> simultaneously. Your basic packet will be same and you need to just change
> egress address TLV and DDMAP before each send. The cost of sending these 10
> echo requests is only incrementally higher than clubbing multiple Egress
> Address sub-TLV and DDMAP into one.
>
>  [Ashwin] Yes, i was consdering this as option.
>

> received  DDMAPs. This is an extension of my solution in the previous email.
> You need to match the interface address to build the tree, and you might as
> well do label validation.
>
[Ashwin] Thanks for letting me know about the ILS TLV i never thought about
this.

> burden will be at the head-end LSR and not on the mid or tail LSR. Therefore
> it will be easier to have vendor interoperability with these two methods
>

>
>
> Thanks,
>
> Shaleen
>
>
>
> *From:* Ashwin C. Prabhu [mailto:[email-masked]]
> *Sent:* Monday, January 18, 2010 6:02 AM
> *To:* Shaleen Saxena (ssaxena)
> *Cc:* [email-masked]
>
> *Subject:* Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt
>
>
>
> Hello Shaleen,
>
>
>

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Thu, 21 Jan 2010 15:37:19 -0600

Hi Ashwin:

The OAM packet ought to follow the data plane traffic. That is the basic
premise of RFC4379. Why won't it follow in this case?

If forwarding is broken at some branch, then you will not get responses
from downstream LSRs. As for detecting these errors, your ping needs to
be aware of what destinations are present. This is generally available
in P2MP TE but might have to be manually provided in mLDP.

Thanks,

Shaleen

From: Ashwin C. Prabhu [mailto:[email-masked]] 
Sent: Thursday, January 21, 2010 8:10 AM
To: Shaleen Saxena (ssaxena)
Cc: [email-masked]
Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-09.txt

Hello Shaleen, 

forgive my ignorance, i should have searched the archives. Other replies
see inline with tag [Ashwin]

One more question. 

Say i have a dataplane error(bug) where it is able to forward only a
single copy and not multiple copies to its multiple nexthops then
tracing node-by-node may not detect these errors?

So shouldn't the trace follow the way the actual data flows in the p2mp
case instead of node by node? 

 

 

Thanks

Ashwin