Re: [Last-Call] Rtgdir last call review of draft-ietf-idr-rfc7752bis-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <jmh@xxxxxxxxxxxxxxx> 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 <noreply@xxxxxxxx> 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

 
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux