Re: [Isis-wg] [Bier] early AD review of draft-ietf-bier-isis-extensions-05

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 <prz@juniper.net> 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
>
>
>
>
>
> <ginsberg@cisco.com> 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:akatlas@gmail.com]
> *Sent:* Tuesday, September 26, 2017 4:09 PM
> *To:* bier@ietf.org; isis-wg@ietf.org; draft-ietf-bier-isis-
> extensions@ietf.org
> *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
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>