Subject: [trill] Alissa Cooper's Discuss on draft-ietf-trill-vendor-channel-00: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Tue, 06 Mar 2018 12:28:36 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-trill-vendor-channel-00: Discuss

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-trill-vendor-channel/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm having trouble understanding what function this specification serves given
that the RBridge Channel Protocol registry has a range reserved already for
private use and that the document doesn't specify any requirements around
vendor-specific protocol semantics. So any implementation of this that needs to
interoperate with another implementation will need to do so according to some
specification generated by the vendor, and that specification can select a code
point from the private use range. What does allocating a single code point for
all such vendor-specific protocols achieve, aside from specifying a structured
way of conveying the OUI/CID (which seems superfluous anyway for multiple
implementations from a single vendor interoperating with each other)?

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

I agree with the Gen-ART reviewer that the text in the Acknowledgements section
is not appropriate. See RFC 7322.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 6 Mar 2018 23:11:44 -0500

Hi Alissa,

On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper <[email-masked]> wrote:
> ...

What if two TRILL campuses using the same private code point for
incompatible purposes are accidentally interconnected?

What if someone wants to use TRILL switches from two different vendors
each of which uses the same private code point for incompatible
purposes? Say one vendor makes highly flexible/desirable edge TRILL
switches while the other make particularly cost effective core TRILL
switches or particularly nifty Level 1 / Level 2 border TRILL
switches, or whatever.

"private" code points seem pretty flakey compared with the more robust
mechanism in this draft.

Maybe this document should also depredate the use of private code points.

OK.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 7 Mar 2018 10:23:47 -0500

> On Mar 6, 2018, at 11:11 PM, Donald Eastlake <[email-masked]> wrote:
> 
> Hi Alissa,
> 
> On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:

Right, both of those examples make it sound like the purpose of having this document specify a code point is because the existing private use range is problematic. Your first example seems to directly contradict the guidance in RFC 7178 about the use of the private range, so if that is a real concern and it outweighs the utility of having the private range for private network use, then it seems like deprecation of the private range might make sense.

The second example I see is the compelling use case for this. I will clear.

Thanks,
Alissa

> [email-masked] <mailto:[email-masked]>

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 7 Mar 2018 12:12:39 -0500

Thanks,
Donald

On Wed, Mar 7, 2018 at 10:23 AM, Alissa Cooper <[email-masked]> wrote:
> Right, both of those examples make it sound like the purpose of having this
> document specify a code point is because the existing private use range is
> problematic. Your first example seems to directly contradict the guidance in
> RFC 7178 about the use of the private range, so if that is a real concern
> and it outweighs the utility of having the private range for private network
> use, then it seems like deprecation of the private range might make sense.
>