Ah, I see. I agree your interpretation is the correct one. So no change is necessary. Thank you.
Sriram ________________________________________ From: Sandra Murphy <[email protected]> Sent: Saturday, October 17, 2015 11:30 AM To: Sriram, Kotikalapudi Cc: Sandra Murphy; Matthew Lepinski; sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-13.txt speaking as a regular ol’ member On Oct 16, 2015, at 12:09 PM, Sriram, Kotikalapudi <[email protected]> wrote: > > > Substantive comment .... > > Looking at this on page 23, > > "BGPsec update messages do not contain an AS_PATH attribute. > Therefore, a BGPsec speaker MUST utilize the AS path information in > the BGPsec_Path attribute in all cases where it would otherwise use > the AS path information in the AS_PATH attribute. The only exception > to this rule is when AS path information must be updated in order to > propagate a route to a peer (in which case the BGPsec speaker follows > the instructions in Section 4)." > > What is being said in the second sentence above is not clear. > > No exception applies if the peer is BGPsec capable and negotiated BGPsec. > > So is the exception for the case when the peer is non-BGPsec? > > May the fix is to replace this (current): > > "The only exception > to this rule is when AS path information must be updated in order to > propagate a route to a peer (in which case the BGPsec speaker follows > the instructions in Section 4)." > > with the following (proposed): > > The only exception > to this rule is when AS path information must be re-formatted to AS_PATH > in order to > propagate a route to a non-BGPsec peer (in which case the BGPsec speaker > follows > the instructions in Section 4.4). > I read that sentence differently. When BGP is propagating a route to a neighbor, it ordinarily appends its AS to the AS_PATH. The “in all cases” would imply the same would happen in BPGsec, whether the neighbor is bpgsec capable or not. The exception is that, in the propagating case, BGPsec will instead follow section 4 - which covers bgpsec capable neighbors (embed AS in BGPsec_Path) and bgpsec incapable neighbors (reconstruct AS_PATH). I think your statement is correct, but I don’t think it is what is meant here. —Sandy, speaking as a regular ol’ member _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
