Hello Camilo, Since it is getting cluttered my responses inline begin with "[Rick]".
------------------- Cheers, Rick Experiences not things. On Fri, Feb 13, 2015 at 7:01 AM, Camilo Cardona < [email protected]> wrote: > Hello Rick, > > Thanks for your feedback, some more answers inline. > > Camilo Cardona > > On 12 Feb 2015, at 18:58, Rick Casarez <[email protected]> wrote: > > Hello Pierre, > > With the hope of not cluttering it up too much I will also respond in line. > > > ------------------- > Cheers, Rick > > Experiences not things. > > On Thu, Feb 12, 2015 at 12:15 PM, Pierre Francois < > [email protected]> wrote: > >> >> Hello Rick, >> >> Please see my comments inline. >> >> On Feb 12, 2015, at 8:18 AM, Rick Casarez <[email protected]> wrote: >> >> I checked the history of the document but did not see this so forgive me >> if these were discussed before. >> >> >> >> No problem. Thank you for your interest and time spent on giving us >> feedback. >> >> >> >> In section 2.2.1: In the scenario and figure listed I am having trouble >> finding what the issue is. The forwarding is following the exact path the >> end AS wants based on policy so I am not sure how this is unexpected. >> >> >> >> The issue is not on the end AS side, the end AS is happy with the >> situation. >> The issue is that AS64502 configures bgp to not provide connectivity >> between 64503 and 64504, (typically because they both are peers and 64502 >> does not want to provide a free ride on its network), >> and yet, it does so due to the game going on. >> >> Ah, I see where you are going with it now although I think you meant > AS64505 which is the Peer AS and not customer AS (64504). > > While I understand it I am still somewhat confused. Since AS64505 does not > have a connection to AS64501 it will still use 64502 as a transit AS to get > to the destination AS (AS64501). So the problem is not the usage of AS64502 > as a transit AS (Since that still occurs if the /34 is withdrawn), nor is > it that the routing shown is unexpected given the prefix being leaked and > the limitations of propogation set by the originator. It is the fact that > the traffic-engineering being done by AS64501 may impact the interconnect > or Peering policies between AS64502 and AS64503 adversely. This would > especially be important if as part of the Peering relationship between > AS64502 and AS64503 there is a ratio requirement or the interconnect is > already running near peak. > > > We indeed considered that AS64505 could receive the prefixes from other > connections besides the one to AS64502. We will add this clarification to > the document (we removed it at some point by mistake, probably to make the > figure less dense). > > Perhaps instead of "unexpected routing" it should be "adverse effects of > this type of routing". I would even posit that the word "unintentional" > might also be added since most peering agreements are locked under NDAs and > the originator AS64501 might not know he is having an impact or even the > nature of the relationship between AS64502 and AS64503 legally. > > > We used "unexpected flows" after discarding a few others adjectives, > including “unintentional" and “undesired". After discussing it in the group > and in the ietf, we kept the term, as these flows are not expected by the > operators, since their BGP policies are designed to avoid them. > > > >> >> Now if you were to shift AS64505 so that it dual homed to both AS64502 >> AND AS64503 you can demonstrate a scenario of inefficient (and unexpected) >> routing if I am reading the figure correctly. Since AS64505 only sees the >> /32 from both AS upstreams from AS64501 but its algorithm selects AS64502. >> We know that AS64502 forwards to AS64503 and then on to the originating AS >> (AS64501). This is inefficient since AS64505 has a direct connection to >> AS64503 it could have saved an AS hop (and consequently line/equipment >> induced delays) by going direct to that AS had the /34 prefix been allowed >> to propagate further. >> >> >> The very first time we presented this case, we've been invited by an >> operator telling us the following story: >> >> "It happened to me". >> >> (I put it in context of figure 2.1.1). >> >> Transit to 64502 is expensive and 64501 tends to use its link too much. >> 64503 is not expensive, nice capacity, and some common business interests >> with 64501. >> >> 64502 has much better reach to 64504 than 64503 (capacity, delay), >> because 64503 uses 64505 to reach 64504 and well, 64505 is not the best >> transit network ever. >> So 64503 and 64502 have both interest in having the trick path followed. >> >> so, to summarize: >> >> 64501 - 64502 - 64504 : best path but expensive and transit link to 64502 >> tends to saturate on rainy days. >> 64501 - 64503 - 64505 - 64504 : the other path 64501 could pick, but it's >> not a nice one, 64505's reach to 64504 is not good. >> >> The config trick leads to the following path being established >> >> 64501 - 64503 - 64502 - 64504 : Same length as the alternative in AS >> count, but much much better reach. >> >> Problem: 64502 does not make a single dime on the flows following that >> path. >> >> Message of the draft for operators: it's >> complicated/inefficient/dangerous to defend against this actively, so >> adding some checks in monitoring tools, and interaction with customers and >> peers is probably the way to go… >> >> Let the problem take place and fix it. Some do not like this but well, >> not many like the proposed alternatives. >> >> > I agree with the problem statement for sure. That is the risk when doing > settlement-free interconnects. It is also one of the main reasons some ISPs > made settlement-free peering requirements so high or did away with it > altogether and do 'Paid Peering' instead. I am not sure if either of those > are within the scope for this document but those are alternative actions > that can be taken as well. In addition to turning down the Peer if they > violate their agreement. Those are really business decisions though. > > > Well, it will certainly depend on how often these problems happen. The > main point of the document is to warn operators to monitor and detect these > cases. They can then make business decisions, such as the ones you suggest, > based on their impact on the network. > > > >> >> Section 3.2: I am not sure I agree with this statement especially the >> abuse part: >> >> "This situation may appear as an abuse to the network resources of other >> ISPs." >> >> The section says this then goes on to explain all the valid reasons to >> create unexpected traffic flows. There is no example of an "abuse" >> situation. I am also at a loss on how anyone would think it "appears like >> an abuse of resources" when the previous sections outline plenty of real >> reasons these types of announcements are done. Prefix hijacking I can >> understand as an abuse but that is not discussed here. Can someone explain >> the abuse sentence to me? >> >> >> >> Because good reasons to some (64501 and 64503) leads to a money loosing >> situation to another (64502). >> >> > That is not abuse though. > > > We don’t say it is abuse, we say that it “may appear as an abuse” to > external AS. The message of that sentence is to recommend AS performing the > filtering to be careful about it. > > [Rick] Even mentioning 'abuse' to me triggers certain thoughts related to real abuse scenarios. Using smaller prefixes for traffic-engineering has been around for a very long time. I am also concerned that this seems to be ISP-centric in its evaluation. It seems to be a viewpoint from an ISP that is sore about losing some revenue because a customer is smart enough to do this type of traffic engineering. So while I see your point I guess we can respectively agree to disagree about that term being there and I will drop it. > > If we do one of the solutions and force routing back to 64502-64501 then > you reverse your statement above. By that definition it is still abuse but > now abuse by 64502 (Gains revenue back) against 64503 (Loses revenue) and > 64501 (Overrides originating AS traffic engineering). Especially if 64503 > is following the peering agreement agreed two by the two network entities > and passing along valid NLRI with valid attributes that 64502 is accepting > (and as demonstrated acting upon said attributes). > > By tweaking the scenario and adding a different /34 from the same /32 > being sent to AS64502 and not AS64503 with the same type of attributes > (Only advertise to AS64503 and nowhere else) we would by definition now > see "abuse" by AS64501, AS64502, and AS64503? It is not abuse though but > normal traffic engineering that has be done for a long, long time. > > When I think abuse I think of prefix-hijacking and spam. Traffic > engineering really should not fall under the same label. If 64502 feels > that either network (64503 or 64505) is abusing the peering/customer > agreements then the solutions would fall under a business/legal framework > between those companies. It would appear obvious a re-negotiation is in > order. > > > Exactly! There is no perfect solution. > I think we are in line here. The document states that solutions that lead > traffic to go directly from AS64502 to AS64501 might "generate conflicts > between AS64502 and AS64501, since AS64502 does not follow the routing > information expressed by AS64501 in its BGP announcements." > > Section 4: If I understand this correctly the originating AS has made a >> traffic engineering decision based on its internal policies but the >> upstreams should actively try to counter it? I am not sure I agree with >> Section 4 in almost its entirety. All the solutions listed seem to be a >> list of bad ideas except for the very first suggestion of contacting the >> originating AS to find out why they are doing it and if it can be stopped. >> >> >> >> This is our point. Our submission to GROW had the goal of discussing the >> best operational practice to solve the problem. >> >> With time, we often heard "yeah but just do that and you're good". As, >> very much like you, we were not really agreeing, we preferred to discuss >> why and document it. >> >> > For this scenario the technical solutions add snowflakes into a > standardized network and as you even pointed out now have to be maintained > and updated periodically every time the originating AS adjust to overcome > them (or just make a change without even knowing you are actively opposing > the changes). If it falls within the scope of the draft the non-technical > solutions (Which are more common) should be addressed. Unless peering > agreements and other tactics ISPs have used (That I know I have used) to > address those abusing agreements are still a no-no to talk about publicly. > >> >> Section 4.2.1 covers actively filtering without thought to the fact that >> the originating AS may be disconnecting the connection between AS65401 and >> AS65402 and this more specific leaking is a precursor to that. Further, >> section 4.2.1 could also violate the agreement between the two networks >> (AS65402 and AS65403). Finally, it would put the network doing ACL'ing >> (AS65402) under risk (From their own customers and other networks along >> with the originating network) since a common traceroute would identify who >> is filtering the traffic. >> >> >> Exactly. >> >> >> General formatting: Some main chapters are in bold while others are not. >> The first sub-chapters also have this issue. >> >> >> >> I do not seem to have the problem on my side, and the html converted doc >> is not provided by us, but by the submission tool :-S >> > > Ah, then it is the tool. No worries. > >> >> Best regards, >> >> Pierre. >> >> >> ------------------- >> Cheers, Rick >> >> Experiences not things. >> >> On Wed, Feb 11, 2015 at 6:27 AM, Camilo Cardona < >> [email protected]>wrote: >> >>> Hello all, >>> >>> We submitted a new version of draft-ietf-grow-filtering-threats, which >>> includes the latest suggestions made by Wes. Please let us know if any of >>> you have any more recommendations on how to improve this document. >>> >>> Thank you, >>> >>> Camilo Cardona >>> >>> Begin forwarded message: >>> >>> *From: *[email protected] >>> *Subject: **[GROW] I-D Action: draft-ietf-grow-filtering-threats-04.txt* >>> *Date: *11 Feb 2015 11:50:58 GMT+1 >>> *To: *<[email protected]> >>> *Cc: *[email protected] >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Global Routing Operations Working Group >>> of the IETF. >>> >>> Title : Impact of BGP filtering on Inter-Domain Routing >>> Policies >>> Authors : Camilo Cardona >>> Pierre Francois >>> Paolo Lucente >>> Filename : draft-ietf-grow-filtering-threats-04.txt >>> Pages : 16 >>> Date : 2015-02-11 >>> >>> Abstract: >>> This document describes how unexpected traffic flows can emerge >>> across an autonomous system, as the result of other autonomous >>> systems filtering, or restricting the propagation of more specific >>> prefixes. We provide a review of the techniques to detect the >>> occurrence of this issue and defend against it. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-grow-filtering-threats/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-grow-filtering-threats-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-grow-filtering-threats-04 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> GROW mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/grow >>> >>> >>> >>> _______________________________________________ >>> GROW mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/grow >>> >>> >> _______________________________________________ >> GROW mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/grow >> >> >> > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
