Internet Exchange BGP Route Server
RFC 7947

Note: This ballot was opened for revision 10 and is now closed.

Alvaro Retana Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2016-06-15 for -11)
No email
send info
From an operational point of view, when an ISP wants to go change from bilateral interconnections to the multilateral interconnection within one IXP, is this correct to say that all bilateral interconnections should be removed?
So that basically the ISP must chose between the two models, and not combined them? If this is the case, it should be mentioned.
I thought it was clear to me until I saw figure 1: The dotted line is the IXP or the IXP Route Server?
At first glance, I thought that it was the IXP and that AS1 was connected to the IXP Route Server while still having a bilateral connection with AS4.
I hope now that the dotted line is the IXP Route Server, otherwise I've confused.

Alissa Cooper No Objection

Comment (2016-06-13 for -11)
No email
send info
Was wondering the same thing as Mirja.

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

(Joel Jaeggli) No Objection

Comment (2016-06-14 for -11)
No email
send info
I'm at a bit of a loss to understand why path hiding would be a considered an undesirable property of an MLPE routeserver.  IMHO as an operator that peers on MLPE exchanges as well as bilaterally on exchange fabrics and via PNIs. blinding a client of the MLPE which I  may have a session already with at the exchange or via PNI is basically mandatory. Likewise without per-asn export policy at exchanges my ability to advertise anycast prefixes via the MLPE is basically noexistant

   If an IXP operator deploys a route server without
   implementing a per-client routing policy control system, then path
   hiding does not occur as all paths are considered equally valid from
   the point of view of the route server.

Does not seem like a particularly desirable outcome.

While I'm fine with 2.3 not being normative, it does seem desirable that an MLPE service offer the client control, it greatly increases the sorts of clients that can safely use the service.

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Comment (2016-06-13 for -11)
No email
send info
Quick question: Why is the following statement a SHOULD and not a MUST:
"the route server SHOULD NOT prepend its own AS number to the AS_PATH
   segment nor modify the AS_PATH segment in any other way. "
Is this because the clients might eitherwise not accept the message? 
Maybe add one sentence to explain the SHOULD!

(Terry Manderson) No Objection

Alexey Melnikov No Objection

(Kathleen Moriarty) No Objection

Comment (2016-06-15 for -11)
No email
send info
Thanks for addressing the SecDir review comments:
https://www.ietf.org/mail-archive/web/secdir/current/msg06613.html