Subject: [Idr] Benoit Claise's Discuss on draft-ietf-idr-large-community-11: (with DISCUSS and COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Wed, 04 Jan 2017 06:52:42 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-idr-large-community-11: 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 IESG DISCUSS and COMMENT positions.

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

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

I see from the abstract: "The attribute is suitable for use with
four-octet ASNs."
I also see this text, which doesn't mention four-octet ASNs

   The Global Administrator field is intended to allow different
   Autonomous Systems to define BGP Large Communities without
collision.
   This field SHOULD be an Autonomous System Number (ASN), in which
case
   the Local Data Parts are to be interpreted as defined by the owner
of
   the ASN.  The use of Reserved ASNs (0 [RFC7607], 65535 and
4294967295
   [RFC7300]) is NOT RECOMMENDED.

What if the ASN is two bytes, we use padding? How?
Even if we would say: "This field SHOULD be an four-octet Autonomous
System Number (ASN)", it doesn't preclude inserting a two-octet ASN in
the Global Administrator field.
Isn't it better to specify how? 

>From RFC 6793:

   Currently assigned two-octet AS numbers are converted into
four-octet
   AS numbers by setting the two high-order octets of the four-octet
   field to zero.  Such a four-octet AS number is said to be mappable
to
   a two-octet AS number.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks John for an excellent shepherd writeup.

---

From: heasley <[email-masked]>
Date: Wed, 4 Jan 2017 15:21:56 +0000

>    the ASN.  The use of Reserved ASNs (0 [RFC7607], 65535 and

The draft should just reference rfc 6793, which ISTR it once had, though
that version may not have been published.

---

From: Ignas Bagdonas <[email-masked]>
Date: Wed, 4 Jan 2017 15:26:43 +0000

Hi Benoit,

Thank you for reviewing.

Global Administrator field is a 4 octet integer that is used to carry AS 
number but it is not mandatory to interpret it as an AS number only 
(while a typical use case is for carrying AS number) - two peers can 
agree on any value that has meaning between those peers. Representation 
on the wire is in network byte order, and 2 byte AS number will get 
naturally padded with two zero bytes in front. Virtually all deployments 
today are AS4 capable and use AS4 encoding even for AS number values 
that fit into 16 bit value range therefore AS number is a 4 octet entity 
already.

The topics of 2 byte padding and any integer value in global 
administrator field have been discussed in the WG.

Ignas

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 04 Jan 2017 15:29:46 +0000

Hi Benoit,

thanks for your comments.  This issue was brought up on idr@ on a couple
of occasions.  We deliberately didn't include text on the issue for
several reasons, one of them being the text in rfc6793 that you noted
below; two others were listed here:

> https://www.ietf.org/mail-archive/web/idr/current/msg16458.html

With regard to implementation, there have been no queries raised by any
code authors about this part of the spec, and we haven't come across any
reports about incompatibilities between any of the existing implementations.

If there had been any ambiguity here, it would have been specified
explicitly, but there isn't.

Nick

Benoit Claise wrote:
>   collision. This field SHOULD be an Autonomous System Number (ASN), in
>   which case the Local Data Parts are to be interpreted as defined by
>   the owner of the ASN. The use of Reserved ASNs (0 [RFC7607], 65535
>   and 4294967295 [RFC7300]) is NOT RECOMMENDED.
> 
>    Currently assigned two-octet AS numbers are converted into four-octet
>    field to zero.  Such a four-octet AS number is said to be mappable to
>    a two-octet AS number.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 4 Jan 2017 16:39:25 +0100

Ignas,
> Hi Benoit,
>
> Thank you for reviewing.
>
> Global Administrator field is a 4 octet integer that is used to carry 
> AS number but it is not mandatory to interpret it as an AS number only 
> agree on any value that has meaning between those peers. 
> Representation on the wire is in network byte order, and 2 byte AS 
> number will get naturally padded with two zero bytes in front. 
> Virtually all deployments today are AS4 capable and use AS4 encoding 
> even for AS number values that fit into 16 bit value range therefore 
> AS number is a 4 octet entity already.
Thanks Ignas.
Then this sentence in the abstract "The attribute is suitable for use 
with four-octet ASNs." is misleading, right? At least to me.
The attribute is suitable for four-octets ASNs and two-octets ASNs 
encoded in four-octets.
This would be more in line with "This field SHOULD be an Autonomous 
System Number (ASN)" later on.

Regards, B.
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> .

---

From: heasley <[email-masked]>
Date: Wed, 4 Jan 2017 15:46:39 +0000

> System Number (ASN)" later on.

No, because it is in reference to rfc1997, which is not usable with AS4.

---

From: Job Snijders <[email-masked]>
Date: Wed, 4 Jan 2017 18:13:29 +0200

Hi Benoit,

On Wed, Jan 04, 2017 at 04:39:25PM +0100, Benoit Claise wrote:
> with four-octet ASNs." is misleading, right? At least to me. The
> attribute is suitable for four-octets ASNs and two-octets ASNs encoded
> in four-octets. This would be more in line with "This field SHOULD be
> an Autonomous System Number (ASN)" later on.

I am under the impression that nowadays the IETF community considers all
ASNs to be four-octet ASNs, however, some of those ASNs can be encoded
as a two octet value. The Large Communities specification is suitable
for usage in Autonomous Systems from all walks of life, where as rfc1997
communities are unsuitable for all ASNs, specifically those ASNs which
cannot be encoded as two-octet values.

Kind regards,

Job

---

From: Benoit Claise <[email-masked]>
Date: Wed, 4 Jan 2017 19:43:23 +0100

Hi Job,

So basically, you're telling me: "The attribute is suitable for use with 
ASNs.", right?
Is this what needs to be in the abstract?

Regards, B.

---

From: Job Snijders <[email-masked]>
Date: Wed, 4 Jan 2017 21:13:08 +0200

Yes, absolutely!

I believe it is helpful because many people are looking for a solution like Large Communities provides (with their favorite search engine). This sentence is a hat tip to a 10+ year problem.

Large Communities addresses a very urgent problem from the operator community, specifically because it can be used by ASNs which fit only in four-octet values.

We are scraping the bottom of the barrel, IANA has run out of two-octet ASNs. Also at the RIR level, the end is also in sight: There are only a few thousand left. We cannot sustain the growth of the internet without a tool like Large Communities. Large Communities specifically addresses an issue which prevents four-octets from being used in a similar way to how RFC1997 is used.

Btw, I am not clear on how the topic at hand relates to the actual content of the DISCUSS. Can you update the discuss? Or how should I view the feedback?

Kind regards,

Job

On 4 Jan 2017, 20:43 +0200, Benoit Claise <[email-masked]>, wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 4 Jan 2017 14:51:06 -0500

Benoit,

I think the wording is accurate as written, but I see your point. I think your suggested wording is terse to a fault since it abandons the important "this will work with your four-byte ASN" information. IMO a change is not strictly needed, but if one is desired how about something like this?

OLD:
   The attribute is suitable for use with four-octet
   Autonomous System Numbers

NEW:
   The attribute is suitable for use with all Autonomous System Numbers including four-octet
   Autonomous System Numbers

Or a lawyer would probably say :-)
   The attribute is suitable for use with, inter alia, four-octet
   Autonomous System Numbers

Regards,

—John

> On Jan 4, 2017, at 1:43 PM, Benoit Claise <[email-masked]> wrote:
> 
> Hi Job,
> 
> So basically, you're telling me: "The attribute is suitable for use with ASNs.", right?

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 4 Jan 2017 20:20:47 +0000

There is no need to change the text.

The attribute is in fact suitable for use with four-octet ASNs.
Since all ASNs can be represented in 4 octets, there is no problem.

Thanks,
Jakob.

> -----Original Message-----
> From: John G. Scudder [mailto:[email-masked]]
> Sent: Wednesday, January 04, 2017 11:51 AM
> To: Benoit Claise (bclaise) <[email-masked]>
> Cc: Job Snijders <[email-masked]>; Ignas Bagdonas <[email-masked]>; The IESG <[email-masked]>; draft-ietf-idr-
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Benoit Claise's Discuss on draft-ietf-idr-large-community-11: (with DISCUSS and COMMENT)
> 
> Benoit,
> 
> I think the wording is accurate as written, but I see your point. I think your suggested wording is terse to a fault
> since it abandons the important "this will work with your four-byte ASN" information. IMO a change is not strictly
> needed, but if one is desired how about something like this?
> 
> OLD:
> -John

---

From: Benoit Claise <[email-masked]>
Date: Thu, 5 Jan 2017 09:19:54 +0100

Hi Jakob,
> Since all ASNs can be represented in 4 octets, there is no problem.
And the document lacks this link to RFC6793 as I mentioned in my initial 
DISCUSS, most probably because it's so obvious to you guys in your 
community.
My reasoning has been:
     either you mention that two-octet ASN can be represented in 
four-octets (RFC6793)
     or you mention: suitable for all ASNs (2 or 4)

Ok, it seems that we're going in circle here.
You guys understood my issue. It was DISCUSSed. I believe the draft 
should be clearer, but this is not DISCUSS-level point any longer.
Moving to a COMMENT, and trusting the responsible shepherd and AD.

For the record, John's proposal solved the issue.

    OLD:

    NEW:

Regards, Benoit