Re: [Idr] John Scudder's Discuss on draft-ietf-idr-bgp-ls-app-specific-attr-11: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi John,

Thanks for your response and I'll work with you to close this while you
still have the context time :-)

Please check inline below.


On Sat, Jun 25, 2022 at 3:18 AM John Scudder <[e-mail]> wrote:

> Hi Ketan,
>
> Sorry for the delay while I swapped the context back in.
>
> I think the §4 (2.C) text is clear now. Thank you!


KT> Thanks for your help with it.


>


> I have a question about the §4.1 example you added, I’m afraid (sorry).
> Here’s the text from -14:
>
>    The corresponding BGP-LS advertisements for that link are determined
>    as follows:
>
>    First, based on rule (1), the advertisements are conveyed to BGP-LS
>    to get the following:
>
>    1.  ASLA with S, F, and X bits set on it carrying link attributes
>        from IS-IS advertisement (a)
>
>    2.  ASLA SRLG with zero-length bit masks with a set of SRLGs from IS-
>        IS advertisement (b)
>
>    3.  ASLA SRLG with the X bit set on it with a set of SRLGs from IS-IS
>        advertisement (c)
>
>    The next rule that applies is (2)(c) and it is determined that
>    collation is required for applications S and F; therefore, we get the
>    following:
>
>    1.  ASLA with the S bit set on it carrying link attributes from IS-IS
>        advertisement (a) and SRLGs from IS-IS advertisement (b) (this is
>        collation for application S based on (2)(c))
>
>    2.  ASLA with the F bit set on it carrying link attributes from IS-IS
>        advertisement (a) and SRLGs from IS-IS advertisement (b) (this is
>        collation for application F based on (2)(c))
>
>    3.  ASLA with the X bit set on it carrying link attributes from IS-IS
>        advertisement (a) (remaining application not affected by
>        collation based on (2)(c))
>
>    4.  ASLA SRLG with zero-length bit masks with SRLGs from IS-IS
>        advertisement (b) (not affected by (2)(c))
>
>    5.  ASLA SRLG with the X bit set on it with SRLGs from IS-IS
>        advertisement (c) (not affected by (2)(c))
>
> I think what you’re saying is that a naive implementation will emit a
> total of eight (ASLA or ASLA SRLG), right? The first list 1-3, plus the
> second list 1-5? You’re not saying that the second list 1-5 is the final
> output, with list 1-3 having been an intermediate result?
>

KT> The processing of the list is progressive and the final list is the 1-5
for a "naive" and 1-4 (or even further consolidation) for a "non-naive"
implementation.


>
> If that’s your intent, I think it would be clearer if you numbered the
> items 1-8, so first 1-3 and then 4-8 instead of restarting the numbering.
> This is especially the case because you follow it with a third list, 1-4,
> which *is* a distinct set of (ASLA, ASLA SRLG).
>
> It’s late-ish on a Friday so I haven’t checked through the example in
> excruciating detail, and I kind of hope someone else is also checking, but
> if my understanding above is correct, I think maybe the change I’ve
> described gets us to the finish line.
>

KT> These progressive steps can be perhaps better clarified by adding text
before them. Something like "starts with this list", then "updated list is
.." and then "the final list ...". Would that make it clearer and address
your comment?

Thanks,
Ketan


>
> In any case the fix to §4 (2.C) is enough for me to clear my DISCUSS,
> although I hope we can finish tuning up the example anyway of course.
>
> Thanks,
>
> —John