Thank's Chris, it makes things much more clear.
> With […], I think we are in agreement that the forwarding behavior described
> in rtgwg-enterprise-pa-multihoming Is identical to that described in
> rtgwg-dst-src-routing.
I think so. :-)
> Assuming that the forwarding behaviors are identical, we can now ask the
> question: Is it useful to have two different representations of the same
> forwarding behavior? I think it is.
>
> It is not the case that "All the section 3 is about what to do if we don't
> have native destination-first SADR tables but only policy routing." If the
> two representations produce the same forwarding behavior, then one should be
> free to implement using either representation.
>
> I think that enterprise network operators are going to have a very difficult
> time understanding destination-first SADR forwarding tables. Instead,
> operators are very familiar with simple destination-based forwarding tables.
> I think that operators will find it much easier to understand and troubleshoot
> when this forwarding behavior is represented using a set of
> source-prefix-scoped destination-based forwarding tables.
I completely missed this discussion while reading the draft. I understand that
people may want to have different representations. Perhaps the draft should
speak about both representations, since routes are advertised as pairs (D,S),
and it's likely that routing protocols will keep this simple representation.
Perhaps having something like the following(?):
3. Forwarding tables representations
3.1. Source Address Dependant Forwarding tables
-> this is just a dump of the announces
3.2. Source-Prefix-Scoped Forwarding Tables
-> using "Generating Source-Prefix-Scoped Forwarding Tables v2"
3.3. Examples
> When routing protocols are working properly, it shouldn't matter. But when
> packets are not going where the network operator wants them to, they are going
> to want to be able to troubleshoot this by looking at the forwarding tables.
Now I see the point.
Thanks,
Matthieu
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
