Bit Index Explicit Replication (BIER) Support via IS-IS
draft-ietf-bier-isis-extensions-11

[Ballot comment]
Thanks for addressing my DISCUSS point.

* Section 4.2.

"When the Prefix Attributes Flags sub-TLV is present N flag MUST be set."

Given that RFC7794, which defines this sub-TLV, clearly mentions that setting this flag is purely optional, is there a reason this is made mandatory? I do not see any checking for this flag in the behavior.

[Ballot comment]
(1) Section 4.2: "Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6 prefix"  What should the receiver do of the length doesn't indicate a host route?

(2) Section 4.2: "When the Prefix Attributes Flags sub-TLV is present N flag MUST be set.  [RFC7794]"  This change from rfc7794 seems like it could impact other uses of the flag (based on the expected behavior in rfc7794).  What should a receiver do if the flag is not set (which would be compliant with rfc7794)?

(3) "Advertisements associated with <0,0> and <2,0> MUST be ignored."  This text is part of the example, so the "MUST" is just stating a fact. s/MUST/must

(4) From 5.4:

  A router that desires to participate in  MUST advertise for
  each bitstring length it supports in  a Maximum Set ID that
  guarantees to cover the maximum BFR-id injected into  (which
  implies a certain maximum set id per bitstring length as described in
  [RFC8279]).  Any router that violates this condition MUST be excluded
  from BIER BFTs for .

What is "this condition" (in the last sentence)?  From the rest of the paragraph, it seems like the condition is the "[guarantee] to cover the maximum BFR-id injected into ".  If so, how can the receiver verify that condition/guarantee?  Maybe the reference is just to the combination of BSL, MT, SD, Max SI, advertised.  Please clarify.

(5) Section 5.5: "Each BFER/BFIR MAY advertise with its TLV the BFR-id that it has administratively chosen."  If the BFER/BFIR doesn't include the BFD-id, is there any value in advertising the new sub-TLV? 

BTW, I think the text was meant to indicate that the BFR can chose to not advertise the "BFR-id that it has administratively chosen" (as in not advertise anything), but another interpretation of the text could be that it may advertise a BFR-id it didn't chose (as in any other id, including someone else's).

(6) Section 5.7: "BIER domain information SHOULD change infrequently."  From a Normative point of view, what does this mean?  What if the changes are frequent?  I think that the sentence is just a statement of fact -- s/SHOULD/should  If the BFR should do something to limit the frequency of changes, please say so.

(7) Section 6.1: "If no BFR-id has been assigned this field is set to the invalid BFR-id."  I looked in rfc8279 for the text about "invalid BFR-id", but found this instead: "The value 0 is not a legal BFR-id."  I assume that in this case "invalid" is the same as "not legal".  It would be nice to be consistent.

(8) Section 6.2: "On violation of any of the following conditions, the receiving router MUST ignore the encapsulating BIER Info sub-TLV."  If a violation is detected, the result is that *all* BIER Info sub-TLVs (from *all* BFRs contributing to the violation) are ignored, right?  The text is not clear as to whether the result applies to all or just the BFR that advertised last (and resulted in the violation being detected).

(9) Section 6.2: "All labels in the range MUST represent valid label values"  What is a "valid label value"?

(10) Security Considerations: I support Eric's DISCUSS.  It seems to me that an attacker could simply advertise duplicate BFR-IDs or overlapping label ranges and have a significant impact on the network.

(11) Section 8: "The RFC is aligned with the [I-D.draft-ietf-bier-ospf-bier-extensions-10] draft as far as the protocol mechanisms overlap."  Good!

(11.1) The ospf draft mentions that the extensions are only applicable to MPLS networks.  This draft also only defines an MPLS encapsulation sub-sub-TLV.  Section 5.2 seems to however open the door to multiple encapsulations ("Multiple encapsulations MAY be advertised/supported...")...but without the support (?) for anything else.  Please be clear about it since it may not be clear to a casual reader.

(11.2) The BIER Info sub-TLV doesn't include an explicit indication of the MT as does the OSPF version -- which is fine.  Assuming that the information is included somewhere else so that the  combination can be evaluated, please include details of how the MT information is obtained.

(11.3) The latest version of draft-ietf-bier-ospf-bier-extensions points to this document as defining a "BIER Algorithm Registry"...but I don't see that yet.  I'm eagerly awaiting the nest version!

[Ballot discuss]
I think we have a process problem here.

This document (Standards Track) makes normative references to RFC 8279 (Experimental) and RFC 8296 (Experimental), neither of which appear in the downref registry. My understanding of the rules defined in RFC 3967 is that these downreferences need to be explicitly called out in the IETF last call announcement so that the community can discuss whether such downreferences are acceptable. Unless the last call text in the datatracker doesn't match the text sent to the IETF discussion list, this document needs to run through IETF LC again with these downrefs explicitly called out before it can move forward.

This also raises the question of whether *this* document should be Experimental rather than Standards Track, as it appears to be defining an extension that is used exclusively for enabling experimental specifications. This would fix the downref problem, but I'm not sure whether it requires another Last Call.

[Ballot discuss]
I think we have a process problem here.

This document (Standards Track) makes normative references to RFC 8279 (Experimental) and RFC 8296 (Experimental), neither of which appear in the downref registry. My understanding of the rules defined in RFC 3967 is that these downreferences need to be explicitly called out in the IETF last call announcement so that the community can discuss whether such downreferences are acceptable. Unless the last call text in the datatracker doesn't match the text sent to the IETF discussion list, this document needs to run through IETF LC again before it can move forward.

This also raises the question of whether *this* document should be Experimental rather than Standards Track, as it appears to be defining an extension that is used exclusively for enabling experimental specifications.

[Ballot comment]
I support EKR's discuss position.

§6.1:

>  BAR  BIER Algorithm. 0 is the only supported value defined in this
>      document.  Other values may be defined in the future. 8 bits

I expected to find a registry for this in the IANA section. Does some other document establish this registry? If so, is 0 already registered? If "no" and "no", then this document needs to do both. If "yes" and "no", then this document need to register "0". If "yes" and "yes", then the phrase "in this document" needs to be replaced by "in [RFCxxxx]".

>  subdomain-id:  Unique value identifying the BIER sub-domain. 1 octet

You need to scope "Unique" (e.g. "Value identifying the BIER sub-domain, unique within the domain.")

>  Local BitString Length (BS Len):  Encoded bitstring length as per
>      [RFC8296]. 4 bits.
>
>  Max SI  Maximum Set Identifier (section 1 of [RFC8279]) used in the
>      encapsulation for this BIER sub-domain for this bitstring length,
>      1 octet.  Each SI maps to a single label in the label range.  The
>      first label is for SI=0, the second label is for SI=1, etc.

This is a bit confusing, since the fields appear in the opposite order from this in the diagram. Would recommend re-ordering to match.

[Ballot comment]
Substantive Comments:

I support Ekr's DISCUSS comment.

Abstract: It would be nice to see a bit more context in the abstract. Also, the entire abstract is a sentence fragment. (IMO the last paragraph in §1 would make a good abstract.)

§5.2: The "MUST" seems like a statement of fact.

Editorial Comments and Nits:

§3: The draft uses an odd organization. IANA considerations (along with security considerations) should be near the end of the draft body.

[Ballot discuss]
* Section 6.2.  BIER MPLS Encapsulation sub-sub-TLV

This should be straightforward to fix but it is not clear if the label range is allowed to wrap around (overflow) or not past the 20 bit space. e.g. is a Label=2^20-X with a MSI of X or larger legal? I was hoping that RFC8296 would have covered this but unfortunately it leaves it to this document (and the OSPF document) to specify.

[Ballot comment]
I support EKRs discuss and think it's just s reference that needs to be added as this is an extension.

I also had a question on 5.6, what does dampen the logging mean?  Is this something that is programmed and can't be changed or configurable in case debugging is not adequate?

[Ballot discuss]
Document: draft-ietf-bier-isis-extensions-00.txt

  Implementations must assure that malformed TLV and Sub-TLV
  permutations do not result in errors which cause hard protocol
  failures.

This is not an adequate security considerations section. What is your
threat model? What attacks are possible? What are not? It may be
the case that this is all covered in other documents, and you
just need to point to them, but the reader doesn't know that,
so this needs to be documented.

Off the top of my head, what happens if I send a BIER Info sub-TLV
with someone else's BFR-Id and a bogus BIER MPLS encapsulation
sub-sub-TLV?

[Ballot comment]
Coming from Joe Clarke in his OPS-DIR review:
The only substantive comment I have is in section 5.6 regarding reporting
misconfigurations.  What is not stated is _how_ this is to be done.  There is
no reference to a standard BIER or IS-IS mechanism with how this reporting
should be carried out.  For operational consistency, I feel some guidance
should be offered.

The one nit I noticed is in section 6.2:

OLD:

Label ranges in multiple sub-sub-TLV MUST NOT overlap.

NEW:

Label ranges in multiple sub-sub-TLVs MUST NOT overlap.

[Ballot comment]
* Section 4.2.

"When the Prefix Attributes Flags sub-TLV is present N flag MUST be set."

Given that RFC7794, which defines this sub-TLV, clearly mentions that setting this flag is purely optional, is there a reason this is made mandatory? I do not see any checking for this flag in the behavior.

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

The IANA Services Operator has completed its review of draft-ietf-bier-isis-extensions-06. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

the existing temporary registration for:

Type: 32
Description: BIER Info
135: Y
235: Y
236: Y
237: Y

will be made permanent and its reference changed to [ RFC-to-be ].

Second, a new registry is to be created called the Sub-sub-TLVs for the BIER Info sub-TLV [32]. The new registry will be a subregistry of the Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The new registry will be managed via Expert Review as defined in RFC 8126.

There is a single, new registration in the new registry as follows:

Type Name Reference
----+------------------------+-------------
1 BIER MPLS Encapsulation [ RFC-to-be ]

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.


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.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

[Ballot comment]
The document is StdTrack, but contains 2 normative references to experimental RFCs - was this called out?

Nit Section 2:
" BAR  BIER Algorithm.  Algorithm used to calculate nexthops." -- the other definitions have a colon (:) after the term.

Section 4.1:
" Additionally, per supported bitstring length in the sub-domain, each router will advertise the necessary label ranges to support it."
I found this sentence really difficult to parse - can it be reworded? I'm actually not sure what it is trying to say, the "per supported bitstring length" threw me. "Additionally, each router will advertise the label ranges to support the bitstring length in the sub-domain"? Sorry, really don't get it.

Section 4.2:
"  o  When the Prefix Attributes Flags sub-TLV is present N flag MUST" - I think that this is missing "the"; sub-TLV is present the N flag..."

Section 5.1.  Multi Topology and Sub-Domain
"A router receiving an  advertisement which does not match the locally configured pair MUST report a misconfiguration of the received  pair."
When I first read this I thought "Yikes, for every non-matching advertisement it must report? Won't that DOS the logging?", and so I made a note. Then, further on I found Section 5.6, which talks about this sort of thing. Please insert a "See Section 5.6" (or similar) to prevent others from panic :-)

Section 5.7.  Flooding Reduction
  "BIER domain information SHOULD change infrequently."
What does "infrequently" mean here? Brushing my teeth frequently has very different meaning to washing my car frequently - is this "around one a minute" or "on the order of many months"?

Section 7:
"Implementations must assure that malformed TLV and Sub-TLV permutations do not result in errors which cause hard protocol failures." - I'm not a security AD, but this feels inadequate. Is "malformed TLV and Sub-TLV " the only *only* security issues? And, does this really *mean* anything (I could equally write "Don't write bad code. K?")

[Ballot comment]
1) Minor comment: The shepherd write-up says wrongly that this docoment is experimental. Assume that was changed at some point during the process.

2) There further seem to be unaddressed comments in the write-up...

3) Please use rfc8174 boilerplate.

4) The IANA section should contain the exact name and URL of the registry that the new sub-TLV value should be addd to.

5) The document should maybe provide further guidance on how the stated goal in the security  considerations section could be achieved.

[Ballot comment]
1) The IANA section should contain the exact name and URL of the registry that the new sub-TLV value should be addd to.

2) The document should maybe provide further guidance on how the stated goal in the security  considerations section could be achieved.

[Ballot comment]
1) The IANA section should contain the exact name and URL of the registry that the new sub-TLV value should be addd to.
2) The document should maybe provide further guidance on how the stated goal in the security  considerations section could be achieved.

The following Last Call announcement was sent out (ends 2018-02-22):

From: The IESG
To: IETF-Announce
CC: bier@ietf.org, Hooman Bidgoli , draft-ietf-bier-isis-extensions@ietf.org, hooman.bidgoli@nokia.com, akatlas@gmail.com, bier-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BIER support via ISIS) to Proposed Standard


The IESG has received a request from the Bit Indexed Explicit Replication WG
(bier) to consider the following document: - 'BIER support via ISIS'
  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 2018-02-22. 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


  Specification of an ISIS extension to support BIER domains and sub-
  domains.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bier-isis-extensions/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bier-isis-extensions/ballot/


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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

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

draft-ietf-bier-isis-extensions-06 is Experimental. This is indicated on the title page.

(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

HB> This draft presents extension needed for isis to advertise BIER information with in a bier domain and its subdomains. This information can be used to build a Bit Index Forwarding Table for BIER, which in order is used for forwarding multicast packets with in a BIER domain or subdomain. The ISIS extension BIER sub-tlv carries the information for BIER sub-domain that the router participates in. This sub-tlv includes multiple sub-sub-tlvs with label range and a bit string length for certain . 

Working Group Summary

HB> The draft has been well recived.

Document Quality

HB> base on the IETF discussions there are implementation of this draft and/or strong roadmap commitment from other vendors.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

HB> Hooman Bidgoli is the shepherd and Alia Atlas is the Director

1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

HB> Hooman Bidgoli, Yes he has reviewed the version 6 of bier-isis-extension
There are some unclear sections in the draft which could use some polishing.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

HB> This document has been reviewed, that said there are minor areas which is in need of polishing.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

HB> Due diligence was done with this respect.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

HB> Following sections might need some ironing:

Section 3: is there a reason that sub-sub-tlvs are not sequential? i.e. type 1 and 3 and no type 2.

Section 4.1: An ISIS signaled BIER domain is aligned with the scope of distribution of BFR-prefixes that identify the BFRs within ISIS.
Comment: should it be BIER sub-domain? As bier-architecture aligns BFR-PREFIX to a subdomain.

Section 4.1: The mapping of sub-domains to topologies MUST be consistent within a BIER flooding domain.
Comment: what is a BIER flooding domain here? The terminology is not consistence with bier-architecture, might be worth a while to have a sentence explaining it.

Section 5.1: All routers in the flooding scope of the BIER sub-TLVs MUST advertise the same sub-domain within the same multi-topology.
Comment: This means one MT can have multiple SDs. As an example, , . But  is not legal, since SD1 is part of MT1. An example might be appropriate here as it is not to clear.



 

  (1.e)  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?

HB> The WG consensus for this draft is very solid.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

HB> Negative

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Running the idnits… 

Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == Mismatching filename: the document gives the document name as
    'draft-ietf-bier-isis-extensions-06', but the file name used is
    'bier-isis-v6'


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-09) exists of
    draft-ietf-bier-ospf-bier-extensions-08


    Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 0 comments (--).



  (1.h)  Has the document split its references into normative and
          informative?  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
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

HB> Yes the document is split to normative and informative references. There are 2 normative draft that are ready to advance namely draft-ietf-bier-mpls-ecnapsulation-9 and draft-ietf-bier-ospf-bier-extension-8.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

HB> There are some questions remaining as per comments above. Why the the sub-sub-tlvs types not sequential.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

HB> Yes