Re: [RTG-DIR] Rtgdir last call review of draft-ietf-idr-rfc7752bis-11

[Ketan Talaulikar <[e-mail]>]

Hi Joel,

Thanks for confirming. I have these changes in the edit buffer to be
included in the next update.

Thanks,
Ketan


On Mon, Nov 7, 2022 at 6:22 PM Joel Halpern <[e-mail]> wrote:

> Thanks.  Both those fixes work for me.
>
> Yours,
>
> Joel
> On 11/7/2022 7:50 AM, Ketan Talaulikar wrote:
>
> Hi Joel
>
> Please check inline below for responses with KT2.
>
> On Mon, Nov 7, 2022 at 4:58 PM Joel Halpern <[e-mail]> wrote:
>
>> Slightly trimmed, two comments.  Joel
>>
>>
>> On 11/7/2022 1:03 AM, Ketan Talaulikar wrote:
>>
>> Hi Joel,
>>
>> Thanks for your review and please check inline below for responses.
>>
>> On Thu, Oct 27, 2022 at 7:32 PM Joel Halpern via Datatracker <
>> [e-mail]> wrote:
>>
>>> ..
>>>     None
>>>
>>> Nits:
>>>   At the end of the first paragraph of section 4, could we add a sentence
>>>   saying "the BGP-LS attributes appear within the corresponding new BGP
>>> NLRI"
>>>   or similar?  While that is explained later in section 4, the length of
>>> the
>>>   section means that a new reader is left wondering for quite some time.
>>>
>>
>> KT> The BGP-LS Attribute TLVs do not appear within the NLRI. Sec 4.2
>> introduces BGP-LS NLRIs and indicates that they are carried within the
>> MP_REACH/UNREACH. Further Sec 4.3 introduces the BGP-LS Attribute and
>> indicates that they are carried as part of the BGP update along with the
>> Link State NLRIs (and other attributes). Perhaps we can clarify a bit
>> upfront that the new NLRI types are carried in the MP_REACH/UNREACH?
>>
>> <jmh> Apparently I still managed to misread it.  Sorry.  It would help if
>> you could put a little more context at the front of section 4. </jmh>
>>
>
> KT2> How about the following?
>
>    The link-state information is carried in BGP UPDATE messages as:
>
>    (1) BGP NLRI information carried within MP_REACH_NLRI and
>
>    MP_UNREACH_NLRI attributes that describes link, node, or
>
>    prefix object, and (2) a new BGP path attribute (BGP-LS
>    Attribute) that carries properties of the link, node, or
>
>    prefix objects such as the link and prefix metric or
>
>    auxiliary Router-IDs of nodes, etc..
>
>
>
>>
>>
>>>
>>>  Section 4.1 has the paragraph:
>>>    All TLVs within the NLRI that are not specified as mandatory are
>>>    considered optional.  All TLVs within the BGP-LS Attribute are
>>>    considered optional unless specified otherwise.
>>>   As far as I can tell, those two sentences are saying, about two
>>> different
>>>   aspects of the encoding, the same thing.  But they say it in different
>>> ways.
>>>   If there is some subtle difference in meaning taht is intended, please
>>>   clarify.  If the meaning is indeed the same, could we use parallel
>>>   construction to avoid readers thinking there is a difference?
>>>
>>
>> KT> They are talking about two different "containers" - the NLRI and the
>> BGP-LS Attribute. The "default" is different for them.
>>
>> <jmh>I am having trouble parsing the distinction, even if the external
>> default is different.  The two sentences both seem to say that the only
>> mandatory items are those which are specified as mandatory.  They simply
>> say it in two different ways.  Why is the sentence construction different?
>> If there is an actual difference in intended effect, I think a few more
>> words would be helpful. </jmh>
>>
>
> KT2> How about the following?
>
>
>    For both the NLRI and BGP-LS Attribute parts, all TLVs are
>
>    considered as optional except where explicitly specified as
>
>    mandatory or required in specific conditions.
>
> Thanks,
>
> Ketan
>
>
>> Thanks,
>> Ketan
>>
>>
>>
>>