My notes / suggested wording changes inline below, marked with "KS:".
One other observation: We also discussed Lazy and Super Lazy modes of router operation at 6/6/12 meeting. If we were to include descriptions for those cases for the confed ASBRs, the description gets a bit more complicated. Especially because the ASBR has to perform operations that are different depending on whether it is in an AS in the middle of the confed or in an exit AS connecting to an external peer. Sriram ________________________________________ From: [email protected] [[email protected]] On Behalf Of Randy Bush [[email protected]] Sent: Saturday, June 16, 2012 12:50 AM To: sidr wg list Subject: [sidr] bgpsec and confeds [was: Minutes of 6/6/12 meeting uploaded] bgpsec and confederations allow me to try to state clearly for the list When an update enters the first AS in a confederation, all last internal ASBRs within the entry AS of the confederation, i.e the first signers within the confederation, set a flag in the signature block that says "I am the first signature within the confederation." KS: Please add: However, the flag MUST NOT be set if the update entered the confed at an AS and also exits from the same AS to go to an external peer AS. (In this case, the update is not traversing any eBGP peering links internal to the confed.) The update wanders around normally in the confederation and every sending internal confederation ASBR signs it with their internal AS. A confederation's exit router looks backwards in the AS sequence until it finds the first, i.e. most recent, instance of that flag. If it finds no flag, the update is treated as originated within the confederation. KS: The last sentence above is not true. Explanation as follows. Consider: AS1 --- (AS2 --- AS3 --- AS4) --- AS5 AS2, AS3, AS4 form a confed. AS1 and AS5 are external peers. Consider an update that is exiting the confed at AS4 and being forward signed to AS5. If the update originated from AS2 or AS3, then it is an update that indeed originated from within the confed but it *will* come with the flag set. And if the update originated in AS4, it should not have any signatures yet; AS4 will add the first signature when it forward signs to AS5. So I suggest the following change of wording: "If the ASBR finds no flag, then it means that the update has entered the confed at this AS (i.e., the same AS where the ASBR is) and hence it has not traversed any confed internal eBGP links." It strips the signature block containing the flag and all subsequent signature blocks. All signs of the internals of the confederation have now been removed. KS: Please add the following: It also strips from the Secure_Path segment the sequence of ASN and pCount fields corresponding to the internal ASs in the confed. It then forward signs to the next AS, using the identity of the public confederation AS. While the update is traversing the confederation, if it should hit a peering where the peer is is not bgpsec capable, it strips all bgpsec gloop and reconstructs a classic AS_path. KS: Suggest adding the following for clarity: The classic AS_path will include the standard confed sequence that is reconstructed from the Secure_Path and includes the sequence of ASNs starting with the ASN with the flag set and all ASNs that follow. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
