asymmetric routing

Richard & Kathleen Pearson rpearso1@tampabay.rr.com
Mon, 28 Jan 2002 14:54:07 -0500
Previous message: asymmetric routing
Next message: asymmetric routing
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This is a multi-part message in MIME format.

------=_NextPart_000_004E_01C1A80B.A3DA8BC0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Please remove me from the distribution list.  This is the 3rd time I have
asked.  If not complied with, I will report these messages a spam mail.

Thanks

-----Original Message-----
From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU]On Behalf Of
Matthew Lehman
Sent: Monday, January 28, 2002 12:04 PM
To: Pim van Pelt; Sandy Wills
Cc: ipng@uni-muenster.de; 6bone
Subject: RE: asymmetric routing


Concerning multiple uplinks to different providers; when you use the
word customer, I am assuming you mean an entity with provider dependent
addressing (Some people will have customers with provider independent
addressing).

It is a common scenario to want provider diversity to guard against
transit provider failure or to implement different policies by service
(i.e. Content Delivery Networks, bulk vs. interactive traffic, etc.).
This does not seem to be limited to IPv4.  There's a draft on this at:
http://www.ietf.org/internet-drafts/draft-ietf-multi6-v4-multihoming-00.
txt

-Matthew

> -----Original Message-----
> From: Pim van Pelt [mailto:pim@ipng.nl]
> Sent: Monday, January 28, 2002 7:56 AM
> To: Sandy Wills
> Cc: ipng@uni-muenster.de; 6bone
> Subject: Re: asymmetric routing
> 
> 
> Regarding my statements on asymmetric routing at IPng, Christian
(JOIN)
> reasoned:
> | > Yes, one could filter all but those prefixes a customer holds, but
> then the
> | > customer has to name all his providers/prefixes. You can't force a
> customer
> | > to do so, because that information might be confidential.
> 
> Sandy said:
> |    Isn't this reasoning flawed? Customer #1 has prefix A.  You let
that
> | traffic through.  Customer #2 has prefixes X, Y and Z - but he
doesn't
> | want you to know about Z because he's afraid that you won't like
him.
> | So, you let through traffic with prefixes X and Y.  Stop Z.  Traffic
Z,
> | if any, will go through some other provider, or it won't go through.
> | You're not forcing anyone to do anything.
> |    What am I missing?  You can limit the prefixes you allow to those
> | your customers tell you about.  Your customers can have more than
one
> | feed, and he doesn't have to tell you everything.
> Well it's not really BGP we were talking about. In the BGP world we
can
> filter updates from downstream customers, which means we will not
route
> traffic to them. But what if the customer, with prefix B, sends
traffic
> originating from B via my networks (and I am prefix aggregator A).
Then
> I will inject traffic into the 6BONE that should not be coming from my
> routers.
> This can no longer be taken care of by BGP prefixlist filters, but the
> need
> for ACL based filtering arises. The customer with a desire to be
> multihomed,
> should respect aggregation policies and not send provider A traffic
that
> comes
> from prefix B, when A does not advertise B's prefixes into the default
> free
> zone.
> In practice, unless you deliberately deop the traffic, customers will
send
> you any and all traffic they please. Being passive makes you break
rules.
> This is why I brought my first post to the list. But I think we made
that
> point already ;-)
> 
> |    You're not forcing anyone to do anything.  He is forcing himself
to
> | pay for routers and network people which can direct his traffic out
the
> | proper cables, and HE is the one who suffers if HE screws it up.  He
> | does NOT have the right to force you to enable routing loops because
his
> | routers got confused.
> This is a very harsh point of view. In real life, the customer pays
you to
> handle his traffic, and I can very well understand him wanting more
than
> one
> uplink to different providers, .. , in the ipv4 world this is very
normal.
> However, with IPv6, you (the provider) cannot simply handle any
traffic
> given
> to you by your customers. This breaks the multihomedness we know and
use
> in
> IPv4 networking.
> 
> About dual uplinks and load balancing. These are not layer3 decisions,
and
> can be taken care of at a lower level, eliminating the need of
disjunct
> sets
> of IPv6 addresses (eg, more than one prefix). Does anybody have info
on
> situations where a customer would want more than one AS to uplink to ?
And
> please look at the future when reasoning, not at the present IPv4
> situation.
> 
> groet,
> Pim
> --
> ---------- - -    - - -+- - -    - - ----------
> Pim van Pelt                 Email: pim@ipng.nl
> http://www.ipng.nl/             IPv6 Deployment
> -----------------------------------------------

------=_NextPart_000_004E_01C1A80B.A3DA8BC0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+IggTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAQAcAA4ANgAAAAEAOwEB
A5AGACwPAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA
AAAAHgBwAAEAAAATAAAAYXN5bW1ldHJpYyByb3V0aW5nAAACAXEAAQAAABYAAAABwag1i4uMpaKf
E2gR1riUAICtRmktAAACAR0MAQAAAB4AAABTTVRQOlJQRUFSU08xQFRBTVBBQkFZLlJSLkNPTQAA
AAsAAQ4AAAAAQAAGDgA8UIc1qMEBAgEKDgEAAAAYAAAAAAAAAMsvD0DCar8Rqe5irxiwMd3CgAAA
AwAUDgEAAAALAB8OAQAAAAIBCRABAAAAJQsAACELAAACFQAATFpGdUKNHioDAAoAcmNwZzEyNeIy
A0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2
MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFkMzYWUAumIFBobGVhFBAgGCAEYHaLHUAH
gCADUiB0aB1ACmQEAHQFEGJ1dGkJAiAgbB6hLiAgVNpoBAAgH/EeUjMLIB5AcQdxIEkgE+AdoR0g
a4MJgB+hSWYgbm8FQH0FoG0LUAiQILAD8B5QLNshEQPwbAMgGCBwF8EeQiMdMQeBc2FnB5FhIN5z
CrAeMADAAxAuCqIKhKcKgB/QAHBrcyYKLSfi+k8FEGcLgAdABdAkxCfjBSYERgNhOiBvd24ZBJAt
NgbgKmBASVOASS5FRFUgWyWymHRvOipPK1BdTwOglEJlE+BsIiBPZiYE3E1hAkAeYAfgTC2AA4Ev
JgQGYAIwKiBNAiBkYSp5I1BKAHB1CsB5IGwyOCNQAdAwFEAOIDr0MDQc4E0mZSvgHOAHcKQgdgOR
UGUrwDsGAppkMOBXI6EnFUNjKiAhBSBuZ0B1AwAtbecKUACADrByLgEAM3AqozEvRXViagWQL9FS
Rd8qIB0gBsAHgB7BYx1QCGDfHxA1ACYKNEUCIGMEkTixnR3AdSvABSAdACB1IrF7JvEeQG8egQEg
BJAvsSBScANgdmkEgXMzcHf7HmADoHkIYDswHTEeUSYEdncFsCCwYz3QK9AHgHLHI1IlgR0gc3Vt
OnI9kv8HgAORA5EvsSMgMOAjEjyHPx6AI/AJ8AEAAjAmBGFkzmQYIAQQOnIoUz8xPID8ZW87AiOT
IUM+9gQgQazXC4BCj0OWKSX7SQVAH/H/JUAigQRgA6AE8AnwCsAfIP07sncAcDx4HoEdoBQAQWL9
O8FnMLEgsCTwC3EesCYE9x7AAHJLiWYlwQhwHUAFsf87wQdwOwEHgDxhO/kG8A3g2wiQBCBiMOAU
EHI8wDow4SYEKGkuZR+gOgEOsL08YUQzQExCMOAHwHQ+oacnACNQHvBsazLgcx+g/wuANcEA0B8Q
HaFOMQEgDeAzI1AUIGMuSMYf02Rv3weRIkIUEB1wO7JiHUAfYA9AIA6wILE70ElQdjT7H6M8MScl
IkOQVnAFQB8xLx5QSdIv0CYEaAJAcDpoLy93XNAuCJAAMC6ZBbBnL1WTLCB0LVrzdHMvWvMtXRI1
YTrRNrYtWgBfRGgDcDixLTFQPyX1DNBHtSeFLmUmCj4gvyfvKP1jcCnkMrord3AHcMJANOIubmxd
YxYvr+EwvDc6NTYQwDIFY3B/MnIzn2NwNK81v2hUNwdl/zevOLdjcHFeb/BNcAsgOnP/UgEBkA6w
UHIEIB8xcD86kM8ucFnRbVAjUENoBRAesAMHMC81KEpPSU4pb2MWGCAdICrBZFv1Y3B8+iBjcFkH
kCNQKsEicTrA/yCwVpArwBKBB0ADIB7xHkHObx0xPJABEGl4JRM+9vshMAbwZFTTR7VjcB5RW2L/
btd5InxYHSA7smQwHdF6wlsf4jyXL3umH6BZPaFj7QBwJwVAAhByOjAhgGMWfz72eKo7wjvQeEBU
4QWQYX891HWxC4CC8QDAHxNAIGf/XGBY8gWghqA80UFBB0Al9T9xuGvEJOA80HiZivFJc6+CsluD
eBQ6cmYLYHcJgOY/EiB8ZiMxf8N7pBDA/x+hglIdAE3GhlF4qFZVHkF/OHGHcB+hjQgUQI3IB5FY
7SNQWUDxILBaY4B68z4mv1fygrF4qEtTPZI7wWsiQP8H4AGgOIGTkYXGHmBaogNQ/4ohhjQ9kj6g
grIfYCGwXAX/B3CIp3kgRDAjUD2SjvGQ1q+QV0GlkqaTU1kfoVMr0J5wk5AfolZkJgRaLHio7waQ
QPFpUSOTZ0sBm8V4QP8d0SJQWmE8h3mRRvEFQJkU96EomkmCUSdPkSJCgvJ1c3+gkHmyhSSggVuB
Z8GKa1f/hlIlgSEgQCBDw4zggkZZJP8eQ3unPZJ6wZaRO8F7Q3io/z2RBcBFmA6wI7Grg5bSjoT/
rXqqEiFDBGBPkYZBLzVuuf95IDwgCYAjUJNiHmKUtCE026wirkZlVBKnbFeuQiMgH1qhIkJ4ESOw
MOBCR1DfIwBE0TwxHkAHQGt1c67U/kl+M7dUBbB6IYywJgSCkf9jFnpVO0BpMA6wBCAeA1fw/ywQ
HrEdEB4wRZegsR/gE9D/QKNGEUTVIkEmBDhybteQZ/ehMh1wH6BCexE9QIZiIiD/HlI++Jy5LWAj
UBQQaSAnFb9WVWMWBbBkA3VjHgNCMuD/BzBzYl3xVJNEEJNiP5OOBd8k8AnBTXAr0AXAQVcoCfD/
YxYjdQuANyKQV1WRwSM2MNBCT05FhjRzYEB6Ev8iQoezQCMeA3Nwd5e/0hQA/4inH9OqEiJAH1AC
ICUABcD/WQEBkCGwA6CCkE+SIiBR8f+3YnukH2J6RX0kfkosIAmA87rXyZJDTFHgHSF6NnVzf3Zh
ghJaUXxIQaNa0QeQaf+w4ljiYxZf9rKhYxbNtUOh/0dQy8HJFh8iUWeTYlhEk3H9QfdBVkaPLyJy
B5C61x4S/8OYPUPf4Ff3Q3BMUR8QHTH+Qlqhe6fMdwEBhfArwOHo+wngYxZ6KsGIp7kRPJBV4v86
MCNQbYAdAAQRPZIBAB9g/1kATkCuMTDgAQCeUR5SVlf/RZojsCYExDJjFquDoJCTU3t6wpBoZTDg
OwEdIcGBZb86cgqwQ8EdotJhq2RieBH+a79lOsCCEdB7H/E9QDDg/yEg8hCREgVAc3FWkBQAUUL/
1CHMlR9kwaIhIKdiVTC3of8AwAEA4H9RUVWRerF4ETPB/Dstd4eKa6U/pk+nVR+w/kgdQB/x/Baa
ERQQLbBN1f5veKgKsPURBbHP9d50VHT/RHe+A6oSHpAYIMvBH+KQZv84gffmfnk8kUdQrXEMoOnB
fbLESM1AICV5sj1AhWF1vzwSIAEiIAcRSpAYIHcgAR/kMDtA/eN4qFfzTk9U/7PFHmFj8YeBO8GC
9JYFSrH/BnF1JxewnlBR0YXUmbZsZ/+K4AEGoSAiYoagl4Eh0PMu/yVAVBMV8kHR+RPTATzAFwD/
uPO28h9RsoAjUMJqAHInFfeWBGMWJtFkOxEDybLEISD/qhJUE4ywI7FtgIFi0lCy8v8ywUtSOnOw
0ffnusduuTtE9zu/PMQjUC6ekCNQZCD2A/9tMF/AubVbg/PBVBJ21PvQe4bRiJhILAC04sMlWeE2
7ZsUKKq033QpgoJYQ1Ai/xLSF5OggcSPY1JkELCQusf/HeHx0zDgrUzYcvPB8hMHVP/bGF3w6eG3
oZZ07aYO12Nwv2QgypdZ8cdmp4pjFkGW0/5kTRAZ0TtVk2Kr4ENw1wH/jJA6IP2z2JHkwdLC+9KM
kPp5XdAzQnHeMEPQdFBU0P9DFe2oqhLSL6iy0aG30Y7h/bCQbFbBWTLGJfYS1dLS8fuURalAam2A
3QDbx48AbGff0wEjwuRBQ5OdYShy4Glg/7DHeaN7pEjAU8AK0qCBbqD/ieFFQ4aSsVbbx06ATRCH
An/0ArfifDkB8HoSS1M9zEHWU1miHXg/dtRB7ajwFP8OIlUwdbH2EhEgQbBPkeNT/4vnaWDkE6qX
xDF1wl/AQR/3L9/dUArQdJ+nZhFjGGMb32OTk7GTwIrxT/MrT/xPZ/dNmWZIU55FZvJo4GdpFveb
XHlntC9TmzyDRGUCcH5vdKBosU7vWj9bT2T4fQFdEAAAAB4AQhABAAAAUQAAADxDMkEyNTY2OTZE
MTdFNDRDOUFEQzk1QTc3RkU5NTk5NzA1NUNDRkQwQHJlZC1tc2ctMDUucmVkbW9uZC5jb3JwLm1p
Y3Jvc29mdC5jb20+AAAAAAMACVkBAAAACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAAD
AAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAAFKF
AAC2dAEAHgAlgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAMAJoAIIAYAAAAA
AMAAAAAAAABGAAAAAAGFAAAAAAAACwAvgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADCA
CCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAMoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAA
AAAACwDVgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAACAfgPAQAAABAAAADLLw9Awmq/Eanu
Yq8YsDHdAgH6DwEAAAAQAAAAyy8PQMJqvxGp7mKvGLAx3QIB+w8BAAAAUQAAAAAAAAA4obsQBeUQ
GqG7CAArKlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcTXkgRG9jdW1lbnRz
XG91dGxvb2sucHN0AAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMENCMkYw
RjQwQzI2QUJGMTFBOUVFNjJBRjE4QjAzMUREMDQxNzE1MDEAAAAAAwAGEBf0uU0DAAcQdA0AAAMA
EBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABQTEVBU0VSRU1PVkVNRUZST01USEVESVNUUklCVVRJ
T05MSVNUVEhJU0lTVEhFM1JEVElNRUlIQVZFQVNLRURJRk5PVENPTVBMSUVEV0lUSCxJV0lMTFJF
UE9SVFRIRVNFTUVTAAAAAOsg

------=_NextPart_000_004E_01C1A80B.A3DA8BC0--
Previous message: asymmetric routing
Next message: asymmetric routing
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]