I believe we are at a point of agreement for draft-ietf-bier-isis-extensions, and should be ready for WGLC. Do we have agreement here?
Thanks, Greg On Sun, Oct 22, 2017 at 9:24 AM, Antoni Przygienda <[email protected]> wrote: > Les, thanks for the work. > > > > Alia, given some of the changes is a 7 days limited (i.e. only pertaining > to changes introduced) WG LC appropriate? > > > > --- tony > > > > > > <[email protected]> spake: > > > > Alia – > > > > A new version of the draft has been posted which addresses your comments. > > > > Sorry this was not completed as quickly as you hoped, but reviewing the > comments/changes led to some lively discussion among the co-authors – it > took us a while to reach consensus on the changes. > > > > Some responses inline. > > > > *From:* Alia Atlas [mailto:[email protected]] > *Sent:* Tuesday, September 26, 2017 4:09 PM > *To:* [email protected]; [email protected]; draft-ietf-bier-isis- > [email protected] > *Subject:* early AD review of draft-ietf-bier-isis-extensions-05 > > > > I have done an early AD review of draft-ietf-bier-isis-extensions-05 in > preparation for receiving a request to publish it. First, I would like to > thank the authors - Les, Tony, Sam and Jeffrey - for their work on this > document. > > > > In my ideal timing, this draft would be updated and ready for IETF Last > Call by Oct 5 so that it could reach the IESG telechat on Oct 26 > with draft-ietf-bier-mpls-encapsulation and > draft-ietf-bier-ospf-bier-extensions. > It would be great to have 4 drafts approved for RFC publication - or even > some RFCs! If we can't make this timeline, then it'll add at least a month > or more. > > > > I do see a number of issues to be addressed. > > > > Major: > > > > 1) Sec 4.1: "At present, IS-IS support for a given BIER domain/sub-domain > is > limited to a single area - or to the IS-IS L2 sub-domain." > > Why is there this limitation? Having just reviewed the ospf draft, the > detail needed to handle inter-area seems straightforward there. It'd be a > pity to have different support in ISIS and OSPF... > > I didn't see anything about such a limitation in the bier-architecture or > bier-mpls-encapsulation drafts, so I'm startled to see it here. > > > > At the very least, some explanation of why IS-IS can't handle inter-area > and the implications for deployments is needed. > > > > In Sec 4.2, this is enforced by "BIER sub-TLVs MUST NOT be included when a > prefix reachability > advertisement is leaked between levels." but I don't see any > reasoning for why the BIER sub-TLVs couldn't be included... > > > > *[Les:] We have removed the restriction.* > > > > 2) Sec 5.1: This section has concern about restricting the advertisement > of BIER information in IS-IS for scalability - but it doesn't discuss at > all when a router would stop advertising the BIER sub-TLVs. It feels like > the section is hunting for a bit of a manageability or operational > considerations section. I'm not comfortable with the interoperability > issues posed by not indicating what triggers should cause advertisements or > withdrawals. Receiving an advertisement from a BFER seems like a > reasonable trigger to me, since it indicates an active receiver for the > <MT, SD>. > > > > *[Les:] This section has been removed.* > > > > 3) Sec 5.5 contradicts the last paragraph in Sec 2.1.1.1 in > draft-ietf-bier-mpls-encapsulation-08 which says" Note that in practice, > labels only have to be assigned if they are > going to be used. If a particular BIER domain supports BSLs 256 and > 512, but some SD, say SD 1, only uses BSL 256, then it is not > necessary to assign labels that correspond to the combination of SD 1 > and BSL 512." > > > > *[Les:] I believe this comment was resolved in the exchange between you > and Tony.* > > > > 4) Sec 5.6: "A valid BFR-id MUST be unique within the flooding scope of > the BIER advertisments." This doesn't leave scope for expanding to > inter-area in the future because the issue is not the flooding scope but > rather the distribution. > > > > *[Les:] Similarly, this was resolved in the email thread.* > > > > 5) Sec 6.1: " The sub-TLV advertises a single <MT,SD> combination followed > by > optional sub-sub-TLVs as described in the following sections." > > The figure and field descriptions do not include the MT-ID. There is > clearly the reserved octet intended for that?? > > > > *[Les:] Tony has already pointed out that the parent TLV has the MTID.* > > > > 6) Sec 6.2: This section needs to clearly define the relationship between > the labels and the Set Index in the specified <MT, SD>. It's also unclear > whether it is better to advertise all the labels ever needed or be able to > advertise only labels for a particular sequential number of SIs. The > restriction that only one sub-sub-TLV with the same BitStringLength makes > that impossible (but so does the lack of explicit starting SI). > > > > *[Les:] Some clarifying text has been added.* > > > > 7) Sec 6.3: The values for the Length & Tree Type field need to be clearer > after the figure. Also, is Tree Type an IANA-managed field?? I don't see > it in the IANA considerations. Ca it be different between IS-IS and OSPF? > > > > *[Les:] As you will see, we have deleted the tree type sub-TLV > altogether. In its place we inserted a BIER Algorithm (BAR) octet in the > BIER Info sub-TLV (replacing the “Reserved” field). Equivalent changes > will be forthcoming in the OSPF draft so the two drafts will remain > aligned.* > > > > Minor: > > > > a) Sec 2: "Invalid BFR-id: Unassigned BFR-id, consisting of all 0s." > > A clearer definition might be "Invalid BFR-ID: The special value of 0 - > used to indicate that there is not a valid BFR-ID" The same comment > applies to "Invalid BMP". > > > > *[Les:] Done.* > > > > b) Sec 5.7: Please add some text about dampening the reports of > misconfiguration - as usual. > > > > *[Les:] Done* > > > > Nits: > > > > i) Sec 5.1: "supported bitstring lengths MLs " All the other BIER drafts > use the acronym BSL (BitStringLength). Consistency is frequently useful > for clarity. > > > > *[Les:] As this section was removed the issue no longer exists.* > > > > ii) Sec 6.2: "Length: 1 octet." Please specify the value! > > > > *[Les:] This sub-TLV was removed, so again the comment no longer applies.* > > > > * Les* > > > > Regards, > > Alia > > _______________________________________________ > BIER mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bier > >
_______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
