Hi Alvaro, ... snip ... Alvaro wrote: >>I don’t have an objection for this behavior, but I think >>we should make the WG (and idr!) aware of the change >>and get their comments (if any) before I approve the publication.
Keyur responded: >#Keyur: Ack. Though I was only requesting some text clarification >so that it is very clear to the implementers. So there was no change required as Keyur points out. Oliver also agreed with Keyur's observation when I ran this by him last week. Per Keyur's request, I have added the following text clarification in Section 7: During Graceful Restart (GR), restarting and receiving BGPsec speakers MUST follow the procedures specified in [RFC4724] for restarting and receiving BGP speakers, respectively. In particular, the behavior of retaining the forwarding state for the routes in the Loc-RIB [RFC4271] and marking them as stale as well as not differentiating between stale and other information during forwarding will be the same as specified in [RFC4724]. ...snip... Alvaro wrote: >>…how should an iBGP speaker perform loop detection >>if there’s no BGPsec_Path attribute? In other words, >>there is no defined mechanism to run the algorithm in 4.4 without it. >> >>I’m not suggesting that you include an empty attribute, >>but that you indicate in 4.4 that no BGPsec_Path attribute >>is equivalent to an empty AS_PATH. Per your suggestion, I have added the following text in Section 4.4: Finally, one special case of reconstruction of AS_PATH is when the BGPsec_Path attribute is absent. As explained in Section 4.1, when a BGPsec speaker originates a prefix and sends it to a BGPsec-capable iBGP peer, the BGPsec_Path is not attached. So when received from a BGPsec-capable iBGP peer, no BGPsec_Path attribute in a BGPsec update is equivalent to an empty AS_PATH [RFC4271]. Please let me know if you have any comments/questions. Thank you. Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
