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

Eric, Hi!

Please see inline.

Regards,
-Pavan

On Wed, Jan 10, 2018 at 9:06 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> 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
>
>
>
[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
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>