Re: [mpls-tp] Discrepencies in FEC Validation procedure in RFC 4379

[Babu Subramani <[e-mail]>]

Hi George/Kireeti,

Could you please clarify these discrepencies in RFC 4379?


Thanks
Babu


On Fri, Jun 18, 2010 at 6:10 AM, Nitin Bahadur <[e-mail]> wrote:

>  Hi Babu,
>
> See NB> below for answer to question # 3...
> For 1) & 2).....a cursory look at the RFC indicates potential procedural
> issues. George or someone else can
> comment on that. IMO, the procedures outlined are a guidance for an
> implementation to do the right
> thing. I think you already know what the right thing to do is.
>
> Thanks
> Nitin
>
>   Does the FEC Validation algorithm given in RFC 4379 work only for PHP
> case? If the answer is 'No', then how the below
> step of the algorithm will work for the given scenario in case 1?
>
> The fourth step in section 4.4.1 (FEC Validation) in the RFC 4379 is given
> below,
>
> *“If the label mapping for FEC is Implicit Null, set FEC-status to 2 and
> proceed to step 5.
> Otherwise, if the label mapping for FEC is Label-L, proceed to step 5.
> Otherwise, set FEC-return-code to 10 ("Mapping for this FEC is not the
> given label at stack-depth"),
> set FEC-status to 1, and return.”*
>
>
> 1) PHP is disabled, the egress router receives the complete label stack
> As per the above algorithm, When performing FEC Validation at egress
> router, label mapping for the FEC
> will not match with Implicit Null. Hence it will go to else condition which
> also will not match since the Label-L
> is always initialized to Implicit Null when Label stack depth becomes zero
> at step 3 (Label  Validation) in section 4.4.
>
> In this case, it will always send the echo reply with return code set to 10
> (“Mapping for this FEC is not the given label
> at stack-depth”) which is not valid.
>
> 2) On successful verification of protocol in section 4.4.1 (FEC
> validation), FEC-return-code
> is not set but in Egress FEC validation procedure the Best-return-code is
> getting overwritten by
> value in FEC-return-code (which was initialized to zero in 4.4.1). Hence
> the echo reply will always
> be sent with the return code set to 0. Is this correct?
>
>
> 3) In trace route mode if the interface to the Downstream LSR is unnumbered
> then the Downstream
> Mapping TLV is filled as per the below procedure given in RFC 4379.
>
> *“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.”*
>
> As the Downstream Interface address in the received packet is interface
> index assigned by the
> upstream LSR for that interface, how does the Interface validation
> performed in the Downstream LSR?
>
> NB> In a subsequent paragraph.....
>
>       If an LSR does not know the IP address of its neighbor, then it
>       MUST set the Address Type to either IPv4 Unnumbered or IPv6
>       Unnumbered.  For IPv4, it must set the Downstream IP Address to
>       127.0.0.1; for IPv6 the address is set to 0::1.
>
>       If an LSR receives an Echo Request packet with either of these
> addresses in the Downstream IP
>       Address field, this indicates that it MUST bypass interface
>       verification but continue with label validation.
>
>