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

[Nitin Bahadur <[e-mail]>]

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) -
> 
> 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?

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