/32...
> -Original Message-
> From: Matthieu Boutier [mailto:bout...@irif.fr]
> Sent: Thursday, July 27, 2017 11:41 AM
> To: Chris Bowers
> Cc: David Lamparter ; rtgwg@ietf.org; Anton Smirnov
> ; Jen Linkova
> Subject: Re: Persistent loops when mixing rtgwg-en
On Thu, Jul 27, 2017 at 05:55:01PM +, Chris Bowers wrote:
> With the proposed generalization of rule #3, together with a clarification
> that the source-prefix-scoped
> forwarding table should be chosen based on longest source prefix match with
> the source address of the packet,
> I think we
On Mon, Aug 07, 2017 at 11:12:02AM +0200, Matthieu Boutier wrote:
> Hi David,
>
> > It's already there
>
> I was speaking about rtgwg-enterprise-pa-multihoming. ;-)
Oh, sorry, I jumped over because the section numbers were so similar ;-D
-David
> Thanks by the way for your explanations in your
Hi David,
> It's already there
I was speaking about rtgwg-enterprise-pa-multihoming. ;-)
Thanks by the way for your explanations in your two previous
mails. I think this really helps us understand each other.
Cheers,
Matthieu
___
rtgwg mailing list
On Fri, Jul 28, 2017 at 02:42:59PM +0200, Matthieu Boutier wrote:
[snip]
> 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-
On Wed, Jul 26, 2017 at 12:16:17AM +, Acee Lindem (acee) wrote:
> I must admit that I had always thought that the source-routing paradigm in
> draft-troan-homenet-sadr-01.txt was backward with the destination address
> Longest Prefix Match (LPM) being done prior to the source address lookup.
>
On Thu, Jul 27, 2017 at 07:23:46PM -0700, Fred Baker wrote:
> > On Jul 27, 2017, at 2:06 AM, Matthieu Boutier wrote:
> >
> > Did you agree that:
> >
> > 1. destination first give the correct behaviour as-is.
> >
> > 2. source first needs extra mechanism and route duplication.
>
> Actually, I
> On Jul 29, 2017, at 1:46 AM, Matthieu Boutier wrote:
>
>> Actually, I don't. I can produce cases in which source first gives the wrong
>> route, and in which destination first gives the wrong route.
>
> Interesting! (but I'm lost with the example below)
>
>> The only way I see to make doin
> Actually, I don't. I can produce cases in which source first gives the wrong
> route, and in which destination first gives the wrong route.
Interesting! (but I'm lost with the example below)
> The only way I see to make doing either one first *always* gives the right
> result is if a small se
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, w
> On Jul 27, 2017, at 2:06 AM, Matthieu Boutier wrote:
>
> Did you agree that:
>
> 1. destination first give the correct behaviour as-is.
>
> 2. source first needs extra mechanism and route duplication.
Actually, I don't. I can produce cases in which source first gives the wrong
route, an
om: Matthieu Boutier [mailto:bout...@irif.fr]
Sent: Thursday, July 27, 2017 11:41 AM
To: Chris Bowers
Cc: David Lamparter ; rtgwg@ietf.org; Anton Smirnov
; Jen Linkova
Subject: Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and
rtgwg-dst-src-routing
Hi,
> Does this generalization
Hi,
> Does this generalization of rule #3 resolve the discrepancy ?
It's not enough, because if you have overlapping source prefix, you'll
need to change the following.
1. If the source address of the packet matches one of the source
prefixes, then look up the destination address of t
> I believe the tables could be similarly collapsed giving source address
> higher precedence than destination address. Do you disagree?
mmm, it seems I failed to explain something since that's not the point…
Did you agree that:
1. destination first give the correct behaviour as-is.
2. sourc
David,
It seems to me that the example that creates a routing loop depends on having
two routes where
one non-default source prefix of one route contains the source prefix of the
other route
Specifically, S=2001:db8::/32 contains S=2001:db8:::/48.
I think that we can resolve the discrepa
Matthieu,
I believe the tables could be similarly collapsed giving source address
higher precedence than destination address. Do you disagree?
Thanks,
Acee
On 7/26/17, 9:05 AM, "Matthieu Boutier" wrote:
>Hi,
>
>David, you're right, and as you remark, the draft says:
>
>2.5: « It is also usef
Hi,
David, you're right, and as you remark, the draft says:
2.5: « It is also useful to note that the prefixes assigned to the site by
different ISPs will not overlap. »
This hypothesis breaks your example. But, as you, I think that we should
not rely on such hypothesis: it seems error-p
Hi David,
I must admit that I had always thought that the source-routing paradigm in
draft-troan-homenet-sadr-01.txt was backward with the destination address
Longest Prefix Match (LPM) being done prior to the source address lookup.
Rather I think if were going to standardize in the RTG WG, it sh
... I should step away from electronical devices, for some reason I'm
missing Chris Bowers and Fred Baker
again...
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
19 matches
Mail list logo
