Adrian,
Thanks for the review.
All of the changes that you suggest have been applied to version-03.
Ron
> -----Original Message-----
> From: BESS [mailto:[email protected]] On Behalf Of Adrian Farrel
> Sent: Sunday, February 01, 2015 4:41 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [bess] AD review of draft-ietf-bess-orf-covering-prefixes
>
> [Re-send with correct address]
>
> 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)
>
> _______________________________________________
> BESS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
