Subject: [mpls] [Technical Errata Reported] RFC3031 (4331)

From: RFC Errata System <[email-masked]>
Date: Thu, 9 Apr 2015 06:29:48 -0700 (PDT)

The following errata report has been submitted for RFC3031,
"Multiprotocol Label Switching Architecture".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3031&eid=4331

--------------------------------------
Type: Technical
Reported by: Robert Shearman <[email-masked]>

Section: 3.22

Original Text
-------------
When a labeled packet is traveling along an LSP, it may occasionally
happen that it reaches an LSR at which the ILM does not map the
packet's incoming label into an NHLFE, even though the incoming label
is itself valid.  This can happen due to transient conditions, or due
to an error at the LSR which should be the packet's next hop.

Corrected Text
--------------
When a labeled packet is traveling along an LSP, it may occasionally
happen that it reaches an LSR at which the ILM does not map the
packet's incoming label into an NHLFE, even though the incoming label
is itself valid and it has a usable L3 next hop.  This can happen due
to transient conditions, or due to an error at the LSR which should
be the packet's next hop.

Notes
-----
There is ambiguity as to the cause of the "ILM [not mapping] the packet's incoming label into an NHLFE". It could be read in a number of ways, of which only one can be correct:

1. The label is valid in terms of syntax (e.g. not Implicit NULL), but no binding has been installed because the label hasn't been advertised. Clearly, 3.18 covers this case already, and is inconsistent with the section title of "Lack of Outgoing Label" so this interpretation is unlikely to have been intended.

2. The label is valid and is expected to be used for forwarding, but an NHLFE entry is missing or not usable because the interface the next hop is reachable over has gone down, or for some other reason isn't usable. This interpretation is ruled out by the statement that "it is tempting in such cases to strip off the label stack and attempt to forward the packet further via conventional forwarding", which wouldn't be possible if the interface was down.

3. A resource allocation error occurred meaning that the ILM binding was allocated, but the NHLFE entry couldn't be allocated. There is no mention of resource issues in this or related sections so again this interpretation seems unlikely.

4. The label is valid and is expected to be used for forwarding, but the LSR has received no label binding from the LSP's next hop even though it has a usable L3 next hop  (i.e. it lacks an outgoing label). It cannot map to an NHLFE entry because the actions in section 3.10 don't include popping and forwarding as unlabeled. This is therefore the interpretation that best fits.

To clarify that interpretation 4 is the one intended, the phrase "and it has a usable L3 next hop" is inserted into the text, using the definition of L3 next hop from section 3.17.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3031 (draft-ietf-mpls-arch-06)
--------------------------------------
Title               : Multiprotocol Label Switching Architecture
Publication Date    : January 2001
Author(s)           : E. Rosen, A. Viswanathan, R. Callon
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 10 Apr 2015 01:09:25 +0000

Hi all,

It seems that interpretation 4 would become more common in MPLS-SPRING (i.e., segment routing) networks where OSPF or ISIS is used as a label distribution protocol and partial routers are still legacy routers (e.g. pure IP router). In this case, it seems feasible to allow the LSR to replace the top label by an IP-based tunnel header and then forward the packet further via conventional IP forwarding. The tunnel destination is the /32 or /128 FEC prefix corresponding to that top label. For more details about this usage, please refer to https://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-04. This usage is valuable both in the incremental deployment case where partial routers have not yet be upgraded to support MPLS-SPRING and in some specific cases where it's unnecessary to make all routers to be MPLS-SPRING-capable (e.g., in the dual-plane TE scenario where only the edge routers of each plane need to be MPLS-SPRING-capable).

Best regards,
Xiaohu

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of RFC Errata System
> Sent: Thursday, April 09, 2015 9:30 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [mpls] [Technical Errata Reported] RFC3031 (4331)
> 
> The following errata report has been submitted for RFC3031, "Multiprotocol
> Label Switching Architecture".
> 
> When a labeled packet is traveling along an LSP, it may occasionally happen that
> it reaches an LSR at which the ILM does not map the packet's incoming label into
> an NHLFE, even though the incoming label is itself valid.  This can happen due
> to transient conditions, or due to an error at the LSR which should be the
> packet's next hop.
> 
> Corrected Text
> --------------
> When a labeled packet is traveling along an LSP, it may occasionally happen that
> it reaches an LSR at which the ILM does not map the packet's incoming label into
> an NHLFE, even though the incoming label is itself valid and it has a usable L3
> next hop.  This can happen due to transient conditions, or due to an error at
> the LSR which should be the packet's next hop.
> 
> Notes
> -----
> There is ambiguity as to the cause of the "ILM [not mapping] the packet's
> incoming label into an NHLFE". It could be read in a number of ways, of which
> only one can be correct:
> 
> 1. The label is valid in terms of syntax (e.g. not Implicit NULL), but no binding has
> been installed because the label hasn't been advertised. Clearly, 3.18 covers this
> case already, and is inconsistent with the section title of "Lack of Outgoing Label"
> so this interpretation is unlikely to have been intended.
> 
> 2. The label is valid and is expected to be used for forwarding, but an NHLFE
> entry is missing or not usable because the interface the next hop is reachable
> over has gone down, or for some other reason isn't usable. This interpretation is
> ruled out by the statement that "it is tempting in such cases to strip off the label
> stack and attempt to forward the packet further via conventional forwarding",
> which wouldn't be possible if the interface was down.
> 
> 3. A resource allocation error occurred meaning that the ILM binding was
> allocated, but the NHLFE entry couldn't be allocated. There is no mention of
> resource issues in this or related sections so again this interpretation seems
> unlikely.
> 
> 4. The label is valid and is expected to be used for forwarding, but the LSR has
> received no label binding from the LSP's next hop even though it has a usable L3
> next hop  (i.e. it lacks an outgoing label). It cannot map to an NHLFE entry
> because the actions in section 3.10 don't include popping and forwarding as
> unlabeled. This is therefore the interpretation that best fits.
> 
> To clarify that interpretation 4 is the one intended, the phrase "and it has a
> usable L3 next hop" is inserted into the text, using the definition of L3 next hop
> from section 3.17.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please use "Reply
> All" to discuss whether it should be verified or rejected. When a decision is
> reached, the verifying party (IESG) can log in to change the status and edit the
> report, if necessary.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 10 Apr 2015 02:18:34 +0000

Xioahu et all,

The transient case talked in 3.22 can be more frequent for  MPLS-SPRING, if the NH node is still re-converging while traffic hits travelling along the installed ingress LSP. I heard this (@IETF-92)  from the early test scenarios with SPRING. Any possible solution here other than dropping the packet?

The case you pointed below in non-transient case which is possible as alluded with both incremental deployments or new IP based deployments (MBH)  with few MPLS-SPRING nodes. 

Thanks!
--
Uma C.

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, April 09, 2015 6:09 PM
To: RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; spring
Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (4331)

Hi all,

Best regards,
Xiaohu

> to transient conditions, or due to an error at the LSR which should be the packet's next hop.
> 
> Notes
> -----
> There is ambiguity as to the cause of the "ILM [not mapping] the 
> packet's incoming label into an NHLFE". It could be read in a number 
> of ways, of which only one can be correct:
> 
> 1. The label is valid in terms of syntax (e.g. not Implicit NULL), but 
> no binding has been installed because the label hasn't been 
> advertised. Clearly, 3.18 covers this case already, and is inconsistent with the section title of "Lack of Outgoing Label"
> 2. The label is valid and is expected to be used for forwarding, but 
> an NHLFE entry is missing or not usable because the interface the next 
> hop is reachable over has gone down, or for some other reason isn't 
> usable. This interpretation is ruled out by the statement that "it is 
> tempting in such cases to strip off the label stack and attempt to 
> forward the packet further via conventional forwarding", which wouldn't be possible if the interface was down.
> 
> 3. A resource allocation error occurred meaning that the ILM binding 
> was allocated, but the NHLFE entry couldn't be allocated. There is no 
> mention of resource issues in this or related sections so again this 
> interpretation seems unlikely.
> 
> 4. The label is valid and is expected to be used for forwarding, but 
> the LSR has received no label binding from the LSP's next hop even 
> though it has a usable L3 next hop  (i.e. it lacks an outgoing label). 
> It cannot map to an NHLFE entry because the actions in section 3.10 
> don't include popping and forwarding as unlabeled. This is therefore the interpretation that best fits.
> 
> To clarify that interpretation 4 is the one intended, the phrase "and 
> it has a usable L3 next hop" is inserted into the text, using the 
> definition of L3 next hop from section 3.17.
> 
> Instructions:
> -------------
> use "Reply All" to discuss whether it should be verified or rejected. 
> When a decision is reached, the verifying party (IESG) can log in to 
> change the status and edit the report, if necessary.
>