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

[Paul Jakma <paul at clubi.ie>]

On Thu, 24 Aug 2006, Enke Chen wrote:

> Ok, so (X, N1) and (X, N2) have to be explicitly withdrawn in your 
> scheme.

Either that or resend all remaining paths for the NLRI in their 
entirety (implicitely withdrawing all previous paths for same NLRI).

See other reply too.

> That means more updates. Perhaps what is more challenging here is 
> that RR1 must withdraw (X, N1) before advertising (X, N11).

It doesn't, the UPDATE for (X,N11) can be sent before explicitely 
withdrawing (X, N1), if an implementation wishes.

> How do you guarantee the ordering in an imploementation?

Not needed. They are different paths in this scheme.

I don't actually see a difference in the implementation requirements 
here between the two drafts. Either implementation must either be 
able to reliably construct the identifier from (path, speaker path is 
to be sent to), or else keep state specific to each (path,speaker 
sent to).

> Please see my previous comment on de-coupling Tx from Rx:

Yes, agree this is highly desirable.

The multiple-hops case occasionally will have to generate multiple 
messages in the Tx path for one path change, which shouldn't be a 
problem. But there's no need for it to be coupled to Rx.

> ---------------------------------------------------------------------------
> In addition, it is desirable and typical in implementations to have the 
> receiving processing de-coupled from the sending processing  (in order to 
> keep less state).   It means that at the time of sending update the info 
> (such as the nexthop) for the old path may no longer available.  I am not 
> sure if your proposal requires an implementation to keep track of the 
> nexthops advertised to a peer for the purpose of figuring out when to use the 
> NEXTHOP attribute or the MULTI-NEXTHOP attribute.
> ---------------------------------------------------------------------------

If the implementation has the ability to advertise the same path with 
different nexthops to different speakers, yes it almost certainly 
would have to keep state on that.

I don't think this is much different from add-path, which also would 
need to keep state on identifiers it has used for each peer and path.

> > I think we can each come up with a scenario where one scheme would be more
> > optimal and would involve lesser number of UPDATEs than the other.
>
> I strongly disagree because of these reasons:
>
>   1) More updates are generated by your proposal due to the need for 
> explicit withdraws as shown in the example.

Though, this would be true only when the nexthop changes for a path.

- If the nexthop is the same, multiple-hops can update it with with
  an implicit withdraw.

- On the flip side, multiple-hops can bunch together paths whose
  attributes are all (bar nexthop(s)) equal.

- Add-path must always send distinct UPDATEs (with all attributes)
  for all paths which differ only by (NLRI,nexthop).

I don't know which would use more or less bandwidth in the real 
world. But we suspect next-hops are comparitively stable compared to 
full path changes.

>   2) As a new attribute is introduced in your proposal, the efficiency of 
> prefix packing will be lower, resulting in more updates.
>       It's shown that the prefix packing efficiency has a huge impact on the 
> performance of update processing  (both Tx and Rx).
> I would welcome an example that shows otherwise.

We could encode the nexthop identifiers in the NRLI quite easily.

I, personally, hate to see message formats redefined. If the 
'traditional' NLRI in BGP-4 no longer meets todays needs, we ought to 
deprecate it and properly define a new UPDATE message, but hey.

But if mushing UPDATE is fine, multiple-hop could do so too.

The identity question is still the tricky one here :).

regards,
--
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Question: Is it better to abide by the rules until they're changed or
help speed the change by breaking them?

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