Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

2018-03-18 Thread Alvaro Retana
Thanks Donald!

On March 15, 2018 at 1:25:07 AM, Donald Eastlake (d3e...@gmail.com) wrote:

A -07 version of draft-ietf-trill-multilevel-unique-nickname has been
posted with the intent of resolving your comment as per my response
below.
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill


Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

2018-03-14 Thread Donald Eastlake
Hi Alvaro,

A -07 version of draft-ietf-trill-multilevel-unique-nickname has been
posted with the intent of resolving your comment as per my response
below.

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


On Tue, Mar 13, 2018 at 11:50 AM, Donald Eastlake  wrote:
> Hi Alvaro,
>
> On Tue, Mar 6, 2018 at 12:37 PM, Alvaro Retana  wrote:
>> Alvaro Retana has entered the following ballot position for
>> draft-ietf-trill-multilevel-unique-nickname-06: No Objection
>>
>> ...
>>
>> --
>> COMMENT:
>> --
>>
>> (1) The nickname selection process for multilevel is not backwards compatible
>> because of the use of the NickBlockFlags APPsub-TLV.  That is ok since the
>> border RBridges can recognize "old" Rbridges (ones that don't support this
>> specification) in an area. A couple of related comments:
>>
>> (1.1) Section 4.4. (Capability Indication) says that "Non border RBridges in 
>> an
>> area SHOULD understand the NickBlockFlags APPsub-TLV."  That statement is
>> somewhat contradictory (maybe that's not the right word, but the only one 
>> that
>> comes to mind):
>>
>> - On one hand, non border RBridges could be just be "old" (ones that don't
>> support this specification).  We can't normatively specify something that by
>> definition nodes that don't support this specification won't know about.
>>
>> - On the other hand, if the non border Rbridge does support this 
>> specficiation,
>> then why wouldn't it understand the NickBlockFlags APPsub-TLV?  IOW, why 
>> isn't
>> the "SHOULD" a "MUST" instead?  When is it ok to not do it?
>>
>> All this is to say that I think that "SHOULD" should not be used normatively.
>> s/SHOULD/should
>
> Sounds reasonable to me.
>
>> (1.2) Given that rfc6325 specifies a single Level 1 network, it is reasonable
>> to expect that networks implementing these multilevel extensions will grow 
>> from
>> a single area to multiple.  It would be ideal to include Deployment
>> Considerations to discuss what a Migration Path would look like.
>>
>> (2) Maybe I missed it somewhere...  The Security Considerations section says
>> that "border RBridges need to fabricate the nickname 
>> announcements...Malicious
>> devices may also fake the NickBlockFlags APPsub-TLV to announce a range of
>> nicknames."  I'm sure that malicious devices don't only include ones that are
>> unauthenticated, but may include over or under claiming by existing border
>> RBridges or even non border RBridges originating the NickBlockFlags 
>> APPsub-TLV.
>>
>> (2.1) Is the origination of the NickBlockFlags APPsub-TLV restricted to 
>> border
>> RBridges?  If so, why isn't there a check to make sure that the 
>> NickBlockFlags
>> APPsub-TLV came from a border RBridge?
>
> Such a check would add some complexity and it is not clear there would
> be much gain as an RBridge that is forging NickBlockFlags APPsub-TLVs
> would presumably just falsely claim it is a border RBridge by claiming
> ownership of at least one Level 2 nickname.
>
>> (2.2) rfc8243 talks about the (potential) ability of border RBridges to
>> "discover each other...by using the IS-IS "attached bit" [IS-IS] or by
>> explicitly advertising in their LSP "I am a border RBridge".  But I didn't 
>> see
>> these options/mechanisms mentioned in this document.
>
> Border RBridges know they are border RBridges because, by
> configuration, they are talking to both Level 1 and 2. They act
> specially but it is not clear what good looking at the attached bit or
> border RBridges advertising that explicitly in the LSP would do. If
> you are in Level 2 and see some Level 2 RBridge advertising that it
> owns Level 1 nicknames, you know it is a border RBridge and likewise,
> if you are in Level 1 and see some Level 1 RBridge advetising that it
> owns Level 2 nicknames, you know it is a border RBridge. And the
> nicknames are distinguished by being taken from mutually exclusive
> ranges of nicknames.
>
> 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] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

2018-03-13 Thread Donald Eastlake
Hi Alvaro,

On Tue, Mar 6, 2018 at 12:37 PM, Alvaro Retana  wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-multilevel-unique-nickname-06: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> (1) The nickname selection process for multilevel is not backwards compatible
> because of the use of the NickBlockFlags APPsub-TLV.  That is ok since the
> border RBridges can recognize "old" Rbridges (ones that don't support this
> specification) in an area. A couple of related comments:
>
> (1.1) Section 4.4. (Capability Indication) says that "Non border RBridges in 
> an
> area SHOULD understand the NickBlockFlags APPsub-TLV."  That statement is
> somewhat contradictory (maybe that's not the right word, but the only one that
> comes to mind):
>
> - On one hand, non border RBridges could be just be "old" (ones that don't
> support this specification).  We can't normatively specify something that by
> definition nodes that don't support this specification won't know about.
>
> - On the other hand, if the non border Rbridge does support this 
> specficiation,
> then why wouldn't it understand the NickBlockFlags APPsub-TLV?  IOW, why isn't
> the "SHOULD" a "MUST" instead?  When is it ok to not do it?
>
> All this is to say that I think that "SHOULD" should not be used normatively.
> s/SHOULD/should

Sounds reasonable to me.

> (1.2) Given that rfc6325 specifies a single Level 1 network, it is reasonable
> to expect that networks implementing these multilevel extensions will grow 
> from
> a single area to multiple.  It would be ideal to include Deployment
> Considerations to discuss what a Migration Path would look like.
>
> (2) Maybe I missed it somewhere...  The Security Considerations section says
> that "border RBridges need to fabricate the nickname announcements...Malicious
> devices may also fake the NickBlockFlags APPsub-TLV to announce a range of
> nicknames."  I'm sure that malicious devices don't only include ones that are
> unauthenticated, but may include over or under claiming by existing border
> RBridges or even non border RBridges originating the NickBlockFlags 
> APPsub-TLV.
>
> (2.1) Is the origination of the NickBlockFlags APPsub-TLV restricted to border
> RBridges?  If so, why isn't there a check to make sure that the NickBlockFlags
> APPsub-TLV came from a border RBridge?

Such a check would add some complexity and it is not clear there would
be much gain as an RBridge that is forging NickBlockFlags APPsub-TLVs
would presumably just falsely claim it is a border RBridge by claiming
ownership of at least one Level 2 nickname.

> (2.2) rfc8243 talks about the (potential) ability of border RBridges to
> "discover each other...by using the IS-IS "attached bit" [IS-IS] or by
> explicitly advertising in their LSP "I am a border RBridge".  But I didn't see
> these options/mechanisms mentioned in this document.

Border RBridges know they are border RBridges because, by
configuration, they are talking to both Level 1 and 2. They act
specially but it is not clear what good looking at the attached bit or
border RBridges advertising that explicitly in the LSP would do. If
you are in Level 2 and see some Level 2 RBridge advertising that it
owns Level 1 nicknames, you know it is a border RBridge and likewise,
if you are in Level 1 and see some Level 1 RBridge advetising that it
owns Level 2 nicknames, you know it is a border RBridge. And the
nicknames are distinguished by being taken from mutually exclusive
ranges of nicknames.

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