I checked the history of the document but did not see this so forgive me if these were discussed before.
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. 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. 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? 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. 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. General formatting: Some main chapters are in bold while others are not. The first sub-chapters also have this issue. ------------------- 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
