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

From: Qin Wu <[email-masked]>
Date: Tue, 18 May 2021 12:19:20 +0000

Hi, Rob:
-----邮件原件-----
发件人: Robert Wilton via Datatracker [mailto:[email-masked]] 
发送时间: 2021年5月18日 18:16
收件人: The IESG <[email-masked]>
抄送: [email-masked]; [email-masked]; [email-masked]; Susan Hares <[email-masked]>; [email-masked]; [email-masked]
主题: Robert Wilton's Discuss on draft-ietf-idr-eag-distribution-16: (with DISCUSS)

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?

[Qin]: I think it should be deal with in the same way as one defined in RFC7308, this issue has been discussed in the v-09 and taken out in v-10 for simplicity. See last sentence in section 2:
"
The semantics of the EAG and the backward compatibility aspects of EAG with respect to the AG are handled as described in the Backward Compatibility section of [RFC7308].
"

Regards,
Rob

---

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

Hi Qin,

Please see inline ...

> -----Original Message-----
> From: Qin Wu <[email-masked]>
> Sent: 18 May 2021 13:19
> To: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [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)
> 
> Hi, Rob:
> -----邮件原件-----
> 抄送: [email-masked]; [email-masked];
> [email-masked]; Susan Hares <[email-masked]>; [email-masked];
> [email-masked]
> 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.)
> 
> 
> 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
> 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?
> 
> [Qin]: I think it should be deal with in the same way as one defined in
> RFC7308, this issue has been discussed in the v-09 and taken out in v-10
> for simplicity. See last sentence in section 2:
> "
> The semantics of the EAG and the backward compatibility aspects of EAG
> with respect to the AG are handled as described in the Backward
> Compatibility section of [RFC7308].
> "
[RW] 

Referencing that text might be okay.

Alternatively, having read the referenced text, having a sentence in the introduction that states that the BGP-LS EAP attribute is handled entirely independently of the AG attribute would be sufficient.  I.e., the text in the introduction makes this seem like this is a replacement for, and in some way related to, the EA attribute.

Thanks,
Rob

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 18 May 2021 07:50:37 -0700

On May 18, 2021 at 10:29:24 AM, Rob Wilton wrote:

Rob:

Hi!

Joining the threads...

...
> Alternatively, having read the referenced text, having a sentence in the
> introduction that states that the BGP-LS EAP attribute is handled entirely
> independently of the AG attribute would be sufficient. I.e., the text in the
> introduction makes this seem like this is a replacement for, and in some way
> related to, the EA attribute.

Here's a suggestion...from the Introduction:

OLD>
   These administrative groups are defined as a fixed-length 32-bit
   bitmask.  As networks grew and more use-cases were introduced, the
   32-bit length was found to be constraining and hence extended
   administrative groups (EAG) were introduced in [RFC7308].

   This document specifies an extension to BGP-LS for advertisement of
   the extended administrative groups.

NEW (append, or add as a new paragraph)>
   The EAG TLV (Section 2) is not a replacement for the Administrative
   Group (color) TLV; as explained in [RFC7308] both values can coexist.
   It is out of scope for this document to specify the behavior of the
   BGP-LS consumer [RFC7752].

Would that work?

Thanks!

Alvaro.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 18 May 2021 15:02:27 +0000

Hi Alvaro, Qin,

Please see inline.

> From: Alvaro Retana <[email-masked]>
> Sent: 18 May 2021 15:51
> To: Qin Wu <[email-masked]>; The IESG <[email-masked]>; Rob Wilton
> (rwilton) <[email-masked]>
> Cc: [email-masked]; [email-masked]; Susan
> Hares <[email-masked]>; [email-masked]
[RW] 
> Would that work?
[RW] 
Broadly, yes.  The first extra sentence would be sufficient to clear my initial confusion when I was reading this document.

I don’t mind if you want to keep the second sentence, but it is a bit unclear to me as to what behaviour is out of scope.

Thanks,
Rob

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 18 May 2021 22:43:23 -0500

Hi Rob,

Thanks for your review!

It is specifically out of scoop of what BGP-LS consumer does with the data.
I’ll go ahead and update the text (both sentences) would that work for you?

Thanks!

Cheers,
Jeff

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 19 May 2021 09:39:28 +0000

Hi Jeff,

Yes.  Thank you.

I’ve cleared my discuss.

Regards.
Rob

From: Jeff Tantsura <[email-masked]>
Sent: 19 May 2021 04:43
To: Alvaro Retana <[email-masked]>; Qin Wu <[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)

Hi Rob,

Thanks for your review!

Thanks!

Cheers,
Jeff
On May 18, 2021, 10:03 AM -0500, Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>, wrote:

Hi Alvaro, Qin,

Please see inline.

-----Original Message-----
From: Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Sent: 18 May 2021 15:51
To: Qin Wu <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>; Rob Wilton
(rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan
Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Robert Wilton's Discuss on draft-ietf-idr-eag-distribution-
16: (with DISCUSS)

Rob:

Hi!

Joining the threads...

...

Alternatively, having read the referenced text, having a sentence in the
introduction that states that the BGP-LS EAP attribute is handled
entirely

independently of the AG attribute would be sufficient. I.e., the text in
the

introduction makes this seem like this is a replacement for, and in some
way

OLD>

Would that work?
[RW]

Thanks,
Rob

Thanks!

Alvaro.