Subject: [Teas] Spencer Dawkins' No Objection on draft-ietf-teas-network-assigned-upstream-label-10: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Fri, 29 Dec 2017 15:26:17 -0800

Spencer Dawkins has entered the following ballot position for
draft-ietf-teas-network-assigned-upstream-label-10: 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:
----------------------------------------------------------------------

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.

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 29 Dec 2017 20:50:02 -0500

Spencer, Hi!

Thanks for the review. Please see inline for responses (prefixed VPB).

Regards,
-Pavan

> https://datatracker.ietf.org/doc/draft-ietf-teas-network-
[VPB] Yes, the use case specified in Section 3 is an example of a scenario
where it is not desirable for a given node to pick the upstream label on
its own. We will add a forward reference to Section 3 in the Introduction.

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 29 Dec 2017 21:03:40 -0600

Hi, Pavan,

> its own. We will add a forward reference to Section 3 in the Introduction.

That would help me a lot.

Thanks!

Spencer

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sat, 30 Dec 2017 06:07:16 -0500

https://tools.ietf.org/rfcdiff?url2=draft-ietf-teas-network-assigned-upstream-label-11.txt

Rev 11 addresses this concern.

Regards,
-Pavan

On Fri, Dec 29, 2017 at 10:03 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> Hi, Pavan,
>
> On Fri, Dec 29, 2017 at 7:50 PM, Vishnu Pavan Beeram <
> [email-masked]> wrote:
>
>> Spencer, Hi!
>>
>> [VPB] Yes, the use case specified in Section 3 is an example of a
>> scenario where it is not desirable for a given node to pick the upstream
>> label on its own. We will add a forward reference to Section 3 in the
>> Introduction.
>>
>