Ballot for draft-ietf-teas-network-assigned-upstream-label
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
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
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.