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

From: Lavanya Srivatsa <[email-masked]>
Date: Thu, 1 Jul 2010 13:08:53 +0530

Hi Nitin,

Please see my responses inlined with tag [LS_3].

- Lavanya

________________________________
From: Nitin Bahadur [mailto:[email-masked]]
Sent: Thursday, July 01, 2010 4:20 AM
To: Lavanya Srivatsa; MPLS TP
Subject: RE: [mpls-tp] Last Calls on P2MP LSP Ping and Enhanced DS Map

Hi Lavanya,

    Please see inline NB> below for comments.

[LS_2] I have a suggestion request. The dsmap draft states in the definition of

Remote Peer Address as "If the operation type is PUSH,  the remote peer address is the

address of the peer from which the FEC was learned."

Can the "FEC was learned" be clarified as to whether it means the peer from which the FEC being

tTraced was learnt or whether it means the peer from which the FEC of the new tunnel was learnt?

This is what misled me to my confusion.

NB>I will clarify that.

[LS_2] Agreed, that when the data plane is hiding everything, there is no need for FEC stack change TLV.

When we hide the FEC in the data-plane, what should the value of the Downstream label stack be?

Since TTL+1 will not expire in the new tunnel, at the transit node that is the egress of the new tunnel,

when TTL+1 expiry happens, the Stack-R will contain both the labels (of original FEC being traced as well as

new tunnel). What should the Stack-D contain here?

NB> If you are using PHP for the new tunnel, then Stack-R will contain just 1 label....and Stack-D will also contain 1 FEC.

If you are using UHP for the new tunnel, then it's best that the node starting the new tunnel adds a FEC-stack change TLV

in it's DSMAP response....so that the egress of the new tunnel is able to map the 2 labels in Stack-D to the 2 labels in Stack-R.

[LS_3] When we use PHP for the new tunnel, Stack-R will contain just 1 label when it reaches the egress of the

new tunnel, agreed. However, Stack-D will contain 2 labels only because the intermediate nodes of the new

tunnel (considering the example of Figure 1, I am referring to Node C here) will not inspect the Stack-D

because TTL+1 does not expire on the transit nodes of the new tunnel. So Stack-D (2 labels) and Stack-R (1 label)

will mismatch in the number of labels and the Stack-D to Stack-R validation of RFC 4379 will fail.

Secondly, when we use UHP, Stack-D and Stack-R will both contain 2 labels. However these labels will not be the

same. Node B will add outer RSVP label 1 and inner LDP label both in Stack-D and Stack-R. When this packet is

now sent from Node C to Node D (egress of the new tunnel), the outer label of Stack-R will now contain outer RSVP

Label 2 (swapped by Node C). However, Stack-D remains unchanged since TTL+1 does not expire in Node C.

So Node D will receive Stack-D and Stack-R with 2 labels that don't match. Therefore the Stack-D to

Stack-R validation of RFC 4379 will once again fail.

That is why I was asking as to what labels Stack-D should contain.

[nitin...]

If you are not hiding the new tunnel and TTL+1 will expire in the new

tunnel, then obviously TTL+2 will expire in the new tunnel as well. So for

correct interface address validation, the Downstream IP should be set to a

value that belongs to the TTL+2 node.

[LS_2] I assume that this means that for the node in the new tunnel where TTL+1 expires, the Downstream IP

address that should have been given by the immediate upstream node should be the value of the TTL+1 node.

In the example, Node B will indicate Node C's address as Downstream IP in its echo response to Node A,

and Node C will indicate Node D's address as Downstream IP in its echo response to Node A. Is this what you

mean?

NB> Yes.

[nitin...]

FEC hiding is basically hiding the details of the inner FEC. It allows the

ingress the know *all the nodes* in the LSP path, without exposing details

of the FEC stack used at all nodes in the LSP path.

[LS_2] I assume this implies that Node A should be able to learn Node C also (even though this is hidden by the newer tunnel)

in its traced route to Node E.

NB> Yes.

[nitin...]

I interpret RFC4379 such that Label-L in section 4.4.1 comes from Stack-D.

If this is not the case, then Stack-D is not used at all and there is no

point in sending a label stack in the DSMAP.

[LS_2] Considering the example of Figure 1 of dsmap draft again, in the case of FEC hiding, Node B responds with Nil FEC in the

FEC stack change TLV with an unspecified remote peer address and as you have mentioned, the Downstream IP may be

of the immediate downstream neighbour Node C. The Stack-D will contain outer RSVP Label followed by LDP label. In the

next echo request sent by Node A to Node C, the Stack-R will also contain outer RSVP Label followed by LDP label and the

RFC 4379 validations for Stack-R and Stack-D will work fine. However the FEC-to-label mapping in the FEC validation (4.4.1)

will fail since Label-L  gets updated only from Stack-R (as per the  4379 algorithm) in Step 3 (Label Validation)

and never seems to get updated from Stack-D.

Even if it gets updated from Stack-D (by inewly introducing this in the algorithm), still Stack-D will contain the RSVP label

(and not value of 0/explicit null) which will not map to the Nil FEC on Node C.

So IMHO, RFC 4379 requires changes to accommodate FEC hiding.

 NB> I see your point. Let me think about this a little more.

[LS_3] OK, will await your response on this.

Thanks

Nitin