Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt

From: David Freedman <[email-masked]>
Date: Sat, 3 Dec 2016 10:14:24 +0000

last minute nit: if we are going to recommend that particular reserved ASNs are avoided for the global administrator, can we please include AS_TRANS (RFC6793), there is probably a certain irony in not doing so.

Dave

---

From: David Freedman <[email-masked]>
Date: Sat, 3 Dec 2016 10:47:44 +0000

just had an offlist conversation with job, and he has recommended that I elaborate on this point as it may be non obvious to some.

The GA is intended to be an ASN, but IMHO AS_TRANS is not an ASN, it is a signal between peers in an OPEN exchange and a signal between hops that information is missing in some way, it is not an ASN in the sense that it should (or perhaps now even *could*) be used by anybody as a local ASN for a router.

As such I'm aware of code that exists which discriminates against AS_TRANS, there are various libraries which handle data structures like ASNs (which could be used in , say , creating or validating a GA field) which would be very unhappy if fed AS_TRANS as their initial input.

I understand we want to progress the draft , and that and a line has to be drawn between what could be unwise in implementations , vs what could be unwise to be seen on the internet , and that a registry can exist for the latter , but this is something I feel strongly should live on the former side , and if a list of values is going to be specified in the draft , I feel this should be in it (irony aside).

Dave 

> On 3 Dec 2016, at 10:14, David Freedman <[email-masked]> wrote:
>

---

From: David Farmer <[email-masked]>
Date: Sat, 3 Dec 2016 07:31:08 -0600

I read the new language as a general recommendation, with emphasis on the
three specific examples, and not necessary limited the the three listed
examples, therefore the recommendation already applies to AS_TRANS
[RFC6793].

  The use of Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is
NOT RECOMMENDED.

If the intent is to be generic, as I am interpreting it, then maybe this
could be clarified a bit by adding a reference to the IANA Special-Purpose
ASN Registry with a minor tweak of the language.

   ...([IANA.SpecialAS], and particularly 0 [RFC7607], 65535 and 4294967295
[RFC7300])...

   [IANA.SpecialAS]
             IANA, "Special-Purpose Autonomous System (AS) Numbers",
              <http://www.iana.org/assignments/
              iana-as-numbers-special-registry/>.

Otherwise, if it is intended to apply to only the specified ASNs then maybe
that should be clarified and AS_TRANS [RFC6793] added.

  The use of the following Reserved ASNs is NOT RECOMMENDED, 0 [RFC7607],
23456 [RFC6793], 65535 and 4294967295 [RFC7300].

I prefer the recommendation be generic, with emphasis on 0, 65535, and
4294967295, but not limited to those three.  That way the recommendation
applies to new ASNs added to the IANA Special-Purpose ASN Registry without
have to update this specification each time a new Reserved ASN is added.

Thanks.

On Sat, Dec 3, 2016 at 4:47 AM, David Freedman <[email-masked]>
wrote:

> just had an offlist conversation with job, and he has recommended that I
> elaborate on this point as it may be non obvious to some.
>
> The GA is intended to be an ASN, but IMHO AS_TRANS is not an ASN, it is a
> signal between peers in an OPEN exchange and a signal between hops that
> information is missing in some way, it is not an ASN in the sense that it
> should (or perhaps now even *could*) be used by anybody as a local ASN for
> a router.
>
> As such I'm aware of code that exists which discriminates against
> AS_TRANS, there are various libraries which handle data structures like
> ASNs (which could be used in , say , creating or validating a GA field)
> which would be very unhappy if fed AS_TRANS as their initial input.
>
> I understand we want to progress the draft , and that and a line has to be
> drawn between what could be unwise in implementations , vs what could be
> unwise to be seen on the internet , and that a registry can exist for the
> latter , but this is something I feel strongly should live on the former
> side , and if a list of values is going to be specified in the draft , I
> feel this should be in it (irony aside).
>
> Dave
>
> > last minute nit: if we are going to recommend that particular reserved
> ASNs are avoided for the global administrator, can we please include
> AS_TRANS (RFC6793), there is probably a certain irony in not doing so.
> >
> > Dave
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 5 Dec 2016 02:16:52 +0000

No new text is required to cover this: 23456 is not an ASN.
Besides, if anyone were to put it into a large community, no harm would be done other than what would happen if any other unassigned ASN were used.

About reserving values, we don't reserve values because the values are unusable, but because we may want to use them for other purposes later. There is no need to reserve another value. 3 is more than enough.

Thanks,
Jakob.

> On Dec 3, 2016, at 2:53 AM, David Freedman <[email-masked]> wrote:
>