From bruno.decraene@orange-ftgroup.com Fri Jul 1 01:29:34 2011 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 3369F21F86BC for ; Fri, 1 Jul 2011 01:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkFG4P+Mwerl for ; Fri, 1 Jul 2011 01:29:32 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 89D2921F86B3 for ; Fri, 1 Jul 2011 01:29:32 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 00996738007; Fri, 1 Jul 2011 10:30:49 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id E7A476C8003; Fri, 1 Jul 2011 10:30:48 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 10:29:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2011 10:29:30 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Fwd: I-D Action: draft-keyur-idr-enhanced-gr-00.txt Thread-Index: Acw2eRRJWAhmePI8S9uK7kMtK6DlbAAsJJrQABH0ws0AE+SPsA== References: From: To: , X-OriginalArrivalTime: 01 Jul 2011 08:29:31.0224 (UTC) FILETIME=[FFD81580:01CC37C8] Cc: idr@ietf.org Subject: Re: [Idr] Fwd: I-D Action: draft-keyur-idr-enhanced-gr-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: Fri, 01 Jul 2011 08:29:34 -0000 Hi Keyur, Thanks for you reply. Please see inline. #Bruno >> 5. Operation >> >> 1) "Once the acknowledgment from a >> peer is not received within the specified upper bound, and the >> maintained state is compromised, then the speaker MUST clear the = "TX >> Routing State" in the GR Capability to be advertised to the peer = in >> the next session restart." >> >> Is there a chance to be able to achieve a resync some time later = within the >> same BGP session? E.g. if latter on we receive an acknowledgement, is = it >> possible to start again sending a new version number & maintaining = the >> required state? If so IMHO it could useful to say so since current = sentence >> could be understood as prohibiting this ("MUST clear the "TX Routing = State" in >> the GR Capability to be advertised to the peer in the next session = restart.") >> > >#Keyur: If the maintained state is compromised (e.g wrt Withdrawals) = then >you want to re-announce complete BGP table. #Bruno: I agree with you in the following use case "1": T0: version 1 sent & acked T1: v2 sent (ack not received) T2: states upper bound reached T3: OPEN, GR, "TX routing Sate" cleared But would the following use case "2" be possible: T0: version 1 sent & acked T1: v2 sent (ack not received) T2: states upper bound reached T3: v2 ack received. T4: version 3 sent & acked T5: OPEN, GR, "TX routing Sate" _set_ ? i.e. during T2-T4 TX routing states are lost. Following T4, TX routing = states are valid and hence in the GR capability "TX routing Sate" can be = _set_ >> 2) " During the lifetime of an established session, if needed, a BGP >> speaker MAY use the UPDATE-VERSION message to request updates from >> the last update version that was previously acknowledged as long = as >> the speaker has received the Enhanced GR Capability from its peer. >> >> When a BGP speaker receives such a request, it SHALL try to send >> routing information from the last acknowledged update version that >> the speaker has recorded. If the speaker is unable to do so for = some >> reason (e.g., "slow peer"), then it SHOULD perform a route refresh >> using mechanism defined in [EH-RR] if possible. Otherwise, the = BGP >> speaker SHOULD reset the session." >> >> - I would propose to add the following example as reason for not = being able to >> send the routes "did not maintained required states") >> - By "reset the session" do you mean sending a NOTIFICATION or = initiating an >> OPEN with GR enabled? (I understand the former, why not = using/allowing the >> latter?) > >#Keyur: Notifications are fine as well as long as you have them on GR >(draft-keyupate-idr-bgp-gr-extension). #Bruno: Agreed. Yet, although I support draft-keyupate-idr-bgp-gr-extension, in the = context of this document, we can assume that GR is enabled on that BGP = session. We can't for draft-keyupate-idr-bgp-gr-extension. >In any case we can provide a bit more clarification in the next rev. Thanks, Regards, Bruno >Regards, >Keyur >> >> Thanks >> Regards, >> Bruno >> >> --------------- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Enke >> Chen >> Sent: Wednesday, June 29, 2011 6:26 PM >> To: idr@ietf.org >> Cc: Keyur Patel >> Subject: [Idr] Fwd: I-D Action: draft-keyur-idr-enhanced-gr-00.txt >> >> FYI.=A0 Will appreciate your comments. >> >> Regards,=A0=A0 -- Enke >> >> -------- Original Message -------- >> Subject: >> I-D Action: draft-keyur-idr-enhanced-gr-00.txt >> Date: >> Wed, 29 Jun 2011 09:21:21 -0700 >> From: >> internet-drafts@ietf.org >> Reply-To: >> internet-drafts@ietf.org >> To: >> i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Accelerated Routing Convergence for BGP Graceful = Restart >> Author(s) : Keyur Patel >> Enke Chen >> Rex Fernando >> John Scudder >> Filename : draft-keyur-idr-enhanced-gr-00.txt >> Pages : 9 >> Date : 2011-06-29 >> >> In this document we specify extensions to BGP graceful restart in >> order to avoid unnecessary transmission of the routing information >> preserved across a session restart, thus accelerating the routing >> convergence. >> >> >> >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-keyur-idr-enhanced-gr-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-keyur-idr-enhanced-gr-00.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From shane@castlepoint.net Fri Jul 1 07:17:06 2011 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 0C72511E8270 for ; Fri, 1 Jul 2011 07:17:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW4RjcEV5auk for ; Fri, 1 Jul 2011 07:17:05 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7D14D11E8104 for ; Fri, 1 Jul 2011 07:17:05 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 088FD268037; Fri, 1 Jul 2011 08:17:05 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 01 Jul 2011 08:17:04 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=56469; syn-fingerprint=65535:54:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Shane Amante In-Reply-To: <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> Date: Fri, 1 Jul 2011 08:16:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24646CE17826CF4A8DF71F9856C7E65659240FE36F@GVW1338EXA.americas.hpqcorp.net> <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" , "Russ White \(russwh\)" Subject: Re: [Idr] Adoption of "BGP Custom Decision" as 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: Fri, 01 Jul 2011 14:17:06 -0000 John, On Jun 30, 2011, at 3:12 PM, John Scudder wrote: > Folks, >=20 > There was reasonable support for this proposal at the IETF-80 meeting = (http://www.ietf.org/proceedings/80/minutes/idr.txt), but there has been = no follow-up on the list. If you have any comments regarding WG = adoption of the document, please send them by Friday, July 8. I've read the doc and support it's adoption as a WG doc. -shane > Thanks, >=20 > --John >=20 > On May 9, 2011, at 3:53 PM, Retana, Alvaro wrote: >=20 >> Hi! >>=20 >> Following up on the meeting in Prague=85 >>=20 >> http://tools.ietf.org/html/draft-retana-bgp-custom-decision >>=20 >> We just published version -02. The only change from -01 is an update = on the authors=92 contact information. >>=20 >> As discussed during the meeting, this is the formal request for = adoption of this draft as a WG document. >>=20 >> The intended status is Standards Track. >>=20 >> Thoughts/comments? >>=20 >> Thanks! >>=20 >> Alvaro. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From mohan.nanduri@gmail.com Fri Jul 1 07:32:58 2011 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 E904311E8097 for ; Fri, 1 Jul 2011 07:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shJ-wRAY3a3p for ; Fri, 1 Jul 2011 07:32:58 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 086601F0C37 for ; Fri, 1 Jul 2011 07:32:57 -0700 (PDT) Received: by iwn39 with SMTP id 39so3592376iwn.31 for ; Fri, 01 Jul 2011 07:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1CqeRzXG2Y/56tCilkcbbpePVYG37ZkYV0BypjYhSCE=; b=C3agVCGEJ6g7qLNEzb90QLpIDCg1HpduupPDzQ5+YG9CR9AS5DYLSyNhkdv4ozr8AT XvXv01TFPJ5IZAr6jnOGVg2aKI7QsLdJcXTsJVSsx8ITar+3ZmAhxYAIw+W+q3mWFb0K sv22am2HBnvqhol2VSRwxfnTRAWt+wIbTtfiE= MIME-Version: 1.0 Received: by 10.42.141.4 with SMTP id m4mr3570514icu.90.1309530776800; Fri, 01 Jul 2011 07:32:56 -0700 (PDT) Received: by 10.42.170.8 with HTTP; Fri, 1 Jul 2011 07:32:56 -0700 (PDT) In-Reply-To: <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> References: <24646CE17826CF4A8DF71F9856C7E65659240FE36F@GVW1338EXA.americas.hpqcorp.net> <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> Date: Fri, 1 Jul 2011 10:32:56 -0400 Message-ID: From: Mohan Nanduri To: John Scudder Content-Type: multipart/alternative; boundary=90e6ba61383ac60d6b04a702e47d Cc: "idr@ietf.org List" , "Russ White \(russwh\)" Subject: Re: [Idr] Adoption of "BGP Custom Decision" as 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: Fri, 01 Jul 2011 14:32:59 -0000 --90e6ba61383ac60d6b04a702e47d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Support it's adoption as a WG doc. Cheers, -Mohan On Thu, Jun 30, 2011 at 5:12 PM, John Scudder wrote: > Folks, > > There was reasonable support for this proposal at the IETF-80 meeting ( > http://www.ietf.org/proceedings/80/minutes/idr.txt), but there has been n= o > follow-up on the list. If you have any comments regarding WG adoption of > the document, please send them by Friday, July 8. > > Thanks, > > --John > > On May 9, 2011, at 3:53 PM, Retana, Alvaro wrote: > > > Hi! > > > > Following up on the meeting in Prague=85 > > > > http://tools.ietf.org/html/draft-retana-bgp-custom-decision > > > > We just published version -02. The only change from -01 is an update o= n > the authors=92 contact information. > > > > As discussed during the meeting, this is the formal request for adoptio= n > of this draft as a WG document. > > > > The intended status is Standards Track. > > > > Thoughts/comments? > > > > Thanks! > > > > Alvaro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --90e6ba61383ac60d6b04a702e47d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Support it's adoption as a WG doc.

Cheers,
-Mohan


=
On Thu, Jun 30, 2011 at 5:12 PM, John Scudder <jgs@juniper.net&= gt; wrote:
Folks,

There was reasonable support for this proposal at the IETF-80 meeting (http://www.ietf.org/proceedings/80/minutes/idr.txt), but there has be= en no follow-up on the list. =A0If you have any comments regarding WG adopt= ion of the document, please send them by Friday, July 8.

Thanks,

--John

On May 9, 2011, at 3:53 PM, Retana, Alvaro wrote:

> Hi!
>
> Following up on the meeting in Prague=85
>
> http://tools.ietf.org/html/draft-retana-bgp-custom-deci= sion
>
> We just published version -02. =A0The only change from -01 is an updat= e on the authors=92 contact information.
>
> As discussed during the meeting, this is the formal request for adopti= on of this draft as a WG document.
>
> The intended status is Standards Track.
>
> Thoughts/comments?
>
> Thanks!
>
> Alvaro.

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

--90e6ba61383ac60d6b04a702e47d-- From ju1738@att.com Fri Jul 1 07:43:15 2011 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 F04A19E8005 for ; Fri, 1 Jul 2011 07:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8bROS-cWsgO for ; Fri, 1 Jul 2011 07:43:13 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id D7AEA9E801B for ; Fri, 1 Jul 2011 07:42:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ju1738@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1309531351!25696748!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 4043 invoked from network); 1 Jul 2011 14:42:32 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2011 14:42:32 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p61EfMvR012523; Fri, 1 Jul 2011 10:41:23 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p61EfKOs012475; Fri, 1 Jul 2011 10:41:20 -0400 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_01CC37FD.19F23F68" Date: Fri, 1 Jul 2011 10:42:28 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD7041A952A@misout7msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of "BGP Custom Decision" as WG Document Thread-Index: Acw3+8/g4/hlxEHhSmyc9o8KzamTagAAULNQ References: <24646CE17826CF4A8DF71F9856C7E65659240FE36F@GVW1338EXA.americas.hpqcorp.net><28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> From: "UTTARO, JAMES (ATTSI)" To: "Mohan Nanduri" , "John Scudder" Cc: idr@ietf.org, "Russ White \(russwh\)" Subject: Re: [Idr] Adoption of "BGP Custom Decision" as 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: Fri, 01 Jul 2011 14:43:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC37FD.19F23F68 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Support =20 Jim Uttaro =20 From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Mohan Nanduri Sent: Friday, July 01, 2011 10:33 AM To: John Scudder Cc: idr@ietf.org List; Russ White (russwh) Subject: Re: [Idr] Adoption of "BGP Custom Decision" as WG Document =20 Support it's adoption as a WG doc. Cheers, -Mohan On Thu, Jun 30, 2011 at 5:12 PM, John Scudder wrote: Folks, There was reasonable support for this proposal at the IETF-80 meeting (http://www.ietf.org/proceedings/80/minutes/idr.txt), but there has been no follow-up on the list. If you have any comments regarding WG adoption of the document, please send them by Friday, July 8. Thanks, --John On May 9, 2011, at 3:53 PM, Retana, Alvaro wrote: > Hi! > > Following up on the meeting in Prague... > > http://tools.ietf.org/html/draft-retana-bgp-custom-decision > > We just published version -02. The only change from -01 is an update on the authors' contact information. > > As discussed during the meeting, this is the formal request for adoption of this draft as a WG document. > > The intended status is Standards Track. > > Thoughts/comments? > > Thanks! > > Alvaro. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 ------_=_NextPart_001_01CC37FD.19F23F68 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Support

 

Jim Uttaro

 

From:= idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Mohan Nanduri
Sent: Friday, July 01, 2011 10:33 AM
To: John Scudder
Cc: idr@ietf.org List; Russ White (russwh)
Subject: Re: [Idr] Adoption of "BGP Custom Decision" as = WG Document

 

Support it's = adoption as a WG doc.

Cheers,
-Mohan

On Thu, Jun 30, 2011 at 5:12 PM, John Scudder = <jgs@juniper.net> = wrote:

Folks,

There was reasonable support for this proposal at the IETF-80 meeting = (http://www.ietf.org/proceedings/80/minutes/idr.txt)= , but there has been no follow-up on the list.  If you have any = comments regarding WG adoption of the document, please send them by Friday, July = 8.

Thanks,

--John


On May 9, 2011, at 3:53 PM, Retana, Alvaro wrote:

> Hi!
>
> Following up on the meeting in Prague…
>
> http://tools.ietf.org/html/draft-retana-bgp-custom-deci= sion
>
> We just published version -02.  The only change from -01 is an = update on the authors’ contact information.
>
> As discussed during the meeting, this is the formal request for = adoption of this draft as a WG document.
>
> The intended status is Standards Track.
>
> Thoughts/comments?
>
> Thanks!
>
> Alvaro.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

------_=_NextPart_001_01CC37FD.19F23F68-- From david.freedman@uk.clara.net Fri Jul 1 17:25:43 2011 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 A871B9E802E for ; Fri, 1 Jul 2011 17:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjZluJNtffWV for ; Fri, 1 Jul 2011 17:25:42 -0700 (PDT) Received: from staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [IPv6:2001:a88:0:fff7::68]) by ietfa.amsl.com (Postfix) with ESMTP id 828F99E8004 for ; Fri, 1 Jul 2011 17:25:42 -0700 (PDT) Received: from [195.157.10.59] (port=6677 helo=SRVGREXCAS01.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1Qco1k-0000AP-0K for idr@ietf.org (return-path ); Sat, 02 Jul 2011 00:25:40 +0000 Received: from SRVGREXMB03.claranet.local ([fe80::8011:a7b4:bd0d:3710]) by SRVGREXCAS01.claranet.local ([fe80::d0e0:3f28:712f:4dea%10]) with mapi id 14.01.0289.001; Sat, 2 Jul 2011 01:25:39 +0100 From: David Freedman To: "idr@ietf.org" Thread-Topic: I-D ACTION:draft-frs-bgp-operational-message-00.txt Thread-Index: AQHMOCn8Ku2x6lywC0K8OzvhqZcTmpTYKe4i Date: Sat, 2 Jul 2011 00:25:39 +0000 Message-ID: References: <4E0E281F.8070902@cisco.com> In-Reply-To: <4E0E281F.8070902@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.6.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Subject: [Idr] FW: I-D ACTION:draft-frs-bgp-operational-message-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, 02 Jul 2011 00:25:43 -0000 Folks, =0A= =0A= After much hard work since Prague, we would like to =0A= present the collaborative effort that is BGP OPERATIONAL, =0A= a draft which merges functionality from both=0A= ADVISORY (draft-ietf-idr-advisory-00) and DIAGNOSTIC=0A= (draft-raszuk-bgp-diagnostic-message-02) drafts to create a unified=0A= in-band messaging plane in the BGP targeted at operations work.=0A= =0A= The draft can be found here:=0A= =0A= http://www.ietf.org/internet-drafts/draft-frs-bgp-operational-message-00.tx= t=0A= =0A= We have prepared a short FAQ which should accompany readers,=0A= this can be found at:=0A= =0A= http://www.convergence.cx/drafts/draft-frs-bgp-operational-message-00-faq.t= xt=0A= =0A= As always, all comments and questions would be most appreciated.=0A= =0A= Regards,=0A= =0A= David. =0A= =0A= =0A= -------- Original Message --------=0A= Subject: I-D ACTION:draft-frs-bgp-operational-message-00.txt=0A= Date: Fri, 01 Jul 2011 11:30:02 -0700=0A= From: Internet-Drafts@ietf.org=0A= Reply-To: internet-drafts@ietf.org=0A= To: i-d-announce@ietf.org=0A= =0A= A new Internet-Draft is available from the on-line Internet-Drafts=0A= directories.=0A= =0A= =0A= Title : BGP OPERATIONAL Message=0A= =0A= Author(s) : R. Raszuk, et al=0A= Filename : draft-frs-bgp-operational-message-00.txt=0A= Pages : 26=0A= Date : 2011-07-01=0A= =0A= =0A= The BGP Version 4 routing protocol (RFC4271) is now used in many=0A= ways, crossing boundaries of administrative and technical=0A= responsibility.=0A= =0A= The protocol lacks an operational messaging plane which could be=0A= utilised to diagnose, troubleshoot and inform upon various conditions= =0A= across these boundaries, securely, during protocol operation, without= =0A= disruption.=0A= =0A= This document proposes a new BGP message type, the OPERATIONAL=0A= message, which can be used to effect such a messaging plane for use=0A= both between and within Autonomous Systems.=0A= =0A= =0A= A URL for this Internet-Draft is:=0A= http://www.ietf.org/internet-drafts/draft-frs-bgp-operational-message-00.tx= t=0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A= Below is the data which will enable a MIME compliant mail reader=0A= implementation to automatically retrieve the ASCII version of the=0A= Internet-Draft.=0A= =0A= From david.freedman@uk.clara.net Fri Jul 1 17:38:54 2011 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 CA5D411E8085 for ; Fri, 1 Jul 2011 17:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz00FFV1cNuF for ; Fri, 1 Jul 2011 17:38:54 -0700 (PDT) Received: from staff01.mail.eu.clara.net (staff01.mail.eu.clara.net [IPv6:2001:a88:0:fff7::54]) by ietfa.amsl.com (Postfix) with ESMTP id 282B911E8072 for ; Fri, 1 Jul 2011 17:38:53 -0700 (PDT) Received: from [195.157.10.59] (port=29828 helo=SRVGREXCAS02.claranet.local) by staff01.mail.eu.clara.net (staff01.mail.eu.clara.net [80.168.65.54]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1QcoEW-0007e4-5j for idr@ietf.org (return-path ); Sat, 02 Jul 2011 00:38:52 +0000 Received: from SRVGREXMB03.claranet.local ([fe80::8011:a7b4:bd0d:3710]) by SRVGREXCAS02.claranet.local ([fe80::cd6a:3120:3174:a299%10]) with mapi id 14.01.0289.001; Sat, 2 Jul 2011 01:38:50 +0100 From: David Freedman To: "idr@ietf.org" Thread-Topic: [Idr] Adoption of "BGP Custom Decision" as WG Document Thread-Index: Acw4UGjjGTSeW7qySiWXbIJjAkmB/w== Date: Sat, 2 Jul 2011 00:38:49 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.6.3] Content-Type: multipart/alternative; boundary="_000_E2B120470A420C49A1CB4F6D01C013F8377D4926SRVGREXMB03clar_" MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Subject: Re: [Idr] Adoption of "BGP Custom Decision" as 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: Sat, 02 Jul 2011 00:38:54 -0000 --_000_E2B120470A420C49A1CB4F6D01C013F8377D4926SRVGREXMB03clar_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support as WG item. Dave. --_000_E2B120470A420C49A1CB4F6D01C013F8377D4926SRVGREXMB03clar_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Support as WG item.

Dave.
--_000_E2B120470A420C49A1CB4F6D01C013F8377D4926SRVGREXMB03clar_-- From raszuk@cisco.com Sat Jul 2 01:25:53 2011 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 D9C7E1F0C3D for ; Sat, 2 Jul 2011 01:25:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX4kPIZ+ttte for ; Sat, 2 Jul 2011 01:25:53 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D28B71F0C3B for ; Sat, 2 Jul 2011 01:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=16; q=dns/txt; s=iport; t=1309595153; x=1310804753; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=gSeNJgtF+yjVdFp5w01Y8qFdo3ZFdB+KuJ7wOEiA6/4=; b=KHND9zj/iul5jER62iugsmR9/cqfXvfeUQp21r9Vl8yauiMAktQUrqd0 jTi4vjcgY8Lw07zlQvgABpNprXZYnvuPfM7RK0wJ0TW9ndw2AgePh+VgX 2INKbBJLOhHeVK9IoEHfs9+kDbOnLPNgqUrGcP2yCIPMpcqJapjXscvWX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUIANjUDk5Io8UT/2dsb2JhbABSmQ+OcneIc6U5gxUPAZoThjYEkjaEeItA X-IronPort-AV: E=Sophos;i="4.65,463,1304294400"; d="scan'208";a="40273639" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 02 Jul 2011 08:25:51 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p628Pl0M018838 for ; Sat, 2 Jul 2011 08:25:48 GMT Message-ID: <4E0ED60F.8050403@cisco.com> Date: Sat, 02 Jul 2011 10:25:51 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: idr@ietf.org References: <24646CE17826CF4A8DF71F9856C7E65659240FE36F@GVW1338EXA.americas.hpqcorp.net> <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> In-Reply-To: <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Adoption of "BGP Custom Decision" as WG Document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 08:25:54 -0000 Support. R. From zhangmingui@huawei.com Mon Jul 4 05:41:55 2011 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 665A121F85ED for ; Mon, 4 Jul 2011 05:41:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFEiPU2n4nE4 for ; Mon, 4 Jul 2011 05:41:55 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DA40521F85E4 for ; Mon, 4 Jul 2011 05:41:54 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNT009O579S1O@szxga05-in.huawei.com> for idr@ietf.org; Mon, 04 Jul 2011 20:41:52 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNT00AIJ79RB2@szxga05-in.huawei.com> for idr@ietf.org; Mon, 04 Jul 2011 20:41:52 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABS91112; Mon, 04 Jul 2011 20:41:51 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 04 Jul 2011 20:41:49 +0800 Received: from SZXEML503-MBS.china.huawei.com ([169.254.3.236]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Mon, 04 Jul 2011 20:41:50 +0800 Date: Mon, 04 Jul 2011 12:41:49 +0000 From: "Zhangmingui, (Mingui)" In-reply-to: <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> X-Originating-IP: [10.110.98.83] To: "idr@ietf.org List" Message-id: <4552F0907735844E9204A62BBDD325E7398915@SZXEML503-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [Idr] Adoption of "BGP Custom Decision" as WG Document Thread-index: AcwOgtBmpBHH6qh0Sn+l9O7U4/U3cgopJRQAAMgPg2A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <24646CE17826CF4A8DF71F9856C7E65659240FE36F@GVW1338EXA.americas.hpqcorp.net> <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> Subject: Re: [Idr] Adoption of "BGP Custom Decision" as 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, 04 Jul 2011 12:41:55 -0000 Support. -- Mingui Zhang From jgs@juniper.net Tue Jul 5 10:36:02 2011 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 307C621F8800 for ; Tue, 5 Jul 2011 10:36:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpXC8CFj-chi for ; Tue, 5 Jul 2011 10:36:01 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7E88521F860D for ; Tue, 5 Jul 2011 10:36:01 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKThNLgIhgzBuecqRa/OBAsd8CiVZ7NPUo@postini.com; Tue, 05 Jul 2011 10:36:01 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 5 Jul 2011 10:33:54 -0700 From: John Scudder To: "idr@ietf.org List" Date: Tue, 5 Jul 2011 10:33:52 -0700 Thread-Topic: Working group last call for draft-ietf-idr-rfc4760bis-01 Thread-Index: Acw7ObYB7WDJZHzHRfCuFtw/29yVJw== 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] Working group last call for draft-ietf-idr-rfc4760bis-01 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, 05 Jul 2011 17:36:02 -0000 Folks, We have received a request to advance draft-ietf-idr-rfc4760bis-01. Please= send any comments to the list by July 19, 2011. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-01.txt Thanks, --John= From jakob.heitz@ericsson.com Tue Jul 5 11:17:38 2011 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 AF4C621F87FB for ; Tue, 5 Jul 2011 11:17:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYDoJpzSMr2x for ; Tue, 5 Jul 2011 11:17:38 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC3121F898B for ; Tue, 5 Jul 2011 11:17:34 -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 p65IHWmS008740; Tue, 5 Jul 2011 13:17:34 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 5 Jul 2011 14:17:29 -0400 From: Jakob Heitz To: John Scudder , "idr@ietf.org List" Date: Tue, 5 Jul 2011 14:17:28 -0400 Thread-Topic: Working group last call for draft-ietf-idr-rfc4760bis-01 Thread-Index: Acw7ObYB7WDJZHzHRfCuFtw/29yVJwABV5IA Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E5D75D6FC@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: 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 Subject: Re: [Idr] Working group last call for draft-ietf-idr-rfc4760bis-01 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, 05 Jul 2011 18:17:38 -0000 support. Editorial: Add a sentence to "Comparison with RFC4760": This document adds rules for Redistribution from one to another= . -- Jakob Heitz. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of John Scudder > Sent: Tuesday, July 05, 2011 10:34 AM > To: idr@ietf.org List > Subject: [Idr] Working group last call for=20 > draft-ietf-idr-rfc4760bis-01 >=20 > Folks, >=20 > We have received a request to advance=20 > draft-ietf-idr-rfc4760bis-01. Please send any comments to=20 > the list by July 19, 2011. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-01.txt >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From jgs@juniper.net Tue Jul 5 12:59:25 2011 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 4923D21F88E0 for ; Tue, 5 Jul 2011 12:59:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzwFmj5ODmkc for ; Tue, 5 Jul 2011 12:59:22 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D4A0421F8805 for ; Tue, 5 Jul 2011 12:59:21 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKThNtGA3BSo49PZs/R1Hr5KZyh9yJFJgY@postini.com; Tue, 05 Jul 2011 12:59:21 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 5 Jul 2011 12:57:15 -0700 From: John Scudder To: "idr@ietf.org List" Date: Tue, 5 Jul 2011 12:57:14 -0700 Thread-Topic: IETF-81 agenda topics Thread-Index: Acw7TbzG8srtuoQSTdqbeAwDfbzKaw== Message-ID: <3F5BDAAB-FB8A-49F2-830A-1903565B3156@juniper.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 Subject: [Idr] IETF-81 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: Tue, 05 Jul 2011 19:59:25 -0000 Folks, We're planning to meet at IETF-81. On the draft agenda we are scheduled fo= r Wednesday, July 27 09:00 - 11:30. Please forward any IDR agenda items yo= u might have to Sue and myself. The deadline is July 17 by 13:00 U.S. East= ern Time. =20 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 slid= es to Sue, Weesan and me no later than 24 hours prior to the meeting. --John & Sue From jgs@juniper.net Fri Jul 8 08:29:24 2011 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 9F00321F8B43 for ; Fri, 8 Jul 2011 08:29:24 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Erl+8nGSP5dG for ; Fri, 8 Jul 2011 08:29:24 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 32D7121F8B42 for ; Fri, 8 Jul 2011 08:29:23 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKThciUexVb4+URzc8pFVJGi/VungBgNBg@postini.com; Fri, 08 Jul 2011 08:29:23 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 8 Jul 2011 08:27:05 -0700 From: John Scudder To: Alvaro Retana , "Russ White (russwh)" Date: Fri, 8 Jul 2011 08:27:03 -0700 Thread-Topic: [Idr] Adoption of "BGP Custom Decision" as WG Document Thread-Index: Acw9g32+iyal8uy6SXKUB+6x1Z6G9Q== Message-ID: References: <24646CE17826CF4A8DF71F9856C7E65659240FE36F@GVW1338EXA.americas.hpqcorp.net> <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.net> In-Reply-To: <28C11CF3-C111-49AA-998E-B0AB64D27396@juniper.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of "BGP Custom Decision" as 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: Fri, 08 Jul 2011 15:29:24 -0000 The document is accepted as an IDR WG doc. Authors, please resubmit as draft-ietf-idr- Thanks, --John On Jun 30, 2011, at 5:12 PM, John Scudder wrote: > Folks, >=20 > There was reasonable support for this proposal at the IETF-80 meeting (ht= tp://www.ietf.org/proceedings/80/minutes/idr.txt), but there has been no fo= llow-up on the list. If you have any comments regarding WG adoption of the= document, please send them by Friday, July 8. >=20 > Thanks, >=20 > --John >=20 > On May 9, 2011, at 3:53 PM, Retana, Alvaro wrote: >=20 >> Hi! >>=20 >> Following up on the meeting in Prague=85 >>=20 >> http://tools.ietf.org/html/draft-retana-bgp-custom-decision >>=20 >> We just published version -02. The only change from -01 is an update on= the authors=92 contact information. >>=20 >> As discussed during the meeting, this is the formal request for adoption= of this draft as a WG document. >>=20 >> The intended status is Standards Track. >>=20 >> Thoughts/comments? >>=20 >> Thanks! >>=20 >> Alvaro. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From zengqing@huawei.com Sun Jul 10 20:41:24 2011 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 AA2C111E807B; Sun, 10 Jul 2011 20:41:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-T8pg6xMJfz; Sun, 10 Jul 2011 20:41:23 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9911F11E807A; Sun, 10 Jul 2011 20:41:23 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO500HZVGWXNY@szxga04-in.huawei.com>; Mon, 11 Jul 2011 11:41:21 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO500B1NGWX5R@szxga04-in.huawei.com>; Mon, 11 Jul 2011 11:41:21 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACO11958; Mon, 11 Jul 2011 11:41:19 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 11 Jul 2011 11:41:18 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.31]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Mon, 11 Jul 2011 11:41:14 +0800 Date: Mon, 11 Jul 2011 03:42:11 +0000 From: Zengqing X-Originating-IP: [10.110.98.163] To: "idr@ietf.org" , "l3vpn@ietf.org" Message-id: <520F3F1A8F14EC4C81AB2F2558D7EB49DC552D@szxeml526-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt Thread-index: AQHMP3ximLR1dj/49kqEhmYfUin9jw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [Idr] [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-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, 11 Jul 2011 03:41:24 -0000 FYI. Any comments will be appreciated. Best Regards! Qing & Jie > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, July 04, 2011 6:48 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Maximum Transmission Unit Extended Community > for BGP-4 > Author(s) : Qing Zeng > Jie Dong > Filename : draft-zeng-idr-bgp-mtu-extension-00.txt > Pages : 6 > Date : 2011-07-04 > > Proper functioning of [RFC1191] path Maximum Transmission Unit (MTU) > discovery requires that IP routers have knowledge of the MTU for each > link to which they are connected. As MPLS progresses, [RFC3988] > specifies some extensions to LDP in support of LDP LSP MTU discovery. > For the LSP created using Border Gateway Protocol (BGP) [RFC3107], it > does not have the ability to signal the path MTU to the ingress Label > Switching Router (LSR). In the absence of this functionality, the > MTU for the BGP LSP must be statically configured by network > operators or by equivalent off-line mechanisms. > > This document defines the MTU Extended Community for BGP in support > of BGP LSP MTU discovery. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zeng-idr-bgp-mtu-extension-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-zeng-idr-bgp-mtu-extension-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From internet-drafts@ietf.org Mon Jul 11 06:44:55 2011 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 5825521F8BB4; Mon, 11 Jul 2011 06:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKYhCv6u+tYp; Mon, 11 Jul 2011 06:44:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D0F21F8BAE; Mon, 11 Jul 2011 06:44:54 -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: 3.55 Message-ID: <20110711134454.8898.65751.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 06:44:54 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp4-mibv2-12.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, 11 Jul 2011 13:44:55 -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 : Definitions of Managed Objects for the Fourth Version of= Border Gateway Protocol (BGP-4), Second Version Author(s) : Jeffrey Haas Filename : draft-ietf-idr-bgp4-mibv2-12.txt Pages : 45 Date : 2011-07-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-12.txt From internet-drafts@ietf.org Mon Jul 11 06:45:09 2011 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 1FB5321F8BE8; Mon, 11 Jul 2011 06:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKqU959pCxsx; Mon, 11 Jul 2011 06:45:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EED121F8BDA; Mon, 11 Jul 2011 06:45:06 -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: 3.55 Message-ID: <20110711134506.8940.78386.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 06:45:06 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp4-mibv2-tc-mib-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: Mon, 11 Jul 2011 13:45:09 -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 : Definitions of Textual Conventions for the Management of= the Fourth Version of Border Gateway Protocol (BGP-4) Author(s) : Jeffrey Haas Filename : draft-ietf-idr-bgp4-mibv2-tc-mib-03.txt Pages : 6 Date : 2011-07-11 This memo defines a portion of the Management Information Base (MIB) which defines Textual Conventions for the management of BGP-4. The intent is that these textual conventions will be used in BGP-related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-tc-mib-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-tc-mib-03.txt From jhaas@slice.pfrc.org Mon Jul 11 07:13:03 2011 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 24E4921F8B24 for ; Mon, 11 Jul 2011 07:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5tZGsR21+Uh for ; Mon, 11 Jul 2011 07:13:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A933221F8B19 for ; Mon, 11 Jul 2011 07:13:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1F004224094; Mon, 11 Jul 2011 14:17:27 +0000 (UTC) Date: Mon, 11 Jul 2011 14:17:27 +0000 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20110711141726.GI30842@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Idr] BGP MIB drafts 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, 11 Jul 2011 14:13:03 -0000 The version number of the drafts has been bumped. There are no changes. -- Jeff ----- Forwarded message from internet-drafts@ietf.org ----- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version Author(s) : Jeffrey Haas Filename : draft-ietf-idr-bgp4-mibv2-12.txt Pages : 45 Date : 2011-07-11 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4) Author(s) : Jeffrey Haas Filename : draft-ietf-idr-bgp4-mibv2-tc-mib-03.txt Pages : 6 Date : 2011-07-11 From internet-drafts@ietf.org Mon Jul 11 07:56:42 2011 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 35FF921F8CB7; Mon, 11 Jul 2011 07:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFzw3+5HIeDH; Mon, 11 Jul 2011 07:56:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3C721F8CAE; Mon, 11 Jul 2011 07:56:41 -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: 3.55 Message-ID: <20110711145641.5537.72325.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 07:56:41 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as4octet-extcomm-generic-subtype-04.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, 11 Jul 2011 14:56:42 -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 : Generic Subtype for BGP Four-octet AS specific extended = community Author(s) : Dhananjaya Rao Pradosh Mohapatra Jeffrey Haas Filename : draft-ietf-idr-as4octet-extcomm-generic-subtype-04.txt Pages : 6 Date : 2011-07-11 Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4octet-extcomm-generic= -subtype-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-as4octet-extcomm-generic-= subtype-04.txt From internet-drafts@ietf.org Mon Jul 11 08:59:27 2011 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 04CC621F8D8D; Mon, 11 Jul 2011 08:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9IsyF88Gg-w; Mon, 11 Jul 2011 08:59:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9231121F8C3D; Mon, 11 Jul 2011 08:59: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: 3.55 Message-ID: <20110711155926.1953.59354.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 08:59:26 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rfc4893bis-04.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, 11 Jul 2011 15:59: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 : BGP Support for Four-octet AS Number Space Author(s) : Quaizar Vohra Enke Chen Filename : draft-ietf-idr-rfc4893bis-04.txt Pages : 11 Date : 2011-07-11 The Autonomous System (AS) number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-04.txt From internet-drafts@ietf.org Mon Jul 11 14:31:08 2011 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 5FD1711E82AD; Mon, 11 Jul 2011 14:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWwZin0ZQXka; Mon, 11 Jul 2011 14:31:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEC021F8F6F; Mon, 11 Jul 2011 14:31:07 -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: 3.55 Message-ID: <20110711213107.5891.11697.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 14:31:07 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ipv6-rt-constrain-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, 11 Jul 2011 21:31:08 -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 : IPv6 Extensions for Route Target Distribution Author(s) : Keyur Patel Robert Raszuk Martine Djernaes Jie Dong Mach(Guoyi) Chen Filename : draft-ietf-idr-bgp-ipv6-rt-constrain-00.txt Pages : 7 Date : 2011-06-12 The current route target distribution specification described in RFC4684 defines Route Target NLRIs of maxiumum length of 12 bytes. The IPv6 specific Route Target extended community is defined in RFC5701 as length of 20 bytes. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when an operator wants to use this application in a pure IPv6 environment. This document defines an extension that allows BGP to exchange longer length IPv6 Route Target prefixes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ipv6-rt-constrain-00= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-ipv6-rt-constrain-00.= txt From bashandy@cisco.com Thu Jul 14 09:20:29 2011 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 107C021F8D43 for ; Thu, 14 Jul 2011 09:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbucFQYc1Myq for ; Thu, 14 Jul 2011 09:20:28 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D436D21F8D38 for ; Thu, 14 Jul 2011 09:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=7104; q=dns/txt; s=iport; t=1310660422; x=1311870022; h=message-id:date:from:reply-to:mime-version:to:subject; bh=iL+j5/PWityLn2UunbW85qq6YMIquV+FbKljmWFLSBU=; b=FixRqPD35YjMAhZK/AFlxolqSidTvfG1+VkAb+DaaVzwnN7mWIbGwake kZ8zfefciagbwEAoMz9lBDTA8QxM2o0PHv01xVxVjX8zKOP4Fn/mNq+RG lPdOTAO9iA9uarXmKbg+GfQlB+9wHxpgAeKLvzTo6w+A3U2M+Jg49sYIC M=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.65,529,1304294400"; d="asc'?scan'208,217";a="2982338" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 14 Jul 2011 16:20:21 +0000 Received: from [128.107.163.46] (dhcp-128-107-163-46.cisco.com [128.107.163.46]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6EGKL55019958; Thu, 14 Jul 2011 16:20:21 GMT Message-ID: <4E1F1731.2060604@cisco.com> Date: Thu, 14 Jul 2011 09:20:01 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "idr@ietf.org List" X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig362300F32C3624AADAF5D318" Subject: [Idr] Fwd: draft-bashandy-bgp-edge-node-frr-00.txt is a new draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bashandy@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 16:20:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig362300F32C3624AADAF5D318 Content-Type: multipart/alternative; boundary="------------050403030506090100090000" This is a multi-part message in MIME format. --------------050403030506090100090000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, The draft proposes a mechanism by which traffic can be rerouted, without = waiting for BGP or IGP to re-converge, to another PE in a BGP-free core w= hen the egress PE becomes totally disconnected from the core (e.g. edge r= outer crashes). The proposal does not require any special router(s) to ha= ndle rerouting traffic and does not require core routers to know about BG= P routes or replication of BGP routes to any other edge router. All comments are welcomed Thanks Ahmed -------- Original Message -------- Subject: draft-bashandy-bgp-edge-node-frr-00.txt is a new draft Date: Mon, 11 Jul 2011 05:55:48 -0700 From: ietf-interest(mailer list) Reply-To: ietf-interest(mailer list) To: Ahmed Bashandy (bashandy) CC: ietf-interest(mailer list) You posted a new draft today. In the interest of informing your Cisco colleagues, would you be so kind as to fill the rest of us in on your project and what the draft is about? The file may be found online at http://wwwin-eng.cisco.com/rfc/DRAFTS/draft-bashandy-bgp-edge-nod= e-frr-00.txt. By the way: if you know of a CPOL that might relate to this, and you have not done so, would you please access http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register the relationship between the CPOL and the draft? The abstract you included reads: There is more background at http://wwwin-people/fred/explanation.html By the way, if you're not on ietf-interest, you may find it an interesting list to join. --------------050403030506090100090000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable draft-bashandy-bgp-edge-node-frr-00.txt is a new draft= Hi,

The draft proposes a mechanism by which traffic can be rerouted, without waiting for BGP or IGP to re-converge, to another PE in a BGP-free core when the egress PE becomes totally disconnected from the core (e.g. edge router crashes). The proposal does not require any special router(s) to handle rerouting traffic and does not require core routers to know about BGP routes or replication of BGP routes to any other edge router.

All comments are welcomed

Thanks

Ahmed


-------- Original Message -------- =
Subje= ct: draft-bashandy-bgp-edge-node-frr-00.txt is a new draft
Date:= Mon, 11 Jul 2011 05:55:48 -0700
From:= ietf-interest(mailer list) <ietf-interest@cisco.com>= ;
Reply= -To: ietf-interest(mailer list) <ietf-interest@cisco.com>= ;
To: <= /th> Ahmed Bashandy (bashandy) <bashandy@cisco.com>
CC: <= /th> ietf-interest(mailer list) <ietf-interest@cisco.com>= ;


draft-bashandy-bgp-edge-node-frr-00.txt is a new draft=

You posted a new draft today. In the interest of informing your
Cisco colleagues, would you be so kind as to fill the rest of us<= br> in on your project and what the draft is about?

The file may be found online at
        http://wwwin-eng.cisco.com/rfc/DRAFTS/draft-bashandy-bgp-ed= ge-node-frr-00.txt.

By the way: if you know of a CPOL that might relate to this,
and you have not done so, would you please access
http= ://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register
the relationship between the CPOL and the draft?

The abstract you included reads:

There is more background at http://wwwin= -people/fred/explanation.html

By the way, if you're not on ietf-interest, you may find it an interesting list to join.

--------------050403030506090100090000-- --------------enig362300F32C3624AADAF5D318 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/ iD8DBQFOHxc4+G19kFA5zIYRAppQAJ991FKiTWXMSWUTibZTgevCk2izrgCbBah6 Gcp82G7N6j2iz9AVkkfnyyA= =N/JE -----END PGP SIGNATURE----- --------------enig362300F32C3624AADAF5D318-- From bashandy@cisco.com Thu Jul 14 09:43:00 2011 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 CC71D21F8D2A for ; Thu, 14 Jul 2011 09:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRqOGaSOzB6a for ; Thu, 14 Jul 2011 09:42:59 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 187E921F8B53 for ; Thu, 14 Jul 2011 09:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=9453; q=dns/txt; s=iport; t=1310661772; x=1311871372; h=message-id:date:from:reply-to:mime-version:to:subject; bh=fUMHuyRKDQ7TDPYF72jNsj5d+Nalzie37UWAMJ0DoeM=; b=WuhqB3l15J5s/s7CvaBWAvBOWPWL1/pE7cn3g/i6EEe152f3a37GgGwD pvAaaq3aCWmWRiWl9d/A4AihbmX5Hr3Vt7H9SNdgqlFB7FcfPXN0P9GY6 QYzvt2hmRjVGZ7gZhUnok8RjYJ8WTAa0ALtotGMx2O/BsKQs57BL8nyQQ M=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.65,529,1304294400"; d="asc'?scan'208,217";a="2986990" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-2.cisco.com with ESMTP; 14 Jul 2011 16:42:51 +0000 Received: from [128.107.163.46] (dhcp-128-107-163-46.cisco.com [128.107.163.46]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6EGgpgM002470; Thu, 14 Jul 2011 16:42:51 GMT Message-ID: <4E1F1C8A.5080706@cisco.com> Date: Thu, 14 Jul 2011 09:42:50 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "idr@ietf.org List" X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig566607248140B0CAF1084A62" Subject: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-edge-node-frr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bashandy@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 16:43:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig566607248140B0CAF1084A62 Content-Type: multipart/alternative; boundary="------------050903050403000607060700" This is a multi-part message in MIME format. --------------050903050403000607060700 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The draft proposes a mechanism by which traffic can be rerouted, without = waiting for BGP or IGP to re-converge, to another PE in a BGP-free core w= hen the egress PE becomes totally disconnected from the core (e.g. edge r= outer crashes). The proposal does not require any special router(s) to ha= ndle rerouting traffic and does not require core routers to know about BG= P routes or replication of BGP routes to any other edge router. All comments are welcomed Thanks Ahmed -------- Original Message -------- Subject: New Version Notification for draft-bashandy-bgp-edge-node-frr-0= 0.txt Date: Sun, 10 Jul 2011 10:48:17 -0700 From: To: Ahmed Bashandy (bashandy) CC: Ahmed Bashandy (bashandy) A new version of I-D, draft-bashandy-bgp-edge-node-frr-00.txt has been su= ccessfully submitted by Ahmed Bashandy and posted to the IETF repository.= Filename: draft-bashandy-bgp-edge-node-frr Revision: 00 Title: Scalable BGP FRR Protection against Edge Node Failure Creation date: 2011-07-10 WG ID: Individual Submission Number of pages: 17 Abstract: Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/p via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it desirable for a penultimate hop route ''P '' carrying traffic to the failed edge router PE= i to immediately restore traffic by re-tunneling packets originally tunneled to PEi and destined to the prefix P/p to one of the other edge routers that advertised P/p, 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. 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) there should be no special router (or group of routers) that handles restoring traffic, and (4) there should be no restrictions on what edge routers advertise what prefixes. For labeled prefixes, (5) the penultimate hop router must swap the label advertised by the failed edge router PEi for the prefix P/p with the label advertised for the same prefix by the edge router PEj before re-tunneling the packet to PEj = =20 The IETF Secretariat --------------050903050403000607060700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable New Version Notification for draft-bashandy-bgp-edge-node-frr-00.txt Hi,

The draft proposes a mechanism by which traffic can be rerouted, without waiting for BGP or IGP to re-converge, to another PE in a BGP-free core when the egress PE becomes totally disconnected from the core (e.g. edge router crashes). The proposal does not require any special router(s) to handle rerouting traffic and does not require core routers to know about BGP routes or replication of BGP routes to any other edge router.

All comments are welcomed

Thanks

Ahmed


-------- Original Message --------
Subje= ct: New Version Notification for draft-bashandy-bgp-edge-node-frr-00.txt
Date:= Sun, 10 Jul 2011 10:48:17 -0700
From:= <internet-drafts@ietf.org>
To: <= /th> Ahmed Bashandy (bashandy) <bashandy@cisco.com>
CC: <= /th> Ahmed Bashandy (bashandy) <bashandy@cisco.com>


New Version Notification for draft-bashandy-bgp-edge-node-frr-00.txt

A new version of I-D, draft-bashandy-bgp-edge-node-frr-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=C2=A0=C2=A0 draft-bashand= y-bgp-edge-node-frr
Revision:=C2=A0=C2=A0=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=C2=A0 Sca= lable BGP FRR Protection against Edge Node Failure
Creation date:=C2=A0=C2=A0 2011-07-10
WG ID:=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ind= ividual Submission
Number of pages: 17

Abstract:
Consider a BGP free core scenario. Suppose the edge BGP speakers PE1,
PE2,..., PEn know about a prefix P/p via the external routers CE1,
CE2,..., CEm.=C2=A0 If the edge router PEi crashes or becomes tot= ally
disconnected from the core, it desirable for a penultimate hop route
&#39;&#39;P=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &#39;&#= 39; 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/p to one of the other edge routers that
advertised P/p, 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. 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) there should be no<= br> special router (or group of routers) that handles restoring traffic,
and (4) there should be no restrictions on what edge routers
advertise what prefixes. For labeled prefixes, (5) the penultimate
hop router must swap the label advertised by the failed edge router
PEi for the prefix P/p with the label advertised for the same prefix
by the edge router PEj before re-tunneling the packet to PEj

=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

--------------050903050403000607060700-- --------------enig566607248140B0CAF1084A62 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/ iD8DBQFOHxyK+G19kFA5zIYRAo7HAJ0eFi490ZmgUuRKPith0nMByXCfwgCfYAxg WHaNF5nsuWzCTEKp83mRAkU= =lKjF -----END PGP SIGNATURE----- --------------enig566607248140B0CAF1084A62-- From internet-drafts@ietf.org Tue Jul 26 11:36:18 2011 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 B6E9921F8B85; Tue, 26 Jul 2011 11:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T19OINE01OtY; Tue, 26 Jul 2011 11:36:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5698E21F8AA8; Tue, 26 Jul 2011 11:36:18 -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: 3.56 Message-ID: <20110726183618.27816.25778.idtracker@ietfa.amsl.com> Date: Tue, 26 Jul 2011 11:36:18 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-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, 26 Jul 2011 18:36:18 -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 : BGP Bestpath Selection Criteria Author(s) : Rajiv Asati Filename : draft-ietf-idr-bgp-bestpath-selection-criteria-03.txt Pages : 9 Date : 2011-07-26 BGP specification [RFC4271] prescribes 'BGP next-hop reachability= 9; as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition&q= uot; to facilitate the next-hop to be resolved in the chosen data plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-c= riteria-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-cr= iteria-03.txt From internet-drafts@ietf.org Wed Jul 27 07:54:48 2011 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 2ECEB5E8029; Wed, 27 Jul 2011 07:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGtuzcr5mV6M; Wed, 27 Jul 2011 07:54:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0446F5E802A; Wed, 27 Jul 2011 07:54:43 -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: 3.56 Message-ID: <20110727145443.21202.31283.idtracker@ietfa.amsl.com> Date: Wed, 27 Jul 2011 07:54:43 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-deprecate-as-sets-05.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: Wed, 27 Jul 2011 14:54:48 -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 : Deprecation of the use of BGP AS_SET, AS_CONFED_SET. Author(s) : Warren Kumari Kotikalapudi Sriram Filename : draft-ietf-idr-deprecate-as-sets-05.txt Pages : 6 Date : 2011-07-27 This document deprecates 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 the BGP protocol 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-05.txt From naikumar@cisco.com Wed Jul 27 11:48:13 2011 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 2920211E8123; Wed, 27 Jul 2011 11:48:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p42-Xruy5Sao; Wed, 27 Jul 2011 11:48:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9A64A21F87C5; Wed, 27 Jul 2011 11:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naikumar@cisco.com; l=4784; q=dns/txt; s=iport; t=1311792490; x=1313002090; h=mime-version:content-transfer-encoding:subject:date: message-id:references:from:to; bh=AiSEQ4T6Nl4CgluuagMMin9SAT+NIpQlPzJiL30NML0=; b=HWpiCK2cCMTVnayD+KGxmNY/DBWFBYtiN5vdX9+8EQ2ki8sXrGLcs/j7 5dmFsNddmtyyyocIahqej3wYEhwcaXzarUsteOjzoJ58imBi2ereomlR8 DIXZG6nA4tusAC4/9yISd39U8dZ3GxNQ8gU4q8oIaAD8Ufjd6Jofzx59d E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAMZcME5Io8US/2dsb2JhbAA1AQEBAQMBAQERARQNBEAXBQIBCREEAQEDAgYGIwECAgIBARIYIw0BBQMCBQELCwwBDA6EL5Msjlhwd4kAoyWNI5FJgSuEBjBfBIdVkDCEXIZ+ X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208";a="45015904" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 27 Jul 2011 18:48:07 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIm7gt023354; Wed, 27 Jul 2011 18:48:07 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 00:18:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 28 Jul 2011 00:18:03 +0530 Message-ID: <7582AC0D011A46419BCDDB2B6DE5481903636648@XMB-BGL-41B.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt Thread-Index: AQHMP3ximLR1dj/49kqEhmYfUin9j5UAkQdAgAALWdA= References: <520F3F1A8F14EC4C81AB2F2558D7EB49DC552D@szxeml526-mbx.china.huawei.com> From: "Nagendra Kumar (naikumar)" To: "Zengqing" , , X-OriginalArrivalTime: 27 Jul 2011 18:48:07.0288 (UTC) FILETIME=[B97B7F80:01CC4C8D] Subject: Re: [Idr] [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-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: Wed, 27 Jul 2011 18:48:13 -0000 SGksDQoNCkkgd2FzIHJlYWRpbmcgdGhpcyBkcmFmdCBhbmQgY2FuIHlvdSBwbGVhc2UgY2xhcmlm eSB0aGUgYmVsb3csDQoNCjxzbmlwPg0KQS4gSWYgQkdQIHNwZWFrZXIgQSBpcyBvcmlnaW5hdG9y IG9mIHRoZSBsYWJlbGVkIElQdjQgKG9yIElQdjYpDQogICByb3V0ZSwgQSBzZXRzIGl0cyBCR1Ag TFNQIFBhdGggTVRVIHRvIHRoZSBtYXhpbWFsIHZhbHVlLCBhZHZlcnRpc2VzDQogICB0aGUgbGFi ZWxlZCBJUHY0IChvciBJUHY2KSByb3V0ZSB3aXRoIHRoZSBNVFUgRXh0ZW5kZWQgQ29tbXVuaXR5 IHRvDQogICBpdHMgQkdQIFBlZXIgKGl0cyB1cHN0cmVhbSBCR1AgTFNSKS4NCg0KMS4gIEFueSBy ZWFzb24gdG8gc3BlY2lmeSB0aGUgTVRVIHdpdGggbWF4aW1hbCB2YWx1ZSBvbiBlZ3Jlc3Mgc2lk ZT8uIEkgdW5kZXJzdGFuZCBSRkMzOTg4IGhhdmUgdGhlIHNhbWUgYmVoYXZpb3IsIGJ1dCBJIGFt IG5vdCBhd2FyZSBvZiBhbnkgcmVhc29uLiBQZXIgbXkgdW5kZXJzdGFuZGluZywgc2V0dGluZyB0 aGUgTVRVIHZhbHVlIGFzIHRoZSBsaW5rIE1UVSB0byB0aGUgcmVzcGVjdGl2ZSBGRUMgdmFsdWUg d2lsbCBoZWxwIGF2b2lkIElQIGZyYWdtZW50YXRpb24gdXB0byBlZ3Jlc3Mgc2lkZS4gRm9yIGV4 YW1wbGUsIGlmIG9uIGVncmVzcyBQRSwgdGhlIGxpbmsgTVRVIGlzIDE1MDAgd2hpbGUgdGhlIGNh bGN1bGF0ZWQgUGF0aCBNVFUgKGJhc2VkIG9uIHRoaXMgZHJhZnQpIGlzIDkwMDAsIGl0IHN0aWxs IG5lZWRzIElQIGZyYWdtZW50YXRpb24gb24gZWdyZXNzIHNpZGUuDQoNCjIuIEFmdGVyIGFkdmVy dGlzaW5nIHRoZSBVUERBVEUgdG8gbmVpZ2hib3Igd2hhdCB3aWxsIGJlIHRoZSBhY3Rpb24gd2hl biB0aGUgTVRVIGNoYW5nZXM/Lg0KDQozLiBTaW5jZSB3ZSBhbHJlYWR5IGhhdmUgUkZDMzk4OCB0 aGF0IGhlbHBzIGNhbGN1bGF0ZSBNVFUgd2l0aCBMRFAsIEFtIEkgYXNzdW1pbmcgcmlnaHQgdGhh dCB0aGlzIElEIGhlbHBzIGluIEludGVyLUFTIHNjZW5hcmlvcyAoT3B0aW9uIEIpIG9yIHNjZW5h cmlvcyB3aGVyZSBSU1ZQIGlzIHVzZWQgZm9yIExTUCBlc3RhYmxpc2htZW50Py4gU2hvdWxkIHdl IHNwZWNpZnkgdGhhdCBpbiBJRD8uDQoNClRoYW5rcywNCk5hZ2VuZHJhDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2 cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFplbmdxaW5nDQpTZW50OiBNb25kYXks IEp1bHkgMTEsIDIwMTEgOToxMiBBTQ0KVG86IGlkckBpZXRmLm9yZzsgbDN2cG5AaWV0Zi5vcmcN ClN1YmplY3Q6IFtpZHJdIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC16ZW5nLWlkci1iZ3AtbXR1LWV4 dGVuc2lvbi0wMC50eHQNCg0KRllJLiAgDQpBbnkgY29tbWVudHMgd2lsbCBiZSBhcHByZWNpYXRl ZC4NCg0KQmVzdCBSZWdhcmRzISAgIA0KUWluZyAmIEppZQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogaS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmcNCj4gW21h aWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiBTZW50OiBNb25kYXksIEp1bHkgMDQsIDIwMTEgNjo0OCBQ TQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IFN1YmplY3Q6IEktRCBBY3Rpb246IGRy YWZ0LXplbmctaWRyLWJncC1tdHUtZXh0ZW5zaW9uLTAwLnR4dA0KPiANCj4gQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRp cmVjdG9yaWVzLg0KPiANCj4gCVRpdGxlICAgICAgICAgICA6IE1heGltdW0gVHJhbnNtaXNzaW9u IFVuaXQgRXh0ZW5kZWQgQ29tbXVuaXR5DQo+IGZvciBCR1AtNA0KPiAJQXV0aG9yKHMpICAgICAg IDogUWluZyBaZW5nDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSmllIERvbmcNCj4gCUZp bGVuYW1lICAgICAgICA6IGRyYWZ0LXplbmctaWRyLWJncC1tdHUtZXh0ZW5zaW9uLTAwLnR4dA0K PiAJUGFnZXMgICAgICAgICAgIDogNg0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxMS0wNy0wNA0K PiANCj4gICAgUHJvcGVyIGZ1bmN0aW9uaW5nIG9mIFtSRkMxMTkxXSBwYXRoIE1heGltdW0gVHJh bnNtaXNzaW9uIFVuaXQgKE1UVSkNCj4gICAgZGlzY292ZXJ5IHJlcXVpcmVzIHRoYXQgSVAgcm91 dGVycyBoYXZlIGtub3dsZWRnZSBvZiB0aGUgTVRVIGZvciBlYWNoDQo+ICAgIGxpbmsgdG8gd2hp Y2ggdGhleSBhcmUgY29ubmVjdGVkLiAgQXMgTVBMUyBwcm9ncmVzc2VzLCBbUkZDMzk4OF0NCj4g ICAgc3BlY2lmaWVzIHNvbWUgZXh0ZW5zaW9ucyB0byBMRFAgaW4gc3VwcG9ydCBvZiBMRFAgTFNQ IE1UVSBkaXNjb3ZlcnkuDQo+ICAgIEZvciB0aGUgTFNQIGNyZWF0ZWQgdXNpbmcgQm9yZGVyIEdh dGV3YXkgUHJvdG9jb2wgKEJHUCkgW1JGQzMxMDddLCBpdA0KPiAgICBkb2VzIG5vdCBoYXZlIHRo ZSBhYmlsaXR5IHRvIHNpZ25hbCB0aGUgcGF0aCBNVFUgdG8gdGhlIGluZ3Jlc3MgTGFiZWwNCj4g ICAgU3dpdGNoaW5nIFJvdXRlciAoTFNSKS4gIEluIHRoZSBhYnNlbmNlIG9mIHRoaXMgZnVuY3Rp b25hbGl0eSwgdGhlDQo+ICAgIE1UVSBmb3IgdGhlIEJHUCBMU1AgbXVzdCBiZSBzdGF0aWNhbGx5 IGNvbmZpZ3VyZWQgYnkgbmV0d29yaw0KPiAgICBvcGVyYXRvcnMgb3IgYnkgZXF1aXZhbGVudCBv ZmYtbGluZSBtZWNoYW5pc21zLg0KPiANCj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBN VFUgRXh0ZW5kZWQgQ29tbXVuaXR5IGZvciBCR1AgaW4gc3VwcG9ydA0KPiAgICBvZiBCR1AgTFNQ IE1UVSBkaXNjb3ZlcnkuDQo+IA0KPiANCj4gDQo+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURy YWZ0IGlzOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16ZW5n LWlkci1iZ3AtbXR1LWV4dGVuc2lvbi0wMC50eHQNCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IFRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJp ZXZlZCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16ZW5n LWlkci1iZ3AtbXR1LWV4dGVuc2lvbi0wMC50eHQNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiBJ LUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNo YWRvdy1zaXRlcy50eHQNCg== From jie.dong@huawei.com Wed Jul 27 13:04:16 2011 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 8362911E809C; Wed, 27 Jul 2011 13:04:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdlRkq1OHi4B; Wed, 27 Jul 2011 13:04:15 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCA711E8082; Wed, 27 Jul 2011 13:04:15 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP0002LMD32E2@szxga05-in.huawei.com>; Thu, 28 Jul 2011 04:04:14 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP000901D31IA@szxga05-in.huawei.com>; Thu, 28 Jul 2011 04:04:14 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACQ54400; Thu, 28 Jul 2011 04:04:13 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Jul 2011 04:04:07 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.156]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Thu, 28 Jul 2011 04:04:09 +0800 Date: Wed, 27 Jul 2011 20:04:08 +0000 From: Jie Dong In-reply-to: <7582AC0D011A46419BCDDB2B6DE5481903636648@XMB-BGL-41B.cisco.com> X-Originating-IP: [172.24.2.40] To: "Nagendra Kumar (naikumar)" , Zengqing , "idr@ietf.org" , "l3vpn@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C9270B7676C8@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt Thread-index: AQHMTI3M2Sk2gU/1lE62no9k0Ewlu5UAhGKz X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <520F3F1A8F14EC4C81AB2F2558D7EB49DC552D@szxeml526-mbx.china.huawei.com> <7582AC0D011A46419BCDDB2B6DE5481903636648@XMB-BGL-41B.cisco.com> Subject: Re: [Idr] [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-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: Wed, 27 Jul 2011 20:04:16 -0000 Hi Nagendra, Thanks a lot for your comments, and please see replies with [Jie] A. If BGP speaker A is originator of the labeled IPv4 (or IPv6) route, A sets its BGP LSP Path MTU to the maximal value, advertises the labeled IPv4 (or IPv6) route with the MTU Extended Community to its BGP Peer (its upstream BGP LSR). 1. Any reason to specify the MTU with maximal value on egress side?. I understand RFC3988 have the same behavior, but I am not aware of any reason. Per my understanding, setting the MTU value as the link MTU to the respective FEC value will help avoid IP fragmentation upto egress side. For example, if on egress PE, the link MTU is 1500 while the calculated Path MTU (based on this draft) is 9000, it still needs IP fragmentation on egress side. [Jie] Actually this specification is for scenarios where the prefix advertised with label belongs to the egress node. When it's not the case, the MTU would be set to the link MTU to the prefix. I guess you are talking about advertising VPN routes, right? Yes in this case the Path MTU should be to a specific VPN prefix. This specification would be modified in next revision. 2. After advertising the UPDATE to neighbor what will be the action when the MTU changes?. [Jie] when the MTU changes, similar to other path attribute changes, update would be sent the the peer. In order to avoid unnecessary route flapping, we would define rules like this: If the MTU decreases, the update SHOULD be sent to peer immediately to avoid possible packet discard. If the MTU increases, the update SHOULD be hold down for a while, probably be sent when there is also change of other attributes. 3. Since we already have RFC3988 that helps calculate MTU with LDP, Am I assuming right that this ID helps in Inter-AS scenarios (Option B) or scenarios where RSVP is used for LSP establishment?. Should we specify that in ID?. [Jie] As I know, RSVP also defines its mechanism of MTU discovery. Thus this draft helps in scenarios where end-to-end LSP is established with labeled BGP. The typical use cases include inter-AS VPN Option C, Seamless MPLS and Carrier's Carrier. And Option B may also be a use case. Next revision will describe the scenarios. Discussion about other possible use cases would be appreciated. Many thanks, Jie -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Zengqing Sent: Monday, July 11, 2011 9:12 AM To: idr@ietf.org; l3vpn@ietf.org Subject: [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt FYI. Any comments will be appreciated. Best Regards! Qing & Jie > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, July 04, 2011 6:48 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Maximum Transmission Unit Extended Community > for BGP-4 > Author(s) : Qing Zeng > Jie Dong > Filename : draft-zeng-idr-bgp-mtu-extension-00.txt > Pages : 6 > Date : 2011-07-04 > > Proper functioning of [RFC1191] path Maximum Transmission Unit (MTU) > discovery requires that IP routers have knowledge of the MTU for each > link to which they are connected. As MPLS progresses, [RFC3988] > specifies some extensions to LDP in support of LDP LSP MTU discovery. > For the LSP created using Border Gateway Protocol (BGP) [RFC3107], it > does not have the ability to signal the path MTU to the ingress Label > Switching Router (LSR). In the absence of this functionality, the > MTU for the BGP LSP must be statically configured by network > operators or by equivalent off-line mechanisms. > > This document defines the MTU Extended Community for BGP in support > of BGP LSP MTU discovery. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zeng-idr-bgp-mtu-extension-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-zeng-idr-bgp-mtu-extension-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Wed Jul 27 17:43:05 2011 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 B753321F8AEC; Wed, 27 Jul 2011 17:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG7CY8V7T2Qc; Wed, 27 Jul 2011 17:43:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012D621F8A91; Wed, 27 Jul 2011 17:43:05 -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: 3.56 Message-ID: <20110728004305.3715.39579.idtracker@ietfa.amsl.com> Date: Wed, 27 Jul 2011 17:43:05 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-05.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, 28 Jul 2011 00:43:05 -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 : Advertisement of Multiple Paths in BGP Author(s) : Daniel Walton Enke Chen Alvaro Retana John Scudder Filename : draft-ietf-idr-add-paths-05.txt Pages : 8 Date : 2011-07-27 In this document we propose a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-add-paths-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-add-paths-05.txt From altonlo@cisco.com Thu Jul 28 08:17:56 2011 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 169CD21F8BFC for ; Thu, 28 Jul 2011 08:17:56 -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=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKV3qVKkJK0k for ; Thu, 28 Jul 2011 08:17:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5C75621F8BF2 for ; Thu, 28 Jul 2011 08:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=altonlo@cisco.com; l=258; q=dns/txt; s=iport; t=1311866275; x=1313075875; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=7hiA8QkwUCtaOgXgWTzhMVqq+T5eIBUWzLwV/pGlilY=; b=itwPn9pkB8I+tx2T4iO3d4oa6fiLDsk5wduopI2dXU/4XEsXTznVvE4x +8+NiVvbqjP9ycWn7M8/Mcvk027RLlAMNtGA4j6idYNbjDHXROhzamBUT b7naDcpn8IEv5Hfq/mCqha4yKOwseOahG8rwy05z/tIDNyMND1fQaZF2c w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOV8MU6rRDoI/2dsb2JhbAA2AQEDFAErAwFUARJdUgEFAT2nMXeJAKQpnleGQQSHWYsghRCLdA X-IronPort-AV: E=Sophos;i="4.67,282,1309737600"; d="scan'208";a="7416650" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jul 2011 15:17:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6SFHsC6011788 for ; Thu, 28 Jul 2011 15:17:54 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 08:17:54 -0700 Received: from 10.21.95.57 ([10.21.95.57]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jul 2011 15:17:54 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 28 Jul 2011 08:17:53 -0700 From: altonlo To: , Keyur Patel , Pradosh Mohapatra , Arjun Sreekantiah via prrq Message-ID: Thread-Topic: draft-l3vpn-legacy-rtc-00.txt Thread-Index: AcxNOYUxmjDayhFBrE+kedWY3crOTA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Jul 2011 15:17:54.0414 (UTC) FILETIME=[860968E0:01CC4D39] Subject: [Idr] draft-l3vpn-legacy-rtc-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, 28 Jul 2011 15:17:56 -0000 Hi, We presented the following draft (Legacy PE RT Filtering) in IETF80 Prague meeting. http://tools.ietf.org/html/draft-l3vpn-legacy-rtc-00 And we are asking the IDR working group to accept this as a working group document. Thanks, -alton From pedro.r.marques@gmail.com Thu Jul 28 20:54:40 2011 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 BA05711E807F for ; Thu, 28 Jul 2011 20:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-bdn6ytqQHE for ; Thu, 28 Jul 2011 20:54:39 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A55DD11E8075 for ; Thu, 28 Jul 2011 20:54:39 -0700 (PDT) Received: by iye7 with SMTP id 7so4307939iye.31 for ; Thu, 28 Jul 2011 20:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VAJKWzT2h8z/XIJ4NwAj0uBa+bK47orgtGnuFCP5Ze8=; b=qycp7Zn50WHTC9WBaOZDJ/+nWSX+TbDYEGu8wyQsVlL9xnc02cMB56S/BvQVTH1bxs wDppNrQ5069uTtspos1vLPJ+8XcqWy3q3wZhcqvbsMoyheGMMta3DTCDUZVP7FKDUT8N iRB3cjgNKWx1BUo7FEzJwb/94uWnb2EziL3d8= MIME-Version: 1.0 Received: by 10.231.191.216 with SMTP id dn24mr547962ibb.32.1311911679279; Thu, 28 Jul 2011 20:54:39 -0700 (PDT) Received: by 10.231.30.204 with HTTP; Thu, 28 Jul 2011 20:54:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jul 2011 20:54:39 -0700 Message-ID: From: Pedro Marques To: altonlo Content-Type: text/plain; charset=ISO-8859-1 Cc: Keyur Patel , idr@ietf.org Subject: Re: [Idr] draft-l3vpn-legacy-rtc-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: Fri, 29 Jul 2011 03:54:40 -0000 Alton, I'd like to ask for a clarification as to whether you believe that the "Legacy PE Behavior" that is described in the draft is achievable by configuration alone, with no software changes to the PEs in question. For instance, can the communities that are defined in the draft be advertised by existing production software ? If the procedure is based on configuration alone, it seems to be a potentially very error prone method. For instance, the RT filtering configuration could easily get out of sync with the actually VRF configuration, making this of doubtful operational value. If on the other hand one assumes that a software upgrade is required, these are not longer "Legacy PEs". In the latter case this proposal seems to be just a competing encoding for RFC4684. I think it is perfectly valid to propose an alternate encoding but i believe the document should be written as such and compare itself with the previous mechanism. regards, Pedro. On Thu, Jul 28, 2011 at 8:17 AM, altonlo wrote: > Hi, > > We presented the following draft (Legacy PE RT Filtering) in IETF80 Prague > meeting. > > http://tools.ietf.org/html/draft-l3vpn-legacy-rtc-00 > > And we are asking the IDR working group to accept this as a working group > document. > > Thanks, > -alton > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From altonlo@cisco.com Fri Jul 29 06:15:47 2011 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 9B96121F8509 for ; Fri, 29 Jul 2011 06:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVtfHTHXsfzY for ; Fri, 29 Jul 2011 06:15:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D1BF221F8500 for ; Fri, 29 Jul 2011 06:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=altonlo@cisco.com; l=2746; q=dns/txt; s=iport; t=1311945347; x=1313154947; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=rD+/vUrElSQp/hXy3jFTNpl9V5XZKKxCfkNB+tLpDw4=; b=khyYS2WdJlggc7PqZ6KMhITn84gRcvUmBM8l70TJY6o/Q6Ag5Xqob07a KXafZOjrlJNLa2l6RxlM8Q0BLtuCXT9hKD1XUBARXE0tAG4818RGviP3P 65eui2N48Ed/+ifAF10MCsTMTu5hETJqZ989b0A5+xkVvtY5US5Qn2cbU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALKxMk6rRDoJ/2dsb2JhbAA0AQEBAQIBAQEBEQErAwE2CwUOAQkJD04SBjkBAQUPCCenRXeIfAShM55AhkEEh1qLIIUPhFuHGQ X-IronPort-AV: E=Sophos;i="4.67,287,1309737600"; d="scan'208";a="7773942" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jul 2011 13:15:43 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6TDFhRu016782; Fri, 29 Jul 2011 13:15:43 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 06:15:42 -0700 Received: from 10.21.79.12 ([10.21.79.12]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Fri, 29 Jul 2011 13:15:42 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 29 Jul 2011 06:15:41 -0700 From: altonlo To: Pedro Marques Message-ID: Thread-Topic: [Idr] draft-l3vpn-legacy-rtc-00.txt Thread-Index: AcxN8Z1kyM0E/XJ6eUiB2enj2Tb1SQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Jul 2011 13:15:42.0804 (UTC) FILETIME=[9E784140:01CC4DF1] Cc: Keyur Patel , idr@ietf.org Subject: Re: [Idr] draft-l3vpn-legacy-rtc-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: Fri, 29 Jul 2011 13:15:47 -0000 Hi Pedro, Thanks for your reviews and comments. Please see inline response. Cheers, -alton On 7/28/11 8:54 PM, "Pedro Marques" wrote: > Alton, > I'd like to ask for a clarification as to whether you believe that the > "Legacy PE Behavior" that is described in the draft is achievable by > configuration alone, with no software changes to the PEs in question. > For instance, can the communities that are defined in the draft be > advertised by existing production software ? The communities value is the following: 0xFFFF0002 ROUTE_FILTER_TRANSLATED_v4 [draft-l3vpn-legacy-rtc] 0xFFFF0003 ROUTE_FILTER_v4 [draft-l3vpn-legacy-rtc] 0xFFFF0004 ROUTE_FILTER_TRANSLATED_v6 [draft-l3vpn-legacy-rtc] 0xFFFF0005 ROUTE_FILTER_v6 [draft-l3vpn-legacy-rtc] The existing production software in IOS and IOS-XR can be used without any software upgrade. > > If the procedure is based on configuration alone, it seems to be a > potentially very error prone method. For instance, the RT filtering > configuration could easily get out of sync with the actually VRF > configuration, making this of doubtful operational value. You've made a very good point and the configuration needs to planned. This scheme is not meant to replace RFC4684. Instead, it offers the SP operators a different migration path to RFC4684. The "extra" configuration should be a one-to-one mapping to the VPN membership (matching route-target value) on the legacy PE. One suggestion is to generate this configuration whenever a new VRF is provision in the legacy PE. We would like to hear feedback from the workgroup also. > > If on the other hand one assumes that a software upgrade is required, > these are not longer "Legacy PEs". In the latter case this proposal > seems to be just a competing encoding for RFC4684. Software upgrade is not required on the legacy PE > > I think it is perfectly valid to propose an alternate encoding but i > believe the document should be written as such and compare itself with > the previous mechanism. This is a very good feedback. We will add your suggestion in next version. > > regards, > Pedro. > > On Thu, Jul 28, 2011 at 8:17 AM, altonlo wrote: >> Hi, >> >> We presented the following draft (Legacy PE RT Filtering) in IETF80 Prague >> meeting. >> >> http://tools.ietf.org/html/draft-l3vpn-legacy-rtc-00 >> >> And we are asking the IDR working group to accept this as a working group >> document. >> >> Thanks, >> -alton >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> From ju1738@att.com Fri Jul 29 07:12:03 2011 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 5506521F8C0F for ; Fri, 29 Jul 2011 07:12:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EER+dAq0x2RE for ; Fri, 29 Jul 2011 07:12:02 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id B0D2E21F8BE1 for ; Fri, 29 Jul 2011 07:12:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ju1738@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1311948721!30296648!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 24135 invoked from network); 29 Jul 2011 14:12:02 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2011 14:12:02 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6TECQ52023992; Fri, 29 Jul 2011 10:12:27 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6TECLUh023866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Jul 2011 10:12:21 -0400 Received: from MISOUT7MSGUSR9P.ITServices.sbc.com ([169.254.7.28]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0289.001; Fri, 29 Jul 2011 10:11:56 -0400 From: "UTTARO, JAMES (ATTSI)" To: "'Pedro Marques'" , altonlo Thread-Topic: [Idr] draft-l3vpn-legacy-rtc-00.txt Thread-Index: AcxNOYUxmjDayhFBrE+kedWY3crOTAAiz8qAAAy2BBA= Date: Fri, 29 Jul 2011 14:11:54 +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: [135.70.61.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] draft-l3vpn-legacy-rtc-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: Fri, 29 Jul 2011 14:12:03 -0000 Comments IN-Line.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Pedro= Marques Sent: Thursday, July 28, 2011 11:55 PM To: altonlo Cc: Keyur Patel; idr@ietf.org Subject: Re: [Idr] draft-l3vpn-legacy-rtc-00.txt Alton, I'd like to ask for a clarification as to whether you believe that the "Legacy PE Behavior" that is described in the draft is achievable by configuration alone, with no software changes to the PEs in question. For instance, can the communities that are defined in the draft be advertised by existing production software ? If the procedure is based on configuration alone, it seems to be a potentially very error prone method. For instance, the RT filtering configuration could easily get out of sync with the actually VRF configuration, making this of doubtful operational value. [Jim U>] The approach is to tie the "legacy" configuration with the provisi= oning of a new VRF.. This is straightforward and there is very little room = for error if not by OSS provisioning systems.. We do not have individuals l= ogging on and doing provisioning..Let's look at the damage that could be do= ne.. If mis-configuration takes place then the worst is that=20 a) Legacy PE gets too many routes of course this is what we are faced with = today..=20 b) Legacy PE gets the routes for VRFs not configured.. This is standard beh= avior and the paths are dropped c) Legacy PE does not get the paths for VRFs configured.. In this case we c= reate a incomplete VPN tree for a given customer. We would be made aware ve= ry quickly if this occurred.. This feature is actually being demanded by Operations to deal with the larg= e amount of routing state being sent to a legacy PE.. It is quite undesirab= le to have to deploy the current RT Constrain and upgrade software on all P= Es to achieve our goal [Jim U>] If on the other hand one assumes that a software upgrade is required, these are not longer "Legacy PEs". In the latter case this proposal seems to be just a competing encoding for RFC4684. I think it is perfectly valid to propose an alternate encoding but i believe the document should be written as such and compare itself with the previous mechanism. regards, Pedro. On Thu, Jul 28, 2011 at 8:17 AM, altonlo wrote: > Hi, > > We presented the following draft (Legacy PE RT Filtering) in IETF80 Pragu= e > meeting. > > http://tools.ietf.org/html/draft-l3vpn-legacy-rtc-00 > > And we are asking the IDR working group to accept this as a working group > document. > > Thanks, > -alton > > _______________________________________________ > 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 pedro.r.marques@gmail.com Fri Jul 29 09:58:50 2011 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 B72E811E8082 for ; Fri, 29 Jul 2011 09:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlYVreAAlX4C for ; Fri, 29 Jul 2011 09:58:50 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12E6A11E807A for ; Fri, 29 Jul 2011 09:58:50 -0700 (PDT) Received: by iye7 with SMTP id 7so5090640iye.31 for ; Fri, 29 Jul 2011 09:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pu87zCd9nckN7tvwevD5qqegw5cjCnxnfRkJN2Qynnc=; b=GyYZi3BlTNhfv6MnL19BCxfsuUaCz0vrTaaF/YJqV/j6bkohjzXR08kzZAcXnuCnY1 sNrbbZRTQEuLhg8cRuOCx/rt15NqOlc57syb4icF5ZlICnGZqFnzWPZdq3PHIZCE/atf F9ODEKh1EbeksNjjKM90d7e2XiGB3WTBcWcf8= MIME-Version: 1.0 Received: by 10.231.43.139 with SMTP id w11mr1065833ibe.82.1311958729412; Fri, 29 Jul 2011 09:58:49 -0700 (PDT) Received: by 10.231.30.204 with HTTP; Fri, 29 Jul 2011 09:58:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Jul 2011 09:58:49 -0700 Message-ID: From: Pedro Marques To: "UTTARO, JAMES (ATTSI)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] draft-l3vpn-legacy-rtc-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: Fri, 29 Jul 2011 16:58:50 -0000 Jim, Wouldn't it be simpler for the OSS to configure the list of route targets as an outgoing filter in the RR ? Without any involvement of the PE. That would amount to have a manual mode to configure the route-target filter that the RR uses towards the PE and could significantly reduce the complexity of the software on the router side. It seems to me that the extra step of adding the information at the PE as VRF routes and them translating from VRF routes to route-target filtering information could be avoided. It is interesting to hear that OSS software development cycle is faster than the PE software qualification cycle. Did OSS software development cycle get just that much agile lately or is it the PE software qual cycle that just got out of whack ? Pedro. On Fri, Jul 29, 2011 at 7:11 AM, UTTARO, JAMES (ATTSI) wro= te: > Comments IN-Line.. > > Jim Uttaro > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Ped= ro Marques > Sent: Thursday, July 28, 2011 11:55 PM > To: altonlo > Cc: Keyur Patel; idr@ietf.org > Subject: Re: [Idr] draft-l3vpn-legacy-rtc-00.txt > > Alton, > I'd like to ask for a clarification as to whether you believe that the > "Legacy PE Behavior" that is described in the draft is achievable by > configuration alone, with no software changes to the PEs in question. > For instance, can the communities that are defined in the draft be > advertised by existing production software ? > > If the procedure is based on configuration alone, it seems to be a > potentially very error prone method. For instance, the RT filtering > configuration could easily get out of sync with the actually VRF > configuration, making this of doubtful operational value. > [Jim U>] The approach is to tie the "legacy" configuration with the provi= sioning of a new VRF.. This is straightforward and there is very little roo= m for error if not by OSS provisioning systems.. We do not have individuals= logging on and doing provisioning..Let's look at the damage that could be = done.. If mis-configuration takes place then the worst is that > > a) Legacy PE gets too many routes of course this is what we are faced wit= h today.. > b) Legacy PE gets the routes for VRFs not configured.. This is standard b= ehavior and the paths are dropped > c) Legacy PE does not get the paths for VRFs configured.. In this case we= create a incomplete VPN tree for a given customer. We would be made aware = very quickly if this occurred.. > > This feature is actually being demanded by Operations to deal with the la= rge amount of routing state being sent to a legacy PE.. It is quite undesir= able to have to deploy the current RT Constrain and upgrade software on all= PEs to achieve our goal > [Jim U>] > > If on the other hand one assumes that a software upgrade is required, > these are not longer "Legacy PEs". In the latter case this proposal > seems to be just a competing encoding for RFC4684. > > I think it is perfectly valid to propose an alternate encoding but i > believe the document should be written as such and compare itself with > the previous mechanism. > > regards, > =A0Pedro. > > On Thu, Jul 28, 2011 at 8:17 AM, altonlo wrote: >> Hi, >> >> We presented the following draft (Legacy PE RT Filtering) in IETF80 Prag= ue >> meeting. >> >> http://tools.ietf.org/html/draft-l3vpn-legacy-rtc-00 >> >> And we are asking the IDR working group to accept this as a working grou= p >> document. >> >> Thanks, >> -alton >> >> _______________________________________________ >> 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 ju1738@att.com Fri Jul 29 10:17:56 2011 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 B5E4921F8B38 for ; Fri, 29 Jul 2011 10:17:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN22c18WDuuO for ; Fri, 29 Jul 2011 10:17:56 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id B1A6421F8866 for ; Fri, 29 Jul 2011 10:17:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ju1738@att.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1311959874!31535985!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 22381 invoked from network); 29 Jul 2011 17:17:54 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-9.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2011 17:17:54 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6THIJja009031; Fri, 29 Jul 2011 13:18:20 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6THIEx1008966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Jul 2011 13:18:14 -0400 Received: from MISOUT7MSGUSR9P.ITServices.sbc.com ([169.254.7.28]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0289.001; Fri, 29 Jul 2011 13:17:48 -0400 From: "UTTARO, JAMES (ATTSI)" To: Pedro Marques Thread-Topic: [Idr] draft-l3vpn-legacy-rtc-00.txt Thread-Index: AcxNOYUxmjDayhFBrE+kedWY3crOTAAiz8qAAAy2BBAADqz7gAAIJaSA Date: Fri, 29 Jul 2011 17:17:47 +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: [135.70.61.29] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] draft-l3vpn-legacy-rtc-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: Fri, 29 Jul 2011 17:17:56 -0000 Pedro, Back in the day ;) I had considered creating policy on the RR. The downside= is that now a customer provisioning event turns into a network/RR provisio= ning event.. Without getting to far into it, our iBGP topology is for the m= ost part static, we do not touch RRs in response to VPNs being provisioned = on PEs. I made that as a conscious decision as to ensure as much stability = in the iBGP topology as possible.. The danger of tweaking the RRs is that t= hey are central and a mis-config there can create a major/catastrophic fail= ure.. I would rather have issue localized to the PEs. The notion is to augment the OSS provisioning so that VRF addition will als= o trigger a policy update for legacy RT.. To your point OSS is difficult an= d PE Upgrades are difficult also.. But the latter requires maintenance wind= ows ( These are quite valuable ), scheduling with customers to notify them = of an outage, vendor development, testing/cert etc... all on legacy equipme= nt. It seems more prudent to use our resources in a more strategic manner. Jim Uttaro=09 -----Original Message----- From: Pedro Marques [mailto:pedro.r.marques@gmail.com]=20 Sent: Friday, July 29, 2011 12:59 PM To: UTTARO, JAMES (ATTSI) Cc: altonlo; Keyur Patel; idr@ietf.org Subject: Re: [Idr] draft-l3vpn-legacy-rtc-00.txt Jim, Wouldn't it be simpler for the OSS to configure the list of route targets as an outgoing filter in the RR ? Without any involvement of the PE. That would amount to have a manual mode to configure the route-target filter that the RR uses towards the PE and could significantly reduce the complexity of the software on the router side. It seems to me that the extra step of adding the information at the PE as VRF routes and them translating from VRF routes to route-target filtering information could be avoided. It is interesting to hear that OSS software development cycle is faster than the PE software qualification cycle. Did OSS software development cycle get just that much agile lately or is it the PE software qual cycle that just got out of whack ? Pedro. On Fri, Jul 29, 2011 at 7:11 AM, UTTARO, JAMES (ATTSI) wro= te: > Comments IN-Line.. > > Jim Uttaro > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Ped= ro Marques > Sent: Thursday, July 28, 2011 11:55 PM > To: altonlo > Cc: Keyur Patel; idr@ietf.org > Subject: Re: [Idr] draft-l3vpn-legacy-rtc-00.txt > > Alton, > I'd like to ask for a clarification as to whether you believe that the > "Legacy PE Behavior" that is described in the draft is achievable by > configuration alone, with no software changes to the PEs in question. > For instance, can the communities that are defined in the draft be > advertised by existing production software ? > > If the procedure is based on configuration alone, it seems to be a > potentially very error prone method. For instance, the RT filtering > configuration could easily get out of sync with the actually VRF > configuration, making this of doubtful operational value. > [Jim U>] The approach is to tie the "legacy" configuration with the provi= sioning of a new VRF.. This is straightforward and there is very little roo= m for error if not by OSS provisioning systems.. We do not have individuals= logging on and doing provisioning..Let's look at the damage that could be = done.. If mis-configuration takes place then the worst is that > > a) Legacy PE gets too many routes of course this is what we are faced wit= h today.. > b) Legacy PE gets the routes for VRFs not configured.. This is standard b= ehavior and the paths are dropped > c) Legacy PE does not get the paths for VRFs configured.. In this case we= create a incomplete VPN tree for a given customer. We would be made aware = very quickly if this occurred.. > > This feature is actually being demanded by Operations to deal with the la= rge amount of routing state being sent to a legacy PE.. It is quite undesir= able to have to deploy the current RT Constrain and upgrade software on all= PEs to achieve our goal > [Jim U>] > > If on the other hand one assumes that a software upgrade is required, > these are not longer "Legacy PEs". In the latter case this proposal > seems to be just a competing encoding for RFC4684. > > I think it is perfectly valid to propose an alternate encoding but i > believe the document should be written as such and compare itself with > the previous mechanism. > > regards, > =A0Pedro. > > On Thu, Jul 28, 2011 at 8:17 AM, altonlo wrote: >> Hi, >> >> We presented the following draft (Legacy PE RT Filtering) in IETF80 Prag= ue >> meeting. >> >> http://tools.ietf.org/html/draft-l3vpn-legacy-rtc-00 >> >> And we are asking the IDR working group to accept this as a working grou= p >> document. >> >> Thanks, >> -alton >> >> _______________________________________________ >> 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 pedro.r.marques@gmail.com Fri Jul 29 14:43:18 2011 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 9DAC811E80AF for ; Fri, 29 Jul 2011 14:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXwrqfPsADWb for ; Fri, 29 Jul 2011 14:43:17 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A14D511E8096 for ; Fri, 29 Jul 2011 14:43:17 -0700 (PDT) Received: by iye7 with SMTP id 7so5339941iye.31 for ; Fri, 29 Jul 2011 14:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=z8sBefLs72ttEsTIY0/9Sv2GGROB/RTgQYD4pKZaIow=; b=YqVLmV7/tqj4mDf1Y2T5R5PvxNyy9pNELfwymp6/uQIpPM3fQ0FCwvrmoGSIZFGV9p 5ULYwgu4wkeNEMd3BZlRkn6qpNluNrI2si0CpbaylRmYV95ltP9erxHWvlI8HoaTHCaX ZTG74nPemvqiEmuCb6MXeua0PNDN8c1q+ykCU= MIME-Version: 1.0 Received: by 10.231.43.139 with SMTP id w11mr1280914ibe.82.1311975796851; Fri, 29 Jul 2011 14:43:16 -0700 (PDT) Received: by 10.231.30.204 with HTTP; Fri, 29 Jul 2011 14:43:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Jul 2011 14:43:16 -0700 Message-ID: From: Pedro Marques To: "UTTARO, JAMES (ATTSI)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] draft-l3vpn-legacy-rtc-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: Fri, 29 Jul 2011 21:43:18 -0000 Jim, I wonder if it would it be helpful to have a section in the draft that describes the OSS functionality required for it to be practical from an operational perspective ? Thank you for taking the time to answer my questions. Pedro. On Fri, Jul 29, 2011 at 10:17 AM, UTTARO, JAMES (ATTSI) wr= ote: > Pedro, > > Back in the day ;) I had considered creating policy on the RR. The downsi= de is that now a customer provisioning event turns into a network/RR provis= ioning event.. Without getting to far into it, our iBGP topology is for the= most part static, we do not touch RRs in response to VPNs being provisione= d on PEs. I made that as a conscious decision as to ensure as much stabilit= y in the iBGP topology as possible.. The danger of tweaking the RRs is that= they are central and a mis-config there can create a major/catastrophic fa= ilure.. I would rather have issue localized to the PEs. > > The notion is to augment the OSS provisioning so that VRF addition will a= lso trigger a policy update for legacy RT.. To your point OSS is difficult = and PE Upgrades are difficult also.. But the latter requires maintenance wi= ndows ( These are quite valuable ), scheduling with customers to notify the= m of an outage, vendor development, testing/cert etc... all on legacy equip= ment. It seems more prudent to use our resources in a more strategic manner= . > > Jim Uttaro > > -----Original Message----- > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > Sent: Friday, July 29, 2011 12:59 PM > To: UTTARO, JAMES (ATTSI) > Cc: altonlo; Keyur Patel; idr@ietf.org > Subject: Re: [Idr] draft-l3vpn-legacy-rtc-00.txt > > Jim, > Wouldn't it be simpler for the OSS to configure the list of route > targets as an outgoing filter in the RR ? Without any involvement of > the PE. > That would amount to have a manual mode to configure the route-target > filter that the RR uses towards the PE and could significantly reduce > the complexity of the software on the router side. > It seems to me that the extra step of adding the information at the PE > as VRF routes and them translating from VRF routes to route-target > filtering information could be avoided. > > It is interesting to hear that OSS software development cycle is > faster than the PE software qualification cycle. Did OSS software > development cycle get just that much agile lately or is it the PE > software qual cycle that just got out of whack ? > > =A0Pedro. > > On Fri, Jul 29, 2011 at 7:11 AM, UTTARO, JAMES (ATTSI) w= rote: >> Comments IN-Line.. >> >> Jim Uttaro >> >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Pe= dro Marques >> Sent: Thursday, July 28, 2011 11:55 PM >> To: altonlo >> Cc: Keyur Patel; idr@ietf.org >> Subject: Re: [Idr] draft-l3vpn-legacy-rtc-00.txt >> >> Alton, >> I'd like to ask for a clarification as to whether you believe that the >> "Legacy PE Behavior" that is described in the draft is achievable by >> configuration alone, with no software changes to the PEs in question. >> For instance, can the communities that are defined in the draft be >> advertised by existing production software ? >> >> If the procedure is based on configuration alone, it seems to be a >> potentially very error prone method. For instance, the RT filtering >> configuration could easily get out of sync with the actually VRF >> configuration, making this of doubtful operational value. >> [Jim U>] The approach is to tie the "legacy" configuration with the prov= isioning of a new VRF.. This is straightforward and there is very little ro= om for error if not by OSS provisioning systems.. We do not have individual= s logging on and doing provisioning..Let's look at the damage that could be= done.. If mis-configuration takes place then the worst is that >> >> a) Legacy PE gets too many routes of course this is what we are faced wi= th today.. >> b) Legacy PE gets the routes for VRFs not configured.. This is standard = behavior and the paths are dropped >> c) Legacy PE does not get the paths for VRFs configured.. In this case w= e create a incomplete VPN tree for a given customer. We would be made aware= very quickly if this occurred.. >> >> This feature is actually being demanded by Operations to deal with the l= arge amount of routing state being sent to a legacy PE.. It is quite undesi= rable to have to deploy the current RT Constrain and upgrade software on al= l PEs to achieve our goal >> [Jim U>] >> >> If on the other hand one assumes that a software upgrade is required, >> these are not longer "Legacy PEs". In the latter case this proposal >> seems to be just a competing encoding for RFC4684. >> >> I think it is perfectly valid to propose an alternate encoding but i >> believe the document should be written as such and compare itself with >> the previous mechanism. >> >> regards, >> =A0Pedro. >> >> On Thu, Jul 28, 2011 at 8:17 AM, altonlo wrote: >>> Hi, >>> >>> We presented the following draft (Legacy PE RT Filtering) in IETF80 Pra= gue >>> meeting. >>> >>> http://tools.ietf.org/html/draft-l3vpn-legacy-rtc-00 >>> >>> And we are asking the IDR working group to accept this as a working gro= up >>> document. >>> >>> Thanks, >>> -alton >>> >>> _______________________________________________ >>> 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 >> >