Re: [Idr] New Draft Notification draft-dickson-idr-last-resort

[Brian Dickson <briand at ca.afilias.info>]

Olivier Bonaventure wrote:
> Brian,
>
>> Version -01 of the document has been uploaded, mostly fixing typos, 
>> adding/removing appropriate References, and condensing the formatting
>> (so as to avoid the mostly-blank pages - thanks Joel.)
>>
>> Comments are more than welcome, they are invited. :-)
>>
>> http://www.ietf.org/internet-drafts/draft-dickson-idr-last-resort-01.txt
>
> One problem which is not discussed in the draft is the incremental 
> deployment. You propose to change the BGP decision process, which 
> could be dangerous as you could have in an AS different BGP decision 
> processes.
>
> Assume that in a given network some routers have been upgraded and 
> support LAST_RESSORT, while other have not been upgraded and 
> completely ignore it. In this case, you may easily enter in a 
> situation where a permanent loop is created between routers that 
> understand LAST_RESSORT and routers that do not understand it. I think 
> that a safer approach would be to use the second option that you 
> propose, namely to convert LAST_RESSORT into an appropriate LOCAL_PREF 
> value when entering an AS.

I'm quite certain that the existing requirements on BGP path selection, 
which prevents routing loops from occurring, are upheld with the new logic.

In order for a loop to occur, two routers need to mutually think the 
other is the best next-hop.

However, BGP only sends the local-best, and thus any router receiving a 
route from a neighbor, regardless of what policy or decision process led 
to that choice, can be sure that using that route will not result in a 
routing loop.

At worst, persistent oscillations may occur.

And, I believe it is the case, that no *new* persistent oscillations are 
introduced, that conditions leading to persistent oscillations would 
have had to exist prior to the new logic, for them to exist post-upgrade.

If you have two routers, one upgraded (U) and one not (N), then the 
possibilities are:

    * U sends an LR to N. N ignores the community and installs the route.
          o This is not a problem, since U would only send the LR to N
            if the LR was also the locally-selected "best" on U.
          o Note that this could only happen if the LR that U selected,
            was from (anyone-but-N).
          o if (and only if) N's previous best being withdrawn from U,
            causes u to select a different "best", a persistent
            oscillation will occur -- but not a permanent loop.
          o No routing loop; N -> U -> (not-N).
    * N sends an LR to U. U applies the new logic.
          o U will only install the route if it is the best route, i.e.
            no other non-LR routes exist.
          o N sent the LR because it was N's best, and it did not come
            from U.
          o if (and only if) U's previous best being withdrawn from N,
            causes N to select a different "best", a persistent
            oscillation will occur -- but not a permanent loop.
          o No routing loop; U -> N - > (not-U).


In all cases, a router will only announce a prefix if it is locally 
selected as "best". LAST_RESORT affects local selection, but does not 
change what happens once local selection is complete.

If after this explanation, you still believe a condition can exist where 
a permanent routing loop would occur, please walk me through a specific 
example, as I think that would be the best way to identify what leads 
the the loop.

Thanks,

Brian
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr