John, Thanks. I think we have converged on this -- yes, I have seen your latest email also. Your newer suggestion is a slight variant of my suggestion but the basic principle is the same, namely, the semantic of the flag is changed to "this is a confed EBGP hop" or "signing update to a confed EBGP peer". That is the same semantic that I was essentially using. Please see additional comments below (response to your questions/comments).
Sriram > On Aug 3, 2012, at 1:51 PM, "Sriram, Kotikalapudi" > <kotikalapudi.sri...@nist.gov> wrote: > >> Let us consider this example: >> >> ----(B1----B2)----(B3----B4)----(B5----B6)----> >> >> ---------AS1------------AS2------------AS3--------> >> >> where AS1, AS2 and AS3 form a confed, and >> the update is propagating from left to right; >> AS1 is the entry AS; >> B1, B2 are border routers in AS1; >> B3, B4 are border routers in AS2; >> B5, B6 are border routers in AS3. >> >> When B1 gets an update, it propagates it to B2 without adding a new >> signature. >> B2 looks at the signatures backwards starting from the most recently added >> AS. >> If the confed-entry flag is not set by any preceding AS (as expected at B2 >> in this example), >> then B2 sets the flag, adds AS1’s signature and forwards the update to B3. > > How is B2 supposed to know that the preceding ASes in the path aren't confed > members? I.e., how is it supposed to know it is in charge of setting the > flag? B1 knows this by configuration, but B2 doesn't. In the method I was suggesting, all border routers within a confed (i.e., B1, B2, …, B6) are configured to set the flag if they are forwarding the update to a confed-EBGP peer, except when they see that a flag was already set by one of the preceding ASes. This is a slightly different but similar semantics of "this is a confederation hop" that you are suggesting below. So we are converging to basically the same idea as I note below. > > One other option does occur to me however, and I'm not sure why I didn't > think of it before: for *every* crossing of a confederation member border, > set the flag, so it has the semantics of "this is a confederation hop" rather > than the current "entering a confederation" semantics. Then on exit, strip > all contiguous flagged hops. This is predicated on the observation that it's > hard for a router to know if its member AS was the confederation entry point, > but trivial to know it's sending the route to another member AS. Yes, I like this. In my proposal, a border router does not set a flag if a one was already set by a preceding AS. That limits it to indicating only the entry AS in the confed. But I think your extension of that idea is better. That is, remove the condition and let each of the border routers always set the flag if forwarding the update to a confed-EBGP peer. Let there be multiple contiguous flags. Thanks! Sriram > > --John _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
