Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments
draft-ietf-trill-aa-multi-attach-06

[Ballot comment]
I've already had an exchange with an author about these comments, and he's resolving them very much to my satisfaction.  Thanks!

-- Section 4.1 --

  It's
  RECOMMENDED that the receiving edge RBridge disable the data plane
  MAC learning from TRILL Data packet decapsulation within those
  advertised Data Labels for the originating RBridge unless the
  receiving RBridge also supports Option A. However, alternative
  implementations MAY be used to produce the same expected behavior.

A minor point, because I think people will properly understand this, but the "SHOULD do X but MAY do Y" construction is a misuse of 2119 language -- the MAY contradicts the SHOULD, because "MAY" says that doing Y is entirely optional.  In this case, I think the best fix is to remove the 2119 language from the second part, making the last sentence, "Alternative implementations that produce the same expected behavior are acceptable," which leaves the initial RECOMMENDED in force.

-- Section 5.3.1 --

  If the output of the selection
  function points to the port attached to the receiving RBridge itself
  (i.e., the packet should be egressed out of this node), it MUST
  egress this packet for that AAE group.

What is the antecedent to "it"?  It looks like it's "the output of the selection function", but I think it's supposed to refer to "the receiving RBridge"; is that right?  If so, I suggest making that clear:

NEW
  If the output of the selection
  function points to the port attached to the receiving RBridge itself
  (i.e., the packet should be egressed out of this node), the receiving
  RBridge MUST egress this packet for that AAE group.
END

  (It is output or not as specified in
  [RFC6325] updated by [RFC7172] for ports that lead to non-AAE links.)

I can't parse this, and have no idea what it means; can you please rephrase?

-- Section 5.3.2 --

  When a multi-destination frame originated from an LAALP is ingressed
  by an RBridge of an AAE group, distributed to the TRILL network and
  then received by another RBridge in the same AAE group, it is
  important that this RBridge does not egress this frame back to this
  LAALP.

In the last phrase, what is "this RBridge"?  There are two RBridges mentioned.  I think you mean "it is important that the second RBridge does not egress the frame back to the originating LAALP."

  Customer may need hosts within
  these overlapped VLANs to communicate with each other.

I tried a few ways to interpret this before settling on the one I think you mean.  First, it needs to say either "Customers" or "A customer", and it's not clear which.  Second, it's not clear whether you want customers or hosts to communicate.  I think this is what you mean; is it?:

NEW
  A customer may require that hosts within
  these overlapped VLANs communicate with each other.
END

-- Section 5.5 --

  In doing this, the forwarding paths
  need not be limited to the least cost Equal Cost Multiple Paths from
  the ingress RBridge to the AAE RBridges.

This reads confusingly, because it doesn't make sense to have a least cost entry from among ECMPs.  I gather that what you mean to say is that the ECMP comprises a set of equal-cost paths, and that set represents the least cost choice.  Let's see if we can find a way to word that which doesn't sound confusing.  Is it even necessary to mention ECMPs here, when the term isn't used elsewhere in the document?  Might this work just as well?:

NEW
  In doing this, the forwarding paths
  need not be limited to the least cost path selection from
  the ingress RBridge to the AAE RBridges.
END

-- Section 5.6 --

In the first sentence, "option A" should have "Option" capitalized, to be consistent with other uses of "Option A".  Similarly for "option B" in the second paragraph.

-- Section 8.2 --
I'm not making this a DISCUSS, but... it would be useful to have some guidance for the designated expert.  What should she be considering in deciding whether to approve a registration request?  I presume the expert review is to make sure the 62 remaining bits aren't expended frivolously, so what guidance can you give about when it's appropriate to say "no"?

-- Section 8.3 --
I strongly suggest that you not duplicate the whole table here, but only show the entries you're adding.  And the section title should probably have a hyphen in "Active-Active".

Also, the registry names aren't right; they're called "Interested VLANs Flag Bits" and "Interested Labels Flag Bits": http://www.iana.org/assignments/trill-parameters#interested-labels-flags

[Ballot comment]
I was also surprised there were no additions for this capability to the security considerations and will follow along to responses on Stephen's question on the same topic.

Thanks.

[Ballot comment]

- abstract: "Thus, remote edge RBridges are required to keep
multiple locations of one MAC address in one Data Label." I
find that very hard to read and don't understand what it's
telling me. Even if these terms are terms-of-art for trill, it'd
be worth being less opaque in the abstract. I have the same
problem with the intro. I think if you tried to be specific
about whose MAC address you mean (a host attached to RBridges
in the AAE) and also explained (or avoided) the term "Data
Label" here that'd help.

- 5.1: for how long is a remote RBridge "required to adhere"?
(Sorry if that's clear in 4.1, in which case I missed it.)

- 5.3.2: "well-known split horizon technique" just screams for
a reference. Please add one, which is presumably easy to do as
this is well-known:-)

- security considerations: I'm surprised there's nothing new
here. Did someone do the analysis to check? (Sorry for doubting
you but security considerations sections like this that only
consist of references are often an indicator that nobody did
take a real look;-) One possible example (not sure if it
works): if I can fake an ESADI message then I could pretend to
be the RBridge in the AAE that has least cost and so lots of
traffic would be sent to me, instead of the real RBridges in
the AAE.  Compared to the situation without this specification,
that might mean a more effective attack. Now I'm not really
sure if that's true or not (I'm sure you'll tell me) but my
question is whether or not those kinds of thing were considered
already.

[Ballot comment]
Just one question. In this text:

5.3.2. No Echo (Split Horizon)

  When a multi-destination frame originated from an LAALP is ingressed
  by an RBridge of an AAE group, distributed to the TRILL network and
  then received by another RBridge in the same AAE group, it is
  important that this RBridge does not egress this frame back to this
  LAALP. Otherwise, it will cause a forwarding loop (echo). The well
  known 'split horizon' technique is used to eliminate the echo issue.
 
Is there a canonical (or semi-canonical) reference for split horizon that you could provide here? A pointer to Appendix A would help, but that's more of a description of how to do split horizon than a description of what split horizon is.

I see that Ben also asked for this ...

[Ballot comment]
A few minor comments (no show stoppers):

-- section 4.1, first paragraph:  "However, alternative implementations MAY be used to produce the same expected behavior."

Does this talk about same “behavior”  of an RBridge (as in the observable one-the-wire bits are identical) or same “results” for the system (as in the receiving RBridge does not flip-flop)? If the former, it probably should not be normative.

-- section 5.3.2:
This section defines a sub-tlv, and related behavior. That probably doesn’t belong in the design goals analysis section. (I predict that many readers will skip section 5 entirely). Please consider moving this under section 4.

Also, can you cite something for the "well-known 'split horizon' technique"?

-- section 7:
This draft defines new data elements. It seem likely that nothing in those new elements add security considerations beyond those in the cited specs. But it would be helpful to explicitly state that.

-- 8.3:
Are you for specific flag values (16 and 4 respectively), rather than allowing IANA to assign the values as needed? Also, it seems odd to recreate the entire flag registries in a spec that merely adds new flags. The registry will change over time; this runs the risk of a reader assuming the contents listed here are current at any point in the future.  (But I see that other TRILL specs have done the same.)

Editorial Comments and Nits:

-- Abstract:
Please expand TRILL on first mention in the abstract.

-- section 1, first paragraph:
Please expand TRILL on first mention in the body, too.

-- 4.1, first paragraph:
"... in MAC learned from the TRILL...": Missing article
s/It's/It is
"A promising way..." : “promising” in this context seems to imply the option is likely, but not certain to work. Is that the intent?
s/So the receiving edge.../The receiving edge...

-- 4.1, 2nd paragraph:
Sentence 1 is a little confusing. I assume the intent is to say that this draft allocates the reserved flags, and the flags are used to advertise the data labels? As it is, it sounds like the act of allocation advertises the data labels.
In sentence two, should "this flag" be "these flags"?

-- 4.1, paragraph 3: "...it MUST be advertised..."
I assume this means that the originating RBridge MUST advertise it? (Please consider active voice for 2119 requirements. )

-- 5:
Consider “This section explores how this specification meets the major design goals of AAE”

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Proposed Standard as stated on the title page. This document
  specifies the protocol for TRILL switches to implement active-
  active services at the TRILL edge with edge group RBridges using
  their own nickname as ingress.

(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:

  TRILL active-active service provides end stations with flow level
  load balance and resilience against link failures at the edge of
  TRILL campuses as described in RFC 7379.

  This draft specifies a method by which member RBridges in an
  active-active edge RBridge group use their own nicknames as the
  ingress RBridge nickname to encapsulate frames from attached end
  systems.  Thus, remote edge RBridges are required to keep multiple
  point of attachment for one MAC address within a Data Label.

Working Group Summary:

  Although early discussion in the TRILL WG favored a pseudo-node
  nickname approach similar to that in draft-ietf-trill-pseudonode-
  nickname, later analysis resulting in the alternatives described in
  the Introduction of this document. Two alternatives, which can be
  deployed simultaneously in a TRILL campus, are being advanced by
  the WG, the other using a pseudo-nickname in draft-ietf-trill-
  pseudonode-nickname.

  There was good WG support for this draft in WG LC (2/11-2/25)
 
Document Quality:

  This document is of high quality.

Personnel:

  Document Shepherd: Donald E. Eastlake, 3rd
  Responsible Area Director: Alia Atlas
  WG chairs: Susan Hares, Jon Hudson


(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/msg06626.html

  (The draft has been also updated based on AD review which is here:
  http://www.ietf.org/mail-archive/web/trill/current/msg06882.html )
 
  (The RTG-Directorate Reviewer: Michael Richardson- review is below:
  https://mailarchive.ietf.org/arch/msg/trill/9QMAY54iiheEzFOKPLdv59QdA7M
  )
 

(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.

  No IPR disclosures.

(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?

  There is strong consensus for this draft among the interested
  members of the WG. It represents an approach developed by a design
  team coordinated by Radia Perlman.

(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. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  No nits although the nits checker warns about a possible bad
  example IPv4 address: "4.6.1.2". This is actually a Section number
  from RFC 6325.

(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?

  There is a normative reference to draft-ietf-trill-rfc7180bis for
  which RFC publication has been requested.

(15) Are there downward normative references (see RFC 3967)? If so,
list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction?

  This document does not change the status of any existing RFC.
 
(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 text. It
  requests appropriate assignments from existing registries and
  creates one new registry for Extended RBridge Capability bits. The
  initial contents is well specified along with allocation procedure
  and name. This new registry is Expert Review and experts with a
  strong background in TRILL should be appointed.

(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.

  This document creates an "Extended RBridge Capabilities Registry"
  with assignment by Expert Review. Strong TRILL technical experts
  should be selected for the IANA Experts.

(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 reviews required.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Proposed Standard as stated on the title page. This document
  specifies the protocol for TRILL switches to implement active-
  active services at the TRILL edge with edge group RBridges using
  their own nickname as ingress.

(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:

  TRILL active-active service provides end stations with flow level
  load balance and resilience against link failures at the edge of
  TRILL campuses as described in RFC 7379.

  This draft specifies a method by which member RBridges in an
  active-active edge RBridge group use their own nicknames as the
  ingress RBridge nickname to encapsulate frames from attached end
  systems.  Thus, remote edge RBridges are required to keep multiple
  point of attachment for one MAC address within a Data Label.

Working Group Summary:

  Although early discussion in the TRILL WG favored a pseudo-node
  nickname approach similar to that in draft-ietf-trill-pseudonode-
  nickname, later analysis resulting in the alternatives described in
  the Introduction of this document. Two alternatives, which can be
  deployed simultaneously in a TRILL campus, are being advanced by
  the WG, the other using a pseudo-nickname in draft-ietf-trill-
  pseudonode-nickname.

  There was good WG support for this draft in WG LC (2/11-2/25)
 
Document Quality:

  This document is of high quality.

Personnel:

  Document Shepherd: Donald E. Eastlake, 3rd
  Responsible Area Director: Alia Atlas
  WG chairs: Susan Hares, Jon Hudson


(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/msg06626.html

  (The draft has been also updated based on AD review which is here:
  http://www.ietf.org/mail-archive/web/trill/current/msg06882.html )
 
  (The RTG-Directorate Reviewer: Michael Richardson- review is below:
  https://mailarchive.ietf.org/arch/msg/trill/9QMAY54iiheEzFOKPLdv59QdA7M)
 

(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.

  No IPR disclosures.

(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?

  There is strong consensus for this draft among the interested
  members of the WG. It represents an approach developed by a design
  team coordinated by Radia Perlman.

(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. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  No nits although the nits checker warns about a possible bad
  example IPv4 address: "4.6.1.2". This is actually a Section number
  from RFC 6325.

(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?

  There is a normative reference to draft-ietf-trill-rfc7180bis for
  which RFC publication has been requested.

(15) Are there downward normative references (see RFC 3967)? If so,
list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction?

  This document does not change the status of any existing RFC.
 
(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 text. It
  requests appropriate assignments from existing registries and
  creates one new registry for Extended RBridge Capability bits. The
  initial contents is well specified along with allocation procedure
  and name. This new registry is Expert Review and experts with a
  strong background in TRILL should be appointed.

(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.

  This document creates an "Extended RBridge Capabilities Registry"
  with assignment by Expert Review. Strong TRILL technical experts
  should be selected for the IANA Experts.

(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 reviews required.

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

IANA has reviewed draft-ietf-trill-aa-multi-attach-03.  Please see the reviewer's summary of the IANA actions below and let us know if our understanding is inaccurate.

IANA understands that, upon approval of this document, there are four actions which must be completed.

First, 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:

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

the following three APPsub-TLV types will be added as follows:

Type: [ TBD; requested value 252]
Name: AA-LAALP-GROUP-MAC
Reference: [ RFC-to-be ]

Type: [ TBD; requested value 253]
Name: EXTENDED-RBRIDGE-CAP
Reference: [ RFC-to-be ]

Type: [ TBD; requested value 254]
Name: AA-LAALP-GROUP-RBRIDGES
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the Extended RBridge Capabilities registry. The new registry will be located in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

The registration procedure for this new registry is Expert Review as defined in RFC 5226. There are initial registrations in the new registry as follows:

Bit Mnemonic Description Reference
---- -------- ----------- -------------
0 E Option C Support [ RFC-to-be ]
1 H Option A Support [ RFC-to-be ]
2-63 - Unassigned

Third, in the Interested VLANs Flag Bits subregistry of the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

one new bit is to be registered as follows:

Bit: 16 (requested)
Mnemonic: AA
Description: Enabled VLANs for Active-Active
Reference: [ RFC-to-be ]

Fourth, in the Interested Labels Flag Bits in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

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

one new bit is to be registered as follows:

Bit: 4 (requested)
Mnemonic: AA
Description: FGLs for Active-Active
Reference: [ RFC-to-be ]

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. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Proposted Standard as stated on the title page. This document
  specifies the protocol for TRILL switches to implement active-
  active services at the TRILL edge with edge group RBridges using
  their own nickname as ingress.

(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:

  TRILL active-active service provides end stations with flow level
  load balance and resilience against link failures at the edge of
  TRILL campuses as described in RFC 7379.

  This draft specifies a method by which member RBridges in an
  active-active edge RBridge group use their own nicknames as the
  ingress RBridge nickname to encapsulate frames from attached end
  systems.  Thus, remote edge RBridges are required to keep multiple
  point of attachment for one MAC address within a Data Label.

Working Group Summary:

  Although early discussion in the TRILL WG favored a pseudo-node
  nickname approach similar to that in draft-ietf-trill-pseudonode-
  nickname, later analysis resulting in the alternatives described in
  the Introduction of this document. Two alterntives, which can be
  deployed simultaneously in a TRILL campus, are being advanced by
  the WG, the other using a pseudo-nickname in draft-ietf-trill-
  pseudonode-nickname.

  There was good WG support for this draft.
 
Document Quality:

  This document is of high quality.

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/msg06626.html

  (The draft has been also updated based on AD review which is here:
  http://www.ietf.org/mail-archive/web/trill/current/msg06882.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.

  No IPR disclosures.

(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?

  There is strong consensus for this draft amoung the interested
  members of the WG. It represents an approach developed by a design
  team coordinated by Radia Perlman.

(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. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  No nits although the nits checker warns about a possible bad
  example IPv4 address: "4.6.1.2". This is actually a Section number
  from RFC 6325.

(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?

  There is a normative reference to draft-ietf-trill-rfc7180bis for
  which RFC publication has been requested.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  There are no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction?

  This document does not change the status of any exising RFC.
 
(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 text. It
  requests appropriate assignments from exising registries and
  creates onw new registry for Extended RBridge Capability bits. The
  initial contents is well specified along with allocation procedure
  and name. This new registry is Expert Review and experts with a
  strong background in TRILL should be appointed.

(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.

  Thid document creates an "Extended RBridge Capapbilities Registry"
  with assignment by Expert Review. Strong TRILL technical experts
  should be selected for the IANA Experts.

(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 reviews required.

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 Active-Active Edge Using Multiple MAC Attachments) 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 Active-Active Edge Using Multiple MAC Attachments'
  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-08-14. 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


  TRILL active-active service provides end stations with flow level
  load balance and resilience against link failures at the edge of
  TRILL campuses as described in RFC 7379.

  This draft specifies a method by which member RBridges in an active-
  active edge RBridge group use their own nicknames as ingress RBridge
  nicknames to encapsulate frames from attached end systems. Thus,
  remote edge RBridges are required to keep multiple locations of one
  MAC address in one Data Label. Design goals of this specification are
  discussed in the document.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trill-aa-multi-attach/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trill-aa-multi-attach/ballot/


No IPR declarations have been submitted directly on this I-D.

Minor quibble from AD review:

1) In Sec 4.1, it says ""The advertisement of enabled Data
Labels for an LAALP can be realized by..."  This is a proposed standard draft.  Be declarative in the language, such as ""The advertisement of enabled Data
Labels for an LAALP is realized, as defined in this document, by..."

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Proposted Standard as stated on the title page. This document
  specifies the protocol for TRILL switches to implement active-
  active services at the TRILL edge with edge group RBridges using
  their own nickname as ingress.

(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:

  TRILL active-active service provides end stations with flow level
  load balance and resilience against link failures at the edge of
  TRILL campuses as described in RFC 7379.

  This draft specifies a method by which member RBridges in an
  active-active edge RBridge group use their own nicknames as ingress
  RBridge nicknames to encapsulate frames from attached end systems.
  Thus, remote edge RBridges are required to keep multiple point of
  attachment for one MAC address within a Data Label.

Working Group Summary:

  Although early discussion in the TRILL WG favored a pseudo-node
  nickname approach similar to that in draft-ietf-trill-pseudonode-
  nickname, later analysis resulting in the three alternatives
  described in the Introduction of this document. Two of these, which
  can be deployed simultaneously in a TRILL campus, are being
  advanced by the WG, alternative 3 in this draft and an evolved
  version of alternative 1 using a pseudo-nickname in draft-ietf-
  trill-pseudonode-nickname.

  There was good WG support for this draft.
 
Document Quality:

  This document is of high quality.

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/msg06626.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.

  No IPR disclosures.

(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?

  There is strong consensus for this draft amoung the interested
  members of the WG. It represents an approach developed by a design
  team coordinated by Radia Perlman.

(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. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  No nits although the nits checker warns about a few References that
  are not references. However, The reference for [RFC7180bis] should
  say "draft-ietf-trill-rfc7180bis" rather than
  "draft-eastlake-trill-rfc7180bis". Also [RFC7379] is listed as a
  Noramtive Reference but it is an Informational Reference. These did
  not seem worth a new version and can be fixed the next time any
  changes are rolled in.

(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?

  There is a normative reference to draft-ietf-trill-rfc7180bis which
  has passed TRILL WG Last Call.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  There are no downard normative references. RFC 7379 which appears
  in the Normative References section is an Informative reference.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction?

  This document does not change the status of any exising RFC.
 
(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 text. It
  requests appropriate assignments from exising registries and
  creates onw new registry for Extended RBridge Capability bits. The
  initial contents is well specified along with allocation procedure
  and name. This new registry is Expert Review and experts with a
  strong background in TRILL should be appointed.

(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.

  Thid document creates an "Extended RBridge Capapbilities Registry"
  with assignment by Expert Review. Strong TRILL technical experts
  should be selected for the IANA Experts.

(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 reviews required.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Proposted Standard as stated on the title page. This document
  specifies the protocol for TRILL switches to implement active-
  active services at the TRILL edge with edge group RBridges using
  their own nickname as ingress.

(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:

  TRILL active-active service provides end stations with flow level
  load balance and resilience against link failures at the edge of
  TRILL campuses as described in RFC 7379.

  This draft specifies a method by which member RBridges in an
  active-active edge RBridge group use their own nicknames as ingress
  RBridge nicknames to encapsulate frames from attached end systems.
  Thus, remote edge RBridges are required to keep multiple point of
  attachment for one MAC address within a Data Label.

Working Group Summary:

  Although early discussion in the TRILL WG favored a pseudo-node
  nickname approach similar to that in draft-ietf-trill-pseudonode-
  nickname, later analysis resulting in the three alternatives
  described in the Introduction of this document. Two of these, which
  can be deployed simultaneously in a TRILL campus, are being
  advanced by the WG, alternative 3 in this draft and an evolved
  version of alternative 1 using a pseudo-nickname in draft-ietf-
  trill-pseudonode-nickname.

  There was good WG support for this draft.
 
Document Quality:

  This document is of high quality.

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/msg06626.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.

  No IPR disclosures.

(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?

  There is strong consensus for this draft amoung the interested
  members of the WG. It represents an approach developed by a design
  team coordinated by Radia Perlman.

(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. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  No nits although the nits checker warns about a few References that
  are not references. However, The reference for [RFC7180bis] should
  say "draft-ietf-trill-rfc7180bis" rather than
  "draft-eastlake-trill-rfc7180bis". Also [RFC7379] is listed as a
  Noramtive Reference but it is an Informational Reference. These did
  not seem worth a new version and can be fixed the next time any
  changes are rolled in.

(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?

  There is a normative reference to draft-ietf-trill-rfc7180bis which
  has passed TRILL WG Last Call.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  There are no downard normative references. RFC 7379 which appears
  in the Normative References section is an Informative reference.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction?

  This document does not change the status of any exising RFC.
 
(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 text. It
  requests appropriate assignments from exising registries and
  creates onw new registry for Extended RBridge Capability bits. The
  initial contents is well specified along with allocation procedure
  and name. This new registry is Expert Review and experts with a
  strong background in TRILL should be appointed.

(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.

  Thid document creates an "Extended RBridge Capapbilities Registry"
  with assignment by Expert Review. Strong TRILL technical experts
  should be selected for the IANA Experts.

(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 reviews required.