Subject: [Teas] Eric Rescorla's No Objection on draft-ietf-teas-network-assigned-upstream-label-11: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Jan 2018 18:06:51 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-teas-network-assigned-upstream-label-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-network-assigned-upstream-label/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 29 Jan 2018 22:09:47 -0500

Eric, Hi!

Please see inline.

Regards,
-Pavan

> https://datatracker.ietf.org/doc/draft-ietf-teas-network-
[Pavan]  We made a minor tweak to the last statement in the first paragraph
above.
(See diff -
https://tools.ietf.org/rfcdiff?url2=draft-ietf-teas-network-assigned-upstream-label-12.txt
).
The text now reads:

   If the upstream node that signals an Unassigned Upstream Label
   receives a label with the "all-ones" pattern or any other unacceptable
   label in the LABEL object of the Resv message, it MUST issue a
   ResvErr message with a "Routing Problem/Unacceptable Label" indication.

Please let us know if this addresses your comment.

> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jan 2018 02:34:59 -0800

LGTM

On Mon, Jan 29, 2018 at 7:09 PM, Vishnu Pavan Beeram <[email-masked]>
wrote:

> [Pavan]  We made a minor tweak to the last statement in the first
> paragraph above.
> (See diff - https://tools.ietf.org/rfcdiff?url2=draft-ietf-teas-
> network-assigned-upstream-label-12.txt).
> The text now reads:
>