Subject: [Idr] Robert Wilton's Discuss on draft-ietf-idr-eag-distribution-16: (with DISCUSS)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 18 May 2021 03:16:18 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-idr-eag-distribution-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-eag-distribution/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Thanks for this short doc, and sorry for the discuss, but hopefully it is
fairly easy to resolve ...

I think that it would be helpful for this document to explicitly state how this
attribute behaves in conjunction with the existing Administrative Group (color)
TLV (1088).  E.g., is the expectation that if this attribute is published then
the 1088 attribute would also always be published (with the same first 32
bits)?  Or is the expectation that this attribute can be published without the
1088 attribute being published at all?

Similarly, if a client receives both attributes there are there any
expectations to how it handles those, i.e., should it always use the new
attribute in preference?  Or otherwise, what should it do if the values were
inconsistent between the two attributes?

Regards,
Rob

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 18 May 2021 06:52:40 -0700

On May 18, 2021 at 6:16:19 AM, Robert Wilton wrote:

Rob:

Hi!

...
> I think that it would be helpful for this document to explicitly state how
> this attribute behaves in conjunction with the existing Administrative Group
> (color) TLV (1088). E.g., is the expectation that if this attribute is
> published then the 1088 attribute would also always be published (with the
> same first 32 bits)? Or is the expectation that this attribute can be
> published without the 1088 attribute being published at all?
>

This document defines an extension to BGP-LS (rfc7752), which leaves
out of scope how the information is used by the client ("consumer" in
rfc7752).  IOW, specifying the behavior is not in scope of this
document.

Thanks!

Alvaro.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 18 May 2021 14:17:54 +0000

Hi Alvaro,

> -----Original Message-----
> From: Alvaro Retana <[email-masked]>
> Sent: 18 May 2021 14:53
> To: Robert Wilton via Datatracker <[email-masked]>; The IESG
> <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>
> Cc: [email-masked]; [email-masked];
> Susan Hares <[email-masked]>; [email-masked]
> Subject: Re: Robert Wilton's Discuss on draft-ietf-idr-eag-
> distribution-16: (with DISCUSS)
> 
[RW] 

My concern isn't really about how this information is used, but how the new version of this attribute is expected to interplay with the existing version of this attribute that only carries a 32-bit value.  I.e., can the client rely on the old 1088 attribute being published even in the case that the attribute field is longer than 32 bits?

Even if the answer is that the server can do whatever it likes, is it not better to explicitly state that than leave the reader wondering?

Thanks,
Rob