Sounds good to me. Regards, Alia
On Thu, Nov 30, 2017 at 12:24 PM, Greg Shepherd <[email protected]> wrote: > 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-extension >> [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
