Subject: [mpls] Discrepencies in FEC Validation procedure in RFC 4379

From: Babu Subramani <[email-masked]>
Date: Fri, 18 Jun 2010 02:05:51 +0530

Hi Nitin,
I have found some discrepencies in the FEC Validation algorithm (section
4.4) given in RFC 4379. I have gone through
the mailing list but i couldn't find anything related to this issue.

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?

Please correct me if my understanding is wrong.

With Regards,
Babu

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 17 Jun 2010 17:40:35 -0700

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

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.

---

From: Babu Subramani <[email-masked]>
Date: Fri, 18 Jun 2010 13:37:10 +0530

Hi Nitin,

Thanks for your time.

I agree that the LSR should set IP address to 127.0.0.1 and interface index
to 0 when the IP address of its neighbour is not known, in which case the
interface validation is bypassed at downstream LSR.

But the RFC doesn't specify that the interface validation should be bypassed
when the address type is unnumbered (i.e., when the downstream interface is
unnumbered).  if it has to be bypassed for this case also, then why we need
to set the interface address to the value assigned by the upstream LSR?

Thanks
Babu

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

>   Does the FEC Validation algorithm given in RFC 4379 work only for PHP
> case? If the answer is 'No', then how the below

---

From: Babu Subramani <[email-masked]>
Date: Fri, 18 Jun 2010 13:41:29 +0530

Hi George/Kireeti,

Could you please clarify these discrepencies in RFC 4379?

Thanks
Babu