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

[Alissa Cooper <[e-mail]>]

> 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] <mailto:[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] <mailto:[e-mail]>