Subject: Re: [Idr] new draft - reservation of two already reserved ASNs

From: David Farmer <[email-masked]>
Date: Tue, 04 Jun 2013 02:04:23 -0500

On 5/20/13 15:13 , Jon Mitchell wrote:
...
> I'm open to others thoughts, but forcing a change on existing
> implementations (versus just IETF/operator guidance on ASN's usage)
> was not my intention.

I'd like to hear others thoughts too.  As I said, I'm not certain we 
need to make this a protocol change, but I would like to hear more 
opinions on the subject.

But for the moment, assuming we don't make this into a protocol change, 
I have a few comments on the current text.

1. I'd suggest making section 4 exclusively about guidance for operators 
and splitting the guidance for BGP implementation into a separate section.

2. I'm mostly OK with the operator guidance in the draft, but I think it 
would be more accurate to change "or for any other purpose" to "and 
SHOULD NOT use these ASNs for any other purpose, except an otherwise 
designated Special Use", and the "MAY filter" language I feel needs to 
stronger, probably "SHOULD filter" would be better.

3. But I think the guidance for BGP implementations needs a lot more 
work. As I said; "As drafted, what implementations should do when these 
two ASNs are seen is ambiguous.  I'm afraid some implementations will 
treat it as an error and others will not, minimally leading interesting 
operational situations, and worst case leading to outright 
incompatibilities."  Therefore, if use of these ASNs are NOT going to be 
made a protocol error, then it needs to be made explicit that its NOT a 
protocol error and all implementations must accept these ASNs.  I think 
the "MAY filter" is appropriate for implementation guidance.

Bringing these together and with some other minor changes, here is some 
suggested text for you, use it as you feel appropriate;

  4. Operational Considerations

     Operators MUST NOT use these Last ASNs as if they are Private Use
     ASNs, and SHOULD NOT use these reserved ASNs for any other purpose,
     except an otherwise designated Special Use.  Any other operational
     use of these reserved ASNs could have unpredictable or undesirable
     results.  For example; use of ASN 65535 as if it was a Private Use
     ASN, may result in inadvertent use of BGP Well-known community
     values [IANA.WK], causing undesirable routing behavior if prefixes
     are inadvertently tagged with BGP Well-known communities.

     Operators that choose to filter Private Use ASNs within the
     AS_PATH, and AS4_PATH, SHOULD also filter these Last ASNs in the
     same way, to prevent the use of these reserved ASNs on their
     networks and the Internet.

  5. BGP Implementation Considerations

     While these Last ASNs are reserved, they are valid ASNs from a
     protocol perspective.  Therefore, implementations MUST NOT treat
     the use of these ASNs as any type of error.  All implementations
     MUST accept these ASNs as the local AS, or as a peer AS in an OPEN
     message.  However, an implementations MAY generate some kind of
     warning message indicating possible improper use of a reserved ASN.

     Implementations that provide tools that filter Private Use ASNs
     within the AS_PATH, and AS4_PATH, MAY also include these Last ASNs
     and filter them in the same way as Private Use ASNs.

Thanks for working on this.

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

---

From: Jared Mauch <[email-masked]>
Date: Tue, 4 Jun 2013 09:37:50 -0400

I think the text below in 4/5 looks good.

- Jared

On Jun 4, 2013, at 3:04 AM, David Farmer <[email-masked]> wrote:

> I'd like to hear others thoughts too.  As I said, I'm not certain we need to make this a protocol change, but I would like to hear more opinions on the subject.
> 
> But for the moment, assuming we don't make this into a protocol change, I have a few comments on the current text.
> 
> 1. I'd suggest making section 4 exclusively about guidance for operators and splitting the guidance for BGP implementation into a separate section.
> 
> 2. I'm mostly OK with the operator guidance in the draft, but I think it would be more accurate to change "or for any other purpose" to "and SHOULD NOT use these ASNs for any other purpose, except an otherwise designated Special Use", and the "MAY filter" language I feel needs to stronger, probably "SHOULD filter" would be better.
> 
> 3. But I think the guidance for BGP implementations needs a lot more work. As I said; "As drafted, what implementations should do when these two ASNs are seen is ambiguous.  I'm afraid some implementations will treat it as an error and others will not, minimally leading interesting operational situations, and worst case leading to outright incompatibilities."  Therefore, if use of these ASNs are NOT going to be made a protocol error, then it needs to be made explicit that its NOT a protocol error and all implementations must accept these ASNs.  I think the "MAY filter" is appropriate for implementation guidance.
> 
> Bringing these together and with some other minor changes, here is some suggested text for you, use it as you feel appropriate;
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 6 Jun 2013 20:43:25 -0400

> I think the text below in 4/5 looks good.

I'd prefer to work out the specific wording once/if WG agrees to work
on this (I'm assuming you support the draft?) but I also generally
like the below section 4/5 text suggestions, think splitting the
sections is a great idea and think implementations should continue to
allow use of these ASNs (not add new code to treat as error).

Jon