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

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 15 Sep 2015 14:26:53 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-trill-pseudonode-nickname-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

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?

If so ... you might give some justification for adopting only one method
(my guesses were capital expense? operating expense? complexity in
troubleshooting?), 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?)

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?

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 16 Sep 2015 07:10:12 +0000

Hi Spencer,

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

> -----Original Message-----
> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Wednesday, September 16, 2015 5:27 AM
> To: The IESG
> Cc: [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Spencer Dawkins' No Objection on
> draft-ietf-trill-pseudonode-nickname-06: (with COMMENT)
> 
> 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

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

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. 

>    be set to 0, and this nickname SHOULD NOT be listed in the "s"

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 16 Sep 2015 14:58:03 -0500

Hi, Mingui,

These responses all worked for me. Thank you for looking at my comments.

Spencer

On Wed, Sep 16, 2015 at 2:10 AM, Mingui Zhang <[email-masked]>
wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> (my
> All these concerns make sense, especially the increased complexity. The
> text will be updated to reflect this point.
>
> 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:
> >
> 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
>