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

2018-03-07 Thread Donald Eastlake 
Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Wed, Mar 7, 2018 at 10:23 AM, Alissa Cooper  wrote:
>
> On Mar 6, 2018, at 11:11 PM, Donald Eastlake  wrote:
>
> Hi Alissa,
>
> On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper  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   +1-508-333-2270 (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> d3e...@gmail.com
>
>

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

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

2018-03-07 Thread Alissa Cooper 

> On Mar 6, 2018, at 11:11 PM, Donald Eastlake  wrote:
> 
> Hi Alissa,
> 
> On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper  > 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   +1-508-333-2270 (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> d3e...@gmail.com 
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

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

2018-03-06 Thread Donald Eastlake 
Hi Alissa,

On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper  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.

> --
> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill