Subject: [Idr] 4-byte AS community encoding (was re: wide communities)

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Jul 2010 08:11:10 +0000

WG,

My apologies for the confusion about this draft during the presentation on
wide communities.  The following draft apparently became orphaned while we
were trying to figure out what WG to get to adopt this - IDR or l3vpn.

http://tools.ietf.org/html/dhrao-idr-4octet-extcomm-generic-subtype-00

I believe this is a somewhat less contentious encoding for generic
communities that are capable of containing 4 byte ASes.  Since I was also a
contributor to the flexible community draft I believe that functionality is
also useful, but if the primary goal is to get a 4-byte AS capable
community, we offer this as a potential solution.

I would like propose to the WG the following:
- Adopt the above draft as a generic encoding of 4-byte communities.
- Continue the exploration of solutions for the additional functionality
  covered by wide communities and the flexible community document.

I don't believe the flexible community authors are overly concerned about
our specific encoding mechanisms for the additional functionality covered by
the two different drafts.  However, I'd suggest continuing that discussion
separately from 4-byte AS communities.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 26 Jul 2010 15:39:14 +0200

Jeff,

I was aware about the below draft, but it's proposed encoding has few 
serious disadvantages as compared with the encoding in Wide BGP 
Community draft.

Let me list those:

1. It uses extended community type of extended communities rather then 
regular type - the consequence of this deep nesting is loosing one octet 
of action field which may be of real value. Today I have two uses of 
actions and today I have heard comments proposing additional value about 
drop flag at AS boundary even if it is supported.

2. This draft is based on RFC 5668 4-Octet AS Specific BGP Extended 
Community which explicitly says in it's section 3:

    Therefore, for backward compatibility with existing deployments and
    to avoid inconsistencies between 2-octet and 4-octet specific
    extended communities, Autonomous Systems that use 2-octet Autonomous
    System numbers SHOULD use 2-octet AS specific extended communities
    rather than 4-octet AS specific extended communities.

But regardless of this mandate text of the RFC the draft in it's current 
form still tries to use it for both 2-octet AS and 4-octet ASes. To 
follow RFC 5668 and base BGP communities encoding on it we would still 
use standard BGP communities for 2 octet ASes and this extended 
community of extended type for 4 octet AS.

I find it much cleaner to define a new regular type and propose clear 
semantics allowing for 4 octets and 2 octets ASes to be encoded.

Also last but not least the draft 
dhrao-idr-4octet-extcomm-generic-subtype does not define a notion of AS 
specific communities which clearly may have good applications even at 
customer-ISP boundary.

Thx,
R.

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Jul 2010 14:42:39 +0000

> serious disadvantages as compared with the encoding in Wide BGP  

For what it's worth, I happen to agree with your comments below, but we do
not consider these to be disadvantages.

> drop flag at AS boundary even if it is supported.

The scope of this draft is meant to provide feature parity with RFC 1997
and company.  As I mentioned in the original e-mail, I find the additional
features of wide communities and flexible communities to have merit.
I also think we could use a simple and quick to deploy feature that provides
for the 4-byte AS representations of these generic communities.

I believe that the work on wide/flexible communities should proceed
simultaneously.

Given our perceived requirements we don't consider the loss of an octet to
be important.  See also below.

> community of extended type for 4 octet AS.

We agree. :-)

We consider the use of this functionality as a way to utilize existing
code.  Very importantly, we are *not* trying to invent a completely new way
to encode communities.  In my opinion, not speaking for all of the
coauthors, this increases the likelihood of having this feature deployed by
a number of vendors in short order.

You are correct in that a set of 2 communities, one with a 2-byte AS and one
with a 4-byte AS would result in a RFC 1997 community and an extended
community.  On the wire encoding isn't terribly important as long as the
semantics are clear for overlap.

> specific communities which clearly may have good applications even at  

That is not its intended purpose.  Again, see my original comment about
proceeding with the additional functionality work covered by wide and
flexible communities.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Jul 2010 15:56:02 +0000

> proceeding with the additional functionality work covered by wide and

It was suggested to me off-list that I may have misunderstood what you meant
by "AS specific communities".  Could you clarify?

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 26 Jul 2010 19:10:36 +0200

Hi Jeff,

Putting flexible communities aside I really see very little development 
difference in providing support for the quoted draft encoding vs wide 
BGP community encoding.

It is just wide BGP community seems more flexible and less nested then 
what has been proposed in yr draft with the exact same parsing/matching 
simplicity in both. That is assuming that we are just talking about 
simple customer assigned local values.

I see no particular value of having customers forced to go via any 
intermittent step :).

And as discussed at the meeting today for that very purpose decoupling 
encoding from filling the registry for the actual recognized values 
seems a wise idea.

So what I propose we could do two things .. merge the drafts or have 
customers and WG pick the more preferred one :) I will split my current 
one and re-post after IETF and let's then resume the conversation.

What do you think ?

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 26 Jul 2010 19:23:05 +0200

Hi Jeff,

> by "AS specific communities".  Could you clarify?

With pleasure  ...

I meant when AS number carried in the community is not to just indicate 
like in original RFC 1997 the AS number who inserted given community. It 
is to indicate the AS on which given community is to be executed.

Example:

I am a customer and you are ISP. You are peering to upstream A and B. I 
am paying you for my transit but really would like to avoid going via 
your upstream A.

The simplest thing to accomplish this is for me to inject a A:Prepend 
what would mean that when you advertise my prefix(es) to ISP A and B you 
will prepend your AS few times when advertising it to ISP A and not B.

I really have live networks asking for such ability today as the only 
way to achieve this currently is via manual operational policy on the 
peering points for you as my provider if you are to continue to be my 
provider :).

Cheers,
R.

---

From: Richard A Steenbergen <[email-masked]>
Date: Mon, 26 Jul 2010 12:38:47 -0500

On Mon, Jul 26, 2010 at 07:23:05PM +0200, Robert Raszuk wrote:
> what would mean that when you advertise my prefix(es) to ISP A and B 
> you will prepend your AS few times when advertising it to ISP A and 
> not B.
> 

Robert,

Are you suggesting that this be supported automatically, i.e. the router 
would know it is peering with AS "A" and honor A:Prepend without the use 
of a route-map/policy-statement going "if from A:prepend then prepend"? 
Or just that there be a specific type/namespace reserved for "target" 
communities affecting a specific ASN?

-- 
Richard A Steenbergen <[email-masked]>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 26 Jul 2010 23:27:57 +0200

Hi Richard,

Clearly I would not think that automatic surprise after reload with new 
software is a wise thing to do.

I would see such behaviour to be enabled either exactly as you say by 
specific new specific type/namespace in the existing outbound policy 
(without the need for extra match clauses) or enabled by other command 
outside of current policy.

A bit unrelated but another point reg registered communities is that 
their values as currently defined in ranges of values do quite 
efficiently simplify selective drops of some groups of them.

Many thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 Jul 2010 07:17:45 +0000

Robert,

> is to indicate the AS on which given community is to be executed.

Thanks for the clarification.

Again, this is not the intention of our draft.  It is meant to achieve
parity with RFC 1997 functionality. 

I agree that AS-targeted functionality is useful and is a good piece of
functionality for wide or flexible communities.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 Jul 2010 07:30:22 +0000

Richard,

> communities affecting a specific ASN?

One of the things that came out of the last round of the flexible
communities discussion with operators was exactly your opinion: We don't
want to force operators to accept new "magic" policies via community.

It was suggested during the routing area general meeting that drafts should
have a managability considerations section recommending appropriate
configuration knobs for deployment of such our features.  Such a section
would belong in either of our proposals.

An example, a control knob of "permit/do not permit the localpref
modification community" should be recommended in the managability section of
these documents. 

I believe our mutual goal is to provide a more standardized way to implement
common policies that are implemented with communities.  A non-goal was to
force a provider to expose such knobs to their customers.

-- Jeff

---

From: "Robert Raszuk (raszuk)" <[email-masked]>
Date: Tue, 27 Jul 2010 00:44:16 -0700

Hi Jeff,

Ok so we have this one clear :). But even for parity with 1997 I see no reason to so deeply encode it as extended type of extended community. 

Deploying this then deploying something else will IMHO just generate more confusion then bring any value. I think that proceeding with both encodings forward essentially one being a subset of the other one should be avoided.

Many thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 Jul 2010 07:58:50 +0000

Robert,

On Tue, Jul 27, 2010 at 12:44:16AM -0700, Robert Raszuk (raszuk) wrote:
> Ok so we have this one clear :). But even for parity with 1997 I see no
> reason to so deeply encode it as extended type of extended community. 

The base extended type we're using is straight from RFC 5668.  Again, this
helps us leverage code that already knows how to parse the contents of the
community.  Making this a regular type would just mean that we have one
octet that would be the usual boilerplate "should be zero on transmission
and ignored upon receipt" and probably continue to use the RFC 5668 parsing
code path. 

I really don't see the objection to regular vs. extended.  Extended subtypes
to date have suggested format and semantics.  This draft leverages a
pre-existing format.

> Deploying this then deploying something else will IMHO just generate more
> confusion then bring any value. I think that proceeding with both
> encodings forward essentially one being a subset of the other one should
> be avoided.

By the same argument, the fact that 2-octet RFC 1997 communities can be
embedded in either wide or flexible communities also creates similar
confusion that should be avoided.

On this, we perhaps must agree to disagree.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 Jul 2010 08:03:26 +0000

> one and re-post after IETF and let's then resume the conversation.

With regards to flexible communities, Andrew and I have discussed splitting
the draft into a structural draft and a features draft.  The first will
cover packet format and general implementation semantics.  The features
draft will cover the "magic" communities that are encoded using the first
draft.

I would suggest that a similar effort for wide communities would be
similarly helpful.  This will let us focus on packet and general semantics
of the extension separately from the individual community features.

-- Jeff

---

From: Richard A Steenbergen <[email-masked]>
Date: Tue, 27 Jul 2010 04:10:52 -0500

On Tue, Jul 27, 2010 at 07:30:22AM +0000, Jeffrey Haas wrote:
> 
> It was suggested during the routing area general meeting that drafts 
> should have a managability considerations section recommending 
> appropriate configuration knobs for deployment of such our features.  
> Such a section would belong in either of our proposals.
> 
> modification community" should be recommended in the managability 
> section of these documents.
> 
> I believe our mutual goal is to provide a more standardized way to 
> implement common policies that are implemented with communities.  A 
> non-goal was to force a provider to expose such knobs to their 
> customers.

So, let me take a moment to throw in my two cents as an operator who has 
implemented a (IMHO) robust bgp community system. I very much support 
extending the community mechanisms in place today, particularly when it 
comes to taking advantage of the type field in extended communities to 
add new message types and try to avoid namespace conflicts. If you look 
at the common community systems out there, most messages can be 
categorized as either informational (i.e. I'm telling you something 
about this route, such as where I learned it, etc), or action (i.e. 
you're telling me to do something with this route, such as no-export or 
alter its attributes in some way). This leads to a conflict over who is 
using the first field and for what purpose, and people doing arbitrary 
things like declaring "65001:$ASN" to mean "prepend to $ASN once". By 
using that extra type information to extend concepts like "origin" and 
"target" to general Internet use, I think you could really make the 
messages a lot more flexible without consuming any additional space 
beyond what is already required.

But, I'm not convinced that it really makes sense to try and predefine 
any of the "complex" messages. For starters, consider an action item 
like "do not export". You might be able to make a well known community 
for it, but what happens when you want to support "do not export to 
peers in north america"? I don't believe you can reasonably define a 
common enough set of actions which will work for everyone, and even in 
my example above there are peers who would consider that type of 
location specific action a breach of consistent announcement peering 
requirements. And if you can't reasonably expect every operator to be 
able to support every message type, you've still got to consult some 
type of reference to figure out what is and isn't supported, so what is 
the advantage of defining well known messages for them in the first 
place?

Another major flaw in the design of the predefined communities in the 
Raszuk draft is how they are broken up into discrete chunks (i.e. one 
community for "from peer", another community for "from customer", etc). 
Besides not logically preventing duplicate/conflicting tag, I'm not 
aware of any router vendor who lets you do any useful match logic across 
two tags like this. For example consider the match "customer routes not 
learned in north america", the ONLY way this can be implemented today is 
with a regexp across a single tag (where a common implementation is a 
digit per field of info), it can't be done across two tags. This is why 
people will frequently design their informational tags to fit into a 
single 5 digit wide field, and put the action tags into smaller chunks. 
If one of you guys is feeling motivated, I've been asking for "from 
community (A && !B)" type policies for ages, but without it these 
predefined communities are effectively unusable.

As an operator I make extensive use of other networks' communities all 
the time, but honestly I don't see the value of having any of these 
communities predefined. Simple stuff like "no advertise" that actually 
CAN be implemented automatically is the only thing that makes sense. I 
can count the number of networks who support the NOPEER community on one 
hand, even though a very large percentage of them have their own 
internal community for the same functionality, because there is no way 
to support it automatically and it's too weak a construct to bother 
supporting on a standardized basis.

IMHO the best way to improve communities would be to widely implement 
programatic constructs like "$neighbor:data" in router policy languages, 
rather than spend time predefining a set of standardized communities no 
one will ever use. For an example of a real world community deployment 
and some of these design considerations, take a look at the NANOG 
presentation by Tom Scholl and myself from a couple years ago:

http://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf

Today we're implementing these edge policies using Juniper cmmmit 
scripts to build the (relatively) complex regexp and policies to support 
per-ASN communities for every peer automatically. But what makes sense 
for me probably doesn't make sense for another network of a different 
size and scope, and I'd be very hard pressed to come up with a single 
system that would. Reading through this list of predefined examples, I 
believe all of them are best left to be implemented by the individual 
operator via a powerful policy language. And if your router doesn't have 
a powerful policy language, fixing that is FAR more important than ANY 
of these predefined communities.

My opinion at any rate. :)

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 27 Jul 2010 07:52:18 -0400

This is a high beam of enlightenment through murky waters.
Other operators please also share.

--
Jakob Heitz.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 Jul 2010 13:57:23 +0200 (CEST)

> Other operators please also share.

What kind of information are you after? More of the same Richard posted, 
or something else?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 Jul 2010 11:58:54 +0000

> Other operators please also share.

RFC 1925, secs. 2.4 and 2.12.  I'd rather build a feature that people want.
:-)

-- Jeff

---

From: John Scudder <[email-masked]>
Date: Tue, 27 Jul 2010 05:01:47 -0700

> What kind of information are you after? More of the same Richard posted, 

IMO even if folks are just posting me-toos to Richard's message, that's valuable (although if you have a different or elaborated perspective to share, by all means please do).

--John

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 Jul 2010 14:25:01 +0200 (CEST)

On Tue, 27 Jul 2010, John Scudder wrote:

> IMO even if folks are just posting me-toos to Richard's message, that's 
> valuable (although if you have a different or elaborated perspective to 
> share, by all means please do).

Oki, let's give this a shot by describing a real-world problem that I 
don't currently have a solution to (so it works so-so):

We have a /24 with an IRC server. IRC servers are DDoS magnets. We 
therefore "limitcast" this /24 only regionally (we'd like it to stay 
within Sweden if possible), but with the international nature of things it 
ends up in more places. Some people in Sweden sit behind european major 
international players as their upstream, and we don't really want to 
announce it to them because they spread it all over, so we don't announce 
it to them at all. They use uRPF loose and since this /24 is not in their 
routing table, if traffic (due to asymmetric routing it gets to us another 
path) is sent to them they'll drop it because the source address is not 
in RIB/FIB for them so uRPF check fails.

There thus is a need for a prefix to be announced to peers as "this is in 
use so allow it to source traffic, but please don't put it in FIB". Having 
a policy framework that is actually industry wide standard might help with 
this. I'm not sure IDR is the place to do it, but there definitely would 
be an upside if it would be used more.

We also have the problem with this same prefix being announced as 
"NO-EXPORT" to peers (because we don't want them to spread it too far) but 
that also means their customers won't get it. We'd like to be able to 
control this more granuarily, which also implies more global policy 
coordination.

---

From: Richard A Steenbergen <[email-masked]>
Date: Tue, 27 Jul 2010 15:04:09 -0500

On Tue, Jul 27, 2010 at 02:25:01PM +0200, Mikael Abrahamsson wrote:
> 
> There thus is a need for a prefix to be announced to peers as "this is 
> in use so allow it to source traffic, but please don't put it in FIB". 
> Having a policy framework that is actually industry wide standard 
> might help with this. I'm not sure IDR is the place to do it, but 
> there definitely would be an upside if it would be used more.

If you don't have a forward path to it, why does it matter if the packet 
is dropped for uRPF violation or destinaiton unreachable?

The one community from this list which I absolutely would support as a 
well known standardized community is the global blackhole. This meets 
the test of being supportable automatically on every router, and is 
widely useful. IMHO if someone has the ability to announce a route and 
have that route accepted and used for forwarding, they should also have 
the ability to have that traffic dropped. They already have complete 
control of that traffic after it gets forwarded to them anyways, the 
only difference is that the traffic can be dropped before it saturates a 
link to them. The only other thing I might suggest to make everyone's 
lives easier is an ICMP unreachable message which indicates that the 
traffic was dropped because of a blackhole community, and possibly some 
information about the route that triggered it such as the AS-PATH. 
Remember there are a lot of people out there without access to BGP data, 
and it isn't immediately clear who to blame/contact when you traceroute 
to $DoStarget to figure out why you can't get on IRC, and the packet 
gets dropped by your ISP.

---

From: john heasley <[email-masked]>
Date: Tue, 27 Jul 2010 20:19:58 +0000

> the ability to have that traffic dropped. They already have complete 

As you know, many ASes do not prefix filter their customers (or any of
their BGP peers).  This could easily be abused without some form of S-BGP;
though such a feature is interesting.

Similarly, not applying some form of packet filtering to customer interfaces
is the origin of Mikael's problem.  yes, i am ignoring the inability of some
platforms to handle such filtering - hardly seems like a valid excuse though.
 
we'll resist any "community feature" which we can not ignore or override.
anything which obligates a service or limits autonomy from another's
business or technical policy.

but, good ideas, Ras.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 Jul 2010 22:21:59 +0200 (CEST)

> is dropped for uRPF violation or destinaiton unreachable?

Just because YOU (being an intermediary) don't have a path to the src of 
the packet you're receiving doesn't mean the final recipient of the packet 
doesn't have another path to get the packet to that IP.

    /-  C  -\
A -         -D
    \-  B  -/

D (irc server ISP) has outgoing path to all of the Internet, but only 
announces the prefix to B, but prefers C to reach A. If C has uRPF enabled 
then packets which goes A->B->D are responded via D->C(->A) but C drops 
the packets because of uRPF failure (because C doesn't get the prefix from 
D).

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 27 Jul 2010 22:26:25 +0200

> (because C doesn't get the prefix from D).

Isn't for C passing return traffic uRPF check src is A and not D ?

Thx,
R.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 Jul 2010 22:29:55 +0200 (CEST)

> Isn't for C passing return traffic uRPF check src is A and not D ?

No, traffic flows A->B->D and D->C->A (and the last fails because of lack 
of prefix in C RIB).

So packet sourced in D with dst A is dropped by C because D address isn't 
in C RIB.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 27 Jul 2010 22:33:42 +0200

Richard,

> widely useful.

Many thx for your opinion. I really agree that in the lack of wide 
flow-spec deployment which Pedro Marquess and I have defined in the past 
using a blackhole community is an only alternative.

Other also supported this one as well as AS specific prepends. So while 
decoupling every other registered community with agreement on the list I 
will tend to provide those two as examples what IANA registry should list.

Any objections from real network operators to both of those as part of 
encoding draft are welcome.

Thx,
R.

---

From: Richard A Steenbergen <[email-masked]>
Date: Tue, 27 Jul 2010 16:13:43 -0500

On Tue, Jul 27, 2010 at 08:19:58PM +0000, john heasley wrote:
> their BGP peers).  This could easily be abused without some form of 
> S-BGP; though such a feature is interesting.

Lets say that I decide today that I'm going to originate an abusive BGP 
announcement and blackhole a lot of traffic, and my upstream isn't 
filtering me, and their upstream/peers aren't filtering them. What is 
the difference between making a regular announcement and blackholing the 
traffic myself, vs using a community tag to blackhole the traffic? I see 
exactly two differences:

1) I could potentially kill a lot more traffic via a blackhole community 
than I could absorb without overloading and killing my network, if I had 
a network with limited ingress capacity. But I could still do plenty of 
damage with a 180 sec hold-timer if you're willing to accept and install 
my prefix, and infact I could probably do more long-term damage by 
flapping the hell out of the prefix and getting it dampened.

2) By having the blackhole applied somewhere other than on my network, 
end users and people without access to BGP data (and btw that doesn't 
necessarily mean people who don't know anything about BGP, it could be 
an internal route that isn't exposed via a looking glass or advertised 
to the person looking) wouldn't be able to tell what was happening. This 
is why I suggested an ICMP unreachable message to encode some extra 
details.

The bottom line is if I can get you to accept my bogus announcement you 
are already boned, and while SBGP may be a good idea in its own right, I 
don't think it is a requirement for a blackhole community.

> we'll resist any "community feature" which we can not ignore or 
> override. anything which obligates a service or limits autonomy from 
> another's business or technical policy.

Of course, I wouldn't suggest otherwise. By all means there should be a 
per-router and per-route "ignore" option for blackhole communities, and 
I'm sure you know how to delete communities in policy.

---

From: Richard A Steenbergen <[email-masked]>
Date: Tue, 27 Jul 2010 16:47:49 -0500

> using a blackhole community is an only alternative.

Well if it makes you feel any better, we use flowspec extensively and 
love it, and I wish more vendors supported it. :)

> Other also supported this one as well as AS specific prepends. So 
> while decoupling every other registered community with agreement on 
> the list I will tend to provide those two as examples what IANA 
> registry should list.

Hrmmm ok AS-specific prepends I'm on the fence about. Really my issues 
are with the completely unsupportable communities, like:

a) informational tags which won't fit most networks, which can't be used 
because existing policy languages can't evaluate them in a constructive 
way, and which would be a hassle to maintain on top of existing info 
tags.

b) action tags which rely on entirely political tags like "customer" 
"peer" "upstream" etc, which can't possibly be implemented 
automatically. If it can't be supported automatically, and I have to 
write a policy for it and then tell customers whether they can or can't 
use it, I might as well have just done it with a proprietary tag in the 
first place (where it could have been tailored to fit my exact needs).

c) action tags which can't be made to fit most networks, such as a 
handful of "localpref +/- 20" communities applied to a value which has a 
range of 0 to 4 billion. :)

This isn't a complete replacement for proprietary community policies of 
course, since you can't support things like "prepend to peers" or 
"prepend to AS1234 in north america", but global per-ASN prepends should 
at least be reasonable to implement and support automatically. The same 
argument applies to AS-specific no-advertise too.

---

From: John Kristoff <[email-masked]>
Date: Tue, 27 Jul 2010 17:25:14 -0500

On Tue, 27 Jul 2010 22:33:42 +0200
Robert Raszuk <[email-masked]> wrote:

> flow-spec deployment which Pedro Marquess and I have defined in the
> past using a blackhole community is an only alternative.

It would have been preferable to have made flow-spec a non-transitive
attribute.  This would make it more amenable for this type thing.

John

---

From: Andrew Lange <[email-masked]>
Date: Tue, 27 Jul 2010 17:59:55 -0700

Jeff,

I have to look over the encoding in this draft and Roberts (in detail) before I can commit to not having a preference.  I'll refresh the flex-comms draft, so there is a current one in the repository, so we can collectively look at it.

Andrew

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 Jul 2010 07:21:06 +0000

> business or technical policy.

Just to reinforce that "we're not trying to shove new communities down your
operational throats", I think all of the authors of all of the drafts agree
with you whole-heartedly. :-)

The drafts are intended to provide standardization.  At the same time
the drafts provide  implementation guidance to letting such knobs be shut
off on a per-class basis.  

Once we've all gone another round of clarification, if the appropriate text
for such a thing is not strong enough, please raise the issue on the list.

-- Jeff

---

From: Kristian Larsson <[email-masked]>
Date: Sat, 31 Jul 2010 01:45:06 +0200

> is dropped for uRPF violation or destinaiton unreachable?

There is a forward path for it. Some "helpful" operators leak the
prefix to those who need it, and since the traffic volumes are
generally not that large it's not a problem. We however route the
return traffic over some larger player who drop the packets due
to uRPF.

> gets dropped by your ISP.

Agreed.
 
  -K 

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511			              [email-masked]