Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic
draft-ietf-trill-centralized-replication-13

[Ballot comment]
TRILL is pretty far outside my area of expertise, so I might be simply misunderstanding the protocol extension model here, but it seems to me that the changes to the RPF port calculation represent a formal update to RFC6325. If so, the metadata and abstract should indicate that.

[Ballot comment]

  if a triple of {ingress nickname, tree, receiving RBridge port} is
  allowed. (The tree is indicted by the nickname of its root which is
  stored in the TRILL Header "egress nickname" field.) When
I think this probably should be "indicated"



7. Centralized replication forwarding process
This diagram would be helpful earlier



                    *  ----------*-------------*--    ^
                    ***************************** |    ^
              LAALP1 *                      LAALP2 |      ^
What are the asterisks?



  equals (m mod k) as egress nickname for BUM traffic unicast TRILL
  encapsulation.
This text might be easier to read as:

"For data label ID m, choose R-nickname = m mod k"

The "equals" isn't that helpful here, but if you wanted to say it that way, you might try
"choose the R-nickname n which is equal to m (mod k)"



            o C = If C flag is one, it indicates that the TRILL traffic
  with this nickname as an ingress nickname that requires the special
Nit: I would use ":" here instead of equals

[Ballot comment]
I have some non-blocking comments.  I would like to see the ones related to Normative Language addressed before publication.

- From the Abstract: "RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge..."  Using Normative Language in the Abstract seems strange to me, specially since the same language is not used later in the text.  The document does get to the same point later, but not with the same language.

- The Introduction says that "...a centralized node, which SHOULD be a distribution tree root", but Section 3 says otherwise: "The centralized node MUST be a distribution tree root."  Suggestion: use Normative Language in just one place.  IMO, the Introduction may not be the right place for it. 

- BTW, what is a "distribution tree root"?  The definition is probably intuitive since we're talking about replication, but explicitly defining it would clear any possible confusion.

- I appreciate the background and the description of the problem and the mechanism, but there's a lot of repetition.  Section 3 presents for the third time an overview of the mechanism -- Abstract, Introduction, and Section 3...note that even the last paragraph repeats information about the replication from this same section.

- Section 9: "An edge group using CMT [RFC7783] MUST NOT set the C-nickname flag on the pseudo-nickname it is using. This is already mandatory behavior..." If "already mandatory" then there's no need to use Normative Language here, right?

- Section 11.1 ("R" and "C" Flag in the Nickname Flags APPsub-TLV):  I'm not sure if I understand correctly, but because there's a distinction between the R-nickname and the C-nickname, both bits should not be set at the same time, right?  What happens if they are?  It seems that the last paragraph tries to address that question ("due to errors")...but I'm then not sure what the action is: "it is RECOMMENDED that the nickname be treated as if the R / C flag was set if any Nickname Flags APPsub-TLV for that nickname has the R / C flag set." Again, what if both are set?  And "RECOMMENDED" implies that there are reasons not to do it this way...what are those cases?

[Ballot comment]
I have some non-blocking comments.  I would like to see the ones related to Normative Language addressed before publication.

- From the Abstract: "RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge..."  Using Normative Language in the Abstract seems strange to me, specially since the same language is not used later in the text.  The document does get to the same point later, but not with the same language.

- The Introduction says that "...a centralized node, which SHOULD be a distribution tree root", but Section 3 says otherwise: "The centralized node MUST be a distribution tree root."  Suggestion: use Normative Language in just one place.  IMO, the Introduction may not be the right place for it. 

- BTW, what is a "distribution tree root"?  The definition is probably intuitive since we're talking about replication, but explicitly defining it would clear any possible confusion.

- I appreciate the background and the description of the problem and the mechanism, but there's a lot of repetition.  Section 3 presents for the third time an overview of the mechanism -- Abstract, Introduction, and Section 3...note that even the last paragraph repeats information about the replication from this same section.

- Section 9: "An edge group using CMT [RFC7783] MUST NOT set the C-nickname flag on the pseudo-nickname it is using. This is already mandatory behavior..."  If "already mandatory" then there's no need to use Normative Language here, right?

- Section 11.1 ("R" and "C" Flag in the Nickname Flags APPsub-TLV):  I'm not sure if I understand correctly, but because there's a distinction between the R-nickname and the C-nickname, both bits should not be set at the same time, right?  What happens if they are?  It seems that the last paragraph tries to address that question ("due to errors")...but I'm then not sure what the action is: "it is RECOMMENDED that the nickname be treated as if the R / C flag was set if any Nickname Flags APPsub-TLV for that nickname has the R / C flag set."  Again, what if both are set?  And "RECOMMENDED" implies that there are reasons not to do it this way...what are those cases?

[Ballot comment]
No TSV concerns from me, but I was interested in the MUST/SHOULD mismatch that Joseph Salowey mentioned in his review of -10. I didn't see a change about that in -11.

I'm assuming the right thing will happen after the holidays, so no Discuss :-) ...

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

The IANA Services Operator has completed its review of draft-ietf-trill-centralized-replication-10. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the NickFlags Bits sub-registry of the TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1 registry on the Transparent Interconnection of Lots of Links (TRILL) Parameters registry page located at

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

two new bits are to be assigned:

Bit Mnemonic Description Reference
--- -------- -------------------- -------------
3 R Replication Nickname [ RFC-to-be ]
4 C Special RFC Check [ RFC-to-be ]

IANA Question --> Bit 2 seems to be unassigned in this sub-registry. Is bit 2 to remain unassigned when this draft is approved, or do the authors intend to assign the next available bits in the registry?

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 the list of actions that will be performed.

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

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-12-12):

From: The IESG
To: IETF-Announce
CC: d3e3e3@gmail.com, trill-chairs@ietf.org, trill@ietf.org, draft-ietf-trill-centralized-replication@ietf.org, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Centralized Replication for Active-Active BUM Traffic) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of Lots
of Links WG (trill) to consider the following document: - 'Centralized
Replication for Active-Active BUM Traffic'
  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 2017-12-12. 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


  In TRILL active-active access, an RPF check failure issue may occur
  when using the pseudo-nickname mechanism specified in RFC 7781. This
  draft describes a solution to resolve this RPF check failure issue
  through centralized replication. All ingress RBridges send BUM
  (Broadcast, Unknown unicast and Mutlicast) traffic to a centralized
  node with unicast TRILL encapsulation. When the centralized node
  receives the BUM traffic, it decapsulates the packets and forwards
  them to their destination RBridges using a distribution tree
  established as per TRILL base protocol RFC 6325. To avoid RPF check
  failure on a RBridge sitting between the ingress RBridge and the
  centralized replication node, some change in the RPF calculation
  algorithm is required. RPF checks on each RBridge should be
  calculated as if the centralized node was the ingress RBridge,
  instead of being calculated using the actual ingress RBridge.






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

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


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

draft-ietf-trill-centralized-replication

=============

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

  Standards track as indicated on the title page. This is appropriate
  because it standardized a method of handling multi-destination
  traffic from active-active end stations.

(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

  This draft uses centralized replication as a solution to reverse
  path forwarding check failure when multi-destination traffic is
  ingressed from an active-active endstation using a pseudo-nickname
  as the ingress nickname.

Working Group Summary

  Nothing particularly noteworthy in the WG process.

Document Quality

  The document is of good quality. Huawei plans to implement this
  feature.

Personnel

  Document Shepherd: Donald Eastlake
  Responsible Area Director: Alia Atlas

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

  Shephard's review is here:
  https://www.ietf.org/mail-archive/web/trill/current/msg07374.html
  These comments have been resolved.

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

  No. In addition to Shepherd and directorate reviews, a thorough AD
  review was done as documented here
  https://www.ietf.org/mail-archive/web/trill/current/msg07799.html
  and the draft has been modified accordingly.

(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? If so, describe the review that
took place.

  This document has had a Routing Directorate review. See
  https://www.ietf.org/mail-archive/web/trill/current/msg07379.html

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

  Author's assurances:
 
  Yizhou Li
https://www.ietf.org/mail-archive/web/trill/current/msg07493.html

  Weiquo Hao
https://www.ietf.org/mail-archive/web/trill/current/msg07495.html

  Muhammad Durrani
https://www.ietf.org/mail-archive/web/trill/current/msg07496.html

  Sujay Gupta
https://www.ietf.org/mail-archive/web/trill/current/msg07528.html

  Andrew Qu
https://www.ietf.org/mail-archive/web/trill/current/msg07534.html


(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 filed with IETF.

(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 a good consensus for this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  No nits.

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

  No such formal review required. It has undergone routing directorate
  review.

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

  No.

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

  No.

(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? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  Tbis draft does not change the status of any other 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 section is correct and complete. The two
  actions required are the assignment of two bit in a currently
  existing registry.

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

As is customary, I have done my AD review of draft-ietf-trill-centralized-replication-08. First, I would like to thank the authors - Weiguo Hao, Yizhou Li, Muhammad Durrani, Sujay Gupta, and Andrew Qu - for their work on this document.

I do have a few concerns that need to be addressed before the document can proceed to IETF Last Call.  If the authors can address them very rapidly (this week), then I have time for an IETF Last Call and putting the draft on the IESG Telechat of July 6.


1) In Sec 3, it says"In this case, the RPF calculation on each RBridge should use the centralized node as the ingress RBridge instead of the real ingress virtual RBridge to perform the calculation."
In Sec 7, it says"The egress nickname in the multi-destination TRILL Header is the nick5 and the ingress nickname is still P-nick."

From scanning RFC6325, I am reminded that the egress nickname indicates the destination tree.  I don't see clearly specified here how the RBridge determines which RPF calculation to use for a particular frame.... 

In Sec 11,"A C-nickname is a specialized pseudo-nickname for which transit RBridges perform a different RPF check algorithm for TRILL data packets with the C-nickname in the ingress nickname field."

If I follow the logic here, an RBridge is intended to install a different RPF interface-set for each C-nickname - but what that RPF interface-set is will also be dependent upon the egress nickname specified??    Does this turn the look-up from a simple ingress nickname (16 bit) to interface-set into a something more complicated? 
I guess it could be a recursive lookup, where if the ingress nickname is a C-nickname, then the RPF interface-set is looked up again from the egress name instead?

If I am correct, then this is a definite change in fast-path forwarding behavior and should be described extremely clearly - which it is not.

I don't think that Sec 8 helps in guessing which distribution tree will be used.

2) In Sec 10:"In this case, an edge group using CMT [RFC7783] MUST NOT set the C-
  nickname flag on the pseudo-nickname it is using."
Given that an implementation support RFC7783 may not support this document, please
clarify in the document how it is that an implementation conformant to RFC7783 is guaranteed to not set the C-nickname flag.

3) Sec 11:" When active-active edge RBridges use centralized replication to
  nickname and the C-nickname is used as ingress nickname in the TRILL
  header for the unicast TRILL encapsulation of BUM traffic."

I have no idea what this sentence fragment means.

4) Sec 12: There is a claim of no new security concerns, but this basically gives a device the ability to advertise an R-nickname and get all/some of the BUM traffic unicast to it - where that device could modify, block, or respond to the BUM traffic and the rest of the campus - except for the local neighbors of ingress RBridge would have no idea this was happening!  I think that some discussion of exactly what security mechanisms for IS-IS ensure that a device injecting an R-nickname is trusted would be helpful as well as articulating the potential impact.

draft-ietf-trill-centralized-replication

=============

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

  Standards track as indicated on the title page. This is appropriate
  because it standardized a method of handling multi-destination
  traffic from active-active end stations.

(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

  This draft uses centralized replication as a solution to reverse
  path forwarding check failure when multi-destination traffic is
  ingressed from an active-active endstation using a pseudo-nickname
  as the ingress nickname.

Working Group Summary

  Nothing particularly noteworthy in the WG process.

Document Quality

  The document is of good quality.

Personnel

  Document Shepherd: Donald Eastlake
  Responsible Area Director: Alia Atlas

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

  Shephard's review is here:
  https://www.ietf.org/mail-archive/web/trill/current/msg07374.html
  These comments have been resolved.

(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? If so, describe the review that
took place.

  This document has had a Routing Directorate review. See
  https://www.ietf.org/mail-archive/web/trill/current/msg07379.html

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

  Author's assurances:
 
  Yizhou Li
https://www.ietf.org/mail-archive/web/trill/current/msg07493.html

  Weiquo Hao
https://www.ietf.org/mail-archive/web/trill/current/msg07495.html

  Muhammad Durrani
https://www.ietf.org/mail-archive/web/trill/current/msg07496.html

  Sujay Gupta
https://www.ietf.org/mail-archive/web/trill/current/msg07528.html

  Andrew Qu
https://www.ietf.org/mail-archive/web/trill/current/msg07534.html


(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 filed with IETF.

(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 a good consensus for this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  There is one nit, a line in the abstract that is one character too
  long, that does not seem worth revising the document to fix. I'm
  sure there will be other reasons to revise the document and it can
  be fixed then.

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

  No such formal review required. It has undergone routing directorate
  review.

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

  No.

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

  No.

(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? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  Tbis draft does not change the status of any other 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 section is correct and complete. The two
  actions required are the assignment of two bit in a currently
  existing registry.

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

Request for posting confirmation emailed to previous authors: "Andrew Qu" , "Li Yizhou" , "Sujay Gupta" , "Muhammad Durrani" , "Tao Han" , trill-chairs@ietf.org, "Hao Weiguo"