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

From: Lavanya Srivatsa <[email-masked]>
Date: Wed, 9 Jun 2010 14:24:36 +0530

George,

Please find my comments on the Enhanced DS Map draft below:

(1) When a FEC being traced enters a new tunnel at transit node, a FEC Stack change TLV is added with Operation Type as PUSH (and at the end node of this new tunnel with operation POP). 
In case of Stitched LSPs (Transition between tunnels), the transit node includes two FEC Stack Change TLVs - one with Operation type POP and one with Operation type as PUSH.

It is not clear when a FEC Stack Change TLV will get added with an Operation Type of SWAP and under what conditions/scenario.

It will be good if examples/scenarios for the SWAP scenario is also added in the draft (similar to Sections 4.1.1 and 4.1.2 for the Additional of new tunnel and Transition between tunnels). 

(2) In section 4.1.1, it is given that the remote peer address type in the FEC Stack Change TLV must be set to "unspecified" (along with using a NIL FEC with label value of 0) when the transit node wants to hide the nature of the tunnel (FEC hiding). 
Under such a scenario, what should/would be the value set in the Downstream IP Address field? Should there be a new value of "unspecified" added in the Downstream IP Address type field also and should this value be used during FEC hiding? There is no mention about this and this needs to be included in the Enhanced DS Map draft.

(3) One more question related to FEC Hiding is that when the FEC stack Change TLV contains the NIL FEC in FEC TLV, what will happen to the FEC validation procedure at the subsequent transit nodes? As per RFC 4379, the NIL FEC would be used in cases of Explicit Null or Router Alert conditions, and the FEC validation section 4.4.1 in RFC 4379 handles this. 

However in the case of FEC Hiding, the NIL FEC is not being added/sent because of Explicit Null or Router Alert. Therefore the FEC validation procedure as per section 4.4.1 of RFC 4379 will fail and a FEC-return-code of "Mapping for this FEC is not the given label at stack-depth" will be returned (kindly refer the snippet of the algorithm that I have pasted below from section 4.4.1 of RFC 4379) -

1. Two return values, FEC-status and FEC-return-code, are initialized
      to 0.

 2. If the FEC is the Nil FEC {
         If Label-L is either Explicit_Null or Router_Alert, return.

         Else {
            Set FEC-return-code to 10 ("Mapping for this FEC is not
            the given label at stack-depth").
            Set FEC-status to 1
            Return.
         }
      }

Therefore, to address the above scenario, is there a change required in the FEC validation section 4.4.1 of RFC 4379 to handle FEC Hiding?

- Lavanya

Date: Thu, 27 May 2010 15:10:29 -0400
From: George Swallow <[email-masked]>
Subject: [mpls-tp] Last Calls on P2MP LSP Ping and Enhanced DS Map
To: "[email-masked]" <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

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: Wed, 23 Jun 2010 17:18:59 -0700

Hi Lavanya,

    Thanks for your comments. Please see inline below.

> (1) When a FEC being traced enters a new tunnel at transit 
> node, a FEC Stack change TLV is added with Operation Type as 
> PUSH (and at the end node of this new tunnel with operation POP). 
> In case of Stitched LSPs (Transition between tunnels), the 
> transit node includes two FEC Stack Change TLVs - one with 
> Operation type POP and one with Operation type as PUSH.
> 
> It is not clear when a FEC Stack Change TLV will get added 
> with an Operation Type of SWAP and under what conditions/scenario.
> It will be good if examples/scenarios for the SWAP scenario 
> is also added in the draft (similar to Sections 4.1.1 and 
> 4.1.2 for the Additional of new tunnel and Transition between 
> tunnels). 

SWAP is historical. I will remove it.

> (2) In section 4.1.1, it is given that the remote peer 
> address type in the FEC Stack Change TLV must be set to 
> "unspecified" (along with using a NIL FEC with label value of 
> 0) when the transit node wants to hide the nature of the 
> tunnel (FEC hiding). 
> Under such a scenario, what should/would be the value set in 
> the Downstream IP Address field? 

> Should there be a new value 
> of "unspecified" added in the Downstream IP Address type 
> field also and should this value be used during FEC hiding? 
> There is no mention about this and this needs to be included 
> in the Enhanced DS Map draft.

The Downstream IP address remains unchanged. Is there any specific
text you would like me to add?

> (3) One more question related to FEC Hiding is that when the 
> FEC stack Change TLV contains the NIL FEC in FEC TLV, what 
> will happen to the FEC validation procedure at the subsequent 
> transit nodes? As per RFC 4379, the NIL FEC would be used in 
> cases of Explicit Null or Router Alert conditions, and the 
> FEC validation section 4.4.1 in RFC 4379 handles this. 
> 
> However in the case of FEC Hiding, the NIL FEC is not being 
> added/sent because of Explicit Null or Router Alert. 
> Therefore the FEC validation procedure as per section 4.4.1 
> of RFC 4379 will fail and a FEC-return-code of "Mapping for 
> this FEC is not the given label at stack-depth" will be 
> returned (kindly refer the snippet of the algorithm that I 
> have pasted below from section 4.4.1 of RFC 4379) -
> 
> Therefore, to address the above scenario, is there a change 
> required in the FEC validation section 4.4.1 of RFC 4379 to 
> handle FEC Hiding?

This draft updates RFC4379. Also, as per Section 4.1.1:
   The echo response would then contain a
   FEC Stack change sub-TLV with operation type PUSH and a NIL FEC.  The
   value of the label in the NIL FEC MUST be set to zero. 

A label value of 0 is same as EXPLICIT_NULL....so RFC4379 procedures should
just work.

Thanks
Nitin

---

From: Lavanya Srivatsa <[email-masked]>
Date: Tue, 29 Jun 2010 12:23:56 +0530

Hello Nitin,

Sorry for delayed response. Please see my comments inlined.

- Lavanya

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Thursday, June 24, 2010 5:49 AM
To: Lavanya Srivatsa; MPLS TP
Subject: RE: [mpls-tp] Last Calls on P2MP LSP Ping and Enhanced DS Map

Hi Lavanya,

[LS] OK fine, thanks.

[LS] I am not sure why you say that the Downstream IP address remains unchanged. Under normal circumstances, when FEC hiding is not done, the transit node that has a new tunnel starting from it will add the remote peer address in the FEC stack change TLV to be remote peer for the new tunnel. Additionally, it will set the Downstream IP also to the same address as the remote peer since the remote peer is now the next downstream node for the new tunnel for this particular node.
Now, if FEC hiding is done, the remote peer is hidden and therefore the type is set to "unspecified". In this case, should not the Downstream IP also be unspecified (because downstream IP should be the same as the remote peer IP)? 

[LS] Please refer figure below (Figure 1 in the dsmap draft).

    A                B                C                  D               E
    o ---------- o ----------- o ------------ o --------- o
     \_____/  | \______/   \______/  | \______/
       LDP        |     RSVP           RSVP      |     LDP
                    |                                        |
                    \____________________/
                                  LDP

Here, when Node B wants to hide the RSVP FEC, it will add the Nil FEC in the FEC stack change TLV of the echo response packet to Node A. When Node A sends the next echo request, it will add the LDP FEC and the Nil FEC in the Target FEC stack TLV. When the echo request packet reaches Node C (based on TTL expiry), it will contain in its Label stack, the LDP label and the RSVP label on top. When Node C performs the FEC validation procedure as per RFC 4379, it will *not* find the FEC-to-label mapping between the Nil FEC and the RSVP label. 

Therefore even if the value of the label in the Nil FEC is 0 and matches the value of Explicit Null (as what you have stated), the Label-L that is used in the FEC-to-label mapping is obtained from the actual label stack as per RFC 4379. Therefore it will fetch only the RSVP label and not the Nil FEC label.

So, as per the logic currently present in RFC 4379, the FEC-to-label mapping validation will fail in this case.

Hence my question on whether any change in the FEC validation procedure of RFC 4379 to handle this situation.

Thanks
Nitin

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 29 Jun 2010 11:08:28 -0700

> [LS] I am not sure why you say that the Downstream IP address remains
> unchanged. Under normal circumstances, when FEC hiding is not done, the
> transit node that has a new tunnel starting from it will add the remote peer
> address in the FEC stack change TLV to be remote peer for the new tunnel.

Correct.

> Additionally, it will set the Downstream IP also to the same address as the
> remote peer since the remote peer is now the next downstream node for the new
> tunnel for this particular node.

Nope. It will set the downstream IP to the neighbor (not necessarily the
remote peer). Note that FEC hiding in control-plane is not the same as FEC
hiding in data-plane. If you are hiding the FEC in data-plane (i.e. TTL+1
will not expire in the new tunnel), then you don't even need to send a FEC
stack TLV. Since the data plane is hiding everything, there's no need to
tell the ingress that there's something interesting going on in the control
plane.

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.

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.

> Now, if FEC hiding is done, the remote peer is hidden and therefore the type
> is set to "unspecified". In this case, should not the Downstream IP also be
> unspecified (because downstream IP should be the same as the remote peer IP)?

See above.

> Here, when Node B wants to hide the RSVP FEC, it will add the Nil FEC in the
> FEC stack change TLV of the echo response packet to Node A. When Node A sends
> the next echo request, it will add the LDP FEC and the Nil FEC in the Target
> FEC stack TLV. When the echo request packet reaches Node C (based on TTL
> expiry), it will contain in its Label stack, the LDP label and the RSVP label
> on top. When Node C performs the FEC validation procedure as per RFC 4379, it
> will *not* find the FEC-to-label mapping between the Nil FEC and the RSVP
> label.
 
> Therefore even if the value of the label in the Nil FEC is 0 and matches the
> value of Explicit Null (as what you have stated), the Label-L that is used in
> the FEC-to-label mapping is obtained from the actual label stack as per RFC
> 4379. Therefore it will fetch only the RSVP label and not the Nil FEC label.

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.

Thanks
Nitin

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 30 Jun 2010 15:50:15 -0700

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.

[nitin...]

[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...]

[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...]

[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.

Thanks

Nitin