Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

[t.petch <[e-mail]>]

----- Original Message -----
From: "Nick Hilliard" <[e-mail]>
Sent: Monday, October 10, 2016 12:34 AM

> t.petch wrote:
> > There is nothing IMHO in
> > '   Global Administrator:  A four-octet namespace identifier.  This
> >       MUST be an Autonomous System Number assigned by IANA.'
> > which says whose ASN it is, just that it must be an ASN; if you
allow
> > IPv4 addresses, Router ID, IGP Area numbers and so on, anything else
> > that fits into 32 bit, then it all breaks down so it MUST be an ASN.
At
> > a stretch, that wording includes private ASN since those values are
> > assigned by IANA although we might want to point that out
explicitly.
>
> There's something I'm not getting here in this discussion.
>
> Let's step back a bit and start with a principal:  "if a policy cannot
> be enforced, it is bad policy".
>
> There is no way a priori for a router to have knowledge of what ASNs
> have or have not been assigned, either by IANA or any other assignment
body.
>
> If a standards track document is created which mandates that a
specific
> identifier field "MUST" contain a ASN assigned by IANA, there is no
> practical way for another router to check this.  Because the MUST
cannot
> be checked or enforced in any meaningful way, a formal requirement of
> this form automatically falls into the realm of bad policy.
>
> The best option here is - as Brian noted - to align with 1997
semantics
> and make a recommendation to operators that the global administrator
> field should be an ASN, and to stay well clear of attempting to define
> what an ASN is, or is not. Operators are adults and will do what works
> for them; there's no need to be over-prescriptive.

Nick

I am probably still not being clear.  I think that 'assigned by IANA' is
a distraction.  My concern is with
'SHOULD be an ASN'

'SHOULD' means it need not be so some router manufacturer in response to
some customers' requests at some time in the future sees a completely
different use for it and puts in a 32-bit value from a different
namespace which may well have the same bit pattern as the ASN of one of
your peers.

You receive such a community and cannot tell, from the protocol, how to
interpret this 32 bit value, whether or not it is an ASN.  And if you
cannot do that, you cannot interpret the rest of the field safely.

The only thing you can do is see where it came from, which, being a
transitive attribute, you again cannot reliably do from the protocol.
So
you have to start ringing around your peers, who created this community,
is that an ASN or not?

Um.

I want a MUST in there so if anyone does otherwise, we can say No!, not
allowed.

I take your point about the lack of enforcement but that is true of
everything the IETF does.  We have no Internet police; if there is a bad
actor, then it is up to peer pressure to get them to change.  (And if
the bad actor dominates the market, then may be it is the IETF that
changes:-(

Tom Petch

> Nick