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

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

----- Original Message -----
From: "Jeffrey Haas" <[e-mail]>
Sent: Tuesday, October 11, 2016 3:07 PM

> On Oct 11, 2016, at 7:09 AM, Nick Hilliard <[e-mail]> wrote:
>
> t.petch wrote:
>> I want a MUST in there so if anyone does otherwise, we can say No!,
not
>> allowed.
>
> If an operator in the far depths of inner Kaboodlestan uses an IPv4
> address instead of an ASN, the IETF can disapprove all it wants, and
it
> will make no difference to anyone.

Somewhat relevant example in other extensions:
Many implementations treat an add-paths path-id as an integer and you
tend to see them showing up as a int in show commands.

At least one implementation chose to use a BGP identifier/IP address in
theirs.

The spec treats the value opaquely.  Both use cases make sense in their
own context.

End of the day, the protocol cares that it's a 4 byte value.  Users may
want a given representational syntax because it makes their life easier
in their particular scenario.

Neither is solely the Right Thing.

<tp>
Jeff

True but not really germane to the point I keep making:-)

Your point is about representation, about how implementations may or may
not go beyond the RFC in what a user sees which is an interesting point
but not one that the relevant RFC says anything about (some RFC do
prescribe a display format).

On the other hand, the relevant RFC does contain a specific warning
about the local significance of the path identifier.  For
large-community, we are using a transitive attribute which, by
definition, has global significance, hence my concern.

Tom Petch
-- Jeff