Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt

[Enke Chen <enkechen at cisco.com>]

Hi, Paul:


Paul Jakma wrote:

> On Thu, 24 Aug 2006, Enke Chen wrote:
>
> > > RR1 would advertise the following UPDATEs to RR2.
> > >
> > > UPDATE: feasible nlri X, next_hop N1, <other attributes>
> > > UPDATE: feasible nlri X, multiple_hop N11, <other attributes>
> > > UPDATE: feasible nlri X, multiple_hop N2, <other attributes>
> > > UPDATE: feasible nlri X, multiple_hop N22, <other attributes>
> >
> > Please note that B1 and B2 are clients and do not advertise 
> > multi-paths. How do (X, N1) and (X, N2) got withdrawn on RR2 as they 
> > are no longer valid (replaced by B1 and B2), in other words how does 
> > RR2 figure out (X, N11) is a replacement of (X, N1), and (X, N22) a 
> > replacement of (X, N2)?
>
>
> They don't need to.
>
> The first above, with NEXT_HOP (or MP_REACH for MP) continues to imply 
> a full implicit withdrawal of the NLRI. So with that first UPDATE all 
> the previous (NLRI,nexthops) are withdrawn.


The update sequence described by Manav is the following:

UPDATE: feasible nlri X, next_hop N1, <other attributes>
UPDATE: feasible nlri X, multiple_hop N2, <other attributes>
UPDATE: unfeasible nlri X, multiple_hop N1
UPDATE: unfeasible nlri X, multiple_hop N2
UPDATE: feasible nlri X, multiple_hop N11, <other attributes>
UPDATE: feasible nlri X, multiple_hop N12, <other attributes>


You seem to be talking about a different approach. Could you detail the sequence of updates?

-- Enke




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