Subject: [bess] AD review of draft-ietf-bess-orf-covering-prefixes

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 1 Feb 2015 21:39:16 -0000

Thanks for this document. I was hard-pushed to find anything to talk 
about, so I guess you did a good job or I am losing my touch.

The points below are pretty minor, but they will get pulled up in 
IETF last call reviews, so I think we should fix them in a new
revision before i start last call.

I'll put the document into "Revised I-D needed" state, and start the 
last call as soon as I see a new revision.

Thanks for the work,
Adrian

---

In section 3

   When a BGP speaker receives a ROUTE-REFRESH message that contains a
   CP-ORF, and that ROUTE-REFRESH message violates any of the encoding
   rules specified in Section 2, the BGP speaker MUST log the event and
   ignore the entire ROUTE-REFRESH message.

I think you need to allow for event logging to implement thresholds to
avoid the logs becoming a gating factor when there is something evil
going on. Probably that makes 

s/MUST/SHOULD/
And add "although an implementation MAY apply logging thresholds to
avoid excessive messaging or log file overflow."

---

Section 7 needs to include a request to the IANA to update the 
references to the code points to point to this document when
published as an RFC.

---

Section 8 has

   o  When negotiating the ORF capability, advertise willingness to
      receive the CP-ORF only to known, trusted iBGP peers

which implies that there is a mechanism to
- negotiate the ORF capability
- advertise willingness to receive CP-ORF

Do you need a small section on this? Probably just a reference to the
negotiation process for the ORF capability, and a note saying how the
CP-ORF willingness is indicated.

---

I completely understand where you are coming from with section 8, but I
also know how our friends in the Security Area will respond.

Can you add a very short section noting...

   Security considerations for BGP are presented in [RFC4271] while
   further security analysis of BGP is found in [RFC6952].

(you'll have to add an informative reference to 6952)