Re: [trill] Spencer Dawkins' No Objection on draft-ietf-trill-pseudonode-nickname-06: (with COMMENT)

[Mingui Zhang <[e-mail]>]

Hi Spencer,

Thanks for the comments. Please see in-lines below.

> -----Original Message-----
> From: Spencer Dawkins [mailto:[e-mail]]
> Sent: Wednesday, September 16, 2015 5:27 AM
> To: The IESG
> Cc: [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Subject: Spencer Dawkins' No Objection on
> draft-ietf-trill-pseudonode-nickname-06: (with COMMENT)
> 
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-trill-pseudonode-nickname-06: No Objection
> 
> 
> 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-pseudonode-nickname/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This was an easy document for me to read through (I have some exposure to
> TRILL but am not skilled in the art). Thank you for that.
> 
> I did have some questions, but nothing at Discuss level.
> 
> In this text:
> 
> Introduction
> 
>    Other methods are possible; for example the
>    specification in this document and the specification in [MultiAttach]
>    could be simultaneously deployed for different AAE groups in the same
>    campus. It is RECOMMENDED that only one method be adopted in a TRILL
>                  ^^^^^^^^^^^
>    campus. For example, if the method is [MultiAttach] is used, TRILL
>    switches need to support the capability indicated by the Capability
>    Flags APPsub-TLV as specified in Section 4.2 of [MultiAttach]. If the
>    method defined in this document is adopted, TRILL switches need to
>    support the Affinity sub-TLV defined in [RFC7176] and [CMT]. For a
>    TRILL campus that deploys both AAE methods, TRILL switches are
>    required to support both methods.
> 
> I'm not thinking that RECOMMENDED is an RFC 2119 RECOMMENDED, but
> more broadly, I THINK this paragraph is saying, "using multiple methods on a
> TRILL campus will work, but if you use multiple methods, all of the TRILL
> switches on the campus MUST support both methods". Did I get that right?

Yes, that's right. 

> 
> If so ... you might give some justification for adopting only one method (my
> guesses were capital expense? operating expense? complexity in
> troubleshooting?),

All these concerns make sense, especially the increased complexity. The text will be updated to reflect this point.

> and perhaps even some explanation why you might adopt
> more than one method (I was guessing that you'd use more than one because
> some of your equipment doesn't support the method you want to use, but if
> TRILL switches have to support both methods, that isn't the reason, is
> it?)

When a method is adopted, it doesn't mean all RBridges in the campus have to support all features that are specified for the Active-Active Edge RBridges. There are lots of non AAE RBridges. They need only support part of the TLVs. For the non edge RBridges, they need support less.
We admit the scenario that more than one methods are adopted because AAEs from different vendors could implement different methods. 

> 
> In this text:
> 
> 3. Virtual RBridge and its Pseudo-nickname
> 
>    Since RBv is not a physical node and no TRILL frames are forwarded
>    between its ports via an LAALP, pseudo-node LSP(s) MUST NOT be
>    created for an RBv. RBv cannot act as a root when constructing
>    distribution trees for multi-destination traffic and its pseudo-
>    nickname is ignored when determining the distribution tree root for
>    TRILL campus [CMT]. So the tree root priority of RBv's nickname MUST
>    be set to 0, and this nickname SHOULD NOT be listed in the "s"
>                                   ^^^^^^^^^^
>    nicknames (see Section 2.5 of [RFC6325]) by the RBridge holding the
>    highest priority tree root nickname.
> 
> what happens if this SHOULD NOT is ignored? Do things still work?
> 

Since RBv is not a real pseudonode, it cannot let through transit traffic. It would cause packet loss in some kind of topologies if RBv is listed as the root. I think it's safer to use MUST instead of SHOULD. Thanks for the catch.

Thanks,
Mingui