Subject: [mpls] Comments on draft-ietf-mpls-p2mp-lsp-ping-10

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Tue, 23 Mar 2010 20:16:04 +0530

Hello Shaleen/Nitin,

I have some queries/comments on the p2mp lsp ping drafts.

   intf 1          intf 1
A ------------- B ------------ C
\----------------/\---------------/
 intf 2            intf2

If i have a p2mp lsp (rsvp) with 2 branches both starting from A and
reaching the egress C but on different interface.

1. When B (transit node) receives the echo request with egress ID TLV (as
C's router id) how does B know if the DDM should contain intf1 as its
nexthop or intf2?
    Should we enhance the FEC TLV to also contain more information (if
required) about the branch lsp?

2. For node C too the similar problem exist. For which path should C
validate and return the code?

3.If the ResponderID TLV is not present and if a node is egress to multiple
branches then how will it send multiple return codes? As per RFC 4379 egress
doesn't add
   any DDMTLV and the lsping header has provision for only one return
code/sub code.

4. Section 4.2.1.3 of draft-10 for bud nodes states

   Node behavior guidelines:

      - If the Responder Identifier TLV is not present, then the node
        will behave as a combination egress and branch node.

      - If the Responder Identifier TLV containing a Node Address
        sub-TLV is present, and:

         - If the address specified in the sub-TLV matches to an address
           in the node, then the node will behave like an egress node
           only.

[Ashwin] Is this not limiting the scope of the node address sub TLV, Can we
also have a case of transit node behavior even with the
node address sub TLV? Say if the implementation is making use of the Node
Address sub TLV even for RSVP then we should have
transit node behavior too.

         - If the address specified in the sub-TLV does not match any
           address in the node, then no response will be sent.

Thanks,
Ashwin

---

From: "Ashwin C. Prabhu" <[email-masked]>
Date: Tue, 23 Mar 2010 21:20:06 +0530

Just to add to below,

even without the below setup.  If we are using the  responder id TLV then we
might have to send the branchlsp information for validating the FEC. If
there is no branch lsp information then we are just validating the p2mp FEC
which might not be complete?

Ashwin

---

From: "Shaleen Saxena (ssaxena)" <[email-masked]>
Date: Mon, 29 Mar 2010 16:45:29 -0500

Hi Ashwin:

Please see the responses inline.

Regards,

Shaleen

From: Ashwin C. Prabhu [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2010 11:50 AM
To: [email-masked]; Shaleen Saxena (ssaxena); Nitin Bahadur
Subject: Re: Comments on draft-ietf-mpls-p2mp-lsp-ping-10

Just to add to below,

even without the below setup.  If we are using the  responder id TLV
then we might have to send the branchlsp information for validating the
FEC. If there is no branch lsp information then we are just validating
the p2mp FEC which might not be complete?

[Shaleen Saxena (ssaxena): ] Why do you think that P2MP FEC is not
complete? We are trying to ping or trace the P2MP Tree. The P2MP FEC is
sufficient to identify it. Also see next point.

Ashwin

On Tue, Mar 23, 2010 at 8:16 PM, Ashwin C. Prabhu
<[email-masked]> wrote:

Hello Shaleen/Nitin, 

   intf 1          intf 1

 intf 2            intf2 

1. When B (transit node) receives the echo request with egress ID TLV
(as C's router id) how does B know if the DDM should contain intf1 as
its nexthop or intf2?

[Shaleen Saxena (ssaxena): ] Both the branches are the same tree. Also
they do not have separate LSP ID. The whole tree has only one LSP ID. 

In this scenario B has two incoming interfaces and two incoming labels.
If you want, you can use the input label or interface information to
separate out the two branches you have. You can put information about
the outgoing interface corresponding to the input label in the DDMAP for
a given reply.

[Shaleen Saxena (ssaxena): ] For both B and C, there will be two
incoming echo requests.  B and C will have to respond to each of them
independently. For identifying the tree, the P2MP FEC should be
sufficient. If you want to distinguish the branch, use the incoming
label and interface information.

3.If the ResponderID TLV is not present and if a node is egress to
multiple branches then how will it send multiple return codes? As per
RFC 4379 egress doesn't add 

[Shaleen Saxena (ssaxena): ] So referring to your diagram above, the
egress C will get multiple echo request packets and should respond to
each of them. DSMAP and DDMAP are used to provide details about the
outgoing interfaces. For an egress node, there is no outgoing interface.
Hence DSMAP and DDMAP are not sent from any egress node.

[Ashwin] Is this not limiting the scope of the node address sub TLV, Can
we also have a case of transit node behavior even with the 

node address sub TLV? Say if the implementation is making use of the
Node Address sub TLV even for RSVP then we should have

[Shaleen Saxena (ssaxena): ] Yes. This is a deliberate attempt to limit
the number of responses. The concept of Node Address Responder
Identifier sub-TLV is to reach only one particular LSR. The operator is
trying to verify connectivity to the address in this sub-TLV. If this
LSR is a bud node, then it is simpler for it to respond as an egress
node.

Thanks,

Ashwin