From jrmitche@puck.nether.net Mon Jul 2 09:48:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6439811E8087 for ; Mon, 2 Jul 2012 09:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6htiuPoJlaY6 for ; Mon, 2 Jul 2012 09:48:30 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9C14421F8620 for ; Mon, 2 Jul 2012 09:48:30 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q62GmYBf015494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Jul 2012 12:48:34 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q62GmY37015492 for idr@ietf.org; Mon, 2 Jul 2012 12:48:34 -0400 Date: Mon, 2 Jul 2012 12:48:34 -0400 From: Jon Mitchell To: idr@ietf.org Message-ID: <20120702164834.GB13713@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 02 Jul 2012 12:48:34 -0400 (EDT) Subject: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 16:48:31 -0000 IDR WG folks - I hope you can take some time from the normal debate(s) to consider and review a fresh draft on expanding the ASN space reserved for Private Use. All comments regarding content, clarity or structure welcome. Cheers, Jon -- A new version of I-D, draft-mitchell-idr-as-private-reservation-00.txt has been successfully submitted by Jon Mitchell and posted to the IETF repository. Filename: draft-mitchell-idr-as-private-reservation Revision: 00 Title: Autonomous System (AS) Reservation for Private Use Creation date: 2012-06-20 WG ID: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-mitchell-idr-as-private-reservation-00.txt Status: http://datatracker.ietf.org/doc/draft-mitchell-idr-as-private-reservation Htmlized: http://tools.ietf.org/html/draft-mitchell-idr-as-private-reservation-00 Abstract: This document describes the reservation of Autonomous System numbers (ASNs) that may be used within networks but should not be advertised to the Internet, known as private use ASNs. This document enlarges the total space available for private use ASNs by documenting the reservation of a second larger range and updates RFC 1930. The IETF Secretariat From robert@raszuk.net Mon Jul 2 10:03:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C8811E808F for ; Mon, 2 Jul 2012 10:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnMTK-u0joxl for ; Mon, 2 Jul 2012 10:03:53 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 76F9111E8087 for ; Mon, 2 Jul 2012 10:03:53 -0700 (PDT) Received: (qmail 14667 invoked by uid 399); 2 Jul 2012 17:03:58 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.233.156) by mail1310.opentransfer.com with ESMTPM; 2 Jul 2012 17:03:58 -0000 X-Originating-IP: 83.31.233.156 Message-ID: <4FF1D47D.5020408@raszuk.net> Date: Mon, 02 Jul 2012 19:03:57 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jon Mitchell References: <20120702164834.GB13713@puck.nether.net> In-Reply-To: <20120702164834.GB13713@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 17:03:54 -0000 Hi Jon, I have read your draft few days back and support adopting it as an IDR WG doc. However I have one question/suggestion ... Perhaps you recall some debates on the topic of reserving some address chunk like 1918, but only for operator's use. Here with private AS numbers we actually are facing the same issue today. Flat space introduces a bit of a difficulty when both my internal ASes (example: data centers) as well as my customer's ASes use the same private as number. This mandates the knobs like as_override or allowas_in to be applied on all address families. The simplest way to solve it would be to define two blocks of 4 octet private AS numbers .. One for multi-as operators and one for stub networks. Maybe we could do the same for 2 octet AS numbers too if we manage to find some decent block space. Cheers, R. > IDR WG folks - > > I hope you can take some time from the normal debate(s) to consider and > review a fresh draft on expanding the ASN space reserved for Private > Use. All comments regarding content, clarity or structure welcome. > > Cheers, > > Jon > > -- > > A new version of I-D, draft-mitchell-idr-as-private-reservation-00.txt > has been successfully submitted by Jon Mitchell and posted to the IETF > repository. > > Filename: draft-mitchell-idr-as-private-reservation > Revision: 00 > Title: Autonomous System (AS) Reservation for Private Use > Creation date: 2012-06-20 > WG ID: Individual Submission > Number of pages: 4 > URL: > http://www.ietf.org/internet-drafts/draft-mitchell-idr-as-private-reservation-00.txt > Status: > http://datatracker.ietf.org/doc/draft-mitchell-idr-as-private-reservation > Htmlized: > http://tools.ietf.org/html/draft-mitchell-idr-as-private-reservation-00 > > > Abstract: > This document describes the reservation of Autonomous System numbers > (ASNs) that may be used within networks but should not be advertised > to the Internet, known as private use ASNs. This document enlarges > the total space available for private use ASNs by documenting the > reservation of a second larger range and updates RFC 1930. > > > > > The IETF Secretariat > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From farmer@umn.edu Mon Jul 2 11:37:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C25811E80D7 for ; Mon, 2 Jul 2012 11:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlX7NzzoXEeT for ; Mon, 2 Jul 2012 11:37:00 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 9A21F11E809C for ; Mon, 2 Jul 2012 11:37:00 -0700 (PDT) Received: from mail-yw0-f48.google.com (mail-yw0-f48.google.com [209.85.213.48]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 2 Jul 2012 13:36:55 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-yw0-f48.google.com [209.85.213.48] #+LO+TR X-Umn-Classification: local Received: by mail-yw0-f48.google.com with SMTP id q46so6028467yhf.7 for ; Mon, 02 Jul 2012 11:36:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=1KPmpoO2Hcc66BzZXpuYGAWKrCqBCjU+pDEPBtazBfw=; b=Hw9GqogKKSRFvFOfNVeTz63tt90Vd7LKCUMo/P77yLV2o2RrFE8LkzneH2E1P6ZcJn 67M0AhCJ3Z89DL3Zgfpbl0vhst02FEgyZgd0BFR10AeauXBCIYZWgKWF/1cogJr2BhXc NOPDDFBu5aBB/Fi0wBJDVE2XylpxNbXB5rsA+SqE7bWE8zlwD/7XhLFiMgQxq5vJsJ9R pN9jMyz+Nki53cpfowchHUL26zesJx1b9RyLTx8/I8K11VB79NvHuf5XeWqryyDpnxOw gVdWgVEWLKi6IhrFbymgW0hSAXRN8fdxdDogN0ov6B+C/ULORuLPCki/hvRoKpUu9OPx B9uQ== Received: by 10.50.36.227 with SMTP id t3mr8319804igj.13.1341254215057; Mon, 02 Jul 2012 11:36:55 -0700 (PDT) Received: from x-128-101-233-140.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:223:6cff:fe94:288c]) by mx.google.com with ESMTPS id dw5sm9185024igc.6.2012.07.02.11.36.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 11:36:54 -0700 (PDT) Message-ID: <4FF1EA45.9000807@umn.edu> Date: Mon, 02 Jul 2012 13:36:53 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: robert@raszuk.net References: <20120702164834.GB13713@puck.nether.net> <4FF1D47D.5020408@raszuk.net> In-Reply-To: <4FF1D47D.5020408@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQncbXgG3zXnczC3CRGhD6e3Jd5izBFWvlauYY6WO1rzLDhngtYjDAIunfE26OhYgxUgmfYl Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 18:37:01 -0000 On 7/2/12 12:03 CDT, Robert Raszuk wrote: > Hi Jon, > > I have read your draft few days back and support adopting it as an IDR > WG doc. I agree and support support adopting it as an IDR WG doc. > However I have one question/suggestion ... > > Perhaps you recall some debates on the topic of reserving some address > chunk like 1918, but only for operator's use. > > Here with private AS numbers we actually are facing the same issue > today. Flat space introduces a bit of a difficulty when both my internal > ASes (example: data centers) as well as my customer's ASes use the same > private as number. > > This mandates the knobs like as_override or allowas_in to be applied on > all address families. > > The simplest way to solve it would be to define two blocks of 4 octet > private AS numbers .. One for multi-as operators and one for stub > networks. Maybe we could do the same for 2 octet AS numbers too if we > manage to find some decent block space. I'm not sure it is a good idea to try to define something like this within the limits of 2-Byte ASNs. I'm not opposed to trying something like this for 4-Byte ASNs. However, the analogy you provide isn't quite accurate, as there isn't really ASN translation that I'm aware of. Stripping of private ASNs could maybe be thought of as a type of translation, but it doesn't function quite the same way especially as multi-layer CGN/NAT. I'm not sure defining two layers of private ASNs is going to simplify anything though. A provider will still need uniqueness among its customer stub ASNs, or have to use knobs like as_override or allowas_in, a million private ASNs will make that a lot easier to maintain uniqueness though. A two layer system, might help if two providers are exchanging private ASNs and they both have stub customers out of the other range that are stripped. But is that really a common situation? I think a million private ASNs will be a much bigger help than trying to bifurcate the ranges, but I'm willing to listen to arguments otherwise. > Cheers, > R. > > >> IDR WG folks - >> >> I hope you can take some time from the normal debate(s) to consider and >> review a fresh draft on expanding the ASN space reserved for Private >> Use. All comments regarding content, clarity or structure welcome. >> >> Cheers, >> >> Jon >> >> -- >> >> A new version of I-D, draft-mitchell-idr-as-private-reservation-00.txt >> has been successfully submitted by Jon Mitchell and posted to the IETF >> repository. >> >> Filename: draft-mitchell-idr-as-private-reservation >> Revision: 00 >> Title: Autonomous System (AS) Reservation for Private Use >> Creation date: 2012-06-20 >> WG ID: Individual Submission >> Number of pages: 4 >> URL: >> http://www.ietf.org/internet-drafts/draft-mitchell-idr-as-private-reservation-00.txt >> >> Status: >> http://datatracker.ietf.org/doc/draft-mitchell-idr-as-private-reservation >> Htmlized: >> http://tools.ietf.org/html/draft-mitchell-idr-as-private-reservation-00 >> >> >> Abstract: >> This document describes the reservation of Autonomous System numbers >> (ASNs) that may be used within networks but should not be advertised >> to the Internet, known as private use ASNs. This document enlarges >> the total space available for private use ASNs by documenting the >> reservation of a second larger range and updates RFC 1930. >> >> >> >> >> The IETF Secretariat >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jhaas@slice.pfrc.org Mon Jul 2 11:47:32 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC2611E812A for ; Mon, 2 Jul 2012 11:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.231 X-Spam-Level: X-Spam-Status: No, score=-102.231 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u-4+Y4P15s8 for ; Mon, 2 Jul 2012 11:47:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B930F11E80D1 for ; Mon, 2 Jul 2012 11:47:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2C162D1D2; Mon, 2 Jul 2012 14:47:37 -0400 (EDT) Date: Mon, 2 Jul 2012 14:47:37 -0400 From: Jeffrey Haas To: Jon Mitchell Message-ID: <20120702184737.GV18361@pfrc> References: <20120702164834.GB13713@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120702164834.GB13713@puck.nether.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 18:47:32 -0000 Jon, Several comments: On Mon, Jul 02, 2012 at 12:48:34PM -0400, Jon Mitchell wrote: > I hope you can take some time from the normal debate(s) to consider and > review a fresh draft on expanding the ASN space reserved for Private > Use. All comments regarding content, clarity or structure welcome. You beat me to such a draft. I had one about 2/3 finished and just got diverted from finishing it. :-) I thus, obviously, support a draft on this. I would also suggest that GROW is probably a more appropriate venue for this draft. I suggest that we leave 65535 alone as a reserved AS. I finally suggest that the number of private ASes (967K) is somewhat weird and would be a counter example of an implementor that would like something that made a bit more sense boundary-wise. (It makes staring at the private stuff in the debugger a bit easier.) -- Jeff From jrmitche@puck.nether.net Mon Jul 2 18:10:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976A911E8080 for ; Mon, 2 Jul 2012 18:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.796 X-Spam-Level: X-Spam-Status: No, score=-5.796 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwFz2yj6qft8 for ; Mon, 2 Jul 2012 18:10:42 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id C635511E80F0 for ; Mon, 2 Jul 2012 18:10:42 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q631AmUg025811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2012 21:10:48 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q631AmVl025810; Mon, 2 Jul 2012 21:10:48 -0400 Date: Mon, 2 Jul 2012 21:10:48 -0400 From: Jon Mitchell To: Robert Raszuk Message-ID: <20120703011048.GA22452@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> <4FF1D47D.5020408@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF1D47D.5020408@raszuk.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 02 Jul 2012 21:10:49 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 01:10:43 -0000 Comments [JM] Inline... On Mon, Jul 02, 2012 at 07:03:57PM +0200, Robert Raszuk wrote: > Hi Jon, > > I have read your draft few days back and support adopting it as an > IDR WG doc. > [JM] Thanks. > However I have one question/suggestion ... > > Perhaps you recall some debates on the topic of reserving some > address chunk like 1918, but only for operator's use. > > Here with private AS numbers we actually are facing the same issue > today. Flat space introduces a bit of a difficulty when both my > internal ASes (example: data centers) as well as my customer's ASes > use the same private as number. > > This mandates the knobs like as_override or allowas_in to be applied > on all address families. > > The simplest way to solve it would be to define two blocks of 4 > octet private AS numbers .. One for multi-as operators and one for > stub networks. Maybe we could do the same for 2 octet AS numbers too > if we manage to find some decent block space. [JM] I'm not sure that adding a single second range would alleviate this. This seems to suggest that networks and the services they offer are somewhat static, or that multi-as network operators could not acquire services from each other? Given that little guidance is given to network operators on private Use ASNs by definition I'm not sure that we could easily define or expect your customers to abide by a defintion of whether they are a multi-AS operator versus a stub network unless you are the one doing the ASN assignment, in which case you shouldn't run into this issue. The only workable solution I can envision for your use case that would guarentee uniqueness is a GLOP style block reservations so anyone with a Public AS would have another set of private ASN to use, however this is so much more ambitious/complex than my proposal and would consume potentially a much larger portion of the pool. Unless others weigh in this is a problem space they feel needs to be solved, I expect that others will accept the existing knobs or the workaround of using a Public (RIR assigned) ASN to front services when connecting to private ASNs that customers own. I also think that this problem will be less likely to occur with a much wider range of ASNs available as David mentioned, assuming you are willing to renumber into a semi-random location in the new range. > > Cheers, > R. > > > >IDR WG folks - > > > >I hope you can take some time from the normal debate(s) to consider and > >review a fresh draft on expanding the ASN space reserved for Private > >Use. All comments regarding content, clarity or structure welcome. > > > >Cheers, > > > >Jon > > > >-- > > > >A new version of I-D, draft-mitchell-idr-as-private-reservation-00.txt > >has been successfully submitted by Jon Mitchell and posted to the IETF > >repository. > > > >Filename: draft-mitchell-idr-as-private-reservation > >Revision: 00 > >Title: Autonomous System (AS) Reservation for Private Use > >Creation date: 2012-06-20 > >WG ID: Individual Submission > >Number of pages: 4 > >URL: > >http://www.ietf.org/internet-drafts/draft-mitchell-idr-as-private-reservation-00.txt > >Status: > >http://datatracker.ietf.org/doc/draft-mitchell-idr-as-private-reservation > >Htmlized: > >http://tools.ietf.org/html/draft-mitchell-idr-as-private-reservation-00 > > > > > >Abstract: > > This document describes the reservation of Autonomous System numbers > > (ASNs) that may be used within networks but should not be advertised > > to the Internet, known as private use ASNs. This document enlarges > > the total space available for private use ASNs by documenting the > > reservation of a second larger range and updates RFC 1930. > > > > > > > > > >The IETF Secretariat > > > >_______________________________________________ > >Idr mailing list > >Idr@ietf.org > >https://www.ietf.org/mailman/listinfo/idr > > > > > From ju1738@att.com Mon Jul 2 18:45:04 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F7721F85C0 for ; Mon, 2 Jul 2012 18:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.051 X-Spam-Level: X-Spam-Status: No, score=-106.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTJGr1Igz3Uy for ; Mon, 2 Jul 2012 18:45:04 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id C3A8621F85B6 for ; Mon, 2 Jul 2012 18:45:03 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 5ae42ff4.0.423095.00-408.1155414.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 03 Jul 2012 01:45:10 +0000 (UTC) X-MXL-Hash: 4ff24ea66bb08a9e-ad6882353c42d822ecb0899fef41124745de0f20 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q631j9dn022992; Mon, 2 Jul 2012 18:45:09 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q631j0Me022891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2012 18:45:01 -0700 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by fflint04.pst.cso.att.com (RSA Interceptor); Mon, 2 Jul 2012 18:44:42 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0298.004; Mon, 2 Jul 2012 21:44:42 -0400 From: "UTTARO, JAMES" To: "'Jon Mitchell'" , "idr@ietf.org" Thread-Topic: [Idr] new ID on expansion of private use ASN range Thread-Index: AQHNWHKljC8TDxs8cE6jyZJb6lmEx5cWx/CA Date: Tue, 3 Jul 2012 01:44:42 +0000 Message-ID: References: <20120702164834.GB13713@puck.nether.net> In-Reply-To: <20120702164834.GB13713@puck.nether.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.21.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=bvJ_HHhP4N4A:10 a=RWSgesl4Y2gA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=6H-FyMtOVf_CPohR60AA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=H7Wc3F33PO4uAkdZ:21 a=] X-AnalysisOut: [D2ZdFx-yW8Rorb4f:21] Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 01:45:04 -0000 Jon, Seems reasonable.. I do not fully get the context.. You describe the fact = that the increase in the number of AS across both l3VPN and Internet use ca= ses are expanding rapidly.. No Doubt... So I see the creation of the new sp= aces and ranges.. My concerns are in re the Operations Considerations Secti= on a) You are creating a set of rules for the internet routing context. " If private use ASNs are used and prefixes are originated from these private use ASNs which are destined to the Internet, private use ASNs must be removed from the AS_PATH before being advertised to the global Internet. " How does this effect folks who use AS_PATH and/or AS_CONTENT in routing pol= icy decisions? Better question is there an issue if all of the Private ASNs= are stripped? b) You specify no rules in re the L3VPN routing context(s).=20 c) Not sure how this would work? If someone screws up what is the collatera= l damage? " Prior to making use of the second, numerically higher, range of these ASNs network operators should be confident any implementation specific features or filters that recognize private use ASNs have been updated to recognize both ranges correctly so that no unintended announcement of private use ASNs to the Internet " Thanks, Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jon M= itchell Sent: Monday, July 02, 2012 12:49 PM To: idr@ietf.org Subject: [Idr] new ID on expansion of private use ASN range IDR WG folks - I hope you can take some time from the normal debate(s) to consider and review a fresh draft on expanding the ASN space reserved for Private Use. All comments regarding content, clarity or structure welcome. Cheers, Jon -- A new version of I-D, draft-mitchell-idr-as-private-reservation-00.txt has been successfully submitted by Jon Mitchell and posted to the IETF repository. Filename: draft-mitchell-idr-as-private-reservation Revision: 00 Title: Autonomous System (AS) Reservation for Private Use Creation date: 2012-06-20 WG ID: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-mitchell-idr-as-private-reservati= on-00.txt Status: http://datatracker.ietf.org/doc/draft-mitchell-idr-as-private-reservation Htmlized: http://tools.ietf.org/html/draft-mitchell-idr-as-private-reservation-00 Abstract: This document describes the reservation of Autonomous System numbers (ASNs) that may be used within networks but should not be advertised to the Internet, known as private use ASNs. This document enlarges the total space available for private use ASNs by documenting the reservation of a second larger range and updates RFC 1930. = =20 The IETF Secretariat _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jrmitche@puck.nether.net Mon Jul 2 18:55:16 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8816011E8104 for ; Mon, 2 Jul 2012 18:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.997 X-Spam-Level: X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p22FEvpzEjrk for ; Mon, 2 Jul 2012 18:55:16 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id E0F6111E8102 for ; Mon, 2 Jul 2012 18:55:15 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q631tLME028496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2012 21:55:21 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q631tLcX028495; Mon, 2 Jul 2012 21:55:21 -0400 Date: Mon, 2 Jul 2012 21:55:21 -0400 From: Jon Mitchell To: Jeffrey Haas Message-ID: <20120703015521.GB22452@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120702184737.GV18361@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 02 Jul 2012 21:55:21 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 01:55:16 -0000 Comments [JM] inline... On Mon, Jul 02, 2012 at 02:47:37PM -0400, Jeffrey Haas wrote: > > On Mon, Jul 02, 2012 at 12:48:34PM -0400, Jon Mitchell wrote: > > I hope you can take some time from the normal debate(s) to consider and > > review a fresh draft on expanding the ASN space reserved for Private > > Use. All comments regarding content, clarity or structure welcome. > > You beat me to such a draft. I had one about 2/3 finished and just got > diverted from finishing it. :-) I thus, obviously, support a draft on this. [JM] Thanks. > > I would also suggest that GROW is probably a more appropriate venue for this > draft. [JM] I have mixed feelings on this which I expressed to both WG chairs, where the main points for thinking it should be in IDR are: 1. This is an update to RFC 1930 which is listed as an IDR document, albeit very old. 2. Documentation ASN reservation RFC was published more recently by IDR. 3. GROW charter is focused on Internet scalability and routing, where private Use ASN use cases (most?) often involve non-Internet routing. A good case can be made for either in my opinion, but the IDR WG chairs were OK with it being worked here. I can definitely send it also to GROW list for comment either before or after it becomes a WG document, or whatever makes the IDR WG chairs most comfortable. GROW WG chairs are aware of it already... > > I suggest that we leave 65535 alone as a reserved AS. [JM] I think it should be clarified either way, and I think adding it to the private use ASN range with this draft is the better approach for the following reason. I consider this an after-the-fact registration (RFC 5226 section 6.3) since this ASN seems to have widespread (mis-)use as many implementations strip it using their remove private ASN knobs and various networks undoubtedly have it deployed since it seems more than since a large amount of Internet documentation including RFC 1930 seem to include it as a private Use ASN. Also, if this document progress, implementors will need to update their knobs and documentation anyway, so they, IETF and IANA can all be on the same page, allowing this ASN to be stripped if there are vendors that don't do it today (note even some vendors with published documentation stating that private ASN range is 64512-65534 strip 65535 with their remove private knobs). > > I finally suggest that the number of private ASes (967K) is somewhat weird > and would be a counter example of an implementor that would like something > that made a bit more sense boundary-wise. (It makes staring at the private > stuff in the debugger a bit easier.) [JM] I don't feel strongly either way, expect others will weigh in on size, placement, and structure of range. I leaned toward the range being easily recognizable which is why I choose a nice round number for the start meaning operators would recognize 4294 (it will be hard to optimize for both, but frankly anything at the end of the total range of space should be easily recognizable since is not likely to be assigned by an RIR for a long time). Can I suggest your alternative proposal for folks to comment on then is 4293918720 - 4294967295 (maintaining ~1M) or are you suggesting a different range location or sizing? From jhaas@slice.pfrc.org Mon Jul 2 19:12:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B962B11E810A for ; Mon, 2 Jul 2012 19:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.946 X-Spam-Level: X-Spam-Status: No, score=-101.946 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+AZSxVcKfed for ; Mon, 2 Jul 2012 19:12:33 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 34A0111E8105 for ; Mon, 2 Jul 2012 19:12:33 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D63D9D1CD; Mon, 2 Jul 2012 22:12:38 -0400 (EDT) Date: Mon, 2 Jul 2012 22:12:38 -0400 From: Jeffrey Haas To: Jon Mitchell Message-ID: <20120703021238.GM18361@pfrc> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120703015521.GB22452@puck.nether.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 02:12:33 -0000 Jon, On Mon, Jul 02, 2012 at 09:55:21PM -0400, Jon Mitchell wrote: > > I suggest that we leave 65535 alone as a reserved AS. > > [JM] I think it should be clarified either way, and I think adding it to > the private use ASN range with this draft is the better approach for the > following reason. I consider this an after-the-fact registration (RFC > 5226 section 6.3) since this ASN seems to have widespread (mis-)use as > many implementations strip it using their remove private ASN knobs and > various networks undoubtedly have it deployed since it seems more than > since a large amount of Internet documentation including RFC 1930 seem > to include it as a private Use ASN. Also, if this document progress, > implementors will need to update their knobs and documentation anyway, > so they, IETF and IANA can all be on the same page, allowing this ASN to > be stripped if there are vendors that don't do it today (note even some > vendors with published documentation stating that private ASN range is > 64512-65534 strip 65535 with their remove private knobs). A strong part of my recommendation has to do with the fact that this AS has assumed a level of "magic" in some implementations. In the case of much older implementations on antique hardware may, in fact, be a magic internal value as it is UINT16_MAX. As a WG, we can deal with such things two ways: 1. Good grief, your code is that old and broken? Replace it/the hardware. Let's use it! 2. We don't really need that one extra AS lying around. Assume it may potentially be toxic and try to pay no attention to the man behind the curtains. I will agree with anyone that the above opinion is one of strong cynicism. :-) > Can I suggest your alternative proposal for > folks to comment on then is 4293918720 - 4294967295 (maintaining ~1M) or > are you suggesting a different range location or sizing? If you want ~1M, pick 2^20 addresses. You could probably even just do 2^16 and have most providers happy. (2^16 was the number I had in mind for my draft.) This lets you align the private AS number at a convenient as.dot boundary. I could even forsee someone's CLI saying PRIVATE. :-) -- Jeff From jrmitche@puck.nether.net Mon Jul 2 19:20:10 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204E711E80F5 for ; Mon, 2 Jul 2012 19:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pTUyLKIPARI for ; Mon, 2 Jul 2012 19:20:09 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id D030321F859F for ; Mon, 2 Jul 2012 19:20:08 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q632KEJG030287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2012 22:20:14 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q632KEiL030286; Mon, 2 Jul 2012 22:20:14 -0400 Date: Mon, 2 Jul 2012 22:20:14 -0400 From: Jon Mitchell To: "UTTARO, JAMES" Message-ID: <20120703022014.GC22452@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 02 Jul 2012 22:20:14 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 02:20:10 -0000 James - all of these operational concerns exist today with the existing private Use ASN range when it meets the Internet, and this document is just acknowledging what operators are already doing (making use of vendor specific knobs). Text that generally states private Use ASNs should not be advertised to the Internet is also in RFC 1930 - section 10. This document does not intend to dictate as much as acknowledge operators are using these knobs and providing some general guidance that they make sure such vendor implementations are updated in accordance with the draft if they are using them to remove private use ASNs towards the Internet before using the new range (providing transition guidance for when/if it's first published). In my experience, the L3VPN providers tend towards knobs like allow-as-in and as-override rather than remove-private so the statements would not be applicable as they don't rely on features that recognize private use ASNs, but in any case this document was not intended to define any features or changes to protocol behavior. As far as I've read (which is by no means every RFC) none of these vendor knobs that do AS_PATH manipulation are documented through the IETF process. As far as impact, there are are a number of private Use ASNs advertised to the Internet at any given time with no large (Internet wide) impact, but presumably there may be some small impact if a route with one of these ASNs was received by an ASN w/o an inbound AS_PATH filter to block them which was using such ASN internally to it's network and was therefore dropped. So the impact is limited mostly to connectivity to those who do no correctly remove the private ASNs. Jon On Tue, Jul 03, 2012 at 01:44:42AM +0000, UTTARO, JAMES wrote: > Jon, > > Seems reasonable.. I do not fully get the context.. You describe the fact that the increase in the number of AS across both l3VPN and Internet use cases are expanding rapidly.. No Doubt... So I see the creation of the new spaces and ranges.. My concerns are in re the Operations Considerations Section > > a) You are creating a set of rules for the internet routing context. > > " If private use ASNs are used and prefixes are originated from these > private use ASNs which are destined to the Internet, private use ASNs > must be removed from the AS_PATH before being advertised to the > global Internet. > " > How does this effect folks who use AS_PATH and/or AS_CONTENT in routing policy decisions? Better question is there an issue if all of the Private ASNs are stripped? > > b) You specify no rules in re the L3VPN routing context(s). > > c) Not sure how this would work? If someone screws up what is the collateral damage? > > " Prior to making use of the second, numerically > higher, range of these ASNs network operators should be confident any > implementation specific features or filters that recognize private > use ASNs have been updated to recognize both ranges correctly so that > no unintended announcement of private use ASNs to the Internet > " > > Thanks, > Jim Uttaro > > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jon Mitchell > Sent: Monday, July 02, 2012 12:49 PM > To: idr@ietf.org > Subject: [Idr] new ID on expansion of private use ASN range > > > IDR WG folks - > > I hope you can take some time from the normal debate(s) to consider and > review a fresh draft on expanding the ASN space reserved for Private > Use. All comments regarding content, clarity or structure welcome. > > Cheers, > > Jon > > -- > > A new version of I-D, draft-mitchell-idr-as-private-reservation-00.txt > has been successfully submitted by Jon Mitchell and posted to the IETF > repository. > > Filename: draft-mitchell-idr-as-private-reservation > Revision: 00 > Title: Autonomous System (AS) Reservation for Private Use > Creation date: 2012-06-20 > WG ID: Individual Submission > Number of pages: 4 > URL: > http://www.ietf.org/internet-drafts/draft-mitchell-idr-as-private-reservation-00.txt > Status: > http://datatracker.ietf.org/doc/draft-mitchell-idr-as-private-reservation > Htmlized: > http://tools.ietf.org/html/draft-mitchell-idr-as-private-reservation-00 > > > Abstract: > This document describes the reservation of Autonomous System numbers > (ASNs) that may be used within networks but should not be advertised > to the Internet, known as private use ASNs. This document enlarges > the total space available for private use ASNs by documenting the > reservation of a second larger range and updates RFC 1930. > > > > > The IETF Secretariat > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From christopher.morrow@gmail.com Mon Jul 2 21:16:10 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA2F11E812C for ; Mon, 2 Jul 2012 21:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlf3u8TROlNB for ; Mon, 2 Jul 2012 21:16:09 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6C911E8134 for ; Mon, 2 Jul 2012 21:16:09 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so10602322obb.31 for ; Mon, 02 Jul 2012 21:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hzZy5B5CtiZsEMymyT3/rkw+76MzIjLf7kt1imdUUzM=; b=R0OHzJH40/OrEChHtVC0PEq6HfYHaaLpR7EaQF31Wu9YYCe9JbpXLY0HdBPEWCG1s0 fV797deRBhdU4yETIf3C7gz2bA1KSfneYAQRehIxnctrDlZMiTXQEtOEFcaYvIfV6brv HVvvkHlFJtPH9HwcxpQY83QyHebSnQJdcFPqEJ825lqj2cRF3ynuA8uxp14qp15fVC2f RD0couwio/4w9giw7OOG7M3tGCYKEjPwFRhvK2RRxSz0hLa2OnY0VR90XPHgojTy3T3E V01zSLD5Cbj5JO8yoMgKrd7wgmbmMVGKwWidHbGl7VRweWyZN/HjWRECpQXtcwGzrNqr SRHA== MIME-Version: 1.0 Received: by 10.182.77.170 with SMTP id t10mr11059282obw.70.1341288975995; Mon, 02 Jul 2012 21:16:15 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.191.98 with HTTP; Mon, 2 Jul 2012 21:16:15 -0700 (PDT) In-Reply-To: <20120703015521.GB22452@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> Date: Tue, 3 Jul 2012 00:16:15 -0400 X-Google-Sender-Auth: UGKGPpow71snf1T47LReMmkpd5w Message-ID: From: Christopher Morrow To: Jon Mitchell Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 04:16:10 -0000 On Mon, Jul 2, 2012 at 9:55 PM, Jon Mitchell wrote: > A good case can be made for either in my opinion, but the IDR WG chairs > were OK with it being worked here. I can definitely send it also to > GROW list for comment either before or after it becomes a WG document, > or whatever makes the IDR WG chairs most comfortable. GROW WG chairs > are aware of it already... it's probably worthwhile (as a co-chair in GROW) to come clean about this bit: Jon asked both chair groups, we debated and mr scudder leaped. As to the whole idea, I think that jon puts forth some valid arguments for making more private-asns, though I fear the tomfoolery in code that already exists for special case thiings (private-asn, private-ip/ULA, accept-own-as, etc...ick) I'd like to see a good discussion on 'why not just get public asns for all this sort of stuff' If there never were private-asns, if asns were as plentiful as rain, why NOT just use them instead? What would be required to go on as we want, without making making more private-asns? -chris From internet-drafts@ietf.org Tue Jul 3 01:56:27 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D5821F87DA; Tue, 3 Jul 2012 01:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhQjMlS8-CT3; Tue, 3 Jul 2012 01:56:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1988121F8781; Tue, 3 Jul 2012 01:56:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120703085625.517.17345.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2012 01:56:25 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 08:56:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Extended Message support for BGP Author(s) : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-03.txt Pages : 4 Date : 2012-07-03 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This draft provides an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-extended-messages-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From randy@psg.com Tue Jul 3 02:05:30 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE6A21F87DB for ; Tue, 3 Jul 2012 02:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uW1QbsVPcWtR for ; Tue, 3 Jul 2012 02:05:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CFF5421F87D8 for ; Tue, 3 Jul 2012 02:05:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Slz39-000OdN-VE; Tue, 03 Jul 2012 09:05:36 +0000 Date: Tue, 03 Jul 2012 18:05:34 +0900 Message-ID: From: Randy Bush To: Jon Mitchell In-Reply-To: <20120702164834.GB13713@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 09:05:30 -0000 the motivation is not clearly stated. the only thing i could find was The limited size of the current range of private use ASNs has led to the usage of a number of implementation specific features that manipulate the AS_PATH or remove AS_PATH based loop prevention described in Section 9 of [RFC4271]. and it is not clear how more private ASs will ameliorate this. perhaps a clear statement of need, and why this is the best solution, right up front would be helpful. randy From jhaas@slice.pfrc.org Tue Jul 3 04:09:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C70021F8709 for ; Tue, 3 Jul 2012 04:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.211 X-Spam-Level: X-Spam-Status: No, score=-102.211 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NSUzOaDdt+m for ; Tue, 3 Jul 2012 04:09:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A941B21F86D6 for ; Tue, 3 Jul 2012 04:09:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 001FAD0D8; Tue, 3 Jul 2012 07:09:54 -0400 (EDT) Date: Tue, 3 Jul 2012 07:09:54 -0400 From: Jeffrey Haas To: Christopher Morrow Message-ID: <20120703110954.GC10161@pfrc> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 11:09:48 -0000 On Tue, Jul 03, 2012 at 12:16:15AM -0400, Christopher Morrow wrote: > I'd like to see a good discussion on 'why not just get public asns for > all this sort of stuff' > If there never were private-asns, if asns were as plentiful as rain, > why NOT just use them instead? What would be required to go on as we > want, without making making more private-asns? The answer probably is something along the lines of "ARIN charges $500 for a registration and $100 per year for 'maintenance'". Modulo waiving part of this if you're already paying for address space. (And I'm only picking on ARIN because they're the first site I checked.) Frankly I'd rather see the RIRs have *4-byte* AS number pricing in line with the cost of registering a domain ($20 US) and then kill this draft. (Note, also spoken as someone who was going to author a similar draft.) This would then move the desired feature to such tom-foolery as "AS hiding" as a feature, but such things don't require standardization. -- Jeff From randy@psg.com Tue Jul 3 04:17:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E5F21F876A for ; Tue, 3 Jul 2012 04:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaQDQ0iie--0 for ; Tue, 3 Jul 2012 04:17:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id AC30521F8754 for ; Tue, 3 Jul 2012 04:17:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sm17K-000OrC-Em; Tue, 03 Jul 2012 11:18:02 +0000 Date: Tue, 03 Jul 2012 20:18:01 +0900 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20120703110954.GC10161@pfrc> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703110954.GC10161@pfrc> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 11:17:56 -0000 > The answer probably is something along the lines of "ARIN charges $500 > for a registration and $100 per year for 'maintenance'". Modulo > waiving part of this if you're already paying for address space. (And > I'm only picking on ARIN because they're the first site I checked.) > > Frankly I'd rather see the RIRs have *4-byte* AS number pricing in > line with the cost of registering a domain ($20 US) and then kill this > draft. (Note, also spoken as someone who was going to author a > similar draft.) the real cost is address space. if you are gonna play this game fix the real problem. and, i sure hope you are not proposing to us this 'private' AS space as a cheap replacement for real AS space. the capex you save will be overwhelmed by the opex of maintaining a new global AS space co-joined with the traditional one. randy From jhaas@slice.pfrc.org Tue Jul 3 04:49:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D6121F8838 for ; Tue, 3 Jul 2012 04:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e94UO4UFnnJA for ; Tue, 3 Jul 2012 04:49:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E566D21F8828 for ; Tue, 3 Jul 2012 04:49:07 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E4037D102; Tue, 3 Jul 2012 07:49:13 -0400 (EDT) Date: Tue, 3 Jul 2012 07:49:13 -0400 From: Jeffrey Haas To: Randy Bush Message-ID: <20120703114913.GA11403@pfrc> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703110954.GC10161@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr wg Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 11:49:08 -0000 On Tue, Jul 03, 2012 at 08:18:01PM +0900, Randy Bush wrote: > > The answer probably is something along the lines of "ARIN charges $500 > > for a registration and $100 per year for 'maintenance'". Modulo > > waiving part of this if you're already paying for address space. (And > > I'm only picking on ARIN because they're the first site I checked.) > > > > Frankly I'd rather see the RIRs have *4-byte* AS number pricing in > > line with the cost of registering a domain ($20 US) and then kill this > > draft. (Note, also spoken as someone who was going to author a > > similar draft.) > > the real cost is address space. if you are gonna play this game fix the > real problem. A lot of people are using private-AS peering within a SP's address space just to get some routing. They don't need a public AS. They don't need provider independent space. They don't want to run an IGP since the failure modalities are ugly and are hard to mitigate. The next best protocol that gives them filtering is RIP. > and, i sure hope you are not proposing to us this 'private' AS space as > a cheap replacement for real AS space. No, I'm not. It's one of the reasons I'm happy with closer to 65K ASes than 1M. > the capex you save will be > overwhelmed by the opex of maintaining a new global AS space co-joined > with the traditional one. Right now an opex pain point for some larger providers is dealing with the absence of enough private ASes to keep their internal stuff, well, private. It's much the same argument as the providers who had run out of RFC 1918 space and do address squatting. I haven't heard any first-hand accounts of AS-squatting, and I hope I never do. -- Jeff From randy@psg.com Tue Jul 3 04:56:29 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9881021F8838 for ; Tue, 3 Jul 2012 04:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGpXNwSksOXx for ; Tue, 3 Jul 2012 04:56:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D8B0521F881F for ; Tue, 3 Jul 2012 04:56:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sm1ie-000OwR-63; Tue, 03 Jul 2012 11:56:36 +0000 Date: Tue, 03 Jul 2012 20:56:35 +0900 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20120703114913.GA11403@pfrc> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703110954.GC10161@pfrc> <20120703114913.GA11403@pfrc> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 11:56:29 -0000 ok, so let's see if i have it correctly. the case you are trying to support is the use of a private asn for a customer who is bgp multihomed to a single isp, and that provider has more than 1024 of this kind of customer. and the asns can not be re-used because they need as-loop prevention so can not turn as-loop detection off? randy From jhaas@slice.pfrc.org Tue Jul 3 05:21:50 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D67C21F8829 for ; Tue, 3 Jul 2012 05:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.222 X-Spam-Level: X-Spam-Status: No, score=-102.222 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK4x0AhNVx23 for ; Tue, 3 Jul 2012 05:21:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8425321F883D for ; Tue, 3 Jul 2012 05:21:49 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 21D8CD106; Tue, 3 Jul 2012 08:21:57 -0400 (EDT) Date: Tue, 3 Jul 2012 08:21:57 -0400 From: Jeffrey Haas To: Randy Bush Message-ID: <20120703122157.GB11403@pfrc> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703110954.GC10161@pfrc> <20120703114913.GA11403@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr wg Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 12:21:50 -0000 On Tue, Jul 03, 2012 at 08:56:35PM +0900, Randy Bush wrote: > ok, so let's see if i have it correctly. > > the case you are trying to support is the use of a private asn for a > customer who is bgp multihomed to a single isp, Or small set of providers using a coordinated internal space. > and that provider has > more than 1024 of this kind of customer. and the asns can not be > re-used because they need as-loop prevention so can not turn as-loop > detection off? There's that opex thing again. You'd have to track which customers are in sites that need to communicate with each other and make sure not to re-use numbers for those customer subsets. More numbers means less operational complexity. -- Jeff From robert@raszuk.net Tue Jul 3 05:43:19 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EBD21F86A3 for ; Tue, 3 Jul 2012 05:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo5tMRlj68z1 for ; Tue, 3 Jul 2012 05:43:18 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 119DD21F859B for ; Tue, 3 Jul 2012 05:43:17 -0700 (PDT) Received: (qmail 10179 invoked by uid 399); 3 Jul 2012 12:43:25 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.196.182) by mail1310.opentransfer.com with ESMTPM; 3 Jul 2012 12:43:25 -0000 X-Originating-IP: 83.31.196.182 Message-ID: <4FF2E8EB.7080604@raszuk.net> Date: Tue, 03 Jul 2012 14:43:23 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jeffrey Haas References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703110954.GC10161@pfrc> <20120703114913.GA11403@pfrc> <20120703122157.GB11403@pfrc> In-Reply-To: <20120703122157.GB11403@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr wg Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 12:43:19 -0000 Jeff, > There's that opex thing again. You'd have to track which customers are in > sites that need to communicate with each other and make sure not to re-use > numbers for those customer subsets. Regardless of opex how technically would you (proactively) go about tracking who needs to communicate with whom within your Internet customers (even if they are directly attached) ? R. From jhaas@slice.pfrc.org Tue Jul 3 06:09:03 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586C621F883F for ; Tue, 3 Jul 2012 06:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCQXFj6+3IxF for ; Tue, 3 Jul 2012 06:09:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 90D6F21F8823 for ; Tue, 3 Jul 2012 06:09:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B3DF9D0D8; Tue, 3 Jul 2012 09:09:08 -0400 (EDT) Date: Tue, 3 Jul 2012 09:09:08 -0400 From: Jeffrey Haas To: Enke Chen Message-ID: <20120703130908.GP18361@pfrc> References: <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> <4FE6441F.2050901@cisco.com> <4FE68269.4070704@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FE68269.4070704@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: 'Shane Amante' , "UTTARO, JAMES" , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 13:09:03 -0000 Enke, On Sat, Jun 23, 2012 at 07:58:49PM -0700, Enke Chen wrote: > Again, GR allows stale paths to be kept for a short duration. I do > not feel comfortable to have stale paths in the routing system for > hours or days. That would make BGP semi-static and semi-dynamic. > The implication is non-trivial, as pointed by others. It is worth noting that the scenario best covered by the persistence draft is when the impacted reachability is semi-static. In my opinion, a significant amount of the heat of this discussion comes from the well placed concerns that such a mechanism isn't well suited to highly dynamic routing information. There is also a lot of concern about when the routing information in question starts to get far enough away from its home network where the scope of whether something is stale is important or not. But in the case of semi-static routing data, some sort of "route stickiness" mechanism is probably appropriate to cover outages in redudnant infrastructure. The primary challenge as protocol developers is how to properly scope such a feature, especially in a protocol that is inter-domain by nature. -- Jeff From jhaas@slice.pfrc.org Tue Jul 3 06:11:09 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F248A21F8828 for ; Tue, 3 Jul 2012 06:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMNqHAg5TKCZ for ; Tue, 3 Jul 2012 06:11:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23121F8649 for ; Tue, 3 Jul 2012 06:11:08 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CE6FAD0D8; Tue, 3 Jul 2012 09:11:13 -0400 (EDT) Date: Tue, 3 Jul 2012 09:11:13 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20120703131113.GQ18361@pfrc> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703110954.GC10161@pfrc> <20120703114913.GA11403@pfrc> <20120703122157.GB11403@pfrc> <4FF2E8EB.7080604@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF2E8EB.7080604@raszuk.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr wg Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 13:11:09 -0000 On Tue, Jul 03, 2012 at 02:43:23PM +0200, Robert Raszuk wrote: > Regardless of opex how technically would you (proactively) go about > tracking who needs to communicate with whom within your Internet > customers (even if they are directly attached) ? In a very high latency protocol called "contractual agreements". Note also that the motivation is not specifically for Internet customers. -- Jeff From jrmitche@puck.nether.net Tue Jul 3 06:17:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A8821F8738 for ; Tue, 3 Jul 2012 06:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmnWZlnSKEZG for ; Tue, 3 Jul 2012 06:17:13 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 70A5B21F8862 for ; Tue, 3 Jul 2012 06:17:13 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q63DHKIu024842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2012 09:17:20 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q63DHKik024841; Tue, 3 Jul 2012 09:17:20 -0400 Date: Tue, 3 Jul 2012 09:17:20 -0400 From: Jon Mitchell To: Robert Raszuk Message-ID: <20120703131720.GA22598@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> <4FF1D47D.5020408@raszuk.net> <20120703011048.GA22452@puck.nether.net> <4FF2AB95.9020600@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF2AB95.9020600@raszuk.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jul 2012 09:17:21 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 13:17:14 -0000 Robert - this appears to be a non-private use case as you are providing service to multiple customers, and I support it and encourage you to work a proposal through the proper venue (RiR's) to get them to lower the bar for applying for larger blocks of public ASNs if necessary, however I think fixing this particular problem is orthogonal to the draft proposed. By definition, a Private Use reservation by IANA is unreserved for a specific customer and re-use is to be expected, in accordance with section 4.1 of RFC 5226. I don't expect this draft to fix/change every situation where AS_PATH manipulation hacks are used, but it should reduce the ones where they are used for communication within one administrative domain that can allocate their own numbering yet the number of sites exceeds 1022. Jon On Tue, Jul 03, 2012 at 10:21:41AM +0200, Robert Raszuk wrote: > > > Hi Jon, > > Thx for your reply. > > How about a bit different approach. > > Could we define a new AS allocation option that I get a registered > AS block of ASes rather then single AS as it is today ? > > So if I get registered AS (first three octets) and fourth octet ANY > then I would have no problem reg my case of any possible private AS > overlap with my customers. > > Just like we allocate prefixes ;) > > Thx, > R. > > > > > >Comments [JM] Inline... > > > >On Mon, Jul 02, 2012 at 07:03:57PM +0200, Robert Raszuk wrote: > >>Hi Jon, > >> > >>I have read your draft few days back and support adopting it as an > >>IDR WG doc. > >> > > > >[JM] Thanks. > > > >>However I have one question/suggestion ... > >> > >>Perhaps you recall some debates on the topic of reserving some > >>address chunk like 1918, but only for operator's use. > >> > >>Here with private AS numbers we actually are facing the same issue > >>today. Flat space introduces a bit of a difficulty when both my > >>internal ASes (example: data centers) as well as my customer's ASes > >>use the same private as number. > >> > >>This mandates the knobs like as_override or allowas_in to be applied > >>on all address families. > >> > >>The simplest way to solve it would be to define two blocks of 4 > >>octet private AS numbers .. One for multi-as operators and one for > >>stub networks. Maybe we could do the same for 2 octet AS numbers too > >>if we manage to find some decent block space. > > > >[JM] I'm not sure that adding a single second range would alleviate > >this. This seems to suggest that networks and the services they offer > >are somewhat static, or that multi-as network operators could not > >acquire services from each other? Given that little guidance is given > >to network operators on private Use ASNs by definition I'm not sure that > >we could easily define or expect your customers to abide by a defintion > >of whether they are a multi-AS operator versus a stub network unless you > >are the one doing the ASN assignment, in which case you shouldn't run > >into this issue. The only workable solution I can envision for your use > >case that would guarentee uniqueness is a GLOP style block reservations > >so anyone with a Public AS would have another set of private ASN to use, > >however this is so much more ambitious/complex than my proposal and > >would consume potentially a much larger portion of the pool. > > > >Unless others weigh in this is a problem space they feel needs to be > >solved, I expect that others will accept the existing knobs or the > >workaround of using a Public (RIR assigned) ASN to front services when > >connecting to private ASNs that customers own. I also think that this > >problem will be less likely to occur with a much wider range of ASNs > >available as David mentioned, assuming you are willing to renumber into > >a semi-random location in the new range. > > > > > >> > >>Cheers, > >>R. > >> > >> > >>>IDR WG folks - > >>> > >>>I hope you can take some time from the normal debate(s) to consider and > >>>review a fresh draft on expanding the ASN space reserved for Private > >>>Use. All comments regarding content, clarity or structure welcome. > >>> > >>>Cheers, > >>> > >>>Jon > >>> > >>>-- > >>> > >>>A new version of I-D, draft-mitchell-idr-as-private-reservation-00.txt > >>>has been successfully submitted by Jon Mitchell and posted to the IETF > >>>repository. > >>> > >>>Filename: draft-mitchell-idr-as-private-reservation > >>>Revision: 00 > >>>Title: Autonomous System (AS) Reservation for Private Use > >>>Creation date: 2012-06-20 > >>>WG ID: Individual Submission > >>>Number of pages: 4 > >>>URL: > >>>http://www.ietf.org/internet-drafts/draft-mitchell-idr-as-private-reservation-00.txt > >>>Status: > >>>http://datatracker.ietf.org/doc/draft-mitchell-idr-as-private-reservation > >>>Htmlized: > >>>http://tools.ietf.org/html/draft-mitchell-idr-as-private-reservation-00 > >>> > >>> > >>>Abstract: > >>> This document describes the reservation of Autonomous System numbers > >>> (ASNs) that may be used within networks but should not be advertised > >>> to the Internet, known as private use ASNs. This document enlarges > >>> the total space available for private use ASNs by documenting the > >>> reservation of a second larger range and updates RFC 1930. > >>> > >>> > >>> > >>> > >>>The IETF Secretariat > >>> > >>>_______________________________________________ > >>>Idr mailing list > >>>Idr@ietf.org > >>>https://www.ietf.org/mailman/listinfo/idr > >>> > >>> > >> > > > > > From jrmitche@puck.nether.net Tue Jul 3 06:39:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E32E21F87C6 for ; Tue, 3 Jul 2012 06:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wVsPjoIHmhP for ; Tue, 3 Jul 2012 06:39:42 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 764BF21F87C9 for ; Tue, 3 Jul 2012 06:39:42 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q63DdmLe026892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2012 09:39:48 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q63DdmvP026891; Tue, 3 Jul 2012 09:39:48 -0400 Date: Tue, 3 Jul 2012 09:39:48 -0400 From: Jon Mitchell To: Jeffrey Haas Message-ID: <20120703133948.GB22598@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703021238.GM18361@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120703021238.GM18361@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jul 2012 09:39:48 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 13:39:43 -0000 [JM] inline... On Mon, Jul 02, 2012 at 10:12:38PM -0400, Jeffrey Haas wrote: > Jon, > > On Mon, Jul 02, 2012 at 09:55:21PM -0400, Jon Mitchell wrote: > > > I suggest that we leave 65535 alone as a reserved AS. > > > > [JM] I think it should be clarified either way, and I think adding it to > > the private use ASN range with this draft is the better approach for the > > following reason. I consider this an after-the-fact registration (RFC > > 5226 section 6.3) since this ASN seems to have widespread (mis-)use as > > many implementations strip it using their remove private ASN knobs and > > various networks undoubtedly have it deployed since it seems more than > > since a large amount of Internet documentation including RFC 1930 seem > > to include it as a private Use ASN. Also, if this document progress, > > implementors will need to update their knobs and documentation anyway, > > so they, IETF and IANA can all be on the same page, allowing this ASN to > > be stripped if there are vendors that don't do it today (note even some > > vendors with published documentation stating that private ASN range is > > 64512-65534 strip 65535 with their remove private knobs). > > A strong part of my recommendation has to do with the fact that this AS has > assumed a level of "magic" in some implementations. In the case of much > older implementations on antique hardware may, in fact, be a magic internal > value as it is UINT16_MAX. As a WG, we can deal with such things two ways: > > 1. Good grief, your code is that old and broken? Replace it/the hardware. > Let's use it! > 2. We don't really need that one extra AS lying around. Assume it may > potentially be toxic and try to pay no attention to the man behind the > curtains. > > I will agree with anyone that the above opinion is one of strong cynicism. > :-) [JM] This is interesting, however given these ASNs are in use today and there is widespread mis-understanding that the 65535 ASN is a private use ASN already based on widespread vendor and other networking documentation, I think publishing this informational draft to officially allocate it as such is not going to cause a rush of changes to use it on devices this old. However new implementors would have clear guidance on what a private ASN if they are trying to comply with this draft/RFC if/when it's published and therefore could avoid this leaving this open to error in new implementations. > > Can I suggest your alternative proposal for > > folks to comment on then is 4293918720 - 4294967295 (maintaining ~1M) or > > are you suggesting a different range location or sizing? > > If you want ~1M, pick 2^20 addresses. You could probably even just do 2^16 > and have most providers happy. (2^16 was the number I had in mind for my > draft.) This lets you align the private AS number at a convenient as.dot > boundary. I could even forsee someone's CLI saying PRIVATE. :-) [JM] Although 65K private ASNs meet our near term needs, BGP is being used further and further down in the DC, with proposals that push it even to the host/hyper-visor. Therefore, given the large amount of space available, I think it makes sense to not limit this so artifically and be frustrating operators again 5-10 years from now as more and more creative network designs are proposed. As for any implementation hoping to make more asdot friendly implementations and encourage it's use, I think this sounds like a good reason not to make the range 16 bits! From jhaas@slice.pfrc.org Tue Jul 3 06:51:49 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B69521F8875 for ; Tue, 3 Jul 2012 06:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.932 X-Spam-Level: X-Spam-Status: No, score=-101.932 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ApZ3qxe+asb for ; Tue, 3 Jul 2012 06:51:48 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BCFF021F8865 for ; Tue, 3 Jul 2012 06:51:48 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D8F8ED02C; Tue, 3 Jul 2012 09:51:54 -0400 (EDT) Date: Tue, 3 Jul 2012 09:51:54 -0400 From: Jeffrey Haas To: Jon Mitchell Message-ID: <20120703135154.GT18361@pfrc> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703021238.GM18361@pfrc> <20120703133948.GB22598@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120703133948.GB22598@puck.nether.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 13:51:49 -0000 On Tue, Jul 03, 2012 at 09:39:48AM -0400, Jon Mitchell wrote: > > If you want ~1M, pick 2^20 addresses. You could probably even just do 2^16 > > and have most providers happy. (2^16 was the number I had in mind for my > > draft.) This lets you align the private AS number at a convenient as.dot > > boundary. I could even forsee someone's CLI saying PRIVATE. :-) > > [JM] Although 65K private ASNs meet our near term needs, BGP is being > used further and further down in the DC, with proposals that push it > even to the host/hyper-visor. Therefore, given the large amount of > space available, I think it makes sense to not limit this so artifically > and be frustrating operators again 5-10 years from now as more and more > creative network designs are proposed. As for any implementation hoping > to make more asdot friendly implementations and encourage it's use, I > think this sounds like a good reason not to make the range 16 bits! Mostly, if you're going to pick a range of addresses, just keep clean bit alignment. That would mean it's cleanly maskable in the code. If you pick 2^20, you can have PRIVATE1. through PRIVATE16.. While I'm only partially serious about something like this as a UI mechanism, one consideration is that 4-byte numbers in decimal format are big enough to be difficult for humans to parse for convenience and having such mneumonics might be very helpful. (To be contrary, canonical display and machine readable should always be as-plain formatted.) -- Jeff From jrmitche@puck.nether.net Tue Jul 3 07:16:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4429321F8823 for ; Tue, 3 Jul 2012 07:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFQj6j8CavYE for ; Tue, 3 Jul 2012 07:16:22 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 139A821F881C for ; Tue, 3 Jul 2012 07:16:22 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q63EGTRC032559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2012 10:16:29 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q63EGT6Q032558; Tue, 3 Jul 2012 10:16:29 -0400 Date: Tue, 3 Jul 2012 10:16:29 -0400 From: Jon Mitchell To: Randy Bush Message-ID: <20120703141629.GC22598@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jul 2012 10:16:29 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 14:16:23 -0000 Randy / Chris - Sorry in advance for the long message, I tend to be verbose. As I stated in my message to Robert, the use cases I was hoping to solve were a single customer that has requirements for much more than a thousand sites (not connected via an IGP which may have unique routing requirements or redundancy). I'd venture that the number of private ASNs (unattached from each other) deployed is at least an order of magnitude, if not several orders, higher than public ASNs allocated. This goes to Chris's message as well... there seems to be interest to ask for justification of use of these ASNs. The use of BGP has expanded so much in Enterprise networks especially for remote site connectivity, when no justification or process was required to use BGP like they utilized any other routing protocol internally. For those who want to move this to a Public ASN paradigm, I encourage you to submit the appropriate proposal to change both IANA/RIR policies to be so lenient that I can walk in and request 10K+ ASNs with minimal justification and low cost. I don't see much value in increasing the administrative burden on the network operators or the registries for ASN processing of these use cases, but if others do I'm at least interested in seeing the proposal and how well it is received. After all, 32 bit ASNs appear to be "like rain" because of the justification required today, while we at the same time have determined that the 32 bit IPv4 resource requiring less justification and using larger allocation blocks was not big enough long term for growth of networks. Also if we go down this method of using public ASNs for building larger internal networks, some folks may want knobs back to hide their multitude of ASNs from the Internet w/o deploying confederations or having to aggregate every prefix at a higher level, as they want to maintain a short and consistent AS_PATH for other reasons. Also, since private Use ASNs that are already allocated will likely exist for a really long time, and no one is proposing some sort of active notification/deprecation strategy as part of a proposal (yet) we will still need all the existing knobs / complexitiy in current vendor implementations on top of the new one. To me extending the one command (I'm aware of) that already recognizes private ASNs to strip a second range seems like a better approach and not overly complex. Please note as-override nor allow-as-in are examples of command that fit in this criteria, but their future use may be lessoned but not eliminated by this proposal. For the other use cases where SPs are providing service to customers who likely are using private ASNs (either in the existing range or the new), I encourage these SPs to see if a non-private ASN or range of ASNs can be allocated to them for these use cases and would support any proposals that reduce the justification needed to assign these if the existing RiR policies are deemeed to stingy. Jon On Tue, Jul 03, 2012 at 06:05:34PM +0900, Randy Bush wrote: > the motivation is not clearly stated. the only thing i could find > was > > The limited size of the current range of private use ASNs has led to > the usage of a number of implementation specific features that > manipulate the AS_PATH or remove AS_PATH based loop prevention > described in Section 9 of [RFC4271]. > > and it is not clear how more private ASs will ameliorate this. > > perhaps a clear statement of need, and why this is the best solution, > right up front would be helpful. > > randy From brian.peter.dickson@gmail.com Tue Jul 3 08:01:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1666821F8839 for ; Tue, 3 Jul 2012 08:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8k7YL+X3IQp for ; Tue, 3 Jul 2012 08:01:04 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE4121F8826 for ; Tue, 3 Jul 2012 08:01:04 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4334193wgb.13 for ; Tue, 03 Jul 2012 08:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bE0bQ8ysEx+0AE6qvfa6AeG0it5EhXJanDPAbjEgGsY=; b=IvFDgM73cWevkVN6DBAWc7fN/gARSIAY4/mqn6g0MkZJiRDNntATifIBBKxCh2FX5N oGSNChfnwTLRXNYQUmxG2cZr8vjcqj79fvlRz3+IG4AE+3mSY3m5Nov2R6nLoDThWJis okowoa3FqPssCOjKsUYnTwhD3KU2zKVwiEZZucrKqA8Zvna96ZXBcBjQ4qeXBVT4ho3x VtEACgxv835AsTB29IFYfr/b3Ii5AEsvgOHtJmlX1l5j9Bx9lNMvPf3BY5H8q3lSVTtH 3Eo+qxNcjzbmoBeZYoh8Z5JtNY7dc+PQg3cbSwnX2/x/vAAv4ql8EbtgwHGskmMIlSkA 02vQ== MIME-Version: 1.0 Received: by 10.216.173.136 with SMTP id v8mr2091615wel.167.1341327671459; Tue, 03 Jul 2012 08:01:11 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Tue, 3 Jul 2012 08:01:11 -0700 (PDT) In-Reply-To: References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> Date: Tue, 3 Jul 2012 11:01:11 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=0016e65a0d026281af04c3ee2f2a Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:01:06 -0000 --0016e65a0d026281af04c3ee2f2a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 3, 2012 at 12:16 AM, Christopher Morrow wrote: > > As to the whole idea, I think that jon puts forth some valid arguments > for making more private-asns, though I fear the tomfoolery in code > that already exists for special case thiings (private-asn, > private-ip/ULA, accept-own-as, etc...ick) > > IMHO, this draft should try to be "clean", i.e. deal only with new content (new private ASNs). Leave well enough alone (regarding 65535), or have it cleaned up separately with some *-bis draft or another. > I'd like to see a good discussion on 'why not just get public asns for > all this sort of stuff' > If there never were private-asns, if asns were as plentiful as rain, > why NOT just use them instead? What would be required to go on as we > want, without making making more private-asns? > > Um, the fact that however large the space is, it is still finite? Also, the use cases that "private" supports, generally won't or shouldn't be visible via AFI/SAFI == 1/1. The administrative overhead of centralized (versus local) management of ASNs that are "ships in the night" is clearly not justified. And, the local use cases already show need for >1024 ASNs within a single SP environment. (As for the concept of blocks of ASNs out of public space, instead of re-used private space - let's avoid the rat-hole that was 10xxx vs 1010xxx on long distance dial-around. If we have first- and second-class public ASNs, we will rapidly consume the whole 32-bit space. Just say no.) So, I am in favor of adoption as a WG draft. And, I suggest the author(s) remove 65535 from this. And, I see no reason not to "go big" on the amount of private 32-bit ASN space. Big means not having to update this in a year or five, and not having to have arguments over whether to expand the space to support those who actually need it. IMHO, 2^24 is about as big as can reasonably be expected to reserve without hamstringing the rest of the public space, and hopefully is enough for single SPs for a long time. 2^20 vs 2^24 is nit-picking, and 2^16 is short-sighted. Let's just bite the bullet and go 2^24. Also, IMHO, use outside of the proper "private" environment should be enforced via draconian language, hard-coded mechanisms, and the like. Having to support "public" use of "private" space isn't a reasonable requirement to place on future protocol elements (e.g. any kind of BGP security mechanisms.) The DFZ *must* *not* be polluted with private ASNs, ever. IMHO. Brian P.S. RIR policy/pricing mods for 32-bit ASNs, and IETF additional private 32-bit ASNs - should be treated as "OR", not "XOR", as in, there's no reason not to pursue both. They have different use cases, and both are justified. --0016e65a0d026281af04c3ee2f2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 3, 2012 at 12:16 AM, Christo= pher Morrow <morrowc.lists@gmail.com> wrote:

As to the whole idea, I think that jon puts forth some valid arguments
for making more private-asns, though I fear the tomfoolery in code
that already exists for special case thiings (private-asn,
private-ip/ULA, accept-own-as, etc...ick)


IMHO, this draft should try to be &quo= t;clean", i.e. deal only with new content (new private ASNs).

Leave well enough alone (regarding 65535), or have it clea= ned up separately with some *-bis draft or another.
=A0
I'd like to see a good discussion on 'why not just get public asns = for
all this sort of stuff'
If there never were private-asns, if asns were as plentiful as rain,
why NOT just use them instead? What would be required to go on as we
want, without making making more private-asns?

Um, the fact that however large the space is, it is still finit= e?
Also, the use cases that "private" supports, general= ly won't or shouldn't be visible via AFI/SAFI =3D=3D 1/1.
The administrative overhead of centralized (versus local) management o= f ASNs that are "ships in the night" is clearly not justified.
And, the local use cases already show need for >1024 ASNs within= a single SP environment.
(As for the concept of blocks of ASNs out of public space, instead of = re-used private space - let's avoid the rat-hole that was 10xxx vs 1010= xxx on long distance dial-around. If we have first- and second-class public= ASNs, we will rapidly consume the whole 32-bit space. Just say no.)

So, I am in favor of adoption as a WG draft.
= And, I suggest the author(s) remove 65535 from this.
And, I see n= o reason not to "go big" on the amount of private 32-bit ASN spac= e.

Big means not having to update this in a year or five, = and not having to have arguments over whether to expand the space to suppor= t those who actually need it.
IMHO, 2^24 is about as big as can r= easonably be expected to reserve without hamstringing the rest of the publi= c space, and hopefully is enough for single SPs for a long time.
2^20 vs 2^24 is nit-picking, and 2^16 is short-sighted. Let's just= bite the bullet and go 2^24.

Also, IMHO, use outs= ide of the proper "private" environment should be enforced via dr= aconian language, hard-coded mechanisms, and the like.
Having to support "public" use of "private" space = isn't a reasonable requirement to place on future protocol elements (e.= g. any kind of BGP security mechanisms.)
The DFZ *must* *not* be = polluted with private ASNs, ever. IMHO.=A0

Brian

P.S. RIR policy/pricing mods = for 32-bit ASNs, and IETF additional private 32-bit ASNs - should be treate= d as "OR", not "XOR", as in, there's no reason not = to pursue both. They have different use cases, and both are justified. --0016e65a0d026281af04c3ee2f2a-- From robert@raszuk.net Tue Jul 3 08:08:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5E221F888B for ; Tue, 3 Jul 2012 08:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKDF7ryw6kOj for ; Tue, 3 Jul 2012 08:08:32 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7069321F8888 for ; Tue, 3 Jul 2012 08:08:32 -0700 (PDT) Received: (qmail 12153 invoked by uid 399); 3 Jul 2012 15:08:40 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.196.182) by mail1310.opentransfer.com with ESMTPM; 3 Jul 2012 15:08:40 -0000 X-Originating-IP: 83.31.196.182 Message-ID: <4FF30AF6.1090203@raszuk.net> Date: Tue, 03 Jul 2012 17:08:38 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jon Mitchell References: <20120702164834.GB13713@puck.nether.net> <4FF1D47D.5020408@raszuk.net> <20120703011048.GA22452@puck.nether.net> <4FF2AB95.9020600@raszuk.net> <20120703131720.GA22598@puck.nether.net> In-Reply-To: <20120703131720.GA22598@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:08:33 -0000 Jon, > I don't expect this draft to fix/change every > situation where AS_PATH manipulation hacks are used, but it should > reduce the ones where they are used for communication within one > administrative domain that can allocate their own numbering yet the > number of sites exceeds 1022. How about if each of such internal site uses the same *single* private AS number and you perform loop detection/troubleshooting by use of SOO extended community ? It is local to you to assign it's value (6 octets seems wide enough) and it has been already widely implemented. Today it is used mainly for multihomed VPN sites, but it could be applied equally well to your internal sites. Thx, R. From heas@shrubbery.net Tue Jul 3 08:26:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4078D21F8755 for ; Tue, 3 Jul 2012 08:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qXmSmxiWlZK for ; Tue, 3 Jul 2012 08:26:22 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9728221F8753 for ; Tue, 3 Jul 2012 08:26:22 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 8911E9A224; Tue, 3 Jul 2012 15:26:31 +0000 (UTC) Date: Tue, 3 Jul 2012 08:26:31 -0700 From: heasley To: Jeffrey Haas Message-ID: <20120703152631.GD3300@shrubbery.net> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703110954.GC10161@pfrc> <20120703114913.GA11403@pfrc> <20120703122157.GB11403@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120703122157.GB11403@pfrc> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr wg Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:26:23 -0000 Tue, Jul 03, 2012 at 08:21:57AM -0400, Jeffrey Haas: > > and that provider has > > more than 1024 of this kind of customer. and the asns can not be > > re-used because they need as-loop prevention so can not turn as-loop > > detection off? > > There's that opex thing again. You'd have to track which customers are in > sites that need to communicate with each other and make sure not to re-use > numbers for those customer subsets. send a default route to those customers, or let them build one based on a backbone route, and leave loop detection alone. From jrmitche@puck.nether.net Tue Jul 3 08:42:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9E021F8746 for ; Tue, 3 Jul 2012 08:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNPafFr+0voS for ; Tue, 3 Jul 2012 08:42:34 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id BB33921F873A for ; Tue, 3 Jul 2012 08:42:33 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q63FgfkJ011442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2012 11:42:41 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q63Fgf2R011441; Tue, 3 Jul 2012 11:42:41 -0400 Date: Tue, 3 Jul 2012 11:42:41 -0400 From: Jon Mitchell To: Robert Raszuk Message-ID: <20120703154241.GA7103@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> <4FF1D47D.5020408@raszuk.net> <20120703011048.GA22452@puck.nether.net> <4FF2AB95.9020600@raszuk.net> <20120703131720.GA22598@puck.nether.net> <4FF30AF6.1090203@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF30AF6.1090203@raszuk.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jul 2012 11:42:41 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:42:34 -0000 [JM] Inline.. On Tue, Jul 03, 2012 at 05:08:38PM +0200, Robert Raszuk wrote: > Jon, > > >I don't expect this draft to fix/change every > >situation where AS_PATH manipulation hacks are used, but it should > >reduce the ones where they are used for communication within one > >administrative domain that can allocate their own numbering yet the > >number of sites exceeds 1022. > > How about if each of such internal site uses the same *single* > private AS number and you perform loop detection/troubleshooting by > use of SOO extended community ? > > It is local to you to assign it's value (6 octets seems wide enough) > and it has been already widely implemented. [JM] Robert - are you are saying you do not support the draft as I can use hacks/workarounds such as allow-as-in or as-override in conjunction with site of origin to add loop detection or am I misunderstanding your suggestion? What if I want to use BGP as designed for AS_PATH loop detection and be able to do standard troubleshooting/filtering based on AS_PATH and not worry about (mis-)configuration of soo? Why not have a range of private ASNs large enough to support internal networking requirements of organizations w/o the use of more and more features? From robert@raszuk.net Tue Jul 3 08:54:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3C211E8168 for ; Tue, 3 Jul 2012 08:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzRj2XJAUqJK for ; Tue, 3 Jul 2012 08:54:20 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 5C39311E8167 for ; Tue, 3 Jul 2012 08:54:20 -0700 (PDT) Received: (qmail 12601 invoked by uid 399); 3 Jul 2012 15:54:28 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.196.182) by mail1310.opentransfer.com with ESMTPM; 3 Jul 2012 15:54:28 -0000 X-Originating-IP: 83.31.196.182 Message-ID: <4FF315B2.5020804@raszuk.net> Date: Tue, 03 Jul 2012 17:54:26 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jon Mitchell References: <20120702164834.GB13713@puck.nether.net> <4FF1D47D.5020408@raszuk.net> <20120703011048.GA22452@puck.nether.net> <4FF2AB95.9020600@raszuk.net> <20120703131720.GA22598@puck.nether.net> <4FF30AF6.1090203@raszuk.net> <20120703154241.GA7103@puck.nether.net> In-Reply-To: <20120703154241.GA7103@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:54:21 -0000 Jon, The point I am making is that you no always have full control on what private AS your customer chooses to use. If you use private AS within your domain there is risk that you would end up using the same AS number as your customers - so all tricks like private AS stripping, allowas-in or as-override would still need to be applied. And once you apply it once you better apply it everywhere as non uniform configuration which does not follow templates is the worst NOC nightmare. That is no matter how many private ASes are in the pool. I am bringing SOO as an example as this is single time configuration when you establish eBGP session to a given site to see what would be missing to realize your objective. The main difference is that you have full control over SOO value. > [JM] Robert - are you are saying you do not support the draft No - however seeing comments from others I am getting less and less keen on it - more towards being just neutral. Clearly just reserving the pool does no harm to anyone ;-) Rgs, R. > [JM] Inline.. > > On Tue, Jul 03, 2012 at 05:08:38PM +0200, Robert Raszuk wrote: >> Jon, >> >>> I don't expect this draft to fix/change every >>> situation where AS_PATH manipulation hacks are used, but it should >>> reduce the ones where they are used for communication within one >>> administrative domain that can allocate their own numbering yet the >>> number of sites exceeds 1022. >> >> How about if each of such internal site uses the same *single* >> private AS number and you perform loop detection/troubleshooting by >> use of SOO extended community ? >> >> It is local to you to assign it's value (6 octets seems wide enough) >> and it has been already widely implemented. > > [JM] Robert - are you are saying you do not support the draft as I can > use hacks/workarounds such as allow-as-in or as-override in conjunction > with site of origin to add loop detection or am I misunderstanding your > suggestion? What if I want to use BGP as designed for AS_PATH loop > detection and be able to do standard troubleshooting/filtering based on > AS_PATH and not worry about (mis-)configuration of soo? Why not have a > range of private ASNs large enough to support internal networking > requirements of organizations w/o the use of more and more features? > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From christopher.morrow@gmail.com Tue Jul 3 11:50:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAE011E80C1 for ; Tue, 3 Jul 2012 11:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LX6BdmzhV5+B for ; Tue, 3 Jul 2012 11:50:46 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3338611E80F2 for ; Tue, 3 Jul 2012 11:50:46 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so11780442obb.31 for ; Tue, 03 Jul 2012 11:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Mr0pVn5G34dhLs01whB8U9LQvMhH8rpWgHy59yxI+90=; b=urjSbKV63U3bOV4dLpa+8R3trsmAj2MXdxIz4Tu/ZByziYwSWVtfNktw9QJBQyczbl tsdcY0QNfgLUxSjRBpIKWHsDsTpJ9bMOpVUTpRCezsQy4kMixcgc1deP/qYtqSnF0P31 0b7NLyAHbgoFUeb+mzaBq1Rfz0IPzG/9HfoVc4hf03T2RLVLcq0uW+TGtAJeEOJp0iju tMO+DFVomETWz81hh2XGa0xcoprYy+QsX8f5gk/Xfn2+Oi5UosYepFb8stz1fnHNZ7rB MBFRU9MSyql6UZbVxhHIivg8sJFIDPS538n4iJHO/g3ii/9SYt62dBE0pf5A7nR6dQw3 koCg== MIME-Version: 1.0 Received: by 10.182.164.8 with SMTP id ym8mr14152331obb.51.1341341454421; Tue, 03 Jul 2012 11:50:54 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.191.98 with HTTP; Tue, 3 Jul 2012 11:50:54 -0700 (PDT) In-Reply-To: <4FF315B2.5020804@raszuk.net> References: <20120702164834.GB13713@puck.nether.net> <4FF1D47D.5020408@raszuk.net> <20120703011048.GA22452@puck.nether.net> <4FF2AB95.9020600@raszuk.net> <20120703131720.GA22598@puck.nether.net> <4FF30AF6.1090203@raszuk.net> <20120703154241.GA7103@puck.nether.net> <4FF315B2.5020804@raszuk.net> Date: Tue, 3 Jul 2012 14:50:54 -0400 X-Google-Sender-Auth: N11B95AogDJvh1WcknWV5G3bmtc Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 18:50:47 -0000 On Tue, Jul 3, 2012 at 11:54 AM, Robert Raszuk wrote: > Jon, > > The point I am making is that you no always have full control on what > private AS your customer chooses to use. > > If you use private AS within your domain there is risk that you would end up > using the same AS number as your customers - so all tricks like private AS > stripping, allowas-in or as-override would still need to be applied. > isn't the case of 'give customers an ASN to peer with us in more than one location' just: RFC2270 why would you pollute your RIB and your configs with private-asn when a public is available for this? (or a reason to get a public is available for this). > And once you apply it once you better apply it everywhere as non uniform > configuration which does not follow templates is the worst NOC nightmare. yes, less complex config, win. > That is no matter how many private ASes are in the pool. > right, because you used 2270 and a public asn. (sorry for hijacking) -chris > I am bringing SOO as an example as this is single time configuration when > you establish eBGP session to a given site to see what would be missing to > realize your objective. The main difference is that you have full control > over SOO value. > > >> [JM] Robert - are you are saying you do not support the draft > > No - however seeing comments from others I am getting less and less keen on > it - more towards being just neutral. Clearly just reserving the pool does > no harm to anyone ;-) > > Rgs, > R. > > > >> [JM] Inline.. >> >> On Tue, Jul 03, 2012 at 05:08:38PM +0200, Robert Raszuk wrote: >>> >>> Jon, >>> >>>> I don't expect this draft to fix/change every >>>> situation where AS_PATH manipulation hacks are used, but it should >>>> reduce the ones where they are used for communication within one >>>> administrative domain that can allocate their own numbering yet the >>>> number of sites exceeds 1022. >>> >>> >>> How about if each of such internal site uses the same *single* >>> private AS number and you perform loop detection/troubleshooting by >>> use of SOO extended community ? >>> >>> It is local to you to assign it's value (6 octets seems wide enough) >>> and it has been already widely implemented. >> >> >> [JM] Robert - are you are saying you do not support the draft as I can >> use hacks/workarounds such as allow-as-in or as-override in conjunction >> with site of origin to add loop detection or am I misunderstanding your >> suggestion? What if I want to use BGP as designed for AS_PATH loop >> detection and be able to do standard troubleshooting/filtering based on >> AS_PATH and not worry about (mis-)configuration of soo? Why not have a >> range of private ASNs large enough to support internal networking >> requirements of organizations w/o the use of more and more features? >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From christopher.morrow@gmail.com Tue Jul 3 11:54:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3422111E8178 for ; Tue, 3 Jul 2012 11:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yud6RB0ThxG4 for ; Tue, 3 Jul 2012 11:54:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADDC611E8174 for ; Tue, 3 Jul 2012 11:54:21 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so11784613obb.31 for ; Tue, 03 Jul 2012 11:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=C2dc4HPL3CMVmbmaUhuBRMVUPJtmD5RZ+hwy0PYFU0M=; b=QNhccwcHA7O1Fi3lWpyvzlT/z9Wo4rDMjiBRgeefJ7YbXJWCaQ4fWEWWE5ZvzCKdeR vv2RN6Wg3pfXPjKIPlUXDPh5NaSv1RuoblbQIre+o3F12MzGyxleCAPnBoN08viPjZ7M iDt/1vFeEqm1w/RLf/JQSQNf5U5BFRkY+EvbDb1LONLDosRRu6H8N07jnVAOEMawXwNd vatt9WcF8i/A32GB8AQCUP07zYx2v0r3ET6MazKHeFoy0NQk/4pB13/Ikq0PDrE7B+8c rI0xvuN65AMgZdziNBz90c3vAGCsOR/l2Ornb6HL6P9hieMRCVqXI8AWraZx2JauC2y3 EYvA== MIME-Version: 1.0 Received: by 10.182.77.170 with SMTP id t10mr14243858obw.70.1341341670103; Tue, 03 Jul 2012 11:54:30 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.191.98 with HTTP; Tue, 3 Jul 2012 11:54:29 -0700 (PDT) In-Reply-To: <20120703141629.GC22598@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> <20120703141629.GC22598@puck.nether.net> Date: Tue, 3 Jul 2012 14:54:29 -0400 X-Google-Sender-Auth: -EcqnT-q7_OGr7MBoehjti_ot10 Message-ID: From: Christopher Morrow To: Jon Mitchell Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 18:54:22 -0000 On Tue, Jul 3, 2012 at 10:16 AM, Jon Mitchell wrote: > that I can walk in and request 10K+ ASNs with minimal justification and > low cost. I don't see much value in increasing the administrative I would bet that if you were a large enterprise WAN like, say: "the Limited" (clothing store) that has +1.5 endsites, you could say to ARIN (for instance): "Hi, I have 1.5k endsites, all connected over a third-party WAN, we use BGP and have unique routing policies for each site, can I have 1.5k TODAY and since I plan to expand 500 sites this year 1k tomorrow" you would probably get that allocated, if you can deal with 4-byte. it's worth asking the hostmaster people I suppose. -chris From farmer@umn.edu Tue Jul 3 13:06:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9001F21F8782 for ; Tue, 3 Jul 2012 13:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1fPRImFxgZc for ; Tue, 3 Jul 2012 13:06:50 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id C1DBD21F875A for ; Tue, 3 Jul 2012 13:06:50 -0700 (PDT) Received: from mail-gg0-f171.google.com (mail-gg0-f171.google.com [209.85.161.171]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 3 Jul 2012 15:06:46 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-gg0-f171.google.com [209.85.161.171] #+LO+TR X-Umn-Classification: local Received: by mail-gg0-f171.google.com with SMTP id i1so10803741ggm.16 for ; Tue, 03 Jul 2012 13:06:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=JFxeomvI/cZ73iRHnOv6pQ3gWjcuqHaLf+RRkWjzv/E=; b=P9qBTbgMc4NXxW1TzLkNHm9VLapv45N+h3byj9msccfIHpdu5Bnr4itqZiE651//Is E895/g8FacoZOtBD22rNS22r3kX+6XV1oXP8WwHkxyQGWGfrOUfOz6fbTZUCBEje6hrC 2HYglSdwK+9OY6uEXVNuUhkneOkzz5aS2chUad9YIGfba2/xUire1In74SvDik7BY5ep ED2UfJkktXqqAnD16eVkE13qS65wMEakhWBly1ttKXIfYDANwUAbpcHgFgpA7inTHtD8 HUovBkWPRDGgDEEv98Q+nRlMpjUIQENwoVyn9oIuMy9O92XTjbXy6NG8Z5X7asHeXf5f /DIw== Received: by 10.50.237.6 with SMTP id uy6mr7132942igc.52.1341346005751; Tue, 03 Jul 2012 13:06:45 -0700 (PDT) Received: from x-134-84-88-76.nts.umn.edu ([2607:ea00:101:2001:223:dfff:fe83:bf68]) by mx.google.com with ESMTPS id if4sm12050378igc.10.2012.07.03.13.06.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jul 2012 13:06:45 -0700 (PDT) Message-ID: <4FF350D3.2030205@umn.edu> Date: Tue, 03 Jul 2012 15:06:43 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Christopher Morrow References: <20120702164834.GB13713@puck.nether.net> <20120703141629.GC22598@puck.nether.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnbzLvhJegdLk/4Gyp8hWF4idC8Hy9fdnnRsUM67CZo2VSKiBzGJ2+X/Q0o5jcbXNLj6WFx Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 20:06:52 -0000 On 7/3/12 13:54 CDT, Christopher Morrow wrote: > On Tue, Jul 3, 2012 at 10:16 AM, Jon Mitchell wrote: >> that I can walk in and request 10K+ ASNs with minimal justification and >> low cost. I don't see much value in increasing the administrative > > I would bet that if you were a large enterprise WAN like, say: "the > Limited" (clothing store) that has +1.5 endsites, you could say to > ARIN (for instance): "Hi, I have 1.5k endsites, all connected over a > third-party WAN, we use BGP and have unique routing policies for each > site, can I have 1.5k TODAY and since I plan to expand 500 sites this > year 1k tomorrow" you would probably get that allocated, if you can > deal with 4-byte. So Chris, why does clothing store with 1.5k endsites want those ASNs publicly registered. I tend toward why not, but they frequently seem to not want them publicly registered. They clam it has something to do with security. I don't buy it, but on the other had it is their network. A lot of enterprise networks are starting to use BGP internally, but they seems to only want to deal with eBGP and no iBGP peerings or only very limited iBGP. So they give every router or pair of site routers its own Private ASN. I seen some with fairly elaborate routing policy, that would qualify as unique routing policy. But many don't they just used Private ASN to avoid iBGP, without any unique routing policy. So, currently Public ASN must be justified by unique routing policy, I believe this essentially comes from RFC 1930, this is the guidance from the IETF that the RIRs are using. Actually most RIR also currently require multi-homing to justify an ASN as well. However, this is primarily attributed to scarcity of 2-byte ASNs, but could probably go away now that we have 4-byte ASNs. But using an ASN so you don't have to deal with iBGP isn't justified by the unique routing policy criteria of RFC 1930. If we don't think a unique routing policy is necessary any longer then maybe the IETF should give that guidance to the RIRs. Realistically, even in your example of the large clothing store chain, I'll bet you there are not multiple unique routing policies involved, its because they want eBGP going to each of the endsites. Right or wrong, lots of people use private ASNs so that most if not all of their peerings are eBGP and not iBGP. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From brian.peter.dickson@gmail.com Tue Jul 3 13:20:32 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABC611E80BC for ; Tue, 3 Jul 2012 13:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaiSCxhA775N for ; Tue, 3 Jul 2012 13:20:31 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 274DA11E8085 for ; Tue, 3 Jul 2012 13:20:30 -0700 (PDT) Received: by werp11 with SMTP id p11so1860526wer.31 for ; Tue, 03 Jul 2012 13:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OaJdpOZepPJ3SJQhfOD9fc/3De1XRQbSAKyXpVBhCwA=; b=WpW+5Ie2mTav3TsSFjgXkxG2yO72N17glxLX+22g5z/g/dKjUhkLcayh8+NUg82ZDF AE/g4UJNQHKv5ViaM8Z/cTtPxqCD6tn9zPVgrh8OIHUy/Q2LWGa0pIOTHYhSgFoL8p05 uHvXUDKKae7qh0OCKxN7Nc1eK1vCAdvgQLDUSrcdQ/8z4S9ISZTsYVC8hPEliYRAUauY ooDruxGdOgy35/5p2xwB+st61wsc8/76NF0LopvqWFfuxifXbKKXSQlhJ9Ecpw5kxLH2 idpZmBkf1nrWC98cNxfxkAMXRuhjtFnosBcpmYiiciq/Gov/NEzeSrJrnIrwapR8syM0 Yzfg== MIME-Version: 1.0 Received: by 10.180.86.133 with SMTP id p5mr22807329wiz.17.1341346839145; Tue, 03 Jul 2012 13:20:39 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Tue, 3 Jul 2012 13:20:38 -0700 (PDT) In-Reply-To: References: <20120702164834.GB13713@puck.nether.net> <4FF1D47D.5020408@raszuk.net> <20120703011048.GA22452@puck.nether.net> <4FF2AB95.9020600@raszuk.net> <20120703131720.GA22598@puck.nether.net> <4FF30AF6.1090203@raszuk.net> <20120703154241.GA7103@puck.nether.net> <4FF315B2.5020804@raszuk.net> Date: Tue, 3 Jul 2012 16:20:38 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=f46d0442820ede2b6404c3f2a5bc Cc: idr@ietf.org, robert@raszuk.net Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 20:20:32 -0000 --f46d0442820ede2b6404c3f2a5bc Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 3, 2012 at 2:50 PM, Christopher Morrow wrote: > On Tue, Jul 3, 2012 at 11:54 AM, Robert Raszuk wrote: > > isn't the case of 'give customers an ASN to peer with us in more than > one location' just: RFC2270 > why would you pollute your RIB and your configs with private-asn when > a public is available for this? (or a reason to get a public is > available for this). No. For lots of reasons. RFC 2270 is (a) informational, (b) 14 years old, and (c) talking about using (and re-using) a _SINGLE_ _private_ ASN for multiple customers. If you have a single customer with multiple, isolated, non-contiguous sites, a single ASN won't necessarily work for _that_ customer. In other words, while it might work some of the time, it won't work in every case. There are lots of possible similar corner cases. (E.g. "back-door" routes as either preferred, or as back-up paths, means that more than just default is needed.) (Similarly, any kind of tunnel/VPN/GRE/whatever, implemented by the customer without the SP's involvement.) One's RIB is polluted by routes, regardless of the attributes of the routes. There may be very slight benefit to the same ASN being used, but generally only if the rest of the attributes are identical. For large customers with lots of sites, this won't hold true. And, while life is easier when all the ASNs you have are unique _within_ your universe of configs, nothing changes if some of those ASNs are re-used by someone else (out of sight from your perspective). > > And once you apply it once you better apply it everywhere as non uniform > > configuration which does not follow templates is the worst NOC nightmare. > > yes, less complex config, win. > Config complexity is orthogonal to standardization via automation. It is only when you over-ride the tools that you lose the scaling war. If you have tools that understand a dozen or so variants, and fully capture the requirements of each, you can plug in necessary values (e.g. from a database or other info source), and crank out the configs. This includes, for example, a private routing registry, where prefixes are keyed off of customer objects, including private ASN origin: fields. Having mapping references _back_ from the config to the template and customer, is key. (Adding your own structure to unstructured description fields has worked well for me.) (If you have to dumb things down, you will end up with only dumb customers. Dumb customers are a commodity, which is ends in a price war with eroded margins.) Reality trumps models. 3 nanoseconds per meter might not be acceptable to some, but it is the law. :-) Brian --f46d0442820ede2b6404c3f2a5bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 3, 2012 at 2:50 PM, Christop= her Morrow <morrowc.lists@gmail.com> wrote:
On Tue, Jul 3, 2012 at 11:54 AM, Robert Raszuk <robert@raszuk.net> wrote:

isn't the case of 'give customers an ASN to peer with us in m= ore than
one location' just: RFC2270
why would you pollute your RIB and your configs with private-asn when
a public is available for this? (or a reason to get a public is
available for this).

No. For lots of reason= s.

RFC 2270 is (a) informational, (b) 14 years old= , and (c) talking about using (and re-using) a _SINGLE_ _private_ ASN for m= ultiple customers.

If you have a single customer with multiple, isolated, = non-contiguous sites, a single ASN won't necessarily work for _that_ cu= stomer.
In other words, while it might work some of the time, it = won't work in every case. There are lots of possible similar corner cas= es.
(E.g. "back-door" routes as either preferred, or as back-up = paths, means that more than just default is needed.)
(Similarly, = any kind of tunnel/VPN/GRE/whatever, implemented by the customer without th= e SP's involvement.)

One's RIB is polluted by routes, regardless of the = attributes of the routes.
There may be very slight benefit to the= same ASN being used, but generally only if the rest of the attributes are = identical.
For large customers with lots of sites, this won't hold true.

And, while life is easier when all the ASNs you have a= re unique _within_ your universe of configs,
nothing changes if s= ome of those ASNs are re-used by someone else (out of sight from your persp= ective).
=A0
> And once you apply it once you better apply it everywhere as non unifo= rm
> configuration which does not follow templates is the worst NOC nightma= re.

yes, less complex config, win.

Co= nfig complexity is orthogonal to standardization via automation.
= It is only when you over-ride the tools that you lose the scaling war.

If you have tools that understand a dozen or so variant= s, and fully capture the requirements
of each, you can plug in ne= cessary values (e.g. from a database or other info source),
and c= rank out the configs. This includes, for example, a private routing registr= y, where
prefixes are keyed off of customer objects, including private ASN orig= in: fields.
=A0
Having mapping references _back_ from t= he config to the template and customer, is key.
(Adding your own = structure to unstructured description fields has worked well for me.)

(If you have to dumb things down, you will end up with= only dumb customers.
Dumb customers are a commodity, which is ends in = a price war with eroded margins.)

Reality trumps m= odels. 3 nanoseconds per meter might not be acceptable to some,
but it is the law. :-)

Brian
--f46d0442820ede2b6404c3f2a5bc-- From jrmitche@puck.nether.net Tue Jul 3 13:32:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD2121F8562 for ; Tue, 3 Jul 2012 13:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPIP9oUHCalX for ; Tue, 3 Jul 2012 13:32:45 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 16A6D21F854E for ; Tue, 3 Jul 2012 13:32:45 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q63KWpmj023720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2012 16:32:51 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q63KWp4U023717; Tue, 3 Jul 2012 16:32:51 -0400 Date: Tue, 3 Jul 2012 16:32:51 -0400 From: Jon Mitchell To: Christopher Morrow Message-ID: <20120703203251.GA6608@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> <20120703141629.GC22598@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jul 2012 16:32:51 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 20:32:45 -0000 On Tue, Jul 03, 2012 at 02:54:29PM -0400, Christopher Morrow wrote: > On Tue, Jul 3, 2012 at 10:16 AM, Jon Mitchell wrote: > > that I can walk in and request 10K+ ASNs with minimal justification and > > low cost. I don't see much value in increasing the administrative > > I would bet that if you were a large enterprise WAN like, say: "the > Limited" (clothing store) that has +1.5 endsites, you could say to > ARIN (for instance): "Hi, I have 1.5k endsites, all connected over a > third-party WAN, we use BGP and have unique routing policies for each > site, can I have 1.5k TODAY and since I plan to expand 500 sites this > year 1k tomorrow" you would probably get that allocated, if you can > deal with 4-byte. [JM] Besides filling out 1500 requests, waiting for 1500 tickets to pass justification, filling out 1500 RSA's with the correct ticket numbers, and paying $750K upfront and ongoing maintanance to ARIN, what added benefit would "the Limited" get for using public ASN's in this presumably non-Internet use case? > > it's worth asking the hostmaster people I suppose. > [JM] Since they seem to be in NoVA, just did. "Sue" at the ARIN helpdesk clarified that each request would have to be justified seperately with diagrams, there are no block assignments, and that she had not seen a "unique routing" policy justification fly in the many years she had worked there, only multi-homing requests go through. She recommended for the scenario I laid out that I use private use ASNs. I think what you are proposing is a huge cultural shift / re-education on the definition of appropriate use of public ASNs, which is certainly possible but I'm unclear the value proposition since I'm thinking the existing private ASN's deployed are not going away so we will have to deal with this new way of using public ASN's for non-public applications as well as all the knobs around AS_PATH manipulation for overlapping and private ASN removal as well. All my proposal does is allow individual organizations to grow beyond the current range, it does not aim to address the difficulities of connecting various organizations with overlapping private use ASNs. From randy@psg.com Tue Jul 3 17:12:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D73311E80B7 for ; Tue, 3 Jul 2012 17:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BILbBNBDOj68 for ; Tue, 3 Jul 2012 17:12:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A7E2511E80A5 for ; Tue, 3 Jul 2012 17:12:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SmDCe-0000x6-G4; Wed, 04 Jul 2012 00:12:21 +0000 Date: Wed, 04 Jul 2012 09:12:04 +0900 Message-ID: From: Randy Bush To: David Farmer In-Reply-To: <4FF350D3.2030205@umn.edu> References: <20120702164834.GB13713@puck.nether.net> <20120703141629.GC22598@puck.nether.net> <4FF350D3.2030205@umn.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 00:12:17 -0000 > So Chris, why does clothing store with 1.5k endsites want those ASNs > publicly registered. I tend toward why not, but they frequently seem to > not want them publicly registered. They clam it has something to do > with security. I don't buy it, but on the other had it is their > network. it's the public's resource > A lot of enterprise networks are starting to use BGP internally, but > they seems to only want to deal with eBGP and no iBGP peerings or only > very limited iBGP. So they give every router or pair of site routers > its own Private ASN. I seen some with fairly elaborate routing policy, > that would qualify as unique routing policy. But many don't they just > used Private ASN to avoid iBGP, without any unique routing policy. i see lots of silly things. i am not inclined to change to world to accommodate them. > But using an ASN so you don't have to deal with iBGP isn't justified by > the unique routing policy criteria of RFC 1930. or by good design practice randy From christopher.morrow@gmail.com Tue Jul 3 19:18:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2672911E80AE for ; Tue, 3 Jul 2012 19:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gNh-gTVwhLu for ; Tue, 3 Jul 2012 19:18:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB6A11E8080 for ; Tue, 3 Jul 2012 19:18:21 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12297815obb.31 for ; Tue, 03 Jul 2012 19:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MDrI5f3+ewDmfTsLkeqWd/gXJzZJCSK56tW3tKMxN0E=; b=dLVMeRHXxbUbaZYMgwf5ZuHJhMNBQR5RzuMIY9OvaNaiW+3yhMNelbsYZdbzGDKS3b bRJsqnZG8UDuDs6H1GMvMNBuQ+dC4RdxLhh/LCgx5O5CHUJMU62JtfFxGgu7mh/REOJF 20U5cP/957gMuCmDMMJka3dJrIboK5ybRnXgmIiNI8x6aU1KU6qw2gJi6Rwp9+K4DFE2 OeDJbb+kUV1B49NdVgqGnXZwHuzQVoj0SIpRtZBA5WCRueSfo66qpt1Jf32C3bOTkkKM aPgojby+FOAnamTcMl/8QfaaRQ+c4m++xr2gLpSwM7XRFr+Brf2g1ud+pNkRdyKAhvZZ vBGQ== MIME-Version: 1.0 Received: by 10.182.228.6 with SMTP id se6mr15194161obc.29.1341368310804; Tue, 03 Jul 2012 19:18:30 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.191.98 with HTTP; Tue, 3 Jul 2012 19:18:30 -0700 (PDT) In-Reply-To: <4FF350D3.2030205@umn.edu> References: <20120702164834.GB13713@puck.nether.net> <20120703141629.GC22598@puck.nether.net> <4FF350D3.2030205@umn.edu> Date: Tue, 3 Jul 2012 22:18:30 -0400 X-Google-Sender-Auth: y6eS4qwrhAppUMxbP9bvhPBHu58 Message-ID: From: Christopher Morrow To: David Farmer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 02:18:22 -0000 On Tue, Jul 3, 2012 at 4:06 PM, David Farmer wrote: > So Chris, why does clothing store with 1.5k endsites want those ASNs > publicly registered. =A0I tend toward why not, but they frequently seem t= o not > want them publicly registered. I'd want them registered in case I happen to link my corp network with any partners, less pain in the rear when it comes to 'who's net is this anyway?' discussions. TODAY they choose the path of zero resistance, 'our vendor said use 65something... oh, 65535, done.' :( I'm not sure it's in our best interest to continue to let people paint themselves into a corner needlessly. (if we can fairly easily avoid it) From christopher.morrow@gmail.com Tue Jul 3 19:22:32 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5D411E80AE for ; Tue, 3 Jul 2012 19:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+i-sgAC6ZpO for ; Tue, 3 Jul 2012 19:22:32 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D791811E8080 for ; Tue, 3 Jul 2012 19:22:31 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12303319obb.31 for ; Tue, 03 Jul 2012 19:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/yiTVbmPLJ7QSFZyz4Coem/ckYCjlbQNMZJqzVqFtPk=; b=Ch6YSxE7AGSf67I5YlDrV9YTJhAh6X8c5Yb8ynjO9hiV31zp11TlE8TYoGfVhBEWI1 wqOh8hYeEbXbt5eP2jZtcGurCXxxGiv9fQ3pSgaMHZh1IAimCQwpW9HEjhiUNog/2l+A BWGaCYVQwWwer0sL3t0/dRkru4kcfInp/MOtbzOT8ab59HeSouKg7uN4EvSN9MVPj7vQ odbxP7IRlQR9deRTrpSPI4ORb5c+HLqXS+tTFwH8S01FN+59fOuXkHgZAi4Rlt3OBOtY uTKFWsTFOOdX9Fopcjs3tDYG2gnWJIE0fDEhPRMJRJ+i4+H21lfO2Slovrb4xl65QB+M 0L5w== MIME-Version: 1.0 Received: by 10.182.164.8 with SMTP id ym8mr15373649obb.51.1341368561086; Tue, 03 Jul 2012 19:22:41 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.191.98 with HTTP; Tue, 3 Jul 2012 19:22:40 -0700 (PDT) In-Reply-To: <4FF350D3.2030205@umn.edu> References: <20120702164834.GB13713@puck.nether.net> <20120703141629.GC22598@puck.nether.net> <4FF350D3.2030205@umn.edu> Date: Tue, 3 Jul 2012 22:22:40 -0400 X-Google-Sender-Auth: LGgqwUAJl_yS4WhhTidDEcpbS-k Message-ID: From: Christopher Morrow To: David Farmer Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 02:22:32 -0000 On Tue, Jul 3, 2012 at 4:06 PM, David Farmer wrote: > Realistically, even in your example of the large clothing store chain, I'll > bet you there are not multiple unique routing policies involved, its because > they want eBGP going to each of the endsites. Right or wrong, lots of people > use private ASNs so that most if not all of their peerings are eBGP and not > iBGP. Their WAN provider (of the week, it may change tomorow) has an ASN (not the clothing stores) that it uses to peer with the endsites. Each endsite uses a unique ASN so as to be easily found... tomorrow they may choose a new network provider, it'd be a bummer if they had to change lots more than 'add new peer to all endsites, depref old peer, turn down old circuits, profit!'. -chris From jrmitche@puck.nether.net Fri Jul 6 10:29:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E6021F85CD for ; Fri, 6 Jul 2012 10:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKW0KyIezLjM for ; Fri, 6 Jul 2012 10:29:10 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id A6A1421F85C7 for ; Fri, 6 Jul 2012 10:29:10 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q66HTP6d009875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2012 13:29:25 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q66HTPrv009874; Fri, 6 Jul 2012 13:29:25 -0400 Date: Fri, 6 Jul 2012 13:29:25 -0400 From: Jon Mitchell To: Christopher Morrow Message-ID: <20120706172924.GA9128@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> <20120703141629.GC22598@puck.nether.net> <4FF350D3.2030205@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Fri, 06 Jul 2012 13:29:25 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:29:11 -0000 On Tue, Jul 03, 2012 at 10:18:30PM -0400, Christopher Morrow wrote: > On Tue, Jul 3, 2012 at 4:06 PM, David Farmer wrote: > > So Chris, why does clothing store with 1.5k endsites want those ASNs > > publicly registered. ?I tend toward why not, but they frequently seem to not > > want them publicly registered. > > I'd want them registered in case I happen to link my corp network with > any partners, less pain in the rear when it comes to 'who's net is > this anyway?' discussions. [JM] Unless we assume that all Enterprise operators are unable to make wise decisions, I agree they should choose to use a Public ASN to make this connection, likely at their HQ or in a dedicated DMZ network, as they are probably not bringing in partner connections directly at their stores. Often this ASN will advertise an aggregate network or very small number of networks containing the servers that need access to the data from this extranet partner and no data from the extranet partner will go directly to the store terminals situations but I think it is hard to justify the next conclusion that they should register the other 1500 ASNs needed for this networking scenario just because they should register that one. Of course this is only one example of a single use case, and walking through every use case of private use ASNs does not seem useful. > > TODAY they choose the path of zero resistance, 'our vendor said use > 65something... oh, 65535, done.' :( > > I'm not sure it's in our best interest to continue to let people paint > themselves into a corner needlessly. (if we can fairly easily avoid > it) [JM] Many networks are succesfully using private use ASNs, I suspect we'll never know how many (although I'd guess far more individual private ASN instances are deployed thank Public) since we don't connect to them all or have to deal with them. In my mind the only thing that would have painted anyone into a corner would have been if such a private use range had never existed in the first place and they were forced to register every ASN, as likely this would have lessoned BGP adoption overall (since there are many use cases that will not meet the RIR justification requirements), when otherwise it was the right protocol for their needs. I don't see how this draft, providing a larger private use range, changes the situation given that there are no plans or even feasible way to make the existing private use ASN space to go away. Not increasing the space will only result in further hacks being used (internally) by networks that need more than 1000 ASNs, not suddenly create a desire or a realistic path to getting public ASNs. Even if we theoritically could take away away all private use space this may not get the result you want either, but may push operators who don't want to incur this burden to utilize other parts of the vast ASN space that they don't think will be allocated soon. I'm not suggesting this is wise or proper behavior, just pointing out it has been done in other resources such as IPv4 private use space when the size was not sufficient for the requirements. I welcome approaches/proposals to encourage a lower threshold for when to use a public ASN and lowering the administrative and justification burdens to obtaining them, and would be happy to work with anyone who wants to solve this problem. However as Brian pointed out, this draft's progress should not be tied to the success of that effort as they are solving different problems. From ju1738@att.com Sun Jul 8 06:36:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4B621F8663; Sun, 8 Jul 2012 06:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.729 X-Spam-Level: X-Spam-Status: No, score=-104.729 tagged_above=-999 required=5 tests=[AWL=-1.371, BAYES_40=-0.185, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfROB0bekAGd; Sun, 8 Jul 2012 06:36:20 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id B9CDF21F864A; Sun, 8 Jul 2012 06:36:19 -0700 (PDT) Received: from unknown [144.160.112.28] (EHLO tlpi048.enaf.dadc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 9ec89ff4.0.22645.00-458.57236.nbfkord-smmo03.seg.att.com (envelope-from ); Sun, 08 Jul 2012 13:36:42 +0000 (UTC) X-MXL-Hash: 4ff98cea79bd13e5-9c4588bd0fa20d634e0cd54f71bb05f6b6bb3993 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id q68DaeYf026599; Sun, 8 Jul 2012 08:36:41 -0500 Received: from dalint01.pst.cso.att.com (dalint01.pst.cso.att.com [135.31.133.159]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id q68DaaBR026564; Sun, 8 Jul 2012 08:36:37 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by dalint01.pst.cso.att.com (RSA Interceptor); Sun, 8 Jul 2012 08:36:13 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0298.004; Sun, 8 Jul 2012 09:35:51 -0400 From: "UTTARO, JAMES" To: "'Rob Shakir'" Thread-Topic: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 Thread-Index: Ac1Qh0AwzuLH5xBMSu2rz3aHemLX7wBK0QmAAAIbFGAAE+v4AABFsGbAAIK+tYAAGy5tQA== Date: Sun, 8 Jul 2012 13:35:51 +0000 Message-ID: References: <52CBEC1F-49E6-4656-A617-CAB7304479F0@rob.sh> <3FE3D8FD-7658-4A42-8D9E-2133825A4061@rob.sh> In-Reply-To: <3FE3D8FD-7658-4A42-8D9E-2133825A4061@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.57.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.112.28] X-AnalysisOut: [v=1.0 c=1 a=AwR8yoXkD5AA:10 a=81eWbNQ_HDgA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=srMsL6ituuWTYe] X-AnalysisOut: [ky9Bs9mA==:17 a=48vgC7mUAAAA:8 a=8ZcXN_yANpVvQNl1C-EA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=nY9Zm9b37MAMMyBa:21 a=] X-AnalysisOut: [9Dej72qHM68fRHrk:21] Cc: 'idr wg' , "'grow@ietf.org'" Subject: Re: [Idr] draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 13:36:21 -0000 Rob, Sorry, I meant to respond to you sooner.. In re good/bad paths... Thanks, Jim Uttaro ">>> [Jim U>] I guess what I meant was the other paths that are considered = good would be treated differently.. So in an environment where only paths w= ith the mal-formed attr are affected by this error condition as opposed to = an environment where all paths are affected ( withdrawn ) would create a in= consistent view of the "good" paths across AS domains.. So not so much the = "bad" paths but the "good" paths and how they may be treated differently.. [rjs]: I'm not sure I fully understand here: - Today: UPDATE is received from element A and found to be erroneous - ses= sion is reset, downstream do not see any paths where A was the best-path in= the RIB.=20 - With this draft: UPDATE is received from element A, found to be erroneou= s, downstream still see all other paths where A is the best-path in the RIB= . [rjs]: I'm not sure that this is so much inconsistency of what the "good" p= aths look like - both the receiving and downstream elements still consider = A's paths as valid, other than the ones that were included in the erroneous= UPDATE. In both cases, the NLRI contained in the erroneous UPDATE is also = not propagated downstream (session reset, or treat-as-withdraw stops the fu= rther propagation). " I do not know if my concern actually matters.. My thought was that if AS1 a= dvertises P(1)...P(n) to AS2 and AS3 and AS2 has deployed error handling an= d AS3 has not, then in a mal-formed scenario AS3 would withdraw all paths a= nd AS2 would only send a withdrawal for the bad paths.. There is no way of = AS4 knowing that the "good" paths from AS2 are actually suspect..Not sure i= f it matters and if AS4 could ever actually know without AS2 sending the "g= ood" paths and informing downstream peers.. -----Original Message----- From: Rob Shakir [mailto:rjs@rob.sh]=20 Sent: Thursday, June 28, 2012 4:49 AM To: UTTARO, JAMES Cc: 'grow@ietf.org'; 'idr wg' Subject: Re: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 Hi Jim, Apologies for the delay in replying to this message. Further discussion in-= line marked [rjs]. On 25 Jun 2012, at 23:47, UTTARO, JAMES wrote: > [rjs]: Absolutely, this is the current behaviour. The problem with taking= a whole session down in this case is that you now take a risk of inconsist= ency for all NLRI across that session for the duration that you hold onto t= he learned NLRI. If one avoids being in the situation where the session is = down (e.g., by applying treat-as-withdraw behaviour in cases where one can = determine the NLRI) then all other NLRI on the session continue to be updat= ed as they need to be. It is only the NLRI that were included in the errone= ous UPDATE that may be affected for looping/black-holing. >=20 >=20 >>> [Jim U>] The assumption being that the error was caused by an upstream = speaker and is therefore not truly indicative of an issue over the session = where the error manifests itself. This seems to make sense in the IPV4 case= . I am still a bit concerned as I do not understand how the following is ad= dressed. >=20 [rjs]: Actually, I think treat-as-withdraw applied more generally than opti= onal-transitive only does not necessarily imply that the error was not the = direct fault of the upstream speaker. However: > - There is no way of knowing if the adjacent peer is the speaker that is = actually responsible for the malformed attr or is coming from an upstream s= peaker. I can think of no way of knowing this.. Can it be inferred from the= notion that an error is of the syntactic or semantic variety? [rjs]: This is true, only where we have a mechanism such as the partial bit= in the optional transitive attribute can we infer that the directly attach= ed neighbour did not look at the session. What the semantic and critical er= rors that are called out in the draft relate to is the impact of the error = on the resulting UPDATE message, rather than the direct neighbour being res= ponsible for it. [Jim U>] >>> Yup. I was hoping that it may be possible to infer..=20 > - There seems to be no threshold when the session is actually taking out = of service. It would seem that some number of these type of errors would in= dicate a major issue is taking place and should be addressed by severing th= e speaker that is advertising paths with the malformed attr into the topolo= gy. A large number of these error will create a large number of withdrawn m= essages being generated from many peers. What are your thoughts on how this= should be addressed? [rjs]: This was something that has been discussed on the list previously. T= here are two key questions in this space: - Do you expect errors that are indicative of a whole box failure, that are= not related to a large change on the device (e.g., code upgrade) that affe= ct all prefixes in a manner that the UPDATE message is formed well enough t= o extract the NLRI? - Is the state of reaching all prefixes withdrawn (with UPDATEs withdrawing= all NLRI being sent to all neighbours) an acceptable state? I think there = is (of course) a scaling impact of such UPDATES being transmitted and parse= d to all downstream neighbours, but the impact of such an event is really d= ependent on assuming that large proportions of the UPDATEs generated become= erroneous. I don't think that I can categorically state that the answer to the former = is no, but I am not aware of the case. In my view, larger scale issues on t= he BGP speaker (e.g., things that affect memory integrity etc.) result in f= ailures that produce output that is not well enough formed to fall within t= he "semantic" errors described in the draft. I would (of course) welcome im= plementor and tester's feed back on this point. [Jim U>] >>> Not sure either.. But that being said it would be good to seve= r a speaker if the number of errors in some time t exceed a threshold.. >> I would expect all solutions implemented in response to these requiremen= ts to be optional. If the risk of incorrectness is unacceptable to you/an o= perator, then you should absolutely not enable any of these mechanisms. In = a number of networks that I have operated, designed and architected, I am p= repared to accept the risk of incorrectness, as I consider it acceptable wh= en compared to the risk of complete service outages in terms of impact to m= y customers during such incidents. At the moment, without the work describe= d through the requirements outlined in this draft I do not have the means t= o make that call... >> [Jim U>] I do not understand how it is possible to make this configurabl= e on a per session or AS basis..I would think all speakers participating in= a routing context would have to adhere to the same rules for a consistent = view across domains.. In my reading of the IDR draft it seems that it would= be a MUST.. Maybe I should not be considering that IDR draft as the actual= realization of the reqs.. >=20 > [rjs]: The IDR draft is the solution for some of the requirements -- part= icularly those described in Section 3 of the GROW draft. >>> [Jim U>] Got it.. >=20 > [rjs]: I do not see why this behaviour needs to be consistent across doma= ins? >>> [Jim U>] Can you explain this [rjs]: See later point about "good"/"bad" paths.=20 >=20 > [rjs]: Essentially, if I receive an invalid UPDATE message, and apply tre= at-as-withdraw, if the advertising speaker did not know that this was erron= eous then I end up with a different view of what is in the RIB than the adv= ertising speaker does. If this was a prefix I had no other route to, then I= may black-hole, if it was one where it was a more-specific of some larger = prefix, then we end up with the potential for loops. >>> [Jim U>] Yes.. I am not sure I like the notion of forwarding loops espe= cially for large flows..=20 [rjs]: The potential for loops exists in some specific scenarios I think --= especially those where there is a covering aggregate advertised to a speak= er, and a more specific that advertised within that aggregate. If this is t= he case, then in some cases, rather than forwarding back to the device adve= rtising the more specific (i.e., the one that was withdrawn). I think the b= elow example shows something like this - if 10.0.0.0/24 is advertised from = C to B, then A forwards packets destined to 10.0.0.0/24, during the time th= at this prefix is withdrawn, then this will loop. Now, I think that this is= a feature of this topology anyway, since where B-C is down, then there wil= l be loops for 10/8 in B-D. <-- 10.0.0.0/8 -- [ A ] --0.0.0.0/0--> [ B ] ---0.0.0.0/0---> [ D ] | 10.0.0.0/24 | [ C ] [rjs]: There is then a discussion as to whether one would actually expect s= uch topologies to occur in practical terms. Really, I'd rather expect that = there are blackholes (e.g., I only had one path to A, and it got withdrawn,= if anyone forwards me packets destined for A, then I drop them) or (more l= ikely in an Internet DFZ perspective) I converge to an alternate path I had= to that NLRI. [rjs]: The reason that this is highlighted in the text is that introducing = behaviour into the protocol such that loops may occur is obviously a compro= mise to protocol correctness, that may be a compromise to overall network f= orwarding integrity. It's important that this risk is understood, and balan= ced against the wider impact of session tear down.=20 >=20 > [rjs]: If I am prepared to accept the black-holing or loops for the NLRI = in the erroneous UPDATE as a risk, in favour of keeping the remaining NLRI = working (and being updated/withdrawn if they change), then this is a local = decision and I do not need to imply any behaviour of the neighbouring domai= ns. >>> [Jim U>] I guess what I meant was the other paths that are considered g= ood would be treated differently.. So in an environment where only paths wi= th the mal-formed attr are affected by this error condition as opposed to a= n environment where all paths are affected ( withdrawn ) would create a inc= onsistent view of the "good" paths across AS domains.. So not so much the "= bad" paths but the "good" paths and how they may be treated differently.. [rjs]: I'm not sure I fully understand here: - Today: UPDATE is received from element A and found to be erroneous - ses= sion is reset, downstream do not see any paths where A was the best-path in= the RIB.=20 - With this draft: UPDATE is received from element A, found to be erroneou= s, downstream still see all other paths where A is the best-path in the RIB= . [rjs]: I'm not sure that this is so much inconsistency of what the "good" p= aths look like - both the receiving and downstream elements still consider = A's paths as valid, other than the ones that were included in the erroneous= UPDATE. In both cases, the NLRI contained in the erroneous UPDATE is also = not propagated downstream (session reset, or treat-as-withdraw stops the fu= rther propagation). > [rjs] I'd say that it's not just applicable to Ivy[46] in the Internet - = but to numerous AFIs (there is a definite use-case for these solutions in L= 3VPN environments for instance). I am not saying that this is applicable or= desirable to be turned on for all AFIs -- but it seems to me that this is = a per-operator, per-deployment decision, not a per-AFI one. For instance, i= f we get an RTC UPDATE that is malformed, an operator may not want to tear = down a session if it also carries other AFIs (e.g., Van[46] also) - in that= case, the operator may want to treat this UPDATE as withdrawing the {as, r= oute-target} NLRI (consider that we have no *standardized* multi-session me= chanism yet, and there are potential scaling impacts of multiple sessions). >=20 >>> [Jim U>] Quite honestly AFs such as RT-C, Flowspec, etc... where the in= fo being propagated is more akin to "configuration" not path info should pe= rsist regardless of the session.. This goes to the heart of the discussion = of BGP is used for many fields of use that require persistence. It is not o= nly paths that use BGP for dissemination.. I would prefer that this solutio= n is limited to AFs that disseminate reachability/path info not configurati= on info.. [rjs]: The persistence discussion is a further optimization over this work = I feel, it addresses (as you correctly said before) more failure cases. In = the case that one UPDATE containing modifications to this configuration inf= ormation is invalid, is it worth making the rest of it "stale" (and not abl= e to be updated)? I think that in the case, you also want to keep as much o= f the RIB/config info up-to-date as possible, therefore targeting the error= handling mechanism to the contained NLRI still seems advantageous. [rjs]: Now, the question may be whether treat-as-withdraw is suitable in th= ese cases -- is it better to remove the flow specification, or RT from thos= e installed, or keep it and know that it might be stale? I'd be interested = to hear your thoughts here. [rjs]: On the point of addressing this per-AF, perhaps the text to add to t= he draft is that behaviour such as treat-as-withdraw must (MUST?) be config= urable on a per-AFI basis? The problem with stating something like this, is= what does one do when there is no multi-session, and it is disabled for on= e AFI, yet enabled for another?=20 Thanks, r. From kotikalapudi.sriram@nist.gov Mon Jul 9 09:20:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26B711E80F8 for ; Mon, 9 Jul 2012 09:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMVRafm7jVtJ for ; Mon, 9 Jul 2012 09:20:54 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id AC91C11E80F0 for ; Mon, 9 Jul 2012 09:20:53 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Jul 2012 12:21:03 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 9 Jul 2012 12:21:17 -0400 From: "Sriram, Kotikalapudi" To: "idr@ietf.org" Date: Mon, 9 Jul 2012 12:21:14 -0400 Thread-Topic: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt Thread-Index: Ac1d7txt/HwO98mnSy6PNG4B5ok4+w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:20:54 -0000 UmVjYWxsIHRoYXQgUkZDNjQ3Mi9CQ1AxNzIgaXMgYSAqcmVjb21tZW5kYXRpb24qIGZvciBub3Qg dXNpbmcgQVNfU0VUIGFuZCBBU19DT05GRURfU0VUIGluIEJHUC4NCkl0IHdhcyBpbnRlbmRlZCB0 aGF0IGV2ZW50dWFsbHkgdGhlcmUgd291bGQgYmUgYSBkb2N1bWVudCB0byAqcHJvc2NyaWJlKg0K dGhlIHVzZSBvZiB0aGUgQVNfU0VUIGFuZCBBU19DT05GRURfU0VUIHR5cGVzIG9mIHRoZSBBU19Q QVRIIGluIEJHUC4gIA0KU28gdGhpcyBkb2N1bWVudCAoIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWt1bWFyaS1kZXByZWNhdGUtYXMtc2V0LWNvbmZlZC1zZXQtMDAgKQ0KaXMgYmVp bmcgc3VibWl0dGVkIGZvciBjb25zaWRlcmF0aW9uIGJ5IHRoZSBXRyB0byBzdGFydCB3b3JrIG9u IGEgc3RhbmRhcmRzLXRyYWNrIFJGQw0KZm9yIGRlcHJlY2F0aW9uIG9mIEFTX1NFVCBhbmQgQVNf Q09ORkVEIF9TRVQgaW4gQkdQdjQuDQpBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIHdvdWxk IGJlIHdlbGNvbWUgYW5kIG11Y2ggYXBwcmVjaWF0ZWQuDQoNClNyaXJhbSAvIFdhcnJlbiANCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIEp1bHkg MDYsIDIwMTIgNzo0MCBQTQ0KVG86IHNyaXJhbS5pZXRmQGdtYWlsLmNvbQ0KQ2M6IHdhcnJlbkBr dW1hcmkubmV0OyBTcmlyYW0sIEtvdGlrYWxhcHVkaQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1rdW1hcmktZGVwcmVjYXRlLWFzLXNldC1jb25mZWQtc2V0LTAw LnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta3VtYXJpLWRlcHJlY2F0ZS1hcy1z ZXQtY29uZmVkLXNldC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg S290aWthbGFwdWRpIFNyaXJhbSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN CkZpbGVuYW1lOgkgZHJhZnQta3VtYXJpLWRlcHJlY2F0ZS1hcy1zZXQtY29uZmVkLXNldA0KUmV2 aXNpb246CSAwMA0KVGl0bGU6CQkgRGVwcmVjYXRpb24gb2YgQVNfU0VUIGFuZCBBU19DT05GRURf U0VUIGluIEJHUA0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMDcNCldHIElEOgkJIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA2DQpVUkw6ICAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWt1bWFyaS1kZXByZWNhdGUtYXMt c2V0LWNvbmZlZC1zZXQtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQta3VtYXJpLWRlcHJlY2F0ZS1hcy1zZXQtY29uZmVkLXNldA0K SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rdW1hcmkt ZGVwcmVjYXRlLWFzLXNldC1jb25mZWQtc2V0LTAwDQoNCkFic3RyYWN0Og0KICAgUkZDIDY0NzIg KGkuZS4sIEJDUCAxNzIpIHJlY29tbWVuZHMgbm90IHVzaW5nIEFTX1NFVCBhbmQNCiAgIEFTX0NP TkZFRF9TRVQgaW4gQkdQLiAgVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyA0MjcxIGFuZCBwcm9z Y3JpYmVzDQogICB0aGUgdXNlIG9mIHRoZSBBU19TRVQgYW5kIEFTX0NPTkZFRF9TRVQgdHlwZXMg b2YgdGhlIEFTX1BBVEggaW4NCiAgIEJHUHY0LiAgVGhpcyBpcyBkb25lIHRvIHNpbXBsaWZ5IHRo ZSBkZXNpZ24gYW5kIGltcGxlbWVudGF0aW9uIG9mIEJHUA0KICAgYW5kIHRvIG1ha2UgdGhlIHNl bWFudGljcyBvZiB0aGUgb3JpZ2luYXRvciBvZiBhIHJvdXRlIG1vcmUgY2xlYXIuDQogICBUaGlz IHdpbGwgYWxzbyBzaW1wbGlmeSB0aGUgZGVzaWduLCBpbXBsZW1lbnRhdGlvbiwgYW5kIGRlcGxv eW1lbnQgb2YNCiAgIG9uZ29pbmcgd29yayBpbiB0aGUgU2VjdXJlIEludGVyLURvbWFpbiBSb3V0 aW5nIFdvcmtpbmcgR3JvdXAuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From enkechen@cisco.com Mon Jul 9 09:29:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6538E11E812E for ; Mon, 9 Jul 2012 09:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsqhw-aDMZNV for ; Mon, 9 Jul 2012 09:29:52 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EB36F11E812F for ; Mon, 9 Jul 2012 09:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=2461; q=dns/txt; s=iport; t=1341851417; x=1343061017; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=EHJ4MK5JleZKEKnUCzQyAYWxIEWIaQPuNGsvJ3mZpuw=; b=Y9K8q8M1cgSmDyLSVvRai0eFujXo9p1NoAIQnCsJgLfFXw6eeG7YAN4H eWV/Z7216ZExCnSwFQnR8LtHybDOYqat2PbgRFe/E5RwJPLbf9dUzrPM6 tzfqeI4MGUut6P7uYZVfTqkwvxNoQNGppw0FgOENUjxQ+ht/GjKR/jXju U=; X-IronPort-AV: E=Sophos;i="4.77,552,1336348800"; d="scan'208";a="48342025" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 09 Jul 2012 16:30:14 +0000 Received: from sjc-vpn5-1293.cisco.com (sjc-vpn5-1293.cisco.com [10.21.93.13]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q69GUD8J024835; Mon, 9 Jul 2012 16:30:14 GMT Message-ID: <4FFB0785.10800@cisco.com> Date: Mon, 09 Jul 2012 09:32:05 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Sriram, Kotikalapudi" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:29:53 -0000 Hi, folks: Is there really a need for another doc on deprecating AS_SET / AS_CONFED_SET? Regardless the code in the software can not be removed. -- Enke On 7/9/12 9:21 AM, Sriram, Kotikalapudi wrote: > Recall that RFC6472/BCP172 is a *recommendation* for not using AS_SET and AS_CONFED_SET in BGP. > It was intended that eventually there would be a document to *proscribe* > the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGP. > So this document ( http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00 ) > is being submitted for consideration by the WG to start work on a standards-track RFC > for deprecation of AS_SET and AS_CONFED _SET in BGPv4. > Any comments and suggestions would be welcome and much appreciated. > > Sriram / Warren > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, July 06, 2012 7:40 PM > To: sriram.ietf@gmail.com > Cc: warren@kumari.net; Sriram, Kotikalapudi > Subject: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt > > A new version of I-D, draft-kumari-deprecate-as-set-confed-set-00.txt > has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository. > > Filename: draft-kumari-deprecate-as-set-confed-set > Revision: 00 > Title: Deprecation of AS_SET and AS_CONFED_SET in BGP > Creation date: 2012-07-07 > WG ID: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-kumari-deprecate-as-set-confed-set-00.txt > Status: http://datatracker.ietf.org/doc/draft-kumari-deprecate-as-set-confed-set > Htmlized: http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00 > > Abstract: > RFC 6472 (i.e., BCP 172) recommends not using AS_SET and > AS_CONFED_SET in BGP. This document updates RFC 4271 and proscribes > the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in > BGPv4. This is done to simplify the design and implementation of BGP > and to make the semantics of the originator of a route more clear. > This will also simplify the design, implementation, and deployment of > ongoing work in the Secure Inter-Domain Routing Working Group. > > The IETF Secretariat > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jhaas@slice.pfrc.org Mon Jul 9 10:25:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462A111E8174 for ; Mon, 9 Jul 2012 10:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.41 X-Spam-Level: X-Spam-Status: No, score=-101.41 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdrOMY64nQ88 for ; Mon, 9 Jul 2012 10:25:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CFC7D11E8117 for ; Mon, 9 Jul 2012 10:25:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 229D6C6A9; Mon, 9 Jul 2012 13:25:45 -0400 (EDT) Date: Mon, 9 Jul 2012 13:25:45 -0400 From: Jeffrey Haas To: Jon Mitchell Message-ID: <20120709172545.GF22984@pfrc> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703021238.GM18361@pfrc> <20120703133948.GB22598@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120703133948.GB22598@puck.nether.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:25:20 -0000 On Tue, Jul 03, 2012 at 09:39:48AM -0400, Jon Mitchell wrote: > [JM] This is interesting, however given these ASNs are in use today and > there is widespread mis-understanding that the 65535 ASN is a private > use ASN already based on widespread vendor and other networking > documentation, I think publishing this informational draft to > officially allocate it as such is not going to cause a rush of changes > to use it on devices this old. However new implementors would have > clear guidance on what a private ASN if they are trying to comply with > this draft/RFC if/when it's published and therefore could avoid this > leaving this open to error in new implementations. There is another very strong argument to leave AS 65535 alone as a reserved AS rather than noting it can be used as "just another private AS": Communities. While users of that AS would likely be addressing their communities to someone else's AS, why preclude them from being able to receive any addressed to their own AS? (If it's not immediately apparent, RFC 1997 well known communities are effectively addressed to AS 65535.) -- Jeff From brian.peter.dickson@gmail.com Mon Jul 9 10:35:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2146421F87E7 for ; Mon, 9 Jul 2012 10:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZQu3IfFVtrc for ; Mon, 9 Jul 2012 10:35:00 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 674D021F87F4 for ; Mon, 9 Jul 2012 10:34:59 -0700 (PDT) Received: by were53 with SMTP id e53so2341764wer.31 for ; Mon, 09 Jul 2012 10:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5rptyUHVGW7d2y5SkrI2nv7tC+AMhz/YywQhY9haO1o=; b=cemaYPYndbQijqyk1JZYafgcV/0wtAnrakUN6t6hwpo6XVdVPchysi1Mcb717t0JOG D3Jawa+f16bwCm5FTa5u8wQ9GIB5vBeese0n6aQ0Ula/3q5qjALRUQ1vTjF9IqqWE2Az 7uolUigLI3ZqA+XYJ19vuj64c4cgdtPj1OOhy4t6w+8zxdUZ366EuwhdqZL6Lp9uQmSl asnh9/XqO8DkfzYwABOlF7UrFL5xTBPQFQ9XoFQQz3X3XJUrF+EAZJkoxBaRHmKAx6pl ze7UZx5dotSSYgdJNsHrCWGbz0JKcpwxUmFuNrsPK2+Mmkpnay2+n1E1YS9zYU6PWNR3 Bipg== MIME-Version: 1.0 Received: by 10.180.86.133 with SMTP id p5mr31181938wiz.17.1341855323901; Mon, 09 Jul 2012 10:35:23 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Mon, 9 Jul 2012 10:35:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jul 2012 13:35:23 -0400 Message-ID: From: Brian Dickson To: "Sriram, Kotikalapudi" Content-Type: multipart/alternative; boundary=f46d0442820eebcf0b04c4690937 Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:35:01 -0000 --f46d0442820eebcf0b04c4690937 Content-Type: text/plain; charset=ISO-8859-1 The "analysis" (slide deck) does not itself detail the few cases where AS_SET is not used incorrectly. Since one of the authors was involved in that analysis, for sake of discussing this proposal, could you please provide the following? - route-views data on AS_SET announcements that are properly formed (per your analysis) - route-views data on related announcements (e.g. exact-match or longer-prefix that form the basis for the AS_SET aggregates) This would be the actual data, not just "counts" of the number of prefixes. Knowing who is doing this, which prefixes are affected, and such, will help inform us on the usage of AS_SET "in the wild". Also, along with those prefixes, could you search the route-views data to find out when the first announcement for each (even roughly, YYYY-MM is good enough) occurred, with the current values? If something has been announced in exactly the same form, for a very long time, perhaps the configuration is just being "left alone" because none of the techies at the organization understand what it is, what it does, or why it is there? And maybe someone could do out-reach to those entities to show them why & how what they are doing is not necessary, and how to achieve whatever the original goals were, without using AS_SET? (If we can reduce the well-formed instances "in the wild" to as close to zero as possible, I think it would be safe to then treat the malformed AS_SET instances as outliers, regardless of quantity.) It is a lot easier to deprecate something that isn't being used correctly at all, than something that is *almost* not being used correctly at all. And even if the latter, I am in favor of adoption of this as a WG item. I'm just suggesting the above to move away from the "angels dancing on the head of a pin" kind of discussion. Brian On Mon, Jul 9, 2012 at 12:21 PM, Sriram, Kotikalapudi < kotikalapudi.sriram@nist.gov> wrote: > Recall that RFC6472/BCP172 is a *recommendation* for not using AS_SET and > AS_CONFED_SET in BGP. > It was intended that eventually there would be a document to *proscribe* > the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGP. > So this document ( > http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00 ) > is being submitted for consideration by the WG to start work on a > standards-track RFC > for deprecation of AS_SET and AS_CONFED _SET in BGPv4. > Any comments and suggestions would be welcome and much appreciated. > > Sriram / Warren > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, July 06, 2012 7:40 PM > To: sriram.ietf@gmail.com > Cc: warren@kumari.net; Sriram, Kotikalapudi > Subject: New Version Notification for > draft-kumari-deprecate-as-set-confed-set-00.txt > > A new version of I-D, draft-kumari-deprecate-as-set-confed-set-00.txt > has been successfully submitted by Kotikalapudi Sriram and posted to the > IETF repository. > > Filename: draft-kumari-deprecate-as-set-confed-set > Revision: 00 > Title: Deprecation of AS_SET and AS_CONFED_SET in BGP > Creation date: 2012-07-07 > WG ID: Individual Submission > Number of pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-kumari-deprecate-as-set-confed-set-00.txt > Status: > http://datatracker.ietf.org/doc/draft-kumari-deprecate-as-set-confed-set > Htmlized: > http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00 > > Abstract: > RFC 6472 (i.e., BCP 172) recommends not using AS_SET and > AS_CONFED_SET in BGP. This document updates RFC 4271 and proscribes > the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in > BGPv4. This is done to simplify the design and implementation of BGP > and to make the semantics of the originator of a route more clear. > This will also simplify the design, implementation, and deployment of > ongoing work in the Secure Inter-Domain Routing Working Group. > > The IETF Secretariat > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --f46d0442820eebcf0b04c4690937 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The "analysis" (slide deck) does not itself detail the few cases = where AS_SET is not used incorrectly.

Since one of the authors was = involved in that analysis, for sake of discussing this proposal, could you = please provide the following?

- route-views data on AS_SET announcements that are pro= perly formed (per your analysis)
- route-views data on related an= nouncements (e.g. exact-match or longer-prefix that form the basis for the = AS_SET aggregates)

This would be the actual data, not just "counts&qu= ot; of the number of prefixes.
Knowing who is doing this, which p= refixes are affected, and such, will help inform us on the usage of AS_SET = "in the wild".

Also, along with those prefixes, could you search the r= oute-views data to find out when the first announcement for each (even roug= hly, YYYY-MM is good enough) occurred, with the current values?

If something has been announced in exactly the same form, fo= r a very long time, perhaps the configuration is just being "left alon= e" because none of the techies at the organization understand what it = is, what it does, or why it is there?

And maybe someone could do out-reach to those entities = to show them why & how what they are doing is not necessary, and how to= achieve whatever the original goals were, without using AS_SET?

(If we can reduce the well-formed instances "in the wil= d" to as close to zero as possible, I think it would be safe to then t= reat the malformed AS_SET instances as outliers, regardless of quantity.)

It is a lot easier to deprecate something that isn'= t being used correctly at all, than something that is *almost* not being us= ed correctly at all.

And even if the latter, I am = in favor of adoption of this as a WG item.

I'm just suggesting the above to move away from the= "angels dancing on the head of a pin" kind of discussion.
<= div>
Brian

On Mon, J= ul 9, 2012 at 12:21 PM, Sriram, Kotikalapudi <kotikalapudi.sri= ram@nist.gov> wrote:
Recall that RFC6472/BCP172 is a *recommendat= ion* for not using AS_SET and AS_CONFED_SET in BGP.
It was intended that eventually there would be a document to *proscribe* the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGP.
So this document ( http://tools.ietf.org/html/dra= ft-kumari-deprecate-as-set-confed-set-00 )
is being submitted for consideration by the WG to start work on a standards= -track RFC
for deprecation of AS_SET and AS_CONFED _SET in BGPv4.
Any comments and suggestions would be welcome and much appreciated.

Sriram / Warren

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Friday, July 06, 2012 7:40 PM
To: sriram.ietf@gmail.com
Cc: warren@kumari.net; Sriram, Kot= ikalapudi
Subject: New Version Notification for draft-kumari-deprecate-as-set-confed-= set-00.txt

A new version of I-D, draft-kumari-deprecate-as-set-confed-set-00.txt
has been successfully submitted by Kotikalapudi Sriram and posted to the IE= TF repository.

Filename: =A0 =A0 =A0 =A0draft-kumari-deprecate-as-set-confed-set
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Deprecation of AS_SET and AS_CONFED_SET in BGP Creation date: =A0 2012-07-07
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 6
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://= www.ietf.org/internet-drafts/draft-kumari-deprecate-as-set-confed-set-00.tx= t
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.i= etf.org/doc/draft-kumari-deprecate-as-set-confed-set
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/ht= ml/draft-kumari-deprecate-as-set-confed-set-00

Abstract:
=A0 =A0RFC 6472 (i.e., BCP 172) recommends not using AS_SET and
=A0 =A0AS_CONFED_SET in BGP. =A0This document updates RFC 4271 and proscrib= es
=A0 =A0the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in
=A0 =A0BGPv4. =A0This is done to simplify the design and implementation of = BGP
=A0 =A0and to make the semantics of the originator of a route more clear. =A0 =A0This will also simplify the design, implementation, and deployment o= f
=A0 =A0ongoing work in the Secure Inter-Domain Routing Working Group.

The IETF Secretariat
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--f46d0442820eebcf0b04c4690937-- From robert@raszuk.net Mon Jul 9 11:16:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8AE11E80D9 for ; Mon, 9 Jul 2012 11:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IpA4JAJBSnI for ; Mon, 9 Jul 2012 11:16:42 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB0911E80D5 for ; Mon, 9 Jul 2012 11:16:42 -0700 (PDT) Received: (qmail 17158 invoked by uid 399); 9 Jul 2012 18:17:07 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.9.209.219) by mail1310.opentransfer.com with ESMTPM; 9 Jul 2012 18:17:07 -0000 X-Originating-IP: 83.9.209.219 Message-ID: <4FFB2020.7080003@raszuk.net> Date: Mon, 09 Jul 2012 20:17:04 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Brian Dickson , "Sriram, Kotikalapudi" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 18:16:43 -0000 Hi Brian and Sriram, Simple question ... Some BGP implementations use AS_SET when IBGP multipath is enabled to correctly advertise what is being used in data plane to a peer. What authors of the document in question recommend to do in this case ? And also as Enke said no matter what draft or rfc says deployed code will remain. In those cases AS_SET will continue to be advertised injected by those BGP implementations as there is no even CLI control to stop it. The multipath code simply calls the aspath_aggregate (latest quagga code http://goo.gl/ISBWj line 669) which in turn IMHO correctly inserts the AS_SET (http://goo.gl/oSsxE line 996). Thx, R. > The "analysis" (slide deck) does not itself detail the few cases where > AS_SET is not used incorrectly. > > Since one of the authors was involved in that analysis, for sake of > discussing this proposal, could you please provide the following? > > - route-views data on AS_SET announcements that are properly formed (per > your analysis) > - route-views data on related announcements (e.g. exact-match or > longer-prefix that form the basis for the AS_SET aggregates) > > This would be the actual data, not just "counts" of the number of prefixes. > Knowing who is doing this, which prefixes are affected, and such, will > help inform us on the usage of AS_SET "in the wild". > > Also, along with those prefixes, could you search the route-views data > to find out when the first announcement for each (even roughly, YYYY-MM > is good enough) occurred, with the current values? > > If something has been announced in exactly the same form, for a very > long time, perhaps the configuration is just being "left alone" because > none of the techies at the organization understand what it is, what it > does, or why it is there? > > And maybe someone could do out-reach to those entities to show them why > & how what they are doing is not necessary, and how to achieve whatever > the original goals were, without using AS_SET? > > (If we can reduce the well-formed instances "in the wild" to as close to > zero as possible, I think it would be safe to then treat the malformed > AS_SET instances as outliers, regardless of quantity.) > > It is a lot easier to deprecate something that isn't being used > correctly at all, than something that is *almost* not being used > correctly at all. > > And even if the latter, I am in favor of adoption of this as a WG item. > > I'm just suggesting the above to move away from the "angels dancing on > the head of a pin" kind of discussion. > > Brian > > On Mon, Jul 9, 2012 at 12:21 PM, Sriram, Kotikalapudi > > wrote: > > Recall that RFC6472/BCP172 is a *recommendation* for not using > AS_SET and AS_CONFED_SET in BGP. > It was intended that eventually there would be a document to *proscribe* > the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGP. > So this document ( > http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00 ) > is being submitted for consideration by the WG to start work on a > standards-track RFC > for deprecation of AS_SET and AS_CONFED _SET in BGPv4. > Any comments and suggestions would be welcome and much appreciated. > > Sriram / Warren > > -----Original Message----- > From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org ] > Sent: Friday, July 06, 2012 7:40 PM > To: sriram.ietf@gmail.com > Cc: warren@kumari.net ; Sriram, Kotikalapudi > Subject: New Version Notification for > draft-kumari-deprecate-as-set-confed-set-00.txt > > A new version of I-D, draft-kumari-deprecate-as-set-confed-set-00.txt > has been successfully submitted by Kotikalapudi Sriram and posted to > the IETF repository. > > Filename: draft-kumari-deprecate-as-set-confed-set > Revision: 00 > Title: Deprecation of AS_SET and AS_CONFED_SET in BGP > Creation date: 2012-07-07 > WG ID: Individual Submission > Number of pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-kumari-deprecate-as-set-confed-set-00.txt > Status: > http://datatracker.ietf.org/doc/draft-kumari-deprecate-as-set-confed-set > Htmlized: > http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00 > > Abstract: > RFC 6472 (i.e., BCP 172) recommends not using AS_SET and > AS_CONFED_SET in BGP. This document updates RFC 4271 and proscribes > the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in > BGPv4. This is done to simplify the design and implementation > of BGP > and to make the semantics of the originator of a route more clear. > This will also simplify the design, implementation, and > deployment of > ongoing work in the Secure Inter-Domain Routing Working Group. > > The IETF Secretariat > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From jakob.heitz@ericsson.com Mon Jul 9 11:26:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EC321F87E7; Mon, 9 Jul 2012 11:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvmN8SSJkRfO; Mon, 9 Jul 2012 11:26:22 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A7CBC21F87BE; Mon, 9 Jul 2012 11:26:22 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q69IQiRY015374; Mon, 9 Jul 2012 13:26:46 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 9 Jul 2012 14:26:41 -0400 From: Jakob Heitz To: "robert@raszuk.net" , Brian Dickson , "Sriram, Kotikalapudi" Date: Mon, 9 Jul 2012 14:26:40 -0400 Thread-Topic: [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt Thread-Index: Ac1d/xUDfih/roMjSr6I4xQbzhoblAAANxqA Message-ID: <7309FCBCAE981B43ABBE69B31C8D213924985C89DB@EUSAACMS0701.eamcs.ericsson.se> References: <4FFB2020.7080003@raszuk.net> In-Reply-To: <4FFB2020.7080003@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "sidr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 18:26:23 -0000 Better to figure out how to aggregate with sidr. A few months ago, I wrote an email suggesting how to build a tree of aggregated signatures. Shall I submit it as a draft, or is there already another way? On Monday, July 09, 2012 11:17 AM, Robert Raszuk <> wrote: > Hi Brian and Sriram, >=20 > Simple question ... >=20 > Some BGP implementations use AS_SET when IBGP multipath is enabled to > correctly advertise what is being used in data plane to a peer. >=20 > What authors of the document in question recommend to do in this case > ?=20 >=20 > And also as Enke said no matter what draft or rfc says deployed code > will remain. >=20 > In those cases AS_SET will continue to be advertised injected by those > BGP implementations as there is no even CLI control to stop it. >=20 > The multipath code simply calls the aspath_aggregate (latest quagga > code http://goo.gl/ISBWj line 669) which in turn IMHO correctly > inserts the AS_SET (http://goo.gl/oSsxE line 996). >=20 > Thx, > R. >=20 >=20 >> The "analysis" (slide deck) does not itself detail the few cases >> where=20 >> AS_SET is not used incorrectly. >>=20 >> Since one of the authors was involved in that analysis, for sake of >> discussing this proposal, could you please provide the following? >>=20 >> - route-views data on AS_SET announcements that are properly formed >> (per=20 >> your analysis) >> - route-views data on related announcements (e.g. exact-match or >> longer-prefix that form the basis for the AS_SET aggregates) >>=20 >> This would be the actual data, not just "counts" of the number of >> prefixes.=20 >> Knowing who is doing this, which prefixes are affected, and such, >> will=20 >> help inform us on the usage of AS_SET "in the wild". >>=20 >> Also, along with those prefixes, could you search the route-views >> data=20 >> to find out when the first announcement for each (even roughly, >> YYYY-MM=20 >> is good enough) occurred, with the current values? >>=20 >> If something has been announced in exactly the same form, for a very >> long time, perhaps the configuration is just being "left alone" >> because=20 >> none of the techies at the organization understand what it is, what >> it=20 >> does, or why it is there? >>=20 >> And maybe someone could do out-reach to those entities to show them >> why & how what they are doing is not necessary, and how to achieve >> whatever=20 >> the original goals were, without using AS_SET? >>=20 >> (If we can reduce the well-formed instances "in the wild" to as >> close to=20 >> zero as possible, I think it would be safe to then treat the >> malformed=20 >> AS_SET instances as outliers, regardless of quantity.) >>=20 >> It is a lot easier to deprecate something that isn't being used >> correctly at all, than something that is *almost* not being used >> correctly at all. >>=20 >> And even if the latter, I am in favor of adoption of this as a WG >> item.=20 >>=20 >> I'm just suggesting the above to move away from the "angels dancing >> on=20 >> the head of a pin" kind of discussion. >>=20 >> Brian >>=20 >> On Mon, Jul 9, 2012 at 12:21 PM, Sriram, Kotikalapudi >> > >> wrote:=20 >>=20 >> Recall that RFC6472/BCP172 is a *recommendation* for not using >> AS_SET and AS_CONFED_SET in BGP. >> It was intended that eventually there would be a document to >> *proscribe* the use of the AS_SET and AS_CONFED_SET types of the >> AS_PATH in BGP. So this document ( >> =20 >> =20 >> =20 >> http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00 >> ) is being submitted for consideration by the WG to start work on a=20 >> standards-track RFC for deprecation of AS_SET and AS_CONFED _SET in >> BGPv4. Any comments and suggestions would be welcome and much >> appreciated. =20 >>=20 >> Sriram / Warren >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org >> [mailto:internet-drafts@ietf.org >> ] Sent: Friday, July 06, 2012 >> 7:40 PM To: sriram.ietf@gmail.com >> Cc: warren@kumari.net ; Sriram, >> Kotikalapudi Subject: New Version Notification for >> draft-kumari-deprecate-as-set-confed-set-00.txt >>=20 >> A new version of I-D, >> draft-kumari-deprecate-as-set-confed-set-00.txt has been >> successfully submitted by Kotikalapudi Sriram and posted to the >> IETF repository. =20 >>=20 >> Filename: draft-kumari-deprecate-as-set-confed-set =20 >> Revision: 00 Title: Deprecation of AS_SET and >> AS_CONFED_SET in BGP Creation date: 2012-07-07 >> WG ID: Individual Submission >> Number of pages: 6 >> URL: >> =20 >> =20 >> =20 >> http://www.ietf.org/internet-drafts/draft-kumari-deprecate-as-set-confed= -set-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-kumari-deprecate-as-set-confed-set >> Htmlized: >> http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00 >>=20 >> Abstract: >> RFC 6472 (i.e., BCP 172) recommends not using AS_SET and >> AS_CONFED_SET in BGP. This document updates RFC 4271 and >> proscribes the use of the AS_SET and AS_CONFED_SET types of >> the AS_PATH in BGPv4. This is done to simplify the design >> and implementation of BGP and to make the semantics of >> the originator of a route more clear. This will also >> simplify the design, implementation, and deployment of >> ongoing work in the Secure Inter-Domain Routing Working Group.=20 >>=20 --=20 Jakob Heitz.= From bashandy@cisco.com Mon Jul 9 11:29:49 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220C711E8102; Mon, 9 Jul 2012 11:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfvmittRKzX5; Mon, 9 Jul 2012 11:29:48 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0A36E11E80D0; Mon, 9 Jul 2012 11:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=8966; q=dns/txt; s=iport; t=1341858613; x=1343068213; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=MKDnFXkbmi02ByGRf9igwLo1MRPv75pc4aU3FSSdQ00=; b=fIAeuVwl2JhJ7/uU59VLHkI9vVXfSPuaDBUvaGwzXI9dVXHxFke1fVLY hlcv+8wehnXvac/E58VhoBRQFC/f1ZuU/EjxTC0nUCq3RZp64xwlwk1WK Qh8RaDrFoKynrksjWm1kEbf/oFT97i3GxOu5LHJiujVsy4bmG8OYcQQtJ s=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,553,1336348800"; d="asc'?scan'208,217";a="51465529" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 09 Jul 2012 18:30:13 +0000 Received: from [171.71.139.5] (dhcp-171-71-139-5.cisco.com [171.71.139.5]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q69IUD3g028887; Mon, 9 Jul 2012 18:30:13 GMT Message-ID: <4FFB2330.4020809@cisco.com> Date: Mon, 09 Jul 2012 11:30:08 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "idr@ietf.org List" , rtgwg@ietf.org References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> In-Reply-To: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD26DE787B37BEC29F385B464" Cc: "Maciek Konstantynowicz \(mkonstan\)" Subject: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 18:29:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD26DE787B37BEC29F385B464 Content-Type: multipart/alternative; boundary="------------060306050304010908050809" This is a multi-part message in MIME format. --------------060306050304010908050809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The draft proposes a new method for BGP FRR. The approach is very scalable as it does not require injecting any prefixes into the core, no re-advertisement of BGP prefixes, and no state replication. At the same time, it is transparent to the operator in the sense that if it is enabled by default, there is no need for human intervention due to any reason including internal and external topology changes or even when switching from MPLS to IP core and back All comments are most welcomed Thanks Ahmed -------- Original Message -------- Subject: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt Date: Sun, 8 Jul 2012 07:05:43 -0700 From: To: CC: , A new version of I-D, draft-bashandy-bgp-frr-vector-label-00.txt has been successfully submitted by Ahmed Bashandy and posted to the IETF repository. Filename: draft-bashandy-bgp-frr-vector-label Revision: 00 Title: BGP FRR Protection against Edge Node Failure Using Vector Labels= Creation date: 2012-07-07 WG ID: Individual Submission Number of pages: 32 URL: http://www.ietf.org/internet-drafts/draft-bashandy-bgp-f= rr-vector-label-00.txt Status: http://datatracker.ietf.org/doc/draft-bashandy-bgp-frr-v= ector-label Htmlized: http://tools.ietf.org/html/draft-bashandy-bgp-frr-vector= -label-00 Abstract: Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/m via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it is desirable for a core router "P" carrying traffic to the failed edge router PEi to immediately restore traffic by re-tunneling packets originally tunneled to PEi and destined to the prefix P/m to one of the other edge routers that advertised P/m, say PEj, until BGP re-converges. In doing so, it is highly desirable to keep the core BGP-free while not imposing restrictions on external connectivity or complicating provisioning effort. Thus (1) a core router should not be required to learn any BGP prefix, (2) the size of the forwarding and routing tables in the core routers should be independent of the number of BGP prefixes, (3) re-routing traffic without waiting for re-convergence must not cause loops, (4) provisioning effort should be kept at minimum, and (5) there should be no restrictions on what edge routers advertise what prefixes. For labeled prefixes, (6) the label stack on the packet must allow the repair PEj to correctly forward the packet and (7) there must not be any need to perform more than one label lookup on any edge or core router during steady state = =20 The IETF Secretariat --------------060306050304010908050809 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The draft proposes a new method for BGP FRR.

The approach is very scalable as it does not require injecting any prefixes into the core, no re-advertisement of BGP prefixes, and no state replication. At the same time, it is transparent to the operator in the sense that if it is enabled by default, there is no need for human intervention due to any reason including internal and external topology changes or even when switching from MPLS to IP core and back

All comments are most welcomed

Thanks

Ahmed

-------- Original Message --------
Sub= ject: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt
Dat= e: Sun, 8 Jul 2012 07:05:43 -0700
Fro= m: <internet-drafts@ietf.org>
To:= <bashandy@cisco.com>
CC:= <naikumar@cisco.com>, <mkonstan@cisco.com><= /td> 


A new version of I-D, draft-bashandy-bgp-frr-vector-label-00.t=
xt
has been successfully submitted by Ahmed Bashandy and posted to the
IETF repository.

Filename:	 draft-bashandy-bgp-frr-vector-label
Revision:	 00
Title:		 BGP FRR Protection against Edge Node Failure Using Vector Labels=

Creation date:	 2012-07-07
WG ID:		 Individual Submission
Number of pages: 32
URL:             http:/=
/www.ietf.org/internet-drafts/draft-bashandy-bgp-frr-vector-label-00.txt<=
/a>
Status:          http://datatracke=
r.ietf.org/doc/draft-bashandy-bgp-frr-vector-label
Htmlized:        http://tools.ietf.o=
rg/html/draft-bashandy-bgp-frr-vector-label-00


Abstract:
Consider a BGP free core scenario. Suppose the edge BGP speakers PE1,
PE2,..., PEn know about a prefix P/m via the external routers CE1,
CE2,..., CEm.  If the edge router PEi crashes or becomes totally
disconnected from the core, it is desirable for a core router "P"
carrying traffic to the failed edge router PEi to immediately restore
traffic by re-tunneling packets originally tunneled to PEi and
destined to the prefix P/m to one of the other edge routers that
advertised P/m, say PEj, until BGP re-converges. In doing so, it is
highly desirable to keep the core BGP-free while not imposing
restrictions on external connectivity or complicating provisioning
effort. Thus (1) a core router should not be required to learn any
BGP prefix, (2) the size of the forwarding and routing tables in the
core routers should be independent of the number of BGP prefixes, (3)
re-routing traffic without waiting for re-convergence must not cause
loops, (4) provisioning effort should be kept at minimum, and (5)
there should be no restrictions on what edge routers advertise what
prefixes. For labeled prefixes, (6) the label stack on the packet
must allow the repair PEj to correctly forward the packet and (7)
there must not be any need to perform more than one label lookup on
any edge or core router during steady state

                                                                         =
        =20


The IETF Secretariat



--------------060306050304010908050809-- --------------enigD26DE787B37BEC29F385B464 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFP+yM0+G19kFA5zIYRAhPdAJ4tf3wMVCY92lLCJGgEyEIkEISUPwCfWpFY 7OLjd9yiNrGatlan+uWWtU8= =WHrf -----END PGP SIGNATURE----- --------------enigD26DE787B37BEC29F385B464-- From brian.peter.dickson@gmail.com Mon Jul 9 12:21:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAF511E814B for ; Mon, 9 Jul 2012 12:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3bI6BITHaO3 for ; Mon, 9 Jul 2012 12:21:12 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0652711E80F3 for ; Mon, 9 Jul 2012 12:21:11 -0700 (PDT) Received: by were53 with SMTP id e53so2408604wer.31 for ; Mon, 09 Jul 2012 12:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Imph8OR1p+T/zHRp89dDLDtyHKXzYAEBuvQkPBBgq1E=; b=rjy58PT0PidxvuEJp8mtXkm8PSBoad6zLwyt6tLfS6CqOoOVBy6AxnfLc18ISn7MN8 vRdyk/qVOjf1Cg8GV/AbomHzPWyJOZmZ8PIOaTehfFhK0nSU41JrESiVVb4zh+lAbc7F RVej6CbgDB08LPfwToaAFcBvBip6Q9hIxmytPEj/ABSYR9R9nXV31iCE146mr+cZcw9p IRm9kxkDkVORV24RHyKDgvTBYHpzDHDTtDFJ8cwa8gVregMB2uhwJciNeJ4M5rExh3sm JssxJ3iAZwPmGZnzouCcKP1T0dhj7yZLWDyu/7bf61F5qCTa7b7sv1zR78RoJ1uCvc56 VSfQ== MIME-Version: 1.0 Received: by 10.180.78.99 with SMTP id a3mr31807759wix.15.1341861696483; Mon, 09 Jul 2012 12:21:36 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Mon, 9 Jul 2012 12:21:36 -0700 (PDT) In-Reply-To: <4FFB2020.7080003@raszuk.net> References: <4FFB2020.7080003@raszuk.net> Date: Mon, 9 Jul 2012 15:21:36 -0400 Message-ID: From: Brian Dickson To: robert@raszuk.net Content-Type: multipart/alternative; boundary=f46d04389041c1b2cd04c46a851e Cc: "idr@ietf.org" , "Sriram, Kotikalapudi" Subject: Re: [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:21:14 -0000 --f46d04389041c1b2cd04c46a851e Content-Type: text/plain; charset=ISO-8859-1 I think the original intent of AS_SET, as being used when aggregating, should be kept separate from instances of "overloading" the attribute for new functionality (e.g. multipath). So, let's consider the "classic" AS_SET instances, which are quite possibly the reason we see AS_SET in the wild. (BTW - I took a quick look at a very recent snapshot from routeviews, and see a grand total of 14 prefixes with non-singular, non-private AS_SET values, i.e. only 14 instance where the AS_SET contains more than one ASN, and the ASN set does not contain any private ASNs. So the deployed use cases in the DFZ, "in the wild", looks like only 14 total. Regardless of deployed code, if we get those 14 instances to fix their configs to not do AS_SET, we should be able to move on to depracating AS_SET, and at least, moving forward, can get rid of it from new code, and avoid having to include support for it in updates to the protocol.) Can anyone explain why it is necessary to have an AS_SET at all, i.e. can anyone give an example where bad things happen without AS_SET, and those bad things don't happen when AS_SET is used? The text of 4271 seems to indicate that ATOMIC_AGGREGATE was needed for signaling that what would have required an AS_SET has had the AS_SET remove, but that in a CIDR-only world, that ATOMIC_AGGREGATE is basically informational-only. And this, in turn suggests that there are actually no instances where removing an AS_SET would break things. Which leads to not only depracating the use of AS_SETs (by operators), but hopefully to the current I-D under discussion - making AS_SET code (and CONFED_AS_SET code) go away. Anyone? Brian P.S. For the multipath case, what about just appending the two paths? That was Tony Li's suggestion in SIDR, and it avoids the routing and routing-information loops. P.P.S. That multipath didn't properly address its "multi-pathness" in the withdrawal side of UPDATE messages, is not necessarily a suitable reason to keep AS_SETs around. P.P.P.S. In an ideal world, it *should* be enough to just have multipath send the best of the multiples to its peers. The fact that it also uses stuff other than its best, is just additional non-control-plane stuff, and shouldn't really impact peers' networks as such. If a peer's peer needs the second-best path to avoid either loops, or instability, there are bigger problems afoot. P.P.P.P.S. The correct solution would have been to create a new PATH element, which consists of fully-formed AS_PATHs themselves, which would have allowed loop prevention while keeping the ordering of AS_PATH attributes, and would allow multi-path-aware speakers to share the extra path info. Negotiated, of course. On Mon, Jul 9, 2012 at 2:17 PM, Robert Raszuk wrote: > Hi Brian and Sriram, > > Simple question ... > > Some BGP implementations use AS_SET when IBGP multipath is enabled to > correctly advertise what is being used in data plane to a peer. > > What authors of the document in question recommend to do in this case ? > > And also as Enke said no matter what draft or rfc says deployed code will > remain. > > In those cases AS_SET will continue to be advertised injected by those BGP > implementations as there is no even CLI control to stop it. > > The multipath code simply calls the aspath_aggregate (latest quagga code > http://goo.gl/ISBWj line 669) which in turn IMHO correctly inserts the > AS_SET (http://goo.gl/oSsxE line 996). > > Thx, > R. > > > The "analysis" (slide deck) does not itself detail the few cases where >> AS_SET is not used incorrectly. >> >> Since one of the authors was involved in that analysis, for sake of >> discussing this proposal, could you please provide the following? >> >> - route-views data on AS_SET announcements that are properly formed (per >> your analysis) >> - route-views data on related announcements (e.g. exact-match or >> longer-prefix that form the basis for the AS_SET aggregates) >> >> This would be the actual data, not just "counts" of the number of >> prefixes. >> Knowing who is doing this, which prefixes are affected, and such, will >> help inform us on the usage of AS_SET "in the wild". >> >> Also, along with those prefixes, could you search the route-views data >> to find out when the first announcement for each (even roughly, YYYY-MM >> is good enough) occurred, with the current values? >> >> If something has been announced in exactly the same form, for a very >> long time, perhaps the configuration is just being "left alone" because >> none of the techies at the organization understand what it is, what it >> does, or why it is there? >> >> And maybe someone could do out-reach to those entities to show them why >> & how what they are doing is not necessary, and how to achieve whatever >> the original goals were, without using AS_SET? >> >> (If we can reduce the well-formed instances "in the wild" to as close to >> zero as possible, I think it would be safe to then treat the malformed >> AS_SET instances as outliers, regardless of quantity.) >> >> It is a lot easier to deprecate something that isn't being used >> correctly at all, than something that is *almost* not being used >> correctly at all. >> >> And even if the latter, I am in favor of adoption of this as a WG item. >> >> I'm just suggesting the above to move away from the "angels dancing on >> the head of a pin" kind of discussion. >> >> Brian >> >> On Mon, Jul 9, 2012 at 12:21 PM, Sriram, Kotikalapudi >> >> >> wrote: >> >> Recall that RFC6472/BCP172 is a *recommendation* for not using >> AS_SET and AS_CONFED_SET in BGP. >> It was intended that eventually there would be a document to >> *proscribe* >> the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGP. >> So this document ( >> http://tools.ietf.org/html/**draft-kumari-deprecate-as-set-** >> confed-set-00) >> is being submitted for consideration by the WG to start work on a >> standards-track RFC >> for deprecation of AS_SET and AS_CONFED _SET in BGPv4. >> Any comments and suggestions would be welcome and much appreciated. >> >> Sriram / Warren >> >> -----Original Message----- >> From: internet-drafts@ietf.org >> > >> [mailto:internet-drafts@ietf.**org > internet-drafts@ietf.**org >] >> Sent: Friday, July 06, 2012 7:40 PM >> To: sriram.ietf@gmail.com >> Cc: warren@kumari.net ; Sriram, >> Kotikalapudi >> Subject: New Version Notification for >> draft-kumari-deprecate-as-set-**confed-set-00.txt >> >> A new version of I-D, draft-kumari-deprecate-as-set-** >> confed-set-00.txt >> has been successfully submitted by Kotikalapudi Sriram and posted to >> the IETF repository. >> >> Filename: draft-kumari-deprecate-as-set-**confed-set >> Revision: 00 >> Title: Deprecation of AS_SET and AS_CONFED_SET in BGP >> Creation date: 2012-07-07 >> WG ID: Individual Submission >> Number of pages: 6 >> URL: >> http://www.ietf.org/internet-**drafts/draft-kumari-deprecate-** >> as-set-confed-set-00.txt >> Status: >> http://datatracker.ietf.org/**doc/draft-kumari-deprecate-as-** >> set-confed-set >> Htmlized: >> http://tools.ietf.org/html/**draft-kumari-deprecate-as-set-** >> confed-set-00 >> >> Abstract: >> RFC 6472 (i.e., BCP 172) recommends not using AS_SET and >> AS_CONFED_SET in BGP. This document updates RFC 4271 and >> proscribes >> the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in >> BGPv4. This is done to simplify the design and implementation >> of BGP >> and to make the semantics of the originator of a route more clear. >> This will also simplify the design, implementation, and >> deployment of >> ongoing work in the Secure Inter-Domain Routing Working Group. >> >> The IETF Secretariat >> ______________________________**_________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/**listinfo/idr >> >> >> >> >> >> ______________________________**_________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/**listinfo/idr >> >> > > --f46d04389041c1b2cd04c46a851e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the original intent of AS_SET, as being used when aggregating, shou= ld be kept separate from instances of "overloading" the attribute= for new functionality (e.g. multipath).

So, let's c= onsider the "classic" AS_SET instances, which are quite possibly = the reason we see AS_SET in the wild.

(BTW - I took a quick look at a very recent snapshot fr= om routeviews, and see a grand total of 14 prefixes with non-singular, non-= private AS_SET values, i.e. only 14 instance where the AS_SET contains more= than one ASN, and the ASN set does not contain any private ASNs. So the de= ployed use cases in the DFZ, "in the wild", looks like only 14 to= tal. Regardless of deployed code, if we get those 14 instances to fix their= configs to not do AS_SET, we should be able to move on to depracating AS_S= ET, and at least, moving forward, can get rid of it from new code, and avoi= d having to include support for it in updates to the protocol.)

Can anyone explain why it is necessary to have an AS_SE= T at all, i.e. can anyone give an example where bad things happen without A= S_SET, and those bad things don't happen when AS_SET is used?

The text of 4271 seems to indicate that ATOMIC_AGGREGAT= E was needed for signaling that what would have required an AS_SET has had = the AS_SET remove, but that in a CIDR-only world, that ATOMIC_AGGREGATE is = basically informational-only.

And this, in turn suggests that there are actually no i= nstances where removing an AS_SET would break things.

<= div>Which leads to not only depracating the use of AS_SETs (by operators), = but hopefully to the current I-D under discussion - making AS_SET code (and= CONFED_AS_SET code) go away.

Anyone?

Brian

P.S. For the multipath case, what about just appending the two pat= hs? That was Tony Li's suggestion in SIDR, and it avoids the routing an= d routing-information loops.
P.P.S. That multipath didn't properly address its "multi-path= ness" in the withdrawal side of UPDATE messages, is not necessarily a = suitable reason to keep AS_SETs around.
P.P.P.S. In an ideal worl= d, it *should* be enough to just have multipath send the best of the multip= les to its peers. The fact that it also uses stuff other than its best, is = just additional non-control-plane stuff, and shouldn't really impact pe= ers' networks as such. If a peer's peer needs the second-best path = to avoid either loops, or instability, there are bigger problems afoot.
P.P.P.P.S. The correct solution would have been to create a new PATH e= lement, which consists of fully-formed AS_PATHs themselves, which would hav= e allowed loop prevention while keeping the ordering of AS_PATH attributes,= and would allow multi-path-aware speakers to share the extra path info. Ne= gotiated, of course.

On Mon, Jul 9, 2012 at 2:17 PM, Robert Raszu= k <robert@raszuk.net> wrote:
Hi Brian and Sriram,

Simple question ...

Some BGP implementations use AS_SET when IBGP multipath is enabled to corre= ctly advertise what is being used in data plane to a peer.

What authors of the document in question recommend to do in this case ?

And also as Enke said no matter what draft or rfc says deployed code will r= emain.

In those cases AS_SET will continue to be advertised injected by those BGP = implementations as there is no even CLI control to stop it.

The multipath code simply calls the aspath_aggregate (latest quagga code http://goo.gl/ISBWj lin= e 669) which in turn IMHO correctly inserts the AS_SET (http://goo.gl/oSsxE line 996).

Thx,
R.


The "analysis" (slide deck) does not itself detail the few cases = where
AS_SET is not used incorrectly.

Since one of the authors was involved in that analysis, for sake of
discussing this proposal, could you please provide the following?

- route-views data on AS_SET announcements that are properly formed (per your analysis)
- route-views data on related announcements (e.g. exact-match or
longer-prefix that form the basis for the AS_SET aggregates)

This would be the actual data, not just "counts" of the number of= prefixes.
Knowing who is doing this, which prefixes are affected, and such, will
help inform us on the usage of AS_SET "in the wild".

Also, along with those prefixes, could you search the route-views data
to find out when the first announcement for each (even roughly, YYYY-MM
is good enough) occurred, with the current values?

If something has been announced in exactly the same form, for a very
long time, perhaps the configuration is just being "left alone" b= ecause
none of the techies at the organization understand what it is, what it
does, or why it is there?

And maybe someone could do out-reach to those entities to show them why
& how what they are doing is not necessary, and how to achieve whatever=
the original goals were, without using AS_SET?

(If we can reduce the well-formed instances "in the wild" to as c= lose to
zero as possible, I think it would be safe to then treat the malformed
AS_SET instances as outliers, regardless of quantity.)

It is a lot easier to deprecate something that isn't being used
correctly at all, than something that is *almost* not being used
correctly at all.

And even if the latter, I am in favor of adoption of this as a WG item.

I'm just suggesting the above to move away from the "angels dancin= g on
the head of a pin" kind of discussion.

Brian

On Mon, Jul 9, 2012 at 12:21 PM, Sriram, Kotikalapudi
<kotik= alapudi.sriram@nist.gov <mailto:kotikalapudi.sriram@nist.gov>&g= t; wrote:

=A0 =A0 Recall that RFC6472/BCP172 is a *recommendation* for not using
=A0 =A0 AS_SET and AS_CONFED_SET in BGP.
=A0 =A0 It was intended that eventually there would be a document to *prosc= ribe*
=A0 =A0 the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGP= .
=A0 =A0 So this document (
=A0 =A0 http://tools.ietf.org/html/draft-k= umari-deprecate-as-set-confed-set-00 )
=A0 =A0 is being submitted for consideration by the WG to start work on a =A0 =A0 standards-track RFC
=A0 =A0 for deprecation of AS_SET and AS_CONFED _SET in BGPv4.
=A0 =A0 Any comments and suggestions would be welcome and much appreciated.=

=A0 =A0 Sriram / Warren

=A0 =A0 -----Original Message-----
=A0 =A0 From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
=A0 =A0 [mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>= ;]
=A0 =A0 Sent: Friday, July 06, 2012 7:40 PM
=A0 =A0 To: srir= am.ietf@gmail.com <mailto:sriram.ietf@gmail.com>
=A0 =A0 Cc: warren@k= umari.net <mailto:warren@kumari.net>; Sriram, Kotikalapudi
=A0 =A0 Subject: New Version Notification for
=A0 =A0 draft-kumari-deprecate-as-set-confed-set-00.txt

=A0 =A0 A new version of I-D, draft-kumari-deprecate-as-set-confed-s= et-00.txt
=A0 =A0 has been successfully submitted by Kotikalapudi Sriram and posted t= o
=A0 =A0 the IETF repository.

=A0 =A0 Filename: =A0 =A0 =A0 =A0draft-kumari-deprecate-as-set-confe= d-set
=A0 =A0 Revision: =A0 =A0 =A0 =A000
=A0 =A0 Title: =A0 =A0 =A0 =A0 =A0 Deprecation of AS_SET and AS_CONFED_SET = in BGP
=A0 =A0 Creation date: =A0 2012-07-07
=A0 =A0 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
=A0 =A0 Number of pages: 6
=A0 =A0 URL:
=A0 =A0 http://www.ietf.org/internet= -drafts/draft-kumari-deprecate-as-set-confed-set-00.txt =A0 =A0 Status:
=A0 =A0 http://datatracker.ietf.org/doc/= draft-kumari-deprecate-as-set-confed-set
=A0 =A0 Htmlized:
=A0 =A0 http://tools.ietf.org/html/draft-k= umari-deprecate-as-set-confed-set-00

=A0 =A0 Abstract:
=A0 =A0 =A0 =A0 RFC 6472 (i.e., BCP 172) recommends not using AS_SET and =A0 =A0 =A0 =A0 AS_CONFED_SET in BGP. =A0This document updates RFC 4271 and= proscribes
=A0 =A0 =A0 =A0 the use of the AS_SET and AS_CONFED_SET types of the AS_PAT= H in
=A0 =A0 =A0 =A0 BGPv4. =A0This is done to simplify the design and implement= ation
=A0 =A0 of BGP
=A0 =A0 =A0 =A0 and to make the semantics of the originator of a route more= clear.
=A0 =A0 =A0 =A0 This will also simplify the design, implementation, and
=A0 =A0 deployment of
=A0 =A0 =A0 =A0 ongoing work in the Secure Inter-Domain Routing Working Gro= up.

=A0 =A0 The IETF Secretariat
=A0 =A0 _______________________________________________
=A0 =A0 Idr mailing list
=A0 =A0 Idr@ietf.org = <mailto:Idr@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/listinfo/idr
=




_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr




--f46d04389041c1b2cd04c46a851e-- From jhaas@slice.pfrc.org Mon Jul 9 12:51:49 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5998011E80CB for ; Mon, 9 Jul 2012 12:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.114 X-Spam-Level: X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB7ScNP7RKoU for ; Mon, 9 Jul 2012 12:51:48 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D661711E8083 for ; Mon, 9 Jul 2012 12:51:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7A230C710; Mon, 9 Jul 2012 15:52:13 -0400 (EDT) Date: Mon, 9 Jul 2012 15:52:13 -0400 From: Jeffrey Haas To: Brian Dickson Message-ID: <20120709195213.GC30232@pfrc> References: <4FFB2020.7080003@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org" , "Sriram, Kotikalapudi" , robert@raszuk.net Subject: Re: [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:51:49 -0000 I really need to write an informational rfc on this. My answers below are extremely esoteric BGP-fu, some of which was reverse engineered from old gated code and watching the evolution of RFCs and I-Ds. :-) On Mon, Jul 09, 2012 at 03:21:36PM -0400, Brian Dickson wrote: > I think the original intent of AS_SET, as being used when aggregating, > should be kept separate from instances of "overloading" the attribute for > new functionality (e.g. multipath). The problem here is that in terms of multipath, there exist topologies where it is not safe to provide a transparent aggregation of paths for forwarding purposes. I.e. if you use some vendor based multipath knobs at the wrong place and you're someone's transit provider, there's a possibility that forwarding loops can form. The fact that they don't mostly attest to the multipath knobs in question being used in sane places. The only way in such a possibly unsafe place to prevent real forwarding loops from being formed is to aggregate the paths into a set. However, existing implementations largely do not generate an AS_SET without also resulting in a shorter prefix. (Yes, the topology exists, but John would have to reconstruct it because my copy of it got eaten by an overly aggressive mail server.) > So, let's consider the "classic" AS_SET instances, which are quite possibly > the reason we see AS_SET in the wild. > > (BTW - I took a quick look at a very recent snapshot from routeviews, and > see a grand total of 14 prefixes with non-singular, non-private AS_SET > values, i.e. only 14 instance where the AS_SET contains more than one ASN, > and the ASN set does not contain any private ASNs. So the deployed use > cases in the DFZ, "in the wild", looks like only 14 total. Regardless of > deployed code, if we get those 14 instances to fix their configs to not do > AS_SET, we should be able to move on to depracating AS_SET, and at least, > moving forward, can get rid of it from new code, and avoid having to > include support for it in updates to the protocol.) You're perhaps looking at this too politely: If the bulk of the Internet threw away those 14 or so routes, who'd notice? That has tended to be bigger motivation than anything else. > Can anyone explain why it is necessary to have an AS_SET at all, i.e. can > anyone give an example where bad things happen without AS_SET, and those > bad things don't happen when AS_SET is used? The typical deployment of an AS_SET was an upstream provider servicing a set of downstream providers from a small number of address spaces. The downstream providers received more specific routes from the less specific space. Everyone spoke BGP to each other in this group of ASes. The downstreams may even have direct peering sessions with each other. The upstream would aggregate the routes together and all of the contributing ASes would end up in the set. The upstream would also suppress the more specific routes. A side effect of this aggregation is that the downstream ASes must have their more specific routes from each other or from the upstream. This is because a side effect of the AS_SET based aggregate was that no one in the contributing set of routes could receive the less specific because it was a loop. Another implementation solved the problem simply by letting you nail up the less specific route and originating that directly. For the topologies that were largely covered by AS_SET type aggregation above, that was fine. Over a short amount of time, filtering of more specific routes became less aggressive or the smaller providers renumbered into real space. Note that I can only vouch for the above as lore rather than point to the data. I suspect others on this list (if they're still reading) can give more first-hand accounts. > The text of 4271 seems to indicate that ATOMIC_AGGREGATE was needed for > signaling that what would have required an AS_SET has had the AS_SET > remove, but that in a CIDR-only world, that ATOMIC_AGGREGATE is basically > informational-only. Atomic aggregate needed its own FAQ. :-P The feature was originally added in as a signalling mechanism mostly useful for transitional practices between BGP-3 and BGP-4. The meaning of the attribute is "do not deaggregate this - loops may occur if you do". The thing is, most people never de-aggregate. The Net transitioned over to BGP-4 in pretty short order, so even that wasn't important for long. The scenarios covered by the original text for the feature and the text proposed across several versions of draft-ietf-idr-bgp4 covering this feature went from incomplete to more complete to complete would be insane, let's mostly ignore this. The text largely as written said that if you aggregate and path information would be lost, add the attribute. The trouble is this covered not only explicit aggregation by creating a shorter prefix route but also suppressing more specific routes when you have a less specific one. As best I can tell, no one got the implicit aggregate feature implemented. There was also the problem that the specification covered the inbound (AdjRibsIn to LocRib) case only. You could end up with the same scenario on an outbound basis as well. Coding for that was impractical. > Which leads to not only depracating the use of AS_SETs (by operators), but > hopefully to the current I-D under discussion - making AS_SET code (and > CONFED_AS_SET code) go away. You can't make code for it completely go away. There at minimum would always be stub code to match for it and not drop peering sessions while at the same time suppressing the routes. > P.S. For the multipath case, what about just appending the two paths? That > was Tony Li's suggestion in SIDR, and it avoids the routing and > routing-information loops. I'm behind in SIDR, but SIDR can't provide anything provable for forwarding. That is currently true today for multipath. > P.P.P.S. In an ideal world, it *should* be enough to just have multipath > send the best of the multiples to its peers. The fact that it also uses > stuff other than its best, is just additional non-control-plane stuff, and > shouldn't really impact peers' networks as such. If a peer's peer needs the > second-best path to avoid either loops, or instability, there are bigger > problems afoot. I suspect you haven't been following add-path enough. :-) > P.P.P.P.S. The correct solution would have been to create a new PATH > element, which consists of fully-formed AS_PATHs themselves, which would > have allowed loop prevention while keeping the ordering of AS_PATH > attributes, and would allow multi-path-aware speakers to share the extra > path info. Negotiated, of course. FWIW, this case is similar to the multipath case above that I was discussing would require sets. An immediate consequence of this is "multipath routes" with paths that churn as components are added or removed from being multipath contributors. If you thought BGP was noisy before, you've seen nothing yet. -- Jeff From jrmitche@puck.nether.net Mon Jul 9 13:26:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4BB11E8105 for ; Mon, 9 Jul 2012 13:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyN2RDgVsj1h for ; Mon, 9 Jul 2012 13:26:35 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5A29E11E80FE for ; Mon, 9 Jul 2012 13:26:35 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q69KR0CU009879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2012 16:27:00 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q69KR0Cq009871; Mon, 9 Jul 2012 16:27:00 -0400 Date: Mon, 9 Jul 2012 16:27:00 -0400 From: Jon Mitchell To: Jeffrey Haas Message-ID: <20120709202700.GA5264@puck.nether.net> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703021238.GM18361@pfrc> <20120703133948.GB22598@puck.nether.net> <20120709172545.GF22984@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120709172545.GF22984@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 09 Jul 2012 16:27:00 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 20:26:36 -0000 Jeff - Thanks, this is a strong argument and I agree it stands to reason operators should not be utilizing AS 65535 due to the reserved use of all of that AS's standard communities (and current use of three of them) through RFC 1997, which I do not intend to have impact on. However, since this draft proposes to update RFC 1930, I'm still inclined to "fix" this documentation issue (whether or not vendors choose to strip the last ASN is another matter and I don't believe this stripping behavior has ever been stadarized by IETF anyway), by putting both ranges in the RFC and ending the existing range at 65534 so that IETF and IANA can agree on the private use range. Do you think for consistency sake and future possible use to not include the last ASN of the new private use range as well? Cheers, Jon On Mon, Jul 09, 2012 at 01:25:45PM -0400, Jeffrey Haas wrote: > On Tue, Jul 03, 2012 at 09:39:48AM -0400, Jon Mitchell wrote: > > [JM] This is interesting, however given these ASNs are in use today and > > there is widespread mis-understanding that the 65535 ASN is a private > > use ASN already based on widespread vendor and other networking > > documentation, I think publishing this informational draft to > > officially allocate it as such is not going to cause a rush of changes > > to use it on devices this old. However new implementors would have > > clear guidance on what a private ASN if they are trying to comply with > > this draft/RFC if/when it's published and therefore could avoid this > > leaving this open to error in new implementations. > > There is another very strong argument to leave AS 65535 alone as a reserved > AS rather than noting it can be used as "just another private AS": > Communities. While users of that AS would likely be addressing their > communities to someone else's AS, why preclude them from being able to > receive any addressed to their own AS? > > (If it's not immediately apparent, RFC 1997 well known communities are > effectively addressed to AS 65535.) > > -- Jeff From jhaas@slice.pfrc.org Mon Jul 9 13:39:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E70711E81E8 for ; Mon, 9 Jul 2012 13:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.123 X-Spam-Level: X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYifviypgVai for ; Mon, 9 Jul 2012 13:39:17 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B840111E81D5 for ; Mon, 9 Jul 2012 13:39:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E7AC6C799; Mon, 9 Jul 2012 16:39:36 -0400 (EDT) Date: Mon, 9 Jul 2012 16:39:36 -0400 From: Jeffrey Haas To: Jon Mitchell Message-ID: <20120709203936.GB3348@pfrc> References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703021238.GM18361@pfrc> <20120703133948.GB22598@puck.nether.net> <20120709172545.GF22984@pfrc> <20120709202700.GA5264@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120709202700.GA5264@puck.nether.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 20:39:17 -0000 On Mon, Jul 09, 2012 at 04:27:00PM -0400, Jon Mitchell wrote: > However, > since this draft proposes to update RFC 1930, I'm still inclined to > "fix" this documentation issue (whether or not vendors choose to strip > the last ASN is another matter and I don't believe this stripping > behavior has ever been stadarized by IETF anyway), by putting both > ranges in the RFC and ending the existing range at 65534 so that IETF > and IANA can agree on the private use range. If the draft ends up solely dealing with instructions to IANA, it'd be fine for it to be in there. It'd simply reflect the current registration of 65535 as "reserved". > Do you think for consistency sake and future possible use to not include > the last ASN of the new private use range as well? This rather depends on where the new private range lies. In the case of the 2-byte space, the last private AS also happened to be the all-1's number. If the new private AS range is at the end of the possible range, we'd want that. Note that 2^32-1 is already reserved in the registry. -- Jeff From farmer@umn.edu Mon Jul 9 17:21:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F8411E8148 for ; Mon, 9 Jul 2012 17:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j3JAzyzHvWY for ; Mon, 9 Jul 2012 17:21:00 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id DF7F911E8123 for ; Mon, 9 Jul 2012 17:20:59 -0700 (PDT) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.213.171]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 9 Jul 2012 19:21:15 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-yx0-f171.google.com [209.85.213.171] #+LO+TR X-Umn-Classification: local Received: by mail-yx0-f171.google.com with SMTP id q11so19407696yen.16 for ; Mon, 09 Jul 2012 17:21:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=X452oZFOgA4olVxJjaEyMqIsgdGyrbVCNl3WSPckOCE=; b=kRe4BWXMefrDvgJ+xAU9ODMjzozxG9yoTNUJWai6Jwpqcx8C7eCHeBZft2ar7rpbjP IwRbmtLBX7mcDpDzYR9i+68YCiDSpRehixG0BdCdeN1psjTCePkAm92Uc5GXw1xCZ+eX AVzpEZh4I/09GJnw2CrCdo8MG8jveYLInR5u0VggPhunCDL6HmvsOf1XiIZ8fUUJlzC+ rFKnOM+4+GmpZ+LK4jBx1un/dZZ3DEV8ZvWg4aiDnN5k7ebNG8ZzH/2Ug2QIXNp0GoWO PLHtDg3Hn857GuY4izATz1TaCZtRrF+j4RUCDSaPowErNZx5uI/hR1prcmNTtMw83Yln IYLw== Received: by 10.50.100.137 with SMTP id ey9mr9771860igb.61.1341879675232; Mon, 09 Jul 2012 17:21:15 -0700 (PDT) Received: from x-134-84-88-76.nts.umn.edu ([2607:ea00:101:2001:223:dfff:fe83:bf68]) by mx.google.com with ESMTPS id nh1sm10263246igc.11.2012.07.09.17.21.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 17:21:14 -0700 (PDT) Message-ID: <4FFB7579.2030008@umn.edu> Date: Mon, 09 Jul 2012 19:21:13 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jeffrey Haas , Jon Mitchell References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc> <20120703015521.GB22452@puck.nether.net> <20120703021238.GM18361@pfrc> <20120703133948.GB22598@puck.nether.net> <20120709172545.GF22984@pfrc> <20120709202700.GA5264@puck.nether.net> <20120709203936.GB3348@pfrc> In-Reply-To: <20120709203936.GB3348@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm2kv2FdXS9eZPb4YRDX5PRdUcfAZDq0NO0w1IofUmle/DsGzuPuv9UcxeOYglTbDXjLt0J Cc: idr@ietf.org Subject: Re: [Idr] new ID on expansion of private use ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 00:21:01 -0000 I just had an idea I though I would float. What if this draft dealt exclusively with defining a new larger private range in 4-byte ASN land. It wouldn't have to update RFC 1930 then and it could just stand on its own, RFC 1930 could just be a Normative Reference defining Private Use ASNs. Then do another Draft "Special Use ASNs", kind of the ASN equilivant of RFC 5735, summarizing all of the special use ASNs with References. Then it could clarify that 65535 is not a Private ASN but a reserved ASN, updating RFC 1930 if that is really necessary. Just a quick list; 0 - Reserved - draft-ietf-idr-as0, RFC 1997 and RFC 6491 23456 - AS_TRANS - RFC 4893 64496-64511 - Documentation (16-bit) - RFC 5398 64512-65534 - Private Use (16-bit) - RFC 1930 65535 - Reserved - RFC 1997 65536-65551 - Documentation (32-bit) - RFC 5398 {new private range} - Private Use (32-bit) - draft-mitchell-idr-as-private-reservation 4294967295 - Reserved - Does this have a special use or is it just reserved, as all ones? There are already a non-trivial number of Special Use ASNs or ranges of ASNs, enough that having them summarized in a single place would probably be helpful. I know I find RFC 5735 useful from time to time. Like I said, just an idea I thought I would float. Thanks. On 7/9/12 15:39 CDT, Jeffrey Haas wrote: > On Mon, Jul 09, 2012 at 04:27:00PM -0400, Jon Mitchell wrote: >> However, >> since this draft proposes to update RFC 1930, I'm still inclined to >> "fix" this documentation issue (whether or not vendors choose to strip >> the last ASN is another matter and I don't believe this stripping >> behavior has ever been stadarized by IETF anyway), by putting both >> ranges in the RFC and ending the existing range at 65534 so that IETF >> and IANA can agree on the private use range. > > If the draft ends up solely dealing with instructions to IANA, it'd be fine > for it to be in there. It'd simply reflect the current registration of > 65535 as "reserved". > >> Do you think for consistency sake and future possible use to not include >> the last ASN of the new private use range as well? > > This rather depends on where the new private range lies. In the case of the > 2-byte space, the last private AS also happened to be the all-1's number. > If the new private AS range is at the end of the possible range, we'd want > that. Note that 2^32-1 is already reserved in the registry. > > -- Jeff > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jgs@juniper.net Thu Jul 12 12:31:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93B021F8575 for ; Thu, 12 Jul 2012 12:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PvIjCHIxyxI for ; Thu, 12 Jul 2012 12:31:59 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2002B21F855A for ; Thu, 12 Jul 2012 12:31:59 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT/8mUTcfx7qI99VkNuZ8z+hSuB+miXK8@postini.com; Thu, 12 Jul 2012 12:32:33 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 12 Jul 2012 12:31:02 -0700 From: John Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jul 2012 15:31:02 -0400 Message-ID: <79714F39-086A-4D57-9C87-4B595A89D6DE@juniper.net> To: "idr@ietf.org List" MIME-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Idr] IETF-84 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 19:31:59 -0000 Folks, We're planning to meet at IETF-84 on Monday from 13:00 to 15:30. Please = forward any IDR agenda items you might have to Sue and myself. The = deadline is July 17 by 13:00 U.S. Eastern Time, although earlier is = better. Given the tardiness of this announcement we'll work to = accommodate those who need additional time, but priority will still be = given to those who get their requests in before the deadline. If you have previously presented on your topic at an IDR meeting, please = explain in your request what you hope to achieve with your presentation = this time. If you plan to make a presentation, please keep in mind the IDR = tradition, "no Internet Draft - no time slot". You should also plan to = send your slides to Sue and me no later than 24 hours prior to the = meeting. Finally, if you request an agenda slot, please do so by replying to this = message and don't change the subject line. Thanks, --John & Sue From robert@raszuk.net Sun Jul 15 02:46:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B723F21F85E1 for ; Sun, 15 Jul 2012 02:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.11 X-Spam-Level: X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mqy7kCSFEUZK for ; Sun, 15 Jul 2012 02:46:19 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 967A321F8579 for ; Sun, 15 Jul 2012 02:46:19 -0700 (PDT) Received: (qmail 31232 invoked by uid 399); 15 Jul 2012 09:46:59 -0000 Received: from unknown (HELO ?10.53.7.165?) (pbs:robert@raszuk.net@80.187.201.11) by mail1310.opentransfer.com with ESMTPM; 15 Jul 2012 09:46:59 -0000 X-Originating-IP: 80.187.201.11 Message-ID: <5002918F.3010107@raszuk.net> Date: Sun, 15 Jul 2012 02:46:55 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ahmed Bashandy References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> In-Reply-To: <4FFB2330.4020809@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 09:46:20 -0000 Hi Ahmed, Encouraged by your kind invitation let me first try to clarify few things reg the proposal. > ii. If "rL" is per-VRF, then pop *two* labels and forward the > packet based on the contents under the two popped labels I am afraid this does not work. VRF lookup on any rPE would still contain the the original best path towards the PE which failed. This is for any AFI/SAFI. Remember the BGP best path has not executed yet to eliminate the BGP best path which can be influenced by local preference or MED. Your case mistakenly assumed that locally received EBGP route always win, however this is not the case in BGP. You re referring to per VRF lookup option in many places of the draft - that needs to be deleted. Only per-CE label where "last hop" rPE does not perform IP lookup may work. > a. Acting as a rPE, PE1 allocates (on per-CE basis) and > advertises a repair label rL1=3100 with the prefixes > 10.0.0.0/8 and 11.0.0.0/8 to all iBGP peers Another issue in your proposal is that you assume that rPE will be a protecting PE for everyone. Again in BGP this is not the case as during best path iPEs will consider BGP next hop metric. Therefor for the identical destination the same PE can be rPE for some iPEs while in the same time it can be pPE for other iPEs. I do not see how in any BGP today you could signal both types of labels (even if the label is per CE). > . When does the penultimate hop stop advertising pNH as its > own prefix? The penultimate hop should continue to > advertise pNH long enough for iPE's to re-converge. > Advertising pNH longer than necessary is harmless because > iPE's would have already re-converged to a new BGP next- > hop and hence no traffic will be attracted to the non- > existing pNH. The specific period length can be subject > to configuration but the default value may be in the > order of 2-3 minutes I really do not think this section is necessary. I do not understand how we can stop advertising pNH from PHP node. If we stop when do we start again ? > 3. Penultimate Hop > a. Receives a packet with top label bound to pNH > b. Pops *three* labels *all the time*. Are you sure that current LSRs can pop more then one label on the stack? Since the early days of MPLS it was my understanding that except the special labels (null labels) MPLS LSRs do not POP more then one label. I am not sure if this is spelled out in any of the MPLS specifications, but I think it would be great to have some sort of assurance that this is doable not only in theory but also in practice > 3. Overview of the BGP FRR using Vector Labels in an IP Core > > This section describes the BGP FRR using vector labels solution in an > IP core for both labeled (AFI/SAFI 1/4, 2/4, 1/128, and 2/128) and > unlabeled (AFI/SAFI 1/1, 2/1, 1/2, and 2/2) protected prefixes. + > The pPE needs to advertise the mapping (bgpNH,pNH). iPE also needs to > allocate a vector label for each known rPE and advertise the mapping > (pNH,rNH,vL) I am not following this section. Let's consider SAFI 1/1. What is the "rL" if I am not running MPLS ? Same for vector label "vL" ? What protocol distributes those labels ? > a. Assume that PE0 uses "Loopback0" as the BGP next-hop, PE0 > automatically picks Loopback2 as the pNH. As such PE0 > advertises (bgpNH,pNH)=(1.1.1.1,1.1.1.2) to all iBGP peers > including the iPE PE11. When you say that PE0 advertises pair of next hops ? How is this encoded ? What is the semantics of this encoding ? > a. On receiving the repair labels 3100 and 3200 from PE1 and > PE2, respectively, PE0 detects that there are two rPEs: PE1 > and PE2. AS such PE0 assigns two vector labels vL1 = 1100 > and vL2 = 1200 to PE1 and PE2, respectively How can PE0 receive the repair labels from PE1 and PE2 if we take SAFI 1/1 and no add-paths ? Anyhow we do not even know that the rL is for SAFI 1/1 yet :) For VPNs you assume different RD per VRF. That still does not work as I mentioned above. The rPE will be a primary PPE for some ingress PEs. Best regards, R. > Hi, > > The draft proposes a new method for BGP FRR. > > The approach is very scalable as it does not require injecting any > prefixes into the core, no re-advertisement of BGP prefixes, and no > state replication. At the same time, it is transparent to the operator > in the sense that if it is enabled by default, there is no need for > human intervention due to any reason including internal and external > topology changes or even when switching from MPLS to IP core and back > > All comments are most welcomed > > Thanks > Ahmed From shares@ndzh.com Mon Jul 16 14:50:58 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC5321F875D; Mon, 16 Jul 2012 14:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqrRZ1qFO3hH; Mon, 16 Jul 2012 14:50:57 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 49D1121F875A; Mon, 16 Jul 2012 14:50:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=63.133.198.20; Received: from SKH2012HPLT (unverified [63.133.198.20]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3458822-1945496 for multiple; Mon, 16 Jul 2012 17:51:40 -0400 From: "Susan Hares" To: "'Ahmed Bashandy'" , , References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> In-Reply-To: <4FFB2330.4020809@cisco.com> Date: Mon, 16 Jul 2012 17:51:39 -0400 Message-ID: <000c01cd639d$2e3f0630$8abd1290$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CD637B.A7392600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJaU3tI8rbwHuAvE5KejGfrXR6iaAFyCLallgcCZBA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'Maciek Konstantynowicz \(mkonstan\)'" Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 21:50:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01CD637B.A7392600 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ahmed: =20 Can provide a short comparison of this BGP frr with past attempts for = BGP FRR? =20 If you wish a list of the BGP FRR drafts, please let me know. =20 sue =20 From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Ahmed Bashandy Sent: Monday, July 09, 2012 2:30 PM To: idr@ietf.org List; rtgwg@ietf.org Cc: Maciek Konstantynowicz (mkonstan) Subject: [Idr] Fwd: New Version Notification for = draft-bashandy-bgp-frr-vector-label-00.txt =20 =20 Hi, The draft proposes a new method for BGP FRR.=20 The approach is very scalable as it does not require injecting any = prefixes into the core, no re-advertisement of BGP prefixes, and no = state replication. At the same time, it is transparent to the operator = in the sense that if it is enabled by default, there is no need for = human intervention due to any reason including internal and external = topology changes or even when switching from MPLS to IP core and back All comments are most welcomed Thanks Ahmed -------- Original Message --------=20 Subject:=20 New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt Date:=20 Sun, 8 Jul 2012 07:05:43 -0700 From:=20 To:=20 CC:=20 , = =20 A new version of I-D, draft-bashandy-bgp-frr-vector-label-00.txt has been successfully submitted by Ahmed Bashandy and posted to the IETF repository. =20 Filename: draft-bashandy-bgp-frr-vector-label Revision: 00 Title: BGP FRR Protection against Edge Node Failure Using = Vector Labels Creation date: 2012-07-07 WG ID: Individual Submission Number of pages: 32 URL: = http://www.ietf.org/internet-drafts/draft-bashandy-bgp-frr-vector-label-0= 0.txt Status: = http://datatracker.ietf.org/doc/draft-bashandy-bgp-frr-vector-label Htmlized: = http://tools.ietf.org/html/draft-bashandy-bgp-frr-vector-label-00 =20 =20 Abstract: Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/m via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it is desirable for a core router "P" carrying traffic to the failed edge router PEi to immediately restore traffic by re-tunneling packets originally tunneled to PEi and destined to the prefix P/m to one of the other edge routers that advertised P/m, say PEj, until BGP re-converges. In doing so, it is highly desirable to keep the core BGP-free while not imposing restrictions on external connectivity or complicating provisioning effort. Thus (1) a core router should not be required to learn any BGP prefix, (2) the size of the forwarding and routing tables in the core routers should be independent of the number of BGP prefixes, (3) re-routing traffic without waiting for re-convergence must not cause loops, (4) provisioning effort should be kept at minimum, and (5) there should be no restrictions on what edge routers advertise what prefixes. For labeled prefixes, (6) the label stack on the packet must allow the repair PEj to correctly forward the packet and (7) there must not be any need to perform more than one label lookup on any edge or core router during steady state =20 = =20 =20 =20 The IETF Secretariat =20 =20 ------=_NextPart_000_000D_01CD637B.A7392600 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Ahmed:

 

Can provide a short comparison of this BGP frr with past attempts for = BGP FRR?

 

If you wish a list of the BGP FRR drafts, please let me = know.

 

sue

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Ahmed Bashandy
Sent: Monday, July 09, 2012 2:30 = PM
To: idr@ietf.org List; rtgwg@ietf.org
Cc: Maciek = Konstantynowicz (mkonstan)
Subject: [Idr] Fwd: New Version = Notification for = draft-bashandy-bgp-frr-vector-label-00.txt

 

 

Hi,

The draft proposes a new method for BGP = FRR.

The approach is very scalable as it does not require = injecting any prefixes into the core, no re-advertisement of BGP = prefixes, and no state replication. At the same time, it is transparent = to the operator in the sense that if it is enabled by default, there is = no need for human intervention due to any reason including internal and = external topology changes or even when switching from MPLS to IP core = and back

All comments are most = welcomed

Thanks

Ahmed

-------- Original Message = --------

Date: =

Subject:

New Version = Notification for = draft-bashandy-bgp-frr-vector-label-00.txt

Sun, 8 Jul 2012 07:05:43 = -0700

From:

<internet-drafts@ietf.org>=

To:

<bashandy@cisco.com>

CC:

<naikumar@cisco.com>, <mkonstan@cisco.com>

 

A new version =
of I-D, =
draft-bashandy-bgp-frr-vector-label-00.txt
has been =
successfully submitted by Ahmed Bashandy and posted to =
the
IETF =
repository.
 
Filename:=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0  =
draft-bashandy-bgp-frr-vector-label
Revision:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0  =
00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0  BGP FRR Protection against Edge Node Failure Using Vector =
Labels
Creation date:  =
2012-07-07
WG =
ID:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0  Individual =
Submission
Number of pages: =
32
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/internet-drafts/draft-bashandy-bgp-frr=
-vector-label-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://datatracker.ietf.org/doc/draft-bashandy-bgp-frr-vector-label
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 http://tools.ietf.org/html/draft-bashandy-bgp-frr-vector-label-00
 
 
Abstract:
Consider a BGP free core scenario. =
Suppose the edge BGP speakers PE1,
PE2,..., PEn =
know about a prefix P/m via the external routers =
CE1,
CE2,..., CEm.=C2=A0 If the edge router PEi =
crashes or becomes totally
disconnected from the =
core, it is desirable for a core router =
"P"
carrying traffic to the failed edge =
router PEi to immediately restore
traffic by =
re-tunneling packets originally tunneled to PEi =
and
destined to the prefix P/m to one of the other =
edge routers that
advertised P/m, say PEj, until =
BGP re-converges. In doing so, it is
highly =
desirable to keep the core BGP-free while not =
imposing
restrictions on external connectivity or =
complicating provisioning
effort. Thus (1) a core =
router should not be required to learn any
BGP =
prefix, (2) the size of the forwarding and routing tables in =
the
core routers should be independent of the =
number of BGP prefixes, (3)
re-routing traffic =
without waiting for re-convergence must not =
cause
loops, (4) provisioning effort should be kept =
at minimum, and (5)
there should be no restrictions =
on what edge routers advertise what
prefixes. For =
labeled prefixes, (6) the label stack on the =
packet
must allow the repair PEj to correctly =
forward the packet and (7)
there must not be any =
need to perform more than one label lookup on
any =
edge or core router during steady =
state
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
 
 
The IETF Secretariat

 

 

------=_NextPart_000_000D_01CD637B.A7392600-- From internet-drafts@ietf.org Mon Jul 16 16:08:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5AE11E825A; Mon, 16 Jul 2012 16:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zgh+KqdTgSPQ; Mon, 16 Jul 2012 16:08:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3EA11E813D; Mon, 16 Jul 2012 16:08:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716230846.2027.26818.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:08:46 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ix-bgp-route-server-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:08:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Internet Exchange Route Server Author(s) : Elisa Jasinska Nick Hilliard Robert Raszuk Niels Bakker Filename : draft-ietf-idr-ix-bgp-route-server-01.txt Pages : 11 Date : 2012-07-16 Abstract: This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more exterior BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ix-bgp-route-server-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-ix-bgp-route-server-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bashandy@cisco.com Mon Jul 16 16:28:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7CE11E82BD; Mon, 16 Jul 2012 16:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0ofwMvZkE6B; Mon, 16 Jul 2012 16:28:13 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8D82211E82B8; Mon, 16 Jul 2012 16:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=10132; q=dns/txt; s=iport; t=1342481336; x=1343690936; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=0VsWR3gt2cbZvxY6OpFlkrJbg3UpJivs9Ttp5FS+aXU=; b=iu5uvJIaddmKUiWEvVjsB6qJf2aycB/44i2rJdzYb+Q0Qkxt6JodAG29 3PjxI5H8gT0V9ApEvELuCQIvdYw9igyN19LzKZL7QapvbbaK2dru/9KMg wbWDKLlfltm+4FWd+bgox3NH6dRDdALe5NGiJHH3zIeoVplMcN+DU+GUt 8=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,598,1336348800"; d="asc'?scan'208";a="49535936" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 16 Jul 2012 23:28:56 +0000 Received: from [171.71.139.5] (dhcp-171-71-139-5.cisco.com [171.71.139.5]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6GNSupR031241; Mon, 16 Jul 2012 23:28:56 GMT Message-ID: <5004A3B2.4040606@cisco.com> Date: Mon, 16 Jul 2012 16:28:50 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: robert@raszuk.net References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> In-Reply-To: <5002918F.3010107@raszuk.net> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEBB26429791D2718491B2673" Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:28:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEBB26429791D2718491B2673 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks a lot for the comments. See Inline. Look for "AB:" Thanks Ahmed On 7/15/2012 2:46 AM, Robert Raszuk wrote: > Hi Ahmed, > > Encouraged by your kind invitation let me first try to clarify few > things reg the proposal. > >> ii. If "rL" is per-VRF, then pop *two* labels and forward the >> packet based on the contents under the two popped labels > > I am afraid this does not work. > > VRF lookup on any rPE would still contain the the original best path > towards the PE which failed. This is for any AFI/SAFI. Remember the > BGP best path has not executed yet to eliminate the BGP best path > which can be influenced by local preference or MED. > > Your case mistakenly assumed that locally received EBGP route always > win, however this is not the case in BGP. AB: I thought it is understandable because the draft talks about a pre-calculated repair path. But it looks like I should say something like: The behavior explained in this document requires the support for multipath, such as best external or add-path. I'll also add a statement as follows: rPE advertises "rL" with a labeled prefix P/m only if it has an external path for the prefix and rPE is administratively permitted to protect the prefix. For unlabeled prefixes, rL is only needed if one of the best paths chosen by rPE is not an external path. The label "rL" is associated with the external path(s) only. > > > You re referring to per VRF lookup option in many places of the draft > - that needs to be deleted. Only per-CE label where "last hop" rPE > does not perform IP lookup may work. AB: If I add the statement mentioning that rL is only associated with external path, then it becomes an implementation detail to say that a router only considers external paths for packets arriving with rL even if the router makes an IP lookup to determine the next-hop. But I agree with you that per-CE rL is better and simpler to implement. I will not be so hung up on the per-VRF option if people think that per-CE is sufficient > >> a. Acting as a rPE, PE1 allocates (on per-CE basis) and >> advertises a repair label rL1=3D3100 with the prefixes >> 10.0.0.0/8 and 11.0.0.0/8 to all iBGP peers > > Another issue in your proposal is that you assume that rPE will be a > protecting PE for everyone. > AB: As I mentioned above, I will add a statement mentioning that multi-path support is required and that rPE advertises rL for prefixes to which rPE has an external path and is administratively allowed to do s= o. > Again in BGP this is not the case as during best path iPEs will > consider BGP next hop metric. Therefor for the identical destination > the same PE can be rPE for some iPEs while in the same time it can be > pPE for other iPEs. > > I do not see how in any BGP today you could signal both types of > labels (even if the label is per CE). AB: I do not understand "both types" refers to which types. But anyway, for a router support any type of fast convergence, such as BGP-PIC or PE-CE link protection, it has to support the notion of more than one path= =2E > > >> . When does the penultimate hop stop advertising pNH as its >> own prefix? The penultimate hop should continue to >> advertise pNH long enough for iPE's to re-converge. >> Advertising pNH longer than necessary is harmless because >> iPE's would have already re-converged to a new BGP next- >> hop and hence no traffic will be attracted to the non- >> existing pNH. The specific period length can be subject >> to configuration but the default value may be in the >> order of 2-3 minutes > > I really do not think this section is necessary. I do not understand > how we can stop advertising pNH from PHP node. If we stop when do we > start again ? AB: Again I though it is clear. But I agree with you that the bullet needs to explain two things: what are the conditions where PHP must advertise pNH and what are the conditions where PHP is allowed to withdraw pNH BTW, the statement does not imply any specific time to stop advertising pNH and the PHP may very well continue advertising pNH for ever. IMO, the statement is necessary to indicate that the PHP must continue to advertise pNH after pPE disappearance for a period long enough to avoid traffic disruption And to answer your question "If we stop when do we start again ?" The condition to start advertising pNH after stopping is the same condition to start advertising pNH for the first time. So PHP will start to advertise pNH again when gets the message (pNH) from the pPE again. > > >> 3. Penultimate Hop >> a. Receives a packet with top label bound to pNH >> b. Pops *three* labels *all the time*. > > Are you sure that current LSRs can pop more then one label on the > stack? Since the early days of MPLS it was my understanding that > except the special labels (null labels) MPLS LSRs do not POP more then > one label. I am not sure if this is spelled out in any of the MPLS > specifications, but I think it would be great to have some sort of > assurance that this is doable not only in theory but also in practice AB: This is a question about an implementation detail. But to keep the answer short, it is VERY EASY for an LSR to pop 3 labels. Routers have been doing a lot more than this at line rate for a long period of time > > >> 3. Overview of the BGP FRR using Vector Labels in an IP Core >> >> This section describes the BGP FRR using vector labels solution in = an >> IP core for both labeled (AFI/SAFI 1/4, 2/4, 1/128, and 2/128) and >> unlabeled (AFI/SAFI 1/1, 2/1, 1/2, and 2/2) protected prefixes. > + >> The pPE needs to advertise the mapping (bgpNH,pNH). iPE also needs = to >> allocate a vector label for each known rPE and advertise the mappin= g >> (pNH,rNH,vL) > > I am not following this section. Let's consider SAFI 1/1. What is the > "rL" if I am not running MPLS ? Same for vector label "vL" ? What > protocol distributes those labels ? AB: First, there is a small typo. The first word in the second sentence needs to be "pPE". Second, the response to your first comment at the beginning of this email explains the usage of "rL" with unlabeled prefixe= s Now let me answer the questions about this paragraph, which I believe they are specific to unlabeled prefixes First question: What is "rL" if I am not running MPLS? rL is a label that informs rPE to always send the packet to an external path. rL has no semantics in the core at all. So the protocol running in the core is totally irrelevant to "rL" Second question: What is "vL" in a pure IP core? Section 3.1 talks about the case where all core routers, including the repairing router "rP", do not understand MPLS. In that case, vL is not use at all. If it is mentioned, then it is probably a mistake Section 3.2 talks about the case where the repairing core router "rP" understands MPLS but the rest of the core routers does not. In that case, "vL" is used the similar to how it is used in MPLS core Third question: What protocol distributes those labels ? Only "vL" needs to be distributed to the core. An optional TLV in ISIS or OSPF can be used to distribute "vL". > >> a. Assume that PE0 uses "Loopback0" as the BGP next-hop, PE0 >> automatically picks Loopback2 as the pNH. As such PE0 >> advertises (bgpNH,pNH)=3D(1.1.1.1,1.1.1.2) to all iBGP peers= >> including the iPE PE11. > > When you say that PE0 advertises pair of next hops ? How is this > encoded ? What is the semantics of this encoding ? AB: The actual syntax for advertising (bgpNH,pNH) is still work in progress. But, as I mentioned in page 9 item 2 (f), we can use a method similar to RFC5512. The semantics (bgpNH,pNH) is explained in item 4(a) in page 10 and in more details in the last bullet at the bottom of page 1= 0. > >> a. On receiving the repair labels 3100 and 3200 from PE1 and >> PE2, respectively, PE0 detects that there are two rPEs: PE1 >> and PE2. AS such PE0 assigns two vector labels vL1 =3D 1100 >> and vL2 =3D 1200 to PE1 and PE2, respectively > > How can PE0 receive the repair labels from PE1 and PE2 if we take SAFI > 1/1 and no add-paths ? Anyhow we do not even know that the rL is for > SAFI 1/1 yet :) For VPNs you assume different RD per VRF. That still > does not work as I mentioned above. The rPE will be a primary PPE for > some ingress PEs. > AB: This is back to the same comment about a router understanding multipath and associating "rL" with external paths only. As mentioned before, at least this document requires supporting multipath. > Best regards, > R. > >> Hi, >> >> The draft proposes a new method for BGP FRR. >> >> The approach is very scalable as it does not require injecting any >> prefixes into the core, no re-advertisement of BGP prefixes, and no >> state replication. At the same time, it is transparent to the operator= >> in the sense that if it is enabled by default, there is no need for >> human intervention due to any reason including internal and external >> topology changes or even when switching from MPLS to IP core and back >> >> All comments are most welcomed >> >> Thanks >> Ahmed --------------enigEBB26429791D2718491B2673 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQBKO3+G19kFA5zIYRAlwQAJwJ6UdeNnjFJeU4VTQlplvuljNS8ACePoza loHoTsAvB/yA3T7SQz/cCTA= =5bIg -----END PGP SIGNATURE----- --------------enigEBB26429791D2718491B2673-- From bashandy@cisco.com Mon Jul 16 17:14:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406B411E8086; Mon, 16 Jul 2012 17:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.098 X-Spam-Level: X-Spam-Status: No, score=-11.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ+EsZtjMkMm; Mon, 16 Jul 2012 17:14:47 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBFB11E8079; Mon, 16 Jul 2012 17:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=19504; q=dns/txt; s=iport; t=1342484133; x=1343693733; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=OmmVHtYtVhOjk6lisvnDXzk+Az60Diuihv6Rq3pJlkg=; b=fq/GuAgiKI/iEqWjsqQ/9TZzsZpGYZK/gJKy32Rllw0WZ9Ov1c9qQhG5 k+wca+v76acXC0yLqHqsyTLfaslp2gT3HieMh4osCWvxsStdmbF2uPKdH yJbiT7Vu3OhberNvx9JlMnbtOzXDG1774Joy2aF/wtsiSZHDYRO+zstCV M=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,598,1336348800"; d="asc'?scan'208,217";a="49538953" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 17 Jul 2012 00:15:33 +0000 Received: from [171.71.139.5] (dhcp-171-71-139-5.cisco.com [171.71.139.5]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6H0FWB8015257; Tue, 17 Jul 2012 00:15:33 GMT Message-ID: <5004AEA4.7010204@cisco.com> Date: Mon, 16 Jul 2012 17:15:32 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Susan Hares References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <000c01cd639d$2e3f0630$8abd1290$@ndzh.com> In-Reply-To: <000c01cd639d$2e3f0630$8abd1290$@ndzh.com> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE32D90942BF1B02AC93AA80A" Cc: idr@ietf.org, "'Maciek Konstantynowicz \(mkonstan\)'" , rtgwg@ietf.org Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 00:14:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE32D90942BF1B02AC93AA80A Content-Type: multipart/alternative; boundary="------------000907020606070407060406" This is a multi-part message in MIME format. --------------000907020606070407060406 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The edge-node protecting BGP-FRR solution that I am aware of is the one described in draft-minto-2547-egress-node-fast-protection and section 5.1.8.4 in draft-ietf-mpls-seamless-mpls I would be happy to know to learn about other ones Thanks Ahmed On 7/16/2012 2:51 PM, Susan Hares wrote: > > Ahmed: > > =20 > > Can provide a short comparison of this BGP frr with past attempts for > BGP FRR? > > =20 > > If you wish a list of the BGP FRR drafts, please let me know. > > =20 > > sue > > =20 > > *From:*idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] *On Behalf > Of *Ahmed Bashandy > *Sent:* Monday, July 09, 2012 2:30 PM > *To:* idr@ietf.org List; rtgwg@ietf.org > *Cc:* Maciek Konstantynowicz (mkonstan) > *Subject:* [Idr] Fwd: New Version Notification for > draft-bashandy-bgp-frr-vector-label-00.txt > > =20 > > =20 > > Hi, > > The draft proposes a new method for BGP FRR. > > The approach is very scalable as it does not require injecting any > prefixes into the core, no re-advertisement of BGP prefixes, and no > state replication. At the same time, it is transparent to the operator > in the sense that if it is enabled by default, there is no need for > human intervention due to any reason including internal and external > topology changes or even when switching from MPLS to IP core and back > > All comments are most welcomed > > Thanks > > Ahmed > > -------- Original Message -------- > > *Subject: * > > =09 > > New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt= > > *Date: * > > =09 > > Sun, 8 Jul 2012 07:05:43 -0700 > > *From: * > > =09 > > > > *To: * > > =09 > > > > *CC: * > > =09 > > , > > > =20 > > A new version of I-D, draft-bashandy-bgp-frr-vector-label-00.txt > has been successfully submitted by Ahmed Bashandy and posted to the > IETF repository. > =20 > Filename: draft-bashandy-bgp-frr-vector-label > Revision: 00 > Title: BGP FRR Protection against Edge Node Failure Using Vect= or Labels > Creation date: 2012-07-07 > WG ID: Individual Submission > Number of pages: 32 > URL: http://www.ietf.org/internet-drafts/draft-bashandy-bgp= -frr-vector-label-00.txt > Status: http://datatracker.ietf.org/doc/draft-bashandy-bgp-frr= -vector-label > Htmlized: http://tools.ietf.org/html/draft-bashandy-bgp-frr-vect= or-label-00 > =20 > =20 > Abstract: > Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, > PE2,..., PEn know about a prefix P/m via the external routers CE1, > CE2,..., CEm. If the edge router PEi crashes or becomes totally > disconnected from the core, it is desirable for a core router "P" > carrying traffic to the failed edge router PEi to immediately restore > traffic by re-tunneling packets originally tunneled to PEi and > destined to the prefix P/m to one of the other edge routers that > advertised P/m, say PEj, until BGP re-converges. In doing so, it is > highly desirable to keep the core BGP-free while not imposing > restrictions on external connectivity or complicating provisioning > effort. Thus (1) a core router should not be required to learn any > BGP prefix, (2) the size of the forwarding and routing tables in the > core routers should be independent of the number of BGP prefixes, (3) > re-routing traffic without waiting for re-convergence must not cause > loops, (4) provisioning effort should be kept at minimum, and (5) > there should be no restrictions on what edge routers advertise what > prefixes. For labeled prefixes, (6) the label stack on the packet > must allow the repair PEj to correctly forward the packet and (7) > there must not be any need to perform more than one label lookup on > any edge or core router during steady state > =20 > = =20 > =20 > =20 > The IETF Secretariat > > =20 > > =20 > --------------000907020606070407060406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The edge-node protecting BGP-FRR solution that I am aware of is the one described in draft-minto-2547-egress-node-fast-protection and section 5.1.8.4 in draft-ietf-mpls-seamless-mpls

I would be happy to know to learn about other ones

Thanks

Ahmed

On 7/16/2012 2:51 PM, Susan Hares wrote:

Ahmed:

=C2=A0

Can provide a short comparison of this BGP frr with past attempts for BGP FRR?

=C2=A0

If you wish a list of the BGP FRR drafts, please let me know.

=C2=A0

sue

=C2=A0

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Ahmed Bashandy
Sent: Monday, July 09, 2012 2:30 PM
To: idr@ietf.org List; rtgwg@ietf.org
Cc: Maciek Konstantynowicz (mkonstan)
Subject: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt

=C2=A0

=C2=A0

Hi,

The draft proposes a new method for BGP FRR.

The approach is very scalable as it does not require injecting any prefixes into the core, no re-advertisement of BGP prefixes, and no state replication. At the same time, it is transparent to the operator in the sense that if it is enabled by default, there is no need for human intervention due to any reason including internal and external topology changes or even when switching from MPLS to IP core and back<= br>
All comments are most welcomed

Thanks

Ahmed

-------- Original Message --------

Subject:

New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt=

Date:

Sun, 8 Jul 2012 07:05:43 -0700

From:

<intern= et-drafts@ietf.org>

To:

<bashandy@cis= co.com>

CC:

<naikumar@cis= co.com>, <mkonstan@cis= co.com>

=C2=A0= 

A new version of I-D, draft-bashandy-bgp-frr-vector-label-=
00.txt
has been successfully submitted by Ahmed Bashandy and post=
ed to the
IETF repository.
=C2=A0
Filename:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0  draft-bashandy-bg=
p-frr-vector-label
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0  00
          
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0  BG=
P FRR Protection against Edge Node Failure Using Vector Labels=


          
Creation date:  2012-07-07

          
WG ID:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0  In=
dividual Submission

          
Number of pages: 32

          
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 http://www.=
ietf.org/internet-drafts/draft-bashandy-bgp-frr-vector-label-00.txt

          
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 http://datatracker.ietf.org/doc/draft=
-bashandy-bgp-frr-vector-label

          
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-bashandy-bgp-frr=
-vector-label-00

          
=C2=A0

          
=C2=A0

          
Abstract:

          
Consider a BGP free core scenario. Suppose the edge BGP sp=
eakers PE1,

          
PE2,..., PEn know about a prefix P/m via the external rout=
ers CE1,

          
CE2,..., CEm.=C2=A0 If the edge router PEi crashes or beco=
mes totally

          
disconnected from the core, it is desirable for a core rou=
ter "P"

          
carrying traffic to the failed edge router PEi to immediat=
ely restore

          
traffic by re-tunneling packets originally tunneled to PEi=
 and

          
destined to the prefix P/m to one of the other edge router=
s that

          
advertised P/m, say PEj, until BGP re-converges. In doing =
so, it is

          
highly desirable to keep the core BGP-free while not impos=
ing

          
restrictions on external connectivity or complicating prov=
isioning

          
effort. Thus (1) a core router should not be required to l=
earn any

          
BGP prefix, (2) the size of the forwarding and routing tab=
les in the

          
core routers should be independent of the number of BGP pr=
efixes, (3)

          
re-routing traffic without waiting for re-convergence must=
 not cause

          
loops, (4) provisioning effort should be kept at minimum, =
and (5)

          
there should be no restrictions on what edge routers adver=
tise what

          
prefixes. For labeled prefixes, (6) the label stack on the=
 packet

          
must allow the repair PEj to correctly forward the packet =
and (7)

          
there must not be any need to perform more than one label =
lookup on

          
any edge or core router during steady state
          
=C2=A0

          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

          
=C2=A0

          
=C2=A0

          
The IETF Secretariat

          
=C2=A0=

=C2=A0



--------------000907020606070407060406-- --------------enigE32D90942BF1B02AC93AA80A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQBK6k+G19kFA5zIYRAn/+AJ4pK1lwwEhC+5DDeOUyUlSiJ/DL9gCfS3hf M/CwkCyz0V0UCfex+KOJJsw= =aZnu -----END PGP SIGNATURE----- --------------enigE32D90942BF1B02AC93AA80A-- From robert@raszuk.net Mon Jul 16 18:48:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E67621F858F for ; Mon, 16 Jul 2012 18:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR1NeR45A5uN for ; Mon, 16 Jul 2012 18:48:36 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id D925F21F8570 for ; Mon, 16 Jul 2012 18:48:35 -0700 (PDT) Received: (qmail 13651 invoked by uid 399); 17 Jul 2012 01:49:21 -0000 Received: from unknown (HELO ?216.69.69.189?) (pbs:robert@raszuk.net@216.69.69.189) by mail1310.opentransfer.com with ESMTPM; 17 Jul 2012 01:49:21 -0000 X-Originating-IP: 216.69.69.189 Message-ID: <5004C4A0.8030306@raszuk.net> Date: Tue, 17 Jul 2012 03:49:20 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ahmed Bashandy References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> In-Reply-To: <5004A3B2.4040606@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:48:37 -0000 Hi Ahmed, > Thanks a lot for the comments. See Inline. Look for "AB:" You are welcome ;) >>> ii. If "rL" is per-VRF, then pop *two* labels and forward the >>> packet based on the contents under the two popped labels >> >> I am afraid this does not work. >> >> VRF lookup on any rPE would still contain the the original best path >> towards the PE which failed. This is for any AFI/SAFI. Remember the >> BGP best path has not executed yet to eliminate the BGP best path >> which can be influenced by local preference or MED. >> >> Your case mistakenly assumed that locally received EBGP route always >> win, however this is not the case in BGP. > > AB: I thought it is understandable because the draft talks about a > pre-calculated repair path. But it looks like I should say something > like: The behavior explained in this document requires the support for > multipath, such as best external or add-path. Nope. Neither best external or add-paths are required for example for SAFI 1/128. I am not talking about path distribution at all in this point. > I'll also add a statement as follows: rPE advertises "rL" with a labeled > prefix P/m only if it has an external path for the prefix and rPE is > administratively permitted to protect the prefix.For unlabeled > prefixes, rL is only needed if one of the best paths chosen by rPE is > not an external path. The label "rL" is associated with the external > path(s) only. That clarification is optional. Above I am commenting on your point that per vrf IP lookup triggered by per-VRF label will not work in your solution. VRF will still point to the original best path exit. It is my understanding that you do not keep original VRF and protected VRF - do you ? If you do then this needs to be clearly stated in the document. The content of the "protection VRF" indeed could different from the original VRF, but I am not sure if you are planning this. As I said ... if the rL points outside this works .. if the rL points to original VRF for IP lookup it does not. Please clarify. >> You re referring to per VRF lookup option in many places of the draft >> - that needs to be deleted. Only per-CE label where "last hop" rPE >> does not perform IP lookup may work. > > AB: If I add the statement mentioning that rL is only associated with > external path, then it becomes an implementation detail to say that a > router only considers external paths for packets arriving with rL even > if the router makes an IP lookup to determine the next-hop. But I agree > with you that per-CE rL is better and simpler to implement. I will not > be so hung up on the per-VRF option if people think that per-CE is > sufficient Again IMHO you have just two options .. - keep nice scaling property and _only_ bind the rL to external next hops (CEs) - compromise scaling by adding new "shadow VRFs - different from primary VRFs and allow rL to point to such shadow VRF for local IP lookup. >>> a. Acting as a rPE, PE1 allocates (on per-CE basis) and >>> advertises a repair label rL1=3100 with the prefixes >>> 10.0.0.0/8 and 11.0.0.0/8 to all iBGP peers >> >> Another issue in your proposal is that you assume that rPE will be a >> protecting PE for everyone. >> > AB: As I mentioned above, I will add a statement mentioning that > multi-path support is required and that rPE advertises rL for prefixes > to which rPE has an external path and is administratively allowed to do so. You are missing my point. In the draft you say that it is on purpose that rL is different label then normal switching label (for example VPN label). I am saying that if any box is advertising a prefix - it can advertise given BGP path only once. No best external .. no add-paths help. And multipath is irrelevant here completely as this term is used to indicate what routers installs in the forwarding. Adding two labels for the same bgp path does not make it two paths. And as pointed out this is common in the networks for an exit PE to in the same time be primary for some ingress PEs and backup for the others. >> Again in BGP this is not the case as during best path iPEs will >> consider BGP next hop metric. Therefor for the identical destination >> the same PE can be rPE for some iPEs while in the same time it can be >> pPE for other iPEs. >> >> I do not see how in any BGP today you could signal both types of >> labels (even if the label is per CE). > > AB: I do not understand "both types" refers to which types. But anyway, > for a router support any type of fast convergence, such as BGP-PIC or > PE-CE link protection, it has to support the notion of more than one path. BGP PIC or PE-CE requires the reception of more then one path. That is clear. Your proposal mandates advertisement of two types of exit switching labels (for 1/128 primary VPN label and backup rL label). In fact you propose to encode rL "as path attributes in MP/BGP updates" > And to answer your question "If we stop when do we start again ?" The > condition to start advertising pNH after stopping is the same condition > to start advertising pNH for the first time. So PHP will start to > advertise pNH again when gets the message (pNH) from the pPE again. You mean that when " c. pPE advertises pNH as a prefix into IGP" right ? Then IGP may not be impacted and may not re-advertise ... only BGP crashed. Then you will never start advertising the pNH. > AB: This is a question about an implementation detail. But to keep the > answer short, it is VERY EASY for an LSR to pop 3 labels. Routers have > been doing a lot more than this at line rate for a long period of time Perhaps it is easy. However I recall folks who invented MPLS telling me that you never should pop more then one level of labels. Do you know if currently deployed routers can do it in practice ? Anyhow to realize your scheme even if we solve major issues a network wide upgrade of participating routers is mandatory. > First question: What is "rL" if I am not running MPLS? > rL is a label that informs rPE to always send the packet to an external > path. rL has no semantics in the core at all. So the protocol running in > the core is totally irrelevant to "rL" I am not talking about the core. I am also talking about the edge ... So edge must use label switching correct ? Hint: You could have a IP tunnel endpoint terminating at the CE/NH. > Second question: What is "vL" in a pure IP core? > Section 3.1 talks about the case where all core routers, including the > repairing router "rP", do not understand MPLS. In that case, vL is not > use at all. If it is mentioned, then it is probably a mistake ok. > Section 3.2 talks about the case where the repairing core router "rP" > understands MPLS but the rest of the core routers does not. In that > case, "vL" is used the similar to how it is used in MPLS core > Third question: What protocol distributes those labels ? > Only "vL" needs to be distributed to the core. An optional TLV in ISIS > or OSPF can be used to distribute "vL". Ahh nice .. so we are back to carrying labels in IGP .. Finally ! That has been proposed so many times :) Also maybe we will get the concept of global label rolled out in more generic way as vL is effectively and semantically a global label (per given IGP domain). Thx, R. From fenner@fenron.com Tue Jul 17 11:43:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161FE21F84B9 for ; Tue, 17 Jul 2012 11:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFCwhMQjp7oN for ; Tue, 17 Jul 2012 11:43:29 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC8721F84BF for ; Tue, 17 Jul 2012 11:43:29 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1106905obb.31 for ; Tue, 17 Jul 2012 11:44:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=JpH1r1UIiCO8AWRv/MbnUlo5c0gUfk0drzY6/wqTeMI=; b=fTQnIyRFXyhVJHPfdY3SvQaCDr8gsRpIJSgfEJ2USTsjobRW9vR/yHhKj2DQ6J9WIh R287UChanGcZbPXmmvjEgLud48jRQB2bKxoHizM7XF1jh5I7uTpQ8rcBrt75m5eTLXw7 sF6BnPQUrkalWeBeIOMwWddav1r0hVBO6l+nEUfeaBQHsGaW61jiT+F8qM+5sXj1oUYx 9oje837xGNZmEf4RA+9rrJJw+V/TK9MgYxFscQ6zwS3D/hoNoZ7nYxz/rfCRdBZ63FfP p7mWyp52ZtSEsmPn3Op2MMj9drkOxGBcmqoq5t4aXS8HI8kOEqkQChlbbhk5xdt0tuAL tgNQ== MIME-Version: 1.0 Received: by 10.182.212.98 with SMTP id nj2mr4932994obc.18.1342550655309; Tue, 17 Jul 2012 11:44:15 -0700 (PDT) Sender: fenner@fenron.com Received: by 10.182.33.228 with HTTP; Tue, 17 Jul 2012 11:44:15 -0700 (PDT) In-Reply-To: <4F68A20F.5000506@bwijnen.net> References: <0E2C44659B4E4C22A58EDF7E0A834092@BertLaptop> <4F5FB239.7090009@bwijnen.net> <4F68A20F.5000506@bwijnen.net> Date: Tue, 17 Jul 2012 14:44:15 -0400 X-Google-Sender-Auth: sw_XMSB2zAX-cYLzYGNThkrTAe0 Message-ID: From: Bill Fenner To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=e89a8f642904e7188e04c50aeebc X-Gm-Message-State: ALoCoQnqBHp4EEQNc1yEZgVrtsVd7d0+mBSJirEezu3GcD9iY7BH3w9sJyRZUPo2r/tEi0Z7oAnv Cc: Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] [sidr] BGP4 MIB module X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 18:43:31 -0000 --e89a8f642904e7188e04c50aeebc Content-Type: text/plain; charset=ISO-8859-1 [sidr list removed, since this is just about BGP4V2-MIB] On Tue, Mar 20, 2012 at 11:28 AM, Bert Wijnen (IETF) wrote: > So I had been in discussion with Jeff in order to see > if we could get the BGP4-mibv2 module in good shape. > > Below is out discussion. > > Those who are interested in this MIB module at all > may want to take a look to make sure they agree with > the changes being proposed. > > The most modules we're discussion are: > > - drafts/draft-ietf-idr-bgp4-**mibv2-13.txt > - drafts/draft-ietf-idr-bgp4-**mibv2-tc-mib-03.txt > > In fact I had below discussion on bgp4-mibv2-12.txt, > which resulted in revision 13. > > On 3/13/12 9:46 PM, Bert Wijnen (IETF) wrote: > >> On 3/11/12 7:36 PM, Jeffrey Haas wrote: >> >>> Bert, >>> >>> On Jan 17, 2012, at 9:28 AM, Bert Wijnen (IETF) wrote: >>> >>> First, should we have this discussion on the SIDR list? >>>> Maybe we can get folk motivated to move this forward >>>> that way? >>>> >>> >>> I'm massively behind on SIDR, but will be looking at it today. >>> >>> I had to get a new SMICng key first. >>>> >>> >>> Thanks for doing that. >>> >>> >>>> With the new MIB modules I get: >>>> >>>> C:\bw\smicng\work>smicng bgp4v2.inc >>>> E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has invalid >>>> value for >>>> MAX-ACCESS >>>> E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid value >>>> for >>>> MAX-ACCESS >>>> W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a >>>> consistent >>>> indexing schem >>>> e - index items from current table must come after index items from >>>> other tables >>>> W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not have a >>>> consistent indexing >>>> scheme - cannot specify an index item from additional "base row" >>>> bgp4V2NlriEntry, since ca >>>> n have only one "base row" which is bgp4V2PeerEntry >>>> E: f(bgp4v2.mi2), (1627,16) OBJECT-TYPE "bgp4V2PeerLocalAddr" is not in >>>> a >>>> MANDATORY or cond >>>> itional group for module "BGP4V2-MIB" >>>> E: f(bgp4v2.mi2), (1635,16) OBJECT-TYPE "bgp4V2PeerRemoteAddr" is not >>>> in a >>>> MANDATORY or con >>>> ditional group for module "BGP4V2-MIB" >>>> E: f(bgp4v2.mi2), (1643,16) OBJECT-TYPE "bgp4V2NlriPrefix" is not in a >>>> MANDATORY >>>> or conditi >>>> onal group for module "BGP4V2-MIB" >>>> >>>> *** 5 errors and 2 warnings in parsing >>>> >>>> C:\bw\smicng\work> >>>> >>>> W.r.t. >>>> E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has invalid >>>> value for >>>> MAX-ACCESS >>>> E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid value >>>> for >>>> MAX-ACCESS >>>> >>>> You have >>>> INDEX { >>>> bgp4V2PeerInstance, >>>> bgp4V2PeerRemoteAddrType, >>>> bgp4V2PeerRemoteAddr >>>> } >>>> >>>> So why are the LOCAL addrtype and addr not-accessible? >>>> Or should they be part of the index? >>>> >>> >>> At one point the local address items were part of the index for the >>> table. After some discussion with implementors, they preferred >>> that it be left as it is in the existing BGP-4 MIB case. While this is >>> unfortunate, it makes sense. >>> >>> In BGP, it is typically the case that you'll have a single peering >>> session to a given destination peer address. However, there are >>> some corner case peering scenarios where two local addresses on a given >>> router may peer with the same destination address from the >>> same instance. This is a *very* uncommon case and it lead to some minor >>> tweaks in the BGP language when RFC 4271 was published. >>> >>> The problem with putting the local address into the key is that it >>> removes the determinism from the index. If the local address is >>> not configured, as may be the case for ebgp peering, you may not know >>> what it would be. In the case of some ibgp, it's also >>> possible the local address may change based on what TCP decided it >>> needed. Instead of catering to these uncertain cases, it was >>> cleaner to remove the local address from the index. >>> >>> I have changed these back to read-only. >>> >>> >> good. >> >> >>>> W.r.t. >>>> W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a >>>> consistent >>>> indexing schem >>>> e - index items from current table must come after index items from >>>> other tables >>>> >>>> You have: >>>> >>>> INDEX { >>>> bgp4V2PeerInstance, >>>> bgp4V2NlriAfi, >>>> bgp4V2NlriSafi, >>>> bgp4V2NlriPrefixType, >>>> bgp4V2NlriPrefix, >>>> bgp4V2NlriPrefixLen, >>>> bgp4V2PeerRemoteAddrType, >>>> bgp4V2PeerRemoteAddr, >>>> bgp4V2NlriIndex >>>> } >>>> ::= { bgp4V2NlriTable 1 } >>>> >>>> So pls explain to me that indexing so I can form an opinion if that is >>>> OK or >>>> not. Besides the warning from SMICng, I also wonder why >>>> NlriIndex is the last index column, while it is the first column in the >>>> table. >>>> >>> >>> The above up to nlri-index is a natural order walk for BGP. It's also >>> largely what is used in the existing 4273 MIB: >>> >>> bgp4PathAttrEntry OBJECT-TYPE >>> SYNTAX Bgp4PathAttrEntry >>> MAX-ACCESS not-accessible >>> STATUS current >>> DESCRIPTION >>> "Information about a path to a network." >>> INDEX { bgp4PathAttrIpAddrPrefix, >>> bgp4PathAttrIpAddrPrefixLen, >>> bgp4PathAttrPeer } >>> ::= { bgp4PathAttrTable 1 } >>> >>> Thus, walk all of a given instance. There's no guarantee that 10/8 in >>> one instance is the same as another, especially since the >>> instance may map to a VPN VRF. >>> Walk a given prefix and peer, as it is in the older table. The prefixes >>> are walked on a per afi/safi basis since the families are >>> also incomparable. You then want to see the prefix from all peers. >>> >>> The nlriindex covers two cases: Multiple routes in RFC 3107 (which I >>> don't believe anyone implements) and BGP add-path. You want >>> to see all routes from a given peer and the nlri index lets you see more >>> than one >>> >>> Hopefully the ordering makes sense in the index. >>> >>> I now see what you mean about the fact that the object for nlriindex >>> precedes things like the afi and safi. It's mostly just been >>> this way for a while. If you feel strongly that it should be re-ordered, >>> we could probably do that since we haven't hit RFC, but >>> it will have impact on anyone that may have an in-flight implementation >>> of this. Thus far our fixes have had only minor impact. >>> >>> > The above is still a warning I get in the revision 13. > Would be good to have some comments from (other) implementers > or those who plan to implement > The contents of the index make sense: BGP Instance (although I would have done this with SNMP contexts, but that ship has sailed) AFI/SAFI Prefix Peer Instance of this prefix from this peer The reason that smicng is getting heartburn is that the MIB uses the instance and peer values from the peer table, even though we're not augmenting/expanding that table. This is presumably done based upon RFC2578's statement, "Note that objects specified in a conceptual row's INDEX clause need not be columnar objects of that conceptual row". I can't find a clear prohibition of reusing INDEX objects from other tables even though you're not following the structure of that table. In fact, RFC2578 section 7.8.1 seems to encourage this reuse: 7.8.1. Relation between INDEX and AUGMENTS clauses (3) Otherwise, **if no existing objects have the required syntax and semantics**, then auxiliary objects should be defined within the conceptual row for the new table, and those objects should be used within the INDEX clause for the conceptual row. Since there *are* existing objects with the desired syntax and semantics, it feels like this clause is telling us to use them, even though this particular use doesn't really match what I understand the original intent to be (which is to have the INDEX of table A be a prefix of the INDEX of related table B). >>> >>>> W.r.t. >>>> W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not have a >>>> consistent indexing >>>> scheme - cannot specify an index item from additional "base row" >>>> bgp4V2NlriEntry, since ca >>>> n have only one "base row" which is bgp4V2PeerEntry >>>> >>>> You have: >>>> INDEX { >>>> bgp4V2PeerInstance, >>>> bgp4V2NlriAfi, >>>> bgp4V2NlriSafi, >>>> bgp4V2NlriPrefixType, >>>> bgp4V2NlriPrefix, >>>> bgp4V2NlriPrefixLen, >>>> bgp4V2PeerRemoteAddrType, >>>> bgp4V2PeerRemoteAddr, >>>> bgp4V2AdjRibsOutIndex >>>> } >>>> ::= { bgp4V2AdjRibsOutTable 1 } >>>> >>>> Pls explain indexing scheme, so I can form an opinion. >>>> >>> >>> The scheme is identical to the prior explanation. The primary difference >>> is since this is sending routes rather than receiving >>> them, we may advertise different routes on egress, hence an OutIndex >>> instead of the prior NlriIndex. >>> >>> Same question here > Same answer, really. The index is: BGP Instance AFI/SAFI Prefix Peer Instance of prefix being sent to this peer smicng is being upset because items 1 and 4 are coming from the peer table and items 2 and 3 are coming from the nlri table, and it is envisioning this world where table A's INDEX is supposed to be a prefix of table B's. If we wanted to pacify smicng, the types of the objects in the INDEX would stay the same - they would just be redefined (e.g., redefine the instance and peer in the NLRI table). Is smicng just expressing a view of how this kind of object reuse is normally done, or is it a rule? Bill --e89a8f642904e7188e04c50aeebc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[sidr list removed, since this is just about BGP= 4V2-MIB]

On Tue, Mar 20, 2012 at 11:28 AM, Bert Wijnen (IETF) &= lt;bertietf@bwijn= en.net> wrote:
So I had been in discussion with Jeff in ord= er to see
if we could get the BGP4-mibv2 module in good shape.

Below is out discussion.

Those who are interested in this MIB module at all
may want to take a look to make sure they agree with
the changes being proposed.

The most modules we're discussion are:

- drafts/draft-ietf-idr-bgp4-mibv2-13.txt
- drafts/draft-ietf-idr-bgp4-mibv2-tc-mib-03.txt

In fact I had below discussion on bgp4-mibv2-12.txt,
which resulted in revision 13.

On 3/13/12 9:46 PM, Bert Wijnen (IETF) wrote:
On 3/11/12 7:36 PM, Jeffrey Haas wrote:
Bert,

On Jan 17, 2012, at 9:28 AM, Bert Wijnen (IETF) wrote:

First, should we have this discussion on the SIDR list?
Maybe we can get folk motivated to move this forward
that way?

I'm massively behind on SIDR, but will be looking at it today.

I had to get a new SMICng key first.

Thanks for doing that.


With the new MIB modules I get:

C:\bw\smicng\work>smicng bgp4v2.inc
E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has inva= lid value for
MAX-ACCESS
E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid = value for
MAX-ACCESS
W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a= consistent
indexing schem
e - index items from current table must come after index items from other t= ables
W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not = have a
consistent indexing
scheme - cannot specify an index item from additional "base row"<= br> bgp4V2NlriEntry, since ca
n have only one "base row" which is bgp4V2PeerEntry
E: f(bgp4v2.mi2), (1627,16) OBJECT-TYPE "bgp4V2PeerLocalAddr" is = not in a
MANDATORY or cond
itional group for module "BGP4V2-MIB"
E: f(bgp4v2.mi2), (1635,16) OBJECT-TYPE "bgp4V2PeerRemoteAddr" is= not in a
MANDATORY or con
ditional group for module "BGP4V2-MIB"
E: f(bgp4v2.mi2), (1643,16) OBJECT-TYPE "bgp4V2NlriPrefix" is not= in a MANDATORY
or conditi
onal group for module "BGP4V2-MIB"

*** 5 errors and 2 warnings in parsing

C:\bw\smicng\work>

W.r.t.
E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has inva= lid value for
MAX-ACCESS
E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid = value for
MAX-ACCESS

You have
INDEX {
bgp4V2PeerInstance,
bgp4V2PeerRemoteAddrType,
bgp4V2PeerRemoteAddr
}

So why are the LOCAL addrtype and addr not-accessible?
Or should they be part of the index?

At one point the local address items were part of the index for the table. = After some discussion with implementors, they preferred
that it be left as it is in the existing BGP-4 MIB case. While this is unfo= rtunate, it makes sense.

In BGP, it is typically the case that you'll have a single peering sess= ion to a given destination peer address. However, there are
some corner case peering scenarios where two local addresses on a given rou= ter may peer with the same destination address from the
same instance. This is a *very* uncommon case and it lead to some minor twe= aks in the BGP language when RFC 4271 was published.

The problem with putting the local address into the key is that it removes = the determinism from the index. If the local address is
not configured, as may be the case for ebgp peering, you may not know what = it would be. In the case of some ibgp, it's also
possible the local address may change based on what TCP decided it needed. = Instead of catering to these uncertain cases, it was
cleaner to remove the local address from the index.

I have changed these back to read-only.


good.


W.r.t.
W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a= consistent
indexing schem
e - index items from current table must come after index items from other t= ables

You have:

INDEX {
bgp4V2PeerInstance,
bgp4V2NlriAfi,
bgp4V2NlriSafi,
bgp4V2NlriPrefixType,
bgp4V2NlriPrefix,
bgp4V2NlriPrefixLen,
bgp4V2PeerRemoteAddrType,
bgp4V2PeerRemoteAddr,
bgp4V2NlriIndex
}
::=3D { bgp4V2NlriTable 1 }

So pls explain to me that indexing so I can form an opinion if that is OK o= r
not. Besides the warning from SMICng, I also wonder why
NlriIndex is the last index column, while it is the first column in the
table.

The above up to nlri-index is a natural order walk for BGP. It's also l= argely what is used in the existing 4273 MIB:

bgp4PathAttrEntry OBJECT-TYPE
SYNTAX Bgp4PathAttrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a path to a network."
INDEX { bgp4PathAttrIpAddrPrefix,
bgp4PathAttrIpAddrPrefixLen,
bgp4PathAttrPeer }
::=3D { bgp4PathAttrTable 1 }

Thus, walk all of a given instance. There's no guarantee that 10/8 in o= ne instance is the same as another, especially since the
instance may map to a VPN VRF.
Walk a given prefix and peer, as it is in the older table. The prefixes are= walked on a per afi/safi basis since the families are
also incomparable. You then want to see the prefix from all peers.

The nlriindex covers two cases: Multiple routes in RFC 3107 (which I don= 9;t believe anyone implements) and BGP add-path. You want
to see all routes from a given peer and the nlri index lets you see more th= an one

Hopefully the ordering makes sense in the index.

I now see what you mean about the fact that the object for nlriindex preced= es things like the afi and safi. It's mostly just been
this way for a while. If you feel strongly that it should be re-ordered, we= could probably do that since we haven't hit RFC, but
it will have impact on anyone that may have an in-flight implementation of = this. Thus far our fixes have had only minor impact.


The above is still a warning I get in the revision 13.
Would be good to have some comments from (other) implementers
or those who plan to implement

The cont= ents of the index make sense:

BGP Instance (althou= gh I would have done this with SNMP contexts, but that ship has sailed)
AFI/SAFI
Prefix
Peer
Instance of this pr= efix from this peer

The reason that smicng is gett= ing heartburn is that the MIB uses the instance and peer values from the pe= er table, even though we're not augmenting/expanding that table. =A0Thi= s is presumably done based upon RFC2578's statement, "Note that ob= jects specified in a conceptual row's INDEX clause need=A0not be column= ar objects of that conceptual row".

I can't find a clear prohibition of reusing INDEX o= bjects from other tables even though you're not following the structure= of that table. =A0In fact, RFC2578 section 7.8.1 seems to encourage this r= euse:

7.8.1. =A0Relation between INDEX and AUGMENTS clau= ses

(3) =A0Otherwise, **if no existing = objects have the required syntax and
=A0 =A0 =A0semantics**, then= auxiliary objects should be defined within the
=A0 =A0 =A0conceptual row for the new table, and those objects should = be used
=A0 =A0 =A0within the INDEX clause for the conceptual row= .

=A0Since there *are* existing objects with= the desired syntax and semantics, it feels like this clause is telling us = to use them, even though this particular use doesn't really match what = I understand the original intent to be (which is to have the INDEX of table= A be a prefix of the INDEX of related table B).



W.r.t.
W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not = have a
consistent indexing
scheme - cannot specify an index item from additional "base row"<= br> bgp4V2NlriEntry, since ca
n have only one "base row" which is bgp4V2PeerEntry

You have:
INDEX {
bgp4V2PeerInstance,
bgp4V2NlriAfi,
bgp4V2NlriSafi,
bgp4V2NlriPrefixType,
bgp4V2NlriPrefix,
bgp4V2NlriPrefixLen,
bgp4V2PeerRemoteAddrType,
bgp4V2PeerRemoteAddr,
bgp4V2AdjRibsOutIndex
}
::=3D { bgp4V2AdjRibsOutTable 1 }

Pls explain indexing scheme, so I can form an opinion.

The scheme is identical to the prior explanation. The primary difference is= since this is sending routes rather than receiving
them, we may advertise different routes on egress, hence an OutIndex instea= d of the prior NlriIndex.

Same question here

Same answer, really.= =A0The index is:

BGP Instance
AFI/SAFI<= /div>
Prefix
Peer
Instance of prefix being sent to = this peer

smicng is being upset because items 1 and 4 are coming = from the peer table and items 2 and 3 are coming from the nlri table, and i= t is envisioning this world where table A's INDEX is supposed to be a p= refix of table B's.

If we wanted to pacify smicng, the types of the objects= in the INDEX would stay the same - they would just be redefined (e.g., red= efine the instance and peer in the NLRI table). =A0Is smicng just expressin= g a view of how this kind of object reuse is normally done, or is it a rule= ?

=A0 Bill
--e89a8f642904e7188e04c50aeebc-- From fenner@fenron.com Tue Jul 17 11:58:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B61021F8522 for ; Tue, 17 Jul 2012 11:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TSdfhb8BUgU for ; Tue, 17 Jul 2012 11:58:12 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C80321F84B9 for ; Tue, 17 Jul 2012 11:58:12 -0700 (PDT) Received: by yhq56 with SMTP id 56so851915yhq.31 for ; Tue, 17 Jul 2012 11:59:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=gRmVqwn0Kqig4KzFAkZs/IzF/Qn9ksPTakGSDlsyzcM=; b=BXbazNKNYDlfCiACqcaIzrxtkN5Ab3IjSLAnqXBZwQnIige+WoVVPlIItxwCIn2ezk xYBochcvTlFA78OtdocLqjjLibbmLNbvyYQxe/eTeoCStkLfIBhSeMH+ty6wRydRMpq0 E1Lle70jmP+wRhTcRz1HVlMcfpyCbDdA3/icMaDUrSE4FHRc5/qyxdy72BrtUhPOZcil RWbwRCRC5tVmXfdkJbIN+sOfsdMldj7sUl7kuRYB7Nt/0+1Juwu7lndw+3M2nPQ0X5Fp yy/mcDUvVP2HXkP0ASGO5tRy/iqBsUYfVZrXGChV7w3SiDEXYHoE6vjeODGEzcR4W6Ok knGQ== MIME-Version: 1.0 Received: by 10.60.29.230 with SMTP id n6mr4932830oeh.22.1342551540061; Tue, 17 Jul 2012 11:59:00 -0700 (PDT) Sender: fenner@fenron.com Received: by 10.182.33.228 with HTTP; Tue, 17 Jul 2012 11:59:00 -0700 (PDT) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C66C@tlvmail1> References: <44F4E579A764584EA9BDFD07D0CA0813076E31CA@tlvmail1> <6246F062-090F-4092-B931-B10F3A84AEB0@juniper.net> <44F4E579A764584EA9BDFD07D0CA0813076E323A@tlvmail1> <283B4946-C3D5-42A0-87D6-02C8FD5CA132@juniper.net> <44F4E579A764584EA9BDFD07D0CA08130777BECD@tlvmail1> <44F4E579A764584EA9BDFD07D0CA08130777C66C@tlvmail1> Date: Tue, 17 Jul 2012 14:59:00 -0400 X-Google-Sender-Auth: zb4YiZJkGpwTlgGsruWR7kJqmOE Message-ID: From: Bill Fenner To: Daniel Cohn Content-Type: multipart/alternative; boundary=e89a8ff1c146a355ef04c50b2398 X-Gm-Message-State: ALoCoQk7V0R+c6uZ1Woae1dA10wE/s71CDqmdoaoq75kGJuJRWqDdDz9C0MgwhIgSoAExMDpMNVB Cc: Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] BGP MIBv2 implementation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 18:58:14 -0000 --e89a8ff1c146a355ef04c50b2398 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Apr 25, 2012 at 8:44 AM, Daniel Cohn wrote: > Hi Jeff and all,**** > > ** ** > > Sorry for the delayed response. I think it would be a shame to go through > the hassle of updating the BGP MIB without fully supporting BGP L3VPN/VPL= S > (in both RFC 4761 and 6074 flavors). Therefore I support using a generic > NLRI prefix TC that explicitly supports these NLRIs and can be extended t= o > support future BGP applications. It doesn=92t seem consistent to add AFI/= SAFI > to the MIB while leaving the NLRI as an IP address.**** > > ** ** > > A couple more suggestions for this draft:**** > > ** ** > > **- **Change the bgp4V2AdjRibsOutTable index to make it the same > as in bgp4V2NlriTable. In its current form (a pointer to the > bgp4V2NlriTable), it doesn=92t support BGP routes originated by this spea= ker > (e.g. redistributed from IGP) so it=92s woefully inadequate. > I had a similar thought about the Adj-RIBS-Out table - it can't represent a locally-originated route. I am not sure what you mean by changing the index to address this, however, since the index as it is makes sense to me. Maybe you mean to change the structure of the table to copy all of the data from the NlriTable, which I disagree with. One idea on handling this with the current structure is to use the pointer to point to a row in the IP-FORWARDING-MIB for a locally-originated route. > - **Add support for BGP communities (as in your communities > draft) in the NLRI in/out tables. > There is no reason this can't be a future addition, right, in the interest of getting the base functionality out? > - **Restore local address (and maybe ports) to bgp4V2PeerTable > index to support multiple BGP sessions between two speakers as in > draft-ietf-grow-diverse-bgp-path-dist > If the ports are in the INDEX, how do you ever find a row if one of the ports is guaranteed to be ephemeral and you don't know a priori who originated the connection? If the remote address was first in the INDEX, you could always use getnext to get a given value independent of the local address, but that's not a concept that many management systems are familiar with. An idea that solves both the ports and the unknown-local-address problem is to use the remote address and an instance identifier. Peers with a single connection (the "normal" case) would be only instance 1, but if you had multiple simultaneous connections to the same remote peer you could use more values. Bill ** ** > > Feedback is welcome, regards,**** > > ** ** > > Daniel**** > > ** ** > > *From:* Jeffrey Haas [mailto:jhaas@pfrc.orgnet] > *Sent:* Thu, 15 Mar 2012 14:19:17 > *Subject:* Re: [Idr] IETF 83 - BGP MIBv2 Update - prefix Textual > Conventions**** > > ** ** > > Working Group,**** > > ** ** > > As per prior plenary discussion on making more effect use of working grou= p > **** > > session time, please find my BGP MIBv2 update slides on the proceedings**= * > * > > page:**** > > ** ** > > http://www.ietf.org/proceedings/83/slides/slides-83-idr-0.pdf**** > > ** ** > > The bulk of the presentation is self explanatory. I'd like to thank **** > > Bert Wijnen for additional MIB feedback. I suspect we'll get a bit more= * > *** > > feedback from him since he discovered bugs as part of doing derivative wo= rk > **** > > for the SIDR MIB. Draft -13 [1] reflects his comments as of the IETF 83*= * > ** > > posting cutoff.**** > > ** ** > > One item I would like to draw the working group's further attention to is= * > *** > > covered on slides 5-7. As part of analyzing the requirements for the**** > > multicast next-gen VPN [2] MIBs that Jeffrey Zhang (zzhang at juniper.net= ) > is**** > > working on, we briefly considered exposing MVPN routing state in BGP via > the**** > > BGP MIBv2. Per prior presentations and discussions on design goals for t= he > **** > > BGP MIBv2, we wanted one MIB that was capable of being re-used for variou= s > **** > > types of reachability that was being carried in BGP. However, the primar= y > **** > > goal was to be able to carry IPv6 reachability.**** > > ** ** > > RFC 6514 can be briefly examined to see the different types of reachabili= ty > **** > > that are being passed around in BGP. The reachability is distinguished**= * > * > > within the same AFI/SAFI by a "Route Type" field within the prefix with > type**** > > specific encodings following. **** > > ** ** > > The BGP MIBv2 presents prefixes using the following two objects:**** > > bgp4V2NlriPrefixType OBJECT-TYPE**** > > SYNTAX InetAddressType**** > > MAX-ACCESS not-accessible**** > > STATUS current**** > > DESCRIPTION**** > > "The type of the IP address prefix in the**** > > Network Layer Reachability Information field.**** > > The value of this object is derived from the**** > > appropriate value from the bgp4V2NlriAfi field.**** > > Where an appropriate InetAddressType is not**** > > available, the value of the object must be**** > > unknown(0)."**** > > ::=3D { bgp4V2NlriEntry 4 }**** > > ** ** > > bgp4V2NlriPrefix OBJECT-TYPE**** > > SYNTAX InetAddress**** > > MAX-ACCESS not-accessible**** > > STATUS current**** > > DESCRIPTION**** > > "An IP address prefix in the Network Layer**** > > Reachability Information field. This object**** > > is an IP address containing the prefix with**** > > length specified by bgp4V2NlriPrefixLen.**** > > Any bits beyond the length specified by**** > > bgp4V2NlriPrefixLen are zeroed.**** > > ** ** > > An implementation is required to support IPv4**** > > prefixes. In this case, the object length**** > > is (0..4).**** > > ** ** > > An implementation MAY support IPv6 prefixes.**** > > In this case, the object length is (0..16)"**** > > REFERENCE**** > > "RFC 4271, Section 4.3."**** > > ::=3D { bgp4V2NlriEntry 5 }**** > > ** ** > > The general goal of the "InetAddressType/InetAddress" textual conventions > [3]**** > > is to provide a level of generality for MIB objects that are "addresses".= * > *** > > Our initial design guidance for the BGP MIBv2 was to make use of these TC= s > **** > > to help represent both IPv4 and IPv6 addresses - and it does this well.**= * > * > > ** ** > > As part of investigating encoding MVPN prefixes in the BGP MIBv2, I sent*= * > ** > > mail to the ietfmibs mailing list to discuss this possibility. After a f= ew > **** > > exchanges, it was suggested that since the information is BGP specific th= at > **** > > this was not the best fit for the INET-ADDRESS-MIB and that we should**** > > consider a BGP TC specifically for this purpose.**** > > ** ** > > If we were to consider such a TC, we would make it "IANA maintained". Th= is > **** > > would permit us to issue the initial MIB but permit IANA to maintain the*= * > ** > > code points as new protocol elements are added. I.e. we don't have to ha= ve > **** > > a MIB document stuck as an I-D forever. The current INET-ADDRESS-MIB is*= * > ** > > an example of such a MIB.**** > > ** ** > > After further discussion with Jeffrey Zhang, we determined that there > wasn't**** > > a strong incentive to continue the MVPN MIB work as a BGP MIBv2 extension= , > **** > > We may see future requirements from other BGP-based address families. **= * > * > > ** ** > > My recommendation would be that we proceed with the work to create a BGP*= * > ** > > Prefix TC MIB with an explicit goal of being backward compatible with the= * > *** > > INET-ADDRESS-MIB. However, the WG may also come to the decision to not**= * > * > > pursue making this MIB completely general purpose and just worry about***= * > > IPv4/IPv6.**** > > ** ** > > With regard to standards advancement, the new BGP Prefix MIB shouldn't***= * > > unnecessarily hinder the BGP MIBv2.**** > > ** ** > > I would like the WG to come to some consensus as to whether we (very > likely,**** > > I) take on the work to make such a prefix TC MIB.**** > > ** ** > > If the discussion becomes interesting enough, Sue and John have agreed to= * > *** > > grant us discussion time at the upcoming IDR session in Paris.**** > > ** ** > > -- Jeff**** > > ** ** > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --e89a8ff1c146a355ef04c50b2398 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 25, 2012 at 8:44 AM, Daniel Cohn <= DanielC@orckit.com> wrote:

Hi Jeff and a= ll,

=A0<= /p>

Sorry for the delayed = response. I think it would be a shame to go through the hassle of updating = the BGP MIB without fully supporting BGP L3VPN/VPLS (in both RFC 4761 and 6= 074 flavors). Therefore I support using a generic NLRI prefix TC that expli= citly supports these NLRIs and can be extended to support future BGP applic= ations. It doesn=92t seem consistent to add AFI/SAFI to the MIB while leavi= ng the NLRI as an IP address.

=A0<= /p>

A couple more suggesti= ons for this draft:

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Change the bgp4= V2AdjRibsOutTable index to make it the same as in bgp4V2NlriTable. In its c= urrent form (a pointer to the bgp4V2NlriTable), it doesn=92t support BGP ro= utes originated by this speaker (e.g. redistributed from IGP) so it=92s woe= fully inadequate.

I had a similar thought about the = Adj-RIBS-Out table - it can't represent a locally-originated route. =A0= I am not sure what you mean by changing the index to address this, however,= since the index as it is makes sense to me. =A0Maybe you mean to change th= e structure of the table to copy all of the data from the NlriTable, which = I disagree with.

One idea on handling this with the current structure is= to use the pointer to point to a row in the IP-FORWARDING-MIB for a locall= y-originated route.

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Add support for BGP communities (as in your communi= ties draft) in the NLRI in/out tables.

There is no reason this can't be a future= addition, right, in the interest of getting the base functionality out?

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Restore local address (and maybe ports) to bgp4V2PeerTab= le index to support multiple BGP sessions between two speakers as in draft-= ietf-grow-diverse-bgp-path-dist

If the ports are in the INDEX, how do you ever find= a row if one of the ports is guaranteed to be ephemeral and you don't = know a priori who originated the connection?

If th= e remote address was first in the INDEX, you could always use getnext to ge= t a given value independent of the local address, but that's not a conc= ept that many management systems are familiar with.

An idea that solves both the ports and the unknown-loca= l-address problem is to use the remote address and an instance identifier. = =A0Peers with a single connection (the "normal" case) would be on= ly instance 1, but if you had multiple simultaneous connections to the same= remote peer you could use more values.

=A0 Bill

=A0<= /p>

Feedback is welcome, = regards,

=A0<= /p>

Daniel

=A0<= /p>

From: Jeffrey = Haas [mailto:jhaas@p= frc.orgnet]
Sent: Thu, 15 Mar 2012 14:19:17
Subject: Re: [Idr] IETF 8= 3 - BGP MIBv2 Update - prefix Textual Conventions

<= /div>

=A0

Workin= g Group,

=A0<= /p>

As per= prior plenary discussion on making more effect use of working group=

session time, please find my BGP MIBv2 u= pdate slides on the proceedings

page:

=A0<= u>

http://www.ietf.org/proceedings/83/slides= /slides-83-idr-0.pdf

=A0

The bulk of t= he presentation is self explanatory.=A0 I'd like to thank

Bert Wijnen for additional MIB feedback.=A0=A0 I suspect w= e'll get a bit more

feedback f= rom him since he discovered bugs as part of doing derivative work=

for the SIDR MIB.=A0 Draft -13 [1] reflects his comments a= s of the IETF 83

posting cutoff.

=A0

One item I wo= uld like to draw the working group's further attention to is<= /u>

covered on slides 5-7.=A0 As part of analyzing the require= ments for the

multicast next-gen V= PN [2] MIBs that Jeffrey Zhang (zzhang at juniper.net) is

working on, we briefly considered exposing MVPN routing st= ate in BGP via the

BGP MIBv2.=A0 P= er prior presentations and discussions on design goals for the

BGP MIBv2, we wanted one MIB that was capable of being re-= used for various

types of reachabi= lity that was being carried in BGP.=A0 However, the primary

goal was to be able to carry IPv6 reachability.<= /u>

=A0

RFC 6514 can be briefly examined to see the different type= s of reachability

that are being p= assed around in BGP.=A0 The reachability is distinguished

within the same AFI/SAFI by a "Route Type" field= within the prefix with type

speci= fic encodings following.=A0

=A0

The BGP MIBv2= presents prefixes using the following two objects:

=A0=A0=A0 bgp4V2NlriPrefixType OBJECT-TYPE

=A0=A0=A0=A0=A0=A0=A0 SYNTAX=A0=A0=A0=A0 InetAddr= essType

=A0=A0=A0=A0=A0=A0=A0 MAX-ACCESS not-accessible<= /u>

=A0=A0=A0=A0=A0=A0=A0 STATUS=A0=A0=A0=A0 cur= rent

=A0=A0=A0=A0=A0=A0=A0 DESCRIPTION

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "The type of the IP= address prefix in the

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Network Layer Reachab= ility Information field.

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 The value of this object is derived from the=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 appropriate value fro= m the bgp4V2NlriAfi field.

<= span style=3D"font-size:10.0pt;font-family:"Courier New"">=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Where an appropriate InetAddressType is not<= u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 available, the value = of the object must be

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 unknown(0)."

=A0=A0=A0=A0=A0=A0=A0 ::=3D { bgp4V2NlriEntry 4 }

=A0

=A0=A0=A0 bgp4V2NlriPrefix OBJECT-TYPE

=A0=A0=A0=A0=A0=A0=A0 SYNTAX=A0=A0=A0=A0 InetAddress<= u>

=A0=A0=A0=A0=A0=A0=A0 MAX-ACCESS not-accessible<= /u>

=A0=A0=A0=A0=A0=A0=A0 STATUS=A0=A0=A0=A0 cur= rent

=A0=A0=A0=A0=A0=A0=A0 DESCRIPTION

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "An IP address pref= ix in the Network Layer

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Reachability Informat= ion field. This object

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 is an IP address containing the prefix with<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 length specified by b= gp4V2NlriPrefixLen.

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Any bits beyond the length specified by<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bgp4V2NlriPrefixLen a= re zeroed.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 An implementation is = required to support IPv4

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 prefixes.=A0 In this case, the object length=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is (0..4).<= /u>

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 An implementation MAY= support IPv6 prefixes.

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 In this case, the object length is (0..16)"= ;

=A0=A0=A0=A0=A0=A0=A0 REFERENCE

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "RFC 4271, Section 4.= 3."

=A0=A0=A0=A0 =A0=A0=A0::=3D { bgp4V2NlriEntry 5 }

=A0

The general goal of the "InetAddressType/InetAddress&= quot; textual conventions [3]

is to = provide a level of generality for MIB objects that are "addresses"= ;.

Our initial design guidance for= the BGP MIBv2 was to make use of these TCs

to help represent both IPv4 and IPv6 addresses - and it do= es this well.

=A0

As part of investigating encoding MVPN prefixes in the BGP= MIBv2, I sent

mail to the ietfm= ibs mailing list to discuss this possibility.=A0 After a few<= /span>

exchanges, it was suggested that since the information is = BGP specific that

this was not the= best fit for the INET-ADDRESS-MIB and that we should<= /p>

consider a BGP TC specifically for this purpose.=

=A0

If we were to consider such a TC, we would make it "I= ANA maintained".=A0 This

woul= d permit us to issue the initial MIB but permit IANA to maintain the=

code points as new protocol elements are added.=A0 I.e. we= don't have to have

a MIB docu= ment stuck as an I-D forever.=A0 The current INET-ADDRESS-MIB is<= /u>

an example of such a MIB.

=A0

After further discussion with Jeffrey Zhang, we determined= that there wasn't

a strong in= centive to continue the MVPN MIB work as a BGP MIBv2 extension,

We may see future requirements from other BGP-based addres= s families.=A0

=A0=

My recommendation would be that we proceed with the work t= o create a BGP

Prefix TC MIB wit= h an explicit goal of being backward compatible with the

INET-ADDRESS-MIB.=A0 However, the WG may also come to the = decision to not

pursue making thi= s MIB completely general purpose and just worry about<= /p>

IPv4/IPv6.

= =A0

With regard to standards advancement, the new BGP Prefix M= IB shouldn't

unnecessarily hin= der the BGP MIBv2.

=A0

I would like = the WG to come to some consensus as to whether we (very likely,

I) take on the work to make such a prefix TC MIB.

=A0

If the discussion becomes interesting enough, Sue and John= have agreed to

grant us discussi= on time at the upcoming IDR session in Paris.

=A0

-- Jeff

=A0


_____________________= __________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


--e89a8ff1c146a355ef04c50b2398-- From jhaas@slice.pfrc.org Tue Jul 17 13:00:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B9B21F865E for ; Tue, 17 Jul 2012 13:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.131 X-Spam-Level: X-Spam-Status: No, score=-102.131 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2GiDK+lGwp1 for ; Tue, 17 Jul 2012 13:00:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 04D5E21F8621 for ; Tue, 17 Jul 2012 13:00:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A0486C6B2; Tue, 17 Jul 2012 16:01:29 -0400 (EDT) Date: Tue, 17 Jul 2012 16:01:29 -0400 From: Jeffrey Haas To: Bill Fenner Message-ID: <20120717200129.GA11505@pfrc> References: <44F4E579A764584EA9BDFD07D0CA0813076E31CA@tlvmail1> <6246F062-090F-4092-B931-B10F3A84AEB0@juniper.net> <44F4E579A764584EA9BDFD07D0CA0813076E323A@tlvmail1> <283B4946-C3D5-42A0-87D6-02C8FD5CA132@juniper.net> <44F4E579A764584EA9BDFD07D0CA08130777BECD@tlvmail1> <44F4E579A764584EA9BDFD07D0CA08130777C66C@tlvmail1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] BGP MIBv2 implementation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:00:42 -0000 Bill, On Tue, Jul 17, 2012 at 02:59:00PM -0400, Bill Fenner wrote: > > - **Add support for BGP communities (as in your communities > > draft) in the NLRI in/out tables. > > > There is no reason this can't be a future addition, right, in the interest > of getting the base functionality out? There's also a matter of how you cleanly represent this. I've had prior drafts suggesting a structure for such a thing, but not a huge amount of traction in it. I'm happy to have the bgp mibv2 hit RFC at this point before I invest the effort. :-) > > > - **Restore local address (and maybe ports) to bgp4V2PeerTable > > index to support multiple BGP sessions between two speakers as in > > draft-ietf-grow-diverse-bgp-path-dist > > > If the ports are in the INDEX, how do you ever find a row if one of the > ports is guaranteed to be ephemeral and you don't know a priori who > originated the connection? That was the original problem. The local address and port was originally part of the index with some attempt to reflect this case. It made for quite the mess and was only really used to cover a small number of really exceptional edge cases in BGP peer configuration. > An idea that solves both the ports and the unknown-local-address problem is > to use the remote address and an instance identifier. Peers with a single > connection (the "normal" case) would be only instance 1, but if you had > multiple simultaneous connections to the same remote peer you could use > more values. If there's strong consensus, I'm not opposed to adding that. -- Jeff From bertietf@bwijnen.net Tue Jul 17 14:19:38 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6C711E80A4 for ; Tue, 17 Jul 2012 14:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFQjeho3KAPU for ; Tue, 17 Jul 2012 14:19:37 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id AF9F511E80A2 for ; Tue, 17 Jul 2012 14:19:34 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SrFBr-0007TD-0f; Tue, 17 Jul 2012 23:20:20 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SrFBq-0007pu-Ow; Tue, 17 Jul 2012 23:20:18 +0200 Message-ID: <5005D712.5030503@bwijnen.net> Date: Tue, 17 Jul 2012 23:20:18 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bill Fenner References: <0E2C44659B4E4C22A58EDF7E0A834092@BertLaptop> <4F5FB239.7090009@bwijnen.net> <4F68A20F.5000506@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120717 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e5c6081094d32aba66576c995d7cdd4a Cc: Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] [sidr] BGP4 MIB module X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 21:19:38 -0000 Thanks Bill. See my response at bottom On 7/17/12 8:44 PM, Bill Fenner wrote: > [sidr list removed, since this is just about BGP4V2-MIB] > > On Tue, Mar 20, 2012 at 11:28 AM, Bert Wijnen (IETF) > wrote: > > So I had been in discussion with Jeff in order to see > if we could get the BGP4-mibv2 module in good shape. > > Below is out discussion. > > Those who are interested in this MIB module at all > may want to take a look to make sure they agree with > the changes being proposed. > > The most modules we're discussion are: > > - drafts/draft-ietf-idr-bgp4-__mibv2-13.txt > - drafts/draft-ietf-idr-bgp4-__mibv2-tc-mib-03.txt > > In fact I had below discussion on bgp4-mibv2-12.txt, > which resulted in revision 13. > > On 3/13/12 9:46 PM, Bert Wijnen (IETF) wrote: > > On 3/11/12 7:36 PM, Jeffrey Haas wrote: > > Bert, > > On Jan 17, 2012, at 9:28 AM, Bert Wijnen (IETF) wrote: > > First, should we have this discussion on the SIDR list? > Maybe we can get folk motivated to move this forward > that way? > > > I'm massively behind on SIDR, but will be looking at it today. > > I had to get a new SMICng key first. > > > Thanks for doing that. > > > With the new MIB modules I get: > > C:\bw\smicng\work>smicng bgp4v2.inc > E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has invalid value for > MAX-ACCESS > E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid value for > MAX-ACCESS > W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a consistent > indexing schem > e - index items from current table must come after index items from other tables > W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not have a > consistent indexing > scheme - cannot specify an index item from additional "base row" > bgp4V2NlriEntry, since ca > n have only one "base row" which is bgp4V2PeerEntry > E: f(bgp4v2.mi2), (1627,16) OBJECT-TYPE "bgp4V2PeerLocalAddr" is not in a > MANDATORY or cond > itional group for module "BGP4V2-MIB" > E: f(bgp4v2.mi2), (1635,16) OBJECT-TYPE "bgp4V2PeerRemoteAddr" is not in a > MANDATORY or con > ditional group for module "BGP4V2-MIB" > E: f(bgp4v2.mi2), (1643,16) OBJECT-TYPE "bgp4V2NlriPrefix" is not in a MANDATORY > or conditi > onal group for module "BGP4V2-MIB" > > *** 5 errors and 2 warnings in parsing > > C:\bw\smicng\work> > > W.r.t. > E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has invalid value for > MAX-ACCESS > E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid value for > MAX-ACCESS > > You have > INDEX { > bgp4V2PeerInstance, > bgp4V2PeerRemoteAddrType, > bgp4V2PeerRemoteAddr > } > > So why are the LOCAL addrtype and addr not-accessible? > Or should they be part of the index? > > > At one point the local address items were part of the index for the table. After some discussion with implementors, they > preferred > that it be left as it is in the existing BGP-4 MIB case. While this is unfortunate, it makes sense. > > In BGP, it is typically the case that you'll have a single peering session to a given destination peer address. However, > there are > some corner case peering scenarios where two local addresses on a given router may peer with the same destination > address from the > same instance. This is a *very* uncommon case and it lead to some minor tweaks in the BGP language when RFC 4271 was > published. > > The problem with putting the local address into the key is that it removes the determinism from the index. If the local > address is > not configured, as may be the case for ebgp peering, you may not know what it would be. In the case of some ibgp, it's also > possible the local address may change based on what TCP decided it needed. Instead of catering to these uncertain cases, > it was > cleaner to remove the local address from the index. > > I have changed these back to read-only. > > > good. > > > W.r.t. > W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a consistent > indexing schem > e - index items from current table must come after index items from other tables > > You have: > > INDEX { > bgp4V2PeerInstance, > bgp4V2NlriAfi, > bgp4V2NlriSafi, > bgp4V2NlriPrefixType, > bgp4V2NlriPrefix, > bgp4V2NlriPrefixLen, > bgp4V2PeerRemoteAddrType, > bgp4V2PeerRemoteAddr, > bgp4V2NlriIndex > } > ::= { bgp4V2NlriTable 1 } > > So pls explain to me that indexing so I can form an opinion if that is OK or > not. Besides the warning from SMICng, I also wonder why > NlriIndex is the last index column, while it is the first column in the > table. > > > The above up to nlri-index is a natural order walk for BGP. It's also largely what is used in the existing 4273 MIB: > > bgp4PathAttrEntry OBJECT-TYPE > SYNTAX Bgp4PathAttrEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Information about a path to a network." > INDEX { bgp4PathAttrIpAddrPrefix, > bgp4PathAttrIpAddrPrefixLen, > bgp4PathAttrPeer } > ::= { bgp4PathAttrTable 1 } > > Thus, walk all of a given instance. There's no guarantee that 10/8 in one instance is the same as another, especially > since the > instance may map to a VPN VRF. > Walk a given prefix and peer, as it is in the older table. The prefixes are walked on a per afi/safi basis since the > families are > also incomparable. You then want to see the prefix from all peers. > > The nlriindex covers two cases: Multiple routes in RFC 3107 (which I don't believe anyone implements) and BGP add-path. > You want > to see all routes from a given peer and the nlri index lets you see more than one > > Hopefully the ordering makes sense in the index. > > I now see what you mean about the fact that the object for nlriindex precedes things like the afi and safi. It's mostly > just been > this way for a while. If you feel strongly that it should be re-ordered, we could probably do that since we haven't hit > RFC, but > it will have impact on anyone that may have an in-flight implementation of this. Thus far our fixes have had only minor > impact. > > > The above is still a warning I get in the revision 13. > Would be good to have some comments from (other) implementers > or those who plan to implement > > > The contents of the index make sense: > > BGP Instance (although I would have done this with SNMP contexts, but that ship has sailed) > AFI/SAFI > Prefix > Peer > Instance of this prefix from this peer > > The reason that smicng is getting heartburn is that the MIB uses the instance and peer values from the peer table, even though we're > not augmenting/expanding that table. This is presumably done based upon RFC2578's statement, "Note that objects specified in a > conceptual row's INDEX clause need not be columnar objects of that conceptual row". > > I can't find a clear prohibition of reusing INDEX objects from other tables even though you're not following the structure of that > table. In fact, RFC2578 section 7.8.1 seems to encourage this reuse: > > 7.8.1. Relation between INDEX and AUGMENTS clauses > > (3) Otherwise, **if no existing objects have the required syntax and > semantics**, then auxiliary objects should be defined within the > conceptual row for the new table, and those objects should be used > within the INDEX clause for the conceptual row. > > Since there *are* existing objects with the desired syntax and semantics, it feels like this clause is telling us to use them, > even though this particular use doesn't really match what I understand the original intent to be (which is to have the INDEX of > table A be a prefix of the INDEX of related table B). > > > > W.r.t. > W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not have a > consistent indexing > scheme - cannot specify an index item from additional "base row" > bgp4V2NlriEntry, since ca > n have only one "base row" which is bgp4V2PeerEntry > > You have: > INDEX { > bgp4V2PeerInstance, > bgp4V2NlriAfi, > bgp4V2NlriSafi, > bgp4V2NlriPrefixType, > bgp4V2NlriPrefix, > bgp4V2NlriPrefixLen, > bgp4V2PeerRemoteAddrType, > bgp4V2PeerRemoteAddr, > bgp4V2AdjRibsOutIndex > } > ::= { bgp4V2AdjRibsOutTable 1 } > > Pls explain indexing scheme, so I can form an opinion. > > > The scheme is identical to the prior explanation. The primary difference is since this is sending routes rather than > receiving > them, we may advertise different routes on egress, hence an OutIndex instead of the prior NlriIndex. > > Same question here > > > Same answer, really. The index is: > > BGP Instance > AFI/SAFI > Prefix > Peer > Instance of prefix being sent to this peer > > smicng is being upset because items 1 and 4 are coming from the peer table and items 2 and 3 are coming from the nlri table, and it > is envisioning this world where table A's INDEX is supposed to be a prefix of table B's. > > If we wanted to pacify smicng, the types of the objects in the INDEX would stay the same - they would just be redefined (e.g., > redefine the instance and peer in the NLRI table). Is smicng just expressing a view of how this kind of object reuse is normally > done, or is it a rule? > It is not a hard rule. I have often called it a Perkinism. There is a smicng flag to ignore/suppress the warnings. But before I use that flag, I want to be sure the indexing is as intended and has some thought behind it. Your explanations are fine for me, Bert > Bill From jgs@juniper.net Thu Jul 19 09:34:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E42F21F8780 for ; Thu, 19 Jul 2012 09:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgBAhp6bcTlk for ; Thu, 19 Jul 2012 09:34:47 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A883D21F8675 for ; Thu, 19 Jul 2012 09:34:47 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUAg3XcYbeY6TEarHnxnwDZgtGKHSp2h5@postini.com; Thu, 19 Jul 2012 09:35:41 PDT Received: from jgs-sslvpn-nc.jnpr.net (172.23.5.32) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 19 Jul 2012 09:35:09 -0700 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jul 2012 09:35:10 -0700 Message-ID: <209E55C5-4FBE-4218-B225-99F9E17BAADB@juniper.net> To: "idr@ietf.org List" MIME-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Idr] IDR IETF-84 draft agenda posted X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:34:48 -0000 Our draft agenda is posted: http://www.ietf.org/proceedings/84/agenda/agenda-84-idr If you requested a slot, please confirm that you're listed. If you meant = to request one and haven't done it yet, now would be a good time. --John= From bashandy@cisco.com Thu Jul 19 12:51:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9019D21F8734; Thu, 19 Jul 2012 12:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.932 X-Spam-Level: X-Spam-Status: No, score=-10.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joI0iVra-TGx; Thu, 19 Jul 2012 12:51:19 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 03E1C21F8700; Thu, 19 Jul 2012 12:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=12239; q=dns/txt; s=iport; t=1342727533; x=1343937133; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ooJzU5A7WKiI8H2nqmIBo1gByRodWc+eXSWe2k70UTk=; b=ABBcQRi/YAOc5G2uz9/BGgFuLc+GnycdIrQYXIn5+byXze1MYdiyK5sl rD092gmap0kx1QXM+irFVJ8/uKGxLnSYR1azhDiG8+67aOObO3JnWddMz YjKDzPNWBEyunuQh3pPh7JsrjBAIg9+rI+mRj7B3V/hqfdoKPxj+OeSzK w=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,617,1336348800"; d="asc'?scan'208";a="52355491" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 19 Jul 2012 19:52:13 +0000 Received: from [171.71.139.5] (dhcp-171-71-139-5.cisco.com [171.71.139.5]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6JJqCJN031291; Thu, 19 Jul 2012 19:52:12 GMT Message-ID: <50086564.9020500@cisco.com> Date: Thu, 19 Jul 2012 12:52:04 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: robert@raszuk.net References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> <5004C4A0.8030306@raszuk.net> In-Reply-To: <5004C4A0.8030306@raszuk.net> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2C149076E69925839744317E" Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 19:51:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2C149076E69925839744317E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, May be I understood the source of confusion regarding paths The draft does not require modifications to existing prefix advertisements rules or implementations. All the draft is saying is that if a prefix satisfies the conditions for attaching and advertising "rL" and the prefix is being advertised, then rPE attaches "rL" as an optional attribute. Satisfying or loosing the conditions for advertising "rL" by itself has no bearing on the decision of whether a prefix should be advertised or not. Think of "rL" as a new export RT configured on a VRF with existing export RT in a simple VPN scenario. If the operator adds an export RT to a VRF, the PE will re-advertise the prefixes to its peers to inform them about the new RT that has been configured on top of the pre-existing ones. At the same time, the operator may prohibit the router from doing that. Regarding diverging to implementation details, I am not prepared to discuss any implementation details, at least at this point in time, and I will refrain from commenting on any of them. There are a couple of inline comments. Look for "AB2:" this time Thanks Ahmed On 7/16/2012 6:49 PM, Robert Raszuk wrote: > Hi Ahmed, > > > Thanks a lot for the comments. See Inline. Look for "AB:" > > You are welcome ;) > >>>> ii. If "rL" is per-VRF, then pop *two* labels and forward the >>>> packet based on the contents under the two popped labels >>> >>> I am afraid this does not work. >>> >>> VRF lookup on any rPE would still contain the the original best path >>> towards the PE which failed. This is for any AFI/SAFI. Remember the >>> BGP best path has not executed yet to eliminate the BGP best path >>> which can be influenced by local preference or MED. >>> >>> Your case mistakenly assumed that locally received EBGP route always >>> win, however this is not the case in BGP. > > >> AB: I thought it is understandable because the draft talks about a >> pre-calculated repair path. But it looks like I should say something >> like: The behavior explained in this document requires the support for= >> multipath, such as best external or add-path. > > Nope. Neither best external or add-paths are required for example for > SAFI 1/128. I am not talking about path distribution at all in this > point. >> I'll also add a statement as follows: rPE advertises "rL" with a label= ed >> prefix P/m only if it has an external path for the prefix and rPE is >> administratively permitted to protect the prefix.For unlabeled >> prefixes, rL is only needed if one of the best paths chosen by rPE is >> not an external path. The label "rL" is associated with the external >> path(s) only. > > That clarification is optional. Above I am commenting on your point > that per vrf IP lookup triggered by per-VRF label will not work in > your solution. VRF will still point to the original best path exit. > > It is my understanding that you do not keep original VRF and protected > VRF - do you ? If you do then this needs to be clearly stated in the > document. The content of the "protection VRF" indeed could different > from the original VRF, but I am not sure if you are planning this. > > As I said ... if the rL points outside this works .. if the rL points > to original VRF for IP lookup it does not. > AB2: I disagree with the last statement. As I mentioned before, it is implementation details to describe how a router only considers external path(s) for packets arriving with "rL". We're still not stuck on keeping per-VRF "rL".. > Please clarify. > >>> You re referring to per VRF lookup option in many places of the draft= >>> - that needs to be deleted. Only per-CE label where "last hop" rPE >>> does not perform IP lookup may work. > > >> AB: If I add the statement mentioning that rL is only associated with= >> external path, then it becomes an implementation detail to say that a >> router only considers external paths for packets arriving with rL even= >> if the router makes an IP lookup to determine the next-hop. But I agre= e >> with you that per-CE rL is better and simpler to implement. I will not= >> be so hung up on the per-VRF option if people think that per-CE is >> sufficient > > Again IMHO you have just two options .. > > - keep nice scaling property and _only_ bind the rL to external next > hops (CEs) > > - compromise scaling by adding new "shadow VRFs - different from > primary VRFs and allow rL to point to such shadow VRF for local IP > lookup. > AB2: Again implementation details about per-VRF "rL":) --> No comments >>>> a. Acting as a rPE, PE1 allocates (on per-CE basis) and >>>> advertises a repair label rL1=3D3100 with the prefixes >>>> 10.0.0.0/8 and 11.0.0.0/8 to all iBGP peers >>> >>> Another issue in your proposal is that you assume that rPE will be a >>> protecting PE for everyone. >>> >> AB: As I mentioned above, I will add a statement mentioning that >> multi-path support is required and that rPE advertises rL for prefixes= >> to which rPE has an external path and is administratively allowed to >> do so. > > You are missing my point. > > In the draft you say that it is on purpose that rL is different label > then normal switching label (for example VPN label). > > I am saying that if any box is advertising a prefix - it can advertise > given BGP path only once. No best external .. no add-paths help. And > multipath is irrelevant here completely as this term is used to > indicate what routers installs in the forwarding. > AB2: As mentioned at the beginning of the email, the draft never indicated that it requires changes to BGP prefix advertisement rules or implementations. All the draft is saying that "rL" can be attached to advertised prefixes if the PE can and is willing to act as a repair PE > Adding two labels for the same bgp path does not make it two paths.=20 AB2: Adding "rL" has no bearing on the number of paths. Adding "rL" to a prefix indicates to iPEs and pPEs that the advertising PE is willing to act as a repair PE for the prefix > And as pointed out this is common in the networks for an exit PE to in > the same time be primary for some ingress PEs and backup for the others= =2E AB: Why do you think that there is a problem if the same ePE is primary for some iPEs and repair for others? In fact item 3(a) at the bottom pf page 9 covers this this case. If there some scenarios where being a primary and repair at the same time causes problems or does not work, it would be very helpful to point them out. >>> Again in BGP this is not the case as during best path iPEs will >>> consider BGP next hop metric. Therefor for the identical destination >>> the same PE can be rPE for some iPEs while in the same time it can be= >>> pPE for other iPEs. >>> >>> I do not see how in any BGP today you could signal both types of >>> labels (even if the label is per CE). > > >> AB: I do not understand "both types" refers to which types. But anyway= , >> for a router support any type of fast convergence, such as BGP-PIC or >> PE-CE link protection, it has to support the notion of more than one >> path. > > BGP PIC or PE-CE requires the reception of more then one path. That is > clear. Your proposal mandates advertisement of two types of exit > switching labels (for 1/128 primary VPN label and backup rL label). In > fact you propose to encode rL "as path attributes in MP/BGP updates" > AB2: Thanks for clarifying what I want to say:) >> And to answer your question "If we stop when do we start again ?" The= >> condition to start advertising pNH after stopping is the same conditio= n >> to start advertising pNH for the first time. So PHP will start to >> advertise pNH again when gets the message (pNH) from the pPE again. > > You mean that when " c. pPE advertises pNH as a prefix into IGP" > right ? Then IGP may not be impacted and may not re-advertise ... only > BGP crashed. Then you will never start advertising the pNH. AB2: No, I do not mean IGP. I mean a special advertisement. Item 2 (e) mentions that. For example, an optional TLV in LDP can be used to advertise this special IP address to the PHP. > >> AB: This is a question about an implementation detail. But to keep the= >> answer short, it is VERY EASY for an LSR to pop 3 labels. Routers have= >> been doing a lot more than this at line rate for a long period of time= > > Perhaps it is easy. However I recall folks who invented MPLS telling > me that you never should pop more then one level of labels. Do you > know if currently deployed routers can do it in practice ? AB2: I already answered the question "Do you know if currently deployed routers can do it in practice ? " when I said "it is VERY EASY". I will not comment any further because this is implementation details. Regarding popping more than one label, routers have been doing that for a very long time. For example, a PE that advertises an explicit label (instead of implicit null) for the BGP next-hop. Besides, is there an RFC that explicitly prohibits a router from popping more than one label? > > Anyhow to realize your scheme even if we solve major issues a network > wide upgrade of participating routers is mandatory. > AB2: This is incorrect. The scheme can be incrementally deployed few routers at a time. For example, one iPE, one rP and two ePEs. >> First question: What is "rL" if I am not running MPLS? >> rL is a label that informs rPE to always send the packet to an externa= l >> path. rL has no semantics in the core at all. So the protocol running = in >> the core is totally irrelevant to "rL" > > I am not talking about the core. I am also talking about the edge ... > So edge must use label switching correct ? > AB2: This draft expects a PE to understand MPLS. PEs that do not support MPLS are not covered by this draftt. IP core means only core routers. > Hint: You could have a IP tunnel endpoint terminating at the CE/NH. AB2: The draft never claimed that it works in all scenarios (and no document should be making this claim). But for this particular scenario, can you provide more clarification? > >> Second question: What is "vL" in a pure IP core? >> Section 3.1 talks about the case where all core routers, including the= >> repairing router "rP", do not understand MPLS. In that case, vL is not= >> use at all. If it is mentioned, then it is probably a mistake > > ok. > >> Section 3.2 talks about the case where the repairing core router "rP" >> understands MPLS but the rest of the core routers does not. In that >> case, "vL" is used the similar to how it is used in MPLS core >> Third question: What protocol distributes those labels ? >> Only "vL" needs to be distributed to the core. An optional TLV in ISIS= >> or OSPF can be used to distribute "vL". > > Ahh nice .. so we are back to carrying labels in IGP .. Finally ! That > has been proposed so many times :)=20 AB2: So I heard:) So one more time would not be so weird:) > Also maybe we will get the concept of global label rolled out in more > generic way as vL is effectively and semantically a global label (per > given IGP domain). AB2: Another misunderstanding. The semantics of "vL" are not global. Is there a place in the draft where it is implied that "vL" has global semantics in an IGP domain? > Thx, > R. --------------enig2C149076E69925839744317E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQCGVs+G19kFA5zIYRAhBQAJ0c5oUYZyAZLlDf0Sqe45R4r/kFRACdGWxi uUAxfOXwpGmD2xDvyFgFxvQ= =eq/7 -----END PGP SIGNATURE----- --------------enig2C149076E69925839744317E-- From robert@raszuk.net Thu Jul 19 23:38:50 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8497D21F8653 for ; Thu, 19 Jul 2012 23:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMQOfatkc8zz for ; Thu, 19 Jul 2012 23:38:49 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 48E6A21F85F2 for ; Thu, 19 Jul 2012 23:38:49 -0700 (PDT) Received: (qmail 22032 invoked by uid 399); 20 Jul 2012 06:39:43 -0000 Received: from unknown (HELO ?10.77.83.122?) (pbs:robert@raszuk.net@72.254.61.36) by mail1310.opentransfer.com with ESMTPM; 20 Jul 2012 06:39:43 -0000 X-Originating-IP: 72.254.61.36 Message-ID: <5008FD2E.1000006@raszuk.net> Date: Fri, 20 Jul 2012 08:39:42 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ahmed Bashandy References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> <5004C4A0.8030306@raszuk.net> <50086564.9020500@cisco.com> In-Reply-To: <50086564.9020500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 06:38:50 -0000 Ahmed, > May be I understood the source of confusion regarding paths > The draft does not require modifications to existing prefix > advertisements rules or implementations. All the draft is saying is that > if a prefix satisfies the conditions for attaching and advertising "rL" > and the prefix is being advertised, then rPE attaches "rL" as an > optional attribute. To the best of my knowledge today we do not have a defined attribute in BGP to carry MPLS labels. If you are proposing a solution which does not have corresponding encoding in the protocol you intend to use I think you are going a wrong way. > Regarding diverging to implementation details, I am not prepared to > discuss any implementation details, at least at this point in time, and > I will refrain from commenting on any of them. That's neat :) While you may claim that everything is an implementation detail I think you should not be stating as an advantage of your proposal the following: " o Very scalable: o No router has to copy the routing table of another router" > AB2: As mentioned at the beginning of the email, the draft never > indicated that it requires changes to BGP prefix advertisement rules or > implementations. All the draft is saying that "rL" can be attached to > advertised prefixes if the PE can and is willing to act as a repair PE Than your solution is broken. You must at min enable best external to cover the case where the VPN chooses by local preference or med different exit point as best path. If you do not enable best external or add-paths your repair paths will not get advertised. >> Anyhow to realize your scheme even if we solve major issues a network >> wide upgrade of participating routers is mandatory. >> > AB2: This is incorrect. The scheme can be incrementally deployed few > routers at a time. For example, one iPE, one rP and two ePEs. That was correct. Pls notice what I said: "participating routers". Do you expect iPE, rP and two ePEs all be from the same vendor and same OS branch supporting your feature ??? > AB2: The draft never claimed that it works in all scenarios (and no > document should be making this claim). But for this particular scenario, > can you provide more clarification ? I am afraid this is an implementation detail how you organize the packet switching after termination of the IP tunnel. Rgs, R. From bashandy@cisco.com Fri Jul 20 18:16:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DF811E80A0; Fri, 20 Jul 2012 18:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0u2wH-H8gnX; Fri, 20 Jul 2012 18:16:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8E64221F84A2; Fri, 20 Jul 2012 18:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=4806; q=dns/txt; s=iport; t=1342833469; x=1344043069; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=+37v4f8239IUffKohLsQdzf4HAanKipjB0bffY3upwg=; b=RsE5PeTE/f1KGnv2l5Kt5ZqTMxMAd7S/8iAxUh0wkx4aGMqllSJG5Dxg DExU86LLi4X4GBZLSTVAoXDdDWLDhXaNn6qd2MfCa/+qVEpDA5Y2UYRDC NardDgZxIVM63GoNtRy3SmcX0FsLBS5T4hThExrSuADUin33SPO6iM/4w s=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,627,1336348800"; d="asc'?scan'208";a="49992105" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 21 Jul 2012 01:17:49 +0000 Received: from [10.21.83.238] (sjc-vpn4-1007.cisco.com [10.21.83.238]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6L1Hlpx008334; Sat, 21 Jul 2012 01:17:48 GMT Message-ID: <500A0336.1080001@cisco.com> Date: Fri, 20 Jul 2012 18:17:42 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: robert@raszuk.net References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> <5004C4A0.8030306@raszuk.net> <50086564.9020500@cisco.com> <5008FD2E.1000006@raszuk.net> In-Reply-To: <5008FD2E.1000006@raszuk.net> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig10E2B7469FF4831EAB5AFA04" Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 01:16:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig10E2B7469FF4831EAB5AFA04 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Robert, See comments inline. This time look for "AB3:" Thanks Ahmed On 7/19/2012 11:39 PM, Robert Raszuk wrote: > Ahmed, > > > May be I understood the source of confusion regarding paths >> The draft does not require modifications to existing prefix >> advertisements rules or implementations. All the draft is saying is th= at >> if a prefix satisfies the conditions for attaching and advertising "rL= " >> and the prefix is being advertised, then rPE attaches "rL" as an >> optional attribute. > > To the best of my knowledge today we do not have a defined attribute > in BGP to carry MPLS labels. If you are proposing a solution which > does not have corresponding encoding in the protocol you intend to use > I think you are going a wrong way. AB3: You are rushing things too fast:) We're still discussing the idea. The syntax of the new attribute will come at later versions. I hope you do not think that the whole solution is wrong just because I did not put the syntax of the attribute in the first version. > >> Regarding diverging to implementation details, I am not prepared to >> discuss any implementation details, at least at this point in time, an= d >> I will refrain from commenting on any of them. > > That's neat :) While you may claim that everything is an > implementation detail I think you should not be stating as an > advantage of your proposal the following: > > " o Very scalable: > o No router has to copy the routing table of another router" AB3: So either I diverge into implementations or blindly accept what should be kept in the draft and what should not. If I were to suggest the above modification, I would make a it more scientific by taking a closer look at the draft and trying to corroborate the suggestion by finding one or more deployment scenarios where one router needs to copy the routing table of another. > >> AB2: As mentioned at the beginning of the email, the draft never >> indicated that it requires changes to BGP prefix advertisement rules o= r >> implementations. All the draft is saying that "rL" can be attached to >> advertised prefixes if the PE can and is willing to act as a repair PE= > > Than your solution is broken.=20 AB3: No it is not. You do not have a full understanding of the draft > You must at min enable best external to cover the case where the VPN > chooses by local preference or med different exit point as best path. > If you do not enable best external or add-paths your repair paths will > not get advertised. AB3: I am not sure why you insist on pushing path selection and advertisement down the throat of the draft. The conditions for advertising "rL" are clear. What you just suggested is one way to satisfy the conditions in a certain scenario. BGP-PIC edge and PE-CE link protection are other scenarios where the conditions of advertising "rL" are satisfied without best external or add-path. > >>> Anyhow to realize your scheme even if we solve major issues a network= >>> wide upgrade of participating routers is mandatory. >>> >> AB2: This is incorrect. The scheme can be incrementally deployed few >> routers at a time. For example, one iPE, one rP and two ePEs. > > That was correct. Pls notice what I said: "participating routers". AB3: IMHO, if a network has thousands of routers, it is hard to label updating 4 routers as "network wide" > > Do you expect iPE, rP and two ePEs all be from the same vendor and > same OS branch supporting your feature ??? AB3: Ah. So now we're taking the discussion of implementation details to the level of feature release and router sales:) >> AB2: The draft never claimed that it works in all scenarios (and no >> document should be making this claim). But for this particular scenari= o, >> can you provide more clarification ? > > I am afraid this is an implementation detail how you organize the > packet switching after termination of the IP tunnel. AB3: Excellent, so I see an agreement to avoid implementation details:). > > Rgs, > R. > --------------enig10E2B7469FF4831EAB5AFA04 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQCgM7+G19kFA5zIYRAq3jAJ4ivGRni5EAey+WCkONBdeq5IbcvwCgiG9u +PsEKUW/NhhZpZg1aA9/zAk= =HjHy -----END PGP SIGNATURE----- --------------enig10E2B7469FF4831EAB5AFA04-- From robert@raszuk.net Sat Jul 21 10:27:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB8C21F8562 for ; Sat, 21 Jul 2012 10:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx6f9VoEBtv0 for ; Sat, 21 Jul 2012 10:27:12 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A3B4521F855D for ; Sat, 21 Jul 2012 10:27:12 -0700 (PDT) Received: (qmail 22109 invoked by uid 399); 21 Jul 2012 17:28:11 -0000 Received: from unknown (HELO ?10.77.83.164?) (pbs:robert@raszuk.net@72.254.10.46) by mail1310.opentransfer.com with ESMTPM; 21 Jul 2012 17:28:11 -0000 X-Originating-IP: 72.254.10.46 Message-ID: <500AE6AA.9090608@raszuk.net> Date: Sat, 21 Jul 2012 19:28:10 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ahmed Bashandy References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> <5004C4A0.8030306@raszuk.net> <50086564.9020500@cisco.com> <5008FD2E.1000006@raszuk.net> <500A0336.1080001@cisco.com> In-Reply-To: <500A0336.1080001@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 17:27:13 -0000 Hi Ahmed, Since you seem to be skipping answering some questions in your replies let me ask (well repeat) one question at a time. Question: How are you going to propagate any information in iBGP from repair PEs to ingress PEs considering that overall best path for this prefix is advertised by some other protected PE ? Are you mandating that your solution is deployable only with use of one of the following techniques: - add-paths on rPEs, RRs & iPEs - best-external on rPEs + add-paths on RRs & iPEs - best-external on rPEs + diverse-path on RRs - full mesh of iPEs & rPEs with best external (I am skipping cluster external option on RRs as in the control plane only RRs which are randomly located this may be a bit difficult to provision). Scenario clarification: I am talking about case where pPE chooses the best path based on local preference or MED. The only comment I found related to the above is in the introduction: In modern networks, it is not uncommon to have a prefix reachable via multiple edge routers. One example is the best external path [8]. The reason for such fundamental question is that architectures which do not require at the service level participation of ingress routers and repair routers in the protection may be chosen over the one which does (your proposal). Rgs, R. From DanielC@orckit.com Sun Jul 22 06:50:27 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2221F859B for ; Sun, 22 Jul 2012 06:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydN+oZnl6yRF for ; Sun, 22 Jul 2012 06:50:21 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB7421F8554 for ; Sun, 22 Jul 2012 06:50:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD6811.6759BF65" Date: Sun, 22 Jul 2012 16:53:40 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081307A42614@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] BGP MIBv2 implementation Thread-Index: Ac1kTpZmmmoOcaXIQxy7BQ3HiL5FoQBIGFTw References: <44F4E579A764584EA9BDFD07D0CA0813076E31CA@tlvmail1><6246F062-090F-4092-B931-B10F3A84AEB0@juniper.net><44F4E579A764584EA9BDFD07D0CA0813076E323A@tlvmail1><283B4946-C3D5-42A0-87D6-02C8FD5CA132@juniper.net><44F4E579A764584EA9BDFD07D0CA08130777BECD@tlvmail1><44F4E579A764584EA9BDFD07D0CA08130777C66C@tlvmail1> From: "Daniel Cohn" To: "Bill Fenner" Cc: Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] BGP MIBv2 implementation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 13:50:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD6811.6759BF65 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bill and all, please see inline with [DC]. =20 From: fenner@fenron.com [mailto:fenner@fenron.com] On Behalf Of Bill Fenner Sent: Tuesday, July 17, 2012 9:59 PM To: Daniel Cohn Cc: Jeffrey Haas; idr@ietf.org Subject: Re: [Idr] BGP MIBv2 implementation =20 On Wed, Apr 25, 2012 at 8:44 AM, Daniel Cohn wrote: Hi Jeff and all, =20 Sorry for the delayed response. I think it would be a shame to go through the hassle of updating the BGP MIB without fully supporting BGP L3VPN/VPLS (in both RFC 4761 and 6074 flavors). Therefore I support using a generic NLRI prefix TC that explicitly supports these NLRIs and can be extended to support future BGP applications. It doesn't seem consistent to add AFI/SAFI to the MIB while leaving the NLRI as an IP address. =20 A couple more suggestions for this draft: =20 - Change the bgp4V2AdjRibsOutTable index to make it the same as in bgp4V2NlriTable. In its current form (a pointer to the bgp4V2NlriTable), it doesn't support BGP routes originated by this speaker (e.g. redistributed from IGP) so it's woefully inadequate. I had a similar thought about the Adj-RIBS-Out table - it can't represent a locally-originated route. I am not sure what you mean by changing the index to address this, however, since the index as it is makes sense to me. =20 Maybe you mean to change the structure of the table to copy all of the data from the NlriTable, which I disagree with. =20 [DC] You're right, that's what I meant. My bad.=20 =20 One idea on handling this with the current structure is to use the pointer to point to a row in the IP-FORWARDING-MIB for a locally-originated route. =20 [DC] I don't think that would work, as there is plenty of BGP-specific information that is not available at the IP forwarding MIB, such as MED, LOCAL_PREF, or ext communities (actually all the information currently indexed by bgpM2PathAttrIndex). What is the problem with expanding the table to include all required BGP information? If your concern is memory utilization, at the risk of stating the obvious let me say that MIB structure doesn't necessarily prescribe the internal database structure, meaning you can always choose a more efficient internal structure (e.g. using pointers instead of storing duplicate information) and translate the SNMP queries from/to the MIB structure. - Add support for BGP communities (as in your communities draft) in the NLRI in/out tables. There is no reason this can't be a future addition, right, in the interest of getting the base functionality out? =20 [DC] Why should this simple addition hold back progress? =20 - Restore local address (and maybe ports) to bgp4V2PeerTable index to support multiple BGP sessions between two speakers as in draft-ietf-grow-diverse-bgp-path-dist If the ports are in the INDEX, how do you ever find a row if one of the ports is guaranteed to be ephemeral and you don't know a priori who originated the connection? =20 If the remote address was first in the INDEX, you could always use getnext to get a given value independent of the local address, but that's not a concept that many management systems are familiar with. =20 An idea that solves both the ports and the unknown-local-address problem is to use the remote address and an instance identifier. Peers with a single connection (the "normal" case) would be only instance 1, but if you had multiple simultaneous connections to the same remote peer you could use more values. =20 [DC] I don't see a problem with using getnext, but a neutral instance is also acceptable. =20 =20 Bill =20 =20 Feedback is welcome, regards, =20 Daniel =20 From: Jeffrey Haas [mailto:jhaas@pfrc.orgnet]=20 Sent: Thu, 15 Mar 2012 14:19:17=20 Subject: Re: [Idr] IETF 83 - BGP MIBv2 Update - prefix Textual Conventions =20 Working Group, =20 As per prior plenary discussion on making more effect use of working group session time, please find my BGP MIBv2 update slides on the proceedings page: =20 http://www.ietf.org/proceedings/83/slides/slides-83-idr-0.pdf =20 The bulk of the presentation is self explanatory. I'd like to thank=20 Bert Wijnen for additional MIB feedback. I suspect we'll get a bit more feedback from him since he discovered bugs as part of doing derivative work for the SIDR MIB. Draft -13 [1] reflects his comments as of the IETF 83 posting cutoff. =20 One item I would like to draw the working group's further attention to is covered on slides 5-7. As part of analyzing the requirements for the multicast next-gen VPN [2] MIBs that Jeffrey Zhang (zzhang at juniper.net) is working on, we briefly considered exposing MVPN routing state in BGP via the BGP MIBv2. Per prior presentations and discussions on design goals for the BGP MIBv2, we wanted one MIB that was capable of being re-used for various types of reachability that was being carried in BGP. However, the primary goal was to be able to carry IPv6 reachability. =20 RFC 6514 can be briefly examined to see the different types of reachability that are being passed around in BGP. The reachability is distinguished within the same AFI/SAFI by a "Route Type" field within the prefix with type specific encodings following. =20 =20 The BGP MIBv2 presents prefixes using the following two objects: bgp4V2NlriPrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the IP address prefix in the Network Layer Reachability Information field. The value of this object is derived from the appropriate value from the bgp4V2NlriAfi field. Where an appropriate InetAddressType is not available, the value of the object must be unknown(0)." ::=3D { bgp4V2NlriEntry 4 } =20 bgp4V2NlriPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "An IP address prefix in the Network Layer Reachability Information field. This object is an IP address containing the prefix with length specified by bgp4V2NlriPrefixLen. Any bits beyond the length specified by bgp4V2NlriPrefixLen are zeroed. =20 An implementation is required to support IPv4 prefixes. In this case, the object length is (0..4). =20 An implementation MAY support IPv6 prefixes. In this case, the object length is (0..16)" REFERENCE "RFC 4271, Section 4.3." ::=3D { bgp4V2NlriEntry 5 } =20 The general goal of the "InetAddressType/InetAddress" textual conventions [3] is to provide a level of generality for MIB objects that are "addresses". Our initial design guidance for the BGP MIBv2 was to make use of these TCs to help represent both IPv4 and IPv6 addresses - and it does this well. =20 As part of investigating encoding MVPN prefixes in the BGP MIBv2, I sent mail to the ietfmibs mailing list to discuss this possibility. After a few exchanges, it was suggested that since the information is BGP specific that this was not the best fit for the INET-ADDRESS-MIB and that we should consider a BGP TC specifically for this purpose. =20 If we were to consider such a TC, we would make it "IANA maintained". This would permit us to issue the initial MIB but permit IANA to maintain the code points as new protocol elements are added. I.e. we don't have to have a MIB document stuck as an I-D forever. The current INET-ADDRESS-MIB is an example of such a MIB. =20 After further discussion with Jeffrey Zhang, we determined that there wasn't a strong incentive to continue the MVPN MIB work as a BGP MIBv2 extension, We may see future requirements from other BGP-based address families. =20 =20 My recommendation would be that we proceed with the work to create a BGP Prefix TC MIB with an explicit goal of being backward compatible with the INET-ADDRESS-MIB. However, the WG may also come to the decision to not pursue making this MIB completely general purpose and just worry about IPv4/IPv6. =20 With regard to standards advancement, the new BGP Prefix MIB shouldn't unnecessarily hinder the BGP MIBv2. =20 I would like the WG to come to some consensus as to whether we (very likely, I) take on the work to make such a prefix TC MIB. =20 If the discussion becomes interesting enough, Sue and John have agreed to grant us discussion time at the upcoming IDR session in Paris. =20 -- Jeff =20 =09 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 ------_=_NextPart_001_01CD6811.6759BF65 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bill and all, please see inline with [DC].

 

From:= = fenner@fenron.com [mailto:fenner@fenron.com] On Behalf Of Bill = Fenner
Sent: Tuesday, July 17, 2012 9:59 PM
To: = Daniel Cohn
Cc: Jeffrey Haas; idr@ietf.org
Subject: = Re: [Idr] BGP MIBv2 implementation

 

On Wed, = Apr 25, 2012 at 8:44 AM, Daniel Cohn <DanielC@orckit.com> = wrote:

Hi Jeff and all,

 

Sorry for the delayed response. I think it would be a shame to go = through the hassle of updating the BGP MIB without fully supporting BGP = L3VPN/VPLS (in both RFC 4761 and 6074 flavors). Therefore I support = using a generic NLRI prefix TC that explicitly supports these NLRIs and = can be extended to support future BGP applications. It doesn’t = seem consistent to add AFI/SAFI to the MIB while leaving the NLRI as an = IP address.

 

A couple more suggestions for this draft:

 

-     &nb= sp;    Change the bgp4V2AdjRibsOutTable index to make it the same as in = bgp4V2NlriTable. In its current form (a pointer to the bgp4V2NlriTable), = it doesn’t support BGP routes originated by this speaker (e.g. = redistributed from IGP) so it’s woefully = inadequate.

I = had a similar thought about the Adj-RIBS-Out table - it can't represent = a locally-originated route.  I am not sure what you mean by = changing the index to address this, however, since the index as it is = makes sense to me.

 

 Maybe you mean = to change the structure of the table to copy all of the data from the = NlriTable, which I disagree with.

 

[DC] You’re right, that’s what I meant. My bad. =

 

One idea on handling this with the current structure = is to use the pointer to point to a row in the IP-FORWARDING-MIB for a = locally-originated route.

 

[DC] I don’t think that would work, as there is plenty of = BGP-specific information that is not available at the IP forwarding MIB, = such as MED, LOCAL_PREF, or ext communities (actually all the = information currently indexed by = bgpM2PathAttrIndex).

What is the problem with expanding the table to include all required = BGP information? If your concern is memory utilization, at the risk of = stating the obvious let me say that MIB structure doesn’t = necessarily prescribe the internal database structure, meaning you can = always choose a more efficient internal structure (e.g. using pointers = instead of storing duplicate information) and translate the SNMP queries = from/to the MIB structure.

-     &nb= sp;    Add support for BGP communities (as in your communities draft) in the = NLRI in/out = tables.

There is no reason this can't be a future addition, = right, in the interest of getting the base functionality = out?

 

[DC] Why should this simple addition hold back = progress?

 

-     &nb= sp;    Restore local address (and maybe ports) to bgp4V2PeerTable index to = support multiple BGP sessions between two speakers as in = draft-ietf-grow-diverse-bgp-path-dist

If the ports are in the INDEX, how do you = ever find a row if one of the ports is guaranteed to be ephemeral and = you don't know a priori who originated the = connection?

 

If the remote address was first in the INDEX, you = could always use getnext to get a given value independent of the local = address, but that's not a concept that many management systems are = familiar with.

 

An idea that solves both the ports and the = unknown-local-address problem is to use the remote address and an = instance identifier.  Peers with a single connection (the = "normal" case) would be only instance 1, but if you had = multiple simultaneous connections to the same remote peer you could use = more values.

 

[DC] I don’t see a problem with using getnext, but a neutral = instance is also acceptable.

 

 

  Bill

 

 

Feedback is welcome, regards,

 

Daniel

 

From:= = Jeffrey Haas [mailto:jhaas@pfrc.orgnet]
Sent: Thu, 15 Mar = 2012 14:19:17
Subject: Re: [Idr] IETF 83 - BGP MIBv2 Update - = prefix Textual Conventions

 <= /o:p>

Working = Group,

 

As per prior = plenary discussion on making more effect use of working = group

session time, = please find my BGP MIBv2 update slides on the = proceedings

page:

 

http://www.ietf.org/proceedings/83/slides/slides-83-idr= -0.pdf

 

The bulk of the = presentation is self explanatory.  I'd like to thank =

Bert Wijnen for = additional MIB feedback.   I suspect we'll get a bit = more

feedback from him = since he discovered bugs as part of doing derivative = work

for the SIDR = MIB.  Draft -13 [1] reflects his comments as of the IETF = 83

posting = cutoff.

 

One item I would = like to draw the working group's further attention to = is

covered on slides = 5-7.  As part of analyzing the requirements for = the

multicast next-gen = VPN [2] MIBs that Jeffrey Zhang (zzhang at juniper.net) = is

working on, we = briefly considered exposing MVPN routing state in BGP via = the

BGP MIBv2.  = Per prior presentations and discussions on design goals for = the

BGP MIBv2, we = wanted one MIB that was capable of being re-used for = various

types of = reachability that was being carried in BGP.  However, the = primary

goal was to be able = to carry IPv6 reachability.

 

RFC 6514 can be = briefly examined to see the different types of = reachability

that are being = passed around in BGP.  The reachability is = distinguished

within the same = AFI/SAFI by a "Route Type" field within the prefix with = type

specific encodings = following. 

 

The BGP MIBv2 = presents prefixes using the following two = objects:

    = bgp4V2NlriPrefixType OBJECT-TYPE

        = SYNTAX     InetAddressType

        MAX-ACCESS = not-accessible

        = STATUS     current

        = DESCRIPTION

            = "The type of the IP address prefix in the

           &= nbsp; Network Layer Reachability Information = field.

           &= nbsp; The value of this object is derived from = the

           &= nbsp; appropriate value from the bgp4V2NlriAfi = field.

           &= nbsp; Where an appropriate InetAddressType is = not

           &= nbsp; available, the value of the object must be

           &= nbsp; unknown(0)."

        ::=3D { bgp4V2NlriEntry = 4 }

 

    = bgp4V2NlriPrefix OBJECT-TYPE

        = SYNTAX     InetAddress

        MAX-ACCESS = not-accessible

        = STATUS     current

        = DESCRIPTION

            = "An IP address prefix in the Network Layer

           &= nbsp; Reachability Information field. This = object

           &= nbsp; is an IP address containing the prefix = with

           &= nbsp; length specified by bgp4V2NlriPrefixLen.

           &= nbsp; Any bits beyond the length specified by

           &= nbsp; bgp4V2NlriPrefixLen are zeroed.

 

           &= nbsp; An implementation is required to support = IPv4

           &= nbsp; prefixes.  In this case, the object = length

           &= nbsp; is (0..4).

 

           &= nbsp; An implementation MAY support IPv6 = prefixes.

           &= nbsp; In this case, the object length is = (0..16)"

        = REFERENCE

            = "RFC 4271, Section 4.3."

        ::=3D { bgp4V2NlriEntry = 5 }

 

The general goal of = the "InetAddressType/InetAddress" textual conventions = [3]

is to provide a = level of generality for MIB objects that are = "addresses".

Our initial design = guidance for the BGP MIBv2 was to make use of these = TCs

to help represent = both IPv4 and IPv6 addresses - and it does this = well.

 

As part of = investigating encoding MVPN prefixes in the BGP MIBv2, I = sent

mail to the = ietfmibs mailing list to discuss this possibility.  After a = few

exchanges, it was = suggested that since the information is BGP specific = that

this was not the = best fit for the INET-ADDRESS-MIB and that we = should

consider a BGP TC = specifically for this purpose.

 

If we were to = consider such a TC, we would make it "IANA maintained".  = This

would permit us to = issue the initial MIB but permit IANA to maintain = the

code points as new = protocol elements are added.  I.e. we don't have to = have

a MIB document = stuck as an I-D forever.  The current INET-ADDRESS-MIB = is

an example of such = a MIB.

 

After further = discussion with Jeffrey Zhang, we determined that there = wasn't

a strong incentive = to continue the MVPN MIB work as a BGP MIBv2 = extension,

We may see future = requirements from other BGP-based address families.  =

 

My recommendation = would be that we proceed with the work to create a = BGP

Prefix TC MIB with = an explicit goal of being backward compatible with = the

INET-ADDRESS-MIB.  However, the WG may also come to the = decision to not

pursue making this = MIB completely general purpose and just worry = about

IPv4/IPv6.

 

With regard to = standards advancement, the new BGP Prefix MIB = shouldn't

unnecessarily = hinder the BGP MIBv2.

 

I would like the WG = to come to some consensus as to whether we (very = likely,

I) take on the work = to make such a prefix TC MIB.

 

If the discussion = becomes interesting enough, Sue and John have agreed = to

grant us discussion = time at the upcoming IDR session in Paris.

 

-- = Jeff

 <= /o:p>


______________________________________= _________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

------_=_NextPart_001_01CD6811.6759BF65-- From bashandy@cisco.com Mon Jul 23 18:48:27 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468E611E80F3; Mon, 23 Jul 2012 18:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.849 X-Spam-Level: X-Spam-Status: No, score=-10.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EfnZQZnmLWS; Mon, 23 Jul 2012 18:48:26 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 81FA711E80E2; Mon, 23 Jul 2012 18:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=4082; q=dns/txt; s=iport; t=1343094506; x=1344304106; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Mnf+lH0w49x/K6tg7ta8xIIqbPa+15k+eanTDAZgnp0=; b=AZtAMeFNld4pERO5WnR+9WN3XtFCtNZowIm4y1+Yo1mTBSVba7RGESNc 59BiPUn2Zm+uhPVJXfrmnH/0zfsMe6Rl8jMgXSb59otSBb02T06SG5LHw 4zdOwyIHi0rx2P3mJrrjiH5m5ZdArmKckFUdDYsBpTsmR7ln3il+coYXI w=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,641,1336348800"; d="asc'?scan'208";a="49714230" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 24 Jul 2012 01:48:26 +0000 Received: from [171.71.139.5] (dhcp-171-71-139-5.cisco.com [171.71.139.5]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6O1mQRs029957; Tue, 24 Jul 2012 01:48:26 GMT Message-ID: <500DFEE9.1020608@cisco.com> Date: Mon, 23 Jul 2012 18:48:25 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "robert@raszuk.net" References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> <5004C4A0.8030306@raszuk.net> <50086564.9020500@cisco.com> <5008FD2E.1000006@raszuk.net> <500A0336.1080001@cisco.com> <500AE6AA.9090608@raszuk.net> In-Reply-To: <500AE6AA.9090608@raszuk.net> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig36FF589D915D3182D7EC9F1C" Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , "rtgwg@ietf.org" Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 01:48:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig36FF589D915D3182D7EC9F1C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It looks like I am going to re-iterate some of the statements that you seem to avoid (I don't know why) See replies inline. Look for AB4 Thanks -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net] Sent: Saturday, July 21, 2012 10:28 AM To: Ahmed Bashandy (bashandy) Cc: idr@ietf.org List; rtgwg@ietf.org; Maciek Konstantynowicz (mkonstan) Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt Hi Ahmed, Since you seem to be skipping answering some questions in your replies let me ask (well repeat) one question at a time. Question: How are you going to propagate any information in iBGP from repair PEs to ingress PEs considering that overall best path for this prefix is advertised by some other protected PE ? AB4: Quotation from the first reply (AB:) "The behavior explained in this document requires the support for multipath". More explicit statement: how to satisfy the multipath requirement is deliberately left out of the draft. Are you mandating that your solution is deployable only with use of one of the following techniques: - add-paths on rPEs, RRs & iPEs - best-external on rPEs + add-paths on RRs & iPEs - best-external on rPEs + diverse-path on RRs - full mesh of iPEs & rPEs with best external AB4: No. The draft does NOT mandate particular multipath technique(s). This is a question that is already answered. Here is a quotation from the previous email (AB3:) "What you just suggested is one way to satisfy the conditions in a certain scenario. BGP-PIC edge and PE-CE link protection are other scenarios where the conditions of advertising "rL" are satisfied without best external or add-path." (I am skipping cluster external option on RRs as in the control plane only RRs which are randomly located this may be a bit difficult to provision). Scenario clarification: I am talking about case where pPE chooses the best path based on local preference or MED. The only comment I found related to the above is in the introduction: In modern networks, it is not uncommon to have a prefix reachable via multiple edge routers. One example is the best external path [8]. The reason for such fundamental question is that architectures which do not require at the service level participation of ingress routers and repair routers in the protection may be chosen over the one which does (your proposal). AB4: So all these questions are alluding to a comparison:) A more direct question, like what Susan asked, would have been easier to answer. IMHO comparison with other techniques is more befitting an informational draft= =2E For the participation of iPE and rPE, I have a comment and a request - BGP-PIC edge is a deployed solution that requires iPE participation. So it seems like other factors, such as scalability, transparency to operators, and simplified provisioning and management, are as important in deployment decisions - For rPE participation, I would be very happy if you point me to a paper/draft/implemented/deployed or about to be implemented/deployed BGP-FRR technique (that rely on local failure detection and traffic re-routing when an ePE fails) that does not require the participation of rPE. That would also help with Susan's request. Rgs, R. --------------enig36FF589D915D3182D7EC9F1C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQDf7p+G19kFA5zIYRApnPAJ9xZyXYA7vcMySFg15b+Ys+CtQ0gQCcDiGT zHikPaaFJADGZ2EaYXFmSTI= =WRNI -----END PGP SIGNATURE----- --------------enig36FF589D915D3182D7EC9F1C-- From fenner@fenron.com Wed Jul 25 16:21:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F095221F849D for ; Wed, 25 Jul 2012 16:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ+lkm9N8iTK for ; Wed, 25 Jul 2012 16:21:51 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E321F849C for ; Wed, 25 Jul 2012 16:21:50 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1473899ghb.31 for ; Wed, 25 Jul 2012 16:21:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=C0sHGxLT5H9DrkFeV7aNpdhcyHF2Eklz37vGQtteI/I=; b=FdPt0tdmv4TAqICXp8RFeI210npkjcYq1z4He0/YotwwmpzHGWxx9QQiORQ0bRiEel BwB+9SxUvFPa+OSomffOLQoFg0Noibp7ZWy30PWyFqJvCePmHrF0QJmtQhjQSF5ZEMrO CAqabL8YIlDOeFhTdxG+HrEqrRUOf680Fmh3N84v12tABlpwPHVw5T9R30VhMuE8uin4 lfI+oZUMfaZp+yoMkjPy8wywpuzNZqxF3HaEwjuJfhZs+rC7RflpwhjCQM2nVFOZclBo Fc9g9wrU1gpNLC0CFfMXH26XQaQ2XVrsy8JLVNWLYM3Ho8ID4H/UPlYBJUDflqS6d+09 TAnA== MIME-Version: 1.0 Received: by 10.60.7.197 with SMTP id l5mr16693634oea.33.1343258510120; Wed, 25 Jul 2012 16:21:50 -0700 (PDT) Sender: fenner@fenron.com Received: by 10.182.33.228 with HTTP; Wed, 25 Jul 2012 16:21:50 -0700 (PDT) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081307A42614@tlvmail1> References: <44F4E579A764584EA9BDFD07D0CA0813076E31CA@tlvmail1> <6246F062-090F-4092-B931-B10F3A84AEB0@juniper.net> <44F4E579A764584EA9BDFD07D0CA0813076E323A@tlvmail1> <283B4946-C3D5-42A0-87D6-02C8FD5CA132@juniper.net> <44F4E579A764584EA9BDFD07D0CA08130777BECD@tlvmail1> <44F4E579A764584EA9BDFD07D0CA08130777C66C@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081307A42614@tlvmail1> Date: Wed, 25 Jul 2012 16:21:50 -0700 X-Google-Sender-Auth: KwCLyyqdX5sjdMMLPouN57uczRk Message-ID: From: Bill Fenner To: Daniel Cohn Content-Type: multipart/alternative; boundary=e89a8f83a1635655bc04c5afbe55 X-Gm-Message-State: ALoCoQm3yMHZ1jG7ftCiQfDoHmMp0wPRS0jGUD1oq0Bhf37+/gYnUL+BPRahgqDeKuSCl7x7sz8t Cc: Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] BGP MIBv2 implementation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 23:21:53 -0000 --e89a8f83a1635655bc04c5afbe55 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Jul 22, 2012 at 6:53 AM, Daniel Cohn wrote: > Hi Bill and all, please see inline with [DC].**** > > ** ** > > *From:* fenner@fenron.com [mailto:fenner@fenron.com] *On Behalf Of *Bill > Fenner > *Sent:* Tuesday, July 17, 2012 9:59 PM > *To:* Daniel Cohn > *Cc:* Jeffrey Haas; idr@ietf.org > *Subject:* Re: [Idr] BGP MIBv2 implementation**** > > ** ** > > On Wed, Apr 25, 2012 at 8:44 AM, Daniel Cohn wrote:*= * > ** > > Hi Jeff and all,**** > > **** > > Sorry for the delayed response. I think it would be a shame to go through > the hassle of updating the BGP MIB without fully supporting BGP L3VPN/VPL= S > (in both RFC 4761 and 6074 flavors). Therefore I support using a generic > NLRI prefix TC that explicitly supports these NLRIs and can be extended t= o > support future BGP applications. It doesn=92t seem consistent to add AFI/= SAFI > to the MIB while leaving the NLRI as an IP address.**** > > **** > > A couple more suggestions for this draft:**** > > **** > > - Change the bgp4V2AdjRibsOutTable index to make it the same as > in bgp4V2NlriTable. In its current form (a pointer to the bgp4V2NlriTable= ), > it doesn=92t support BGP routes originated by this speaker (e.g. > redistributed from IGP) so it=92s woefully inadequate.**** > > I had a similar thought about the Adj-RIBS-Out table - it can't represent > a locally-originated route. I am not sure what you mean by changing the > index to address this, however, since the index as it is makes sense to m= e. > **** > > ** ** > > Maybe you mean to change the structure of the table to copy all of the > data from the NlriTable, which I disagree with.**** > > ** ** > > [DC] You=92re right, that=92s what I meant. My bad. **** > > ** ** > > One idea on handling this with the current structure is to use the pointe= r > to point to a row in the IP-FORWARDING-MIB for a locally-originated route= . > **** > > ** ** > > [DC] I don=92t think that would work, as there is plenty of BGP-specific > information that is not available at the IP forwarding MIB, such as MED, > LOCAL_PREF, or ext communities (actually all the information currently > indexed by bgpM2PathAttrIndex).**** > > What is the problem with expanding the table to include all required BGP > information? If your concern is memory utilization, at the risk of statin= g > the obvious let me say that MIB structure doesn=92t necessarily prescribe= the > internal database structure, meaning you can always choose a more efficie= nt > internal structure (e.g. using pointers instead of storing duplicate > information) and translate the SNMP queries from/to the MIB structure. > Of course the SNMP structure is not necessarily at all related to the internal data structures. My understanding is that the reason for the Rib-OUT table using RowPointer was the [not that well-founded, but still widespread] concern about the amount of data returned in a full MIB walk. (Also, it does concretely reduce the amount of data you need to process if you're a management system that wants to know all of the RIB-IN plus RIB-OUTs.) What about representing locally-advertised routes as being received from a peer of type unknown, with zero length address? > **** > > - Add support for BGP communities (as in your communities draft) > in the NLRI in/out tables.**** > > There is no reason this can't be a future addition, right, in the interes= t > of getting the base functionality out?**** > > ** ** > > [DC] Why should this simple addition hold back progress? > It was removed in 2007 because of a lack of consensus about including it. Is your sense that that lack of consensus has changed? > - Restore local address (and maybe ports) to bgp4V2PeerTable > index to support multiple BGP sessions between two speakers as in > draft-ietf-grow-diverse-bgp-path-dist**** > > If the ports are in the INDEX, how do you ever find a row if one of the > ports is guaranteed to be ephemeral and you don't know a priori who > originated the connection?**** > > ** ** > > If the remote address was first in the INDEX, you could always use getnex= t > to get a given value independent of the local address, but that's not a > concept that many management systems are familiar with.**** > > ** ** > > An idea that solves both the ports and the unknown-local-address problem > is to use the remote address and an instance identifier. Peers with a > single connection (the "normal" case) would be only instance 1, but if yo= u > had multiple simultaneous connections to the same remote peer you could u= se > more values.**** > > ** ** > > [DC] I don=92t see a problem with using getnext, but a neutral instance i= s > also acceptable. > The problem with using getnext is that so many management systems are "MRTG-like" in that they can graph arbitrary objects if you give them the whole OID, but can only use GET to do so. You may say that people shouldn't use such management systems, but if there's a straightforward way to accomodate them then why not? Bill **** > > Feedback is welcome, regards,**** > > **** > > Daniel**** > > **** > > *From:* Jeffrey Haas [mailto:jhaas@pfrc.orgnet] > *Sent:* Thu, 15 Mar 2012 14:19:17 > *Subject:* Re: [Idr] IETF 83 - BGP MIBv2 Update - prefix Textual > Conventions**** > > **** > > Working Group,**** > > **** > > As per prior plenary discussion on making more effect use of working grou= p > **** > > session time, please find my BGP MIBv2 update slides on the proceedings**= * > * > > page:**** > > **** > > http://www.ietf.org/proceedings/83/slides/slides-83-idr-0.pdf**** > > **** > > The bulk of the presentation is self explanatory. I'd like to thank **** > > Bert Wijnen for additional MIB feedback. I suspect we'll get a bit more= * > *** > > feedback from him since he discovered bugs as part of doing derivative wo= rk > **** > > for the SIDR MIB. Draft -13 [1] reflects his comments as of the IETF 83*= * > ** > > posting cutoff.**** > > **** > > One item I would like to draw the working group's further attention to is= * > *** > > covered on slides 5-7. As part of analyzing the requirements for the**** > > multicast next-gen VPN [2] MIBs that Jeffrey Zhang (zzhang at juniper.net= ) > is**** > > working on, we briefly considered exposing MVPN routing state in BGP via > the**** > > BGP MIBv2. Per prior presentations and discussions on design goals for t= he > **** > > BGP MIBv2, we wanted one MIB that was capable of being re-used for variou= s > **** > > types of reachability that was being carried in BGP. However, the primar= y > **** > > goal was to be able to carry IPv6 reachability.**** > > **** > > RFC 6514 can be briefly examined to see the different types of reachabili= ty > **** > > that are being passed around in BGP. The reachability is distinguished**= * > * > > within the same AFI/SAFI by a "Route Type" field within the prefix with > type**** > > specific encodings following. **** > > **** > > The BGP MIBv2 presents prefixes using the following two objects:**** > > bgp4V2NlriPrefixType OBJECT-TYPE**** > > SYNTAX InetAddressType**** > > MAX-ACCESS not-accessible**** > > STATUS current**** > > DESCRIPTION**** > > "The type of the IP address prefix in the**** > > Network Layer Reachability Information field.**** > > The value of this object is derived from the**** > > appropriate value from the bgp4V2NlriAfi field.**** > > Where an appropriate InetAddressType is not**** > > available, the value of the object must be**** > > unknown(0)."**** > > ::=3D { bgp4V2NlriEntry 4 }**** > > **** > > bgp4V2NlriPrefix OBJECT-TYPE**** > > SYNTAX InetAddress**** > > MAX-ACCESS not-accessible**** > > STATUS current**** > > DESCRIPTION**** > > "An IP address prefix in the Network Layer**** > > Reachability Information field. This object**** > > is an IP address containing the prefix with**** > > length specified by bgp4V2NlriPrefixLen.**** > > Any bits beyond the length specified by**** > > bgp4V2NlriPrefixLen are zeroed.**** > > **** > > An implementation is required to support IPv4**** > > prefixes. In this case, the object length**** > > is (0..4).**** > > **** > > An implementation MAY support IPv6 prefixes.**** > > In this case, the object length is (0..16)"**** > > REFERENCE**** > > "RFC 4271, Section 4.3."**** > > ::=3D { bgp4V2NlriEntry 5 }**** > > **** > > The general goal of the "InetAddressType/InetAddress" textual conventions > [3]**** > > is to provide a level of generality for MIB objects that are "addresses".= * > *** > > Our initial design guidance for the BGP MIBv2 was to make use of these TC= s > **** > > to help represent both IPv4 and IPv6 addresses - and it does this well.**= * > * > > **** > > As part of investigating encoding MVPN prefixes in the BGP MIBv2, I sent*= * > ** > > mail to the ietfmibs mailing list to discuss this possibility. After a f= ew > **** > > exchanges, it was suggested that since the information is BGP specific th= at > **** > > this was not the best fit for the INET-ADDRESS-MIB and that we should**** > > consider a BGP TC specifically for this purpose.**** > > **** > > If we were to consider such a TC, we would make it "IANA maintained". Th= is > **** > > would permit us to issue the initial MIB but permit IANA to maintain the*= * > ** > > code points as new protocol elements are added. I.e. we don't have to ha= ve > **** > > a MIB document stuck as an I-D forever. The current INET-ADDRESS-MIB is*= * > ** > > an example of such a MIB.**** > > **** > > After further discussion with Jeffrey Zhang, we determined that there > wasn't**** > > a strong incentive to continue the MVPN MIB work as a BGP MIBv2 extension= , > **** > > We may see future requirements from other BGP-based address families. **= * > * > > **** > > My recommendation would be that we proceed with the work to create a BGP*= * > ** > > Prefix TC MIB with an explicit goal of being backward compatible with the= * > *** > > INET-ADDRESS-MIB. However, the WG may also come to the decision to not**= * > * > > pursue making this MIB completely general purpose and just worry about***= * > > IPv4/IPv6.**** > > **** > > With regard to standards advancement, the new BGP Prefix MIB shouldn't***= * > > unnecessarily hinder the BGP MIBv2.**** > > **** > > I would like the WG to come to some consensus as to whether we (very > likely,**** > > I) take on the work to make such a prefix TC MIB.**** > > **** > > If the discussion becomes interesting enough, Sue and John have agreed to= * > *** > > grant us discussion time at the upcoming IDR session in Paris.**** > > **** > > -- Jeff**** > > **** > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr**** > > ** ** > --e89a8f83a1635655bc04c5afbe55 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 22, 2012 at 6:53 AM, Daniel Cohn <= DanielC@orckit.com> wrote:

Hi Bill and all, please see inline with [DC]= .

=A0<= /p>

From: fenner@fenron.com [mail= to:fenner@fenron.com= ] On Behalf Of Bill Fenner
Sent: Tuesday, July 17, 2012 9:59 PM
To: Daniel Cohn
Cc: Jeffrey Haas; id= r@ietf.org
Subject: Re: [Idr] BGP MIBv2 implementation=

=A0

On Wed, Apr 25, 2012 at 8:44 AM, Daniel Cohn <DanielC@orckit.com> wrote:<= /u>

Hi Jeff and all= ,

=A0

Sorry for the delayed res= ponse. I think it would be a shame to go through the hassle of updating the= BGP MIB without fully supporting BGP L3VPN/VPLS (in both RFC 4761 and 6074= flavors). Therefore I support using a generic NLRI prefix TC that explicit= ly supports these NLRIs and can be extended to support future BGP applicati= ons. It doesn=92t seem consistent to add AFI/SAFI to the MIB while leaving = the NLRI as an IP address.

=A0<= /p>

A couple more suggesti= ons for this draft:

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 C= hange the bgp4V2AdjRibsOutTable index to make it the same as in bgp4V2NlriT= able. In its current form (a pointer to the bgp4V2NlriTable), it doesn=92t = support BGP routes originated by this speaker (e.g. redistributed from IGP)= so it=92s woefully inadequate.

I had a similar thought = about the Adj-RIBS-Out table - it can't represent a locally-originated = route. =A0I am not sure what you mean by changing the index to address this= , however, since the index as it is makes sense to me.

=A0<= /p>

=A0Maybe you mean to change the structure of the = table to copy all of the data from the NlriTable, which I disagree with.=

=A0<= /p>

[DC] You=92re ri= ght, that=92s what I meant. My bad.

=A0

One idea on handling this with the current structure is = to use the pointer to point to a row in the IP-FORWARDING-MIB for a locally= -originated route.

=A0

[DC] I don=92t think that would work, as there is = plenty of BGP-specific information that is not available at the IP forwardi= ng MIB, such as MED, LOCAL_PREF, or ext communities (actually all the infor= mation currently indexed by bgpM2PathAttrIndex).

What is the problem with = expanding the table to include all required BGP information? If your concer= n is memory utilization, at the risk of stating the obvious let me say that= MIB structure doesn=92t necessarily prescribe the internal database struct= ure, meaning you can always choose a more efficient internal structure (e.g= . using pointers instead of storing duplicate information) and translate th= e SNMP queries from/to the MIB structure.


Of course the SNMP= structure is not necessarily at all related to the internal data structure= s. =A0My understanding is that the reason for the Rib-OUT table using RowPo= inter was the [not that well-founded, but still widespread] concern about t= he amount of data returned in a full MIB walk. =A0(Also, it does concretely= reduce the amount of data you need to process if you're a management s= ystem that wants to know all of the RIB-IN plus RIB-OUTs.)

What about representing locally-advertised routes as be= ing received from a peer of type unknown, with zero length address?
=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Add support for BGP communities (as in your = communities draft) in the NLRI in/out tables.

There is no= reason this can't be a future addition, right, in the interest of gett= ing the base functionality out?

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Restore local address (and maybe ports) to bgp4V2PeerTable index to suppor= t multiple BGP sessions between two speakers as in draft-ietf-grow-diverse-= bgp-path-dist

If the ports are in the INDE= X, how do you ever find a row if one of the ports is guaranteed to be ephem= eral and you don't know a priori who originated the connection?<= u>

=A0

If the remote address was first in the INDEX, you could alwa= ys use getnext to get a given value independent of the local address, but t= hat's not a concept that many management systems are familiar with.<= /u>

=A0

An idea that solves both the ports and the unknown= -local-address problem is to use the remote address and an instance identif= ier. =A0Peers with a single connection (the "normal" case) would = be only instance 1, but if you had multiple simultaneous connections to the= same remote peer you could use more values.

=A0

[DC] I don=92t see a problem with using getnext, b= ut a neutral instance is also acceptable.


The problem with using g= etnext is that so many management systems are "MRTG-like" in that= they can graph arbitrary objects if you give them the whole OID, but can o= nly use GET to do so. =A0You may say that people shouldn't use such man= agement systems, but if there's a straightforward way to accomodate the= m then why not?

=A0 Bill

=A0=

Feedback is welcome, rega= rds,

=A0

Daniel

=A0

From: Jeffrey Haas [mailto:jhaas@pfrc.orgnet]
Sent: Thu, 15 Mar 2012 14:19:17
Subject: Re: [Idr] IETF 8= 3 - BGP MIBv2 Update - prefix Textual Conventions

<= /div>

=A0

Workin= g Group,

=A0<= /p>

As per= prior plenary discussion on making more effect use of working group=

session time, please find my BGP MIBv2 u= pdate slides on the proceedings

page:

=A0<= u>

http://www.ietf.org/proceedings/83/slides= /slides-83-idr-0.pdf

=A0

The bulk of t= he presentation is self explanatory.=A0 I'd like to thank

Bert Wijnen for additional MIB feedback.=A0=A0 I suspect w= e'll get a bit more

feedback f= rom him since he discovered bugs as part of doing derivative work=

for the SIDR MIB.=A0 Draft -13 [1] reflects his comments a= s of the IETF 83

posting cutoff.

=A0

One item I wo= uld like to draw the working group's further attention to is<= /u>

covered on slides 5-7.=A0 As part of analyzing the require= ments for the

multicast next-gen V= PN [2] MIBs that Jeffrey Zhang (zzhang at juniper.net) is

working on, we briefly considered exposing MVPN routing st= ate in BGP via the

BGP MIBv2.=A0 P= er prior presentations and discussions on design goals for the

BGP MIBv2, we wanted one MIB that was capable of being re-= used for various

types of reachabi= lity that was being carried in BGP.=A0 However, the primary

goal was to be able to carry IPv6 reachability.<= /u>

=A0

RFC 6514 can be briefly examined to see the different type= s of reachability

that are being p= assed around in BGP.=A0 The reachability is distinguished<= /u>

within the same AFI/SAFI by a "Route Type" field= within the prefix with type

specif= ic encodings following.=A0

=A0

The BGP MIBv2= presents prefixes using the following two objects:

=A0=A0=A0 bgp4V2NlriPrefixType OBJECT-TYPE

=A0=A0=A0=A0=A0=A0=A0 SYNTAX=A0=A0=A0=A0 InetAddr= essType

=A0=A0=A0=A0=A0=A0=A0 MAX-ACCESS not-accessible<= /u>

=A0=A0=A0=A0=A0=A0=A0 STATUS=A0=A0=A0=A0 cur= rent

=A0=A0=A0=A0=A0=A0=A0 DESCRIPTION

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "The type of the IP= address prefix in the

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Network Layer Reachab= ility Information field.

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 The value of this object is derived from the

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 appropriate value fro= m the bgp4V2NlriAfi field.

<= span style=3D"font-size:10.0pt;font-family:"Courier New"">=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Where an appropriate InetAddressType is not<= /span>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 available, the value = of the object must be

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 unknown(0)."

=A0=A0=A0=A0=A0=A0=A0 ::=3D { bgp4V2NlriEntry 4 }

=A0

=A0=A0=A0 bgp4V2NlriPrefix OBJECT-TYPE

=A0=A0=A0=A0=A0=A0=A0 SYNTAX=A0=A0=A0=A0 InetAddress<= /span>

=A0=A0=A0=A0=A0=A0=A0 MAX-ACCESS not-accessible<= /u>

=A0=A0=A0=A0=A0=A0=A0 STATUS=A0=A0=A0=A0 cur= rent

=A0=A0=A0=A0=A0=A0=A0 DESCRIPTION

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "An IP address pref= ix in the Network Layer

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Reachability Informat= ion field. This object

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 is an IP address containing the prefix with

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 length specified by b= gp4V2NlriPrefixLen.

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Any bits beyond the length specified by<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bgp4V2NlriPrefixLen a= re zeroed.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 An implementation is = required to support IPv4

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 prefixes.=A0 In this case, the object length

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is (0..4).<= /u>

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 An implementation MAY= support IPv6 prefixes.

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 In this case, the object length is (0..16)"= ;

=A0=A0=A0=A0=A0=A0=A0 REFERENCE

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "RFC 4271, Section 4.= 3."

=A0=A0=A0=A0 =A0=A0=A0::=3D { bgp4V2NlriEntry 5 }

=A0

The general goal of the "InetAddressType/InetAddress&= quot; textual conventions [3]

is to = provide a level of generality for MIB objects that are "addresses"= ;.

Our initial design guidance for= the BGP MIBv2 was to make use of these TCs

to help represent both IPv4 and IPv6 addresses - and it do= es this well.

=A0=

As part of investigating encoding MVPN prefixes in the BGP= MIBv2, I sent

mail to the ietfm= ibs mailing list to discuss this possibility.=A0 After a few<= u>

exchanges, it was suggested that since the information is = BGP specific that

this was not the= best fit for the INET-ADDRESS-MIB and that we should<= /p>

consider a BGP TC specifically for this purpose.=

=A0

If we were to consider such a TC, we would make it "I= ANA maintained".=A0 This

woul= d permit us to issue the initial MIB but permit IANA to maintain the=

code points as new protocol elements are added.=A0 I.e. we= don't have to have

a MIB docu= ment stuck as an I-D forever.=A0 The current INET-ADDRESS-MIB is<= /u>

an example of such a MIB.

=A0

After further discussion with Jeffrey Zhang, we determined= that there wasn't

a strong in= centive to continue the MVPN MIB work as a BGP MIBv2 extension,

We may see future requirements from other BGP-based addres= s families.=A0

=A0=

My recommendation would be that we proceed with the work t= o create a BGP

Prefix TC MIB wit= h an explicit goal of being backward compatible with the

INET-ADDRESS-MIB.=A0 However, the WG may also come to the = decision to not

pursue making thi= s MIB completely general purpose and just worry about<= /p>

IPv4/IPv6.

= =A0

With regard to standards advancement, the new BGP Prefix M= IB shouldn't

unnecessarily hin= der the BGP MIBv2.

=A0

I would like = the WG to come to some consensus as to whether we (very likely,

I) take on the work to make such a prefix TC MIB.

=A0

If the discussion becomes interesting enough, Sue and John= have agreed to

grant us discussi= on time at the upcoming IDR session in Paris.

=A0

-- Jeff

=A0


__________________________________________= _____
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

=A0


--e89a8f83a1635655bc04c5afbe55-- From adam.simpson@alcatel-lucent.com Thu Jul 26 09:19:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800DF21F8629 for ; Thu, 26 Jul 2012 09:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.562 X-Spam-Level: X-Spam-Status: No, score=-7.562 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00eS-FNbVFCu for ; Thu, 26 Jul 2012 09:19:36 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5926221F85BB for ; Thu, 26 Jul 2012 09:19:36 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q6QGJZmj003941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Jul 2012 11:19:35 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6QGJYAH012589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 26 Jul 2012 11:19:35 -0500 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.146]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 26 Jul 2012 11:19:34 -0500 From: "Simpson, Adam (Adam)" To: "idr@ietf.org" Date: Thu, 26 Jul 2012 11:19:33 -0500 Thread-Topic: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt Thread-Index: Ac1jX/N3TaIM97JURF2iIHSH6GdLRAH6g1Yw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 16:19:38 -0000 VGhpcyBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gd2FzIHBvc3RlZCBsYXN0IHdlZWsgYW5kIHdpbGwg YmUgcHJlc2VudGVkIGF0IHRoZSBJRFIgbWVldGluZyBuZXh0IHdlZWsuIEFueSBmZWVkYmFjayB5 b3UgaGF2ZSBiZWZvcmUgb3IgYWZ0ZXIgdGhlIG1lZXRpbmcgd291bGQgYmUgd2VsY29tZS4NCg0K VGhhbmtzLA0KQWRhbQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K U2VudDogTW9uZGF5LCBKdWx5IDE2LCAyMDEyIDEwOjMzIEFNDQpUbzogU2ltcHNvbiwgQWRhbSAo QWRhbSkNCkNjOiBtdGV4aWVyQGFyYm9yLm5ldDsgcG1vaGFwYXRAY2lzY28uY29tOyBkanNtaXRo QGNpc2NvLmNvbTsgSGVuZGVyaWNreCwgV2ltIChXaW0pDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXNpbXBzb24taWRyLWZsb3dzcGVjLXJlZGlyZWN0LTAxLnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zaW1wc29uLWlkci1mbG93c3BlYy1y ZWRpcmVjdC0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWRhbSBT aW1wc29uIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkg ZHJhZnQtc2ltcHNvbi1pZHItZmxvd3NwZWMtcmVkaXJlY3QNClJldmlzaW9uOgkgMDENClRpdGxl OgkJIEJHUCBGbG93LVNwZWMgRXh0ZW5kZWQgQ29tbXVuaXR5IGZvciBUcmFmZmljIFJlZGlyZWN0 IHRvIElQIE5leHQgSG9wDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wNy0xNg0KV0cgSUQ6CQkgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDcNClVSTDogICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2ltcHNvbi1pZHItZmxv d3NwZWMtcmVkaXJlY3QtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtc2ltcHNvbi1pZHItZmxvd3NwZWMtcmVkaXJlY3QNCkh0bWxp emVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2ltcHNvbi1pZHIt Zmxvd3NwZWMtcmVkaXJlY3QtMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zaW1wc29uLWlkci1mbG93c3BlYy1yZWRpcmVjdC0wMQ0K DQpBYnN0cmFjdDoNCiAgIEZsb3ctc3BlYyBpcyBhbiBleHRlbnNpb24gdG8gQkdQIHRoYXQgYWxs b3dzIGZvciB0aGUgZGlzc2VtaW5hdGlvbiBvZg0KICAgdHJhZmZpYyBmbG93IHNwZWNpZmljYXRp b24gcnVsZXMuIFRoaXMgaGFzIG1hbnkgcG9zc2libGUgYXBwbGljYXRpb25zDQogICBidXQgdGhl IHByaW1hcnkgb25lIGZvciBtYW55IG5ldHdvcmsgb3BlcmF0b3JzIGlzIHRoZSBkaXN0cmlidXRp b24gb2YNCiAgIHRyYWZmaWMgZmlsdGVyaW5nIGFjdGlvbnMgZm9yIEREb1MgbWl0aWdhdGlvbi4g VGhlIGZsb3ctc3BlYyBzdGFuZGFyZA0KICAgW1JGQyA1NTc1XSBkZWZpbmVzIGEgcmVkaXJlY3Qt dG8tVlJGIGFjdGlvbiBmb3IgcG9saWN5LWJhc2VkDQogICBmb3J3YXJkaW5nIGJ1dCB0aGlzIG1l Y2hhbmlzbSBjYW4gYmUgZGlmZmljdWx0IHRvIHVzZSwgcGFydGljdWxhcmx5DQogICBpbiBuZXR3 b3JrcyB3aXRob3V0IEwzIFZQTnMuDQoNCiAgIFRoaXMgZHJhZnQgcHJvcG9zZXMgYSBuZXcgcmVk aXJlY3QtdG8tSVAgZmxvdy1zcGVjIGFjdGlvbiB0aGF0DQogICBwcm92aWRlcyBhIHNpbXBsZXIg bWV0aG9kIG9mIHBvbGljeS1iYXNlZCBmb3J3YXJkaW5nLiBUaGlzIGFjdGlvbiBpcw0KICAgaW5k aWNhdGVkIGJ5IHRoZSBwcmVzZW5jZSBvZiBhIG5ldyBCR1AgZXh0ZW5kZWQgY29tbXVuaXR5IGlu IHRoZQ0KICAgZmxvdy1zcGVjIHJvdXRlLiBNYW55IHJvdXRlcnMgYWxyZWFkeSBzdXBwb3J0IGEg cmVkaXJlY3QtdG8tSVAgZmlsdGVyDQogICBhY3Rpb24gYW5kLCBpbiB0aGlzIGNhc2UsIHRoZSBv bmx5IG5ldyBmdW5jdGlvbmFsaXR5IGltcGxpZWQgYnkgdGhpcw0KICAgZHJhZnQgaXMgdGhlIGFi aWxpdHkgdG8gc2lnbmFsIHRoZSBhY3Rpb24gdXNpbmcgZmxvdy1zcGVjLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From robert@raszuk.net Thu Jul 26 09:40:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC3021F850B for ; Thu, 26 Jul 2012 09:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWdoNAcv7Lg2 for ; Thu, 26 Jul 2012 09:40:20 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B30E721F8504 for ; Thu, 26 Jul 2012 09:40:19 -0700 (PDT) Received: (qmail 3604 invoked by uid 399); 26 Jul 2012 16:40:18 -0000 Received: from unknown (HELO ?10.0.1.2?) (pbs:robert@raszuk.net@72.254.55.53) by mail1310.opentransfer.com with ESMTPM; 26 Jul 2012 16:40:18 -0000 X-Originating-IP: 72.254.55.53 Message-ID: <501172F3.2080400@raszuk.net> Date: Thu, 26 Jul 2012 18:40:19 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Simpson, Adam (Adam)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 16:40:21 -0000 Hi Adam, While we are at such extension how about we would also define in this document one more extended community value which would allow in addition to "redirect-to-ip", also "mirror-to-ip" action ? Of course both would be mutually exclusive. Thx, R. > This individual submission was posted last week and will be presented at the IDR meeting next week. Any feedback you have before or after the meeting would be welcome. > > Thanks, > Adam From robert@raszuk.net Thu Jul 26 10:15:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE9921F85CD for ; Thu, 26 Jul 2012 10:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1Yy4B8b5a2i for ; Thu, 26 Jul 2012 10:15:34 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id C55BA21F85C2 for ; Thu, 26 Jul 2012 10:15:33 -0700 (PDT) Received: (qmail 22876 invoked by uid 399); 26 Jul 2012 17:15:33 -0000 Received: from unknown (HELO ?10.0.1.2?) (pbs:robert@raszuk.net@72.254.55.53) by mail1310.opentransfer.com with ESMTPM; 26 Jul 2012 17:15:33 -0000 X-Originating-IP: 72.254.55.53 Message-ID: <50117B35.2020504@raszuk.net> Date: Thu, 26 Jul 2012 19:15:33 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Simpson, Adam (Adam)" References: <501172F3.2080400@raszuk.net> In-Reply-To: <501172F3.2080400@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 17:15:34 -0000 Let me expand a bit .... Actually the original "redirect-to-vrf" flowspec action also addressed the issue of forwarding via flow-spec unaware core via any form of tunneling enabled under given vrf instance. Since here the default would be to relay on global forwarding table of the router the same flow spec rules must be understood and executed hop by hop. In order to simplify deployment aspect it seems recommended to also within each of the community define few bits to indicate optional encapsulation of redirected or mirror flows. 0000 - native 0001 - NH is GRE tunnel destination 0002 - NH is L2TPv3 tunnel destination etc ... Best regards, R. > Hi Adam, > > While we are at such extension how about we would also define in this > document one more extended community value which would allow in addition > to "redirect-to-ip", also "mirror-to-ip" action ? > > Of course both would be mutually exclusive. > > Thx, > R. > >> This individual submission was posted last week and will be presented >> at the IDR meeting next week. Any feedback you have before or after >> the meeting would be welcome. >> >> Thanks, >> Adam > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From wim.henderickx@alcatel-lucent.com Thu Jul 26 10:39:07 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010D821F8601 for ; Thu, 26 Jul 2012 10:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.689 X-Spam-Level: X-Spam-Status: No, score=-9.689 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWwJVK1cO0Rr for ; Thu, 26 Jul 2012 10:39:06 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id CC4B821F8616 for ; Thu, 26 Jul 2012 10:39:05 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6QHd3Gi012166 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Jul 2012 19:39:04 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 26 Jul 2012 19:39:03 +0200 From: "Henderickx, Wim (Wim)" To: "robert@raszuk.net" , "Simpson, Adam (Adam)" Date: Thu, 26 Jul 2012 19:39:01 +0200 Thread-Topic: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt Thread-Index: Ac1rUk3aX8HzjRi/QL6DqZaaaWXYOgAAwq+g Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702E16333B5@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <501172F3.2080400@raszuk.net> <50117B35.2020504@raszuk.net> In-Reply-To: <50117B35.2020504@raszuk.net> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 17:39:07 -0000 Robert, why do you want to do this explicitly and not implicitly? We are as= suming the tunnels can be of any kind and the NH resolves to whatever the r= outing protocols have given us. Meaning if the NH is resolved to native or = GRE or L2TPv3 we don't care. Do you see a reason to constraint this? -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: donderdag 26 juli 2012 19:16 To: Simpson, Adam (Adam) Cc: idr@ietf.org Subject: Re: [Idr] FW: New Version Notification for draft-simpson-idr-flows= pec-redirect-01.txt Let me expand a bit .... Actually the original "redirect-to-vrf" flowspec action also addressed=20 the issue of forwarding via flow-spec unaware core via any form of=20 tunneling enabled under given vrf instance. Since here the default would be to relay on global forwarding table of=20 the router the same flow spec rules must be understood and executed hop=20 by hop. In order to simplify deployment aspect it seems recommended to also=20 within each of the community define few bits to indicate optional=20 encapsulation of redirected or mirror flows. 0000 - native 0001 - NH is GRE tunnel destination 0002 - NH is L2TPv3 tunnel destination etc ... Best regards, R. > Hi Adam, > > While we are at such extension how about we would also define in this > document one more extended community value which would allow in addition > to "redirect-to-ip", also "mirror-to-ip" action ? > > Of course both would be mutually exclusive. > > Thx, > R. > >> This individual submission was posted last week and will be presented >> at the IDR meeting next week. Any feedback you have before or after >> the meeting would be welcome. >> >> Thanks, >> Adam > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Thu Jul 26 11:01:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA1921F861B for ; Thu, 26 Jul 2012 11:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoaeKMqJaOl0 for ; Thu, 26 Jul 2012 11:01:35 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33621F8611 for ; Thu, 26 Jul 2012 11:01:35 -0700 (PDT) Received: (qmail 17771 invoked by uid 399); 26 Jul 2012 18:01:34 -0000 Received: from unknown (HELO ?216.69.69.254?) (pbs:robert@raszuk.net@216.69.69.254) by mail1310.opentransfer.com with ESMTPM; 26 Jul 2012 18:01:34 -0000 X-Originating-IP: 216.69.69.254 Message-ID: <501185FB.2020206@raszuk.net> Date: Thu, 26 Jul 2012 20:01:31 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Henderickx, Wim (Wim)" References: <501172F3.2080400@raszuk.net> <50117B35.2020504@raszuk.net> <14C7F4F06DB5814AB0DE29716C4F6D6702E16333B5@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702E16333B5@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 18:01:36 -0000 Hi Wim, Actually I do. Routing protocols do not provide the encapsulation destination today. So you would need to configure it as recursive static route on each ingress router. Today you are always (for example in BGP) signalling your encap endpoint explicitly. If we signal it within the flow-spec SAFI there is much less overhead and much less room for operational mistakes. Also when we use the NH as tunnel-to address there should be no next hop self on the flowspec route at the EBGP boundary. Regards, R. > Robert, why do you want to do this explicitly and not implicitly? We > are assuming the tunnels can be of any kind and the NH resolves to > whatever the routing protocols have given us. Meaning if the NH is > resolved to native or GRE or L2TPv3 we don't care. Do you see a > reason to constraint this? > > -----Original Message----- From: idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: > donderdag 26 juli 2012 19:16 To: Simpson, Adam (Adam) Cc: > idr@ietf.org Subject: Re: [Idr] FW: New Version Notification for > draft-simpson-idr-flowspec-redirect-01.txt > > Let me expand a bit .... > > Actually the original "redirect-to-vrf" flowspec action also > addressed the issue of forwarding via flow-spec unaware core via any > form of tunneling enabled under given vrf instance. > > Since here the default would be to relay on global forwarding table > of the router the same flow spec rules must be understood and > executed hop by hop. > > In order to simplify deployment aspect it seems recommended to also > within each of the community define few bits to indicate optional > encapsulation of redirected or mirror flows. > > 0000 - native 0001 - NH is GRE tunnel destination 0002 - NH is L2TPv3 > tunnel destination etc ... > > Best regards, R. > >> Hi Adam, >> >> While we are at such extension how about we would also define in >> this document one more extended community value which would allow >> in addition to "redirect-to-ip", also "mirror-to-ip" action ? >> >> Of course both would be mutually exclusive. >> >> Thx, R. >> >>> This individual submission was posted last week and will be >>> presented at the IDR meeting next week. Any feedback you have >>> before or after the meeting would be welcome. >>> >>> Thanks, Adam >> >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> >> > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From tnadeau@juniper.net Thu Jul 26 11:06:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9447E21F85F7; Thu, 26 Jul 2012 11:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1Kqd6m-KCHI; Thu, 26 Jul 2012 11:06:42 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id B5BB721F861E; Thu, 26 Jul 2012 11:06:34 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUBGHJN+nS851zOdeAP4iS+xW/auReO3Y@postini.com; Thu, 26 Jul 2012 11:06:41 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Jul 2012 11:05:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 26 Jul 2012 14:05:19 -0400 From: Thomas Nadeau To: "mpls@ietf.org" , "rtgwg@ietf.org" , "pce@ietf.org" , "idr@ietf.org" , "alto@ietf.org" Date: Thu, 26 Jul 2012 14:05:18 -0400 Thread-Topic: Interface to the Internet Routing System (IRS) Discussion List Created Thread-Index: Ac1rWTdkMa/o1HJvQ46cDHHzjaMH4g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wardd@cisco.com" , Alia Atlas Subject: [Idr] Interface to the Internet Routing System (IRS) Discussion List Created X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 18:06:43 -0000 We have created a non-WG mailing list to discuss IRS. The purpose of the list: This list is for the discussion of an interface to the routing system (IRS)= that allows applications to rapidly and dynamically install routing state = into routers, and to learn sufficient information from routers to make time= ly, data-based decisions about what routing state to specify. Such an inter= face would facilitate control and diagnosis of the routing infrastructure, = as well as enabling sophisticated applications to be built on top of today'= s routed networks. The IRS is conceived as a programmatic, streaming inter= face for transferring state into and out of the Internet's routing system, = recognizing that the routing system and a router's OS provide useful mechan= isms that applications could harness to accomplish application-level goals.= A fundamental component of the IRS is a clear data model that defines the= semantics of the information that can be written and read. An initial framework document for IRS is available here: http://www.lucidvision.com/draft-ward-irs-framework-00.txt To subscribe, please visit the following: https://www.ietf.org/mailman/listinfo/irs-discuss From wim.henderickx@alcatel-lucent.com Thu Jul 26 11:39:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FE021F85D1 for ; Thu, 26 Jul 2012 11:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.782 X-Spam-Level: X-Spam-Status: No, score=-7.782 tagged_above=-999 required=5 tests=[AWL=-1.533, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZByX1Q00gZ3 for ; Thu, 26 Jul 2012 11:39:13 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id A75A321F852E for ; Thu, 26 Jul 2012 11:39:12 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6QIdBTF023775 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Jul 2012 20:39:11 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 26 Jul 2012 20:39:11 +0200 From: "Henderickx, Wim (Wim)" To: "robert@raszuk.net" Date: Thu, 26 Jul 2012 20:39:11 +0200 Thread-Topic: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt Thread-Index: Ac1rWLZPJLOaeLQETl2DldghRp5ImwABOutA Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702E16333C9@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <501172F3.2080400@raszuk.net> <50117B35.2020504@raszuk.net> <14C7F4F06DB5814AB0DE29716C4F6D6702E16333B5@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <501185FB.2020206@raszuk.net> In-Reply-To: <501185FB.2020206@raszuk.net> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-simpson-idr-flowspec-redirect-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 18:39:13 -0000 Clear, you want a 1 step process rather than an additional indirection with= additional config/routing exchange. -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: donderdag 26 juli 2012 20:02 To: Henderickx, Wim (Wim) Cc: Simpson, Adam (Adam); idr@ietf.org Subject: Re: [Idr] FW: New Version Notification for draft-simpson-idr-flows= pec-redirect-01.txt Hi Wim, Actually I do. Routing protocols do not provide the encapsulation destination today. So you would need to configure it as recursive static route on each ingress router. Today you are always (for example in BGP)=20 signalling your encap endpoint explicitly. If we signal it within the flow-spec SAFI there is much less overhead=20 and much less room for operational mistakes. Also when we use the NH as tunnel-to address there should be no next hop self on the flowspec route at the EBGP boundary. Regards, R. > Robert, why do you want to do this explicitly and not implicitly? We > are assuming the tunnels can be of any kind and the NH resolves to > whatever the routing protocols have given us. Meaning if the NH is > resolved to native or GRE or L2TPv3 we don't care. Do you see a > reason to constraint this? > > -----Original Message----- From: idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: > donderdag 26 juli 2012 19:16 To: Simpson, Adam (Adam) Cc: > idr@ietf.org Subject: Re: [Idr] FW: New Version Notification for > draft-simpson-idr-flowspec-redirect-01.txt > > Let me expand a bit .... > > Actually the original "redirect-to-vrf" flowspec action also > addressed the issue of forwarding via flow-spec unaware core via any > form of tunneling enabled under given vrf instance. > > Since here the default would be to relay on global forwarding table > of the router the same flow spec rules must be understood and > executed hop by hop. > > In order to simplify deployment aspect it seems recommended to also > within each of the community define few bits to indicate optional > encapsulation of redirected or mirror flows. > > 0000 - native 0001 - NH is GRE tunnel destination 0002 - NH is L2TPv3 > tunnel destination etc ... > > Best regards, R. > >> Hi Adam, >> >> While we are at such extension how about we would also define in >> this document one more extended community value which would allow >> in addition to "redirect-to-ip", also "mirror-to-ip" action ? >> >> Of course both would be mutually exclusive. >> >> Thx, R. >> >>> This individual submission was posted last week and will be >>> presented at the IDR meeting next week. Any feedback you have >>> before or after the meeting would be welcome. >>> >>> Thanks, Adam >> >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> >> > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From jgs@juniper.net Mon Jul 30 09:42:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCB511E80FC for ; Mon, 30 Jul 2012 09:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCL6X44JDha5 for ; Mon, 30 Jul 2012 09:42:42 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0A07D11E80EB for ; Mon, 30 Jul 2012 09:42:41 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUBa5gZniEQfXT+QNJn1LIyzonqDx8aux@postini.com; Mon, 30 Jul 2012 09:42:42 PDT Received: from jgs-sslvpn-nc.jnpr.net (172.23.2.14) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 30 Jul 2012 09:42:16 -0700 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jul 2012 09:42:11 -0700 References: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> To: "idr@ietf.org List" Message-ID: MIME-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Idr] Fwd: Need volunteers for the NomCom X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 16:42:42 -0000 I encourage WG members to consider volunteering for NomCom. --John Begin forwarded message: > From: NomCom Chair > Subject: Need volunteers for the NomCom > Date: July 29, 2012 8:22:33 PM PDT > To: Working Group Chairs >=20 > We are currently looking for volunteers to serve on the 2012-2013 = NomCom. > As you know, the success of the NomCom process depends crucially on=20 > having a large pool of volunteers from throughout the IETF community.=20= > In particular, it is valuable for the pool of volunteers to have = strong=20 > representation from all of the technical areas within the IETF.=20 >=20 > I understand that not all IETF participants read the IETF announce = list=20 > frequently. Therefore, if you would be willing to inform active = participants=20 > in your working groups about this year's call for NomCom volunteers, I=20= > would greatly appreciate it.=20 >=20 > The NomCom 2012-2013 Call for Volunteers is open until this Sunday,=20 > August 5. Details can be found at: = https://datatracker.ietf.org/ann/nomcom/49851/ >=20 > Thank you for your help, > - Matt Lepinski > mlepinski.ietf@gmail.com > nomcom-chair@ietf.org From jgs@juniper.net Mon Jul 30 14:00:16 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D183911E818E for ; Mon, 30 Jul 2012 14:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyYNhSF2joTP for ; Mon, 30 Jul 2012 14:00:03 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 92A3611E81BB for ; Mon, 30 Jul 2012 14:00:02 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUBb1zGgADC6VUhb4S0/fUyUCycVyzVUN@postini.com; Mon, 30 Jul 2012 14:00:02 PDT Received: from jgs-sslvpn-nc.jnpr.net (172.23.2.14) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 30 Jul 2012 13:58:33 -0700 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jul 2012 13:58:33 -0700 Message-ID: To: "idr@ietf.org List" MIME-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:00:16 -0000 Folks, We have received a request from the authors to adopt = draft-gredler-idr-ls-distribution as an IDR WG document. Please send = your comments to the list. The deadline for comments is August 14, 2012 = at noon EDT. Thanks, --John From keyupate@cisco.com Mon Jul 30 14:04:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203F611E81E5 for ; Mon, 30 Jul 2012 14:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEUxC+uvcQBK for ; Mon, 30 Jul 2012 14:04:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9AB11E81D9 for ; Mon, 30 Jul 2012 14:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=479; q=dns/txt; s=iport; t=1343682253; x=1344891853; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=EBKk4b5IwzD5ypjBokcExIK1/SP4UYGJDoTdk9MGnqg=; b=ezyCp6cUH6oBCx1UdPO2EMWGNVSc+GspDw/klui1cNr3NEUKmTSidvmS 33SgvCs2Zb///erEivGXD8XN6tvw9X2BdYKSy+mMunuDIWPMfn+dIi7yz pVs+JI/UYJ61BxyCb8zIMM8YFhfIZCYjgDqfDHpFkHu45OUmo+GQVAxSM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokFAAz2FlCtJXHA/2dsb2JhbABFhS+0KoEHgiIBBAEBAQ8BJzQdAQg2NwslAgQBEiKHawuabKAVBItQhwkDlUmOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,681,1336348800"; d="scan'208";a="106763021" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2012 21:04:12 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6UL4CWb017533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jul 2012 21:04:12 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.33]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 16:04:11 -0500 From: "Keyur Patel (keyupate)" To: "John G. Scudder" , "idr@ietf.org List" Thread-Topic: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document Thread-Index: AQHNbpbdYcXyuixlBEK+tB/fZuWT0A== Date: Mon, 30 Jul 2012 21:04:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.77.117] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.001 x-tm-as-result: No--35.274900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9ACEEC912F811E4F8DFFF63654F203C0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:04:14 -0000 Support. Regards, -Keyur On 7/30/12 1:58 PM, "John G. Scudder" wrote: >Folks, > >We have received a request from the authors to adopt >draft-gredler-idr-ls-distribution as an IDR WG document. Please send your >comments to the list. The deadline for comments is August 14, 2012 at >noon EDT. > >Thanks, > >--John >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Mon Jul 30 14:12:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D9811E8072 for ; Mon, 30 Jul 2012 14:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qdl4mNdigza1 for ; Mon, 30 Jul 2012 14:12:44 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA1721F8564 for ; Mon, 30 Jul 2012 14:12:44 -0700 (PDT) Received: (qmail 25646 invoked by uid 399); 30 Jul 2012 21:12:37 -0000 Received: from unknown (HELO ?130.129.19.9?) (robert@raszuk.net@130.129.19.9) by mail1310.opentransfer.com with ESMTPAM; 30 Jul 2012 21:12:37 -0000 X-Originating-IP: 130.129.19.9 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5C4F0172-7C4B-4515-B531-0D6A40BBCBA2@raszuk.net> X-Mailer: iPad Mail (9B206) From: Robert Raszuk Date: Mon, 30 Jul 2012 14:12:42 -0700 To: "John G. Scudder" Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:12:45 -0000 I support it. Rgs, R. Sent from my iPad On Jul 30, 2012, at 1:58 PM, "John G. Scudder" wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-gredler-idr-ls-= distribution as an IDR WG document. Please send your comments to the list. T= he deadline for comments is August 14, 2012 at noon EDT. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jrmitche@puck.nether.net Mon Jul 30 16:16:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0B311E80D5 for ; Mon, 30 Jul 2012 16:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z17MRKg4TeMc for ; Mon, 30 Jul 2012 16:16:53 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id EB74911E809A for ; Mon, 30 Jul 2012 16:16:52 -0700 (PDT) Received: from [130.129.23.81] (dhcp-1751.meeting.ietf.org [130.129.23.81]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q6UNGpCh009956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Jul 2012 19:16:52 -0400 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <1C7C2CE0-ABA1-4F03-8665-B5515CA09569@puck.nether.net> X-Mailer: iPhone Mail (9B206) From: Jon Mitchell Date: Mon, 30 Jul 2012 16:16:49 -0700 To: "John G. Scudder" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 30 Jul 2012 19:16:52 -0400 (EDT) Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:16:53 -0000 Support. -Jon (from phone) On Jul 30, 2012, at 1:58 PM, "John G. Scudder" wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-gredler-idr-ls-= distribution as an IDR WG document. Please send your comments to the list. T= he deadline for comments is August 14, 2012 at noon EDT. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ss2539@att.com Mon Jul 30 19:10:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DAF11E812D for ; Mon, 30 Jul 2012 19:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzGWQSePwdKO for ; Mon, 30 Jul 2012 19:10:19 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id B697321F852C for ; Mon, 30 Jul 2012 19:10:18 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 78e37105.0.402129.00-371.1102956.nbfkord-smmo04.seg.att.com (envelope-from ); Tue, 31 Jul 2012 02:10:18 +0000 (UTC) X-MXL-Hash: 50173e8a23070017-f107db37822f462144a035a5654a166e4d070713 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6V2AFRe012810; Mon, 30 Jul 2012 19:10:15 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6V2A5Ep012725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 19:10:06 -0700 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by fflint03.pst.cso.att.com (RSA Interceptor); Mon, 30 Jul 2012 19:09:40 -0700 Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 22:09:40 -0400 From: "SAAD, SAMIR S" To: "John G. Scudder" , "idr@ietf.org List" Thread-Topic: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document Thread-Index: AQHNbpZZ+lRLRK7PvUOvNLjXShYMNpdCpWWw Date: Tue, 31 Jul 2012 02:09:39 +0000 Message-ID: <438B11A5EC21D347A63ACB77E58C78BA183B66@MISOUT7MSGUSR9N.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.32.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=ll1CIi-hfRQA:10 a=zH2vM3gVAK4A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=UD8F6EhTtkd0tHiU_DQA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] X-Mailman-Approved-At: Mon, 30 Jul 2012 23:22:02 -0700 Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:10:26 -0000 Support Samir Saad AT&T Labs -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John = G. Scudder Sent: Monday, July 30, 2012 4:59 PM To: idr@ietf.org List Subject: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG docu= ment Folks, We have received a request from the authors to adopt draft-gredler-idr-ls-d= istribution as an IDR WG document. Please send your comments to the list. = The deadline for comments is August 14, 2012 at noon EDT. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From shares@ndzh.com Tue Jul 31 10:07:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AC121F8539 for ; Tue, 31 Jul 2012 10:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDwjNLhW0WeT for ; Tue, 31 Jul 2012 10:07:35 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9E89C21F8463 for ; Tue, 31 Jul 2012 10:07:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=130.129.20.220; Received: from SKH2012HPLT (unverified [130.129.20.220]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3494340-1945496 for multiple; Tue, 31 Jul 2012 13:07:33 -0400 From: "Susan Hares" To: References: <438B11A5EC21D347A63ACB77E58C78BA183B66@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <438B11A5EC21D347A63ACB77E58C78BA183B66@MISOUT7MSGUSR9N.ITServices.sbc.com> Date: Tue, 31 Jul 2012 13:07:32 -0400 Message-ID: <002a01cd6f3e$fa1b6fd0$ee524f70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhe085Se9vT2ltVWVFDDsmOGrr2wJBVy3zl4l8RhA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [Idr] Spam:********, Re: Adoption of draft-gredler-idr-ls-distribution as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:07:36 -0000 To the Authors, Is there IPR on this draft? Sue Hares Co-Chair hat on. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of SAAD, SAMIR S Sent: Monday, July 30, 2012 10:10 PM To: John G. Scudder; idr@ietf.org List Subject: Spam:********, Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document Support Samir Saad AT&T Labs -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Monday, July 30, 2012 4:59 PM To: idr@ietf.org List Subject: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document Folks, We have received a request from the authors to adopt draft-gredler-idr-ls-distribution as an IDR WG document. Please send your comments to the list. The deadline for comments is August 14, 2012 at noon EDT. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From manbhard@cisco.com Tue Jul 31 11:05:50 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B5821F88B9 for ; Tue, 31 Jul 2012 11:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8p4Q0cHWBO5 for ; Tue, 31 Jul 2012 11:05:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCAD21F873A for ; Tue, 31 Jul 2012 11:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=manbhard@cisco.com; l=482; q=dns/txt; s=iport; t=1343757949; x=1344967549; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BmUvYAuu9+4AWbu4uhnBvZ4z7b3rIgR84X2amh7eh4E=; b=WujPjO7AGGSGH5Um8xwTI0Bp0MNDIJ2SUIZnULfEIfkqzc/yEu2lcx2D ID6XOQor38eCDY0QgiPxEN+NwBfGPRJXIuyM76A69PweqJH5z+s/RkNwm oFwm4SsvLqzDIgrhP+thAIxbADOeUhZzFoMUPhcyiwKUYZJSs6aHkA1/M A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAE8dGFCtJV2b/2dsb2JhbABFhTG0SYEHgiIBBAEBAQ8BJzQdAQgiFDcLJgEEARIIGodrC5wCoHaLSYYpYAOWW40TgWaCXw X-IronPort-AV: E=Sophos;i="4.77,688,1336348800"; d="scan'208";a="107104116" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2012 18:05:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6VI5ndg032678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 31 Jul 2012 18:05:49 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.145]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 13:05:49 -0500 From: "Manish Bhardwaj (manbhard)" To: "John G. Scudder\" , \"idr@ietf.org List" Thread-Topic: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document Thread-Index: Ac1vRmDT8CQCWEtjQ/iFWJ0EUzwWNA== Date: Tue, 31 Jul 2012 18:05:49 +0000 Message-ID: <564354767338CC468564734FE0BD0BAF031292@xmb-aln-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.005 x-tm-as-result: No--35.274900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:05:50 -0000 Support. Thanks, -Manish On 7/30/12 1:58 PM, "John G. Scudder" wrote: >Folks, > >We have received a request from the authors to adopt >draft-gredler-idr-ls-distribution as an IDR WG document. Please send your >comments to the list. The deadline for comments is August 14, 2012 at >noon EDT. > >Thanks, > >--John >_______________________________________________ >Idr mailing list >Idr at ietf.org >https://www.ietf.org/mailman/listinfo/idr From jvasseur@cisco.com Tue Jul 31 11:40:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09E211E80A2 for ; Tue, 31 Jul 2012 11:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll6VIvzKSvIZ for ; Tue, 31 Jul 2012 11:40:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2201D11E8098 for ; Tue, 31 Jul 2012 11:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=465; q=dns/txt; s=iport; t=1343760054; x=1344969654; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rWNOAyZmQOsC7YwDlbhXchztp8GEiCXQDBrlpazvlXM=; b=KSrfzujyn3k8E8xWm9tSJVFNtdEeVdfhOehL31S7A91JWfYTU4s6IYwu WvExrsBOevCb80slWCJYckw1XBgIN5x0sQAJjwTAXkMuTiEAw6LuEn3zD 6nF4ngkNChoP9xzOHsjvPqTJez3XsX2j9DwfsVOjzoSOTUuT8mT2V9Vnh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAIwlGFCtJXHB/2dsb2JhbABFhTG0SoEHgiABAQEDAQEBAQ8BJzQLBQsCAQg2ECcLJQIEDgUih2UGC5tyoG4Ei0mGKWADlUeOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,688,1336348800"; d="scan'208";a="107126411" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 31 Jul 2012 18:40:53 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6VIerhg022655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 18:40:53 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.113]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 13:40:52 -0500 From: "JP Vasseur (jvasseur)" To: "John G. Scudder" Thread-Topic: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document Thread-Index: AQHNb0wDZRkbEOplS0K06BnWNlonWA== Date: Tue, 31 Jul 2012 18:40:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.29] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.001 x-tm-as-result: No--36.809400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <3F6439C3B1659245B0BAF09BA583719C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:40:55 -0000 Support. On Jul 30, 2012, at 1:58 PM, John G. Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-gredler-idr-ls= -distribution as an IDR WG document. Please send your comments to the list.= The deadline for comments is August 14, 2012 at noon EDT. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jeff.tantsura@ericsson.com Tue Jul 31 23:20:00 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F8B21F85D8 for ; Tue, 31 Jul 2012 23:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbvXGC87wiQW for ; Tue, 31 Jul 2012 23:20:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCA321F85D0 for ; Tue, 31 Jul 2012 23:19:59 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q716Jwla030306; Wed, 1 Aug 2012 01:19:59 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.160]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 1 Aug 2012 02:19:54 -0400 From: Jeff Tantsura To: "John G. Scudder" Date: Wed, 1 Aug 2012 02:19:52 -0400 Thread-Topic: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document Thread-Index: Ac1uqWuxFLn2jrNJQMK1zepDy8GbOgBBBvOw Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF62676673FA3@EUSAACMS0701.eamcs.ericsson.se> References: <1C7C2CE0-ABA1-4F03-8665-B5515CA09569@puck.nether.net> In-Reply-To: <1C7C2CE0-ABA1-4F03-8665-B5515CA09569@puck.nether.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 06:20:01 -0000 Yes/support Regards, Jeff -----Original Message----- On Jul 30, 2012, at 1:58 PM, "John G. Scudder" wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-gredler-idr-ls= -distribution as an IDR WG document. Please send your comments to the list.= The deadline for comments is August 14, 2012 at noon EDT. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr