Sriram: Hi!
Yes, I think I may have read more into Keyur’s comment than what he was asking for, so I think we’re ready to go. ☺ I’ll approve publication. Thanks!! Alvaro. On 1/16/17, 10:10 PM, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sri...@nist.gov<mailto:kotikalapudi.sri...@nist.gov>> wrote: 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
