Skip to main content

Network-Assigned Upstream Label
RFC 8359

Yes

(Deborah Brungard)

No Objection

Alvaro Retana
Warren Kumari
(Adam Roach)
(Alexey Melnikov)
(Alia Atlas)
(Alissa Cooper)
(Ben Campbell)
(Benoît Claise)
(Kathleen Moriarty)
(Mirja Kühlewind)
(Suresh Krishnan)

Note: This ballot was opened for revision 10 and is now closed.

Alvaro Retana No Objection

Warren Kumari No Objection

(Deborah Brungard; former steering group member) Yes

Yes (for -10)

                            

(Adam Roach; former steering group member) No Objection

No Objection (for -11)

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -11)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -11)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -11)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (for -11)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (for -11)

                            

(Eric Rescorla; former steering group member) No Objection

No Objection (2018-01-10 for -11)
Per email exchange:


I wrote:
Can an upstream node have multiple labels that it is receiving
traffic on?  I assume that the answer is "yes". If so, what happens if
the downstream node picks a label that collides with another label?

Response is:
[VPB] Yes, it is possible for the downstream node to pick a symmetric label that is not acceptable to the upstream node. The upstream node responds with a ResvErr in such cases (this is usual Generalized Label Object processing — See Section 2.3 in RFC3473) and the downstream node would end up picking something else. In order to avoid this unnecessary exchange, the upstream node would include a LABEL_SET object in the PATH message. The LABEL_SET object will carry a list of valid labels that are acceptable on the Upstream node.


The text isn't entirely clear on this point. The most on-point thing seems to be:
   In response, the downstream node picks an appropriate symmetric label
   and sends it via the LABEL object in the Resv message.  The upstream
   node would then start using this symmetric label for both directions
   of the LSP.  If the downstream node cannot pick the symmetric label,
   it MUST issue a PathErr message with a "Routing Problem/Unacceptable
   Label Value" indication.  If the upstream node that signals an
   Unassigned Upstream Label receives a label with the "all-ones"
   pattern in the LABEL object of the Resv message, it MUST issue a
   ResvErr message with a "Routing Problem/Unacceptable Label"
   indication.

   The upstream node will continue to signal the Unassigned Upstream
   Label in the Path message even after it receives an appropriate
   symmetric label in the Resv message.  This is done to make sure that
   the downstream node would pick a different symmetric label if and
   when it needs to change the label at a later time.  If the upstream
   node receives an unacceptable changed label, then it MUST issue a
   ResvErr message with a "Routing Problem/Unacceptable Label"
   indication.

But the first graf talks about all ones and the second talks about subsequent changes. Neither addresses the initial label

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -11)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -11)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (2017-12-29 for -10)
I believe you when you say this

   As per the existing
   setup procedure outlined for a bidirectional LSP, each upstream node
   must allocate a valid upstream label on the outgoing interface before
   sending the initial Path message downstream.  However, there are
   certain scenarios where it is not desirable or possible for a given
   node to pick the upstream label on its own.  This document defines
   the protocol mechanism to be used in such scenarios.

but I wonder if you could give an example or two of those "certain scenarios", so that readers would know whether they need to keep reading. 

After reading all of Section 3, I found myself wondering whether that use case was one of the "certain scenarios", but I couldn't tell for certain. If it is, even a forward reference to Section 3 in the Introduction would have helped me.

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -11)