Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access
draft-ietf-trill-pseudonode-nickname-07

[Ballot discuss]
I am referring to Russ Housley's Gen-ART review. I believe we still has to resolve what to do about the sort order.

(Maybe this helps: I’m not actually sure why in a k-element set you order them based  mod k because that would seem to produce likely duplicates. Since your backup option in the case of duplicates is proper numeric sort, why just not do that and only that? E.g. "RBridges are sorted in byte string ascending order by their LAALP IDs, or if they are equal, by their System IDs considered as unsigned integers.” But it could also be that it is too early and I have not yet had enough Diet Coke…)

Also, I am not sure I understand this in Section 5.2:

  Assuming there are … k member RBridges in an RBv; ... each RBridge is
  referred to as RBj where 0 <= j < k-1

Wouldn’t that mean that for 2 bridges you have RB0 only, because j=1 does not satisfy 0 <= j < k-1 because 0 <= 1 < 1 is untrue. But again, it is too early here and maybe I’m missing something.

[Ballot discuss]

I have two questions where it's not clear to me if this
specification does or does not introduce new vulnerabilities.
It could well be that it does not and these are handled
elsewhere, but I'm not sure so...

(1) How is authorization for being a member of an RBv handled?

(2) If a rogue RB can add itself to an RBv can it arrange
things so the rogue RB becomes the DF for the RBv?  (If so,
that would seem to create new DoS opportunities at least.)

[Ballot 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?

[Ballot comment]
-- section 12, last paragraph:

Elaboration on the details would be useful. This draft adds new procedures; what analysis was done to show those new procedures have no new security impact?

Editorial:

-- 1.1, definition of AAE, "AAE is also referred to as edge group or Virtual RBridge in this document"
Why use multiple terms for the same thing? This seems to create awkward wording in several places, where the text  repeats things like “In an AAE group (i.e. RBv)…”

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-trill-pseudonode-nickname-05. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA needs to complete.

In the TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1 subregistry of the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

https://www.iana.org/assignments/trill-parameters/

four new registrations will be made as follows:

Type: [ TBD-at-Registration ]
Name: PN-LAALP-Membership
Reference: [ RFC-to-be ]

Type: [ TBD-at-Registration ]
Name: PN-RBv
Reference: [ RFC-to-be ]

Type: [ TBD-at-Registration ]
Name: PN-MAC-RI-LAALP-INFO-START
Reference: [ RFC-to-be ]

Type: [ TBD-at-Registration ]
Name: PN-MAC-RI-LAALP-INFO-END
Reference: [ RFC-to-be ]

IANA understands that these registrations are to come from the type range below the value 255.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TRILL: Pseudo-Nickname for Active-Active Access) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'TRILL: Pseudo-Nickname for Active-Active Access'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-09-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IETF TRILL (TRansparent Interconnection of Lots of Links)
  protocol provides support for flow level multi-pathing for both
  unicast and multi-destination traffic in networks with arbitrary
  topology. Active-active access at the TRILL edge is the extension of
  these characteristics to end stations that are multiply connected to
  a TRILL campus as discussed in RFC 7379. In this document, the edge
  RBridge (TRILL switch) group providing active-active access to such
  an end station are represented as a Virtual RBridge. Based on the
  concept of Virtual RBridge along with its pseudo-nickname, this
  document specifies a method for TRILL active-active access by such
  end stations.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trill-pseudonode-nickname/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trill-pseudonode-nickname/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2083/
  https://datatracker.ietf.org/ipr/2444/

1) On p. 15 & 16: I'm a bit confused because on p. 15, it says "The basic
idea of DF is to elect one RBridge per VLAN from an RBv to egress
multi-destination TRILL Data traffic and replicate locally-received
multi-destination native frames to the CEs served by the RBv."  but
then on p. 16 in Step 4 part 1), it says: "RBv ports associated with
the same pseudo-nickname as that of the incoming port, no matter
whether RBi is the DF for the frame's VLAN on the outgoing ports
except that the frame MUST NOT be replicated back to the incoming
port".  This seems to be contradictory.  Moreover, if one say CE1,
CE2, and CE3 all in the same RBv, when CE1 sends a packet to RB2 and
RB1 is the DF for the particularly VLAN, then wouldn't RB2 forward the
packet to CE1 and CE2 while RB1 would also do so as the DF?  Could you
please clarify what is causing the inconsistency and problem?  Maybe
the text in 6.1 on p. 18 helps describe that there are actually two
cases to the text on p. 16?

2) On p.23 in Sec 9.1: There is no way of identifying what the type of
the LAALP ID is.  Assuming it is a number and meaning doesn't matter,
it would be really good to clarify that.

3) In Sec 9.2: How can an LAALP ID be withdrawn from PN-RBv
APPsub-TLV?  Could you please describe that sequence?

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  This is targeted at Proposed Standard as indicated on the title
  page.  This document specifies protocol behavior of TRILL switches
  to implement active-active services at the TRILL edge using a
  pseudo-nickname to represent an edge group of RBridges.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  Active-active access at the TRILL edge is the extension of flow
  level multi-pathing and rapid fail-over service available in the
  interior of a TRILL campus to end stations that are multiply
  connected to a TRILL campus edge as discussed in RFC 7379. In this
  document, a Virtual RBridge's pseudo-nickname represents the edge
  RBridge group providing active-active access to such an end
  station.

Working Group Summary:

  Early discussion in the TRILL WG favored a pseudo-node nickname
  approach similar to that in this draft. Later analysis resulted in
  the three alternatives described in the Introduction to
  draft-ietf-trill-aa-multi-attach. Two of these, which can be
  deployed simultaneously in a TRILL campus, are being advanced by
  the WG, an evolved version of alternative 1 using a pseudo-nickname
  in this draft and alternative 3 in draft-ietf-trill-aa-multi-
  attach.

  There was good WG support for this draft.

Document Quality:

  This document was developed by the WG over a two-year period. The
  document is of good quality and is being implemented.
 
Personnel:

  Document Shepherd: Donald Eastlake, 3rd
  Responsible Area Director: Alia Atlas

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

  The Shepherd has reviewed this document at various stages and
  provided feedback. The most recent and formal Shepherd review is
  here:
  http://www.ietf.org/mail-archive/web/trill/current/msg06637.html

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

  No.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of?

  No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed.

  Yes.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Two IPR disclosures have been filed against this draft.  See
  https://datatracker.ietf.org/ipr/2083/ and
  https://datatracker.ietf.org/ipr/2444/
  These IPR disclosures were not noted in the first WG Last Call on
  this draft and a 2nd WG Last Call was specifically held due to that
  oversight. There were no objections.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  Many members of the WG have been involved in the development of
  strategies to provide active-active support at the TRILL edge
  [RFC7379]. This draft represents the original direction decided by
  the original active-active design team coordinated by Tissa
  Senevirathne.  Consensus for this draft continues to be reasonably
  broad.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document.

  There are no actual nits. The nits checker complains about
  non-RFC5735-compliant IPv4 addresses, but these are references to
  level 4 sections in other documents.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review required.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  This document has normative references to draft-ietf-trill-cmt and
  draft-ietf-trill-rfc7180bis both of which have passed WG Last Call.

(15) Are there downward normative references (see RFC 3967)?

  No, although there is a reference to the ISO/IEC IS-IS standard
  about which the nits checker warns.

(16) Will publication of this document change the status of any
existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

  The IANA Considerations were carefully compared with the rest of
  the text. It requests appropriate assignments from the "TRILL
  APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1"
  Registry. No other registries are used and no new registries
  created.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  No IANA registries created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such review required.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  This is targeted at Proposed Standard as indicated on the title
  page.  This document specifies protocol behavior of TRILL switches
  to implement active-active services at the TRILL edge using a
  pseudo-nickname to represent an edge group of RBridges.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  Active-active access at the TRILL edge is the extension of flow
  level multi-pathing and rapid fail-over service available in the
  interior of a TRILL campus to end stations that are multiply
  connected to a TRILL campus edge as discussed in RFC 7379. In this
  document, a Virtual RBridge's pseudo-nickname represents the edge
  RBridge group providing active-active access to such an end
  station.

Working Group Summary:

  Early discussion in the TRILL WG favored a pseudo-node nickname
  approach similar to that in this draft. Later analysis resulted in
  the three alternatives described in the Introduction to
  draft-ietf-trill-aa-multi-attach. Two of these, which can be
  deployed simultaneously in a TRILL campus, are being advanced by
  the WG, an evolved version of alternative 1 using a pseudo-nickname
  in this draft and alternative 3 in draft-ietf-trill-aa-multi-
  attach.

  There was good WG support for this draft.

Document Quality:

  This document was developed by the WG over a two-year period. The
  document is of good quality and is being implemented.
 
Personnel:

  Document Shepherd: Donald Eastlake, 3rd
  Responsible Area Director: Ted Lemon

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

  The Shepherd has reviewed this document at various stages and
  provided feedback. The most recent and formal Shepherd review is
  here:
  http://www.ietf.org/mail-archive/web/trill/current/msg06637.html

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

  No.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of?

  No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed.

  Yes.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Two IPR disclosures have been filed against this draft.  See
  https://datatracker.ietf.org/ipr/2083/ and
  https://datatracker.ietf.org/ipr/2444/
  These IPR disclosures were not noted in the first WG Last Call on
  this draft and a 2nd WG Last Call was specifically held due to that
  oversight. There were no objections.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  Many members of the WG have been involved in the development of
  strategies to provide active-active support at the TRILL edge
  [RFC7379]. This draft represents the original direction decided by
  the original active-active design team coordinated by Tissa
  Senevirathne.  Consensus for this draft continues to be reasonably
  broad.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document.

  There are no actual nits. The nits checker complains about
  non-RFC5735-compliant IPv4 addresses, but these are references to
  level 4 sections in other documents.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review required.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  This document has normative references to draft-ietf-trill-cmt and
  draft-ietf-trill-rfc7180bis both of which have passed WG Last Call.

(15) Are there downward normative references (see RFC 3967)?

  No, although there is a reference to the ISO/IEC IS-IS standard
  about which the nits checker warns.

(16) Will publication of this document change the status of any
existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

  The IANA Considerations were carefully compared with the rest of
  the text. It requests appropriate assignments from the "TRILL
  APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1"
  Registry. No other registries are used and no new registries
  created.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  No IANA registries created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such review required.