Re: [GROW] [Sidrops] Question about mutual transit and complex BGP peering

iginal Message- From: Nick Hilliard Sent: Sunday, April 21, 2024 1:10 PM To: Sriram, Kotikalapudi (Fed) Cc: grow@ietf.org; sidr...@ietf.org Subject: Re: [GROW] Question about mutual transit and complex BGP peering Sriram, Kotikalapudi (Fed) wrote on 21/04/2024 16:53: > Q1: Consider an A

[GROW] Question about mutual transit and complex BGP peering

Hi all, Q1: Consider an AS peering relationship that is complex (or hybrid) meaning, for example, provider-to-customer (P2C) for one set of prefixes and lateral peers (i.e., transit-free peer-to-peer (P2P)) for another set of prefixes. Are these diverse relationships usually segregated, i.e.,

[GROW] Invite comments on updated AS_SET deprecation draft

Hi all, We (authors) recently published an updated version of "Deprecation of AS_SET and AS_CONFED_SET..." draft: https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-10 Please give it a read and let us know if you have some comments before we go to WGLC. The

Re: [GROW] [Sidrops] WG Adoption call for draft-sriram-sirops-bar-sav-02.txt - ENDS 01/30/2023 (Jan 30 2023)

[including SAVNET and GROW since those WGs also have interest in this] While reading the draft, you may wish to take help from our (authors') ppt presentation (especially the figures). Slides from our IETF 114 presentation are here:

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-11.txt

Hi Rich, Thank you for giving it a read. Your editorial comments are incorporated in v-12 of my editor copy. The other comments: >Section 4 has text of: >" The procedure takes (AS1, AS2, AFI) as input parameters" and >" Therefore, the above procedure with the input (AS1, AS2, AFI) may >have

Re: [GROW] [Sidrops] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

I think we can conclude that the outcome of the discussions in this thread is to make the following change in ASPA-based AS path verification: If an AS_PATH has one or more AS_SETs in any position, mark it as Invalid. At least four (perhaps all five) of us who participated in the discussion

Re: [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

From: Jeffrey Haas Sent: Thursday, July 21, 2022 10:37 PM To: Sriram, Kotikalapudi (Fed) Cc: Nick Hilliard; sidr...@ietf.org; GROW WG; draft-ietf-sidrops-aspa-verificat...@ietf.org; a.e.azi...@gmail.com Subject: Re: [GROW] Any credence to AS_SET

Re: [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

y, July 21, 2022 6:22 PM To: Nick Hilliard Cc: Sriram, Kotikalapudi (Fed); sidr...@ietf.org; GROW WG; draft-ietf-sidrops-aspa-verificat...@ietf.org Subject: Re: [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs? > On Jul 21, 2022, at 4:36 AM, Nick Hilliard wrote: > > S

Re: [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

Hi Nick, >Apart from the deprecation in rfc 6472, there's also rfc6907, which has >a complex set of rules for handling routes with an origin which is an >AS_SET. This complexity is already not good, and of dubious practical >use. Replicating something similar to this in ASPA seems like a bad

Re: [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

Job, Nick, Thank you for the inputs. To be perfectly clear, an UPDATE with an AS_SET will never get a 'Valid' or even 'Unknown' result from ASPA validation. It can only get an 'Invalid' or 'Unverifiable' result. The 'Unverifiable' is considered equivalent to 'Invalid' (Section 5.3) for route

[GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

Question: Operationally, is an AS_SET ever used in the *middle* between AS_SEQUENCEs? Or, should one simply give zero credence to it? [Even as I was composing this post, Jeff has already given a helpful answer/suggestion to this in the other thread :) Please see:

Re: [GROW] seeking advice about non-standard use of ‘Segment’ (in the ASPA verification draft)

Jeff, >> Is such non-standard use objectionable or unadvisable? >Objectionable and unadvisable both. Thank you. All of your observations very helpful. Yes, it is understood... we must remove the use of 'Segment' to refer to individual ASes in an AS_SEQUENCE. >Within a segment, if it's of type

[GROW] seeking advice about non-standard use of ‘Segment’ (in the ASPA verification draft)

RFC 4271 and RFC 5065 specify using the term ‘Segment’ to denote AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE, or AS_CONFED_SET. The ASPA verification draft v-09 currently deviates from that and uses ‘Segment’ to refer to an AS in an AS_SEQUENCE and also to refer to an AS_SET. Is such non-standard

[GROW] BAR-SAV: new draft on "Source Address Validation Using BGP Updates, ASPA, and ROA"

We (authors) have submitted the following new draft in SIDROPS. It updates RFC 8704. Your comments and suggestions are welcome here and/or on the SIDROPS list. Thank you. Title:Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV) URL:

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

tions". Sriram From: Jeffrey Haas Sent: Monday, March 21, 2022 12:43 PM To: Zhuangshunwan Cc: Jakob Heitz (jheitz) ; Gyan Mishra ; Sriram, Kotikalapudi (Fed) ; Ben Maddison ; sidr...@ietf.org; grow@ietf.org Subject: Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server ques

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

>If AS1 attests that AS3 is its provider, then there is no leak. >That would be weird, but is it illegal? No that wouldn't work. If you propose that then for an Update that is propagating in the opposite direction, you would also want the reverse: 'AS3 attests that AS1 is its provider'. That

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

Hi Shunwan, >> AS1 (RS Client) -> AS2 (RS) -> AS3 (RS Client) ---p2p (lateral >> peer) ---> AS4 (validating AS) >2. AS3 is not included in the set of C2P AS numbers set registered by AS1; #2 (above) from your list is what we have focused on as a solution. Please see my previous post

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

Hi Jakob, >> AS1 (RS Client) -> AS2 (RS) -> AS3 (RS Client) ---p2p (lateral >> peer) ---> AS4 (validating AS) ... >The AS-path at AS4 is (4 3 1). >If you assume that AS1 and AS3 are bilateral peers, then both sides of AS3 >declare AS3 not to be its provider. AS3 >has both sides

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

Hi Jakob, >To be clear, I'm talking about BGP devices that do not insert their ASN into >the AS path. Even if you assume that all route servers are transparent, what would you like to propose to solve the following problem? AS1 (RS Client) -> AS2 (RS) -> AS3 (RS Client) ---p2p

Re: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server question)

Hi Gyan, >Gyan>I understand the issue with the ASPA path verification, however if the RS >AS added to ASPA then that would influence the forwarding plane is the issue.  >How do you insert RS AS for the ASPA path verification but not allow RS to be >part of forwarding plane?  I guess you could

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

Hi Shunwan, Please see the comments below marked with [KS]. >> An RS client of an RS (transparent or not) includes the RS AS in their >> SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with >> whom it connects in the control plane via the RS. >> [SW] IMO, this idea

Re: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server question)

om: GROW On Behalf Of Sriram, Kotikalapudi (Fed) Sent: Tuesday, March 15, 2022 11:34 AM To: Nick Hilliard Cc: Ben Maddison ; grow@ietf.org; sidr...@ietf.org Subject: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server question) Nick (and all), I was also rereading/reviewing Section

[GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server question)

Nick (and all), I was also rereading/reviewing Section 5.3 and had similar thoughts about the two options you outlined. As you noted, "the approach in Section 5.3 gives a workable outcome". However… >... the RS should be treated as a provider by the rs client; the rs client >should include

Re: [GROW] IXP Route Server question

Hi Shunwan, >> The ASPA verification draft treats the relationship of RS to RS-client >> as similar to that of Provider to Customer. Seems reasonable? The AS >> of an RS client includes the RS's AS in its ASPA as a "Provider". >IMO, the ASPA verification draft regards the relationship between

Re: [GROW] IXP Route Server question

Nick, >Ben Maddison wrote on 11/03/2022 07:23: >> Essential, I would think: how could a far end relying party know that >> an AS in the middle of a received AS_PATH is a non-transparent IXP RS >> in order to apply any other treatment? >given that they're a shrinking rarity, would it not make

Re: [GROW] IXP Route Server question

Sounds good. Thank you so much for the discussions and info. Sriram -Original Message- From: Ben Maddison Sent: Friday, March 11, 2022 2:23 AM To: Nick Hilliard Cc: Sriram, Kotikalapudi (Fed) ; grow@ietf.org; sidr...@ietf.org Subject: Re: [GROW] IXP Route Server question Hi Sriram

Re: [GROW] [Sidrops] IXP Route Server question

Ben, >I know of several transit providers that will allow customers to use an IXP as >a kind of virtual access circuit (which itself is a poor idea), but I would be >*very* surprised if any of them allow RS peerings to be the control plane >interconnection (intentionally, at least). Good.

Re: [GROW] IXP Route Server question

in its ASPA as a "Provider". Sriram -Original Message- From: Nick Hilliard Sent: Tuesday, March 8, 2022 4:28 PM To: Sriram, Kotikalapudi (Fed) Cc: grow@ietf.org; sidr...@ietf.org Subject: Re: [GROW] IXP Route Server question Sriram, Kotikalapudi (Fed) wrote on

[GROW] IXP Route Server question

This question has relevance to the ASPA method for route leak detection. Is it possible that an ISP AS A peers with a customer AS C via a non-transparent IXP AS B? IOW, the AS path in routes propagated by the ISP A for customer C's prefixes looks like this: A B C. I.e., can the AS of a

Re: [GROW] AD Review of draft-ietf-idr-bgp-open-policy-15

Hi Alvaro, Sorry for the delay in responding. Thank you for the new set of comments. Our responses are inline below marked with [AA/KS-2]. We have uploaded version-17 with changes based on your suggestions (either in the round-2 set of comments or the email discussions that followed). Please

Re: [GROW] some questions from {RC, LC, EC} analysis presentation in GROW

Hi Shunwan, >Thanks for your great job! Your work has given me a very in-depth >understanding of the propagation behavior of BGP community attributes on the >Internet. Glad to hear that. I share the compliments with my colleague Lilia Hannachi. >Regarding " Total # Unique {Prefix, RC =

Re: [GROW] some questions from {RC, LC, EC} analysis presentation in GROW

investigation. Any further thoughts/comments? Sriram -- From: Sriram, Kotikalapudi (Fed) Sent: Wednesday, August 4, 2021 12:58 PM To: Zhuangshunwan; Sriram, Kotikalapudi (Fed); GROW WG Cc: IDR Subject: Re: some questions

Re: [GROW] some questions from {RC, LC, EC} analysis presentation in GROW

265K count of unique {Prefix, AS Path, RC = Any:666}, how many are with 3356:666. I will let you know. Sriram From: GROW on behalf of Zhuangshunwan Sent: Tuesday, August 3, 2021 10:37 PM To: Sriram, Kotikalapudi (Fed); GROW WG Cc: IDR Subject: Re: [GROW

[GROW] some questions from {RC, LC, EC} analysis presentation in GROW

Some questions raised at the mike or in the chat window during my GROW presentation last week on the analysis of {Regular, Large, Extended} Communities are worth a revisit. The presentation slides are here:

[GROW] NIST RPKI Monitor Version 2.0

We (NIST) have released a new version of the NIST RPKI Monitor (v2.0): https://www.nist.gov/services-resources/software/nist-rpki-deployment-monitor We are open to adding more features and analyses based on user feedback. Please feel free to share your comments/suggestions. Thank you. Sriram

Re: [GROW] Choice of Large vs. Extended Community for Route Leaks Solution

on it, that does not imply that the community traveled through 5 AS hops. The community could have been added at any of the ASes in the path. Where does the data show that any communities transited any AS boundaries? Regards, Jakob. > On Apr 1, 2021, at 2:06 PM, Sriram, Kotikalapudi (Fed) >

Re: [GROW] Choice of Large vs. Extended Community for Route Leaks Solution

There may be a knob that AS operators have for permitting transitivity, but we need to look at measurements to understand whether or not operators actually allow transitivity to EC and LC. NIST BGP measurements (thanks to my colleague Lilia Hannachi) were shared on the GROW list in May 2020:

Re: [GROW] Choice of Large vs. Extended Community for Route Leaks Solution

. Sriram From: Brian Dickson Sent: Wednesday, March 31, 2021 6:10 PM To: Sriram, Kotikalapudi (Fed) Cc: Susan Hares; i...@ietf.org; draft-heitz-idr-w...@ietf.org; grow@ietf.org; a.e.azi...@gmail.com Subject: Re: Choice of Large vs. Extended Community for Ro

Re: [GROW] [Idr] Choice of Large vs. Extended Community for Route Leaks Solution

new type of Community that comes with transitivity guarantees? Sriram From: Jeffrey Haas Sent: Wednesday, March 31, 2021 12:13 PM To: Sriram, Kotikalapudi (Fed) Cc: Susan Hares; i...@ietf.org; grow@ietf.org; draft-heitz-idr-w...@ietf.org Subject: Re: [I

[GROW] Choice of Large vs. Extended Community for Route Leaks Solution

Hi Sue, Thanks for the detailed thoughts you have shared on the IDR list about the WKLC draft and route leaks solution draft (while also responding to Brian’s post). At one point in the past, the route leaks solution needed 8 bytes of user data space to accommodate two ASNs but then there was

[GROW] route leak solution and IANA large community register

I have a question for the GROW Chairs and anyone who can help. There are these two drafts: Methods for Detection and Mitigation of BGP Route Leaks https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04 BGP Well Known Large Community

Re: [GROW] I-D Action: draft-ietf-grow-route-leak-detection-mitigation-04.txt

John Heasley gave us a nice set of editorial comments. They have been incorporated in this new version and help improve the clarity. Thank you John. Sriram From: GROW on behalf of internet-dra...@ietf.org Sent: Monday, October 26, 2020 4:20 PM To:

Re: [GROW] New Version Notification for draft-sriram-sidrops-as-hijack-detection-00.txt

From: Sriram, Kotikalapudi (Fed) Sent: Tuesday, July 14, 2020 8:44 AM To: sidr...@ietf.org Subject: Fw: New Version Notification for draft-sriram-sidrops-as-hijack-detection-00.txt Comments on the draft are welcome. Chairs have kindly allocated time to present

Re: [GROW] Measurements on Regular, Extended, and Large Communities

Thanks Nick and Colin. Insights you shared are helpful. Colin: >If you are analysing Route-Views table dumps (and not updates) then you >won't see ECs because Quagga/FRR only dumps selected attributes into the >MRT files [0]. ECs are not on the list of dumped attributes. LCs were >added to the

[GROW] Measurements on Regular, Extended, and Large Communities

Please see measurements below on Regular, Extended (EC), and Large Communities (LC). Analysis is based on data from many newer Routeviews collectors. ** Question: Any insights why we don't see any ECs at all? ** OTOH, we do see good numbers of LCs even though there is no IANA registry for them

Re: [GROW] [Idr] I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-03.txt

Some notes & changes since version -02: 1. Section 5 (Operational Considerations) is new. * IDR and GROW WG feedback especially welcome on this section. 2. The revisions take into consideration the feedback received at IETF 106 (Singapore). 3. The authors are still discussing about BCP

[GROW] FW: [OPSEC] BCP 84, RFC 8704 on Enhanced Feasible-Path Unicast Reverse Path Forwarding

This new RFC is a product of the OPSEC WG. https://tools.ietf.org/html/rfc8704 I thought I should share the publication notice in GROW because substantial discussion and feedback occurred also in the GROW WG when this RFC was in draft form. Thank you. CC'ing SIDROPS WG also since the RFC (BCP)

Re: [GROW] Question about BGP Large Communities

Jakob, >Private ASNs are 4,200,000,000 upwards. >I am requesting a block just below that > 4,000,000,000. That sounds reasonable. We can discuss trading off some bits between WKLC ID and Data 1 to possibly give room for more than 256 WKLCs. Sriram

Re: [GROW] Question about BGP Large Communities

> -Original Message- > From: John Heasly > Sent: Tuesday, February 4, 2020 5:55 PM > To: Jakob Heitz (jheitz) > Cc: Sriram, Kotikalapudi (Fed) ; Job Snijders > ; Nick Hilliard ; John Heasly > ; i...@ietf.org; grow@ietf.org; idr-cha...@ietf.org; > grow-cha...@ietf.

[GROW] Question about BGP Large Communities

In the route leaks solution draft, https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02 we (the authors) have proposed using BGP Large Community. We specify this to be a "well-known transitive Large Community". Question: Can the draft simply make an IANA request

Re: [GROW] [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

Earlier in this thread, there was discussion about some measurements that were shared (by Jared, Warren, myself). Jeff's suggestion: why don't we list all routes with AS_SET in addition to the stats. Now we have a detailed analysis (thanks once again to Lilia Hannachi my colleague at NIST):

Re: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

Warren, Thanks for the additional data/suggestions. Comments below. .. >> Some recent measurements we have at NIST about this are as follow: >> (thanks to Lilia Hannachi - my colleague) >> > >This is nice, but what would make it more useful would be if it also >reported if there are *useful*

Re: [GROW] [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

Alejandro, >> It would be great if this were to progress to standards track RFC. >> AS_SETs are a nuisance and cause real-world confusion with no >> appreciable gain. >+1, well said. Thanks. Perhaps you are aware, but just in case ... The WG adoption call took place in IDR and this is now a WG

Re: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

Jared, >(Obviously my search in e-mail today went afoul, I see it’s adopted.. Yes, the draft was adopted. You can see the discussion here: https://mailarchive.ietf.org/arch/browse/idr/?gbt=1=WG%20adoption%20for%20draft-kumari-deprecate-as-set-confed-set One key point of the discussion was

[GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

There was significant interest expressed during a SIDROPS presentation in Montreal and in the discussion that followed at the mike about advancing the following individual draft: https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-14 (standards track) The authors have

Re: [GROW] [Sidrops] Path validation with RPKI

[Including GROW list because some members there would be interested given the RLP draft has home in GROW] Iljitsch, >> Just in case you are not aware, there is another effort in the GROW WG >> for route leaks solution: >>

Re: [GROW] call for feedback on draft-ietf-grow-route-leak-detection-mitigation

>From: Brian Dickson >Sent: Monday, June 17, 2019 5:19 PM ... snip ... >(We authors have done extensive analysis, too much to present on-list, IMHO.) Authors-team discussion (design rationale) slides with extensive scenario analyses are here: (some of it presented in IDR/GROW WG meetings)

Re: [GROW] call for feedback on draft-ietf-grow-route-leak-detection-mitigation

Nick, Thank you for your thoughts on this. This work has been in GROW / IDR since 2014. Initially in GROW where we published a route leak problem definition RFC: https://tools.ietf.org/html/rfc7908 The work then moved to IDR for the route leak solution based on BGP Attribute. It was moved back

[GROW] Comments on draft-ietf-idr-route-leak-detection-mitigation-10

I am creating this separate thread for this draft. Better to have the subject line relevant to the comments/discussion. The authors would love to hear your comments/questions. Sriram We have this updated WG draft in IDR on route leaks detection and mitigation. There is a

Re: [GROW] Agenda Slot Requests - IETF 103

Chris, >Please send along agenda requests as time permits... We are planning to meet >in Bangkok, unless no one can find agenda topics? :) If possible to accommodate, I would like to request 10 to 15 minutes. We have this updated WG draft in IDR on route leaks detection and mitigation. There

Re: [GROW] WG ADOPTION - draft-ss-grow-rpki-as-cone - ENDS: June 04, 2018

Chris, I have read the document and feel that the work is worth pursuing in the WG. Support adoption. Willing to contribute and review going forward. For now, I have some comments for the authors below. Dear authors: Some of my questions/suggestions may be better handled with a face-to-face

Re: [GROW] New Version Notification for draft-sriram-opsec-urpf-improvements-03.txt

on the list anytime, and also in person in London. Thanks. Sriram From: internet-dra...@ietf.org <internet-dra...@ietf.org> Sent: Monday, March 5, 2018 6:19 PM To: Sriram, Kotikalapudi (Fed); Montgomery, Douglas (Fed); Jeffrey Haas Subject: New V

[GROW] FW: New Version Notification for draft-sriram-opsec-urpf-improvements-01.txt

...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Wednesday, May 03, 2017 7:37 PM To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sri...@nist.gov>; Montgomery, Douglas (Fed) <do...@nist.gov> Subject: New Version Notification for draft-sriram-opsec-urpf-improvements-01.txt A new version o

[GROW] GROW RFC 7908 gets press coverage

Just noticed ... RFC 7908 (route leaks problem definition) -- developed in GROW -- reported in The Register. https://www.theregister.co.uk/2016/06/23/fatthumbed_a_bgp_entry_relax_now_your_pain_has_a_name/ Link to the RFC: https://tools.ietf.org/html/rfc7908 Sriram

[GROW] operator inputs -- route leak solution

Inviting comments especially from GROW WG folk (network operators). Please look at this and address the question posed at the end. Thank you. The most common form of route leak occurs when multi-homed customer AS-C receives a route from its transit provider AS-A and leaks it to another transit

Re: [GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6 2016

+1 support Sriram From: GROW on behalf of Jeffrey Haas Sent: Wednesday, November 16, 2016 12:14 AM To: grow@ietf.org Subject: Re: [GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

| AS4 | +-++--+--+ | | +--+--+ | | AS2 +---+ +-+ Regards On Tue, Nov 15, 2016 at 4:31 AM, Sriram, Kotikalapudi (Fed) <kotikalapudi.sri...@nist.gov> wrote: > Marco, > > My responses Marked with [Sriram] below: > > [Marco] But it also goes further and suggest

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

interfaces, then the enhanced FP uRPF still works for this scenario. Sriram From: Job Snijders <j...@instituut.net> Sent: Tuesday, November 15, 2016 3:26 AM To: Sriram, Kotikalapudi (Fed) Cc: Gert Doering; grow@ietf.org Subject: Re: [GROW] Fw: New V

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

Job, My responses marked [Sriram] below: [Job]: In section 3, the border router which received Q1, might not be the same border router which received Q2 and Q3, these two border routers might not have the same view on the routing table: each could have a partial routing table (and reach the

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

>Does this technique make routers self-aware? What exactly is meant with >the word 'intelligence' in this context? 'Logic' may be a better choice than 'intelligence' in this context? For a brief description of the algorithm, please see:

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

Marco, My responses Marked with [Sriram] below: [Marco] But it also goes further and suggest to amend the usual behavior by advertising via BGP the source addresses of the traffic you want to drop so that the routers can null route and trigger uRPF. This is where i see problems. [Sriram] This

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

Gert, My response marked with [Sriram] below. [Gert] Having implementations that could tack arbitrary "RPF lists" to an interface would be very nice, but this is more like "auto-generate ACLs based on prefix info" than "RPF" which stands for "reverse path filter" (not sure about the "filter"

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

Nick, My responses marked with [Sriram]. [Nick] I suspect Sriram's proposed methodology is not going to be as useful as it might seem in production networks because he's making an assumption that the list of valid source paths can be built up by creating a union of all source ASNs and applying

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

>Sriram, Kotikalapudi (Fed) wrote: >> The common source ASN checking is performed on BGP updates in the >> control plane (not in the data path), and that results in adding some >> additional allowed prefixes (for particular interfaces) to the Reverse >> Path Filter

Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

>I am not sure if anyone would ever deploy such mechanism. >For contents it's useless as they have to filter DDoSes before they reach >their network. >For carriers is poorly scalable as they'd have to configure thousands of >prefixes. >It could make sense for eyeballs but they hardly would drop

Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

>>-- Jeff Seems OK to leave the details to the implementers about how to tag/notate/mark the updates. Sriram -Original Message- From: Job Snijders [mailto:j...@instituut.net] Sent: Tuesday, November 01, 2016 12:24 PM To: Jeffrey Haas <jh...@pfrc.org> Cc: Sriram, Kotikalap

Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

>> Additionally, should there be an alert generated for the network >> operator. The discard of routes happening quietly (while operator >> knows nothing about it) is not good. >An alert is overkill imho, can't have a system spew 600,000 alerts >because it rejected a full table feed. I was

Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

Greg, Thanks for your responses. You may call me Sriram - name I go by. Comments below. Sriram >Hi Kotikalapudi, thanks for you comments. We proposing to change the first >two lines to remove the inconsistencies: >- Software MUST mark any routes from an EBGP peer as 'invalid' in the

Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

o Software MUST mark any routes from an eBGP peer as 'invalid' in the Adj-RIB-In, if no explicit policy was configured. This bullet says “explicit” policy. The next bullet does not say “explicit”. What is the definition of “explicit policy” as opposed to “policy”? o Software

[GROW] FW: New Version Notification for draft-ietf-grow-route-leak-problem-definition-06.txt

This new version incorporates an editorial change suggested by Deborah. Thanks, Deborah. Sriram -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Thursday, May 05, 2016 5:45 PM To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sri...@nist.

Re: [GROW] Stephen Farrell's Yes on draft-ietf-grow-route-leak-problem-definition-05: (with COMMENT)

Stephen: Thank you for your review and comments. In our off-list discussion, we agreed that using "propagation" in the definition is fine. Hence, not making any change in the document in regards to this. Sriram -Original Message- From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of