On Fri, Jun 10, 2016 at 10:50:17AM +0200, Job Snijders wrote:
> Hi All,
>
> On Wed, Jun 08, 2016 at 08:48:11AM -0400, Joe Provo wrote:
[snip]
> > It is useful to note that AS_PATH if often also involved on egress
> > decisions.
>
> You say 'often', but I don't recognise that design pattern from
>> One thing we do to reduce opportunistically hazardous vectors is to not
>> learn customer paths via peers.
> so I can't be a customer of you and a network you peer with?
> (I'm sure I got your meaning wrong)
sure you can. just don't expect packets from job's cone when your link
to him is dow
On 10/Jun/16 19:34, Leo Bicknell wrote:
> It does mean the provider creating the leak has already lost, but
> that doesn't mean it still isn't vital to protecting the larger
> internet. A good example of this is fire code. Most fire codes
> do not do much to prevent you from starting a fire in
On 10/Jun/16 19:19, Hugo Slabbert wrote:
>
>
> Unless it's mitigated by you accepting customer A's prefixes from any
> transits you have,
This.
Mark.
signature.asc
Description: OpenPGP digital signature
In a message written on Fri, Jun 10, 2016 at 10:50:17AM +0200, Job Snijders
wrote:
> You say 'often', but I don't recognise that design pattern from my own
> experience. A weakness with the egress point (in context of route leak
> prevention) is that if you are filtering there, its already too lat
On Fri, Jun 10, 2016 at 1:17 PM, Mark Tinka wrote:
>
>
> On 10/Jun/16 19:08, Christopher Morrow wrote:
>
>
>
> oh, so I didn't misunderstand.. that makes 'backup isp' less useful, no?
>
>
>
> With regard to reaching our network, not true. You would still be able to
> reach our network if your p
On Fri 2016-Jun-10 13:08:48 -0400, Christopher Morrow
wrote:
On Fri, Jun 10, 2016 at 1:05 PM, Mark Tinka wrote:
On 10/Jun/16 16:47, Christopher Morrow wrote:
so I can't be a customer of you and a network you peer with?
You can, but we won't learn your paths via the peering session w
On 10/Jun/16 19:08, Christopher Morrow wrote:
>
>
> oh, so I didn't misunderstand.. that makes 'backup isp' less useful, no?
>
With regard to reaching our network, not true. You would still be able
to reach our network if your primary service with us failed, but not via
a local peer.
Mark.
On Fri, Jun 10, 2016 at 1:05 PM, Mark Tinka wrote:
>
>
> On 10/Jun/16 16:47, Christopher Morrow wrote:
>
>
>
> so I can't be a customer of you and a network you peer with?
>
>
> You can, but we won't learn your paths via the peering session we would
> have with your other ISP.
>
>
oh, so I didn
On 10/Jun/16 16:47, Christopher Morrow wrote:
>
>
> so I can't be a customer of you and a network you peer with?
You can, but we won't learn your paths via the peering session we would
have with your other ISP.
Mark.
On 10/Jun/16 10:50, Job Snijders wrote:
> I second this. One of NTT's design principles is to be very strict in
> what we accept (e.g. "postel was wrong") at the ingress point. At the
> ingress point the route announcement is weighted, judged, categorized &
> tagged. This decides 99% of what hap
On Tue, Jun 7, 2016 at 2:35 AM, Mark Tinka wrote:
> One thing we do to reduce opportunistically hazardous vectors is to not
> learn customer paths via peers.
>
so I can't be a customer of you and a network you peer with?
(I'm sure I got your meaning wrong)
Hi All,
On Wed, Jun 08, 2016 at 08:48:11AM -0400, Joe Provo wrote:
> On Wed, Jun 08, 2016 at 11:48:36AM +, Sriram, Kotikalapudi (Fed) wrote:
> > Thanks for the inputs about the inter-AS messaging and route-leak
> > prevention techniques between neighboring ASes. Certainly helpful
> > informati
messaging for route leak prevention
On 8/Jun/16 14:48, Joe Provo wrote:
>
> "There are more routing policies in heavan and earth, Sriram
> Than are dreamt of in your draft."
>
> But in my experience, community tagging is by far the widest
> deployment due to the
On 8/Jun/16 14:48, Joe Provo wrote:
>
> "There are more routing policies in heavan and earth, Sriram
> Than are dreamt of in your draft."
>
> But in my experience, community tagging is by far the widest
> deployment due to the broad support and extent of information
> which can be carried.
On Wed, Jun 08, 2016 at 11:48:36AM +, Sriram, Kotikalapudi (Fed) wrote:
> Thanks for the inputs about the inter-AS messaging and route-leak prevention
> techniques between neighboring ASes. Certainly helpful information and also
> useful
> for the draft (draft-ietf-idr-route-leak-detection-mit
Thanks for the inputs about the inter-AS messaging and route-leak prevention
techniques between neighboring ASes. Certainly helpful information and also
useful
for the draft (draft-ietf-idr-route-leak-detection-mitigation).
However, my question was focused on "intra-AS" messaging.
About conveying
On 6/Jun/16 17:54, Job Snijders wrote:
> There is the "human network" approach, where operators share information
> with each other which be used to generate config to help block
> "unlikely" announcements from eBGP neighbors.
>
> For instance AT&T and NTT agreed (through email) that there shoul
On Mon, Jun 06, 2016 at 05:54:18PM +0200, Job Snijders wrote:
> On Mon, Jun 06, 2016 at 11:41:52AM +, Sriram, Kotikalapudi (Fed) wrote:
> > I am a co-author on a route-leak detection/mitigation/prevention draft
> > in the IDR WG in the IETF:
> > https://tools.ietf.org/html/draft-ietf-idr-route
On Mon, Jun 06, 2016 at 11:41:52AM +, Sriram, Kotikalapudi (Fed) wrote:
> I am a co-author on a route-leak detection/mitigation/prevention draft
> in the IDR WG in the IETF:
> https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03
>
>
> Question: Are there other mean
I am a co-author on a route-leak detection/mitigation/prevention draft
in the IDR WG in the IETF:
https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03
Based on private conversations with a few major ISPs, the following
common practice for intra-AS messaging (using Commu
21 matches
Mail list logo
