[j-nsp] AS65535 rejected in recent JunOS

[Saku Ytti]

Recent JunOS (13.3R4 -> 13.3.R5)[0] have interpretation of RFC7300
where you should drop prefixes if  AS65535 occurs in your ASPATH.

I'm first to admit that we've done terrible mistake years ago by
choosing 65535 as CE ASN,

---
   While Last ASNs are reserved, they remain valid ASNs from a BGP
   perspective.  Therefore, implementations of BGP [RFC4271] SHOULD NOT
   treat the use of Last ASNs as any type of protocol error.  However,
   if a Last ASN is configured as the local AS, implementations MAY
   generate a warning message indicating improper use of a reserved ASN.
---

This paragraph, very obviously states that you can configure 65535 as
your local-as, only thing implementation may penalize, is give you a
warning. And logical conclusion is, as 65535 can be local-as it MUST
be ok see it in AS_PATH.

---
   Implementations that provide tools that filter Private Use ASNs
   within the AS_PATH and AS4_PATH attributes MAY also include Last
   ASNs.
---

My interpretation of this paragraph is, if you offer private-asn
stripping knob, this knob MAY also affect 65535. This also implies
prefix is to be accepted, as manipulating AS_PATH of rejected route is
no-op.


But considering that in my biases I'm reading this wrong. It seems it
would still be fundamentally against robustness principles to drop
these prefixes.

I think vendors would benefit on engaging the community more actively,
it would have not been large effort to ask in j-nsp about this, and
use the discussion as input in your decision-making. I understand how
hard it is to implement code based on just RFC, without having
operational experience.
I love JNPR is working on quality and correctness, and I understand
mistakes do happen. But they would happen less, if customers voices
would be heard more.

Is anyone aware if there already is beta rebuild available with knob
to change this behavior?

[0] http://forums.juniper.net/t5/Junos/Juniper-Mx480-peer-as/td-p/269144
-- 
  ++ytti