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

[Donald Eastlake <[e-mail]>]

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Wed, Mar 7, 2018 at 10:23 AM, Alissa Cooper <[e-mail]> wrote:
>
> On Mar 6, 2018, at 11:11 PM, Donald Eastlake <[e-mail]> wrote:
>
> Hi Alissa,
>
> On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper <[e-mail]> wrote:
>
> Alissa Cooper has entered the following ballot position for
> draft-ietf-trill-vendor-channel-00: Discuss
>
> ...
>
> ----------------------------------------------------------------------
> 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)?
>
>
> 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.
>
>
> 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
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I agree with the Gen-ART reviewer that the text in the Acknowledgements
> section
> is not appropriate. See RFC 7322.
>
>
> OK.
>
> Thanks,
> Donald
> ===============================
> Donald E. Eastlake 3rd   [phone] (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> [e-mail]
>
>