From iesg-secretary@ietf.org Tue Sep 3 07:13:11 2013 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 F1F7811E81E8; Tue, 3 Sep 2013 07:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8wDi1Nqxg+L; Tue, 3 Sep 2013 07:13:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ADC11E81B3; Tue, 3 Sep 2013 07:13:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Sender: Message-ID: <20130903141308.21877.33995.idtracker@ietfa.amsl.com> Date: Tue, 03 Sep 2013 07:13:08 -0700 Cc: idr@ietf.org Subject: [Idr] Last Call: (Making Route Flap Damping Usable) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 14:13:11 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Making Route Flap Damping Usable' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/ballot/ No IPR declarations have been submitted directly on this I-D. From bill.wu@huawei.com Mon Sep 9 20:48:04 2013 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 1F21C11E8147 for ; Mon, 9 Sep 2013 20:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z4L3bfZI5-R for ; Mon, 9 Sep 2013 20:48:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 21A1A21F99F3 for ; Mon, 9 Sep 2013 20:47:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVG03860; Tue, 10 Sep 2013 03:47:57 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 04:47:50 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 04:47:55 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Tue, 10 Sep 2013 11:47:47 +0800 From: Qin Wu To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week LC for: Early Code point allocation for draft-ietf-idr-ls-distribution Thread-Index: Ac6gEcGK8AmeRQfXQ3icD7WWhrWtFgNxJevQ Date: Tue, 10 Sep 2013 03:47:45 +0000 Message-ID: References: <00ed01cea013$2b0ba7d0$8122f770$@ndzh.com> In-Reply-To: <00ed01cea013$2b0ba7d0$8122f770$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43BFA2A0nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Idr] 2 Week LC for: Early Code point allocation for draft-ietf-idr-ls-distribution 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, 10 Sep 2013 03:48:04 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43BFA2A0nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, authors: Sorry for late reply. I have no objection to early code point allocation. Here is a few minor comments to this draft: 1.Abstract said "The mechanism described is subject to policy control. " [Qin]: Suggest to change Either "The described mechanism" or "The mechanism described in this document". 2. Introduction section, 5th paragraph: [Qin]: Is all those link attribute retrieved from LSPDB? Or some from TEDB? Is link metric is a new link attribute defined in this document, i.e., Metr= ic defined in section 3.3.23.? Is TE metric a default TE metric defined in section 3.7 of RFC5305? Or refe= rred to the metrics that is retrieved from TEDB? 3. Introduction section, last paragraph [Qin]: "Full stop" is missing at the end of the last paragraph of section 1 4. Section 3.1 TLV format, it said: " Information in the new link state NLRIs and attributes is encoded in Type/Length/Value triplets. The TLV format is shown in Figure 4. .... " [Qin]: What's the difference between link state NLRI and link state attribu= te since they both use TLV format. Is the difference TLV code point or one is mandatory while = the other TLV is optional? 5. Section 3.2, last paragraph It said: "Table Table 1 lists the 'Identifier' values that are defined as well-known in this draft. " [Qin]: The word "Table" appears twice in the above sentence. 6. Section 3.2.1, the 1st paragraph It said: " These auxiliary Router-IDs MUST be included in the link attribute described in Section Section 3.3.2. " The word "Section" appears twice in the above sentence. 7. Section 3.2.1.1. last paragraph, the word "section" appears twice. 8. Section 3.2.2 Link descriptor, Section 3.2.3. Prefix descriptor [Qin]: Why not allocate TLV code point for Link Descriptor just like local = node descriptor did? Local node is allocated with TLV codepoint 256. Regards! -Qin From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan= Hares Sent: Friday, August 23, 2013 11:12 PM To: idr wg Cc: shares@ndzh.com Subject: [Idr] 2 Week LC for: Early Code point allocation for draft-ietf-id= r-ls-distribution idr wg: The authors of draft-ietf-idr-ls-distribution have asked for an early code = point allocation. https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ As the IETF 87 WG meeting discussion showed, there is good support by many = implementers for this early code allocation. Please see the IETF 87 WG mee= ting notes (sent to list) for discussion. Per RFC4020, we are asking the W= G for 2 week consensus call for these early code points. The 2 week WG last call starts today and it will end on September 6th. For those curious about the BGP parameter assignments http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml Please comment early and often about allowing the early code point allocati= on. Comments on the draft are welcome in the exchange as this draft is rapidly = moving toward WG LC, but please clearly state if you want to allocate early= allocation. Sue Hares and John Scudder WG co-chairs ________________________________ --_000_B8F9A780D330094D99AF023C5877DABA43BFA2A0nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, authors:

Sorry for late reply. = I have no objection to early code point allocation.

Here is a few minor co= mments to this draft:

1.Abstract said <= /o:p>

“The mechanism d= escribed is subject to policy

control.

”

[Qin]: Suggest to ch= ange Either “The described mechanism” or

“The mechanism= described in this document”.

 

2. Introduction sect= ion, 5th paragraph:

[Qin]: Is all those = link attribute retrieved from LSPDB? Or some from TEDB?

Is link metric is a = new link attribute defined in this document, i.e., Metric defined in sectio= n 3.3.23.?

Is TE metric a defau= lt TE metric defined in section 3.7 of RFC5305? Or referred to the metrics = that is retrieved from TEDB?

 

3. Introduction sect= ion, last paragraph

[Qin]: “Full s= top” is missing at the end of the last paragraph of section 1

 

4. Section 3.1 TLV f= ormat, it said:

“

Information in the new link state NLRIs and attributes is = encoded in

   Type/Length/Value triplets.  The TLV for= mat is shown in Figure 4.

….<= /span>

”

[Qin]: What’s = the difference between link state NLRI and link state attribute since they = both

use TLV format. Is t= he difference TLV code point or one is mandatory while the other TLV is

optional?=

 

5. Section 3.2, last= paragraph

It said:<= /span>

“Table Table 1 = lists the 'Identifier'

   values that are defined as well-known in this= draft.

”

[Qin]: The word R= 20;Table” appears twice in the above sentence.

 

6. Section 3.2.1, th= e 1st paragraph

It said:<= /span>

“

These auxiliary Router-IDs MUST be

included in the link attribute described in Section Sectio= n 3.3.2.

 

”

The word “Sect= ion” appears twice in the above sentence.

 

 

7. Section 3.2.1.1. = last paragraph, the word “section” appears twice.

 

8. Section 3.2.2 Lin= k descriptor, Section 3.2.3. Prefix descriptor

[Qin]: Why not alloc= ate TLV code point for Link Descriptor just like local node descriptor did?=

Local node is alloca= ted with TLV codepoint 256.

 

Regards!<= /span>

-Qin

 

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, August 23, 2013 11:12 PM
To: idr wg
Cc: shares@ndzh.com
Subject: [Idr] 2 Week LC for: Early Code point allocation for draft-= ietf-idr-ls-distribution

 

 

idr wg:

 

The authors of draft-ietf-idr-ls-distribution have a= sked for an early code point allocation.

https://datatracker.ietf.org/doc/draft-ietf-idr-ls= -distribution/

 

As the IETF 87 WG meeting discussion showed, there i= s good support by many implementers for this early code allocation.  P= lease see the IETF 87 WG meeting notes (sent to list) for discussion.  = ;Per RFC4020, we are asking the WG for 2 week consensus call for these early code points.

 

The 2 week WG last call starts today and it will end= on September 6th. 

 

For those curious about the BGP parameter assignment= s

http://www.iana.org/assignments/bgp-parameters/= bgp-parameters.xhtml

 

Please comment early and often about allowing the ea= rly code point allocation. 

 

Comments on the draft are welcome in the exchange as= this draft is rapidly moving toward WG LC, but please clearly state if you= want to allocate early allocation.

 

Sue Hares and John Scudder

WG co-chairs

--_000_B8F9A780D330094D99AF023C5877DABA43BFA2A0nkgeml501mbschi_-- From shares@ndzh.com Mon Sep 9 20:58:43 2013 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 A1F2111E80FB for ; Mon, 9 Sep 2013 20:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=1.233, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMcAQUo4IcIq for ; Mon, 9 Sep 2013 20:58:39 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 615E621F9F77 for ; Mon, 9 Sep 2013 20:58:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Qin Wu'" , "'idr wg'" References: <00ed01cea013$2b0ba7d0$8122f770$@ndzh.com> In-Reply-To: Date: Mon, 9 Sep 2013 23:58:31 -0400 Message-ID: <004001ceadda$04056020$0c102060$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01CEADB8.7CF98C80" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQJecRILuy44o5nZACwwUvXAX+0g4gH3bjK4mI8WXHA= X-Authenticated-User: skh@ndzh.com Subject: Re: [Idr] 2 Week LC for: Early Code point allocation for draft-ietf-idr-ls-distribution 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, 10 Sep 2013 03:58:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0041_01CEADB8.7CF98C80 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Qin Wu: Thank you for reviewing this draft. We really appreciate it. Sue From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Qin Wu Sent: Monday, September 09, 2013 11:48 PM To: Susan Hares; idr wg Subject: Re: [Idr] 2 Week LC for: Early Code point allocation for draft-ietf-idr-ls-distribution Hi, authors: Sorry for late reply. I have no objection to early code point allocation. Here is a few minor comments to this draft: 1.Abstract said "The mechanism described is subject to policy control. " [Qin]: Suggest to change Either "The described mechanism" or "The mechanism described in this document". 2. Introduction section, 5th paragraph: [Qin]: Is all those link attribute retrieved from LSPDB? Or some from TEDB? Is link metric is a new link attribute defined in this document, i.e., Metric defined in section 3.3.23.? Is TE metric a default TE metric defined in section 3.7 of RFC5305? Or referred to the metrics that is retrieved from TEDB? 3. Introduction section, last paragraph [Qin]: "Full stop" is missing at the end of the last paragraph of section 1 4. Section 3.1 TLV format, it said: " Information in the new link state NLRIs and attributes is encoded in Type/Length/Value triplets. The TLV format is shown in Figure 4. .. " [Qin]: What's the difference between link state NLRI and link state attribute since they both use TLV format. Is the difference TLV code point or one is mandatory while the other TLV is optional? 5. Section 3.2, last paragraph It said: "Table Table 1 lists the 'Identifier' values that are defined as well-known in this draft. " [Qin]: The word "Table" appears twice in the above sentence. 6. Section 3.2.1, the 1st paragraph It said: " These auxiliary Router-IDs MUST be included in the link attribute described in Section Section 3.3.2. " The word "Section" appears twice in the above sentence. 7. Section 3.2.1.1. last paragraph, the word "section" appears twice. 8. Section 3.2.2 Link descriptor, Section 3.2.3. Prefix descriptor [Qin]: Why not allocate TLV code point for Link Descriptor just like local node descriptor did? Local node is allocated with TLV codepoint 256. Regards! -Qin From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, August 23, 2013 11:12 PM To: idr wg Cc: shares@ndzh.com Subject: [Idr] 2 Week LC for: Early Code point allocation for draft-ietf-idr-ls-distribution idr wg: The authors of draft-ietf-idr-ls-distribution have asked for an early code point allocation. https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ As the IETF 87 WG meeting discussion showed, there is good support by many implementers for this early code allocation. Please see the IETF 87 WG meeting notes (sent to list) for discussion. Per RFC4020, we are asking the WG for 2 week consensus call for these early code points. The 2 week WG last call starts today and it will end on September 6th. For those curious about the BGP parameter assignments http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml Please comment early and often about allowing the early code point allocation. Comments on the draft are welcome in the exchange as this draft is rapidly moving toward WG LC, but please clearly state if you want to allocate early allocation. Sue Hares and John Scudder WG co-chairs ------=_NextPart_000_0041_01CEADB8.7CF98C80 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Qin Wu:

 

Thank you for reviewing = this draft.  We really appreciate it.

 

Sue =

 

From:= = idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Qin Wu
Sent: Monday, September 09, 2013 11:48 = PM
To: Susan Hares; idr wg
Subject: Re: [Idr] 2 Week = LC for: Early Code point allocation for = draft-ietf-idr-ls-distribution

 

Hi, authors:

Sorry for late reply. I = have no objection to early code point = allocation.

Here is a few minor comments to this = draft:

1.Abstract said

“The mechanism = described is subject to policy

control.

”

[Qin]: Suggest to change Either “The described mechanism” = or

“The mechanism described in this = document”.

 

2. Introduction section, 5th paragraph:

[Qin]: Is all those link attribute retrieved from LSPDB? Or some from = TEDB?

Is link metric is a new link attribute defined in this document, = i.e., Metric defined in section 3.3.23.?

Is TE metric a default TE metric defined in section 3.7 of RFC5305? = Or referred to the metrics that is retrieved from = TEDB?

 

3. Introduction section, last paragraph

[Qin]: “Full stop” is missing at the end of the last = paragraph of section 1

 

4. Section 3.1 TLV format, it said:

“

Information in the = new link state NLRIs and attributes is encoded = in

   = Type/Length/Value triplets.  The TLV format is shown in Figure = 4.

….

”

[Qin]: What’s the difference between link state NLRI and link = state attribute since they both

use TLV format. Is the difference TLV code point or one is mandatory = while the other TLV is

optional?

 

5. Section 3.2, last paragraph

It said:

“Table Table 1 lists = the 'Identifier'

   values = that are defined as well-known in this draft.

”

[Qin]: The word “Table” appears twice in the above = sentence.

 

6. Section 3.2.1, the 1st = paragraph

It said:

“

These auxiliary = Router-IDs MUST be

included in the = link attribute described in Section Section = 3.3.2.

 

”

The word “Section” appears twice in the above = sentence.

 

 

7. Section 3.2.1.1. last paragraph, the word “section” = appears twice.

 

8. Section 3.2.2 Link descriptor, Section 3.2.3. Prefix = descriptor

[Qin]: Why not allocate TLV code point for Link Descriptor just like = local node descriptor did?

Local node is allocated with TLV codepoint = 256.

 

Regards!

-Qin

 

From:= = idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Friday, August 23, 2013 = 11:12 PM
To: idr wg
Cc: shares@ndzh.com
Subject: = [Idr] 2 Week LC for: Early Code point allocation for = draft-ietf-idr-ls-distribution

 

 

idr wg: =

 

The authors of draft-ietf-idr-ls-distribution have = asked for an early code point allocation.

https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ =

 

As the IETF 87 WG meeting discussion showed, there is = good support by many implementers for this early code allocation. =  Please see the IETF 87 WG meeting notes (sent to list) for = discussion.  Per RFC4020, we are asking the WG for 2 week consensus = call for these early code points.

 

The 2 week = WG last call starts today and it will end on September = 6th. 

 

For those = curious about the BGP parameter assignments

http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml

 

Please comment early and often about allowing the = early code point allocation. 

 

Comments on = the draft are welcome in the exchange as this draft is rapidly moving = toward WG LC, but please clearly state if you want to allocate early = allocation.

 

Sue Hares and John Scudder

WG co-chairs

------=_NextPart_000_0041_01CEADB8.7CF98C80-- From bill.wu@huawei.com Wed Sep 11 02:26:18 2013 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 2AF2621F92B7 for ; Wed, 11 Sep 2013 02:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxQs9UQj12p8 for ; Wed, 11 Sep 2013 02:26:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE0621E809B for ; Wed, 11 Sep 2013 02:26:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVH30238; Wed, 11 Sep 2013 09:26:05 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 11 Sep 2013 10:25:54 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 11 Sep 2013 10:26:02 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0146.000; Wed, 11 Sep 2013 17:25:57 +0800 From: Qin Wu To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt Thread-Index: Ac6gEPa63w1J/Q70T2a37AKQev3sBwOugJPg Date: Wed, 11 Sep 2013 09:25:56 +0000 Message-ID: References: <00da01cea011$09c50c80$1d4f2580$@ndzh.com> In-Reply-To: <00da01cea011$09c50c80$1d4f2580$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43BFDA12nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'Yakov Rekhter' , "erosen@cisco.com" Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-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, 11 Sep 2013 09:26:18 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43BFDA12nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, authors: Sorry for late review again. I think this draft is very useful draft. Here are a few minor comments: 1. Section 2 paragraph 2,3. It is not obvious that the relationship between paragraph 2 and 3. It is not clear the relationship between two registries in paragraph 2 and = the registry in the paragraph 3. It looks some extended community type has extended community sub-type while= some not. 2. Section 3 Applicability to IPv6 Address Specific EC Attribute It looks IPv6 Address Specific Extended Community is one special example of Extended Community Types since the first one octet indicates Extended Commu= nity types But the second octet indicate extended Community sub-type. I am wondering why not base on the second octet and see IPv6 address specif= ic EC as a IPv6 address specific sub type. 3. Section 4, it said: " When an allocation from both registries is requested, the requester may find it desirable for both allocations to share the same low-order six bits. " Why make both allocation to share the same low-order six bits? Make them ea= sy to be recognized as two allocation related to the same EC type? Why should be low= er-order six bits? Is it too restrictive? 4. Section 4, 5th paragraph: It said: " It is recommended that the allocation policy described in section 2 be used. I.e., 0x00-0xBF to be allocated by IANA under the "First Come, First Served" policy, and 0xC0-0xFF to be allocated by IANA under the "IETF Review" policy. " It repeats what it said in the section 2 and is a little bit redundant. Sug= gest Remove the second paragraph in this quoted text. 5. Section 4, last two paragraph: It said: " When a new Extended Community is defined, it may be necessary to ask IANA to allocate codepoints in several Sub-Type registries. In this case, it is a common practice to ask IANA to allocate the same codepoint value in each registry. If this is desired, it is the responsibility of the requester to explicitly ask IANA to allocate the same value in each registry. When a new Extended Community Sub-Type codepoint is allocated, it may also be desirable to allocate a corresponding value in one or both of the IPv6-Address-Specific Extended Community registries. The requester is responsible for requesting this allocation explicitly. If the requester would like the same numerical value to be allocated in an IPv6-Address-Specific Extended Community registry that is allocated in some other registry, it is the responsibility of the requester to explicitly ask this of IANA. " I don't understand these two last paragraphs. When we decided the first hig= h order octet for Extended Community Type, Then we need to decide the second octet for Extended Community Sub-Type? Can we allocate multiple codepoints from multiple Sub-Type registry in this= case? If multiple Extended Community Sub-Type can be allocated for the same Exten= ded Community Type, Why it should be mandatory to allocate a value in IPv6 address specific Ext= ended Community registry? What about other Extended Community Sub-types? Is there any mandatory Exten= ded Community Sub-type? 6.Section 5,2nd paragraph Suggest the following change: OLD TEXT: " Any Extended Community Type or Sub-type codepoints allocated by IANA between the date of this document that the date at which the registries are reorganized must also be incorporated into the new registry organization. " NEW TEXT: " Any Extended Community Type or Sub-type codepoints allocated by IANA between the date of this document and the date at which the registries are reorganized must also be incorporated into the new registry organization. " 7. Section 5,it said: " the authors will work with IANA to ensure this this information is carried over correctly to the new registry organization. " The word "this" repeats twice. Regards! -Qin From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan= Hares Sent: Friday, August 23, 2013 10:57 PM To: idr wg Cc: 'Yakov Rekhter'; erosen@cisco.com Subject: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt This messages starts a 2 week WG Last call for: IANA Registries for BGP Extended Communities draft-ietf-idr-extcomm-iana-00.txt https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ What this document does: This document reorganizes the IANA Registries for the type values and sub-type values of BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. Comment early, frequently and often. Sue and John Idr-co-chairs --_000_B8F9A780D330094D99AF023C5877DABA43BFDA12nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, authors:

Sorry for late review = again. I think this draft is very useful draft.

Here are a few minor c= omments:

1. Section 2 paragraph= 2,3.

It is not obvious that= the relationship between paragraph 2 and 3.

It is not clear the re= lationship between two registries in paragraph 2 and the registry in the pa= ragraph 3.

It looks some extended= community type has extended community sub-type while some not.<= /span>

 

2. Section 3 Applicab= ility to IPv6 Address Specific EC Attribute

It looks IPv6 Address= Specific Extended Community is one special example of

Extended Community Types since the first one octet indicat= es Extended Community types

But the second octet indicate extended Community sub-type.=

 

I am wondering why not base on the second octet and see IP= v6 address specific EC as a IPv6 address specific sub type.

 

3. Section 4, it said:

“

When an allocation from both registries is requested, the requester may=

   find it de= sirable for both allocations to share the same low-order<= /p>

   six bits.<= /span>=

”

Why make both allocation to share the same low-order six b= its? Make them easy to be

recognized as two allocation related to the same EC type? = Why should be lower-order six bits?

Is it too restrictive?

 

4. Section 4, 5th paragraph:<= /p>

It said:

“

It is recommended that the allocation

   policy described in section 2 be used.  I.e., 0x00-0xBF to b= e

   alloca= ted by IANA under the "First Come, First Served" policy, and=

   0xC0-0= xFF to be allocated by IANA under the "IETF Review" policy.=

 

”

It repeats what it said in the section 2 and is a little b= it redundant. Suggest

Remove the second paragraph in this quoted text.

 

5. Section 4, last two paragraph:

It said:

“

   When a new Extended Community is defined, it = may be necessary to ask

   IANA to allocate codepoints in several Sub-Ty= pe registries.  In this

   case, it is a common practice to ask IANA to = allocate the same

   codepoint value in each registry. If this is = desired, it is the

   responsibility of the requester to explicitly= ask IANA to allocate

   the same value in each registry.

 

   When a new Extended Community Sub-Type codepo= int is allocated, it may

   also be desirable to allocate a corresponding= value in one or both of

   the IP= v6-Address-Specific Extended Community registries.  The

   requester is responsible for requesting this = allocation explicitly.

   If the requester would like the same numerica= l value to be allocated

   in an IPv6-Address-Specific Extended Communit= y registry that is

   allocated in some other registry, it is the r= esponsibility of the

   requester to explicitly ask this of IANA.

 

”

I don’t understand these two last paragraphs. When w= e decided the first high order octet for Extended Community Type,

Then we need to decide the second octet for Extended Commu= nity Sub-Type?

Can we allocate multiple codepoints from multiple Sub-Type= registry in this case?

 

If multiple Extended Community Sub-Type can be allocated f= or the same Extended Community Type,

Why it should be mandatory to allocate a value in IPv6 add= ress specific Extended Community registry?

What about other Extended Community Sub-types? Is there an= y mandatory Extended Community Sub-type?

 

6.Section 5,2nd paragraph

Suggest the following change:

OLD TEXT:

“

Any Extended Community Type or Sub-type codepoints allocat= ed by IANA

   between the date of this document that the da= te at which the

   registries are reorganized must also be incor= porated into the new

   registry organization. 

”

NEW TEXT:

“

Any Extended Community Type or Sub-type codepoints allocat= ed by IANA

   between the date of this document and the date at which the

   registries are reorganized must also be incor= porated into the new

   registry organization. 

”

 

7. Section 5,it said:

“

the authors will

   work with IANA to ensure this this informat= ion is carried over

   correctly to the new registry organization.

 

”

The word “this” repeats twice.

 

Regards!

-Qin

 

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, August 23, 2013 10:57 PM
To: idr wg
Cc: 'Yakov Rekhter'; erosen@cisco.com
Subject: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt

 

 

This messages starts a 2 week WG Last call for:

 

IANA Registries for BGP Exten= ded Communities

draft-ietf-idr-extcomm-iana-0= 0.txt

https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-ian= a/

 

What this document does:

 

   This document reo= rganizes the IANA Registries for the type values and

   sub-type values o= f BGP Extended Communities attribute and the BGP

   IPv6-Address-Specific Extended Communities att= ribute.

 

Comment early, frequently and often.

 

Sue and John  

Idr-co-chairs

--_000_B8F9A780D330094D99AF023C5877DABA43BFDA12nkgeml501mbschi_-- From bill.wu@huawei.com Thu Sep 12 03:38:18 2013 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 0485111E815F for ; Thu, 12 Sep 2013 03:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.379 X-Spam-Level: X-Spam-Status: No, score=-5.379 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGq9xI4vY9AV for ; Thu, 12 Sep 2013 03:38:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BD69E11E812D for ; Thu, 12 Sep 2013 03:38:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVI33973; Thu, 12 Sep 2013 10:38:08 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Sep 2013 11:36:52 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Sep 2013 11:37:04 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0146.000; Thu, 12 Sep 2013 18:36:56 +0800 From: Qin Wu To: Robert Raszuk , Thomas Mangin Thread-Topic: [Idr] draft-raszuk-idr-flow-spec-v6-03 Thread-Index: AQHOon+C+Emn2qjv8E2JfHKNTfjT9JmnveqAgBpErJA= Date: Thu, 12 Sep 2013 10:36:55 +0000 Message-ID: References: <891D6F02-B937-4BBB-9802-E1EE61B830D7@exa-networks.co.uk> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43BFEDF9nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-idr-flow-spec-v6@tools.ietf.org" , idr wg Subject: Re: [Idr] draft-raszuk-idr-flow-spec-v6-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 10:38:18 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43BFEDF9nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksUm9iZXJ0Og0KSSBoYXZlIHJlYWQgZHJhZnQtaWV0Zi1pZGUtZmxvdy1zcGVjLXY2LiBBIGZl dyBxdWVzdGlvbnMgZm9yIGNsYXJpZmljYXRpb24gYmVsb3c6DQpJbiBzZWN0aW9uIDIsIGl0IHNh aWQ6DQqhsA0KVmFsaWRhdGlvbiB0YWJsZXMNCiAgIHdpbGwgbm93IGJlIHBlcmZvcm1lZCBhY2Nv cmRpbmcgdG8gdGhlIGZvbGxvd2luZyBydWxlcy4NCg0KICAgICAgRmxvdyBzcGVjaWZpY2F0aW9u IHJlY2VpdmVkIG92ZXIgQUZJL1NBRkk9MS8xMzMgd2lsbCBiZSB2YWxpZGF0ZWQNCiAgICAgIGFn YWluc3Qgcm91dGluZyByZWFjaGFiaWxpdHkgcmVjZWl2ZWQgb3ZlciBBRkkvU0FGST0xLzENCg0K ICAgICAgRmxvdyBzcGVjaWZpY2F0aW9uIHJlY2VpdmVkIG92ZXIgQUZJL1NBRkk9MS8xMzQgd2ls bCBiZSB2YWxpZGF0ZWQNCiAgICAgIGFnYWluc3Qgcm91dGluZyByZWFjaGFiaWxpdHkgcmVjZWl2 ZWQgb3ZlciBBRkkvU0FGST0xLzEyOA0KDQogICAgICBGbG93IHNwZWNpZmljYXRpb24gcmVjZWl2 ZWQgb3ZlciBBRkkvU0FGST0yLzEzMyB3aWxsIGJlIHZhbGlkYXRlZA0KICAgICAgYWdhaW5zdCBy b3V0aW5nIHJlYWNoYWJpbGl0eSByZWNlaXZlZCBvdmVyIEFGSS9TQUZJPTIvMQ0KDQogICAgICBG bG93IHNwZWNpZmljYXRpb24gcmVjZWl2ZWQgb3ZlciBBRkkvU0FGST0yLzEzNCB3aWxsIGJlIHZh bGlkYXRlZA0KICAgICAgYWdhaW5zdCByb3V0aW5nIHJlYWNoYWJpbGl0eSByZWNlaXZlZCBvdmVy IEFGSS9TQUZJPTIvMTI4DQoNCqGxDQpJIGRpZG6hr3QgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIHJh dGlvbmFsZSBiZWhpbmQgdGhpcyBzaW5jZSBJIG1pc3NlZCB0aGUgaGlzdG9yeSBkaXNjdXNzaW9u IGhhcHBlbmVkIG9uIHRoZSBsaXN0Lg0KV291bGQgeW91IGxpa2UgdG8gY2xhcmlmeSBhIGxpdHRs ZSBiaXQgb24gd2h5IHRoaXMgdmFsaWRhdGlvbiBpcyBuZWVkZWQ/DQoNCkluIHNlY3Rpb24gMywg aXQgc2FpZDoNCqGwDQpUaGUgZm9sbG93aW5nIGNvbXBvbmVudCB0eXBlcyBhcmUgcmVkZWZpbmVk IG9yIGFkZGVkIGZvciB0aGUgcHVycG9zZQ0KICAgb2YgYWNjb21tb2RhdGluZyBuZXcgSVB2NiBo ZWFkZXIgZW5jb2RpbmcuDQqhsQ0KSSBhbSB3b25kZXJpbmcgdG8gYWNjb21tb2RhdGUgbmV3IElQ djYgaGVhZGVyIGV4dGVuc2lvbiwgd2h5IG92ZXJyaWRlIG9yIHJldXNlIGV4aXN0aW5nIHR5cGUg YWxsb2NhdGVkIGZvciBJUHY0Pw0KV2h5IG5vdCBhbGxvY2F0ZSBuZXcgdHlwZSB0byBzdXBwb3J0 IElQdjYgZmxvdz8gSG93IGRvIEkgZGlzdGluZ3Vpc2ggSVB2NiBmbG93IGZyb20gSVB2NCBmbG93 Pw0KUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZ6OuDQoNClJlZ2FyZHMhDQotUWluDQoN CkZyb206IGlkci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjcsIDIw MTMgOToyNyBBTQ0KVG86IFRob21hcyBNYW5naW4NCkNjOiBkcmFmdC1pZXRmLWlkci1mbG93LXNw ZWMtdjZAdG9vbHMuaWV0Zi5vcmc7IGlkciB3Zw0KU3ViamVjdDogUmU6IFtJZHJdIGRyYWZ0LXJh c3p1ay1pZHItZmxvdy1zcGVjLXY2LTAzDQoNCkhpIFRob21hcywNCg0KVGhhbmsgeW91IHZlcnkg bXVjaCBmb3IgYm90aCB0aGUgY29tbWVudCBhcyB3ZWxsIGFzIGltcGxlbWVudGF0aW9uIG9mIHRo ZSBkcmFmdCBpbiBFeGFCR1AuDQoNCkkgYWdyZWUgd2l0aCB5b3VyIHN1Z2dlc3Rpb24gYW5kIHRo ZXJlIHdhcyBubyBwYXJ0aWN1bGFyIHJlYXNvbiB3aHkgdGhlIG9yZGVyIGluIHRoZSBkcmFmdCBv ZiB0aGUgb2Zmc2V0IGZpZWxkIHdhcyBwbGFjZWQgYWZ0ZXIgdGhlIGxlbmd0aCBmaWVsZC4NCg0K QXMgd2UgYXJlIGFjdHVhbGx5IHVwZGF0aW5nIHRoZSBkcmFmdCBub3cgd2Ugd2lsbCB1c2UgeW91 ciBzdWdnZXN0aW9uLg0KDQpNYW55IHRoeCBmb3IgdGhlIGNvbnRyaWJ1dGlvbiwNClIuDQoNCg0K T24gTW9uLCBBdWcgMjYsIDIwMTMgYXQgNzowOSBQTSwgVGhvbWFzIE1hbmdpbiA8dGhvbWFzLm1h bmdpbkBleGEtbmV0d29ya3MuY28udWs8bWFpbHRvOnRob21hcy5tYW5naW5AZXhhLW5ldHdvcmtz LmNvLnVrPj4gd3JvdGU6DQpIZWxsbywNCg0KSSBuZXZlciBwb3N0ZWQgdG8gYW55IElFVEYgbGlz dCBvZiBjb250cmlidXRlZCB0byBpdCwgc28gcGxlYXNlIGV4Y3VzZSBtZSBpZiBJIGRvIGFueXRo aW5nIG91dCBvZiBvcmRlci4NCg0KSSB3b3VsZCBsaWtlIHRvIGNvbW1lbnQgYW5kIHByb3Bvc2Ug YSBjaGFuZ2UgdG8gZHJhZnQtcmFzenVrLWlkci1mbG93LXNwZWMtdjYtMDMuDQpJIGhhdmUgaW1w bGVtZW50ZWQgdGhlIGRyYWZ0IGluIHRoZSBoZWFkL3RydW5rIHZlcnNpb24gb2YgRXhhQkdQIHdo aWNoIGNhbiBiZSBmb3VuZCBhdCBodHRwOi8vY29kZS5nb29nbGUuY29tL3AvZXhhYmdwLw0KDQpJ bXBsZW1lbnRpbmcgaXQgSSBub3RpY2VkIHRoZSBmb2xsb3dpbmcgOg0KDQpUaGUgSVB2NiBmbG93 cyBhcmUgZW5jb2RlZCBhcyA6DQo8dHlwZSAoMSBvY3RldCksIHByZWZpeCBsZW5ndGggKDEgb2N0 ZXQpLCBwcmVmaXggb2Zmc2V0ICgxIG9jdGV0KSwgcHJlZml4Pg0KDQpXaGVuIHRoZSBJUHY0IGZs b3dzIGFyZSBlbmNvZGVkIDoNCjx0eXBlICgxIG9jdGV0KSwgcHJlZml4IGxlbmd0aCAoMSBvY3Rl dCksIHByZWZpeD4NCg0KSU1ITyB0aGUgZHJhZnQgc2hvdWxkIGJlIGNoYW5nZWQgdG8gcmVhZCA6 DQo8dHlwZSAoMSBvY3RldCksIHByZWZpeCBvZmZzZXQgKDEgb2N0ZXQpLCBwcmVmaXggbGVuZ3Ro ICgxIG9jdGV0KSwgcHJlZml4Pg0KDQpwcmVmaXggbGVuZ3RoLCBwcmVmaXggb2Zmc2V0IGlzIHRo ZSAiY2xhc3NpY2FsIEJHUCBlbmNvZGluZyIsIHNvIGV2ZXJ5IElQdjQvSVB2NiBhZGRyZXNzIGlz IHN0b3JlZCBhcyBOTFJJIGFuZCBlbmNvZGVkIHRoaXMgd2F5LCBleHRlbmRpbmcgdGhlIGVuY29k aW5nIGJ5IHByZXBlbmRpbmcgdGhlIG9mZnNldCBpcyBjbGVhbiBhbmQgZWFzeSwgaGF2aW5nIHRv IHJlZGVmaW5lIHRoZSBlbmNvZGluZyBpcyBub3QgYXMgbmljZS4NCg0KSXQgaXMgb2J2aW91cyBh cyB3ZWxsIHdoZW4geW91IGxvb2sgYXQgc29tZSBkZWNvZGluZyBjb2RlLCBpbiBteSBjYXNlIGlu IHB5dGhvbjoNCg0KSVB2NDoNCl8scmQsbWFzayxzaXplLHByZWZpeCxsZWZ0ID0gX25scmlmYWN0 b3J5KGFmaSxzYWZpLGJncCkNCg0KSVB2NjoNCmJ5dGUsYmdwID0gYmdwWzFdLGJncFswXStiZ3Bb MjpdDQpvZmZzZXQgPSBvcmQoYnl0ZSkNCl8scmQsbWFzayxzaXplLHByZWZpeCxsZWZ0ID0gX25s cmlmYWN0b3J5KGFmaSxzYWZpLGJncCkNCg0KSXQgd291bGQgaGF2ZSBiZWVuIGNsZWFuZXIgdG8g d3JpdGU6DQpvZmZzZXQgPSBvcmQoYmdwWzBdKQ0KXyxyZCxtYXNrLHNpemUscHJlZml4LGxlZnQg PSBfbmxyaWZhY3RvcnkoYWZpLHNhZmksYmdwWzE6XSkNCg0KVGhhbmsgeW91IGZvciByZWFkaW5n LA0KDQpUaG9tYXMgTWFuZ2luDQoNCg0K --_000_B8F9A780D330094D99AF023C5877DABA43BFEDF9nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,Robert:

I have read draft-ietf-id= e-flow-spec-v6. A few questions for clarification below:<= /p>

In section 2, it said:

=A1=B0<= /p>

Validation = tables

  = ; will now be performed according to the following rules.=

 =

  = ;    Flow specification received over AFI/SAFI=3D1/133 will = be validated

  = ;    against routing reachability received over AFI/SAFI=3D1= /1

 =

  = ;    Flow specification received over AFI/SAFI=3D1/134 will = be validated

  = ;    against routing reachability received over AFI/SAFI=3D1= /128

 =

  = ;    Flow specification received over AFI/SAFI=3D2/133 will = be validated

  = ;    against routing reachability received over AFI/SAFI=3D2= /1

 =

  = ;    Flow specification received over AFI/SAFI=3D2/134 will = be validated

  = ;    against routing reachability received over AFI/SAFI=3D2= /128

 =

=A1=B1<= /p>

I didn=A1=AFt really unde= rstand the rationale behind this since I missed the history discussion happ= ened on the list.

Would you like to clarify= a little bit on why this validation is needed?

 <= /p>

In section 3, it said:

=A1=B0<= /p>

The f= ollowing component types are redefined or added for the purpose<= /span>

 &= nbsp; of accommodating new IPv6 header encoding.

=A1=B1<= /p>

I am wondering to accommo= date new IPv6 header extension, why override or reuse existing type allocat= ed for IPv4?

Why not allocate new type= to support IPv6 flow? How do I distinguish IPv6 flow from IPv4 flow?<= /o:p>

Please correct me if I am= wrong=A3=AE

 <= /p>

Regards!

-Qin

 <= /p>

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, August 27, 2013 9:27 AM
To: Thomas Mangin
Cc: draft-ietf-idr-flow-spec-v6@tools.ietf.org; idr wg
Subject: Re: [Idr] draft-raszuk-idr-flow-spec-v6-03

 

Hi Thomas,

Thank you very much for both the comment as well as implementation of the d= raft in ExaBGP.

I agree with your suggestion and there was no particular reason why the ord= er in the draft of the offset field was placed after the length field.

As we are actually updating the draft now we will use your suggestion.

Many thx for the contribution,
R.

 

 

On Mon, Aug 26, 2013 at 7:09 PM, Thomas Mangin <<= a href=3D"mailto:thomas.mangin@exa-networks.co.uk" target=3D"_blank">thomas= .mangin@exa-networks.co.uk> wrote:

Hello,

I never posted to any IETF list of contributed to it, so please excuse me i= f I do anything out of order.

I would like to comment and propose a change to draft-raszuk-idr-flow-spec-= v6-03.
I have implemented the draft in the head/trunk version of ExaBGP which can = be found at http://code.= google.com/p/exabgp/

Implementing it I noticed the following :

The IPv6 flows are encoded as :
<type (1 octet), prefix length (1 octet), prefix offset (1 octet), prefi= x>

When the IPv4 flows are encoded :
<type (1 octet), prefix length (1 octet), prefix>

IMHO the draft should be changed to read :
<type (1 octet), prefix offset (1 octet), prefix length (1 octet), prefi= x>

prefix length, prefix offset is the "classical BGP encoding", so = every IPv4/IPv6 address is stored as NLRI and encoded this way, extending t= he encoding by prepending the offset is clean and easy, having to redefine = the encoding is not as nice.

It is obvious as well when you look at some decoding code, in my case in py= thon:

IPv4:
_,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp)

IPv6:
byte,bgp =3D bgp[1],bgp[0]+bgp[2:]
offset =3D ord(byte)
_,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp)

It would have been cleaner to write:
offset =3D ord(bgp[0])
_,rd,mask,size,prefix,left =3D _nlrifactory(afi,safi,bgp[1:])

Thank you for reading,

Thomas Mangin

 

--_000_B8F9A780D330094D99AF023C5877DABA43BFEDF9nkgeml501mbschi_-- From erosen@cisco.com Thu Sep 12 08:43:40 2013 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 CFE1F11E824F for ; Thu, 12 Sep 2013 08:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbhqNSvnxcVf for ; Thu, 12 Sep 2013 08:43:22 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E20B611E81C0 for ; Thu, 12 Sep 2013 08:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6779; q=dns/txt; s=iport; t=1379000602; x=1380210202; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=k0eaHjti21Kj6iuUiG9cQitaD9dYl/r5XrwHcamknQk=; b=fhdX2weKKWOXtIMrci4Ev+JpIm/Jk9fd6FmH3sHok+1Qjomptv7vsopD llFZvHwzj6dUqpoab+Yq41bSAtPt5Ywg89NeuaJiozTTwrbzKmr+EINwh OkU0eJotJbSM7X5wVvVauwq/C949hfY1+dnQLFpKgmB8FFk+CfGyABsA2 c=; X-IronPort-AV: E=Sophos;i="4.90,891,1371081600"; d="scan'208";a="91729689" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 12 Sep 2013 15:43:18 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8CFhGMl013165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 15:43:17 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r8CFhFEI017061; Thu, 12 Sep 2013 11:43:15 -0400 From: Eric Rosen To: Qin Wu In-reply-to: Your message of Wed, 11 Sep 2013 09:25:56 -0000. Date: Thu, 12 Sep 2013 11:43:15 -0400 Message-ID: <17060.1379000595@erosen-linux> Cc: idr wg , erosen@cisco.com, Susan Hares , 'Yakov Rekhter' Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:43:40 -0000 Thanks for reviewing this draft! > 1. Section 2 paragraph 2,3. > It is not obvious that the relationship between paragraph 2 and 3. Paragraph 2 talks about the Extended Community Type registries; there are two such registries, as described in sections 5.1.1 and 5.1.2. Paragraph 3 talks about the Extended Community Sub-Type registries. There are currently 10 such registries, as described in sections 5.2.1-5.2.10. Separating the Type registries from the Sub-type registries is the major change proposed by this draft. > It is not clear the relationship between two registries in paragraph 2 and > the registry in the paragraph 3. As stated in paragraph 4: "If a particular Type has Sub-Types, that Type's entry in its Type registry identifies its Sub-Type registry." That is, each entry in a Type registry is known as a "Type". Each Type is associated with a numerical codepoint, and optionally with a Sub-type registry. > It looks some extended community type has extended community sub-type > while some not. Exactly correct, some types have sub-types and some don't. > 2. Section 3 Applicability to IPv6 Address Specific EC Attribute > It looks IPv6 Address Specific Extended Community is one special example > of Extended Community Types since the first one octet indicates Extended > Community types. But the second octet indicate extended Community > sub-type. > I am wondering why not base on the second octet and see IPv6 address > specific EC as a IPv6 address specific sub type. Actually, the IPv6 Address Specific Extended Communities attribute is not an Extended Communities attribute at all. It is a completely different BGP Path attribute. The Extended Communities attribute consists of 64-bit extended community values, and those value fields aren't large enough to hold an IPv6 address. > 3. Section 4, it said: > When an allocation from both registries is requested, Note that "both registries" in this context means the "Transitive Extended Community Types" registry, and the "Non-transitive Extended Community Types" registry. > the requester may find it desirable for both allocations to share the same > low-order six bits. > Why make both allocation to share the same low-order six bits? Make them > easy to be recognized as two allocation related to the same EC type? Why > should be lower-order six bits? Is it too restrictive? To get a new Type codepoint from one of the registries, you have to specify the registry, and you have to choose one of the assignable ranges for that registry. Once you do this, there are only six bits (the low-order six bits) in the type field for IANA to allocate. Note for example that "Non-Transitive Opaque Extended Community" has codepoint 0x43, and "Transitive Opaque Extended Community" has codepoint 0x03. So there are two types of "opaque extended community", and their respective codepoints are the same in the low-order six bits. It is not really necessary for this to be the case, but it's a convention that some folks like to follow. > 4. Section 4, 5th paragraph: > It said: It is recommended that the allocation policy described in section 2 be used. I.e., 0x00-0xBF to be allocated by IANA under the "First Come, First Served" policy, and 0xC0-0xFF to be allocated by IANA under the "IETF Review" policy. > It repeats what it said in the section 2 and is a little bit > redundant. Suggest Remove the second paragraph in this quoted text. Section 2 describes the allocation policy for the existing Sub-Type registries. Section 4 recommends (but does not require) that new Sub-Type registries created in the future use the same policy. So I don't think it is redundant. > 5. Section 4, > last two paragraph: It said: When a new Extended Community is defined, it may be necessary to ask IANA to allocate codepoints in several Sub-Type registries. In this case, it is a common practice to ask IANA to allocate the same codepoint value in each registry. If this is desired, it is the responsibility of the requester to explicitly ask IANA to allocate the same value in each registry. When a new Extended Community Sub-Type codepoint is allocated, it may also be desirable to allocate a corresponding value in one or both of the IPv6-Address-Specific Extended Community registries. The requester is responsible for requesting this allocation explicitly. If the requester would like the same numerical value to be allocated in an IPv6-Address-Specific Extended Community registry that is allocated in some other registry, it is the responsibility of the requester to explicitly ask this of IANA. > I don't understand these two last paragraphs. When we decided the first > high order octet for Extended Community Type, Then we need to decide the > second octet for Extended Community Sub-Type? Can we allocate multiple > codepoints from multiple Sub-Type registry in this case? As an example, look at the "Route Target" Extended Community. There are four different ways to construct a Route Target: 1. a. Type = Transitive Two-Octet AS-Specific Extended Community b. Sub-Type = Route Target (codepoint value 2 from the registry in 5.2.2) 2. a. Type = Transitive Four-Octet AS-Specific Extended Community b. Sub-Type = Route Target (codepoint value 2 from the registry in 5.2.4) 3. a. Type = Transitive IPv4-Address-Specific Extended Community b. Sub-type = Route Target (codepoint value 2 from the registry in 5.2.6) 4. Transitive IPv6-Address-Specific Extended Community (codepoint value 2 from the registry in 5.3.1) Note that if we want to be able to construct Route Targets in these four different ways, it requires a codepoint allocation in four different registries. The same codepoint value happens to be used in all four, but that is not required. > 6.Section 5,2nd paragraph > Suggest the following change: OLD TEXT: Any Extended Community Type or Sub-type codepoints allocated by IANA between the date of this document that the date at which registries are reorganized must also be incorporated into the new registry organization. NEW TEXT: Any Extended Community Type or Sub-type codepoints allocated by IANA between the date of this document and the date at which the registries are reorganized must also be incorporated into the new registry organization. Fixed. > 7. Section 5,it said: the authors will work with IANA to ensure this this information is carried over correctly to the new registry organization. The word this repeats twice. Fixed. From bill.wu@huawei.com Thu Sep 12 19:23:18 2013 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 3041A11E8169 for ; Thu, 12 Sep 2013 19:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCg-F0i4zwYt for ; Thu, 12 Sep 2013 19:22:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 770A511E8163 for ; Thu, 12 Sep 2013 19:22:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AXG74667; Fri, 13 Sep 2013 02:22:45 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 03:22:29 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 03:22:43 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 10:22:34 +0800 From: Qin Wu To: "erosen@cisco.com" Thread-Topic: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt Thread-Index: AQHOr87L3w1J/Q70T2a37AKQev3sB5nC5iag Date: Fri, 13 Sep 2013 02:22:33 +0000 Message-ID: References: Your message of Wed, 11 Sep 2013 09:25:56 -0000. <17060.1379000595@erosen-linux> In-Reply-To: <17060.1379000595@erosen-linux> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: idr wg , Susan Hares , 'Yakov Rekhter' Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-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, 13 Sep 2013 02:23:18 -0000 Hi,Eric: Thanks for your clarifications. I have removed the comments I have no issue= s. Here are two followup comments. Regards! -Qin -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com]=20 Sent: Thursday, September 12, 2013 11:43 PM To: Qin Wu Cc: Susan Hares; idr wg; 'Yakov Rekhter'; erosen@cisco.com Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt Thanks for reviewing this draft! > 2. Section 3 Applicability to IPv6 Address Specific EC Attribute > It looks IPv6 Address Specific Extended Community is one special example > of Extended Community Types since the first one octet indicates Extended > Community types. But the second octet indicate extended Community > sub-type. > I am wondering why not base on the second octet and see IPv6 address > specific EC as a IPv6 address specific sub type. Actually, the IPv6 Address Specific Extended Communities attribute is not a= n Extended Communities attribute at all. It is a completely different BGP Path attribute. The Extended Communities attribute consists of 64-bit extended community values, and those value fields aren't large enough to hold an IPv6 address. [Qin]: Really? by reading RFC5701, I think IPv6 Address Specific BGP Extend= ed Community Attribute Follow the similar format as Extended Communities Attribute, to identify IP= v6 address specific BGP Extended Community Attribute, you also only need to look at the first two o= ctets, the first octet Is used to indicate whether it is transitive or non-transitive attribute, t= he second octet is used To indicate subtype. It doesn't matter whether the value is 6 octets or 18 = octets, doesn't it? So why not use similar syntax and format of section 5.2.6 and section 5.2.7= and change section 5.3 as follows: OLD TEXT: " 5.3. Registries for IPv6-Address-Specific ECs 5.3.1. Transitive Types This registry contains values of the two high-order octets of an IPv6-Address-Specific Extended Communities attribute. Registry Name: TRANSITIVE IPV6 ADDRESS SPECIFIC EXTENDED COMMUNITY TYPES RANGE REGISTRATION PROCEDURE 0x0000-0x00FF First Come, First Served TYPE VALUE NAME 0x0002 Route Target 0x0003 Route Origin 0x0004 OSPFv3 Route Attributes (deprecated) 0x000B VRF Route Import 0x0010 Cisco VPN-Distinguisher 0x0011 UUID-based Route Target 5.3.2. Non-Transitive Types This registry contains values of the two high-order octets of an IPv6-Address-Specific Extended Communities attribute. Registry Name: NON-TRANSITIVE IPV6 ADDRESS SPECIFIC EXTENDED COMMUNITY TYPES RANGE REGISTRATION PROCEDURE 0x4000-0x40FF First Come, First Served None assigned " NEW TEXT: " 5.3. Registries for IPv6-Address-Specific ECs 5.3.1. Transitive Types This registry contains values of the second octet (the "Sub-Type field") of an IPv6-Address-Specific Extended Communities attribute, when the value of the first octet (the "Type field") is 0x00. Registry Name: TRANSITIVE IPV6 ADDRESS SPECIFIC EXTENDED COMMUNITY TYPES RANGE REGISTRATION PROCEDURE 0x00-0xFF First Come, First Served TYPE VALUE NAME 0x02 Route Target 0x03 Route Origin 0x04 OSPFv3 Route Attributes (deprecated) 0x0B VRF Route Import 0x10 Cisco VPN-Distinguisher 0x11 UUID-based Route Target 5.3.2. Non-Transitive Types This registry contains values of the second octet (the "Sub-Type field") of an IPv6-Address-Specific Extended Communities attribute,=20 when the value of the first octet (the "Type field") is 0x40. Registry Name: NON-TRANSITIVE IPV6 ADDRESS SPECIFIC EXTENDED COMMUNITY TYPES RANGE REGISTRATION PROCEDURE 0x00-0xFF First Come, First Served None assigned " > 4. Section 4, 5th paragraph: > It said: It is recommended that the allocation policy described in section 2 be used. I.e., 0x00-0xBF to be allocated by IANA under the "First Come, First Served" policy, and 0xC0-0xFF to be allocated by IANA under the "IETF Review" policy. > It repeats what it said in the section 2 and is a little bit > redundant. Suggest Remove the second paragraph in this quoted text. Section 2 describes the allocation policy for the existing Sub-Type registries. Section 4 recommends (but does not require) that new Sub-Type registries created in the future use the same policy. So I don't think it is redundant. [Qin]: I can live with your explanation however I think the first sentence= =20 " It is recommended that the allocation policy described in section 2 be used. " I quoted above is sufficient. > 5. Section 4, > last two paragraph: It said: When a new Extended Community is defined, it may be necessary to ask IANA to allocate codepoints in several Sub-Type registries. In this case, it is a common practice to ask IANA to allocate the same codepoin= t value in each registry. If this is desired, it is the responsibility of the requester to explicitly ask IANA to allocate the same value in each registry. When a new Extended Community Sub-Type codepoint is allocated, it may also be desirable to allocate a corresponding value in one or both of the IPv6-Address-Specific Extended Community registries.=20 [Qin]: One or both is referred to transitive or both transitive and non-tra= nsitive? If it is, it should be clear in the text. The requester is responsible for requesting this allocation explicitly. If the requester would like the same numerical value to be allocated in an IPv6-Address-Specific Extended Community registry that is allocated in some other registry, it is the responsibility of the requester to explicitly ask this of IANA. > I don't understand these two last paragraphs. When we decided the first > high order octet for Extended Community Type, Then we need to decide the > second octet for Extended Community Sub-Type? Can we allocate multiple > codepoints from multiple Sub-Type registry in this case? As an example, look at the "Route Target" Extended Community. There are four different ways to construct a Route Target: 1. a. Type =3D Transitive Two-Octet AS-Specific Extended Community b. Sub-Type =3D Route Target (codepoint value 2 from the registry in 5.2= .2) 2. a. Type =3D Transitive Four-Octet AS-Specific Extended Community b. Sub-Type =3D Route Target (codepoint value 2 from the registry in 5.2= .4) 3. a. Type =3D Transitive IPv4-Address-Specific Extended Community b. Sub-type =3D Route Target (codepoint value 2 from the registry in 5.2= .6) 4. Transitive IPv6-Address-Specific Extended Community (codepoint value 2 from the registry in 5.3.1) [Qin]: Good example. From this example, I can see the codepoint as subtype= =20 allocated in IPv6-address-Specific Extended Community is same as the codec= =20 allocated in other three registries. So I believe IPv6-address-Specific Extended Community should use the simila= r Syntax as the other registries, i.e., using 1st octet to indicate type and = 2nd Octet to indicate subtype. Also I believe it is better to add a reference to each registry to point ou= t Where the attributed is defined and how to use this attribute. From shares@ndzh.com Fri Sep 13 12:04:24 2013 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 874F811E8184 for ; Fri, 13 Sep 2013 12:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.147 X-Spam-Level: X-Spam-Status: No, score=0.147 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_20=-0.74, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkNf5aEKAkgX for ; Fri, 13 Sep 2013 12:04:20 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id AE51711E8200 for ; Fri, 13 Sep 2013 12:04:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.228.15; From: "Susan Hares" To: "idr wg" Date: Fri, 13 Sep 2013 15:03:59 -0400 Message-ID: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025C_01CEB092.7A5779B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6ws3neg5XJZ5eKR2KsQ/G28HibwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: erosen@cisco.com, "'John G. Scudder'" , 'Yakov Rekhter' Subject: [Idr] WG LC for draft-ietf-idr-extcomm-iana-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, 13 Sep 2013 19:04:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_025C_01CEB092.7A5779B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just in case the last message on this topic got caught in August doldrums, we are extending the WG last call for 1 more week: IANA Registries for BGP Extended Communities draft-ietf-idr-extcomm-iana-00.txt https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ What this document does: This document reorganizes the IANA Registries for the type values and sub-type values of BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. Without additional Votes for approval, this document will not pass WG last call. Sue and John Idr-co-chairs ------=_NextPart_000_025C_01CEB092.7A5779B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just in = case the last message on this topic got caught in August doldrums, we = are extending the WG last call for 1 more = week: 

IANA Registries for BGP Extended = Communities

draft-ietf-idr-extcomm-iana-00.txt

ht= tps://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/

What = this document does:

This document reorganizes the IANA Registries for the = type values and sub-type values of BGP Extended Communities attribute = and the BGP IPv6-Address-Specific Extended Communities = attribute.

Without = additional Votes for approval, this document will not pass WG last call. =

Sue and = John  

Idr-co-chairs

------=_NextPart_000_025C_01CEB092.7A5779B0-- From shares@ndzh.com Fri Sep 13 12:10:51 2013 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 9E28311E814D for ; Fri, 13 Sep 2013 12:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_40=-0.185, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjeSbmQN-U27 for ; Fri, 13 Sep 2013 12:10:38 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 23A9011E81C3 for ; Fri, 13 Sep 2013 12:10:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.228.15; From: "Susan Hares" To: "idr wg" Date: Fri, 13 Sep 2013 15:10:30 -0400 Message-ID: <026801ceb0b4$ea17c030$be474090$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0269_01CEB093.6307F4F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6ws0wX59k/mQY1TcS+7w7EXiv+XQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'Keyur Patel \(keyupate\)'" Subject: [Idr] 2 Week Working Group Adoption 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, 13 Sep 2013 19:10:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0269_01CEB093.6307F4F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The authors have asked that this implementation report on enhanced route refresh be adopted as a WG document. This starts a 2 week last call on the document. Enhanced Route Refresh Implementation Report draft-keyupate-idr-enhanced-refresh-impl-00 http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-impl/ Sue and John Idr co-chairs ------=_NextPart_000_0269_01CEB093.6307F4F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The authors have = asked that this implementation report on enhanced route refresh be = adopted as a WG document.

 

This starts a 2 = week last call on the document.

 

Enhanced Route Refresh Implementation = Report

draft-keyupate-idr-enhanced-refresh-impl-00

 

http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-ref= resh-impl/

 

 

Sue and John =

Idr = co-chairs

 

------=_NextPart_000_0269_01CEB093.6307F4F0-- From bdickson@verisign.com Fri Sep 13 12:14:36 2013 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 0FD2311E80FF for ; Fri, 13 Sep 2013 12:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvIVL83+45Dd for ; Fri, 13 Sep 2013 12:14:31 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 3D79911E8112 for ; Fri, 13 Sep 2013 12:14:06 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUjNj+ZQV6SVH5JlUeT6cPjgWBcAY7+Ru@postini.com; Fri, 13 Sep 2013 12:14:30 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8DJE0pp031449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 15:14:00 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 13 Sep 2013 15:13:32 -0400 From: "Dickson, Brian" To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt Thread-Index: Ac6ws3neg5XJZ5eKR2KsQ/G28HibwAAAeu0A Date: Fri, 13 Sep 2013 19:13:59 +0000 Message-ID: In-Reply-To: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CE58DC21D470bdicksonverisigncom_" MIME-Version: 1.0 Cc: 'Yakov Rekhter' , "erosen@cisco.com" , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-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, 13 Sep 2013 19:14:36 -0000 --_000_CE58DC21D470bdicksonverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Sorry for not doing so sooner. (I thought it had enough votes and/= or passed.) Brian From: Susan Hares > Date: Friday, September 13, 2013 3:03 PM To: idr wg > Cc: "erosen@cisco.com" >, "'John G. Scudder'" >, 'Yak= ov Rekhter' > Subject: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt Just in case the last message on this topic got caught in August doldrums, = we are extending the WG last call for 1 more week: IANA Registries for BGP Extended Communities draft-ietf-idr-extcomm-iana-00.txt https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ What this document does: This document reorganizes the IANA Registries for the type values and sub-t= ype values of BGP Extended Communities attribute and the BGPIPv6-Address-Sp= ecific Extended Communities attribute. Without additional Votes for approval, this document will not pass WG last = call. Sue and John Idr-co-chairs --_000_CE58DC21D470bdicksonverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <80ED2D6C7DC7B045979029B82E93F9B0@verisign.com> Content-Transfer-Encoding: quoted-printable
Support. Sorry for not doing so sooner. (I thought it had enough votes= and/or passed.)

Brian

From: Susan Hares <shares@ndzh.com>
Date: Friday, September 13, 2013 3:= 03 PM
To: idr wg <idr@ietf.org>
Cc: "erosen@cisco.com" <erosen@cisco.com>, "'John G. Scudder'" <jgs@bgp.nu>, 'Yakov Rekhter' <yakov@juniper.net>
Subject: [Idr] WG LC for draft-ietf= -idr-extcomm-iana-00.txt

Just in case the last message on this topic got caught in August = doldrums, we are extending the WG last call for 1 more week: 

IANA Registries for BGP Extended Communities

draft-ietf-idr-extcomm-iana-00.txt

https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/<= /span>

What this document does:

= This document reorganizes the IANA Registries for the type values and sub-t= ype values of BGP Extended Communities attribute and the BGPIPv6-Address-Specific Extended Communities attribute.

Without additional Votes for approval, this document will not pass= WG last call.

Sue and John  <= /span>

Idr-co-chairs=

--_000_CE58DC21D470bdicksonverisigncom_-- From randy@psg.com Fri Sep 13 12:14:38 2013 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 EFE5621E809C for ; Fri, 13 Sep 2013 12:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOijC4gBXIyE for ; Fri, 13 Sep 2013 12:14:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 5903311E816F for ; Fri, 13 Sep 2013 12:14:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VKYpB-0002N4-2M; Fri, 13 Sep 2013 19:14:37 +0000 Date: Fri, 13 Sep 2013 09:14:35 -1000 Message-ID: From: Randy Bush To: Susan Hares In-Reply-To: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> References: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-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, 13 Sep 2013 19:14:39 -0000 have read, and have no issues worth being a pita about randy From randy@psg.com Fri Sep 13 12:22:09 2013 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 9111B21E80B1 for ; Fri, 13 Sep 2013 12:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0Lp+0oX6z6g for ; Fri, 13 Sep 2013 12:22:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id DED8321E80B2 for ; Fri, 13 Sep 2013 12:22:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VKYwM-0002O0-5K; Fri, 13 Sep 2013 19:22:02 +0000 Date: Fri, 13 Sep 2013 09:22:00 -1000 Message-ID: From: Randy Bush To: Susan Hares In-Reply-To: <026801ceb0b4$ea17c030$be474090$@ndzh.com> References: <026801ceb0b4$ea17c030$be474090$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] 2 Week Working Group Adoption 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, 13 Sep 2013 19:22:09 -0000 > Enhanced Route Refresh Implementation Report > draft-keyupate-idr-enhanced-refresh-impl-00 as the spec is sparse, the implementation report is pretty sparse. so i guess that's ok. and i like implementation reports, so i support wg adoption of this one. does anyone have any reference for the "APGW Automation" implementation? randy From randy@psg.com Fri Sep 13 12:22:58 2013 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 6570E11E80D5 for ; Fri, 13 Sep 2013 12:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwvqKf9q073t for ; Fri, 13 Sep 2013 12:22:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id F3CF011E80D3 for ; Fri, 13 Sep 2013 12:22:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VKYxF-0002OH-8j; Fri, 13 Sep 2013 19:22:57 +0000 Date: Fri, 13 Sep 2013 09:22:55 -1000 Message-ID: From: Randy Bush To: Brian Dickson In-Reply-To: References: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-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, 13 Sep 2013 19:22:58 -0000 > I thought it had enough votes and/or passed. that would be impossible, as we do not vote randy From shares@ndzh.com Fri Sep 13 12:31:54 2013 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 7CE3B21E8056 for ; Fri, 13 Sep 2013 12:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbO7gei7Dlfd for ; Fri, 13 Sep 2013 12:31:50 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7A21F9EA8 for ; Fri, 13 Sep 2013 12:31:50 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.228.15; From: "Susan Hares" To: "idr wg" Date: Fri, 13 Sep 2013 15:31:44 -0400 Message-ID: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6wt8D1L5sinGlEQF6dDpyxwQSmIA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'Keyur Patel \(keyupate\)'" Subject: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh 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, 13 Sep 2013 19:31:54 -0000 This begins a 2 week working group last call for (ending 9/27) Enhanced Route Refresh Capability for BGP-4 http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-04 This WG last call is in parallel with the 2 week implementation report adoption call. The implementation report is at: http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-impl/ We will read both threads in considering the last call. If the implementation report is accepted, we will do a last call on the implementation report. Sue Hares and John Scudder Idr co-chairs From edc@google.com Fri Sep 13 12:33:33 2013 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 1072021F9CE7 for ; Fri, 13 Sep 2013 12:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VzGU1NjWQNo for ; Fri, 13 Sep 2013 12:33:32 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 68B8B21F9CBF for ; Fri, 13 Sep 2013 12:33:32 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q59so1583305wes.34 for ; Fri, 13 Sep 2013 12:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vZGxn1QKByzIjlYr3zMJ9UKKPCT2cfDIj6z7xK6BETE=; b=iRgad9TjcG7tHMe4NM3UbEyJZnCdL5mamoGJYrMZKEVete/ejabmRUhwy5gO8JcMqd Cvktx4MocUZHu8mfE3SJXpEG2fXYOiJeqFoU2ADTPeD9TI7JqhgSds0iZDHEB8DdRZ31 at19SY8kBGVnpWrYoDxVbeWAy9GYQWAYu6RNbNTEMhhbDWjajkympK2u2Fy64MCvDllq Wb6UkqOWGHYgk+yniYHXUX90j0+QSpMJxq9/wSJb9QycaxV8uevtwZjAQ0OubPNpHtyI mEcBUzX2YLuI3LUnP2nrtgjR9bQ5SjTmIM52EULSTSToSz87caK/SIS4I56z0Cgqm9st C5dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vZGxn1QKByzIjlYr3zMJ9UKKPCT2cfDIj6z7xK6BETE=; b=EsfL7VTIkr27wtuZJin6OWitqbkUaCNFfeFjBI8KEekfo1y1Nvqe0Uf/11rgUot07c Al897IQGzKMxEoe6+yS1QcqwvTGeafGKitCWrE2gaJhk1rJm21kyNRmwBqHWRuRGm0ba KBw676aKk0cOpRd4KnzQi8610gM7uhnYWfcRr1p9B9lrTIxvRKGAvpG7zq4mDUE5jmwb KWgqDKttx6XRhNLS8Eb+WFjinLqdGrMiPhKtDRBe30gR/lnSFE7Z1H066UU3cgoO0Pj0 CNKRz0Xyw/Z9QfCF2P5mT+eYyJ2SrTyomW8GzFCv24rFzlfC+zSNSVsqJEL09/OtCCxj rULw== X-Gm-Message-State: ALoCoQmp22pyEee24lBmwYjt1FGIj9EmPxn1Tkki4UsSea7Fd+bxCv93WCHwaYQKCY9/gpWphqgV00snidPy5Y/uPR8Gzr55tcl6z85rdXSIGhcTCm3iZWlsZGvAe3TQJikHXAiB540dACEzo/lcLNWRgVvT4SexN89TLlmCAbXC6xI67pLJ9RxrM4GVrUT5p1WKYGXtEgxN X-Received: by 10.194.175.133 with SMTP id ca5mr12150677wjc.19.1379100811374; Fri, 13 Sep 2013 12:33:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Fri, 13 Sep 2013 12:32:51 -0700 (PDT) In-Reply-To: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> From: Edward Crabbe Date: Fri, 13 Sep 2013 12:32:51 -0700 Message-ID: To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Cc: "Keyur Patel \(keyupate\)" , idr wg Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh 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, 13 Sep 2013 19:33:33 -0000 support On Fri, Sep 13, 2013 at 12:31 PM, Susan Hares wrote: > This begins a 2 week working group last call for (ending 9/27) > Enhanced Route Refresh Capability for BGP-4 > http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-04 > > This WG last call is in parallel with the 2 week > implementation report adoption call. > > The implementation report is at: > http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-impl/ > > We will read both threads in considering the last call. If the > implementation report is accepted, we will do a last call on the > implementation report. > > Sue Hares and John Scudder > Idr co-chairs > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From bdickson@verisign.com Fri Sep 13 12:42:49 2013 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 7964521E8056 for ; Fri, 13 Sep 2013 12:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVEEZjKtPQ7w for ; Fri, 13 Sep 2013 12:42:43 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1090721E80DD for ; Fri, 13 Sep 2013 12:42:20 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUjNqm04+ZsHldsxzTxJrXEAula3dW50D@postini.com; Fri, 13 Sep 2013 12:42:43 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r8DJgGYT014543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 15:42:16 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 13 Sep 2013 15:42:16 -0400 From: "Dickson, Brian" To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOsLlJ0tO/cX2Qk0yePWFFGCiuLw== Date: Fri, 13 Sep 2013 19:42:16 +0000 Message-ID: In-Reply-To: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh 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, 13 Sep 2013 19:42:49 -0000 Support both. Brian On 9/13/13 3:31 PM, "Susan Hares" wrote: >This begins a 2 week working group last call for (ending 9/27) >Enhanced Route Refresh Capability for BGP-4 >http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-04 > >This WG last call is in parallel with the 2 week >implementation report adoption call. > >The implementation report is at: >http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-impl/ > >We will read both threads in considering the last call. If the >implementation report is accepted, we will do a last call on the >implementation report. > >Sue Hares and John Scudder >Idr co-chairs=20 > > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Fri Sep 13 12:44:48 2013 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 8E5F311E80D3 for ; Fri, 13 Sep 2013 12:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DcNBDxpG1We for ; Fri, 13 Sep 2013 12:44:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 4211B21F99E8 for ; Fri, 13 Sep 2013 12:44:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VKZIL-0002Rl-5H; Fri, 13 Sep 2013 19:44:45 +0000 Date: Fri, 13 Sep 2013 09:44:43 -1000 Message-ID: From: Randy Bush To: Susan Hares In-Reply-To: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh 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, 13 Sep 2013 19:44:48 -0000 the grammar really needs to be cleaned up before it leaves the wg. e.g. A BGP speaker that support the message ^s and many more --- The enhancement can be used to facilitate on-line, non- disruptive consistency validation of BGP routing updates. but it never says how, which may cause someone to wonder if this is a useful or correct hack randy From shares@ndzh.com Fri Sep 13 12:46:58 2013 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 61DA221F99E8 for ; Fri, 13 Sep 2013 12:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YfjL6bgx-hO for ; Fri, 13 Sep 2013 12:46:49 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE0D11E80D3 for ; Fri, 13 Sep 2013 12:46:49 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.228.15; From: "Susan Hares" To: "'Randy Bush'" References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> In-Reply-To: Date: Fri, 13 Sep 2013 15:46:43 -0400 Message-ID: <004601ceb0b9$f9b4d820$ed1e8860$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWVRGMesRlg9yhBoY3WiZzMXXjYQIQNVtwmqRH6HA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh 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, 13 Sep 2013 19:46:58 -0000 Agreed. Grammar and English editorial fixes are needed. Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Friday, September 13, 2013 3:45 PM To: Susan Hares Cc: idr wg Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh the grammar really needs to be cleaned up before it leaves the wg. e.g. A BGP speaker that support the message ^s and many more --- The enhancement can be used to facilitate on-line, non- disruptive consistency validation of BGP routing updates. but it never says how, which may cause someone to wonder if this is a useful or correct hack randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Fri Sep 13 12:51:02 2013 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 1865321E80FA for ; Fri, 13 Sep 2013 12:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77pVPBBrelRS for ; Fri, 13 Sep 2013 12:51:01 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 784BA21E80F1 for ; Fri, 13 Sep 2013 12:51:01 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id tp5so3626843ieb.12 for ; Fri, 13 Sep 2013 12:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NjPFzuFMwVapyTvAf5NYOFH7pJGbbHuiMPryFKOMNkI=; b=rmvoB+sGOfWXeBCNG1JRJmnO0xSSh7ferX1Ij42cPwuX590VBQ4+OJGd9oCqXQshEc XjfxiMZJ4x6mI23EK+20cj972p0tNPsC86p/zk9dMCeEKwlbPk69iwdFMl/sa34T7m8H /mBNijfpV6B24U37BvzNtJ1E+zRJ5k+jkqZmsjh1bOhJqXGGfi8Qdae9pZu2y8jSJgBW vkuW5TJ5JuKRrxomrl86AJ0YiDCEi/sqL4Dq7RBCgrubwWYv+4H1KbmgGaadsjr5ZIH2 iqGsX9lWo+xRnkC/fR7dm4pwvPTHuG9EIjPahikfxOM6OqcXs1JzUH+87eu4sFCuLeSN BNYw== MIME-Version: 1.0 X-Received: by 10.50.23.16 with SMTP id i16mr1924084igf.50.1379101857775; Fri, 13 Sep 2013 12:50:57 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Fri, 13 Sep 2013 12:50:57 -0700 (PDT) In-Reply-To: References: <026801ceb0b4$ea17c030$be474090$@ndzh.com> Date: Fri, 13 Sep 2013 21:50:57 +0200 X-Google-Sender-Auth: 6T2_WBWB6HbmaGFnbce5l_hT8BI Message-ID: From: Robert Raszuk To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , Susan Hares Subject: Re: [Idr] 2 Week Working Group Adoption 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, 13 Sep 2013 19:51:03 -0000 Hi Randy, > does anyone have any reference for the "APGW Automation" implementation? It's NTT I3 internal BGP implementation of VPNv4, VPNv6 and RTC, . What reference are you looking for ? Thx, R. From randy@psg.com Fri Sep 13 13:23:09 2013 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 30F5B21E80AA for ; Fri, 13 Sep 2013 13:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81TBD8KHxKUc for ; Fri, 13 Sep 2013 13:23:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id B66C821E8092 for ; Fri, 13 Sep 2013 13:23:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VKZtD-0002Xb-36; Fri, 13 Sep 2013 20:22:51 +0000 Date: Fri, 13 Sep 2013 10:22:49 -1000 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <026801ceb0b4$ea17c030$be474090$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] 2 Week Working Group Adoption 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, 13 Sep 2013 20:23:09 -0000 robert, >> does anyone have any reference for the "APGW Automation" >> implementation? > It's NTT I3 internal BGP implementation of VPNv4, VPNv6 and RTC, . > What reference are you looking for ? thanks. would have been nice if both implementations were public, allowing a reproducible experiment. but what the heck. randy From thomas.mangin@exa-networks.co.uk Fri Sep 13 13:27:59 2013 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 9ED5521E80AA; Fri, 13 Sep 2013 13:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkZvghuClvJN; Fri, 13 Sep 2013 13:27:54 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id 8250511E80D3; Fri, 13 Sep 2013 13:27:54 -0700 (PDT) Received: from smtp-4.mail.exa.net.uk (smtp-4.mail.exa.net.uk [82.219.5.4]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 31E9EA0088; Fri, 13 Sep 2013 21:27:52 +0100 (BST) Received: from [82.219.212.37] (ptr-37.212.219.82.rev.exa.net.uk [82.219.212.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-4.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id E25E24006B; Fri, 13 Sep 2013 21:27:51 +0100 (BST) References: <026801ceb0b4$ea17c030$be474090$@ndzh.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2BEB26DD-D9BD-4C6E-A94F-B94329D501E2@exa-networks.co.uk> X-Mailer: iPad Mail (10B329) From: Thomas Mangin Date: Fri, 13 Sep 2013 21:27:51 +0100 To: "idr-bounces@ietf.org" X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: idr wg , Robert Raszuk Subject: Re: [Idr] 2 Week Working Group Adoption 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, 13 Sep 2013 20:27:59 -0000 Someone give me a week and a bgp session to a BGP speaker supporting the fea= ture and I can have the feature in ExaBGP ... Sent from my iPad On 13 Sep 2013, at 21:22, Randy Bush wrote: > robert, >=20 >>> does anyone have any reference for the "APGW Automation" >>> implementation? >> It's NTT I3 internal BGP implementation of VPNv4, VPNv6 and RTC, . >> What reference are you looking for ? >=20 > thanks. would have been nice if both implementations were public, > allowing a reproducible experiment. but what the heck. >=20 > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From randy@psg.com Fri Sep 13 13:30:28 2013 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 A583D11E80D3 for ; Fri, 13 Sep 2013 13:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwmhATwmhvJ7 for ; Fri, 13 Sep 2013 13:30:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 32C7B11E80FF for ; Fri, 13 Sep 2013 13:30:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VKa0Y-0002Ya-SA; Fri, 13 Sep 2013 20:30:27 +0000 Date: Fri, 13 Sep 2013 10:30:25 -1000 Message-ID: From: Randy Bush To: Thomas Mangin In-Reply-To: <2BEB26DD-D9BD-4C6E-A94F-B94329D501E2@exa-networks.co.uk> References: <026801ceb0b4$ea17c030$be474090$@ndzh.com> <2BEB26DD-D9BD-4C6E-A94F-B94329D501E2@exa-networks.co.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: Keyur Patel , idr wg Subject: Re: [Idr] 2 Week Working Group Adoption 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, 13 Sep 2013 20:30:28 -0000 > Someone give me a week and a bgp session to a BGP speaker supporting > the feature and I can have the feature in ExaBGP ... > ... >> thanks. would have been nice if both implementations were public, >> allowing a reproducible experiment. but what the heck. if keyur can give me an image which supports it, i can set up a multi-hop bgp peer for you. randy From warren@kumari.net Fri Sep 13 13:59:45 2013 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 7E1B711E80F1 for ; Fri, 13 Sep 2013 13:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiNpKUULpaDv for ; Fri, 13 Sep 2013 13:59:39 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF7311E8129 for ; Fri, 13 Sep 2013 13:59:39 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id C82A21B401BE; Fri, 13 Sep 2013 16:59:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> Date: Fri, 13 Sep 2013 16:59:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0D7A45DD-85F8-47CA-A006-B7B79F7017D7@kumari.net> References: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1508) Cc: idr wg , erosen@cisco.com, "'John G. Scudder'" , 'Yakov Rekhter' Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-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, 13 Sep 2013 20:59:45 -0000 On Sep 13, 2013, at 3:03 PM, Susan Hares wrote: > Just in case the last message on this topic got caught in August = doldrums, we are extending the WG last call for 1 more week:=20 > IANA Registries for BGP Extended Communities > draft-ietf-idr-extcomm-iana-00.txt > https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ > What this document does: > This document reorganizes the IANA Registries for the type values and = sub-type values of BGP Extended Communities attribute and the BGP = IPv6-Address-Specific Extended Communities attribute. > Without additional Votes for approval, this document will not pass WG = last call. Read. Support. > Sue and John =20 > Idr-co-chairs > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --=20 "I think it would be a good idea."=20 - Mahatma Ghandi, when asked what he thought of Western civilization From zzhang@juniper.net Fri Sep 13 14:08:24 2013 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 A0EB621E80C0 for ; Fri, 13 Sep 2013 14:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuSxl4wRKpZG for ; Fri, 13 Sep 2013 14:08:19 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 09FB511E818A for ; Fri, 13 Sep 2013 14:08:17 -0700 (PDT) Received: from mail215-db9-R.bigfish.com (10.174.16.233) by DB9EHSOBE023.bigfish.com (10.174.14.86) with Microsoft SMTP Server id 14.1.225.22; Fri, 13 Sep 2013 21:08:16 +0000 Received: from mail215-db9 (localhost [127.0.0.1]) by mail215-db9-R.bigfish.com (Postfix) with ESMTP id 967B31A0229 for ; Fri, 13 Sep 2013 21:08:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail215-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=zzhang@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(51704005)(24454002)(377454003)(47736001)(66066001)(49866001)(15975445006)(33646001)(74876001)(4396001)(50986001)(46102001)(47976001)(80022001)(65816001)(19580395003)(51856001)(63696002)(81816001)(74706001)(81686001)(74366001)(76482001)(54356001)(53806001)(69226001)(59766001)(56776001)(76576001)(76786001)(76796001)(83072001)(81342001)(79102001)(80976001)(83322001)(74662001)(74316001)(19580405001)(81542001)(54316002)(77982001)(31966008)(56816003)(74502001)(47446002)(77096001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB077; H:BY2PR05MB079.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail215-db9 (localhost.localdomain [127.0.0.1]) by mail215-db9 (MessageSwitch) id 1379106494115610_29126; Fri, 13 Sep 2013 21:08:14 +0000 (UTC) Received: from DB9EHSMHS006.bigfish.com (unknown [10.174.16.231]) by mail215-db9.bigfish.com (Postfix) with ESMTP id 16909480045 for ; Fri, 13 Sep 2013 21:08:14 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS006.bigfish.com (10.174.14.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 13 Sep 2013 21:08:13 +0000 Received: from BY2PR05MB077.namprd05.prod.outlook.com (10.242.38.11) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Fri, 13 Sep 2013 21:08:13 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB077.namprd05.prod.outlook.com (10.242.38.11) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 13 Sep 2013 21:08:11 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.110]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.110]) with mapi id 15.00.0745.000; Fri, 13 Sep 2013 21:08:11 +0000 From: "Jeffrey (Zhaohui) Zhang" To: idr wg Thread-Topic: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt Thread-Index: AQHOsMQ7UZYSZk9b1kaazvYs5VDjs5nEKLnQ Date: Fri, 13 Sep 2013 21:08:10 +0000 Message-ID: <8ad9ed2ebdfd4ce58db0fa84de211522@BY2PR05MB079.namprd05.prod.outlook.com> References: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> <0D7A45DD-85F8-47CA-A006-B7B79F7017D7@kumari.net> In-Reply-To: <0D7A45DD-85F8-47CA-A006-B7B79F7017D7@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0968D37274 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-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, 13 Sep 2013 21:08:24 -0000 Support. > On Sep 13, 2013, at 3:03 PM, Susan Hares wrote: >=20 > > Just in case the last message on this topic got caught in August > doldrums, we are extending the WG last call for 1 more week: > > IANA Registries for BGP Extended Communities > > draft-ietf-idr-extcomm-iana-00.txt > > https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ > > What this document does: > > This document reorganizes the IANA Registries for the type values and > sub-type values of BGP Extended Communities attribute and the BGP IPv6- > Address-Specific Extended Communities attribute. > > Without additional Votes for approval, this document will not pass WG > last call. > =20 > > Sue and John > > Idr-co-chairs > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr From marco@juniper.net Fri Sep 13 14:18:04 2013 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 1675C21E80C7 for ; Fri, 13 Sep 2013 14:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX8r0SKdwb0b for ; Fri, 13 Sep 2013 14:17:59 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id E43A011E80D2 for ; Fri, 13 Sep 2013 14:17:58 -0700 (PDT) Received: from mail21-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.22; Fri, 13 Sep 2013 21:17:58 +0000 Received: from mail21-co1 (localhost [127.0.0.1]) by mail21-co1-R.bigfish.com (Postfix) with ESMTP id 081ABC40199; Fri, 13 Sep 2013 21:17:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371Ic85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah18c673h1de097h186068h8275bh8275dhz2fh2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h1155h) Received-SPF: pass (mail21-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=marco@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(377454003)(80976001)(83072001)(19300405004)(81686001)(74502001)(74662001)(47446002)(76482001)(31966008)(81816001)(83322001)(19580405001)(15975445006)(66066001)(69226001)(74366001)(54316002)(56776001)(19580395003)(63696002)(54356001)(76176001)(36756003)(51856001)(74706001)(46102001)(49866001)(47736001)(47976001)(50986001)(74876001)(4396001)(59766001)(53806001)(80022001)(56816003)(77096001)(16236675002)(76796001)(15202345003)(76786001)(81342001)(83506001)(79102001)(77982001)(81542001)(65816001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB218; H:BN1PR05MB075.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail21-co1 (localhost.localdomain [127.0.0.1]) by mail21-co1 (MessageSwitch) id 1379107076527318_10200; Fri, 13 Sep 2013 21:17:56 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.229]) by mail21-co1.bigfish.com (Postfix) with ESMTP id 761238C006B; Fri, 13 Sep 2013 21:17:56 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 13 Sep 2013 21:17:55 +0000 Received: from BN1PR05MB218.namprd05.prod.outlook.com (10.255.206.20) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.353.4; Fri, 13 Sep 2013 21:17:54 +0000 Received: from BN1PR05MB075.namprd05.prod.outlook.com (10.255.199.21) by BN1PR05MB218.namprd05.prod.outlook.com (10.255.206.20) with Microsoft SMTP Server (TLS) id 15.0.775.9; Fri, 13 Sep 2013 21:17:52 +0000 Received: from BN1PR05MB075.namprd05.prod.outlook.com ([169.254.11.251]) by BN1PR05MB075.namprd05.prod.outlook.com ([169.254.11.251]) with mapi id 15.00.0775.005; Fri, 13 Sep 2013 21:17:52 +0000 From: Marco Rodrigues To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt Thread-Index: AQHOsMa02K3/eUnyXU+OyNiNFn0Gjg== Date: Fri, 13 Sep 2013 21:17:51 +0000 Message-ID: In-Reply-To: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [66.129.232.2] x-forefront-prvs: 0968D37274 Content-Type: multipart/alternative; boundary="_000_CE58F93417E5A1marcojunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Yakov Rekhter , "erosen@cisco.com" , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-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, 13 Sep 2013 21:18:04 -0000 --_000_CE58F93417E5A1marcojunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Marco. From: Susan Hares > Date: Friday, September 13, 2013 3:03 PM To: idr wg > Cc: "erosen@cisco.com" >, "'John G. Scudder'" >, Yako= v Rekhter > Subject: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt Just in case the last message on this topic got caught in August doldrums, = we are extending the WG last call for 1 more week: IANA Registries for BGP Extended Communities draft-ietf-idr-extcomm-iana-00.txt https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ What this document does: This document reorganizes the IANA Registries for the type values and sub-t= ype values of BGP Extended Communities attribute and the BGPIPv6-Address-Sp= ecific Extended Communities attribute. Without additional Votes for approval, this document will not pass WG last = call. Sue and John Idr-co-chairs --_000_CE58F93417E5A1marcojunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support.

Marco.

From: Susan Hares <shares@ndzh.com>
Date: Friday, September 13, 2013 3:= 03 PM
To: idr wg <idr@ietf.org>
Cc: "erosen@cisco.com" <erosen@cisco.com>, "'John G. Scudder'" <jgs@bgp.nu>, Yakov Rekhter <yakov@juniper.net>
Subject: [Idr] WG LC for draft-ietf= -idr-extcomm-iana-00.txt

Just in case the last message on this topic got caught in August = doldrums, we are extending the WG last call for 1 more week: 

IANA Registries for BGP Extended Communities

draft-ietf-idr-extcomm-iana-00.txt

https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/<= /span>

What this document does:

= This document reorganizes the IANA Registries for the type values and sub-t= ype values of BGP Extended Communities attribute and the BGPIPv6-Address-Specific Extended Communities attribute.

Without additional Votes for approval, this document will not pass= WG last call.

Sue and John  <= /span>

Idr-co-chairs=

--_000_CE58F93417E5A1marcojunipernet_-- From bhavani@cisco.com Fri Sep 13 16:01:59 2013 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 6612621E8056 for ; Fri, 13 Sep 2013 16:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCkg-wwDDH9Z for ; Fri, 13 Sep 2013 16:01:55 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0188A21E8053 for ; Fri, 13 Sep 2013 16:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=839; q=dns/txt; s=iport; t=1379113315; x=1380322915; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=QwyVAhU7iqCvmeUUNSMK7Z9lJAjJDChXK6e6CWRNKmo=; b=kWz/udpqtll/JDl8xNDzNRLNPLcI3nWa0Idb8ui9xe9J1lI/z3wRjkt7 Y+n5bD9I2QK90IXmyaW3KHKE3q/hsNtbcIu9eBNsOgCVPY5JOpCM8pATm z+rzdUSCnezjuFznZDI7/sxo6AFK+gnkDNyo07H9JiFyc1Y2KYYAv2KNp Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0HANGYM1KrRDoI/2dsb2JhbABbgwc4gzWxHox6gR0WdIIlAQEBBAEBARobNgoRCxgJFg8JAwIBAgEVMBMGAgEBh34NuTqPeBaECAOJOI5CgS+FAYtEg0Qc X-IronPort-AV: E=Sophos;i="4.90,901,1371081600"; d="scan'208";a="91784266" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 13 Sep 2013 23:01:48 +0000 Received: from [10.154.210.20] ([10.154.210.20]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8DN1lBg030836 for ; Fri, 13 Sep 2013 23:01:47 GMT Message-ID: <5233995B.2060906@cisco.com> Date: Fri, 13 Sep 2013 16:01:47 -0700 From: Bhavani Parise User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: idr@ietf.org References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> In-Reply-To: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh 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, 13 Sep 2013 23:01:59 -0000 Support both regards, Bhavani On 9/13/13 12:31 PM, Susan Hares wrote: > This begins a 2 week working group last call for (ending 9/27) > Enhanced Route Refresh Capability for BGP-4 > http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-04 > > This WG last call is in parallel with the 2 week > implementation report adoption call. > > The implementation report is at: > http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-impl/ > > We will read both threads in considering the last call. If the > implementation report is accepted, we will do a last call on the > implementation report. > > Sue Hares and John Scudder > Idr co-chairs > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From shares@ndzh.com Fri Sep 13 16:06:30 2013 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 B29F121F9D3B for ; Fri, 13 Sep 2013 16:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLTiQmvcQgpF for ; Fri, 13 Sep 2013 16:06:26 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4419D21F99CD for ; Fri, 13 Sep 2013 16:06:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.228.15; From: "Susan Hares" To: "idr wg" Date: Fri, 13 Sep 2013 19:06:19 -0400 Message-ID: <000001ceb0d5$db6f4c30$924de490$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CEB0B4.5461A3D0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac6w08wdfTQQ5+oUT+KHARdIlbU9Zw== X-Authenticated-User: skh@ndzh.com Cc: "'John G. Scudder'" Subject: [Idr] 2 Week WG LC for Early Code points. 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, 13 Sep 2013 23:06:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CEB0B4.5461A3D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is a 2 Week (ending Sept 27) last call to assign early code points (per RFC4020) to North-Bound Distribution of Link-State and TE Information using BGP draft-ietf-idr-ls-distribution-03 http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ per RFC 4020 (see info below), the authors have requested early code points be assigned to this draft. John and Sue (WG chairs) agree that early code points will help develop this IDR draft. We are step three below. Do you all think this effort should get early code points? If so vote early and often. Sue and John --------------- 3.1. Request The process for requesting and obtaining early allocation of code points is as follows: 1) The authors (editors) of the document submit a request for early allocation to the Working Group chairs, specifying which code points require early allocation and which document they should be assigned to. 2) The WG chairs determine whether the conditions for early allocations described in section 2 are met; particularly, conditions (c) and (d). 3) The WG chairs gauge whether there is consensus within the WG that early allocation is appropriate in the case of the given document. 4) If it is, with the approval of the Area Director(s), the WG chairs request IANA to make an early allocation. 5) IANA makes an allocation from the appropriate registry, marking it as "temporary", valid for a period of one year from the date of allocation. The date of allocation should also be recorded in the registry and made visible to the public. ------=_NextPart_000_0001_01CEB0B4.5461A3D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a 2 Week = (ending Sept 27) last call to assign early code points (per RFC4020) to =

 

  North-Bound = Distribution of Link-State and TE Information using = BGP

= draft-ietf-idr-ls-distribution-03

 

= http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/<= /o:p>

 

per RFC 4020 (see = info below), the authors have requested early code points be assigned to = this draft.

John and Sue (WG = chairs) agree that early code points will help develop this IDR draft. =

We are step three = below. 

 

Do you all think = this effort should get early code points? If so vote early and often. =

 

Sue and John =

 

---------------

3.1.  = Request

   The process for =
requesting and obtaining early allocation of =
code
   points is as =
follows:
 
   1) The authors =
(editors) of the document submit a request for =
early
      =
allocation to the Working Group chairs, specifying which =
code
      =
points require early allocation and which document they should =
be
      =
assigned to.
 
   2) The WG chairs =
determine whether the conditions for early
      =
allocations described in section 2 are =
met; particularly,
      =
conditions (c) and (d).
 
   3) The WG chairs =
gauge whether there is consensus within the WG =
that
      =
early allocation is appropriate in the case of the given =
document.
 
   4) If it is, with the =
approval of the Area Director(s), the WG =
chairs
      =
request IANA to make an early allocation.
 
   5) IANA makes an =
allocation from the appropriate registry, marking =
it
      as =
"temporary", valid for a period of one year from the date =
of
      =
allocation.  The date of allocation should also be recorded in =
the
      =
registry and made visible to the public.

 

------=_NextPart_000_0001_01CEB0B4.5461A3D0-- From shares@ndzh.com Fri Sep 13 16:12:54 2013 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 424DC21E8053 for ; Fri, 13 Sep 2013 16:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJmY3Byzx2oQ for ; Fri, 13 Sep 2013 16:12:50 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0D47111E8216 for ; Fri, 13 Sep 2013 16:12:49 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.228.15; From: "Susan Hares" To: "idr wg" Date: Fri, 13 Sep 2013 19:12:43 -0400 Message-ID: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01CEB0B5.39907260" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac6w1mK9oZDNOu+SQiq0dAmRJ9YB/g== X-Authenticated-User: skh@ndzh.com Cc: "'John G. Scudder'" Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) 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, 13 Sep 2013 23:12:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000E_01CEB0B5.39907260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is to start at 2 week WG last call for The Accumulated IGP Metric Attribute for BGP draft-ietf-idr-aigp-10.txt http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ This last call will end 9/27/13 Three implementations exist: ALU, Cisco, Juniper. Vote early and speak often. Sue and John IDR co-chairs ------=_NextPart_000_000E_01CEB0B5.39907260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to = start at 2 week WG last call for

 

The Accumulated IGP = Metric Attribute for BGP

draft-ietf-idr-aigp-10.txt

 

http://data= tracker.ietf.org/doc/draft-ietf-idr-aigp/

 

This last = call will end 9/27/13

 

Three = implementations exist: ALU, Cisco, Juniper.

 

Vote early = and speak often.

 

Sue and John =

IDR co-chairs

 

------=_NextPart_000_000E_01CEB0B5.39907260-- From bill.wu@huawei.com Sun Sep 15 18:40:59 2013 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 4949411E818D for ; Sun, 15 Sep 2013 18:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlPPycI6tPj0 for ; Sun, 15 Sep 2013 18:40:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 01E0611E8189 for ; Sun, 15 Sep 2013 18:40:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVK95133; Mon, 16 Sep 2013 01:40:41 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 16 Sep 2013 02:40:14 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 16 Sep 2013 02:40:37 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0146.000; Mon, 16 Sep 2013 09:40:29 +0800 From: Qin Wu To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: Ac6wt8D1L5sinGlEQF6dDpyxwQSmIABw0HOw Date: Mon, 16 Sep 2013 01:40:29 +0000 Message-ID: References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> In-Reply-To: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 01:40:59 -0000 Section 3, paragraph 3 said: " When a route entry in the "ADJ-RIB- Out" changes, the advertisement of the modified route entry (instead of the snapshot entry) would suffice. " What message subtype is used when sending Route Refresh message in case of = the advertisement of the modified route entry? No Route message is sent in this case? Regards! -Qin From erosen@cisco.com Mon Sep 16 11:26:39 2013 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 50B2511E82EA for ; Mon, 16 Sep 2013 11:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMuPot2beZkB for ; Mon, 16 Sep 2013 11:26:33 -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 EA18321F9D92 for ; Mon, 16 Sep 2013 11:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1281; q=dns/txt; s=iport; t=1379355993; x=1380565593; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=sil2HRGX1/0qtXVjZ8TLu9EX1n1jdoNs5Qj37D81M+Y=; b=PI5br7OLkGLxci6tKQrSfyzgObIBOT2AF8fsuJ1bH+fwtfvC9Nvk6B5o JdbizO2/XZwSMTL6Bgl3zO964VxjxuLe+YkQtdwoq+CEebo0H8D2cu3hp nZu8BsPczbLQv+qbzVi9HarA7UscHEsiZsSt9d0PRRcczqX/hjkHT3LAe o=; X-IronPort-AV: E=Sophos;i="4.90,917,1371081600"; d="scan'208";a="260528492" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 16 Sep 2013 18:26:32 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8GIQVwr027661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Sep 2013 18:26:32 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r8GIQVdl030294; Mon, 16 Sep 2013 14:26:31 -0400 From: Eric Rosen To: Qin Wu In-reply-to: Your message of Fri, 13 Sep 2013 02:22:33 -0000. Date: Mon, 16 Sep 2013 14:26:31 -0400 Message-ID: <30293.1379355991@erosen-linux> Cc: idr wg , erosen@cisco.com, Susan Hares , 'Yakov Rekhter' Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 18:26:39 -0000 > I believe it is better to add a reference to each registry to point out > Where the attributed is defined and how to use this attribute. These references should appear on the IANA web page (where the line length is not restricted to 72 characters), but we didn't think it necessary to include them in the draft > I believe IPv6-address-Specific Extended Community should use the similar > Syntax as the other registries, i.e., using 1st octet to indicate type and > 2nd Octet to indicate subtype. To me, there's not much value in having separate Sub-Type registries for the IPv6-address-specific extended communities, as an IPv6-address-specific extended community always begins with two octets of registered codepoint. This is much simpler than the case of the "ordinary" extended communities, which may begin with either octet or two octets of registered codepoint. So I think what we have proposed is satisfactory. Of course, your proposal would work also. (What makes it complicated to administer the codepoints for the "ordinary" extended communities is that fact that the sub-type field isn't necessarily present; sometimes the second octet is part of the value field. The IPv6-address-specific extended community doesn't have this issue.) From thomas.mangin@exa-networks.co.uk Tue Sep 17 10:50:14 2013 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 8614E11E82AC for ; Tue, 17 Sep 2013 10:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3baOqIzDJzb9 for ; Tue, 17 Sep 2013 10:50:09 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE8911E8540 for ; Tue, 17 Sep 2013 10:49:54 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 7BA1EA019D; Tue, 17 Sep 2013 18:49:52 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 43A6B6C0047; Tue, 17 Sep 2013 18:49:52 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Mangin In-Reply-To: Date: Tue, 17 Sep 2013 18:49:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <09773E17-235A-45EC-BEF3-9CAFADEEC23F@exa-networks.co.uk> References: <026801ceb0b4$ea17c030$be474090$@ndzh.com> <2BEB26DD-D9BD-4C6E-A94F-B94329D501E2@exa-networks.co.uk> To: randy@psg.com X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: Keyur Patel , idr wg Subject: Re: [Idr] 2 Week Working Group Adoption X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 17:50:14 -0000 On 13 Sep 2013, at 21:30, Randy Bush wrote: >> Someone give me a week and a bgp session to a BGP speaker supporting >> the feature and I can have the feature in ExaBGP ... >> ... >>> thanks. would have been nice if both implementations were public, >>> allowing a reproducible experiment. but what the heck. The code of ExaBGP currently on github has support for the draft since = this week-end. Two ExaBGP speaking to each other can exchange enhanced = route-refresh messages but the interoperability with other = implementation was not yet done. As I am not sure neither what notification code has been agreed between = Cisco and NTT, I did not implement the required notification in case of = invalid message yet. Sending multiple ERR sent at once should work but is untested yet. Sincerely, Thomas --- Self check on a mac : > ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)" > brew install git terminal one : > git clone git@github.com:Thomas-Mangin/exabgp.git > cd exabgp/dev/self/refresh > ./first terminal two : > cd exabgp/dev/self/refresh > ./second The first peer will display something like this : received neighbor update start received neighbor announced route 1.0.0.0/25 next-hop 9.9.9.9 = origin igp local-preference 100 received neighbor update end received received neighbor update start received neighbor announced route 1.0.0.128/25 next-hop 9.9.9.9 = origin igp local-preference 100 received neighbor update end received received neighbor update start received neighbor announced route eor 1/1 (ipv4 unicast) received neighbor update end received announce route-refresh ipv4 unicast received neighbor route-refresh afi ipv4 safi unicast begin received neighbor update start received neighbor announced route 1.0.0.0/25 next-hop 9.9.9.9 = origin igp local-preference 100 received neighbor update end received received neighbor update start received neighbor announced route 1.0.0.128/25 next-hop 9.9.9.9 = origin igp local-preference 100 received neighbor update end received received neighbor route-refresh afi ipv4 safi unicast end From jgs@juniper.net Wed Sep 18 08:41:33 2013 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 4DCA911E82F1 for ; Wed, 18 Sep 2013 08:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVE1OYwc36EQ for ; Wed, 18 Sep 2013 08:41:28 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id A680611E82FB for ; Wed, 18 Sep 2013 08:40:04 -0700 (PDT) Received: from mail2-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.22; Wed, 18 Sep 2013 15:40:01 +0000 Received: from mail2-ch1 (localhost [127.0.0.1]) by mail2-ch1-R.bigfish.com (Postfix) with ESMTP id BBEF62602CD; Wed, 18 Sep 2013 15:40:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz98dI9371I146fI1432I1453I4015I168aJzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail2-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(57704003)(377454003)(199002)(189002)(24454002)(52034003)(164054003)(51704005)(52314003)(50226001)(49866001)(36756003)(15975445006)(47976001)(76796001)(50986001)(66066001)(82746002)(81816001)(81686001)(69226001)(77156001)(56816003)(81542001)(33656001)(23726002)(47736001)(77096001)(15202345003)(81342001)(51856001)(80022001)(74706001)(46102001)(57306001)(31966008)(74662001)(42186004)(77982001)(79102001)(65816001)(74876001)(53806001)(76786001)(74366001)(74502001)(4396001)(47446002)(46406003)(63696002)(80976001)(62966002)(76482001)(54316002)(50466002)(83072001)(59766001)(56776001)(19580405001)(19580395003)(47776003)(83322001)(83716001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:[172.28.131.154]; CLIP:66 Received: from mail2-ch1 (localhost.localdomain [127.0.0.1]) by mail2-ch1 (MessageSwitch) id 1379518799862763_22229; Wed, 18 Sep 2013 15:39:59 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail2-ch1.bigfish.com (Postfix) with ESMTP id C4A2D2004A; Wed, 18 Sep 2013 15:39:59 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 18 Sep 2013 15:39:59 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.359.1; Wed, 18 Sep 2013 15:39:59 +0000 Received: from [172.28.131.154] (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 18 Sep 2013 15:39:55 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "John G. Scudder" In-Reply-To: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> Date: Wed, 18 Sep 2013 11:39:40 -0400 Content-Transfer-Encoding: 7bit Message-ID: <15455006-B087-43D4-9D4D-6F7E7B45D545@juniper.net> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> To: Hares Susan , "Keyur Patel (keyupate)" X-Mailer: Apple Mail (2.1510) X-Originating-IP: [66.129.232.2] X-ClientProxiedBy: BLUPR02CA009.namprd02.prod.outlook.com (10.255.223.157) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) X-Forefront-PRVS: 09730BD177 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: idr wg Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh 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, 18 Sep 2013 15:41:33 -0000 Summary: based on the below review, I think the document is not yet done. - The document needs an "Updates: RFC2918" header - " A BGP speaker that support the message subtypes for the ROUTE-REFRESH" s/support/supports/ This was previously noted by Randy Bush, IIRC. BTW, I don't claim to be an expert grammarian but other than what I've noted in this review I don't see any problems. - " Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a ROUTE-REFRESH message with the specified message subtype to mark the beginning of the route refresh. After the speaker completes the re-advertisement of the entire Adj- RIB-Out to the peer, it MUST send a ROUTE-REFRESH message with the specified message subtype to mark the ending of the route refresh." Presumably in the first case, the "specified message subtype" is the "Demarcation of the beginning of a route refresh" subtype 1, and in the second case, the "specified message subtype" is the "Demarcation of the ending of a route refresh" subtype 2. Say that explicitly (either by the name, the type code, or both). See also the second-last point in this review, about short symbolic names. - " Conceptually the "entire ADJ-RIB-Out" for a peer in this section refers to all the route entries in the "ADJ-RIB-Out" for the peer at the start of the route refresh. When a route entry in the "ADJ-RIB- Out" changes, the advertisement of the modified route entry (instead of the snapshot entry) would suffice." (By the way, s/ADJ/Adj/g) As Qin Wu's message suggests, this text isn't clear enough. Part of the problem is that you haven't defined "snapshot" but I think it goes beyond that. One way I can think of to fix it would be to simply remove the paragraph, on the assumption that "advertise the entire Adj-RIB-Out" is sufficiently obvious to an implementor, and that's all you're really trying to specify here. Otherwise, I think you're going to have to specify more rigorously what you mean by "advertise the entire Adj-RIB-Out". In particular, I suspect you're trying to bound the time you have to spend before you send the subcode 2 message to be O(size of Adj-RIB-Out when you started), so that you're not tripped up by pathological cases? I don't have text to offer for this case, but I do think the authors and WG need to consider it. - I don't think this text is right: " In processing a ROUTE-REFRESH message from a peer, the BGP speaker MUST examine the "message subtype" field of the message and take the appropriate actions." I mean, it's OK, except it basically says "do the right thing" ("take the appropriate actions"). The spec either needs to say unambiguously what the right thing is (if it's a MUST) or adopt some more relaxed tone. Likewise, "The BGP speaker SHALL use the demarcations of the beginning and the ending of a route refresh to perform consistency validations of the updates received from the peer." At most, the speaker MAY do that. If we wanted to mandate it (and I don't think we do) we would need to say what "perform consistency validations" means. I would be OK with either striking the text, or changing the SHALL to a MAY. Here is a possible rewrite of the paragraph: When a BGP speaker receives a Route Refresh message from a peer with subtype 1 it MUST mark all routes with the given AFI/SAFI from that peer as stale. As it receives routes from its peer's subsequent Adj-RIB-Out readvertisement, these replace any corresponding stale routes. When the BGP speaker receives a Route Refresh message from the peer with subtype 2, it MUST immediately remove any routes from the peer that are still marked as stale for that address family. Such routes MAY be logged for further analysis. (It can be observed that this procedure is substantially the same as for the Restarting Speaker in Section 4.2 of [RFC4724].) - RFC 4724 has a timer to deal with the case where the Restarting Speaker forgets to send the EoR. Subcode 2 is basically an EoR, but we have no timer. Is this a problem? Do we need some other kind of safety mechanism? Or are we happy to just rely on the correctness of the implementation (ahem). - During the initial Adj-RIB-Out advertisement, can normal withdraws be sent? I assume so. Not sure if anything need be said about this. - The Error Handling section of the draft assumes traditional RFC 4271 style error handling, namely if you see something wrong, reset the session. Is this the right thing to do in light of the other work the WG has been doing with draft-ietf-idr-error-handling? For that matter, is this the right thing to do in light of the fact that regular route-refresh messages aren't specified to behave in this way? I don't *necessarily* propose that malformed refresh messages should be ignored, but it seems worth discussing. If this stricter approach is adopted, should it be considered for regular Route Refresh too, and if so, should that go in this document? Also, assuming the current error approach is kept, why not go whole hog and finish enumerating the possible error conditions? I think there's only one other: Invalid Subtype. (See also my final point below.) - What is the expected behavior if the peer sends another Route Refresh request when the first request is still in progress (subtype 2 has not yet been sent)? One option is that you could cancel the old refresh, send another subtype 1, then the new refresh, then close it with a subtype 2. But this implies there would be two subtype 1's followed by only one subtype 2. Another way of asking this question is whether there are any restrictions on the interleaving of subtype 1 and 2, and what error handling (if any) is to be applied if the restrictions (if any) are violated. - In the Acks, you need to capitalize Jeff Hass's last name. - In writing this review I've had to choose several times between referring to "subcode 1" and "subcode 2" (not very descriptive) and "Demarcation of the beginning of a route refresh" and "Demarcation of the ending of a route refresh" (verbose). This leads me to think it might be handy for the document to provide short symbolic names for the subtypes, such as BoRR and EoRR. - By the way, now that you've turned the "reserved" field into a "subtype" field, you need to decide what to do with the rest of the values. Right now we have 0 which means either route-refresh or ORF (disambiguated by length) and 1 and 2 defined in this document. The obvious thing to do would be to make this a registry, though then you have to say what to do with unrecognized values. Come to think of it, you have to say that anyway, right now the Error Handling section doesn't cover it. Thanks, --John On Sep 13, 2013, at 3:31 PM, Susan Hares wrote: > This begins a 2 week working group last call for (ending 9/27) > Enhanced Route Refresh Capability for BGP-4 > http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-04 > > This WG last call is in parallel with the 2 week > implementation report adoption call. > > The implementation report is at: > http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-impl/ > > We will read both threads in considering the last call. If the > implementation report is accepted, we will do a last call on the > implementation report. > > Sue Hares and John Scudder > Idr co-chairs > > > > > From jgs@juniper.net Wed Sep 18 08:42:24 2013 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 669EA11E8256 for ; Wed, 18 Sep 2013 08:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdCZYl-VI-zk for ; Wed, 18 Sep 2013 08:42:24 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id A448211E8160 for ; Wed, 18 Sep 2013 08:42:14 -0700 (PDT) Received: from mail118-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE037.bigfish.com (10.236.130.100) with Microsoft SMTP Server id 14.1.225.22; Wed, 18 Sep 2013 15:42:14 +0000 Received: from mail118-co9 (localhost [127.0.0.1]) by mail118-co9-R.bigfish.com (Postfix) with ESMTP id D54E01001D0; Wed, 18 Sep 2013 15:42:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz98dI9371I146fI1432I1453I4015I168aJzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail118-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(57704003)(377454003)(199002)(189002)(24454002)(52034003)(164054003)(51704005)(52314003)(50226001)(49866001)(36756003)(15975445006)(47976001)(76796001)(50986001)(66066001)(82746002)(81816001)(81686001)(69226001)(77156001)(56816003)(81542001)(33656001)(23726002)(47736001)(77096001)(15202345003)(81342001)(51856001)(80022001)(74706001)(46102001)(57306001)(31966008)(74662001)(42186004)(77982001)(79102001)(65816001)(74876001)(53806001)(76786001)(74366001)(74502001)(4396001)(47446002)(46406003)(63696002)(80976001)(62966002)(76482001)(54316002)(50466002)(83072001)(59766001)(56776001)(19580405001)(19580395003)(47776003)(83322001)(83716001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:[172.28.131.154]; CLIP:66 Received: from mail118-co9 (localhost.localdomain [127.0.0.1]) by mail118-co9 (MessageSwitch) id 1379518855692341_7846; Wed, 18 Sep 2013 15:40:55 +0000 (UTC) Received: from CO9EHSMHS028.bigfish.com (unknown [10.236.132.253]) by mail118-co9.bigfish.com (Postfix) with ESMTP id A4688AC004B; Wed, 18 Sep 2013 15:40:55 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS028.bigfish.com (10.236.130.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 18 Sep 2013 15:40:55 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.359.1; Wed, 18 Sep 2013 15:40:54 +0000 Received: from [172.28.131.154] (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 18 Sep 2013 15:40:52 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "John G. Scudder" In-Reply-To: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> Date: Wed, 18 Sep 2013 11:39:40 -0400 Content-Transfer-Encoding: 7bit Message-ID: <15455006-B087-43D4-9D4D-6F7E7B45D545@juniper.net> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> To: Hares Susan , "Keyur Patel (keyupate)" X-Mailer: Apple Mail (2.1510) X-Originating-IP: [66.129.232.2] X-ClientProxiedBy: BLUPR02CA006.namprd02.prod.outlook.com (10.255.223.154) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) X-Forefront-PRVS: 09730BD177 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: idr wg Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh 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, 18 Sep 2013 15:42:24 -0000 Summary: based on the below review, I think the document is not yet done. - The document needs an "Updates: RFC2918" header - " A BGP speaker that support the message subtypes for the ROUTE-REFRESH" s/support/supports/ This was previously noted by Randy Bush, IIRC. BTW, I don't claim to be an expert grammarian but other than what I've noted in this review I don't see any problems. - " Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a ROUTE-REFRESH message with the specified message subtype to mark the beginning of the route refresh. After the speaker completes the re-advertisement of the entire Adj- RIB-Out to the peer, it MUST send a ROUTE-REFRESH message with the specified message subtype to mark the ending of the route refresh." Presumably in the first case, the "specified message subtype" is the "Demarcation of the beginning of a route refresh" subtype 1, and in the second case, the "specified message subtype" is the "Demarcation of the ending of a route refresh" subtype 2. Say that explicitly (either by the name, the type code, or both). See also the second-last point in this review, about short symbolic names. - " Conceptually the "entire ADJ-RIB-Out" for a peer in this section refers to all the route entries in the "ADJ-RIB-Out" for the peer at the start of the route refresh. When a route entry in the "ADJ-RIB- Out" changes, the advertisement of the modified route entry (instead of the snapshot entry) would suffice." (By the way, s/ADJ/Adj/g) As Qin Wu's message suggests, this text isn't clear enough. Part of the problem is that you haven't defined "snapshot" but I think it goes beyond that. One way I can think of to fix it would be to simply remove the paragraph, on the assumption that "advertise the entire Adj-RIB-Out" is sufficiently obvious to an implementor, and that's all you're really trying to specify here. Otherwise, I think you're going to have to specify more rigorously what you mean by "advertise the entire Adj-RIB-Out". In particular, I suspect you're trying to bound the time you have to spend before you send the subcode 2 message to be O(size of Adj-RIB-Out when you started), so that you're not tripped up by pathological cases? I don't have text to offer for this case, but I do think the authors and WG need to consider it. - I don't think this text is right: " In processing a ROUTE-REFRESH message from a peer, the BGP speaker MUST examine the "message subtype" field of the message and take the appropriate actions." I mean, it's OK, except it basically says "do the right thing" ("take the appropriate actions"). The spec either needs to say unambiguously what the right thing is (if it's a MUST) or adopt some more relaxed tone. Likewise, "The BGP speaker SHALL use the demarcations of the beginning and the ending of a route refresh to perform consistency validations of the updates received from the peer." At most, the speaker MAY do that. If we wanted to mandate it (and I don't think we do) we would need to say what "perform consistency validations" means. I would be OK with either striking the text, or changing the SHALL to a MAY. Here is a possible rewrite of the paragraph: When a BGP speaker receives a Route Refresh message from a peer with subtype 1 it MUST mark all routes with the given AFI/SAFI from that peer as stale. As it receives routes from its peer's subsequent Adj-RIB-Out readvertisement, these replace any corresponding stale routes. When the BGP speaker receives a Route Refresh message from the peer with subtype 2, it MUST immediately remove any routes from the peer that are still marked as stale for that address family. Such routes MAY be logged for further analysis. (It can be observed that this procedure is substantially the same as for the Restarting Speaker in Section 4.2 of [RFC4724].) - RFC 4724 has a timer to deal with the case where the Restarting Speaker forgets to send the EoR. Subcode 2 is basically an EoR, but we have no timer. Is this a problem? Do we need some other kind of safety mechanism? Or are we happy to just rely on the correctness of the implementation (ahem). - During the initial Adj-RIB-Out advertisement, can normal withdraws be sent? I assume so. Not sure if anything need be said about this. - The Error Handling section of the draft assumes traditional RFC 4271 style error handling, namely if you see something wrong, reset the session. Is this the right thing to do in light of the other work the WG has been doing with draft-ietf-idr-error-handling? For that matter, is this the right thing to do in light of the fact that regular route-refresh messages aren't specified to behave in this way? I don't *necessarily* propose that malformed refresh messages should be ignored, but it seems worth discussing. If this stricter approach is adopted, should it be considered for regular Route Refresh too, and if so, should that go in this document? Also, assuming the current error approach is kept, why not go whole hog and finish enumerating the possible error conditions? I think there's only one other: Invalid Subtype. (See also my final point below.) - What is the expected behavior if the peer sends another Route Refresh request when the first request is still in progress (subtype 2 has not yet been sent)? One option is that you could cancel the old refresh, send another subtype 1, then the new refresh, then close it with a subtype 2. But this implies there would be two subtype 1's followed by only one subtype 2. Another way of asking this question is whether there are any restrictions on the interleaving of subtype 1 and 2, and what error handling (if any) is to be applied if the restrictions (if any) are violated. - In the Acks, you need to capitalize Jeff Hass's last name. - In writing this review I've had to choose several times between referring to "subcode 1" and "subcode 2" (not very descriptive) and "Demarcation of the beginning of a route refresh" and "Demarcation of the ending of a route refresh" (verbose). This leads me to think it might be handy for the document to provide short symbolic names for the subtypes, such as BoRR and EoRR. - By the way, now that you've turned the "reserved" field into a "subtype" field, you need to decide what to do with the rest of the values. Right now we have 0 which means either route-refresh or ORF (disambiguated by length) and 1 and 2 defined in this document. The obvious thing to do would be to make this a registry, though then you have to say what to do with unrecognized values. Come to think of it, you have to say that anyway, right now the Error Handling section doesn't cover it. Thanks, --John On Sep 13, 2013, at 3:31 PM, Susan Hares wrote: > This begins a 2 week working group last call for (ending 9/27) > Enhanced Route Refresh Capability for BGP-4 > http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-04 > > This WG last call is in parallel with the 2 week > implementation report adoption call. > > The implementation report is at: > http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-impl/ > > We will read both threads in considering the last call. If the > implementation report is accepted, we will do a last call on the > implementation report. > > Sue Hares and John Scudder > Idr co-chairs > > > > > From thomas.mangin@exa-networks.co.uk Wed Sep 18 10:03:04 2013 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 150E111E8285; Wed, 18 Sep 2013 10:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szdzhWmrzhyW; Wed, 18 Sep 2013 10:02:57 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id 641D211E8127; Wed, 18 Sep 2013 10:02:56 -0700 (PDT) Received: from smtp-4.mail.exa.net.uk (smtp-4.mail.exa.net.uk [82.219.5.4]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 81FF2A01EB; Wed, 18 Sep 2013 18:02:54 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-4.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 383384005D; Wed, 18 Sep 2013 18:02:54 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Mangin In-Reply-To: <15455006-B087-43D4-9D4D-6F7E7B45D545@juniper.net> Date: Wed, 18 Sep 2013 18:02:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0DCADEB3-3DE9-4B3D-B78D-091C59E601FA@exa-networks.co.uk> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <15455006-B087-43D4-9D4D-6F7E7B45D545@juniper.net> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "Keyur Patel \(keyupate\)" , idr wg , Hares Susan Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh 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, 18 Sep 2013 17:03:04 -0000 Hello, On 18 Sep 2013, at 16:39, John G. Scudder wrote: > - RFC 4724 has a timer to deal with the case where the Restarting > Speaker forgets to send the EoR. Subcode 2 is basically an EoR, but > we have no timer. Is this a problem? Do we need some other kind of > safety mechanism? Or are we happy to just rely on the correctness > of the implementation (ahem). Good point. I was happy to rely on the correctness of the implementation = (see reason below) but can see how a timer could be considered. > - During the initial Adj-RIB-Out advertisement, can normal withdraws > be sent? I assume so. Not sure if anything need be said about this. As the draft speaks of a "snapshot", which I read (quoting wikipedia) as = "the state of a system at a particular point in time", I assumed that = all updates received after the sending of the start of route-refresh = message, including withdrawn, from the same family as the route being = currently transferred, should be queued and only sent once the end of = refresh message (EoRR in your speak) was sent. This decision as the side effect to remove the need for a timer as the = number of route to transfer is bound but I believe the definition should = be loose enough to not close the option to reflect change received since = the start of the dump, including sending withdraw message. Another advantage of this design : as it is not possible for the = recipient to differentiate routes sent part of a Route-Refresh and = 'normal' updates, a withdrawn being send (part of a normal update) = before the announcement (part of the RR refresh) could leave a route as = announced when it should not. This border case could be dealt with by a = clever implementation, using point in time snapshot simply eliminate the = need for such cleverness. > - The Error Handling section of the draft assumes traditional RFC 4271 > style error handling, namely if you see something wrong, reset the > session. Is this the right thing to do in light of the other work the=20= > WG has been doing with draft-ietf-idr-error-handling? IMHO, this is outside the scope of this draft. Would we want some RFC = implementing part of draft-ietf-idr-error-handling if it this draft = never reach RFC status ? If the normal behaviour of BGP regarding notification should change, = this should be reflected in draft-ietf-idr-error-handling not in this = draft. > - What is the expected behavior if the peer sends another Route = Refresh > request when the first request is still in progress (subtype 2 has > not yet been sent)? Very good question ! I would propose that the draft should ask the = sender to not send another RR for the same family while the first one is = being honoured, and explicitly request for the second message to be = ignored by the receiving party while its first transfer is still = ongoing. Otherwise how would you do this ? Allowing cancellation would surely require the creation of a new code = for this "cancelled transfer" (like a subtype 3) before a new start of = RR (subtype 1) is sent, or how would the router know that it can not = performed any validation with the data received as incomplete ? > - In writing this review I've had to choose several times between=20 > referring to "subcode 1" and "subcode 2" (not very descriptive) and > "Demarcation of the beginning of a route refresh" and "Demarcation=20 > of the ending of a route refresh" (verbose). This leads me to think > it might be handy for the document to provide short symbolic names > for the subtypes, such as BoRR and EoRR. Agree. Thomas From jhaas@slice.pfrc.org Thu Sep 19 07:11:32 2013 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 2830A21F937E for ; Thu, 19 Sep 2013 07:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.499 X-Spam-Level: X-Spam-Status: No, score=-101.499 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZ6HYAgyW7lg for ; Thu, 19 Sep 2013 07:11:28 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 122D521F944C for ; Thu, 19 Sep 2013 07:11:28 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 24958C395; Thu, 19 Sep 2013 10:11:13 -0400 (EDT) Date: Thu, 19 Sep 2013 10:11:13 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20130919141113.GK8137@pfrc> References: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr wg , erosen@cisco.com, "'John G. Scudder'" , 'Yakov Rekhter' Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 14:11:32 -0000 On Fri, Sep 13, 2013 at 03:03:59PM -0400, Susan Hares wrote: > Just in case the last message on this topic got caught in August doldrums, > we are extending the WG last call for 1 more week: > > IANA Registries for BGP Extended Communities > > draft-ietf-idr-extcomm-iana-00.txt > > https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ As usual, I'm behind in my email. However, I strongly support the last call on this draft. The life of the extended communities feature has been somewhat muddled across its lifetime from original I-D to its RFC state. A significant portion of its lack of clarity has been the appearance, even though not actually stated in the draft or other I-Ds or RFCs that add related code points, that things are far more structured than they're really specified. Examples as a young BGP implementor had included presuming the transitivity bit is simply a bit rather than defining a separate code space. The same thing holds for the IANA bit. Additional points of confusion have tended to include the sub-type field which is effectively in many implementations a "format type", is shown that this is explicitly only so for specific types - and that it may be distinct depending on the I or T bits. Finally, the issues surrounding allocation policy were significantly tightened up as the original extended community drafts went from I-D to RFC, this document further normalizes the "experimental" space as having long lived code points in it, such as the RFC 5575 flowspec redirect-to-vrf community. In my opinion, this work is not only long overdue, but strongly necessary to help avoiding further semantic drift in the extended community registries and related accidentally incorrect implementations. Did I mention I support this document? :-) (And if you haven't chimed in but have a BGP implementation, you should do so as well.) -- Jeff From nick@foobar.org Mon Sep 23 06:12:53 2013 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 DBCB121F99D0 for ; Mon, 23 Sep 2013 06:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1656e+1tPAIR for ; Mon, 23 Sep 2013 06:12:50 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCC221F8D20 for ; Mon, 23 Sep 2013 06:12:46 -0700 (PDT) X-Envelope-To: Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r8NDCh5J055854 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 23 Sep 2013 14:12:43 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.local Message-ID: <52403E4D.8090904@foobar.org> Date: Mon, 23 Sep 2013 14:12:45 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: IETF IDR Working Group X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Idr] 16bit ASN exhaustion 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, 23 Sep 2013 13:12:53 -0000 Looks like IANA handed out the last chunk of unallocated 16 bit ASNs: http://www.iana.org/assignments/as-numbers/as-numbers.xhtml Does IDR have recommendations for how to handle BGP community support in a 32 bit environment? Nick From jrmitche@puck.nether.net Mon Sep 23 06:30:53 2013 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 5FFEA21F9EA8 for ; Mon, 23 Sep 2013 06:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+qTeMSHIs+L for ; Mon, 23 Sep 2013 06:30:52 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id A3B7021F9E40 for ; Mon, 23 Sep 2013 06:30:52 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r8NCEQED011061; Mon, 23 Sep 2013 08:14:26 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r8NCEPtx011049; Mon, 23 Sep 2013 08:14:25 -0400 Date: Mon, 23 Sep 2013 08:14:25 -0400 From: Jon Mitchell To: Nick Hilliard Message-ID: <20130923121425.GA5726@puck.nether.net> References: <52403E4D.8090904@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52403E4D.8090904@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Mon, 23 Sep 2013 08:14:27 -0400 (EDT) Cc: IETF IDR Working Group Subject: Re: [Idr] 16bit ASN exhaustion 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, 23 Sep 2013 13:30:53 -0000 On 23/09/13 14:12 +0100, Nick Hilliard wrote: > Looks like IANA handed out the last chunk of unallocated 16 bit ASNs: > > http://www.iana.org/assignments/as-numbers/as-numbers.xhtml > > Does IDR have recommendations for how to handle BGP community support in a > 32 bit environment? Above and beyond RFC6793 Section 5? -Jon From nick@foobar.org Mon Sep 23 07:25:52 2013 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 BBD6E21F9EDA for ; Mon, 23 Sep 2013 07:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD36Imv9S6Mj for ; Mon, 23 Sep 2013 07:25:51 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id DE0FC21F9EB8 for ; Mon, 23 Sep 2013 07:25:48 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r8NEPic8056423 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 23 Sep 2013 15:25:44 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.local Message-ID: <52404F6A.80207@foobar.org> Date: Mon, 23 Sep 2013 15:25:46 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jon Mitchell References: <52403E4D.8090904@foobar.org> <20130923121425.GA5726@puck.nether.net> In-Reply-To: <20130923121425.GA5726@puck.nether.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] 16bit ASN exhaustion 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, 23 Sep 2013 14:25:52 -0000 On 23/09/2013 13:14, Jon Mitchell wrote: > Above and beyond RFC6793 Section 5? I probably should have been more specific. Until 4byte asns came along we could do stuff like encoding other ASNs in the local administrator field. There are some well known examples of this, e.g. http://onesc.net/communities/as8714/ http://onesc.net/communities/as6695/ But more generally, this is a very useful feature on transit networks which has effectively disappeared if you're using ASN4s. draft-raszuk-wide-bgp-communities would have fixed this, although the implementation details looked pretty messy and I'm not sure that it was a good approach to take as a long term fix for the problem. As operators, we need 32-bit:32-bit communities, not just 32:16. Whatever about the implementation issues, Robert's wide-communities draft looked like it would solve a pile of problems. Nick From rraszuk@gmail.com Mon Sep 23 07:56:58 2013 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 8FA0321F9360 for ; Mon, 23 Sep 2013 07:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuBR9uov1K3P for ; Mon, 23 Sep 2013 07:56:57 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4823121F8AF4 for ; Mon, 23 Sep 2013 07:56:48 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id qd12so6397832ieb.8 for ; Mon, 23 Sep 2013 07:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AASGPKcZuan4zlNBABh5ogXUwtj4QzqpJZ2byXt5DUc=; b=WeU5RXC1hPFlCHMSdrAAzqXYFq5/Q7/sH2Rv4y4FrmkkhYAzDO5wwABJd7GDyIaeV/ Au0FJDYjrwTVEMUg+utEKgXUgaV/Ce7dQfPXUObij9C2qihPQZw9D+SqyPNzKUr9ykAD CfoakA8OjjUNTCEFvqIQnhh9m74l7b1bZUAGYzlHKmouA8gKd9xfmdO4EtkPRrqyGEQq qeQ00ELCNgvbYE0UjOcp9qJ39pEfPK4TGm3FsPmisnCv4FaweYCVoyLEpq8GmUBOvgcZ 2d4QDrwuj9KVGA8C8/wPWyXdVQp1P0MW7D+ypzPmeoECq7CI6wyfuXrU431Tx9Ak0g8/ zRfQ== MIME-Version: 1.0 X-Received: by 10.43.98.202 with SMTP id cp10mr12958367icc.28.1379948201094; Mon, 23 Sep 2013 07:56:41 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Mon, 23 Sep 2013 07:56:41 -0700 (PDT) In-Reply-To: <52404F6A.80207@foobar.org> References: <52403E4D.8090904@foobar.org> <20130923121425.GA5726@puck.nether.net> <52404F6A.80207@foobar.org> Date: Mon, 23 Sep 2013 16:56:41 +0200 X-Google-Sender-Auth: 0eUyZf7pxmlos-oTwAvtQaIkzi8 Message-ID: From: Robert Raszuk To: Nick Hilliard Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF IDR Working Group Subject: Re: [Idr] 16bit ASN exhaustion 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, 23 Sep 2013 14:56:58 -0000 Hi Nick, Just an update on draft-raszuk-wide-bgp-communities .. In Berlin all involved folks have met and I think we clarified the issues which were holding it. Basically while we have tried to made it more flexible then the original idea it quickly became to complex from number of aspects including operation. So we revered back to predefined wide communities rather then spending more time on putting algebra language into them. That means that hopefully soon (one of the co-authors has the src at this point) - maybe before YVR we will have a proposed draft out. So stay tuned .. the work is not abandoned. Cheers, R. On Mon, Sep 23, 2013 at 4:25 PM, Nick Hilliard wrote: > On 23/09/2013 13:14, Jon Mitchell wrote: >> Above and beyond RFC6793 Section 5? > > I probably should have been more specific. Until 4byte asns came along we > could do stuff like encoding other ASNs in the local administrator field. > There are some well known examples of this, e.g. > > http://onesc.net/communities/as8714/ > http://onesc.net/communities/as6695/ > > But more generally, this is a very useful feature on transit networks which > has effectively disappeared if you're using ASN4s. > > draft-raszuk-wide-bgp-communities would have fixed this, although the > implementation details looked pretty messy and I'm not sure that it was a > good approach to take as a long term fix for the problem. > > As operators, we need 32-bit:32-bit communities, not just 32:16. Whatever > about the implementation issues, Robert's wide-communities draft looked > like it would solve a pile of problems. > > Nick > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jhaas@slice.pfrc.org Mon Sep 23 11:51:00 2013 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 E7B9C21F9D7C for ; Mon, 23 Sep 2013 11:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.352 X-Spam-Level: X-Spam-Status: No, score=-101.352 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84bHtFl2xRIH for ; Mon, 23 Sep 2013 11:50:57 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D15CD21F8CB4 for ; Mon, 23 Sep 2013 11:50:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 799E5C20C; Mon, 23 Sep 2013 14:50:44 -0400 (EDT) Date: Mon, 23 Sep 2013 14:50:44 -0400 From: Jeffrey Haas To: Nick Hilliard Message-ID: <20130923185044.GA23879@pfrc> References: <52403E4D.8090904@foobar.org> <20130923121425.GA5726@puck.nether.net> <52404F6A.80207@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52404F6A.80207@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IETF IDR Working Group Subject: Re: [Idr] 16bit ASN exhaustion 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, 23 Sep 2013 18:51:01 -0000 Nick, On Mon, Sep 23, 2013 at 03:25:46PM +0100, Nick Hilliard wrote: > On 23/09/2013 13:14, Jon Mitchell wrote: > > Above and beyond RFC6793 Section 5? > > I probably should have been more specific. Until 4byte asns came along we > could do stuff like encoding other ASNs in the local administrator field. > There are some well known examples of this, e.g. > > http://onesc.net/communities/as8714/ > http://onesc.net/communities/as6695/ > > But more generally, this is a very useful feature on transit networks which > has effectively disappeared if you're using ASN4s. > > draft-raszuk-wide-bgp-communities would have fixed this, although the > implementation details looked pretty messy and I'm not sure that it was a > good approach to take as a long term fix for the problem. http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-06 is more intended to solve the "4byte AS equivalent community" problem. Wide communities is biting off more of the general community problem. > As operators, we need 32-bit:32-bit communities, not just 32:16. Whatever > about the implementation issues, Robert's wide-communities draft looked > like it would solve a pile of problems. That's one thing that could be done in wide comms, but seems overkill. -- Jeff From jhaas@slice.pfrc.org Mon Sep 23 11:52:05 2013 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 A062B21F9D90 for ; Mon, 23 Sep 2013 11:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.704 X-Spam-Level: X-Spam-Status: No, score=-101.704 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQWwB-rRMmYi for ; Mon, 23 Sep 2013 11:52:00 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 460D321F9D7C for ; Mon, 23 Sep 2013 11:51:58 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0454EC238; Mon, 23 Sep 2013 14:51:58 -0400 (EDT) Date: Mon, 23 Sep 2013 14:51:57 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20130923185157.GB23879@pfrc> References: <52403E4D.8090904@foobar.org> <20130923121425.GA5726@puck.nether.net> <52404F6A.80207@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IETF IDR Working Group Subject: Re: [Idr] 16bit ASN exhaustion 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, 23 Sep 2013 18:52:05 -0000 On Mon, Sep 23, 2013 at 04:56:41PM +0200, Robert Raszuk wrote: > Just an update on draft-raszuk-wide-bgp-communities .. > > In Berlin all involved folks have met and I think we clarified the > issues which were holding it. > > Basically while we have tried to made it more flexible then the > original idea it quickly became to complex from number of aspects > including operation. So we revered back to predefined wide communities > rather then spending more time on putting algebra language into them. > > That means that hopefully soon (one of the co-authors has the src at > this point) - maybe before YVR we will have a proposed draft out. And as that individual, I'm working through my work queue for IETF and finally making progress. Hopefully we'll see that in the next week or so. -- Jeff (who has been traveling for 3.5 of the last 6 weeks and is a bad road warrior) From jared@puck.nether.net Mon Sep 23 11:58:42 2013 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 B8CE021F9C05 for ; Mon, 23 Sep 2013 11:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUwUWxwcolKH for ; Mon, 23 Sep 2013 11:58:42 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 21FB021F9B92 for ; Mon, 23 Sep 2013 11:58:42 -0700 (PDT) Received: from [10.0.0.129] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r8NIweBg017379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Sep 2013 14:58:44 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <20130923185044.GA23879@pfrc> Date: Mon, 23 Sep 2013 14:58:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52403E4D.8090904@foobar.org> <20130923121425.GA5726@puck.nether.net> <52404F6A.80207@foobar.org> <20130923185044.GA23879@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.1 (puck.nether.net [204.42.254.5]); Mon, 23 Sep 2013 14:58:45 -0400 (EDT) Cc: IETF IDR Working Group Subject: Re: [Idr] 16bit ASN exhaustion 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, 23 Sep 2013 18:58:42 -0000 On Sep 23, 2013, at 2:50 PM, Jeffrey Haas wrote: >> As operators, we need 32-bit:32-bit communities, not just 32:16. = Whatever >> about the implementation issues, Robert's wide-communities draft = looked >> like it would solve a pile of problems. >=20 > That's one thing that could be done in wide comms, but seems overkill. I'll chime in saying based on general usage u32:u32 is what the BGP = using end-users will expect. - Jared= From thomas.mangin@exa-networks.co.uk Mon Sep 23 12:07:41 2013 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 2C0A211E80EA; Mon, 23 Sep 2013 12:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBac5yHBwjjz; Mon, 23 Sep 2013 12:07:35 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id CDC9E21F9E12; Mon, 23 Sep 2013 12:07:34 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 71A99A0288; Mon, 23 Sep 2013 20:07:32 +0100 (BST) Received: from [82.219.212.13] (ptr-13.212.219.82.rev.exa.net.uk [82.219.212.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id CCEE16C0048; Mon, 23 Sep 2013 20:07:31 +0100 (BST) References: <52403E4D.8090904@foobar.org> <20130923121425.GA5726@puck.nether.net> <52404F6A.80207@foobar.org> <20130923185044.GA23879@pfrc> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5214F90C-4A30-4302-B524-BDAAC9E1B62B@exa-networks.co.uk> X-Mailer: iPad Mail (11A465) From: Thomas Mangin Date: Mon, 23 Sep 2013 20:07:23 +0100 To: "idr-bounces@ietf.org" X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: IETF IDR Working Group Subject: Re: [Idr] 16bit ASN exhaustion 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, 23 Sep 2013 19:07:41 -0000 Yes .. I am still wondering why it is still not available but I am sure that= reading the archive of the list will enlighten me .... Thomas Sent from my iPad > On 23 Sep 2013, at 19:58, Jared Mauch wrote: >=20 > I'll chime in saying based on general usage u32:u32 is what the BGP using e= nd-users will expect. From jhaas@slice.pfrc.org Mon Sep 23 12:26:50 2013 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 643D121F9E8B for ; Mon, 23 Sep 2013 12:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.784 X-Spam-Level: X-Spam-Status: No, score=-101.784 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyWwNAapSBaG for ; Mon, 23 Sep 2013 12:26:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4D89121F9E89 for ; Mon, 23 Sep 2013 12:26:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5DC70C238; Mon, 23 Sep 2013 15:26:43 -0400 (EDT) Date: Mon, 23 Sep 2013 15:26:43 -0400 From: Jeffrey Haas To: Jared Mauch Message-ID: <20130923192643.GD23879@pfrc> References: <52403E4D.8090904@foobar.org> <20130923121425.GA5726@puck.nether.net> <52404F6A.80207@foobar.org> <20130923185044.GA23879@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IETF IDR Working Group Subject: Re: [Idr] 16bit ASN exhaustion 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, 23 Sep 2013 19:26:50 -0000 On Mon, Sep 23, 2013 at 02:58:25PM -0400, Jared Mauch wrote: > On Sep 23, 2013, at 2:50 PM, Jeffrey Haas wrote: > >> As operators, we need 32-bit:32-bit communities, not just 32:16. Whatever > >> about the implementation issues, Robert's wide-communities draft looked > >> like it would solve a pile of problems. > > > > That's one thing that could be done in wide comms, but seems overkill. > > I'll chime in saying based on general usage u32:u32 is what the BGP using end-users will expect. Wide comms can accommodate it. Just seemed overkill to expand the number space. Ah well, another use case to add - perhaps to the base spec. -- Jeff From jhaas@slice.pfrc.org Mon Sep 23 12:52:29 2013 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 5B4C621F9D46 for ; Mon, 23 Sep 2013 12:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.844 X-Spam-Level: X-Spam-Status: No, score=-101.844 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-12pYelhjA8 for ; Mon, 23 Sep 2013 12:52:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5509B21F8FF8 for ; Mon, 23 Sep 2013 12:52:24 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 019C0C20C; Mon, 23 Sep 2013 15:52:23 -0400 (EDT) Date: Mon, 23 Sep 2013 15:52:23 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20130923195223.GE23879@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs 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, 23 Sep 2013 19:52:29 -0000 The authors of the following two drafts would like to request adoption of these drafts by the IDR working group: draft-rekhter-mdcs - Multicast Distribution Control Signaling draft-rekhter-mdrs - Multicast Distribution Reachability Signaling draft-rekhter-geo-distribution will be seeking adoption in mboned. These drafts were presented at the IDR session at the IETF 87 in Berlin. As noted during the presentation, the primary goal of soliciting WG adoption is to get WG review of the drafts. The drafts primarily request additional SAFI codepoints while also noting an application of the RFC 5575 BGP Flowspec encoding for use in multicast control plane filtering. -- Jeff (for the authors) From aservin@lacnic.net Tue Sep 24 05:35:08 2013 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 DCA6521F87B7 for ; Tue, 24 Sep 2013 05:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTPZ1B4tLplc for ; Tue, 24 Sep 2013 05:35:08 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAC711E8122 for ; Tue, 24 Sep 2013 05:35:01 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [IPv6:2001:13c7:7001:7000:8d4c:c271:7614:8d87]) by mail.lacnic.net.uy (Postfix) with ESMTP id BC4583084A8 for ; Tue, 24 Sep 2013 09:34:33 -0300 (UYT) Message-ID: <524186F0.2050906@lacnic.net> Date: Tue, 24 Sep 2013 09:34:56 -0300 From: Arturo Servin Organization: LACNIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: idr@ietf.org References: <52403E4D.8090904@foobar.org> In-Reply-To: <52403E4D.8090904@foobar.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [Idr] 16bit ASN exhaustion X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:35:09 -0000 Do not believe my word (ask IANA) but I though that there where still some ASNs to allocate to RIRs from this last chunk: 64000-64495 Reserved by the IANA Anyway, it may be irrelevant because they may go away in any moment. Regards, as On 9/23/13 10:12 AM, Nick Hilliard wrote: > Looks like IANA handed out the last chunk of unallocated 16 bit ASNs: > > http://www.iana.org/assignments/as-numbers/as-numbers.xhtml > > Does IDR have recommendations for how to handle BGP community support in a > 32 bit environment? > > Nick > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nick@foobar.org Tue Sep 24 05:44:24 2013 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 6DD7E21F9B18 for ; Tue, 24 Sep 2013 05:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE0Tzv7kpgjJ for ; Tue, 24 Sep 2013 05:44:24 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 658B621F9B25 for ; Tue, 24 Sep 2013 05:44:19 -0700 (PDT) X-Envelope-To: Received: from crumpet.local ([IPv6:2001:1bb8:2004:200::180]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r8OCiGQP066027 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 24 Sep 2013 13:44:16 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:1bb8:2004:200::180] claimed to be crumpet.local Message-ID: <52418920.3070602@foobar.org> Date: Tue, 24 Sep 2013 13:44:16 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: idr@ietf.org References: <52403E4D.8090904@foobar.org> <524186F0.2050906@lacnic.net> In-Reply-To: <524186F0.2050906@lacnic.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] 16bit ASN exhaustion X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:44:24 -0000 On 24/09/2013 13:34, Arturo Servin wrote: > 64000-64495 Reserved by the IANA > > Anyway, it may be irrelevant because they may go away in any moment. those are reserved rather than unallocated. By comparison, the available ASN32 ranges are marked as "unallocated". Nick From aservin@lacnic.net Tue Sep 24 06:00:47 2013 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 D76D921F95D0 for ; Tue, 24 Sep 2013 06:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4ZH4WtqfnsL for ; Tue, 24 Sep 2013 06:00:47 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id AF24A21F8C65 for ; Tue, 24 Sep 2013 06:00:46 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [IPv6:2001:13c7:7001:7000:8d4c:c271:7614:8d87]) by mail.lacnic.net.uy (Postfix) with ESMTP id 0656230848A; Tue, 24 Sep 2013 10:00:19 -0300 (UYT) Message-ID: <52418CFA.9040508@lacnic.net> Date: Tue, 24 Sep 2013 10:00:42 -0300 From: Arturo Servin Organization: LACNIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nick Hilliard References: <52403E4D.8090904@foobar.org> <524186F0.2050906@lacnic.net> <52418920.3070602@foobar.org> In-Reply-To: <52418920.3070602@foobar.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: idr@ietf.org Subject: Re: [Idr] 16bit ASN exhaustion X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 13:00:48 -0000 Yes, I know. But check this archived version of the IANA registry: http://web.archive.org/web/20111020211749/http://www.iana.org/assignments/as-numbers/as-numbers.xml Note that ASNs that are marked as "Reserved" are now allocated. As I said, ask IANA for clarification but my impression is that those are reserved for allocation and not for any other use. Regards, as On 9/24/13 9:44 AM, Nick Hilliard wrote: > On 24/09/2013 13:34, Arturo Servin wrote: >> 64000-64495 Reserved by the IANA >> >> Anyway, it may be irrelevant because they may go away in any moment. > > those are reserved rather than unallocated. By comparison, the available > ASN32 ranges are marked as "unallocated". > > Nick > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From rogaglia@cisco.com Tue Sep 24 07:25:17 2013 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 77E3611E811E for ; Tue, 24 Sep 2013 07:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4e3yP6kHL3M for ; Tue, 24 Sep 2013 07:25:10 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 76BC211E8133 for ; Tue, 24 Sep 2013 07:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7887; q=dns/txt; s=iport; t=1380032710; x=1381242310; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EgWnFSL+rpETtnDWmk/6qjhTXvSw2ew03Avl6ercYUA=; b=UITB57+LzynNXVxQmm18ozJOCPrnqTF1K6Qd7IPKXBLXFChUdkLULKQc N9MA9JoQ6D3bD7FNTj5emY9jqhhPvDuH+visusDnkI+JamQRshJI9pWCX gN3By94fFLvqjkMsHWyN5E/b9Ws5q8i3L1+yWIMA0bQg3VZgZzwkPzj22 g=; X-Files: smime.p7s : 4459 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAJufQVKtJXG+/2dsb2JhbABagwc4UsAFSoEdFnSCJQEBAQMBAQEBawsFCwIBCA4KCiQCJQslAgQOBQgBBYdxBgy9HoxcgkQWGweDHYEAA5AmgS+YHoMkgio X-IronPort-AV: E=Sophos;i="4.90,970,1371081600"; d="p7s'?scan'208";a="263798814" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 24 Sep 2013 14:25:08 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8OEP84c010162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Sep 2013 14:25:08 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.92]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 09:25:07 -0500 From: "Roque Gagliano (rogaglia)" To: Arturo Servin Thread-Topic: [Idr] 16bit ASN exhaustion Thread-Index: AQHOuF6jokmDW1i2x0KbGToTwWDQHZnVKAcAgAACnACAAASXAIAAF5UA Date: Tue, 24 Sep 2013 14:25:06 +0000 Message-ID: References: <52403E4D.8090904@foobar.org> <524186F0.2050906@lacnic.net> <52418920.3070602@foobar.org> <52418CFA.9040508@lacnic.net> In-Reply-To: <52418CFA.9040508@lacnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.11] Content-Type: multipart/signed; boundary="Apple-Mail=_EB32E199-B4D1-491D-A41A-90203915DC02"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [Idr] 16bit ASN exhaustion X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 14:25:21 -0000 --Apple-Mail=_EB32E199-B4D1-491D-A41A-90203915DC02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 24, 2013, at 3:00 PM, Arturo Servin wrote: >=20 > Yes, I know. >=20 > But check this archived version of the IANA registry: >=20 > = http://web.archive.org/web/20111020211749/http://www.iana.org/assignments/= as-numbers/as-numbers.xml >=20 > Note that ASNs that are marked as "Reserved" are now allocated. = As I > said, ask IANA for clarification but my impression is that those are > reserved for allocation and not for any other use. IANA can only allocate blocks of 1024. So, the space is technically = depleted Policy Ref: = https://www.icann.org/en/resources/policy/global-addressing/global-policy-= asn-blocks-21sep10-en.htm Roque > Regards, > as >=20 > On 9/24/13 9:44 AM, Nick Hilliard wrote: >> On 24/09/2013 13:34, Arturo Servin wrote: >>> 64000-64495 Reserved by the IANA >>>=20 >>> Anyway, it may be irrelevant because they may go away in any = moment. >>=20 >> those are reserved rather than unallocated. By comparison, the = available >> ASN32 ranges are marked as "unallocated". >>=20 >> Nick >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >>=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_EB32E199-B4D1-491D-A41A-90203915DC02 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/ xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28 ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB 8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4 e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9 5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4 OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi dE0HbYQwggb/MIIF56ADAgECAhAYf+/XztcT+E2kExj0ut5oMA0GCSqGSIb3DQEBBQUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzA1 MTQwMDAwMDBaFw0xNDA1MTUyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQgLSAxMzY4NTI0MDEwMDczMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20xDzAN BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/aDENz/1kQVeEyPK5cHw3n9c4ErU13WONPXjL7 fHYj0Yr/DSGbdyiWZ001bkIMPxvJbxv4r5EaTq72gHxhTF/frLoM5+sEKAErBPuOqpAAYlxo4uyK U1pQzPy+3rtlVRStNUAJZHVN4kYtHRghGoBCkqh2JoSBMCgc41Mr1UvS3dI4kp5lKEqutKjoDtdc /O4Kee/CLzEy0D8QNOF7OSjrPmed1jsAxxqsv9EHMJvG9z/CIXF2Q/kYf24ozeujCPZVaOTjWVsd BsZSNUaD9LyeGQBtGCXq7e0rUEFPZfsdxUoBoVeTYRYIcloFuiG4QQsvjr6rlFZDbXEhOWOJnRsC AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU+K3xGZv+qs21HN5cJGWwMOyfwHcwHQYDVR0R BBYwFIEScm9nYWdsaWFAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90 JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1 dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1 dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA A4IBAQA9KvHI6pN0/W4MJl3cATuTU0cdkjZBvfztljunVmn72rij+hJKzSg8lGawguiccFWVqqEl sMIAinuB1zqFe1ILchliltXEj5vPI+HyGxn5akhQuzk7/hmAfs00CC1hbC1HB8r+b7R2s/bkJ7YY fpE0lMd7exB62MccwKh5yFCgxIvxG/irFLjNicpW/C6ixzmuPoKQO9Rs5H9oBnYVxtGpORPt6H5+ DINZOpsbDcnNgi3mIpSK0lapSzVUueOWBJwS5sfjOLe5pBbpvarrZp0zs0gADupX5u1bH0DpSwj1 zN5wP/p5f2h0L2i4rpaU05LLgBzh0JTy+zidLpU8NgAhMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAYf+/XztcT+E2k Exj0ut5oMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDkyNDE0MjUwN1owIwYJKoZIhvcNAQkEMRYEFLTJRD9SLsmf8w+XiiC50YA3jlUu MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAYf+/XztcT+E2kExj0ut5oMIHOBgsqhkiG9w0BCRACCzGBvqCB uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC EBh/79fO1xP4TaQTGPS63mgwDQYJKoZIhvcNAQEBBQAEggEAcRiOmrl/whAJO3FWxW3sS1SQ0/yl 4tuHQOZypD4Vy3uvSE33o3WYmNUp6ODSUJFUNBY8mjeS/LjJj2vVSX07xAe5e5bTW3EqM1YOhYwS LyMkkt6G52LyiTg9pxRFeBU0H4kx821g3mdxtL5fAh3MYlMc04gy0hh30e55jxIabljOhvc2GUyR zEMxBWmucnPcZkcpzorc5q4fQM57AtNepJyCy8bLmvj8YmwqbDjg2tOKsEv5yEZ7XjmqoF0YJJNO +fl0HBCkJMxs44WtK7x2fiFEl8lbYGVqRXN/yhhDcWz2mMfERkhJl+sETxgjxCcMBkCLyxtEshRN Lc7X/FOliwAAAAAAAA== --Apple-Mail=_EB32E199-B4D1-491D-A41A-90203915DC02-- From bruno.decraene@orange.com Tue Sep 24 07:33:00 2013 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 4F83F11E813F for ; Tue, 24 Sep 2013 07:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgm91ztvRFAD for ; Tue, 24 Sep 2013 07:32:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EFC5E11E8122 for ; Tue, 24 Sep 2013 07:32:55 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 02EB418C11E; Tue, 24 Sep 2013 16:32:53 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DBF61238083; Tue, 24 Sep 2013 16:32:52 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 24 Sep 2013 16:32:52 +0200 From: To: "draft-ietf-idr-aigp.all@tools.ietf.org" Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: Ac6w1mK9oZDNOu+SQiq0dAmRJ9YB/gIUulJQ Date: Tue, 24 Sep 2013 14:32:51 +0000 Message-ID: <23255_1380033172_5241A294_23255_1465_1_53C29892C857584299CBF5D05346208A0706134B@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> In-Reply-To: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: idr wg Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 14:33:00 -0000 Hi, 1) A question for my own culture, regarding TLV encoding: draft-ietf-idr-aigp defines the Length field as "Length: Two octets encoding the length in octets of the TLV, including the= type and length fields." Is there any reason to include the type and length? Especially since, IS-IS and ISO defines the length of TLVs as the length of= the Value field. This translates into (IMHO) less intuitive usage and notes, e.g. - "(Note that the minimum length is 3, indicating that no value field is p= resent.)" - "Length: 11" [...] "The value field of the AIGP TLV is always 8 bytes lon= g." Is there an IETF or routing area recommendation for encoding the length fie= ld of TLVs? 2) Please find below some additional comments: - "The value field of the AIGP TLV is always 8 bytes long. IGP metrics are= frequently expressed as 4-octet values, and this ensures that the AIGP att= ribute can be used to hold the sum of an arbitrary number of 4-octet values= .' Strictly speaking, I'm not sure that the word "arbitrary" is true. - "The default value of AIGP_SESSION, for IBGP and confederation-EBGP sessi= ons, MUST be "enabled." IMHO the "MUST be enabled by default" is questionable. IMHO people wanting = AIGP should be able to configure it. And people not wanting the attribute, = should have nothing to do. And IMHO if I were using AIGP, I would rather call for a global cli enablin= g AIGP on all IBGP/confederation-EBGP sessions. - Error handling >From my reading of draft-ietf-idr-error-handling, a length error in the AIG= P attribute (which seems doable as per the first comment) would result in "= treat-as-withdraw". Is this the desired behavior? "attribute discard" may be more appropriate given the following text: "If a Route Reflector supports the AIGP attribute, but some of its clients do not, then the routing choices that result may not all reflect= the intended routing policy." - list of ASes in the AIGP Administrative Domain [The AIGP attribute] "may be added only to routes that satisfy one of the f= ollowing conditions: [...] The route is an EBGP-learned route whose AS_PATH contains only ASes that ar= e in the same AIGP Administrative Domain as the BGP speaker." This seems to mandate that implementations MUST support a configuration ite= m listing the ASes numbers which are part of the AIGP AD. - references " Thus is it highly recommended that the procedures of [BESTEXT] and [ADDPATH] be used in conjunction with the AIGP Attribute." Shouldn't [BESTEXT] and [ADDPATH] be normative references? Usually the name [ADDPATH] refers to "draft-ietf-idr-add-paths" and not to = "draft-pmohapat-idr-fast-conn-restore". Hence IMHO, I find the name of the = reference misleading. Thanks, Regards, Bruno ------------------- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan= Hares Sent: Saturday, September 14, 2013 1:13 AM To: idr wg Cc: 'John G. Scudder' Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) This is to start at 2 week WG last call for=20 The Accumulated IGP Metric Attribute for BGP draft-ietf-idr-aigp-10.txt http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ This last call will end 9/27/13=20 Three implementations exist: ALU, Cisco, Juniper.=20 Vote early and speak often.=20 Sue and John=20 IDR co-chairs=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From tony.li@tony.li Tue Sep 24 09:11:29 2013 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 AD15911E80E3 for ; Tue, 24 Sep 2013 09:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.437 X-Spam-Level: X-Spam-Status: No, score=-101.437 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jIQLyAOgzeP for ; Tue, 24 Sep 2013 09:11:21 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id B4C2A21F9339 for ; Tue, 24 Sep 2013 09:11:20 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta13.emeryville.ca.mail.comcast.net with comcast id V1QR1m0051afHeLAD4BLgd; Tue, 24 Sep 2013 16:11:20 +0000 Received: from [192.168.2.111] ([98.248.44.164]) by omta17.emeryville.ca.mail.comcast.net with comcast id V4BK1m0023YXu3E8d4BKwV; Tue, 24 Sep 2013 16:11:20 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tony Li In-Reply-To: <23255_1380033172_5241A294_23255_1465_1_53C29892C857584299CBF5D05346208A0706134B@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Tue, 24 Sep 2013 09:11:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0598AB86-C417-4A3C-83B0-BE1D7B3A83C1@tony.li> References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> <23255_1380033172_5241A294_23255_1465_1_53C29892C857584299CBF5D05346208A0706134B@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1510) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380039080; bh=BzPfItJ7U5LIaDuJpWJ2GKYHBn2WbQjKhhTO1QWHHxU=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=dSf3nlfGBmOLHdjoYuPbsbYeJJGqzo1jFveKNm0YmHMmBikxZyzhVnppFPvJEbkYv 4+ejyakscSpDKl2cbMgfotIJQ4++VveQvRZYLm0jV1DkO2EU0Z3+/DcS/4DF02TENj qXhTWvjLGAXVZJ0XPlVQ8MwCgHsSGQOVhaMwUWnJViQ3KTamSTSoWPmAx+5u5IbVL5 4oqx3zAS0lWw5Wsk7hmlP0gkSJF7SyZkNTWB6Zx7zXMv6JzYPWIRZQdNF9HvtQnaO2 cnZZeIhjlAdCbECsXJldEbmbgw0BJJrz0VNx9jZiHwEdKLFhynOyAvQTeJJzso2o28 7IJvXURO1+DWw== Cc: idr wg , "draft-ietf-idr-aigp.all@tools.ietf.org" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 16:11:29 -0000 On Sep 24, 2013, at 7:32 AM, wrote: > 1) A question for my own culture, regarding TLV encoding: >=20 > draft-ietf-idr-aigp defines the Length field as > "Length: Two octets encoding the length in octets of the TLV, = including the type and length fields." >=20 > Is there any reason to include the type and length? > Especially since, IS-IS and ISO defines the length of TLVs as the = length of the Value field. >=20 > This translates into (IMHO) less intuitive usage and notes, e.g. > - "(Note that the minimum length is 3, indicating that no value field = is present.)" > - "Length: 11" [...] "The value field of the AIGP TLV is always 8 = bytes long." >=20 > Is there an IETF or routing area recommendation for encoding the = length field of TLVs? >=20 I've never seen one and I've never seen a strong argument for including = or not including the type and length fields in the count. There are some trivial arguments, but nothing that is compelling, so it = seems to be up to the authors. =20 The arguments that I can think of: - Be consistent with the remainder of the protocol. - There is some programming ease when parsing if the length does not = include the type and length fields. This allows you to just load the = length field and use it directly in iteration across the value. This = save a whole '- 3'. Not a big deal. - You actually lose 3 bytes of potential payload. For a 1 byte length = field, this is of course more of a concern. Again, nothing worth arguing about. Tony From thomas.mangin@exa-networks.co.uk Tue Sep 24 10:00:52 2013 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 889F211E815C; Tue, 24 Sep 2013 10:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSGp++Pq1h4U; Tue, 24 Sep 2013 10:00:47 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8211E8158; Tue, 24 Sep 2013 10:00:43 -0700 (PDT) Received: from smtp-4.mail.exa.net.uk (smtp-4.mail.exa.net.uk [82.219.5.4]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id C5FA2A02AE; Tue, 24 Sep 2013 18:00:39 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-4.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 8B4A84006B; Tue, 24 Sep 2013 18:00:39 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Mangin In-Reply-To: <0598AB86-C417-4A3C-83B0-BE1D7B3A83C1@tony.li> Date: Tue, 24 Sep 2013 18:00:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B1F56A0-24F0-4F70-A200-D2D6AC8DA435@exa-networks.co.uk> References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> <23255_1380033172_5241A294_23255_1465_1_53C29892C857584299CBF5D05346208A0706134B@PEXCVZYM11.corporate.adroot.infra.ftgroup> <0598AB86-C417-4A3C-83B0-BE1D7B3A83C1@tony.li> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: bruno.decraene@orange.com, "draft-ietf-idr-aigp.all@tools.ietf.org" , idr wg Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 17:00:52 -0000 Hello, Sorry, I did not know about this draft before today - hence the late = comments. On 24 Sep 2013, at 17:11, Tony Li wrote: > - There is some programming ease when parsing if the length does not = include the type and length fields. This allows you to just load the = length field and use it directly in iteration across the value. This = save a whole '- 3'. Not a big deal. > - You actually lose 3 bytes of potential payload. For a 1 byte length = field, this is of course more of a concern. >=20 > Again, nothing worth arguing about. I was thinking _exactly_ the same thing. As this TLV was clearly created = to allow the creation of other TYPE later, I think it should be done = right ! Even without speaking of other protocol, it is not consistent = with the rest of the protocol... the BGP header only contain the size of = the BODY, etc. As I like the idea, I believe it should be done right. Otherwise why bother, as AIGP is a double size MED and could have be = encoded as such ! On 24 Sep 2013, at 15:32, bruno.decraene@orange.com wrote: > - Error handling > =46rom my reading of draft-ietf-idr-error-handling, a length error in = the AIGP attribute (which seems doable as per the first comment) would = result in "treat-as-withdraw". > Is this the desired behavior? > "attribute discard" may be more appropriate given the following text: > "If a Route Reflector supports the AIGP attribute, but some of its > clients do not, then the routing choices that result may not all = reflect the intended routing policy." I agree. As well, should the document reserve all the known attributes values, = should someone at a later date unify the presentation of attributes = within TLV. This would clearly require the value of 1 for AIGP to be changed. Sincerely, Thomas From thomas.mangin@exa-networks.co.uk Tue Sep 24 10:44:01 2013 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 4E42F21F9DFA; Tue, 24 Sep 2013 10:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-Wl75NBKiak; Tue, 24 Sep 2013 10:43:55 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id F0F2721F9D2B; Tue, 24 Sep 2013 10:43:54 -0700 (PDT) Received: from smtp-4.mail.exa.net.uk (smtp-4.mail.exa.net.uk [82.219.5.4]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 8249EA02B5; Tue, 24 Sep 2013 18:43:50 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-4.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 3DD884005D; Tue, 24 Sep 2013 18:43:50 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Mangin In-Reply-To: <4B1F56A0-24F0-4F70-A200-D2D6AC8DA435@exa-networks.co.uk> Date: Tue, 24 Sep 2013 18:43:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6F45CB0A-E4BF-4E01-875C-948FDC7838F7@exa-networks.co.uk> References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> <23255_1380033172_5241A294_23255_1465_1_53C29892C857584299CBF5D05346208A0706134B@PEXCVZYM11.corporate.adroot.infra.ftgroup> <0598AB86-C417-4A3C-83B0-BE1D7B3A83C1@tony.li> <4B1F56A0-24F0-4F70-A200-D2D6AC8DA435@exa-networks.co.uk> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: bruno.decraene@orange.com, "draft-ietf-idr-aigp.all@tools.ietf.org" , idr wg Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 17:44:01 -0000 On 24 Sep 2013, at 18:00, Thomas Mangin = wrote: > As well, should the document reserve all the known attributes values, = should someone at a later date unify the presentation of attributes = within TLV. > This would clearly require the value of 1 for AIGP to be changed. At first reading I assumed that the TLV code namespace would be global = (but it does not seems to be the intend of the authors). So this comment is moot. Thomas= From erosen@cisco.com Tue Sep 24 12:34:08 2013 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 DF2CD11E80F2 for ; Tue, 24 Sep 2013 12:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2b7uhHSdC0tq for ; Tue, 24 Sep 2013 12:34:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 54B1311E80ED for ; Tue, 24 Sep 2013 12:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1840; q=dns/txt; s=iport; t=1380051243; x=1381260843; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=S+NKJ3QtUHUaZ83GC7HhBTWOJSurgU/Vs3jCzhAl/KY=; b=h4btGw+Pj5B2PluK/6MMOj8VGHWfFJBCTxL7g9UwnMhk5yvsemLgU7de vIpeCIb//FFOSOAg3kUhsjgOXKRxgutvQgdhdTMLctcF7TIIGQnquuaW/ MNyk+D2hWLbEwFRX0xyOCcyAVHwNe6tbClR9qG7xYfxXI73WxriiWdlor 4=; X-IronPort-AV: E=Sophos;i="4.90,972,1371081600"; d="scan'208";a="263759724" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 24 Sep 2013 19:34:03 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8OJY2e5021053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Sep 2013 19:34:02 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r8OJY15Q026160; Tue, 24 Sep 2013 15:34:01 -0400 From: Eric Rosen To: bruno.decraene@orange.com In-reply-to: Your message of Tue, 24 Sep 2013 14:32:51 -0000. <23255_1380033172_5241A294_23255_1465_1_53C29892C857584299CBF5D05346208A0706134B@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Tue, 24 Sep 2013 15:34:01 -0400 Message-ID: <26159.1380051241@erosen-linux> Cc: idr wg , "draft-ietf-idr-aigp.all@tools.ietf.org" , erosen@cisco.com Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 19:34:09 -0000 > 1) A question for my own culture, regarding TLV encoding: > draft-ietf-idr-aigp defines the Length field as "Length: Two octets > encoding the length in octets of the TLV, including the type and length > fields." > Is there any reason to include the type and length? After five years and at least three implementations, there would need to be a very strong technical justification for changing the encoding. > "The default value of AIGP_SESSION, for IBGP and confederation-EBGP > sessions, MUST be "enabled." IMHO the "MUST be enabled by default" is > questionable. IMHO people wanting AIGP should be able to configure it. And > people not wanting the attribute, should have nothing to do. If you leave the AIGP_SESSION and AIGP_ORIGINATE parameters at their default values in all your routers, then you will never attach an AIGP attribute to any prefix, and you will discard any AIGP attribute that arrives from another administrative domain. So I think the draft meets your requirement, i.e., if you don't want to use AIGP you don't have to do anything. If you do want to attach AIGP to a prefix, you have to configure it at the routers that originate routes to that prefix. The purpose of AIGP_SESSION is to ensure that you ignore AIGP attributes that mistakenly leak out of other administrative domains. > And IMHO if I were using AIGP, I would rather call for a global cli > enabling AIGP on all IBGP/confederation-EBGP sessions. That would be a very reasonable request to make of your vendor. > From my reading of draft-ietf-idr-error-handling, a length error in the > AIGP attribute (which seems doable as per the first comment) would result > in "treat-as-withdraw". I have the same interpretation. > Is this the desired behavior? I don't see a problem with it. From jgs@juniper.net Tue Sep 24 12:57:21 2013 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 A9D2B11E8159; Tue, 24 Sep 2013 12:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.621 X-Spam-Level: X-Spam-Status: No, score=-3.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEaFwq7Xhzgg; Tue, 24 Sep 2013 12:57:14 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id D63A821F9E3F; Tue, 24 Sep 2013 12:57:11 -0700 (PDT) Received: from mail60-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.22; Tue, 24 Sep 2013 19:57:10 +0000 Received: from mail60-co1 (localhost [127.0.0.1]) by mail60-co1-R.bigfish.com (Postfix) with ESMTP id E611C8001AF; Tue, 24 Sep 2013 19:57:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zz98dI9371I1432I168aJzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz8275ch1de098h1de097hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail60-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(51704005)(189002)(377454003)(199002)(57704003)(57306001)(47776003)(62966002)(56776001)(19580405001)(83072001)(50466002)(54316002)(83322001)(19580395003)(79102001)(42186004)(74876001)(65816001)(76482001)(77982001)(47446002)(59766001)(74502001)(66066001)(46406003)(80976001)(4396001)(63696002)(80022001)(74662001)(76786001)(46102001)(31966008)(53806001)(74366001)(50226001)(36756003)(81816001)(81686001)(69226001)(77156001)(47976001)(76796001)(81342001)(23726002)(81542001)(50986001)(82746002)(77096001)(47736001)(49866001)(33656001)(51856001)(56816003)(53416003)(74706001)(83716002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:jgs-sslvpn-nc.jnpr.net; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail60-co1 (localhost.localdomain [127.0.0.1]) by mail60-co1 (MessageSwitch) id 1380052628723667_10737; Tue, 24 Sep 2013 19:57:08 +0000 (UTC) Received: from CO1EHSMHS005.bigfish.com (unknown [10.243.78.250]) by mail60-co1.bigfish.com (Postfix) with ESMTP id AB79C980040; Tue, 24 Sep 2013 19:57:08 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS005.bigfish.com (10.243.66.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 24 Sep 2013 19:57:04 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.359.1; Tue, 24 Sep 2013 19:57:02 +0000 Received: from jgs-sslvpn-nc.jnpr.net (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 19:57:01 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "John G. Scudder" In-Reply-To: <0DCADEB3-3DE9-4B3D-B78D-091C59E601FA@exa-networks.co.uk> Date: Tue, 24 Sep 2013 15:56:51 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0BBBFCA1-76B4-4542-9622-207802914D6C@juniper.net> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <15455006-B087-43D4-9D4D-6F7E7B45D545@juniper.net> <0DCADEB3-3DE9-4B3D-B78D-091C59E601FA@exa-networks.co.uk> To: Thomas Mangin X-Mailer: Apple Mail (2.1510) X-Originating-IP: [66.129.232.2] X-ClientProxiedBy: BL2PR08CA017.namprd08.prod.outlook.com (10.141.66.37) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) X-Forefront-PRVS: 09796A1B83 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "Keyur Patel \(keyupate\)" , idr wg , idr-bounces@ietf.org, Hares Susan Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 19:57:23 -0000 Thomas, On Sep 18, 2013, at 1:02 PM, Thomas Mangin = wrote: ... > On 18 Sep 2013, at 16:39, John G. Scudder wrote: >=20 >> - RFC 4724 has a timer to deal with the case where the Restarting >> Speaker forgets to send the EoR. Subcode 2 is basically an EoR, but >> we have no timer. Is this a problem? Do we need some other kind of >> safety mechanism? Or are we happy to just rely on the correctness >> of the implementation (ahem). >=20 > Good point. I was happy to rely on the correctness of the = implementation (see reason below) but can see how a timer could be = considered. >=20 >> - During the initial Adj-RIB-Out advertisement, can normal withdraws >> be sent? I assume so. Not sure if anything need be said about this. >=20 > As the draft speaks of a "snapshot", which I read (quoting wikipedia) = as "the state of a system at a particular point in time", I assumed that = all updates received after the sending of the start of route-refresh = message, including withdrawn, from the same family as the route being = currently transferred, should be queued and only sent once the end of = refresh message (EoRR in your speak) was sent. >=20 > This decision as the side effect to remove the need for a timer as the = number of route to transfer is bound but I believe the definition should = be loose enough to not close the option to reflect change received since = the start of the dump, including sending withdraw message. Two points: First, I think your "snapshot" paragraph above illustrates the need for = a little more clarity in the draft as to what routes are to be = transferred, and when, since I suspect not all readers would have the = same interpretation. Second, I don't see how this has "the side effect to remove the need for = a timer", since one possible error case is where the sending side simply = forgets to send the EoRR, but otherwise continues to send normal routing = updates. One may argue that this is unlikely, but it's still possible. I = guess the counter-argument is that unlike GR, we aren't mandating that = implementations hold up any other processing or retain large volumes of = state, so the consequences of not ever getting the EoRR might not be = severe -- or if implementation choices make the consequences severe, the = implementation could implement a timer as a local option. --John= From jgs@juniper.net Tue Sep 24 13:02:37 2013 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 467DB11E816B for ; Tue, 24 Sep 2013 13:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.118 X-Spam-Level: X-Spam-Status: No, score=-5.118 tagged_above=-999 required=5 tests=[AWL=1.481, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LawtIH+5SWNj for ; Tue, 24 Sep 2013 13:02:31 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABAA21F9BC4 for ; Tue, 24 Sep 2013 13:02:27 -0700 (PDT) Received: from mail173-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Tue, 24 Sep 2013 20:02:26 +0000 Received: from mail173-tx2 (localhost [127.0.0.1]) by mail173-tx2-R.bigfish.com (Postfix) with ESMTP id 6D76D48012C; Tue, 24 Sep 2013 20:02:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 8 X-BigFish: VPS8(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail173-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(57306001)(47776003)(62966002)(56776001)(83072001)(50466002)(54316002)(83322001)(79102001)(42186004)(74876001)(65816001)(76482001)(77982001)(47446002)(59766001)(74502001)(66066001)(46406003)(80976001)(4396001)(63696002)(80022001)(74662001)(76786001)(46102001)(31966008)(53806001)(74366001)(50226001)(36756003)(81816001)(81686001)(69226001)(77156001)(47976001)(76796001)(81342001)(23726002)(81542001)(50986001)(82746002)(77096001)(47736001)(49866001)(33656001)(51856001)(56816003)(53416003)(74706001)(83716002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:jgs-sslvpn-nc.jnpr.net; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail173-tx2 (localhost.localdomain [127.0.0.1]) by mail173-tx2 (MessageSwitch) id 1380052870565188_16186; Tue, 24 Sep 2013 20:01:10 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.230]) by mail173-tx2.bigfish.com (Postfix) with ESMTP id 15294220074; Tue, 24 Sep 2013 20:00:52 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 24 Sep 2013 20:00:51 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.359.1; Tue, 24 Sep 2013 20:00:50 +0000 Received: from jgs-sslvpn-nc.jnpr.net (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 20:00:49 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "John G. Scudder" In-Reply-To: <15455006-B087-43D4-9D4D-6F7E7B45D545@juniper.net> Date: Tue, 24 Sep 2013 16:00:40 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <15455006-B087-43D4-9D4D-6F7E7B45D545@juniper.net> To: Hares Susan , "Keyur Patel (keyupate)" X-Mailer: Apple Mail (2.1510) X-Originating-IP: [66.129.232.2] X-ClientProxiedBy: BL2PR08CA017.namprd08.prod.outlook.com (10.141.66.37) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) X-Forefront-PRVS: 09796A1B83 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: idr wg Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 20:02:37 -0000 It occurs to me that one bit of clarification that might help is to = state that all updates received during the route refresh are to be = processed as normal, except as explicitly noted in the spec, and that = the EoRR's only uses are to signal that stale routes can be flushed, and = optionally any "sanity" steps (locally defined) can be taken. --John= From bdickson@verisign.com Tue Sep 24 13:07:44 2013 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 DA1AB11E80F2 for ; Tue, 24 Sep 2013 13:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1s79ND88OWF for ; Tue, 24 Sep 2013 13:07:38 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 37DB921F9AF0 for ; Tue, 24 Sep 2013 13:07:33 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUkHw/5GTf8c6wog8oPYZ/OCIV09Lsnsw@postini.com; Tue, 24 Sep 2013 13:07:36 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8OK7OmQ025649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Sep 2013 16:07:24 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 24 Sep 2013 16:07:24 -0400 From: "Dickson, Brian" To: "erosen@cisco.com" , "bruno.decraene@orange.com" Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOuV0FoZDNOu+SQiq0dAmRJ9YB/pnVUKEA Date: Tue, 24 Sep 2013 20:07:23 +0000 Message-ID: In-Reply-To: <26159.1380051241@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <2FB8CE6AD013D04F973ABB0533BE98E6@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg , "draft-ietf-idr-aigp.all@tools.ietf.org" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 20:07:44 -0000 I have briefly skimmed the document, and in-line below, have comments. On 9/24/13 3:34 PM, "Eric Rosen" wrote: >> "The default value of AIGP_SESSION, for IBGP and confederation-EBGP >> sessions, MUST be "enabled." IMHO the "MUST be enabled by default" is >> questionable. IMHO people wanting AIGP should be able to configure it. >>And >> people not wanting the attribute, should have nothing to do. > >If you leave the AIGP_SESSION and AIGP_ORIGINATE parameters at their >default >values in all your routers, then you will never attach an AIGP attribute >to >any prefix, and you will discard any AIGP attribute that arrives from >another administrative domain. So I think the draft meets your >requirement, >i.e., if you don't want to use AIGP you don't have to do anything. > >If you do want to attach AIGP to a prefix, you have to configure it at the >routers that originate routes to that prefix. Here's where IMHO things break down: It violates the "two missile key" approach to networking, even if it is intended to be limited to iBGP or confederations. This basically boils down to presuming that "should not" is equivalent to "will not", in operational environments. How many times must large networks collapse before vendors and/or standards stop making this assumption? I'd be happy to point the authors at a variety of cases where introducing something new/different in the transitive environment broke things. Breaking things can have global-Internet-scale impact, even if it was not the intention. A session reset between IBGP speakers WILL cause EBGP traffic collapse, if the IBGP speakers were also both EBGP speakers. IBGP is full mesh, and there would not be any alternative path for BGP prefixes heard by one, sent to the other, and announced to EBGP neighbors. A session reset is a withdraw-trigger. Yes, this AIGP is intentionally limited to self-originated prefixes, but is still potentially hazardous. At a minimum, the AIGP_SESSION should be dependent on validating the peer's ability to not do session resets (e.g if/when the new error handling standard is implemented, that the capability is known to be running on the peer). Otherwise, this creates a place where unilateral activity by a single individual, has the potential to cause harm to large networks. E.g. suppose a heterogenous network (of multiple vendors and/or multiple hardware platforms and/or multiple firmware revisions) has one or more AIGP-capable routers introduced into it. Further suppose that some subset of the non-AIGP-capable routers does not handle unknown attributes nicely. If the AIGP-capable routers default to AIGP_SESSION enabled, then the only thing preventing a network calamity is the installation of an AIGP_ORIGINATE parameter. This is a single step, which could be done by e.g. a network administrator either intentionally experimenting with new features, or by accidentally hitting return while doing "command completion" to discover the syntax of new commands. While it is a PITA, having to configure both ends of a peering session for every pair of routers is the only way to be safe from single-command catastrophe. > >The purpose of AIGP_SESSION is to ensure that you ignore AIGP attributes >that mistakenly leak out of other administrative domains. Again, this presumes that "ignore" functionality works as expected. What happens when the attribute is attached to prefixes that get reflected by route-reflectors? The identity and status of recipients is not necessarily obvious, if there are reflectors involved, which may lead to unintended outages. Other than the DEFAULT state of the session parameter, I don't see anything big (perhaps the TLV thing that Tony pointed out). Brian From thomas.mangin@exa-networks.co.uk Tue Sep 24 13:59:02 2013 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 5CBCD21F9CF5; Tue, 24 Sep 2013 13:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4+JzTed+-+h; Tue, 24 Sep 2013 13:58:56 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id 246CA21F9D68; Tue, 24 Sep 2013 13:58:39 -0700 (PDT) Received: from smtp-4.mail.exa.net.uk (smtp-4.mail.exa.net.uk [82.219.5.4]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 84CF5A02B8; Tue, 24 Sep 2013 21:58:36 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-4.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 4049A4005D; Tue, 24 Sep 2013 21:58:36 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Mangin In-Reply-To: <0BBBFCA1-76B4-4542-9622-207802914D6C@juniper.net> Date: Tue, 24 Sep 2013 21:58:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <45287F59-DBD8-4D1E-B309-FC075CA16FDA@exa-networks.co.uk> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <15455006-B087-43D4-9D4D-6F7E7B45D545@juniper.net> <0DCADEB3-3DE9-4B3D-B78D-091C59E601FA@exa-networks.co.uk> <0BBBFCA1-76B4-4542-9622-207802914D6C@juniper.net> To: jgs@juniper.net X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "Keyur Patel \(keyupate\)" , idr wg , idr-bounces@ietf.org, Hares Susan Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 20:59:02 -0000 > Second, I don't see how this has "the side effect to remove the need = for a timer", since one possible error case is where the sending side = simply forgets to send the EoRR, I assumed that vendor would never ship code as broken as that, but I = will concede this point and agree with you :-) > It occurs to me that one bit of clarification that might help is to = state that all updates received during the route refresh are to be = processed as normal, except as explicitly noted in the spec, and that = the EoRR's only uses are to signal that stale routes can be flushed, and = optionally any "sanity" steps (locally defined) can be taken. Sounds good to me. Thomas From bruno.decraene@orange.com Wed Sep 25 00:15:11 2013 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 76A8811E8105 for ; Wed, 25 Sep 2013 00:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KddJhTqksxuI for ; Wed, 25 Sep 2013 00:15:06 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B4FB221F9E96 for ; Wed, 25 Sep 2013 00:15:05 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 19DC226428B; Wed, 25 Sep 2013 09:15:04 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id F00FA27C07B; Wed, 25 Sep 2013 09:15:03 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 25 Sep 2013 09:15:03 +0200 From: To: "erosen@cisco.com" Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOuV0FoZDNOu+SQiq0dAmRJ9YB/pnWB08A Date: Wed, 25 Sep 2013 07:15:02 +0000 Message-ID: <28145_1380093304_52428D77_28145_2975_2_53C29892C857584299CBF5D05346208A07061641@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: Your message of Tue, 24 Sep 2013 14:32:51 -0000. <23255_1380033172_5241A294_23255_1465_1_53C29892C857584299CBF5D05346208A0706134B@PEXCVZYM11.corporate.adroot.infra.ftgroup> <26159.1380051241@erosen-linux> In-Reply-To: <26159.1380051241@erosen-linux> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.25.45415 Cc: idr wg , "draft-ietf-idr-aigp.all@tools.ietf.org" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 07:15:12 -0000 Eric, >> 1) A question for my own culture, regarding TLV encoding: > >> draft-ietf-idr-aigp defines the Length field as "Length: Two octets >> encoding the length in octets of the TLV, including the type and leng= th >> fields." > >> Is there any reason to include the type and length? > >After five years and at least three implementations, there would need to be >a very strong technical justification for changing the encoding. I agree with you. However, to clarify, that was neither my question (is there any reason for = preferring one option or the other) nor my point (for my information; for f= uture documents/usages). To come back to my question, I guess your answer is "no". >> From my reading of draft-ietf-idr-error-handling, a length error in the >> AIGP attribute (which seems doable as per the first comment) would result >> in "treat-as-withdraw". > >I have the same interpretation. > >> Is this the desired behavior? > >I don't see a problem with it. The problem is that in case of error, you withdraw the route -which is usua= lly used- while you could only withdraw the attribute -which apparently is = not required (to be consistent within the AS)-.=20 That being said, if this is intended, I'm fine with this because I'm not us= ing it. Thank you Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From thomas.mangin@exa-networks.co.uk Wed Sep 25 01:57:48 2013 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 6492221F9F96; Wed, 25 Sep 2013 01:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZgs9-zmKI97; Wed, 25 Sep 2013 01:57:42 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id 537BA21F9FB7; Wed, 25 Sep 2013 01:57:39 -0700 (PDT) Received: from smtp-4.mail.exa.net.uk (smtp-4.mail.exa.net.uk [82.219.5.4]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id E84B1A03DB; Wed, 25 Sep 2013 09:57:37 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-4.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id A29854008C; Wed, 25 Sep 2013 09:57:37 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Mangin In-Reply-To: <28145_1380093304_52428D77_28145_2975_2_53C29892C857584299CBF5D05346208A07061641@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Wed, 25 Sep 2013 09:57:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: Your message of Tue, 24 Sep 2013 14:32:51 -0000. <23255_1380033172_5241A294_23255_1465_1_53C29892C857584299CBF5D05346208A0706134B@PEXCVZYM11.corporate.adroot.infra.ftgroup> <26159.1380051241@erosen-linux> <28145_1380093304_52428D77_28145_2975_2_53C29892C857584299CBF5D05346208A07061641@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: idr wg , "erosen@cisco.com" , "draft-ietf-idr-aigp.all@tools.ietf.org" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 08:57:48 -0000 Hello Eric, >> After five years and at least three implementations, there would need = to be >> a very strong technical justification for changing the encoding. I found the positive answer for you :-) At the point you are parsing the TLV, all the data has already been = read, so the value is not here to provide a number of bytes to read but = to provide the location of the separation in the read buffer. so by having the size, you have the offset at which to split the buffer = ... It is therefore simpler than having the size of the data. For the other points .. we are still not agreeing, but I fear that = nothing I can say can change your mind if you are trying to get the = feature in the hands of users in a timely fashion. Thomas From russw@riw.us Wed Sep 25 04:51:29 2013 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 E711221F9B90 for ; Wed, 25 Sep 2013 04:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIJ6m784hQh5 for ; Wed, 25 Sep 2013 04:51:24 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 162C921F9B8A for ; Wed, 25 Sep 2013 04:51:23 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95]:62816 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VOncm-0002GI-60; Wed, 25 Sep 2013 11:51:20 +0000 From: "Russ White" To: "'Jeffrey Haas'" , References: <20130923195223.GE23879@pfrc> In-Reply-To: <20130923195223.GE23879@pfrc> Date: Wed, 25 Sep 2013 07:51:20 -0400 Message-ID: <019d01ceb9e5$8d9bcb50$a8d361f0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJ/mmVc6oQyhGejjIq/hIWTdkYGdZh0ljjQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 11:51:30 -0000 > The authors of the following two drafts would like to request adoption of > these drafts by the IDR working group: > > draft-rekhter-mdcs - Multicast Distribution Control Signaling draft-rekhter- > mdrs - Multicast Distribution Reachability Signaling > > draft-rekhter-geo-distribution will be seeking adoption in mboned. I've read and support. :-) Russ From bruno.decraene@orange.com Wed Sep 25 06:19:30 2013 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 5DD9A21F9A2D for ; Wed, 25 Sep 2013 06:19:30 -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, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4rBsDMWrYXt for ; Wed, 25 Sep 2013 06:19:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id E9B1521F9E5E for ; Wed, 25 Sep 2013 06:19:25 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 55C9D2AC144; Wed, 25 Sep 2013 15:19:24 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 3B7DFC807D; Wed, 25 Sep 2013 15:19:24 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 25 Sep 2013 15:19:23 +0200 From: To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: Ac6wt8D1L5sinGlEQF6dDpyxwQSmIAJHJVGQ Date: Wed, 25 Sep 2013 13:19:22 +0000 Message-ID: <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> In-Reply-To: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.25.51815 Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 13:19:30 -0000 Hi all, Please find below some comments: Note: in this email, RR stands for ROUTE-REFRESH. 1) Routing consistency validation 3. Operations: " When a route entry in the "ADJ-RIB- Out" changes, the advertisement of the modified route entry (instead of the snapshot entry) would suffice." This indeed allows faster propagation of routing change which is a priori g= ood. However, this seems to limit the ability to perform "consistency validation= s of BGP routing updates" as described in the abstract. Because the BGP spe= aker receiving the route refresh does not know if the inconsistency (betwee= n its local route and the received refreshed one) is due to a new update, o= r a missed old one. Indeed, the introduction only refers to "missing withdraws". However, for V= PN SAFI, missing updates are also important as the VPN label of the NLRI ma= y have change and hence, with a missed BGP update, the packet could be dire= cted to a wrong VPN. 2) Error handling 2.a) " When the BGP speaker detects an error while processing a ROUTE- REFRESH message with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION message" I don't think this behavior is the one called by " Operational Requirements= for Enhanced Error Handling Behaviour in BGP-4 " draft-ietf-grow-ops-reqs-for-bgp-error-handling This seems too disruptive for a non vital message. One could say that this point if for draft-ietf-idr-error-handling. However= IMHO, draft-ietf-idr-error-handling should rather cover the general case p= lus past RFC. New document should handle their new error cases, the new way. And from an implementation standpoint, let's imagine a company that has imp= lemented both drafts, which error handling behavior has been implemented i.= e. will get deployed? 2.b) One case of error is missing: what should be done if the BGP capabilit= y received has a length not matching the receiver requirements? (ignore the= capability? ignore the wrong length? send a notification? 2.c) Draft is more or less overriding the "Reserved [...]. Should be set to= 0 by the sender and ignored by the receiver.". I think I would be fair to = say that "RR messages with unknown Subtypes SHOULD be processed as regular = RR", which seems on the same line of the existing RR RFC (rather than sendi= ng a notification as currently specified in this draft: " When the BGP spea= ker detects an error while processing a ROUTE-REFRESH message with a non-ze= ro "Message Subtype" field, it MUST send a NOTIFICATION message") 3) Message subtypes - IMO, a new IANA registry needs to be created to allow new values to be de= fined for this new sub-type. - It would be good to define how new sub-types values are going to be intro= duced in the protocol/network. One option may be to have the new "Enhanced = Route Refresh Capability" listing (in its value field) all the supported su= btypes. 4) aborting ERR A BGP speaker having send a "Demarcation of the beginning of a route refres= h" may want to abort the ERR procedure and not send the "Demarcation of the= ending of a route refresh". One reason may be that sending the route refre= sh is too long (e.g. exceed a local timer) and hence delay too much the sen= ding of BGP withdraw, hence delay the BGP convergence. In such case, how is= the speaker supposed to react? (one option may be to define a sub-type for= abortion) Same question for the receiver: if it finds the RR too long (compared to it= s BGP convergence time requirements), how should it behave? (one option whi= ch may help would be to advertise such max delay in the BGP capability) 5) not receiving "Demarcation of the ending of a route refresh How is the receiver supposed to react? - Never ever send a new RR on this session? This would be problematic as RR= are typically used often, e.g. when a new VPN is configured. But it's not = clear if sending a new RR is, strictly speaking, allowed by the current tex= t. Hence the receiver would take the risk of "upsetting" the speaker and re= ceiving a NOTIFICATION.=20 - And if it sends a new RR, and receive a new "Demarcation of the beginning= of a route refresh", should it wait for two " Demarcation of the ending of= a route refresh" or is single one. (same question for the speaker: should = it send two or one). 6) MUST? " Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a ROUTE-REFRESH message with the specified message subtype to mark the beginning of the route refresh." If the RR is initiated locally, I don't think that there is a need for a MU= ST. SHOULD seems more reasonable. MAY could even be enough. Thank you, Regards, Bruno >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan >Hares >Sent: Friday, September 13, 2013 9:32 PM >To: idr wg >Cc: 'Keyur Patel (keyupate)' >Subject: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route- >refresh > >This begins a 2 week working group last call for (ending 9/27) >Enhanced Route Refresh Capability for BGP-4 >http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-04 > >This WG last call is in parallel with the 2 week >implementation report adoption call. > >The implementation report is at: >http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-impl/ > >We will read both threads in considering the last call. If the >implementation report is accepted, we will do a last call on the >implementation report. > >Sue Hares and John Scudder >Idr co-chairs > > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From erosen@cisco.com Wed Sep 25 08:01:15 2013 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 0F73221F8D62 for ; Wed, 25 Sep 2013 08:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8JBqW9KoPde for ; Wed, 25 Sep 2013 08:01:08 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4A221F9F03 for ; Wed, 25 Sep 2013 08:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1747; q=dns/txt; s=iport; t=1380121263; x=1381330863; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=Zul2j0DY+Mx0CXyX3DILrh8KqLvJp5L3xX4VqUm8Lgw=; b=a22zq75CuE7me8RU/KwjsmPPrUK5PXlLFAyG+zhtcwa6w5HkC5Ne+Qsl t7jRrPn+41XI6KNm870gz43mkHt9m1LOzLq7E4JVJPZk02lpa6lX+Cu9u XhCP+fVetBh8ztqD6K1/29Ea5Y3jHhDTjDPyV5RmvX8rCgG6JQJ8wCYGU 8=; X-IronPort-AV: E=Sophos;i="4.90,978,1371081600"; d="scan'208";a="93094051" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 25 Sep 2013 15:00:43 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8PF0f1V031715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 15:00:42 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r8PF0e0B013084; Wed, 25 Sep 2013 11:00:40 -0400 From: Eric Rosen To: bruno.decraene@orange.com In-reply-to: Your message of Wed, 25 Sep 2013 07:15:02 -0000. <28145_1380093304_52428D77_28145_2975_2_53C29892C857584299CBF5D05346208A07061641@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Wed, 25 Sep 2013 11:00:40 -0400 Message-ID: <13083.1380121240@erosen-linux> Cc: idr wg , "draft-ietf-idr-aigp.all@tools.ietf.org" , erosen@cisco.com Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:01:16 -0000 Eric> After five years and at least three implementations, there would need Eric> to be a very strong technical justification for changing the encoding. Bruno> I agree with you. However, to clarify, that was neither my question Bruno> (is there any reason for preferring one option or the other) nor my Bruno> point (for my information; for future documents/usages). To come Bruno> back to my question, I guess your answer is "no". There is no particular reason why the draft specifies one TLV encoding rather than another, and I'm not aware of any document recommending a particular encoding technique. > in case of error, you withdraw the route -which is usually used- while you > could only withdraw the attribute -which apparently is not required (to be > consistent within the AS) I can't say that I have strong feelings about this one way or the other. Bruno> Shouldn't [BESTEXT] and [ADDPATH] be normative references? I don't think so, as they are not strictly required in order to implement AIGP. Bruno> Usually the name [ADDPATH] refers to "draft-ietf-idr-add-paths" and Bruno> not to "draft-pmohapat-idr-fast-conn-restore" I will change the reference name. draft> [The AIGP attribute] "may be added only to routes that satisfy one of draft> the following conditions: [...] The route is an EBGP-learned route draft> whose AS_PATH contains only ASes that are in the same AIGP draft> Administrative Domain as the BGP speaker." Bruno> This seems to mandate that implementations MUST support a Bruno> configuration item listing the ASes numbers which are part of the Bruno> AIGP AD. I think there are a variety of ways to meet this condition without having such a configuration item. From gdawra@cisco.com Wed Sep 25 08:02:38 2013 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 BB50721F99E8 for ; Wed, 25 Sep 2013 08:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjMysAaUwTAu for ; Wed, 25 Sep 2013 08:02:33 -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 9F79E21F9FD7 for ; Wed, 25 Sep 2013 08:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5308; q=dns/txt; s=iport; t=1380121347; x=1381330947; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=6enKAFd5posOoB+chIxyFWTAWW+7B51mz3MPzB6M9to=; b=JX/NJxZKvdJnfMyBYL8tf8okSrTfubmcpTekbLlfIxplrCOfUlmDV36O iAxz2X9YPPQ9StA145YYfOnCVKzKrKc8/VtDBn6de/lo3qBSzF5liFlGG PAAWy/KaB2N04I7qQoVs+pSc183pHNg3sTiVZuQY4fpyd8sXSEdxHm/0Z o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoGAIb6QlKtJV2Z/2dsb2JhbABbgkNEOFKuJYleiESBHRZ0giUBAQEEHRBMEgEIDgMDAQILHTkUCQgCBAENBQiHfgy8Fo8gIBEHgx2BAAOZK5BIgySCKg X-IronPort-AV: E=Sophos;i="4.90,978,1371081600"; d="scan'208,217";a="264413827" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 25 Sep 2013 15:02:17 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8PF2HMk006671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 15:02:17 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.239]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 10:02:16 -0500 From: "Gaurav Dawra (gdawra)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOugA4C42IzMPIcEOTrD6dQhtrSg== Date: Wed, 25 Sep 2013 15:02:16 +0000 Message-ID: In-Reply-To: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.88.178] Content-Type: multipart/alternative; boundary="_000_DA0CF4624FFC5A4494FF2C4009A5744908DF761Axmbalnx08ciscoc_" MIME-Version: 1.0 Cc: "'John G. Scudder'" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:02:38 -0000 --_000_DA0CF4624FFC5A4494FF2C4009A5744908DF761Axmbalnx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Thanks, -Gaurav From: Susan Hares > Date: Friday, September 13, 2013 4:12 PM To: idr wg > Cc: "'John G. Scudder'" > Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) This is to start at 2 week WG last call for The Accumulated IGP Metric Attribute for BGP draft-ietf-idr-aigp-10.txt http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ This last call will end 9/27/13 Three implementations exist: ALU, Cisco, Juniper. Vote early and speak often. Sue and John IDR co-chairs --_000_DA0CF4624FFC5A4494FF2C4009A5744908DF761Axmbalnx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support.

Thanks,
-Gaurav

From: Susan Hares <shares@ndzh.com>
Date: Friday, September 13, 2013 4:= 12 PM
To: idr wg <idr@ietf.org>
Cc: "'John G. Scudder'" &= lt;jgs@bgp.nu>
Subject: [Idr] WG Last call for dra= ft-ietf-idr-aigp-10 (ending 9/27/13)

This is to start at 2 week WG last call for

 

The Accumulated IGP Metric Attribute= for BGP

draft-ietf-idr-aigp-10.txt

 

http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/<= /o:p>

 

This last call will end 9/27/13

 

Three implementations exist: ALU, Cisco, Juniper.

 

Vote early and speak often.

 

Sue and John

IDR co-chairs

 

 --_000_DA0CF4624FFC5A4494FF2C4009A5744908DF761Axmbalnx08ciscoc_-- From bduvivie@cisco.com Wed Sep 25 08:29:45 2013 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 1977811E8119 for ; Wed, 25 Sep 2013 08:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-Y4BfGEFLJw for ; Wed, 25 Sep 2013 08:29:31 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D798711E810D for ; Wed, 25 Sep 2013 08:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8903; q=dns/txt; s=iport; t=1380122959; x=1381332559; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tRlPinvQcCgJajPqM4CPssixjpV55plJurr3OUMRtQM=; b=MCCzDTkWGaH1uQo+mbPIDKYaJlHoFXUgQm5plSE/hssFcMljKvnrB6iF dHLf0pOxjXtk70cFf8usM+77+IQlBdmZGDj8eZqVFJysoJ0dyZWXy6DSc RJ6VOofkrhKBX0HFg1KB11ZgOBf08XqH5UEU5rmfVWpooGu/x+SRj8J1e g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksGAM8AQ1KtJXG//2dsb2JhbABbgkNEOFKuJYleiESBHhZ0giUBAQEEHRBMEAIBCBEDAQEBCx0HMhQJCAIEAQ0FCId+DLwJjyAgEQYBgx2BAAOZK5BIgySCKg X-IronPort-AV: E=Sophos;i="4.90,978,1371081600"; d="scan'208,217";a="264328255" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 25 Sep 2013 15:29:10 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8PFTAE6002367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 15:29:10 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.253]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 10:29:10 -0500 From: "Bertrand Duvivier (bduvivie)" To: "Gaurav Dawra (gdawra)" , Susan Hares , idr wg Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOugA4C42IzMPIcEOTrD6dQhtrSpnWkqaA Date: Wed, 25 Sep 2013 15:29:09 +0000 Message-ID: <5F1FD493E541C642ABBC18EDC327C82F1F27917D@xmb-aln-x11.cisco.com> References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.113.245] Content-Type: multipart/alternative; boundary="_000_5F1FD493E541C642ABBC18EDC327C82F1F27917Dxmbalnx11ciscoc_" MIME-Version: 1.0 Cc: "'John G. Scudder'" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:29:45 -0000 X-List-Received-Date: Wed, 25 Sep 2013 15:29:45 -0000 --_000_5F1FD493E541C642ABBC18EDC327C82F1F27917Dxmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support, Just to mention, at Cisco we do support AIGP on both IOS Classic OS and XR = OS, therefore we should consider this as 2 separate BGP implementations. Therefore we talking about 4 implementations. BRGDS Bertrand From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Gaura= v Dawra (gdawra) Sent: mercredi 25 septembre 2013 17:02 To: Susan Hares; idr wg Cc: 'John G. Scudder' Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Support. Thanks, -Gaurav From: Susan Hares > Date: Friday, September 13, 2013 4:12 PM To: idr wg > Cc: "'John G. Scudder'" > Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) This is to start at 2 week WG last call for The Accumulated IGP Metric Attribute for BGP draft-ietf-idr-aigp-10.txt http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ This last call will end 9/27/13 Three implementations exist: ALU, Cisco, Juniper. Vote early and speak often. Sue and John IDR co-chairs --_000_5F1FD493E541C642ABBC18EDC327C82F1F27917Dxmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support,

 

Just to mention, at Ci= sco we do support AIGP on both IOS Classic OS and XR OS, therefore we shoul= d consider this as 2 separate BGP implementations.

 

Therefore we talking a= bout 4  implementations.

 

BRGDS Bertrand

 

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Gaurav Dawra (gdawra)
Sent: mercredi 25 septembre 2013 17:02
To: Susan Hares; idr wg
Cc: 'John G. Scudder'
Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9= /27/13)

 

Support.

 

Thanks,

-Gaurav

 

From: Susan Hares <= shares@ndzh.com>
Date: Friday, September 13, 2013 4:12 PM
To: idr wg <idr@ietf.org><= br> Cc: "'John G. Scudder'" <= jgs@bgp.nu>
Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/= 13)

 

This is to start at 2 we= ek WG last call for

 =

The Accumulated I= GP Metric Attribute for BGP

draft-ietf-idr-ai= gp-10.txt

 =

http://datatracker.ietf.org/doc/dr= aft-ietf-idr-aigp/

 =

This last call will end = 9/27/13

 =

Three implementations ex= ist: ALU, Cisco, Juniper.

 =

Vote early and speak oft= en.

 =

Sue and John =

IDR co-chairs

 =

--_000_5F1FD493E541C642ABBC18EDC327C82F1F27917Dxmbalnx11ciscoc_-- From aservin@lacnic.net Wed Sep 25 08:33:06 2013 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 8D04421F9A16 for ; Wed, 25 Sep 2013 08:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyuePxnQlYTP for ; Wed, 25 Sep 2013 08:33:00 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDAB21F940D for ; Wed, 25 Sep 2013 08:32:58 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [200.7.87.33]) by mail.lacnic.net.uy (Postfix) with ESMTP id 320AA3084C3; Wed, 25 Sep 2013 12:32:30 -0300 (UYT) Message-ID: <52430226.1030702@lacnic.net> Date: Wed, 25 Sep 2013 12:32:54 -0300 From: Arturo Servin Organization: LACNIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Roque Gagliano (rogaglia)" References: <52403E4D.8090904@foobar.org> <524186F0.2050906@lacnic.net> <52418920.3070602@foobar.org> <52418CFA.9040508@lacnic.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "" Subject: Re: [Idr] 16bit ASN exhaustion X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:33:06 -0000 It says "IANA allocates ASNs to RIRs in blocks of 1024 ASNs" Those could be 1 ASN of 2 bytes and 1023 ASNs of 4 bytes. They do not do that extreme case, but just check how many 16 bits ASNs were given to APNIC (it was half block of 1024). Also, in NANOG, IANA clarifies that they still have ASNs to allocate. http://mailman.nanog.org/pipermail/nanog/2013-September/061191.html /as On 9/24/13 11:25 AM, Roque Gagliano (rogaglia) wrote: > On Sep 24, 2013, at 3:00 PM, Arturo Servin > wrote: > >> >> Yes, I know. >> >> But check this archived version of the IANA registry: >> >> http://web.archive.org/web/20111020211749/http://www.iana.org/assignments/as-numbers/as-numbers.xml >> >> Note that ASNs that are marked as "Reserved" are now allocated. As I >> said, ask IANA for clarification but my impression is that those are >> reserved for allocation and not for any other use. > > IANA can only allocate blocks of 1024. So, the space is technically depleted > > Policy Ref: https://www.icann.org/en/resources/policy/global-addressing/global-policy-asn-blocks-21sep10-en.htm > > Roque > >> Regards, >> as >> >> On 9/24/13 9:44 AM, Nick Hilliard wrote: >>> On 24/09/2013 13:34, Arturo Servin wrote: >>>> 64000-64495 Reserved by the IANA >>>> >>>> Anyway, it may be irrelevant because they may go away in any moment. >>> >>> those are reserved rather than unallocated. By comparison, the available >>> ASN32 ranges are marked as "unallocated". >>> >>> Nick >>> >>> _______________________________________________ >>> 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 bhavani@cisco.com Wed Sep 25 08:43:21 2013 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 6018511E8108 for ; Wed, 25 Sep 2013 08:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GT7yUYrp7T0 for ; Wed, 25 Sep 2013 08:43:17 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C08C511E8115 for ; Wed, 25 Sep 2013 08:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4570; q=dns/txt; s=iport; t=1380123796; x=1381333396; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=L/HBH4YsVbcFxrxWDcwiYKhz6ROSoW1UnBmDnaLEFlQ=; b=gT63vkKHfnbLZg+gNOXJ615WCLzsaUgzMADwn8nMsQgPPs1qrCX+qmAK IFpAMwxab6kQQFN3e+Z5HxGMqq6sx3hLx7o6cJAbzzbzrrA+XCe2lSBEm TPUqxIaHAfUwKHEPlakUvZT6lTEw5zL3+v0HHvR778OO38c04LwW9SnJ2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAKUDQ1KrRDoH/2dsb2JhbABbgkNEOIlYt0GBHhZ0giUBAQEEAQEBGhBBChELGAkWDwkDAgECARUwEwYCAQGIAQ28Co9YFoQHA4k4jkSBL4UDi0WDRBw X-IronPort-AV: E=Sophos;i="4.90,978,1371081600"; d="scan'208,217";a="93158022" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 25 Sep 2013 15:43:16 +0000 Received: from [10.21.126.201] (sjc-vpn6-1737.cisco.com [10.21.126.201]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8PFhFfU028876 for ; Wed, 25 Sep 2013 15:43:15 GMT Message-ID: <52430494.9030809@cisco.com> Date: Wed, 25 Sep 2013 08:43:16 -0700 From: Bhavani Parise User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: idr@ietf.org References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> In-Reply-To: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> Content-Type: multipart/alternative; boundary="------------010000040300050507070607" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:43:21 -0000 This is a multi-part message in MIME format. --------------010000040300050507070607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit support regards, Bhavani On 9/13/13 4:12 PM, Susan Hares wrote: > > This is to start at 2 week WG last call for > > The Accumulated IGP Metric Attribute for BGP > > draft-ietf-idr-aigp-10.txt > > http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ > > This last call will end 9/27/13 > > Three implementations exist: ALU, Cisco, Juniper. > > Vote early and speak often. > > Sue and John > > IDR co-chairs > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------010000040300050507070607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

support

regards,
Bhavani

On 9/13/13 4:12 PM, Susan Hares wrote:

This is to start at 2 week WG last call for

 

The Accumulated IGP Metric Attribute for BGP

draft-ietf-idr-aigp-10.txt

 

http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/

 

This last call will end 9/27/13

 

Three implementations exist: ALU, Cisco, Juniper.

 

Vote early and speak often.

 

Sue and John

IDR co-chairs

 



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

--------------010000040300050507070607-- From erosen@cisco.com Wed Sep 25 08:48:14 2013 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 CFD5121F9DE1 for ; Wed, 25 Sep 2013 08:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNvc7fBvJNaN for ; Wed, 25 Sep 2013 08:48:09 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A90121F9D8D for ; Wed, 25 Sep 2013 08:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1499; q=dns/txt; s=iport; t=1380124086; x=1381333686; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=aIjyd3dQxR2OmXNxItB/+PIhJJBAgnKWvUOIUVIQTuE=; b=Anw10aqhxxI+PADZir4OyZqtRSQ5K3BUdMIY7tQXeUriCw8l42AJUFxl n5RAnUXJG+b6HD0REEW3wdkA/DebhCPIAq2de3ah/g5bD04pvvUDvRdXM J+p/Oa9iaLtqIajDOIHqRPQ/qJePtLqKIFPExOkQXLB/JxUHAY7JxpCjM o=; X-IronPort-AV: E=Sophos;i="4.90,978,1371081600"; d="scan'208";a="264155857" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 25 Sep 2013 15:48:05 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8PFm4Vn028612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 15:48:05 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r8PFm4Zv014934; Wed, 25 Sep 2013 11:48:04 -0400 From: Eric Rosen To: "Dickson, Brian" In-reply-to: Your message of Tue, 24 Sep 2013 20:07:23 -0000. Date: Wed, 25 Sep 2013 11:48:04 -0400 Message-ID: <14933.1380124084@erosen-linux> Cc: "bruno.decraene@orange.com" , "draft-ietf-idr-aigp.all@tools.ietf.org" , erosen@cisco.com, idr wg Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:48:14 -0000 Brian> I'd be happy to point the authors at a variety of cases where Brian> introducing something new/different in the transitive environment Brian> broke things. What is meant by "the transitive environment"? The AIGP attribute is a non-transitive attribute, so it won't generally get passed along by BGP speakers who don't understand it. Thus it shouldn't be subject to the "each BGP speaker passes it along and then crashes" problem that we sometimes see with new transitive attributes. Brian> It violates the "two missile key" approach to networking Eric> The purpose of AIGP_SESSION is to ensure that you ignore AIGP Eric> attributes that mistakenly leak out of other administrative domains. Brian> Again, this presumes that "ignore" functionality works as expected. If you receive an AIGP attribute from another administrative domain, then a mistake has been made on the other side of your BGP session. AIGP_SESSION is the "second missile key" that you seem to want in this case; it protects you if you understand the non-transitive attribute but don't want to receive it on a particular session. However, I have no particular objection to changing the default value of AIGP_SESSION if it is the consensus of the WG that it should always default to "disabled". I am skeptical though that it will have much of a protective effect on internal BGP sessions, as it will probably just get enabled semi-automatically by script or template on those sessions. From bdickson@verisign.com Wed Sep 25 09:08:55 2013 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 D711F21F9B7E for ; Wed, 25 Sep 2013 09:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t30PPWYXKR4k for ; Wed, 25 Sep 2013 09:08:49 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 7978021F9CA5 for ; Wed, 25 Sep 2013 09:08:43 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUkMKiE7MpYepVLduxeKfXkkiZTHqhLCF@postini.com; Wed, 25 Sep 2013 09:08:46 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r8PG8bP0014401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 12:08:37 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 25 Sep 2013 12:08:37 -0400 From: "Dickson, Brian" To: "erosen@cisco.com" Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOugaeoZDNOu+SQiq0dAmRJ9YB/pnWnuoA Date: Wed, 25 Sep 2013 16:08:35 +0000 Message-ID: In-Reply-To: <14933.1380124084@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <63332237117D544C92084CFE8760AB84@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bruno.decraene@orange.com" , "draft-ietf-idr-aigp.all@tools.ietf.org" , idr wg Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:08:56 -0000 Hi, Eric, I think it would be sufficient to have this be a negotiated capability. E.g. router A and router B both speak AIGP (and have it enabled, e.g. by default) -> both advertise the capability -> both ends have AIGP_SESSION enabled. All other cases (either A or B does not speak AIGP, or have it disabled globally or for this session) result in AIGP_SESSION being disabled FOR THAT NEIGHBOR PAIR. A router that does not speak AIGP would never receive the attribute, so the issue becomes moot. Add global enable/disable, plus per-peer enable/disable, and the risk is significantly mitigated. On 9/25/13 11:48 AM, "Eric Rosen" wrote: > >Brian> I'd be happy to point the authors at a variety of cases where >Brian> introducing something new/different in the transitive environment >Brian> broke things. > >What is meant by "the transitive environment"? The DFZ, the global set of BGP speakers. Typically new attributes, or changes to implementations of attributes, normally transitive attributes caused the problem. The issue is, past issues were triggered between EBGP speakers of different vendor boxes. If the problem triggered session resents on vendor C, but was being propagated by vendor J, for an issue originated by vendor A, major chaos was the result. Here, what I am cautioning is, breaking things on an IBGP basis (if a session reset occurs), can lead to similar effects, perhaps at a lesser scale (single AS breakage). But the impact, if the AS in question is not a "leaf" AS, is larger than just the AS in question. E.g. if the problem manifested itself in one of the 10 biggest ASes globally, the impact would likely be felt by thousands of ASes. > >The AIGP attribute is a non-transitive attribute, so it won't generally >get >passed along by BGP speakers who don't understand it. Thus it shouldn't >be >subject to the "each BGP speaker passes it along and then crashes" problem >that we sometimes see with new transitive attributes. > >Brian> It violates the "two missile key" approach to networking > >Eric> The purpose of AIGP_SESSION is to ensure that you ignore AIGP >Eric> attributes that mistakenly leak out of other administrative domains. > >Brian> Again, this presumes that "ignore" functionality works as expected. > >If you receive an AIGP attribute from another administrative domain, then >a mistake has been made on the other side of your BGP session. >AIGP_SESSION >is the "second missile key" that you seem to want in this case; it >protects >you if you understand the non-transitive attribute but don't want to >receive >it on a particular session. > >However, I have no particular objection to changing the default value of >AIGP_SESSION if it is the consensus of the WG that it should always >default >to "disabled". I am skeptical though that it will have much of a >protective >effect on internal BGP sessions, as it will probably just get enabled >semi-automatically by script or template on those sessions. See my top-reply comments. Negotiated is much better than unilateral, when it comes to "default". Brian From rraszuk@gmail.com Wed Sep 25 09:09:59 2013 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 7728E21F84E0 for ; Wed, 25 Sep 2013 09:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSwQMJOMB93c for ; Wed, 25 Sep 2013 09:09:59 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE3721F9B57 for ; Wed, 25 Sep 2013 09:09:55 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id tp5so11149126ieb.12 for ; Wed, 25 Sep 2013 09:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5levyDt0e7sISPXksHYEoNNKQ2ooMhlgHqKUiwAUKOU=; b=Mez4qm9gRJBomHDODGKGeKbUp1hXQGEKfr/I7sikJ6jI7s7yn7BS/f/AZHwgYGONeK HM1lt02NPg9d5iR9XGIyAmLblhH8btDM4CS7ybhRXT+Kg2VzK/4io2lJ5WKdM8nCim/3 j8whsLOWQB5fGL23oTUNCe/Qa40bFO5u+O0tBSZLVYpGUTNrgO9L6kZv5smHwopBzCIg U0teaiLALTYxiU8TFkFH8y3vZCbWFlK/Pcs+lW38iJEK1aFumyP8oKWhduNW98oVRAhg 4IvbHlSxoz/3oxzTAb8bpzKm+fMJEL3Wb9fam50I4bXXNxEJVfK/NsXRFQqy3fIB2ab+ 4ELg== MIME-Version: 1.0 X-Received: by 10.42.61.147 with SMTP id u19mr19823306ich.36.1380125392819; Wed, 25 Sep 2013 09:09:52 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Wed, 25 Sep 2013 09:09:52 -0700 (PDT) In-Reply-To: <14933.1380124084@erosen-linux> References: <14933.1380124084@erosen-linux> Date: Wed, 25 Sep 2013 18:09:52 +0200 X-Google-Sender-Auth: 1FnDe1gveIOV9U8NlrupOgTLnXw Message-ID: From: Robert Raszuk To: "erosen@cisco.com" Content-Type: text/plain; charset=ISO-8859-1 Cc: "bruno.decraene@orange.com" , "draft-ietf-idr-aigp.all@tools.ietf.org" , idr wg Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:09:59 -0000 Hi Eric, > However, I have no particular objection to changing the default value of > AIGP_SESSION if it is the consensus of the WG that it should always > default to "disabled". If by "disable" you mean that default policy on EBGP sessions on inbound is to drop such attribute (meaning strip it from BGP_UPDATE message) unless explicitly permitted by policy then perhaps it will address Brian's concern > I am skeptical though that it will have much of a protective > effect on internal BGP sessions, as it will probably just get enabled > semi-automatically by script or template on those sessions. I am not sure we should filter anything on IBGP sessions at all. Best, r. From ju1738@att.com Wed Sep 25 09:25:24 2013 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 488B911E8117 for ; Wed, 25 Sep 2013 09:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I--iYoCI+HyJ for ; Wed, 25 Sep 2013 09:25:17 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB4721F9D30 for ; Wed, 25 Sep 2013 09:25:15 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b6e03425.7f23d940.1477875.00-528.3889665.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 25 Sep 2013 16:25:15 +0000 (UTC) X-MXL-Hash: 52430e6b6fca45fc-dc7102cf9ed86f7d52c974c2ccb5cc3e9280bebb Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 06e03425.0.1477862.00-234.3889403.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 25 Sep 2013 16:25:05 +0000 (UTC) X-MXL-Hash: 52430e612869a500-a6b8f56ef2da03ea97387e22472ed065325bce2a Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8PGP3s0009829; Wed, 25 Sep 2013 12:25:04 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8PGOnbM009626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 12:24:58 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 25 Sep 2013 16:24:37 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0158.001; Wed, 25 Sep 2013 12:24:37 -0400 From: "UTTARO, JAMES" To: "erosen@cisco.com" , "Dickson, Brian" Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOugaeoZDNOu+SQiq0dAmRJ9YB/pnWoyOw Date: Wed, 25 Sep 2013 16:24:37 +0000 Message-ID: References: Your message of Tue, 24 Sep 2013 20:07:23 -0000. <14933.1380124084@erosen-linux> In-Reply-To: <14933.1380124084@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.246.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=Rv1y2laK c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=svwTKtZ8aEEA:10 a=5Ay4ljVScIYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16pnZUWWBcIA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=AUd_NHdVAAAA:8 a=9d0uurpfp7M8AAn6dzEA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10 a=JfD0Fch1gWkA:10 a] X-AnalysisOut: [=bfJyFJH4kj_AvtTb:21 a=hedTB5LIi1p7PPJC:21] Cc: "bruno.decraene@orange.com" , "draft-ietf-idr-aigp.all@tools.ietf.org" , idr wg Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:25:24 -0000 "Enabling" by default greatly simplifies the operational model. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Eric = Rosen Sent: Wednesday, September 25, 2013 11:48 AM To: Dickson, Brian Cc: bruno.decraene@orange.com; draft-ietf-idr-aigp.all@tools.ietf.org; eros= en@cisco.com; idr wg Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Brian> I'd be happy to point the authors at a variety of cases where Brian> introducing something new/different in the transitive environment Brian> broke things. What is meant by "the transitive environment"? The AIGP attribute is a non-transitive attribute, so it won't generally get passed along by BGP speakers who don't understand it. Thus it shouldn't be subject to the "each BGP speaker passes it along and then crashes" problem that we sometimes see with new transitive attributes. Brian> It violates the "two missile key" approach to networking Eric> The purpose of AIGP_SESSION is to ensure that you ignore AIGP Eric> attributes that mistakenly leak out of other administrative domains. Brian> Again, this presumes that "ignore" functionality works as expected. If you receive an AIGP attribute from another administrative domain, then a mistake has been made on the other side of your BGP session. AIGP_SESSIO= N is the "second missile key" that you seem to want in this case; it protects you if you understand the non-transitive attribute but don't want to receiv= e it on a particular session. However, I have no particular objection to changing the default value of AIGP_SESSION if it is the consensus of the WG that it should always default to "disabled". I am skeptical though that it will have much of a protectiv= e effect on internal BGP sessions, as it will probably just get enabled semi-automatically by script or template on those sessions. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Wed Sep 25 09:30:04 2013 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 15C2921E805F for ; Wed, 25 Sep 2013 09:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozbXY8Mn4-Ji for ; Wed, 25 Sep 2013 09:29:57 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6A021F9C87 for ; Wed, 25 Sep 2013 09:29:57 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 58f03425.2aaad3a18940.8640230.00-573.23749981.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 25 Sep 2013 16:29:57 +0000 (UTC) X-MXL-Hash: 52430f8509ce1711-af33510a143a317175fa58b29101ab3744f37aad Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id f7f03425.0.8640222.00-219.23749860.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 25 Sep 2013 16:29:52 +0000 (UTC) X-MXL-Hash: 52430f801a8c2418-9a3ff0998391af89d667d4d358d36ed38f00326b Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8PGTpPs014432; Wed, 25 Sep 2013 12:29:51 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8PGTdfQ014249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 12:29:44 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 25 Sep 2013 16:29:26 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.03.0158.001; Wed, 25 Sep 2013 12:29:26 -0400 From: "UTTARO, JAMES" To: "erosen@cisco.com" , "bruno.decraene@orange.com" Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOuf//oZDNOu+SQiq0dAmRJ9YB/pnWpFVw Date: Wed, 25 Sep 2013 16:29:25 +0000 Message-ID: References: Your message of Wed, 25 Sep 2013 07:15:02 -0000. <28145_1380093304_52428D77_28145_2975_2_53C29892C857584299CBF5D05346208A07061641@PEXCVZYM11.corporate.adroot.infra.ftgroup> <13083.1380121240@erosen-linux> In-Reply-To: <13083.1380121240@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.246.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=svwTKtZ8aEEA:10 a=5Ay4ljVScIYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16pnZUWWBcIA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=AUd_NHdVAAAA:8 a=9d0uurpfp7M8AAn6dzEA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10 a=JfD0Fch1gWkA:10] Cc: idr wg , "draft-ietf-idr-aigp.all@tools.ietf.org" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:30:04 -0000 Support as co-author.. FYI we ( AT&T ) are currently suing the AIGP in the = architecture of our domestic and global networks.. We have not encountered = a need to change the encoding and I would be wary of changing this without = better understanding.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Eric = Rosen Sent: Wednesday, September 25, 2013 11:01 AM To: bruno.decraene@orange.com Cc: idr wg; draft-ietf-idr-aigp.all@tools.ietf.org; erosen@cisco.com Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Eric> After five years and at least three implementations, there would need Eric> to be a very strong technical justification for changing the encoding= . Bruno> I agree with you. However, to clarify, that was neither my question Bruno> (is there any reason for preferring one option or the other) nor my Bruno> point (for my information; for future documents/usages). To come Bruno> back to my question, I guess your answer is "no". There is no particular reason why the draft specifies one TLV encoding rather than another, and I'm not aware of any document recommending a particular encoding technique. > in case of error, you withdraw the route -which is usually used- while yo= u > could only withdraw the attribute -which apparently is not required (to b= e > consistent within the AS) I can't say that I have strong feelings about this one way or the other. Bruno> Shouldn't [BESTEXT] and [ADDPATH] be normative references? I don't think so, as they are not strictly required in order to implement AIGP. Bruno> Usually the name [ADDPATH] refers to "draft-ietf-idr-add-paths" and Bruno> not to "draft-pmohapat-idr-fast-conn-restore" I will change the reference name. draft> [The AIGP attribute] "may be added only to routes that satisfy one o= f draft> the following conditions: [...] The route is an EBGP-learned route draft> whose AS_PATH contains only ASes that are in the same AIGP draft> Administrative Domain as the BGP speaker." Bruno> This seems to mandate that implementations MUST support a Bruno> configuration item listing the ASes numbers which are part of the Bruno> AIGP AD. I think there are a variety of ways to meet this condition without having such a configuration item. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Wed Sep 25 09:37:52 2013 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 4FE9411E811D for ; Wed, 25 Sep 2013 09:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSjBJOV1bV+V for ; Wed, 25 Sep 2013 09:37:46 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id DDD1821F99DC for ; Wed, 25 Sep 2013 09:37:04 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 03113425.2aaaec03f940.8645337.00-549.23764454.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 25 Sep 2013 16:37:04 +0000 (UTC) X-MXL-Hash: 52431130542dac45-8538609324497eb86578258625a4dedd6754952f Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id e2113425.0.8645310.00-363.23764332.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 25 Sep 2013 16:37:02 +0000 (UTC) X-MXL-Hash: 5243112e6809641a-8dc10409cd29b28575500051260718b085e4f45d Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8PGb19s025354; Wed, 25 Sep 2013 12:37:02 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8PGaujv025279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 12:36:58 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 25 Sep 2013 16:36:43 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0158.001; Wed, 25 Sep 2013 12:36:42 -0400 From: "UTTARO, JAMES" To: "erosen@cisco.com" , "bruno.decraene@orange.com" Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOuV0OoZDNOu+SQiq0dAmRJ9YB/pnWp42Q Date: Wed, 25 Sep 2013 16:36:42 +0000 Message-ID: References: Your message of Tue, 24 Sep 2013 14:32:51 -0000. <23255_1380033172_5241A294_23255_1465_1_53C29892C857584299CBF5D05346208A0706134B@PEXCVZYM11.corporate.adroot.infra.ftgroup> <26159.1380051241@erosen-linux> In-Reply-To: <26159.1380051241@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.246.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=svwTKtZ8aEEA:10 a=5Ay4ljVScIYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16pnZUWWBcIA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=AUd_NHdVAAAA:8 a=NmssVvgfW8udh7dyWBgA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10 a=JfD0Fch1gWkA:10 a] X-AnalysisOut: [=rvlx-uMlRSNnlIO4:21 a=5hpfVVAEAfn_tJEb:21] Cc: idr wg , "draft-ietf-idr-aigp.all@tools.ietf.org" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:37:52 -0000 Comments In-Line Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Eric = Rosen Sent: Tuesday, September 24, 2013 3:34 PM To: bruno.decraene@orange.com Cc: idr wg; draft-ietf-idr-aigp.all@tools.ietf.org; erosen@cisco.com Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) > 1) A question for my own culture, regarding TLV encoding: > draft-ietf-idr-aigp defines the Length field as "Length: Two octets > encoding the length in octets of the TLV, including the type and lengt= h > fields."=20 > Is there any reason to include the type and length? After five years and at least three implementations, there would need to be a very strong technical justification for changing the encoding. [Jim U>] Along with the fact that it is implemented in a production network > "The default value of AIGP_SESSION, for IBGP and confederation-EBGP > sessions, MUST be "enabled." IMHO the "MUST be enabled by default" is > questionable. IMHO people wanting AIGP should be able to configure it. A= nd > people not wanting the attribute, should have nothing to do. If you leave the AIGP_SESSION and AIGP_ORIGINATE parameters at their defaul= t values in all your routers, then you will never attach an AIGP attribute to any prefix, and you will discard any AIGP attribute that arrives from another administrative domain. So I think the draft meets your requirement= , i.e., if you don't want to use AIGP you don't have to do anything. [Jim U>] As intended. If you do want to attach AIGP to a prefix, you have to configure it at the routers that originate routes to that prefix. The purpose of AIGP_SESSION is to ensure that you ignore AIGP attributes that mistakenly leak out of other administrative domains. > And IMHO if I were using AIGP, I would rather call for a global cli > enabling AIGP on all IBGP/confederation-EBGP sessions. That would be a very reasonable request to make of your vendor. [Jim U>] +1 > From my reading of draft-ietf-idr-error-handling, a length error in the > AIGP attribute (which seems doable as per the first comment) would result > in "treat-as-withdraw". I have the same interpretation. > Is this the desired behavior? I don't see a problem with it. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Wed Sep 25 09:42:26 2013 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 814E921F9E26 for ; Wed, 25 Sep 2013 09:42:26 -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=[AWL=-0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5nRtnqtTfnS for ; Wed, 25 Sep 2013 09:42:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 168F121F997D for ; Wed, 25 Sep 2013 09:42:20 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 6B509190289; Wed, 25 Sep 2013 18:42:19 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 48A0A158099; Wed, 25 Sep 2013 18:42:19 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 25 Sep 2013 18:42:18 +0200 From: To: "erosen@cisco.com" Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOuf//oZDNOu+SQiq0dAmRJ9YB/pnWp2hQ Date: Wed, 25 Sep 2013 16:42:17 +0000 Message-ID: <16570_1380127339_5243126B_16570_16593_1_53C29892C857584299CBF5D05346208A07061BC3@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: Your message of Wed, 25 Sep 2013 07:15:02 -0000. <28145_1380093304_52428D77_28145_2975_2_53C29892C857584299CBF5D05346208A07061641@PEXCVZYM11.corporate.adroot.infra.ftgroup> <13083.1380121240@erosen-linux> In-Reply-To: <13083.1380121240@erosen-linux> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.25.51815 Cc: idr wg , "draft-ietf-idr-aigp.all@tools.ietf.org" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:42:26 -0000 Eric, Thank you for answering and addressing all my comments. That's fine for me. Regards, Bruno >From: Eric Rosen [mailto:erosen@cisco.com] > > >Eric> After five years and at least three implementations, there would need >Eric> to be a very strong technical justification for changing the encodin= g. > >Bruno> I agree with you. However, to clarify, that was neither my question >Bruno> (is there any reason for preferring one option or the other) nor my >Bruno> point (for my information; for future documents/usages). To come >Bruno> back to my question, I guess your answer is "no". > >There is no particular reason why the draft specifies one TLV encoding >rather than another, and I'm not aware of any document recommending a >particular encoding technique. > >> in case of error, you withdraw the route -which is usually used- while y= ou >> could only withdraw the attribute -which apparently is not required (to = be >> consistent within the AS) > >I can't say that I have strong feelings about this one way or the other. > > >Bruno> Shouldn't [BESTEXT] and [ADDPATH] be normative references? > >I don't think so, as they are not strictly required in order to implement >AIGP. > >Bruno> Usually the name [ADDPATH] refers to "draft-ietf-idr-add-paths" and >Bruno> not to "draft-pmohapat-idr-fast-conn-restore" > >I will change the reference name. > >draft> [The AIGP attribute] "may be added only to routes that satisfy one = of >draft> the following conditions: [...] The route is an EBGP-learned route >draft> whose AS_PATH contains only ASes that are in the same AIGP >draft> Administrative Domain as the BGP speaker." > >Bruno> This seems to mandate that implementations MUST support a >Bruno> configuration item listing the ASes numbers which are part of the >Bruno> AIGP AD. > >I think there are a variety of ways to meet this condition without having >such a configuration item. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From thomas.mangin@exa-networks.co.uk Wed Sep 25 10:02:00 2013 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 2DBBB21F937E; Wed, 25 Sep 2013 10:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srUmYH9KA4o4; Wed, 25 Sep 2013 10:01:54 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id 6F83C21F88BA; Wed, 25 Sep 2013 10:01:26 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 25D20A03E9; Wed, 25 Sep 2013 18:01:24 +0100 (BST) Received: from [192.0.2.73] (office.exa-networks.co.uk [82.219.212.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 0CC5D6C0047; Wed, 25 Sep 2013 18:01:24 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_EA9DBA7E-0601-4BE3-80B2-5928C2FBB4ED" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Mangin In-Reply-To: <5F1FD493E541C642ABBC18EDC327C82F1F27917D@xmb-aln-x11.cisco.com> Date: Wed, 25 Sep 2013 18:01:23 +0100 Message-Id: References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> <5F1FD493E541C642ABBC18EDC327C82F1F27917D@xmb-aln-x11.cisco.com> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: idr wg , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:02:00 -0000 --Apple-Mail=_EA9DBA7E-0601-4BE3-80B2-5928C2FBB4ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As I make some criticism about the draft, I will make my position clear, = Support. I believe that this draft has achieved "rough consensus and running = code". And ExaBGP supports the draft since 1 minute ago so Bertrand mail should = read 5 working implementations :-) Thomas On 25 Sep 2013, at 16:29, Bertrand Duvivier (bduvivie) = wrote: > Support, > =20 > Just to mention, at Cisco we do support AIGP on both IOS Classic OS = and XR OS, therefore we should consider this as 2 separate BGP = implementations. > =20 > Therefore we talking about 4 implementations. > =20 > BRGDS Bertrand > =20 > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Gaurav Dawra (gdawra) > Sent: mercredi 25 septembre 2013 17:02 > To: Susan Hares; idr wg > Cc: 'John G. Scudder' > Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending = 9/27/13) > =20 > Support. > =20 > Thanks, > -Gaurav > =20 > From: Susan Hares > Date: Friday, September 13, 2013 4:12 PM > To: idr wg > Cc: "'John G. Scudder'" > Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending = 9/27/13) > =20 > This is to start at 2 week WG last call for > =20 > The Accumulated IGP Metric Attribute for BGP > draft-ietf-idr-aigp-10.txt > =20 > http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ > =20 > This last call will end 9/27/13 > =20 > Three implementations exist: ALU, Cisco, Juniper. > =20 > Vote early and speak often. > =20 > Sue and John > IDR co-chairs > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_EA9DBA7E-0601-4BE3-80B2-5928C2FBB4ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

And ExaBGP supports the = draft since 1 minute ago so Bertrand mail should read 5 working = implementations :-)

Thomas

On = 25 Sep 2013, at 16:29, Bertrand Duvivier (bduvivie) <bduvivie@cisco.com> = wrote:

 
Just to = mention, at Cisco we do support AIGP on both IOS Classic OS and XR OS, = therefore we should consider this as 2 separate BGP = implementations.
 
 
BRGDS = Bertrand
 
 idr-bounces@ietf.org = [mailto:idr-bounces@ietf.org] On Behalf Of Gaurav Dawra = (gdawra)
Sent: mercredi 25 septembre 2013 = 17:02
To: Susan Hares; idr = wg
Cc: 'John = G. Scudder'
Subject: Re: [Idr] WG Last call for = draft-ietf-idr-aigp-10 (ending = 9/27/13)
From: Susan Hares < Friday, September 13, = 2013 4:12 PM
To: idr wg <idr@ietf.org>
Cc: "'John G. Scudder'" = <jgs@bgp.nu>
Subject: [Idr] WG Last call for = draft-ietf-idr-aigp-10 (ending = 9/27/13)
This= is to start at 2 week WG last call for
 
The Accumulated IGP Metric Attribute = for BGP
 
Three implementations exist: = ALU, Cisco, Juniper.
Sue and = John
_____________________= __________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mail= man/listinfo/idr
= --Apple-Mail=_EA9DBA7E-0601-4BE3-80B2-5928C2FBB4ED-- From ankapoor@cisco.com Wed Sep 25 10:14:23 2013 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 3E6A311E811D; Wed, 25 Sep 2013 10:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM+h4MaCJ4HY; Wed, 25 Sep 2013 10:14:18 -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 20BC511E8117; Wed, 25 Sep 2013 10:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14073; q=dns/txt; s=iport; t=1380129258; x=1381338858; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Hz6KzA75sCARXzZWEe4fKHD7jbtBhEbPsB5bECdD9uM=; b=Di+sxYyBqzuv0PsepAickHftezAtkGWu1fdte/zgYWBijNYw6SlFZMCt QCduF3dw8JOzrETKSwCqZP2yi068/+79M7ek6JONpnjjh3l6FxGT0cWZZ +O15wrcYPTDB4GejjDYTIDjDqzf7r1+tFDsVSSgt+b3pHK1Yg7zxMrCPm Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQGAGwZQ1KtJV2c/2dsb2JhbABbgkNEOFKuJ4leiEOBHxZ0giUBAQEEAQEBGlELEgEIEQMBAQELHS4LFAkIAQEEAQ0FCId+DLt7jhiBCCANBAYBgx2BAAOZK5BIgySBcTk X-IronPort-AV: E=Sophos;i="4.90,979,1371081600"; d="scan'208,217";a="264357998" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 25 Sep 2013 17:14:16 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8PHEFqo008470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 17:14:15 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.143]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 12:14:15 -0500 From: "Anoop Kapoor (ankapoor)" To: Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: Ac6w1mK9oZDNOu+SQiq0dAmRJ9YB/gJU78gAAADwW4AAAzihgP//jj4A Date: Wed, 25 Sep 2013 17:14:15 +0000 Message-ID: <45BC6BFD9C998D46A7F8CEAA971ED4F11C089DB1@xmb-aln-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.210.155] Content-Type: multipart/alternative; boundary="_000_45BC6BFD9C998D46A7F8CEAA971ED4F11C089DB1xmbalnx10ciscoc_" MIME-Version: 1.0 Cc: idr wg , Susan Hares , "'John G. Scudder'" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:14:23 -0000 --_000_45BC6BFD9C998D46A7F8CEAA971ED4F11C089DB1xmbalnx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Anoop. From: Thomas Mangin > Date: Wednesday, September 25, 2013 10:01 AM To: "idr-bounces@ietf.org" > Cc: idr wg >, "'John G. Scudder'" >, Susan Hares > Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) As I make some criticism about the draft, I will make my position clear, Su= pport. I believe that this draft has achieved "rough consensus and running code". And ExaBGP supports the draft since 1 minute ago so Bertrand mail should re= ad 5 working implementations :-) Thomas On 25 Sep 2013, at 16:29, Bertrand Duvivier (bduvivie) > wrote: Support, Just to mention, at Cisco we do support AIGP on both IOS Classic OS and XR = OS, therefore we should consider this as 2 separate BGP implementations. Therefore we talking about 4 implementations. BRGDS Bertrand From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Gaurav Dawra (gdawra) Sent: mercredi 25 septembre 2013 17:02 To: Susan Hares; idr wg Cc: 'John G. Scudder' Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Support. Thanks, -Gaurav From: Susan Hares > Date: Friday, September 13, 2013 4:12 PM To: idr wg > Cc: "'John G. Scudder'" > Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) This is to start at 2 week WG last call for The Accumulated IGP Metric Attribute for BGP draft-ietf-idr-aigp-10.txt http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ This last call will end 9/27/13 Three implementations exist: ALU, Cisco, Juniper. Vote early and speak often. Sue and John IDR co-chairs _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_45BC6BFD9C998D46A7F8CEAA971ED4F11C089DB1xmbalnx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <31323060FDD80849BA53A5834BD2E7A1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support.

Anoop.

From: Thomas Mangin <thomas.mangin@exa-networks.co.uk>
Date: Wednesday, September 25, 2013= 10:01 AM
To: "idr-bounces@ietf.org" <idr-bounces@ietf.org>
Cc: idr wg <idr@ietf.org>, "'John G. Scudder'" <jgs@bgp.nu>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] WG Last call for= draft-ietf-idr-aigp-10 (ending 9/27/13)

As I make some criticism about the draft, I will make my position clea= r, Support.
I believe that this draft has achieved "rough consensus and runni= ng code".

And ExaBGP supports the draft since 1 minute ago so Bertrand mail should re= ad 5 working implementations :-)

Thomas

On 25 Sep 2013, at 16:29, Bertrand Duvivier (bduvivie) <bduvivie@cisco.com> wrote:

Support,
 
Just to mention, at Cisco we do s= upport AIGP on both IOS Classic OS and XR OS, therefore we should consider = this as 2 separate BGP implementations.
 
Therefore we talking about 4 &nbs= p;implementations.
 
BRGDS Bertrand<= /div>
 
From:=  idr-bounces@ietf.org [mailto= :idr-bounces@ietf.org] On Behalf Of Gaurav Daw= ra (gdawra)
Sent: mercredi 25 = septembre 2013 17:02
To: Susan Hares; i= dr wg
Cc: 'John G. Scudd= er'
Subject: Re: [Idr]= WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)=
 
Support.
 
Thanks,
-Gaurav
 
From: Susan Hares <shares@ndzh.com<= /a>>
Date: Friday, Sept= ember 13, 2013 4:12 PM
To: idr wg <idr@ietf.org>
Cc: "'John G.= Scudder'" <jgs@bgp.nu>
Subject: [Idr] WG = Last call for draft-ietf-idr-aigp-10 (ending 9/27/13)
 
This is to start at 2 week WG last call for
 
The Accumulat= ed IGP Metric Attribute for BGP
draft-ietf-id= r-aigp-10.txt
 
 
This last call will end 9/27/13
 
Three implementations exist: ALU, Cisco, Juniper.
 
Vote early and speak often.
 
Sue and John
IDR co-chairs
 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/= mailman/listinfo/idr

 --_000_45BC6BFD9C998D46A7F8CEAA971ED4F11C089DB1xmbalnx10ciscoc_-- From jgs@juniper.net Wed Sep 25 10:47:47 2013 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 407E011E8121 for ; Wed, 25 Sep 2013 10:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.303 X-Spam-Level: X-Spam-Status: No, score=-5.303 tagged_above=-999 required=5 tests=[AWL=1.296, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYejVB+6yiMS for ; Wed, 25 Sep 2013 10:47:27 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id DCC9221F96B1 for ; Wed, 25 Sep 2013 10:47:25 -0700 (PDT) Received: from mail116-co9-R.bigfish.com (10.236.132.244) by CO9EHSOBE037.bigfish.com (10.236.130.100) with Microsoft SMTP Server id 14.1.225.22; Wed, 25 Sep 2013 17:47:25 +0000 Received: from mail116-co9 (localhost [127.0.0.1]) by mail116-co9-R.bigfish.com (Postfix) with ESMTP id 0BA36C2016A; Wed, 25 Sep 2013 17:47:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(z21eIz98dI9371I146fI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1de097h8275bhz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail116-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(377454003)(24454002)(5423002)(52314003)(51704005)(57306001)(76796001)(54316002)(56776001)(66066001)(69226001)(83072001)(74366001)(56816003)(77156001)(76482001)(36756003)(77096001)(62966002)(53416003)(23726002)(59766001)(77982001)(79102001)(42186004)(53806001)(76786001)(51856001)(82746002)(50986001)(47736001)(49866001)(47976001)(50226001)(74876001)(46102001)(47446002)(31966008)(74502001)(74706001)(46406003)(19580395003)(74662001)(50466002)(19580405001)(80976001)(83322001)(81542001)(81342001)(63696002)(47776003)(81686001)(4396001)(33656001)(80022001)(81816001)(65816001)(83716002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:jgs-sslvpn-nc.jnpr.net; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail116-co9 (localhost.localdomain [127.0.0.1]) by mail116-co9 (MessageSwitch) id 1380131180903219_23541; Wed, 25 Sep 2013 17:46:20 +0000 (UTC) Received: from CO9EHSMHS021.bigfish.com (unknown [10.236.132.229]) by mail116-co9.bigfish.com (Postfix) with ESMTP id D7CAB380048; Wed, 25 Sep 2013 17:46:20 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS021.bigfish.com (10.236.130.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 25 Sep 2013 17:46:19 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.359.1; Wed, 25 Sep 2013 17:46:17 +0000 Received: from jgs-sslvpn-nc.jnpr.net (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 25 Sep 2013 17:46:16 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "John G. Scudder" In-Reply-To: <13083.1380121240@erosen-linux> Date: Wed, 25 Sep 2013 13:46:06 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <24413D85-9DBA-40F9-9801-27B1B427F79B@juniper.net> References: <13083.1380121240@erosen-linux> To: X-Mailer: Apple Mail (2.1510) X-Originating-IP: [66.129.232.2] X-ClientProxiedBy: BL2PR08CA012.namprd08.prod.outlook.com (10.141.66.32) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) X-Forefront-PRVS: 098076C36C X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: bruno.decraene@orange.com, "draft-ietf-idr-aigp.all@tools.ietf.org" , idr wg Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:47:47 -0000 On Sep 25, 2013, at 11:00 AM, Eric Rosen wrote: > Bruno> Usually the name [ADDPATH] refers to "draft-ietf-idr-add-paths" = and > Bruno> not to "draft-pmohapat-idr-fast-conn-restore" >=20 > I will change the reference name. I believe the RFC Editor changes the reference names according to their = own style guide anyway, so it's probably moot. --John= From ietfc@btconnect.com Thu Sep 26 02:08:48 2013 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 0E32411E817B for ; Thu, 26 Sep 2013 02:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU7777F8OAGB for ; Thu, 26 Sep 2013 02:08:31 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id F034F21F9D23 for ; Thu, 26 Sep 2013 02:08:26 -0700 (PDT) Received: from mail20-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Thu, 26 Sep 2013 09:08:05 +0000 Received: from mail20-va3 (localhost [127.0.0.1]) by mail20-va3-R.bigfish.com (Postfix) with ESMTP id 77C4A240191; Thu, 26 Sep 2013 09:08:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(z21eIzbb2dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h20f7h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail20-va3 (localhost.localdomain [127.0.0.1]) by mail20-va3 (MessageSwitch) id 1380186483555194_26557; Thu, 26 Sep 2013 09:08:03 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.250]) by mail20-va3.bigfish.com (Postfix) with ESMTP id 8257D1E0065; Thu, 26 Sep 2013 09:08:03 +0000 (UTC) Received: from AMSPRD0711HT001.eurprd07.prod.outlook.com (157.56.250.181) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 26 Sep 2013 09:08:01 +0000 Received: from pc6 (86.135.129.38) by pod51017.outlook.com (10.242.14.162) with Microsoft SMTP Server (TLS) id 14.16.359.1; Thu, 26 Sep 2013 09:07:50 +0000 Message-ID: <021901ceba97$ac166560$4001a8c0@gateway.2wire.net> From: t.petch To: Susan Hares , idr wg References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> Date: Thu, 26 Sep 2013 10:06:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.135.129.38] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "'John G. Scudder'" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 09:08:48 -0000 The Type registry is defined to be 0 to 255 but the first allocated value is one. I suggest reserving zero and 255; no sound technical reason at present but it is common practice and good housekeeping. Also, most of the existing BGP registries are in fact sub-registries of Border Gateway Protocol (BGP) Parameters registry so suggest making this one one as well. Tom Petch ----- Original Message ----- From: "Susan Hares" To: "idr wg" Cc: "'John G. Scudder'" Sent: Saturday, September 14, 2013 12:12 AM Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) > This is to start at 2 week WG last call for > > > > The Accumulated IGP Metric Attribute for BGP > > draft-ietf-idr-aigp-10.txt > > > > http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ > > > > This last call will end 9/27/13 > > > > Three implementations exist: ALU, Cisco, Juniper. > > > > Vote early and speak often. > > > > Sue and John > > IDR co-chairs From randy@psg.com Thu Sep 26 10:48:14 2013 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 9A17121E80A7 for ; Thu, 26 Sep 2013 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHczPWS+O-tV for ; Thu, 26 Sep 2013 10:48:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 0354621E80A6 for ; Thu, 26 Sep 2013 10:48:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VPFfZ-0002io-1r; Thu, 26 Sep 2013 17:48:05 +0000 Date: Thu, 26 Sep 2013 07:48:04 -1000 Message-ID: From: Randy Bush To: t.petch In-Reply-To: <021901ceba97$ac166560$4001a8c0@gateway.2wire.net> References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> <021901ceba97$ac166560$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 17:48:14 -0000 > The Type registry is defined to be 0 to 255 but the first allocated > value is one. I suggest reserving zero and 255; no sound technical > reason at present but it is common practice and good housekeeping. i think we should reserve 42 as well :) don't needlessly manufacture more magic numbers. we have waaaaay to many of them already. randy From ilya@nobulus.com Thu Sep 26 14:27:51 2013 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 76ECA21F9B86 for ; Thu, 26 Sep 2013 14:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9yoccPh0e6A for ; Thu, 26 Sep 2013 14:27:50 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAF821E8088 for ; Thu, 26 Sep 2013 14:27:48 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id BC94D1765E; Thu, 26 Sep 2013 23:27:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YJZ++3RLOCz3; Thu, 26 Sep 2013 23:27:44 +0200 (CEST) Received: from [31.68.192.227] (unknown [31.68.192.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 2C10A173CB; Thu, 26 Sep 2013 23:27:42 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_027E1977-7127-47C8-B5BE-7D5B6F9AE56B" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ilya Varlashkin In-Reply-To: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> Date: Thu, 26 Sep 2013 22:26:16 +0100 Message-Id: <50CC9CD0-01C9-4C9A-A6EF-7C8838746AC8@nobulus.com> References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> To: idr wg X-Mailer: Apple Mail (2.1508) Cc: Susan Hares , "John G. Scudder" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 21:27:51 -0000 --Apple-Mail=_027E1977-7127-47C8-B5BE-7D5B6F9AE56B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I didn't plan originally to post following text but it was suggested to = me that the real-world scenario that I've encountered might be worth = mentioning before WGLC for AIGP concludes. Please consider this only as = "info", and neither "for" nor "against" current edition of AIGP draft. Several weeks ago I've started looking into various methods to employ = while re-organising a BGP confederation. The network involves set of = disjoint IGP domains, hence no end-to-end path-cost visibility. (BGP) = Best-path selection for global table in this environment often boils = down to "lowest IGP-cost exit" (and they can be 5-50ms apart). When = exits are in different IGP domains I thought AIGP could be used, but = turned out AIGP was not made for this kind of use case. Currently AIGP = is designed to be absolute decision maker. Although the draft does say = that a router calculates AIGP+IGP cost, it stops short of using result = in place where rfc4271 BGP would use IGP cost.=20 To give an example, if I have an external prefix NetA coming via ASBR1 = in AS1 and ASBR2 in AS2 (both AS1 and AS2 are members of the same BGP = confederation, each AS has its own IGP). I'd like to prefer shortest = AS_PATH, and if all are of equal length then take nearest exit. Suppose = I was to use AIGP, the resulting best path would be what I'd like only = if AS_PATH via ASBR1 and ASBR2 are of equal length. If AS_PATH via ASBR2 = is shorter than via ASBR1, but ASBR1 is closer to me then AIGP would = force traffic to exit via ASBR1 anyway, though I'd want it to go via = ASBR2 in this case. In order to achieve desired behaviour the AIGP draft = would need to be modified so that AIGP+IGP cost would be considered not = as foremost tie-breaker, but where IGP cost is currently used in BGP = tie-breaking rules. The above described modification is of course different from what the = draft says now, and won't serve people who use it now. However, it looks = like the modification is rather simple and could be turned on and off by = a configuration knob so AIGP could work in both current scenario = (multiple real AS's under common administration) and in case of BGP = confederation (as described above). This switch would simply move order = where AIGP+IGP is used (somewhat similar to how this is done with cost = community). Is the above something that IDR should consider for amending the draft? Kind regards, iLya On Sep 14, 2013, at 12:12 AM, Susan Hares wrote: > This is to start at 2 week WG last call for > =20 > The Accumulated IGP Metric Attribute for BGP > draft-ietf-idr-aigp-10.txt > =20 > http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ > =20 > This last call will end 9/27/13 > =20 > Three implementations exist: ALU, Cisco, Juniper. > =20 > Vote early and speak often. > =20 > Sue and John > IDR co-chairs > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_027E1977-7127-47C8-B5BE-7D5B6F9AE56B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

I didn't plan originally to post following text = but it was suggested to me that the real-world scenario that I've = encountered might be worth mentioning before WGLC for AIGP concludes. = Please consider this only as "info", and neither "for" nor "against" = current edition of AIGP draft.

Several weeks = ago I've started looking into various methods to employ while = re-organising a BGP confederation. The network involves set of disjoint = IGP domains, hence no end-to-end path-cost visibility. (BGP) Best-path = selection for global table in this environment often boils down to = "lowest IGP-cost exit" (and they can be 5-50ms apart). When exits are in = different IGP domains I thought AIGP could be used, but turned out AIGP = was not made for this kind of use case. Currently AIGP is designed to be = absolute decision maker. Although the draft does say that a router = calculates AIGP+IGP cost, it stops short of using result in place where = rfc4271 BGP would use IGP cost. 

To give = an example, if I have an external prefix NetA coming via ASBR1 in AS1 = and ASBR2 in AS2 (both AS1 and AS2 are members of the same BGP = confederation, each AS has its own IGP). I'd like to prefer shortest = AS_PATH, and if all are of equal length then take nearest exit. Suppose = I  was to use AIGP, the resulting best path would be what I'd like = only if AS_PATH via ASBR1 and ASBR2 are of equal length. If AS_PATH via = ASBR2 is shorter than via ASBR1, but ASBR1 is closer to me then AIGP = would force traffic to exit via ASBR1 anyway, though I'd want it to go = via ASBR2 in this case. In order to achieve desired behaviour the AIGP = draft would need to be modified so that AIGP+IGP cost would be = considered not as foremost tie-breaker, but where IGP cost is currently = used in BGP tie-breaking rules.

The above = described modification is of course different from what the draft says = now, and won't serve people who use it now. However, it looks like the = modification is rather simple and could be turned on and off by a = configuration knob so AIGP could work in both current scenario (multiple = real AS's under common administration) and in case of BGP confederation = (as described above). This switch would simply move order where AIGP+IGP = is used (somewhat similar to how this is done with cost = community).

Is the above something that IDR = should consider for amending the draft?

Kind = regards,
iLya


On Sep = 14, 2013, at 12:12 AM, Susan Hares <shares@ndzh.com> wrote:

This = is to start at 2 week WG last call for

 

The = Accumulated IGP Metric Attribute for BGP

draft-ietf-idr-aigp-10.txt

 

http://datat= racker.ietf.org/doc/draft-ietf-idr-aigp/

 

This = last call will end 9/27/13

 

Three = implementations exist: ALU, Cisco, Juniper.

 

Vote = early and speak often.

 

Sue and = John

IDR co-chairs =

 

_____________________= __________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mail= man/listinfo/idr

= --Apple-Mail=_027E1977-7127-47C8-B5BE-7D5B6F9AE56B-- From ju1738@att.com Thu Sep 26 15:32:28 2013 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 2507321E80C5 for ; Thu, 26 Sep 2013 15:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmkYDvE5-X6S for ; Thu, 26 Sep 2013 15:32:22 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 91EA021F9F5B for ; Thu, 26 Sep 2013 15:32:21 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 5f5b4425.6a566940.9540926.00-524.26277594.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 26 Sep 2013 22:32:21 +0000 (UTC) X-MXL-Hash: 5244b5f5218d4e57-c604ef750deaf4c7cfd04322c6a9ff84ec6cac37 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 3f5b4425.0.9540917.00-251.26277552.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 26 Sep 2013 22:32:20 +0000 (UTC) X-MXL-Hash: 5244b5f474b46525-e203903db7860b7b6705fa9d219bd4f9b942781b Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8QMWILt021985; Thu, 26 Sep 2013 18:32:19 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8QMW5VL021879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 18:32:08 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 26 Sep 2013 22:31:52 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0158.001; Thu, 26 Sep 2013 18:31:52 -0400 From: "UTTARO, JAMES" To: Ilya Varlashkin , idr wg Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOuv8IoZDNOu+SQiq0dAmRJ9YB/pnYmCRw Date: Thu, 26 Sep 2013 22:31:52 +0000 Message-ID: References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> <50CC9CD0-01C9-4C9A-A6EF-7C8838746AC8@nobulus.com> In-Reply-To: <50CC9CD0-01C9-4C9A-A6EF-7C8838746AC8@nobulus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.26.210] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F062D6B05MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=5i5E06EXLX0A:10 a=5Ay4ljVScIYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=16pnZUWWB] X-AnalysisOut: [cIA:10 a=48vgC7mUAAAA:8 a=1sjgXBK7AAAA:8 a=ZIfVhb814-Tlvif] X-AnalysisOut: [A30AA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=kZwP4KTQBigA] X-AnalysisOut: [:10 a=HR9ZA4GD38cTImKY:21 a=Yk6fxuSX9VklPy0_:21 a=yMhMjlub] X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=LMD7GWM2LCqplWsjhfcA:9 a=gKO2Hq4] X-AnalysisOut: [RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hU] X-AnalysisOut: [A:10 a=JYyC4TkM0xGD39Uj:21 a=kLBsB93nAFT3f9YS:21 a=tzNHi2O] X-AnalysisOut: [yxA_nMBhg:21] Cc: "John G. Scudder" , Susan Hares Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 22:32:28 -0000 --_000_B17A6910EEDD1F45980687268941550F062D6B05MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ilya, Comments In-Line.. Jim Uttaro From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Ilya = Varlashkin Sent: Thursday, September 26, 2013 5:26 PM To: idr wg Cc: Susan Hares; John G. Scudder Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Hi all, I didn't plan originally to post following text but it was suggested to me = that the real-world scenario that I've encountered might be worth mentionin= g before WGLC for AIGP concludes. Please consider this only as "info", and = neither "for" nor "against" current edition of AIGP draft. Several weeks ago I've started looking into various methods to employ while= re-organising a BGP confederation. The network involves set of disjoint IG= P domains, hence no end-to-end path-cost visibility. (BGP) Best-path select= ion for global table in this environment often boils down to "lowest IGP-co= st exit" (and they can be 5-50ms apart). When exits are in different IGP do= mains I thought AIGP could be used, but turned out AIGP was not made for th= is kind of use case. Currently AIGP is designed to be absolute decision mak= er. Although the draft does say that a router calculates AIGP+IGP cost, it = stops short of using result in place where rfc4271 BGP would use IGP cost. To give an example, if I have an external prefix NetA coming via ASBR1 in A= S1 and ASBR2 in AS2 (both AS1 and AS2 are members of the same BGP confedera= tion, each AS has its own IGP). I'd like to prefer shortest AS_PATH, and if= all are of equal length then take nearest exit. Suppose I was to use AIGP= , the resulting best path would be what I'd like only if AS_PATH via ASBR1 = and ASBR2 are of equal length. If AS_PATH via ASBR2 is shorter than via ASB= R1, but ASBR1 is closer to me then AIGP would force traffic to exit via ASB= R1 anyway, though I'd want it to go via ASBR2 in this case. In order to ach= ieve desired behaviour the AIGP draft would need to be modified so that AIG= P+IGP cost would be considered not as foremost tie-breaker, but where IGP c= ost is currently used in BGP tie-breaking rules. [Jim U>] This behavior is why AIGP is not at the POI of IGP but above AS_PA= TH, An ex, assuming a global network comprised of 3 AS domains correspondin= g to US, EMEA and AP connecting in a triangle .. Further assume that India = is in AP.. For traffic destined from NY to India the current decision makin= g would select the shorter AS-PATH which would force traffic to traverse fr= om NY( US) ->AP (India). The desired path is NY->EMEA->AP ( India ) which i= s the shorter latency.. The above described modification is of course different from what the draft= says now, and won't serve people who use it now. However, it looks like th= e modification is rather simple and could be turned on and off by a configu= ration knob so AIGP could work in both current scenario (multiple real AS's= under common administration) and in case of BGP confederation (as describe= d above). This switch would simply move order where AIGP+IGP is used (somew= hat similar to how this is done with cost community). [Jim U>] So that would be a POI knob ? Is the above something that IDR should consider for amending the draft? Kind regards, iLya On Sep 14, 2013, at 12:12 AM, Susan Hares > wrote: This is to start at 2 week WG last call for The Accumulated IGP Metric Attribute for BGP draft-ietf-idr-aigp-10.txt http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ This last call will end 9/27/13 Three implementations exist: ALU, Cisco, Juniper. Vote early and speak often. Sue and John IDR co-chairs _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_B17A6910EEDD1F45980687268941550F062D6B05MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ilya,

 

   &nbs= p;            Commen= ts In-Line..

 

Jim Uttaro<= /span>

 

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Ilya Varlashkin
Sent: Thursday, September 26, 2013 5:26 PM
To: idr wg
Cc: Susan Hares; John G. Scudder
Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9= /27/13)

 

Hi all,

 

I didn't plan originally to post following text but = it was suggested to me that the real-world scenario that I've encountered m= ight be worth mentioning before WGLC for AIGP concludes. Please consider th= is only as "info", and neither "for" nor "against" current edition of AIGP draft.

 

Several weeks ago I've started looking into various = methods to employ while re-organising a BGP confederation. The network invo= lves set of disjoint IGP domains, hence no end-to-end path-cost visibility.= (BGP) Best-path selection for global table in this environment often boils down to "lowest IGP-cost exit&q= uot; (and they can be 5-50ms apart). When exits are in different IGP domain= s I thought AIGP could be used, but turned out AIGP was not made for this k= ind of use case. Currently AIGP is designed to be absolute decision maker. Although the draft does say that a router c= alculates AIGP+IGP cost, it stops short of using result in place where = rfc4271 BGP would use IGP cost. 

 

To give an example, if I have an external prefix Net= A coming via ASBR1 in AS1 and ASBR2 in AS2 (both AS1 and AS2 are members of= the same BGP confederation, each AS has its own IGP). I'd like to prefer s= hortest AS_PATH, and if all are of equal length then take nearest exit. Suppose I  was to use AIGP, the = resulting best path would be what I'd like only if AS_PATH via ASBR1 and AS= BR2 are of equal length. If AS_PATH via ASBR2 is shorter than via ASBR1, bu= t ASBR1 is closer to me then AIGP would force traffic to exit via ASBR1 anyway, though I'd want it to go via ASBR2= in this case. In order to achieve desired behaviour the AIGP draft would n= eed to be modified so that AIGP+IGP cost would be considered not as for= emost tie-breaker, but where IGP cost is currently used in BGP tie-breaking rules.

[Jim U>] This= behavior is why AIGP is not at the POI of IGP but above AS_PATH, An ex, as= suming a global network comprised of 3 AS domains corresponding to US, EMEA= and AP connecting in a triangle .. Further assume that India is in AP.. For traffic destined from NY to India the cur= rent decision making would select the shorter AS-PATH which would force tra= ffic to traverse from NY( US) ->AP (India). The desired path is NY->E= MEA->AP ( India ) which is the shorter latency.. <= /p>

 

The above described modification is of course differ= ent from what the draft says now, and won't serve people who use it now. Ho= wever, it looks like the modification is rather simple and could be turned = on and off by a configuration knob so AIGP could work in both current scenario (multiple real AS's under comm= on administration) and in case of BGP confederation (as described above). T= his switch would simply move order where AIGP+IGP is used (somewhat sim= ilar to how this is done with cost community).

[Jim U>] So t= hat would be a POI knob ?=

 

Is the above something that IDR should consider for = amending the draft?

 

Kind regards,

iLya

 

 

On Sep 14, 2013, at 12:12 AM, Susan Hares <shares@ndzh.com> wrote:



This is to start at 2 week WG last call for

 

The Accumulated IGP Metric At= tribute for BGP

draft-ietf-idr-aigp-10.txt

 

http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/<= /o:p>

 

This last call will end 9/27/13

 

Three implementations exist: ALU, Cisco, Juniper.

 

Vote early and speak often.

 

Sue and John

IDR co-chairs

 

____________________________________= ___________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/= mailman/listinfo/idr

 

--_000_B17A6910EEDD1F45980687268941550F062D6B05MISOUT7MSGUSR9I_-- From ilya@nobulus.com Thu Sep 26 16:21:58 2013 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 BE4E921E80C3 for ; Thu, 26 Sep 2013 16:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BEFORE=1.272, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCfqh0Isxmjo for ; Thu, 26 Sep 2013 16:21:54 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id A2A7811E80F2 for ; Thu, 26 Sep 2013 16:21:46 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 0B41F1752F; Fri, 27 Sep 2013 01:21:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bQ14X7wJzcAD; Fri, 27 Sep 2013 01:21:42 +0200 (CEST) Received: from [31.69.69.204] (unknown [31.69.69.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 00D5A171BC; Fri, 27 Sep 2013 01:21:41 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_CF52A2EA-949E-4109-9D13-E54F212580B9" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ilya Varlashkin In-Reply-To: Date: Fri, 27 Sep 2013 00:21:37 +0100 Message-Id: <6C0F50DC-E4EC-433A-9C30-4EC5CAFE75B8@nobulus.com> References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> <50CC9CD0-01C9-4C9A-A6EF-7C8838746AC8@nobulus.com> To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1508) Cc: idr wg , "John G. Scudder" , Susan Hares Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 23:21:58 -0000 --Apple-Mail=_CF52A2EA-949E-4109-9D13-E54F212580B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > [Jim U>] This behavior is why AIGP is not at the POI of IGP but above = AS_PATH, An ex, assuming a global network comprised of 3 AS domains = corresponding to US, EMEA and AP connecting in a triangle .. Further = assume that India is in AP.. For traffic destined from NY to India the = current decision making would select the shorter AS-PATH which would = force traffic to traverse from NY( US) ->AP (India). The desired path is = NY->EMEA->AP ( India ) which is the shorter latency.. I fully understand and don't dispute your use case. So the current AIGP = specification should not be removed. What I'm proposing is an amendment, = to cater to more use cases. Though also notice that in your case AIGP = works only for networks directly connected to you or for which you have = devised latency/proximity from external sources, not for a random prefix = you receive from "blackbox peers". > =20 > The above described modification is of course different from what the = draft says now, and won't serve people who use it now. However, it looks = like the modification is rather simple and could be turned on and off by = a configuration knob so AIGP could work in both current scenario = (multiple real AS's under common administration) and in case of BGP = confederation (as described above). This switch would simply move order = where AIGP+IGP is used (somewhat similar to how this is done with cost = community). > [Jim U>] So that would be a POI knob ? in a simplistic form - yes, locally-significant (but consistently = configured within your administrative domain) POI knob. This would allow = AIGP to work _either_ for your (real AS's) case or mine (BGP confed), = but not for both at the same time. Now after reviewing AIGP attribute format, I see there's potentially = room for more flexible solution. We could leave Type=3D1 AIGP TLV to be = fore "real AS's case" (what you have described, exactly what current = implementations do), then we can add Type=3D2 AIGP TLV for "BGP = confederations" that will have exactly same originating and propagating = rules as current Type 1, but will have POI just before IGP cost. /iLya= --Apple-Mail=_CF52A2EA-949E-4109-9D13-E54F212580B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
[Jim U>] This = behavior is why AIGP is not at the POI of IGP but above AS_PATH, An ex, = assuming a global network comprised of 3 AS domains corresponding to US, = EMEA and AP connecting in a triangle .. Further assume that India is in = AP.. For traffic destined from NY to India the current decision making = would select the shorter AS-PATH which would force traffic to traverse = from NY( US) ->AP (India). The desired path is NY->EMEA->AP ( = India ) which is the shorter latency..

 
The above described modification is of course = different from what the draft says now, and won't serve people who use = it now. However, it looks like the modification is rather simple and = could be turned on and off by a configuration knob so AIGP could work in = both current scenario (multiple real AS's under common administration) = and in case of BGP confederation (as described above). This switch would = simply move order where AIGP+IGP is used (somewhat similar to how this = is done with cost community).
[Jim U>] So that = would be a POI knob = ?

in a = simplistic form - yes, locally-significant (but consistently configured = within your administrative domain) POI knob. This would allow AIGP to = work _either_ for your (real AS's) case or mine (BGP confed), but not = for both at the same time.

Now after reviewing = AIGP attribute format, I see there's potentially room for more flexible = solution. We could leave Type=3D1 AIGP TLV to be fore "real AS's case" = (what you have described, exactly what current implementations do), then = we can add Type=3D2 AIGP TLV for "BGP confederations" that will have = exactly same originating and propagating rules as current Type 1, but = will have POI just before IGP = cost.

/iLya
= --Apple-Mail=_CF52A2EA-949E-4109-9D13-E54F212580B9-- From ju1738@att.com Thu Sep 26 17:28:39 2013 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 1404911E8118 for ; Thu, 26 Sep 2013 17:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.587 X-Spam-Level: X-Spam-Status: No, score=-5.587 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, FRT_BEFORE=1.272, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSZ8Gron8zAF for ; Thu, 26 Sep 2013 17:28:32 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id E198E11E80ED for ; Thu, 26 Sep 2013 17:28:31 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id f21d4425.7c783940.9591745.00-526.26414710.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 27 Sep 2013 00:28:31 +0000 (UTC) X-MXL-Hash: 5244d12f3a9ee958-38874ac9bb37cbfc586a634e6426c59da6cedc16 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id b21d4425.0.9591721.00-310.26414649.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 27 Sep 2013 00:28:31 +0000 (UTC) X-MXL-Hash: 5244d12f431b1cc3-d196a19d490501b977ae77b1c4f163e5baf70a68 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8R0SQwF008591; Thu, 26 Sep 2013 20:28:26 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8R0S9lp008484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 20:28:11 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 27 Sep 2013 00:27:53 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.03.0158.001; Thu, 26 Sep 2013 20:27:53 -0400 From: "UTTARO, JAMES" To: Ilya Varlashkin Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOuv8IoZDNOu+SQiq0dAmRJ9YB/pnYmCRwgABTN4D//86NIA== Date: Fri, 27 Sep 2013 00:27:53 +0000 Message-ID: References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> <50CC9CD0-01C9-4C9A-A6EF-7C8838746AC8@nobulus.com> <6C0F50DC-E4EC-433A-9C30-4EC5CAFE75B8@nobulus.com> In-Reply-To: <6C0F50DC-E4EC-433A-9C30-4EC5CAFE75B8@nobulus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.26.210] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F062D6B2CMISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=5i5E06EXLX0A:10 a=5Ay4ljVScIYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=16pnZUWWB] X-AnalysisOut: [cIA:10 a=iJs141qlAAAA:8 a=Q5FOzTD_dgf1ON0E-h4A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=_JJl2SXyuhsA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA] X-AnalysisOut: [:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a] X-AnalysisOut: [=frz4AuCg-hUA:10 a=ycUbjYhuPD9EzMM7:21] Cc: idr wg , "John G. Scudder" , Susan Hares Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) 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, 27 Sep 2013 00:28:39 -0000 --_000_B17A6910EEDD1F45980687268941550F062D6B2CMISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments In-Line Jim Uttaro From: Ilya Varlashkin [mailto:ilya@nobulus.com] Sent: Thursday, September 26, 2013 7:22 PM To: UTTARO, JAMES Cc: idr wg; Susan Hares; John G. Scudder Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) [Jim U>] This behavior is why AIGP is not at the POI of IGP but above AS_PA= TH, An ex, assuming a global network comprised of 3 AS domains correspondin= g to US, EMEA and AP connecting in a triangle .. Further assume that India = is in AP.. For traffic destined from NY to India the current decision makin= g would select the shorter AS-PATH which would force traffic to traverse fr= om NY( US) ->AP (India). The desired path is NY->EMEA->AP ( India ) which i= s the shorter latency.. I fully understand and don't dispute your use case. So the current AIGP spe= cification should not be removed. What I'm proposing is an amendment, to ca= ter to more use cases. Though also notice that in your case AIGP works only= for networks directly connected to you or for which you have devised laten= cy/proximity from external sources, not for a random prefix you receive fro= m "blackbox peers". [Jim U>] This was designed for a group of domains under a single admin doma= in.. Extending to "blackbox peers" where the underlying metric may not be t= he same will yield unpredictable results and is not recommended.. The above described modification is of course different from what the draft= says now, and won't serve people who use it now. However, it looks like th= e modification is rather simple and could be turned on and off by a configu= ration knob so AIGP could work in both current scenario (multiple real AS's= under common administration) and in case of BGP confederation (as describe= d above). This switch would simply move order where AIGP+IGP is used (somew= hat similar to how this is done with cost community). [Jim U>] So that would be a POI knob ? in a simplistic form - yes, locally-significant (but consistently configure= d within your administrative domain) POI knob. This would allow AIGP to wor= k _either_ for your (real AS's) case or mine (BGP confed), but not for both= at the same time. Now after reviewing AIGP attribute format, I see there's potentially room f= or more flexible solution. We could leave Type=3D1 AIGP TLV to be fore "rea= l AS's case" (what you have described, exactly what current implementations= do), then we can add Type=3D2 AIGP TLV for "BGP confederations" that will = have exactly same originating and propagating rules as current Type 1, but = will have POI just before IGP cost. [Jim U>] The addl TLVs were put there for future use.. I had thought there = may be other metric types i.e availability, robustness, reliability.. I see= no reason why your use case could not advantage these TLVs.. /iLya --_000_B17A6910EEDD1F45980687268941550F062D6B2CMISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments In-Line

 <= /p>

    &= nbsp;           Jim Uttar= o

 <= /p>

From: Ilya Var= lashkin [mailto:ilya@nobulus.com]
Sent: Thursday, September 26, 2013 7:22 PM
To: UTTARO, JAMES
Cc: idr wg; Susan Hares; John G. Scudder
Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9= /27/13)

 

[Jim U>] This be= havior is why AIGP is not at the POI of IGP but above AS_PATH, An ex, assum= ing a global network comprised of 3 AS domains corresponding to US, EMEA and AP connecting in a triangle .. Further assume that India i= s in AP.. For traffic destined from NY to India the current decision making= would select the shorter AS-PATH which would force traffic to traverse fro= m NY( US) ->AP (India). The desired path is NY->EMEA->AP ( India ) which is the shorter latency..=

 

I fully understand and don't dispute your use case. = So the current AIGP specification should not be removed. What I'm proposing= is an amendment, to cater to more use cases. Though also notice that in yo= ur case AIGP works only for networks directly connected to you or for which you have devised latency/proximity = from external sources, not for a random prefix you receive from "black= box peers".

[Jim U>] This wa= s designed for a group of domains under a single admin domain.. Extending t= o “blackbox peers” where the underlying metric may not be the same will yield unpredictable results and is not recommended..<= /b>



 

The above described modification is of = course different from what the draft says now, and won't serve people who u= se it now. However, it looks like the modification is rather simple and could be turned on and off by a configuration knob so AIGP coul= d work in both current scenario (multiple real AS's under common administra= tion) and in case of BGP confederation (as described above). This switch wo= uld simply move order where AIGP+IGP is used (somewhat similar to how this is done with cost community).

[Jim U>] So that= would be a POI knob ?

 

in a simplistic form - yes, locally-significant (but= consistently configured within your administrative domain) POI knob. This = would allow AIGP to work _either_ for your (real AS's) case or mine (BGP co= nfed), but not for both at the same time.

 

Now after reviewing AIGP attribute format, I see the= re's potentially room for more flexible solution. We could leave Type=3D1 A= IGP TLV to be fore "real AS's case" (what you have described, exa= ctly what current implementations do), then we can add Type=3D2 AIGP TLV for "BGP confederations" that will hav= e exactly same originating and propagating rules as current Type 1, but wil= l have POI just before IGP cost.

[Jim U>] The add= l TLVs were put there for future use.. I had thought there may be other met= ric types i.e availability, robustness, reliability.. I see no reason why your use case could not advantage these TLVs..

 

/iLya

--_000_B17A6910EEDD1F45980687268941550F062D6B2CMISOUT7MSGUSR9I_-- From rajiva@cisco.com Thu Sep 26 18:46:18 2013 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 4939D21E80DF for ; Thu, 26 Sep 2013 18:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.363 X-Spam-Level: X-Spam-Status: No, score=-9.363 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, FRT_BEFORE=1.272, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnoFEKSHPoe3 for ; Thu, 26 Sep 2013 18:46:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 47FD621E80D4 for ; Thu, 26 Sep 2013 18:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12276; q=dns/txt; s=iport; t=1380246373; x=1381455973; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=12d9BTKdHhJRSX+XxbL4zy4DGQXsO46iFEiias0h/cA=; b=idCrhx7PuiEU9wgE6sn5A/NhzXpM23A+5gRQ2FV6apUXS9qrXf8aHOYG Iqvw43ydxzDHRybGEu9r6PJcNBUv9QnWOgtYbOPHflSy2falrsn5oWlFm IG2UW3cVKEiCbEmLCnNrqgwhzPZ6MO8CVIWjDdSa4lQL4antH8QrjCrHK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAO3iRFKtJV2Z/2dsb2JhbABbgkNEOMEdgRsWdIIlAQEBBAEBARoKBkELEAIBCBEEAQEoBycLFAkIAgQOBRQHh2sMu18EjhOBOgQGAYMdgQEDlCCDXZF4gySBaAEEGw X-IronPort-AV: E=Sophos;i="4.90,989,1371081600"; d="scan'208,217";a="265063615" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 27 Sep 2013 01:46:12 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8R1kCM3002896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 01:46:12 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 20:46:12 -0500 From: "Rajiv Asati (rajiva)" To: "UTTARO, JAMES" Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOuv8IoZDNOu+SQiq0dAmRJ9YB/pnYmCRwgABj+oCAABKEgP//wg+i Date: Fri, 27 Sep 2013 01:46:11 +0000 Message-ID: <280031DA-CDCA-4E96-B530-09724C38A8C3@cisco.com> References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> <50CC9CD0-01C9-4C9A-A6EF-7C8838746AC8@nobulus.com> <6C0F50DC-E4EC-433A-9C30-4EC5CAFE75B8@nobulus.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_280031DACDCA4E96B53009724C38A8C3ciscocom_" MIME-Version: 1.0 Cc: idr wg , "John G. Scudder" , Susan Hares Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) 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, 27 Sep 2013 01:46:18 -0000 --_000_280031DACDCA4E96B53009724C38A8C3ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ilya, your use-case seems quite valid and I like your proposal to define a= new type to address it. This is a cleaner / better approach than having to= put the POI change everywhere. We should not limit it to confed though. Cheers, Rajiv Sent from my Phone On Sep 26, 2013, at 8:29 PM, "UTTARO, JAMES" > wrote: Comments In-Line Jim Uttaro From: Ilya Varlashkin [mailto:ilya@nobulus.com] Sent: Thursday, September 26, 2013 7:22 PM To: UTTARO, JAMES Cc: idr wg; Susan Hares; John G. Scudder Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) [Jim U>] This behavior is why AIGP is not at the POI of IGP but above AS_PA= TH, An ex, assuming a global network comprised of 3 AS domains correspondin= g to US, EMEA and AP connecting in a triangle .. Further assume that India = is in AP.. For traffic destined from NY to India the current decision makin= g would select the shorter AS-PATH which would force traffic to traverse fr= om NY( US) ->AP (India). The desired path is NY->EMEA->AP ( India ) which i= s the shorter latency.. I fully understand and don't dispute your use case. So the current AIGP spe= cification should not be removed. What I'm proposing is an amendment, to ca= ter to more use cases. Though also notice that in your case AIGP works only= for networks directly connected to you or for which you have devised laten= cy/proximity from external sources, not for a random prefix you receive fro= m "blackbox peers". [Jim U>] This was designed for a group of domains under a single admin doma= in.. Extending to =93blackbox peers=94 where the underlying metric may not = be the same will yield unpredictable results and is not recommended.. The above described modification is of course different from what the draft= says now, and won't serve people who use it now. However, it looks like th= e modification is rather simple and could be turned on and off by a configu= ration knob so AIGP could work in both current scenario (multiple real AS's= under common administration) and in case of BGP confederation (as describe= d above). This switch would simply move order where AIGP+IGP is used (somew= hat similar to how this is done with cost community). [Jim U>] So that would be a POI knob ? in a simplistic form - yes, locally-significant (but consistently configure= d within your administrative domain) POI knob. This would allow AIGP to wor= k _either_ for your (real AS's) case or mine (BGP confed), but not for both= at the same time. Now after reviewing AIGP attribute format, I see there's potentially room f= or more flexible solution. We could leave Type=3D1 AIGP TLV to be fore "rea= l AS's case" (what you have described, exactly what current implementations= do), then we can add Type=3D2 AIGP TLV for "BGP confederations" that will = have exactly same originating and propagating rules as current Type 1, but = will have POI just before IGP cost. [Jim U>] The addl TLVs were put there for future use.. I had thought there = may be other metric types i.e availability, robustness, reliability.. I see= no reason why your use case could not advantage these TLVs.. /iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_280031DACDCA4E96B53009724C38A8C3ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Ilya, your use-case seems quite valid  and I like your proposal t= o define a new type to address it. This is a cleaner / better approach than= having to put the POI change everywhere. 

We should not limit it to confed though. 

Cheers,
Rajiv

Sent from my Phone

On Sep 26, 2013, at 8:29 PM, "UTTARO, JAMES" <ju1738@att.com> wrote:

Comments In-Line

 <= /p>

    &= nbsp;           Jim Uttar= o

 <= /p>

From: Ilya Var= lashkin [mailto:ilya@nobulus.com]
Sent: Thursday, September 26, 2013 7:22 PM
To: UTTARO, JAMES
Cc: idr wg; Susan Hares; John G. Scudder
Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9= /27/13)

 

[Jim U>] This be= havior is why AIGP is not at the POI of IGP but above AS_PATH, An ex, assum= ing a global network comprised of 3 AS domains corresponding to US, EMEA and AP connecting in a triangle .. Further assume that India i= s in AP.. For traffic destined from NY to India the current decision making= would select the shorter AS-PATH which would force traffic to traverse fro= m NY( US) ->AP (India). The desired path is NY->EMEA->AP ( India ) which is the shorter latency..=

 

I fully understand and don't dispute your use case. = So the current AIGP specification should not be removed. What I'm proposing= is an amendment, to cater to more use cases. Though also notice that in yo= ur case AIGP works only for networks directly connected to you or for which you have devised latency/proximity = from external sources, not for a random prefix you receive from "black= box peers".

[Jim U>] This wa= s designed for a group of domains under a single admin domain.. Extending t= o =93blackbox peers=94 where the underlying metric may not be the same will yield unpredictable results and is not recommended..<= /b>



 

The above described modification is of = course different from what the draft says now, and won't serve people who u= se it now. However, it looks like the modification is rather simple and could be turned on and off by a configuration knob so AIGP coul= d work in both current scenario (multiple real AS's under common administra= tion) and in case of BGP confederation (as described above). This switch wo= uld simply move order where AIGP+IGP is used (somewhat similar to how this is done with cost community).

[Jim U>] So that= would be a POI knob ?

 

in a simplistic form - yes, locally-significant (but= consistently configured within your administrative domain) POI knob. This = would allow AIGP to work _either_ for your (real AS's) case or mine (BGP co= nfed), but not for both at the same time.

 

Now after reviewing AIGP attribute format, I see the= re's potentially room for more flexible solution. We could leave Type=3D1 A= IGP TLV to be fore "real AS's case" (what you have described, exa= ctly what current implementations do), then we can add Type=3D2 AIGP TLV for "BGP confederations" that will hav= e exactly same originating and propagating rules as current Type 1, but wil= l have POI just before IGP cost.

[Jim U>] The add= l TLVs were put there for future use.. I had thought there may be other met= ric types i.e availability, robustness, reliability.. I see no reason why your use case could not advantage these TLVs..

 

/iLya

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_280031DACDCA4E96B53009724C38A8C3ciscocom_-- From ietfc@btconnect.com Fri Sep 27 01:02:31 2013 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 9EF1221E80DA for ; Fri, 27 Sep 2013 01:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.233 X-Spam-Level: X-Spam-Status: No, score=-3.233 tagged_above=-999 required=5 tests=[AWL=3.366, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZwSi8s9-9yp for ; Fri, 27 Sep 2013 01:02:25 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4B87121F92B2 for ; Fri, 27 Sep 2013 01:02:25 -0700 (PDT) Received: from mail71-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Fri, 27 Sep 2013 08:02:24 +0000 Received: from mail71-tx2 (localhost [127.0.0.1]) by mail71-tx2-R.bigfish.com (Postfix) with ESMTP id 987A1360277; Fri, 27 Sep 2013 08:02:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(z21eIz9371I542I1432I1418Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h20f7h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h8275bh8275dhz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail71-tx2 (localhost.localdomain [127.0.0.1]) by mail71-tx2 (MessageSwitch) id 1380268914758551_4281; Fri, 27 Sep 2013 08:01:54 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.240]) by mail71-tx2.bigfish.com (Postfix) with ESMTP id AA1C5E011C; Fri, 27 Sep 2013 08:01:54 +0000 (UTC) Received: from AMSPRD0710HT005.eurprd07.prod.outlook.com (157.56.249.85) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 27 Sep 2013 08:01:54 +0000 Received: from AMXPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.160.168) with Microsoft SMTP Server (TLS) id 14.16.359.1; Fri, 27 Sep 2013 08:01:24 +0000 Message-ID: <003201cebb57$8d7ab0a0$4001a8c0@gateway.2wire.net> From: t.petch To: , References: <13083.1380121240@erosen-linux> Date: Fri, 27 Sep 2013 08:55:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: idr wg Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) 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, 27 Sep 2013 08:02:31 -0000 ----- Original Message ----- From: "Eric Rosen" To: Cc: "idr wg" ; ; Sent: Wednesday, September 25, 2013 4:00 PM > > Eric> After five years and at least three implementations, there would need > Eric> to be a very strong technical justification for changing the encoding. > > Bruno> I agree with you. However, to clarify, that was neither my question > Bruno> (is there any reason for preferring one option or the other) nor my > Bruno> point (for my information; for future documents/usages). To come > Bruno> back to my question, I guess your answer is "no". > > There is no particular reason why the draft specifies one TLV encoding > rather than another, and I'm not aware of any document recommending a > particular encoding technique. Sigh. One problem, two solutions, an increase in the likelihood of coding errors:-( I think that other SDOs got it right. The manufacturer I worked for had a simple rule, TLV was always the length of the value field whereas LDV always included the length of the header as well. A simple rule, so deeply engrained that I would probably make a coding error whenever TLV is not defined in that way. But, if this protoocol has been the 'wrong' way for five years, it is probably best left alone. Tom Petch > > in case of error, you withdraw the route -which is usually used- while you > > could only withdraw the attribute -which apparently is not required (to be > > consistent within the AS) > > I can't say that I have strong feelings about this one way or the other. > > > Bruno> Shouldn't [BESTEXT] and [ADDPATH] be normative references? > > I don't think so, as they are not strictly required in order to implement > AIGP. > > Bruno> Usually the name [ADDPATH] refers to "draft-ietf-idr-add-paths" and > Bruno> not to "draft-pmohapat-idr-fast-conn-restore" > > I will change the reference name. > > draft> [The AIGP attribute] "may be added only to routes that satisfy one of > draft> the following conditions: [...] The route is an EBGP-learned route > draft> whose AS_PATH contains only ASes that are in the same AIGP > draft> Administrative Domain as the BGP speaker." > > Bruno> This seems to mandate that implementations MUST support a > Bruno> configuration item listing the ASes numbers which are part of the > Bruno> AIGP AD. > > I think there are a variety of ways to meet this condition without having > such a configuration item. > From ss2539@att.com Fri Sep 27 09:16:10 2013 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 41A3221F9123 for ; Fri, 27 Sep 2013 09:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IswjnOhRbVy2 for ; Fri, 27 Sep 2013 09:16:04 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1A24721F9248 for ; Fri, 27 Sep 2013 09:16:04 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 44fa5425.2aaadbc25940.9932380.00-509.27355654.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 27 Sep 2013 16:16:04 +0000 (UTC) X-MXL-Hash: 5245af4451f29d2d-3852b3359070540d8630c4166f67bb52c955a20f Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id f3fa5425.0.9932336.00-158.27355527.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 27 Sep 2013 16:16:00 +0000 (UTC) X-MXL-Hash: 5245af4054177820-d0df510aee6b4e5d36249f22ca5415bc3e67b199 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8RGFwES010702; Fri, 27 Sep 2013 12:15:59 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8RGFnxD010529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Sep 2013 12:15:54 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 27 Sep 2013 16:15:38 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0158.001; Fri, 27 Sep 2013 12:15:37 -0400 From: "SAAD, SAMIR S" To: Susan Hares , idr wg Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: Ac6w1mK9oZDNOu+SQiq0dAmRJ9YB/gKxlFDA Date: Fri, 27 Sep 2013 16:15:37 +0000 Message-ID: <438B11A5EC21D347A63ACB77E58C78BA0B4A3CF4@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> In-Reply-To: <000d01ceb0d6$c0a12800$41e37800$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.86.186] Content-Type: multipart/alternative; boundary="_000_438B11A5EC21D347A63ACB77E58C78BA0B4A3CF4MISOUT7MSGUSR9N_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=fLlYGGpskhUA:10 a=5Ay4ljVScIYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=16pnZUWWB] X-AnalysisOut: [cIA:10 a=48vgC7mUAAAA:8 a=TWZ_pG6aWpX1CTNdT5YA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA] X-AnalysisOut: [:8 a=GaH8jBBTj9STIqLu4iEA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S] X-AnalysisOut: [4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=cxTh6nj2XOynyS] X-AnalysisOut: [GN:21] Cc: "'John G. Scudder'" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) 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, 27 Sep 2013 16:16:10 -0000 --_000_438B11A5EC21D347A63ACB77E58C78BA0B4A3CF4MISOUT7MSGUSR9N_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Samir Saad AT&T Labs From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan= Hares Sent: Friday, September 13, 2013 7:13 PM To: idr wg Cc: 'John G. Scudder' Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) This is to start at 2 week WG last call for The Accumulated IGP Metric Attribute for BGP draft-ietf-idr-aigp-10.txt http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ This last call will end 9/27/13 Three implementations exist: ALU, Cisco, Juniper. Vote early and speak often. Sue and John IDR co-chairs --_000_438B11A5EC21D347A63ACB77E58C78BA0B4A3CF4MISOUT7MSGUSR9N_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

Samir Saad<= /span>

AT&T Labs

 

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, September 13, 2013 7:13 PM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/= 13)

 

This is to start at 2 week WG last call for

 

The Accumulated IGP Metric At= tribute for BGP

draft-ietf-idr-aigp-10.txt

 

http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/<= /o:p>

 

This last call will end 9/27/13

 

Three implementations exist: ALU, Cisco, Juniper.

 

Vote early and speak often.

 

Sue and John

IDR co-chairs

 

--_000_438B11A5EC21D347A63ACB77E58C78BA0B4A3CF4MISOUT7MSGUSR9N_-- From erosen@cisco.com Fri Sep 27 11:23:26 2013 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 AF07321F9F86 for ; Fri, 27 Sep 2013 11:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYikeyVUoBYh for ; Fri, 27 Sep 2013 11:23:21 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4C121F9F1B for ; Fri, 27 Sep 2013 11:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=253; q=dns/txt; s=iport; t=1380306201; x=1381515801; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=7ozgravNpuoFQFMDDoH4TIjESJd2142OqqF+OqT5wYc=; b=Rw2q/lyFxZIIFZQvEgILFUIJBjPxcKHdKIiFD2mFgdfgSB1otF5dKjVL f+8MIU0yFsNPz6ljGLX4UyRLGrcRRg1vHMlAtHYmuTn4pNxhzxJO2ZQ+d 7Ux+0exSksfj0Ck5o/cTOKuqGCLUX370cJDx6dhIHBHwxamh8jM80pUL0 Q=; X-IronPort-AV: E=Sophos;i="4.90,994,1371081600"; d="scan'208";a="265415216" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 27 Sep 2013 18:23:20 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8RINH3G015874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Sep 2013 18:23:18 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r8RINFuO015823; Fri, 27 Sep 2013 14:23:15 -0400 From: Eric Rosen To: Ilya Varlashkin In-reply-to: Your message of Thu, 26 Sep 2013 22:26:16 +0100. <50CC9CD0-01C9-4C9A-A6EF-7C8838746AC8@nobulus.com> Date: Fri, 27 Sep 2013 14:23:15 -0400 Message-ID: <15822.1380306195@erosen-linux> Cc: idr wg , erosen@cisco.com, "John G. Scudder" , Susan Hares Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 18:23:26 -0000 > Is the above something that IDR should consider for amending the draft? I think it would be much better to leave the AIGP draft as is, and for someone to write a new draft, possibly updating the AIGP draft, that specifies the option you want. From ju1738@att.com Fri Sep 27 12:15:39 2013 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 A33D721F9EB0 for ; Fri, 27 Sep 2013 12:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kqje742xCpdV for ; Fri, 27 Sep 2013 12:15:33 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id AEEBC21F9E26 for ; Fri, 27 Sep 2013 12:15:33 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 559d5425.4a733940.10053371.00-524.27700612.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 27 Sep 2013 19:15:33 +0000 (UTC) X-MXL-Hash: 5245d95561b03748-dcae9a11ca50cb6adb20823f2f14b3928f71d1a7 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 459d5425.0.10053355.00-464.27700560.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 27 Sep 2013 19:15:33 +0000 (UTC) X-MXL-Hash: 5245d9553bbffaa7-343fe81c0f4e4f60c6d49b72030dfbff102de01e Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8RJFV1G032288; Fri, 27 Sep 2013 15:15:31 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8RJFAmt031992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Sep 2013 15:15:15 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 27 Sep 2013 19:15:03 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0158.001; Fri, 27 Sep 2013 15:15:03 -0400 From: "UTTARO, JAMES" To: "erosen@cisco.com" , Ilya Varlashkin Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOu66hoZDNOu+SQiq0dAmRJ9YB/pnZ9FWA Date: Fri, 27 Sep 2013 19:15:02 +0000 Message-ID: References: Your message of Thu, 26 Sep 2013 22:26:16 +0100. <50CC9CD0-01C9-4C9A-A6EF-7C8838746AC8@nobulus.com> <15822.1380306195@erosen-linux> In-Reply-To: <15822.1380306195@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.61.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=T3PedOoFyaYA:10 a=5Ay4ljVScIYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16pnZUWWBcIA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8] X-AnalysisOut: [ a=UPhbmpSP0E5wFQwjLXcA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=JfD0Fch1gWkA:10] Cc: idr wg , Susan Hares , "John G. Scudder" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) 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, 27 Sep 2013 19:15:39 -0000 Agreed -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Eric = Rosen Sent: Friday, September 27, 2013 2:23 PM To: Ilya Varlashkin Cc: idr wg; erosen@cisco.com; John G. Scudder; Susan Hares Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) > Is the above something that IDR should consider for amending the draft? I think it would be much better to leave the AIGP draft as is, and for someone to write a new draft, possibly updating the AIGP draft, that specifies the option you want. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From bdickson@verisign.com Fri Sep 27 12:20:59 2013 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 99DAB21F9F85 for ; Fri, 27 Sep 2013 12:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e22rZZw-oNzI for ; Fri, 27 Sep 2013 12:20:53 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6951621F9F77 for ; Fri, 27 Sep 2013 12:20:48 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUkXajLTkPVTQdrK05dFkz0uwvVYezbDx@postini.com; Fri, 27 Sep 2013 12:20:52 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r8RJKeq8013787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 15:20:40 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 27 Sep 2013 15:20:40 -0400 From: "Dickson, Brian" To: "erosen@cisco.com" , Ilya Varlashkin Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOu66hoZDNOu+SQiq0dAmRJ9YB/pnZ9e4A Date: Fri, 27 Sep 2013 19:20:39 +0000 Message-ID: In-Reply-To: <15822.1380306195@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg , Susan Hares , "John G. Scudder" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) 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, 27 Sep 2013 19:20:59 -0000 So, what about the suggestion of using a capability-negotiate rather than (intrinsically) a capability-"assume"? It would not change the operational model of "default enable", while removing the possibility of introducing problems in cases of iBGP sessions between AIGP and non-AIGP routers. It seems like a very small change, IMHO. You may have overlooked it in my larger email. (The impacted code is basically exercised only on session set-up, and disables AIGP_SESSION if the capability is not negotiated.) Thoughts? Brian On 9/27/13 2:23 PM, "Eric Rosen" wrote: > >> Is the above something that IDR should consider for amending the draft? > >I think it would be much better to leave the AIGP draft as is, and for >someone to write a new draft, possibly updating the AIGP draft, that >specifies the option you want. > > > > > > > > > > > > > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From shares@ndzh.com Fri Sep 27 12:51:03 2013 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 4C3EA21F9323 for ; Fri, 27 Sep 2013 12:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaqEJS34h4Vx for ; Fri, 27 Sep 2013 12:50:59 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 164E921F918C for ; Fri, 27 Sep 2013 12:50:58 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.159.172; From: "Susan Hares" To: "'Jeffrey Haas'" References: <025b01ceb0b4$01682f50$04388df0$@ndzh.com> <20130919141113.GK8137@pfrc> In-Reply-To: <20130919141113.GK8137@pfrc> Date: Fri, 27 Sep 2013 15:50:49 -0400 Message-ID: <00e101cebbba$de99b6d0$9bcd2470$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQBYE4zlIfvAI9Q2A9FDJpECSdK0LwHuszpmnLfTbeA= X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' , erosen@cisco.com, "'John G. Scudder'" , 'Yakov Rekhter' Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-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, 27 Sep 2013 19:51:03 -0000 Jeff, Randy, Qin, Yakov and Eric: Nice discussion the draft. This draft has passed WG last call. The write-up will be posted today. The cross-area reviews have begun (OPS-DIR, GEN-ART, IANA). If you wish to suggest any other reviews, please send the note to Sue Hares (Document shepherd). Lastly, please watch for IETF last call. Sue Hares -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Thursday, September 19, 2013 10:11 AM To: Susan Hares Cc: idr wg; erosen@cisco.com; 'John G. Scudder'; 'Yakov Rekhter' Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt On Fri, Sep 13, 2013 at 03:03:59PM -0400, Susan Hares wrote: > Just in case the last message on this topic got caught in August > doldrums, we are extending the WG last call for 1 more week: > > IANA Registries for BGP Extended Communities > > draft-ietf-idr-extcomm-iana-00.txt > > https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ As usual, I'm behind in my email. However, I strongly support the last call on this draft. The life of the extended communities feature has been somewhat muddled across its lifetime from original I-D to its RFC state. A significant portion of its lack of clarity has been the appearance, even though not actually stated in the draft or other I-Ds or RFCs that add related code points, that things are far more structured than they're really specified. Examples as a young BGP implementor had included presuming the transitivity bit is simply a bit rather than defining a separate code space. The same thing holds for the IANA bit. Additional points of confusion have tended to include the sub-type field which is effectively in many implementations a "format type", is shown that this is explicitly only so for specific types - and that it may be distinct depending on the I or T bits. Finally, the issues surrounding allocation policy were significantly tightened up as the original extended community drafts went from I-D to RFC, this document further normalizes the "experimental" space as having long lived code points in it, such as the RFC 5575 flowspec redirect-to-vrf community. In my opinion, this work is not only long overdue, but strongly necessary to help avoiding further semantic drift in the extended community registries and related accidentally incorrect implementations. Did I mention I support this document? :-) (And if you haven't chimed in but have a BGP implementation, you should do so as well.) -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From shares@ndzh.com Fri Sep 27 14:38:25 2013 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 B5F0C21F9FA2 for ; Fri, 27 Sep 2013 14:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[AWL=0.852, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj59cJQoF7rw for ; Fri, 27 Sep 2013 14:38:21 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2B35921F9F45 for ; Fri, 27 Sep 2013 14:38:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.159.172; From: "Susan Hares" To: , "'idr wg'" References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Fri, 27 Sep 2013 17:38:15 -0400 Message-ID: <014101cebbc9$e0adf300$a209d900$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQFWVRGMesRlg9yhBoY3WiZzMXXjYQIGvnGKmrqzBdA= X-Authenticated-User: skh@ndzh.com Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh 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, 27 Sep 2013 21:38:25 -0000 Bruno and all other reviewers: Thank you for your comments and your review of idr-ietf-idr-bgp-enhanced-route-refresh. This draft seems to be implemented, but the text seems to need another revision prior to passing WG LC. I encourage the authors to spin another revision of the text. We'll pick this up with another WG LC on this draft. Sue Hares and John Scudder -----Original Message----- From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Wednesday, September 25, 2013 9:19 AM To: Susan Hares; idr wg Cc: 'Keyur Patel (keyupate)' Subject: RE: [Idr] 2 Week WG last call for draft-ietf-idr-bgp-enhanced-route-refresh Hi all, Please find below some comments: Note: in this email, RR stands for ROUTE-REFRESH. 1) Routing consistency validation 3. Operations: " When a route entry in the "ADJ-RIB- Out" changes, the advertisement of the modified route entry (instead of the snapshot entry) would suffice." This indeed allows faster propagation of routing change which is a priori good. However, this seems to limit the ability to perform "consistency validations of BGP routing updates" as described in the abstract. Because the BGP speaker receiving the route refresh does not know if the inconsistency (between its local route and the received refreshed one) is due to a new update, or a missed old one. Indeed, the introduction only refers to "missing withdraws". However, for VPN SAFI, missing updates are also important as the VPN label of the NLRI may have change and hence, with a missed BGP update, the packet could be directed to a wrong VPN. 2) Error handling 2.a) " When the BGP speaker detects an error while processing a ROUTE- REFRESH message with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION message" I don't think this behavior is the one called by " Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 " draft-ietf-grow-ops-reqs-for-bgp-error-handling This seems too disruptive for a non vital message. One could say that this point if for draft-ietf-idr-error-handling. However IMHO, draft-ietf-idr-error-handling should rather cover the general case plus past RFC. New document should handle their new error cases, the new way. And from an implementation standpoint, let's imagine a company that has implemented both drafts, which error handling behavior has been implemented i.e. will get deployed? 2.b) One case of error is missing: what should be done if the BGP capability received has a length not matching the receiver requirements? (ignore the capability? ignore the wrong length? send a notification? 2.c) Draft is more or less overriding the "Reserved [...]. Should be set to 0 by the sender and ignored by the receiver.". I think I would be fair to say that "RR messages with unknown Subtypes SHOULD be processed as regular RR", which seems on the same line of the existing RR RFC (rather than sending a notification as currently specified in this draft: " When the BGP speaker detects an error while processing a ROUTE-REFRESH message with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION message") 3) Message subtypes - IMO, a new IANA registry needs to be created to allow new values to be defined for this new sub-type. - It would be good to define how new sub-types values are going to be introduced in the protocol/network. One option may be to have the new "Enhanced Route Refresh Capability" listing (in its value field) all the supported subtypes. 4) aborting ERR A BGP speaker having send a "Demarcation of the beginning of a route refresh" may want to abort the ERR procedure and not send the "Demarcation of the ending of a route refresh". One reason may be that sending the route refresh is too long (e.g. exceed a local timer) and hence delay too much the sending of BGP withdraw, hence delay the BGP convergence. In such case, how is the speaker supposed to react? (one option may be to define a sub-type for abortion) Same question for the receiver: if it finds the RR too long (compared to its BGP convergence time requirements), how should it behave? (one option which may help would be to advertise such max delay in the BGP capability) 5) not receiving "Demarcation of the ending of a route refresh How is the receiver supposed to react? - Never ever send a new RR on this session? This would be problematic as RR are typically used often, e.g. when a new VPN is configured. But it's not clear if sending a new RR is, strictly speaking, allowed by the current text. Hence the receiver would take the risk of "upsetting" the speaker and receiving a NOTIFICATION. - And if it sends a new RR, and receive a new "Demarcation of the beginning of a route refresh", should it wait for two " Demarcation of the ending of a route refresh" or is single one. (same question for the speaker: should it send two or one). 6) MUST? " Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a ROUTE-REFRESH message with the specified message subtype to mark the beginning of the route refresh." If the RR is initiated locally, I don't think that there is a need for a MUST. SHOULD seems more reasonable. MAY could even be enough. Thank you, Regards, Bruno >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of >Susan Hares >Sent: Friday, September 13, 2013 9:32 PM >To: idr wg >Cc: 'Keyur Patel (keyupate)' >Subject: [Idr] 2 Week WG last call for >draft-ietf-idr-bgp-enhanced-route- >refresh > >This begins a 2 week working group last call for (ending 9/27) Enhanced >Route Refresh Capability for BGP-4 >http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-04 > >This WG last call is in parallel with the 2 week implementation report >adoption call. > >The implementation report is at: >http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-imp >l/ > >We will read both threads in considering the last call. If the >implementation report is accepted, we will do a last call on the >implementation report. > >Sue Hares and John Scudder >Idr co-chairs > > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ____________________________________________________________________________ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From shares@ndzh.com Fri Sep 27 14:40:41 2013 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 18CB221F9FBF for ; Fri, 27 Sep 2013 14:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM5jVXSYSmfu for ; Fri, 27 Sep 2013 14:40:35 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E9B0011E8115 for ; Fri, 27 Sep 2013 14:40:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.159.172; From: "Susan Hares" To: "'Jeffrey Haas'" , References: <20130923195223.GE23879@pfrc> In-Reply-To: <20130923195223.GE23879@pfrc> Date: Fri, 27 Sep 2013 17:40:31 -0400 Message-ID: <015201cebbca$30e00a20$92a01e60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQJ/mmVc6oQyhGejjIq/hIWTdkYGdZh4Xz/w X-Authenticated-User: skh@ndzh.com Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs 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, 27 Sep 2013 21:40:41 -0000 Jeff: The adoption request will be open for 2 weeks (9/23 - 10/7/13) for: draft-rekhter-mdcs - Multicast Distribution Control Signaling draft-rekhter-mdrs - Multicast Distribution Reachability Signaling Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, September 23, 2013 3:52 PM To: idr@ietf.org Subject: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs The authors of the following two drafts would like to request adoption of these drafts by the IDR working group: draft-rekhter-mdcs - Multicast Distribution Control Signaling draft-rekhter-mdrs - Multicast Distribution Reachability Signaling draft-rekhter-geo-distribution will be seeking adoption in mboned. These drafts were presented at the IDR session at the IETF 87 in Berlin. As noted during the presentation, the primary goal of soliciting WG adoption is to get WG review of the drafts. The drafts primarily request additional SAFI codepoints while also noting an application of the RFC 5575 BGP Flowspec encoding for use in multicast control plane filtering. -- Jeff (for the authors) _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From shares@ndzh.com Fri Sep 27 14:44:50 2013 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 7405521F9DD5 for ; Fri, 27 Sep 2013 14:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.136 X-Spam-Level: X-Spam-Status: No, score=0.136 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_20=-0.74, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smhJ1Uo57Q1E for ; Fri, 27 Sep 2013 14:44:46 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 82EEA21F9DCE for ; Fri, 27 Sep 2013 14:44:41 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.159.172; From: "Susan Hares" To: "idr wg" Date: Fri, 27 Sep 2013 17:44:38 -0400 Message-ID: <015401cebbca$c44bc150$4ce343f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0155_01CEBBA9.3D3AE4A0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac67yrrz3ijrH5VVQvKGyxNlyFSh0w== X-Authenticated-User: skh@ndzh.com Subject: [Idr] approved as WG Draft: draft-keyupate-idr-enhanced-refresh-impl-00 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, 27 Sep 2013 21:44:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0155_01CEBBA9.3D3AE4A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The document on: Enhanced Route Refresh Implementation Report (draft-keyupate-idr-enhanced-refresh-impl-00) http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-impl/ Is approved as WG document. Please submit as: Draft-idr-enhanced-refresh-implementation-rpt-00 Sue and John Scudder ------=_NextPart_000_0155_01CEBBA9.3D3AE4A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The document on:

Enhanced Route Refresh Implementation = Report

(draft-keyupate-idr-enhanced-refresh-impl-00) =

http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-ref= resh-impl/

Is approved as WG = document.

 

Please submit = as:

   = Draft-idr-enhanced-refresh-implementation-rpt-00 =

 

Sue and John = Scudder

 

------=_NextPart_000_0155_01CEBBA9.3D3AE4A0-- From ilya@nobulus.com Sat Sep 28 15:47:54 2013 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 D7EA421E811B for ; Sat, 28 Sep 2013 15:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIr-SOg7lX19 for ; Sat, 28 Sep 2013 15:47:44 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8D21F995E for ; Sat, 28 Sep 2013 15:47:42 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 97405175D6; Sun, 29 Sep 2013 00:47:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LGIltcI8UyJW; Sun, 29 Sep 2013 00:47:37 +0200 (CEST) Received: from [192.168.0.5] (cpc16-nmal17-2-0-cust409.croy.cable.virginmedia.com [80.195.189.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id B9D1017516; Sun, 29 Sep 2013 00:47:37 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ilya Varlashkin In-Reply-To: Date: Sat, 28 Sep 2013 23:47:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1ECAC79F-4274-4CB1-996B-1988B8A661F8@nobulus.com> References: Your message of Thu, 26 Sep 2013 22:26:16 +0100. <50CC9CD0-01C9-4C9A-A6EF-7C8838746AC8@nobulus.com> <15822.1380306195@erosen-linux> To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1508) Cc: idr wg , "erosen@cisco.com" , Susan Hares , "John G. Scudder" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) 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, 28 Sep 2013 22:47:55 -0000 Ok, but then current draft should say how to handle AIGP Types an = implementation doesn't recognise. /iLya On Sep 27, 2013, at 8:15 PM, "UTTARO, JAMES" wrote: > Agreed >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Eric Rosen > Sent: Friday, September 27, 2013 2:23 PM > To: Ilya Varlashkin > Cc: idr wg; erosen@cisco.com; John G. Scudder; Susan Hares > Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending = 9/27/13) >=20 >=20 >> Is the above something that IDR should consider for amending the = draft? >=20 > I think it would be much better to leave the AIGP draft as is, and for > someone to write a new draft, possibly updating the AIGP draft, that > specifies the option you want. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From thomas.mangin@exa-networks.co.uk Sun Sep 29 02:31:12 2013 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 7470921F9346; Sun, 29 Sep 2013 02:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppOVhtBo2-tg; Sun, 29 Sep 2013 02:31:07 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) by ietfa.amsl.com (Postfix) with ESMTP id 26B6521F9F34; Sun, 29 Sep 2013 02:31:03 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 4B7FCA004C; Sun, 29 Sep 2013 10:31:01 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id EEF9C6C0047; Sun, 29 Sep 2013 10:31:00 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Mangin In-Reply-To: Date: Sun, 29 Sep 2013 10:31:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "John G. Scudder" , idr wg , "erosen@cisco.com" , Susan Hares Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 09:31:12 -0000 Hello Brian, At first read I was also surprised not to find a capability, as nearly = every BGP RFC adds one, but thinking about it I do not believe it is = necessary, but I believe something important was missed (see last = paragraph). In this case, the default behaviour of BGP is to already ignore the = unknown attribute, It will not be transmitted neither, so adding some = code for the negotiation of the feature is not really required. One = could add the code complexity of an capability, but I see no advantage. Capability negotiation is useful : - when both parties need to know about the feature to make sense of the = new data format sent on the wire, as otherwise the data received would = be seen as invalid and would cause the tearing down of the session - to prevent the propagation of new NLRI or otherwise transitive = attributes, which could cause bugs in routers quite a few ASN away from = the originating network. However nothing prevent the propagation of a TRANSITIVE attribute 26. = The default behaviour on EBGP is to ignore the attribute, but the RFC = does not explicitly ask for the TRANSITIVE attribute to be blocked.=20 As RFC 4271 says : "Paths with unrecognized transitive optional = attributes SHOULD be accepted.". I would suggest that the RFC adds some = wording to explicitly ignore transitive attribute received with = attribute 26. As without this limitation, one could cause the activation = of the feature on a foreign network on IBGP ( capability or no = capability ) through messages sent through EBGP. Thomas On 27 Sep 2013, at 20:20, "Dickson, Brian" = wrote: > So, what about the suggestion of using a capability-negotiate rather = than > (intrinsically) a capability-"assume"? >=20 > It would not change the operational model of "default enable", while > removing the possibility of introducing problems in cases of iBGP = sessions > between AIGP and non-AIGP routers. >=20 > It seems like a very small change, IMHO. >=20 > You may have overlooked it in my larger email. >=20 > (The impacted code is basically exercised only on session set-up, and > disables AIGP_SESSION if the capability is not negotiated.) >=20 > Thoughts? >=20 > Brian >=20 > On 9/27/13 2:23 PM, "Eric Rosen" wrote: >=20 >>=20 >>> Is the above something that IDR should consider for amending the = draft? >>=20 >> I think it would be much better to leave the AIGP draft as is, and = for >> someone to write a new draft, possibly updating the AIGP draft, that >> specifies the option you want. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From lenny@juniper.net Fri Sep 27 13:40:09 2013 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 1ED5521F9D95 for ; Fri, 27 Sep 2013 13:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mewfO9M2cTM for ; Fri, 27 Sep 2013 13:40:04 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5457A21F9D9C for ; Fri, 27 Sep 2013 13:40:04 -0700 (PDT) Received: from mail212-tx2-R.bigfish.com (10.9.14.226) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Fri, 27 Sep 2013 20:40:03 +0000 Received: from mail212-tx2 (localhost [127.0.0.1]) by mail212-tx2-R.bigfish.com (Postfix) with ESMTP id C71031C024A; Fri, 27 Sep 2013 20:40:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(z21eIzbb2dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz8275ch1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h944hd25hf0ah11b5h121eh1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h16a6h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dc1h1de2h1dfeh1dffh1fe8h1ff5h1155h) Received-SPF: pass (mail212-tx2: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=lenny@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail212-tx2 (localhost.localdomain [127.0.0.1]) by mail212-tx2 (MessageSwitch) id 1380314401264885_31177; Fri, 27 Sep 2013 20:40:01 +0000 (UTC) Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.227]) by mail212-tx2.bigfish.com (Postfix) with ESMTP id 389DFAC003F; Fri, 27 Sep 2013 20:40:01 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.54) by TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 27 Sep 2013 20:39:57 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Sep 2013 13:39:56 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r8RKdtL64941; Fri, 27 Sep 2013 13:39:55 -0700 (PDT) (envelope-from lenny@juniper.net) Received: by eng-mail01.juniper.net (Postfix, from userid 1709) id 8D77311446; Fri, 27 Sep 2013 13:39:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 16EE91144E; Fri, 27 Sep 2013 13:39:53 -0700 (PDT) Date: Fri, 27 Sep 2013 13:39:53 -0700 From: Leonard Giuliano To: idr wg Message-ID: <20130927133649.D32491@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Mon, 30 Sep 2013 08:02:35 -0700 Cc: "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) 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, 27 Sep 2013 20:40:09 -0000 I support advancing this draft. It is very useful functionality in certain scenarios. -Lenny > From: Susan Hares > Subject: WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) > Date: September 13, 2013 7:12:43 PM EDT > To: idr wg > Cc: "'John G. Scudder'" , "John G. Scudder" , > > This is to start at 2 week WG last call for > > The Accumulated IGP Metric Attribute for BGP > draft-ietf-idr-aigp-10.txt > > http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ > > This last call will end 9/27/13 > > Three implementations exist: ALU, Cisco, Juniper. > > Vote early and speak often. > > Sue and John > IDR co-chairs From internet-drafts@ietf.org Mon Sep 30 08:06:50 2013 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 5A8AA21F9BC2; Mon, 30 Sep 2013 08:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy2-96EPZQIZ; Mon, 30 Sep 2013 08:06:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D1421F92B7; Mon, 30 Sep 2013 08:06:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130930150649.31558.67531.idtracker@ietfa.amsl.com> Date: Mon, 30 Sep 2013 08:06:49 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-extcomm-iana-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 15:06:50 -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 : IANA Registries for BGP Extended Communities Author(s) : Eric C. Rosen Yakov Rekhter Filename : draft-ietf-idr-extcomm-iana-01.txt Pages : 18 Date : 2013-09-30 Abstract: This document reorganizes the IANA Registries for the type values and sub-type values of BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove inter-dependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations, and thus do not affect protocol implementations. The changes will however impact the "IANA Considerations" sections of future protocol specifications. This document updates RFCs 4360 and 5701. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-extcomm-iana-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-extcomm-iana-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ss2539@att.com Mon Sep 30 10:53:23 2013 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 E6FDD21F9AD5 for ; Mon, 30 Sep 2013 10:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWMxaMHOiPuY for ; Mon, 30 Sep 2013 10:53:18 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id ACFA721F960A for ; Mon, 30 Sep 2013 10:53:16 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id b8ab9425.0.320889.00-168.909273.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 30 Sep 2013 17:53:16 +0000 (UTC) X-MXL-Hash: 5249ba8c3a8f81a7-2c3dc0bee5ece8574648df835fb3daa4fdc2a4bc Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8UHrFsW003090; Mon, 30 Sep 2013 13:53:15 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8UHr0j5002889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Sep 2013 13:53:11 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (MISOUT7MSGHUB9A.itservices.sbc.com [144.151.223.62]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 30 Sep 2013 17:52:54 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.03.0158.001; Mon, 30 Sep 2013 13:52:54 -0400 From: "SAAD, SAMIR S" To: Susan Hares Thread-Topic: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs Thread-Index: AQJ/mmVc6oQyhGejjIq/hIWTdkYGdZh4Xz/wgAR3HZA= Date: Mon, 30 Sep 2013 17:52:54 +0000 Message-ID: <438B11A5EC21D347A63ACB77E58C78BA0B4A4D78@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <20130923195223.GE23879@pfrc> <015201cebbca$30e00a20$92a01e60$@ndzh.com> In-Reply-To: <015201cebbca$30e00a20$92a01e60$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.224.100] Content-Type: multipart/alternative; boundary="_000_438B11A5EC21D347A63ACB77E58C78BA0B4A4D78MISOUT7MSGUSR9N_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=O52OSmBW c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=qCnTXhYKvtQA:10 a=-znsv2yXjpwA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=x6pz03Db4] X-AnalysisOut: [gAA:10 a=48vgC7mUAAAA:8 a=dQ8NIw3iD0-AUL8ynm4A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=_wFI7v3LBNo8X2HS:21 a=XfbEQa_] X-AnalysisOut: [jC6hPFCy0:21 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=QYZaG5w] X-AnalysisOut: [FkFTLucsK:21 a=XCcJVQs8iJuelaZo:21 a=L9W2lRX4HrERBl3B:21] Cc: "idr@ietf.org" Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 17:53:24 -0000 --_000_438B11A5EC21D347A63ACB77E58C78BA0B4A4D78MISOUT7MSGUSR9N_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support the adoption of the drafts Samir Saad AT&T Labs -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan= Hares Sent: Friday, September 27, 2013 5:41 PM To: 'Jeffrey Haas'; idr@ietf.org Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rek= hter-mdcs Jeff: The adoption request will be open for 2 weeks (9/23 - 10/7/13) for: draft-rekhter-mdcs - Multicast Distribution Control Signaling draft-rekhter-mdrs - Multicast Distribution Reachability Signaling Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, September 23, 2013 3:52 PM To: idr@ietf.org Subject: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs The authors of the following two drafts would like to request adoption of these drafts by the IDR working group: draft-rekhter-mdcs - Multicast Distribution Control Signaling draft-rekhter-mdrs - Multicast Distribution Reachability Signaling draft-rekhter-geo-distribution will be seeking adoption in mboned. These drafts were presented at the IDR session at the IETF 87 in Berlin. As noted during the presentation, the primary goal of soliciting WG adoptio= n is to get WG review of the drafts. The drafts primarily request additional SAFI codepoints while also noting an application of the RFC 5575 BGP Flowspec encoding for use in multicast control plane filtering. -- Jeff (for the authors) _______________________________________________ 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 --_000_438B11A5EC21D347A63ACB77E58C78BA0B4A4D78MISOUT7MSGUSR9N_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support the adoption of the drafts
 
Samir Saad
AT&T Labs
 
-----Original Message-----
From: idr-bounces@ietf.org [mailto:= idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, September 27, 2013 5:41 PM
To: 'Jeffrey Haas'; idr@ietf.org
Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rek= hter-mdcs
 
Jeff:
 
The adoption request will be open for 2 weeks (= 9/23 - 10/7/13) for:
 
draft-rekhter-mdcs - Multicast Distribution Con= trol Signaling
draft-rekhter-mdrs - Multicast Distribution Rea= chability Signaling
 
Sue
 
-----Original Message-----
Jeffrey Haas
Sent: Monday, September 23, 2013 3:52 PM=
Subject: [Idr] Request WG adoption for draft-re= khter-mdrs and
draft-rekhter-mdcs
 
The authors of the following two drafts would l= ike to request adoption of
these drafts by the IDR working group:
 
draft-rekhter-mdcs - Multicast Distribution Con= trol Signaling
draft-rekhter-mdrs - Multicast Distribution Rea= chability Signaling
 
draft-rekhter-geo-distribution will be seeking = adoption in mboned.
 
These drafts were presented at the IDR session = at the IETF 87 in Berlin.
 
As noted during the presentation, the primary g= oal of soliciting WG adoption
is to get WG review of the drafts.  The dr= afts primarily request additional
SAFI codepoints while also noting an applicatio= n of the RFC 5575 BGP
Flowspec encoding for use in multicast control = plane filtering.
 
-- Jeff (for the authors)
_______________________________________________=
Idr mailing list
 
_______________________________________________=
Idr mailing list
 
 --_000_438B11A5EC21D347A63ACB77E58C78BA0B4A4D78MISOUT7MSGUSR9N_-- From ju1738@att.com Mon Sep 30 11:03:58 2013 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 5286121F9AD2 for ; Mon, 30 Sep 2013 11:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YQFa1oA2jPt for ; Mon, 30 Sep 2013 11:03:52 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2FF21F89A5 for ; Mon, 30 Sep 2013 11:03:52 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 70db9425.0.4059700.00-090.11043452.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 30 Sep 2013 18:03:52 +0000 (UTC) X-MXL-Hash: 5249bd0823a5f0d4-90cbaf131e1ab828e39a8453407c87ba58fd7770 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8UI3pu7019724; Mon, 30 Sep 2013 14:03:51 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8UI3i5q019598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Sep 2013 14:03:48 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 30 Sep 2013 18:03:25 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0158.001; Mon, 30 Sep 2013 14:03:25 -0400 From: "UTTARO, JAMES" To: "SAAD, SAMIR S" , Susan Hares Thread-Topic: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs Thread-Index: AQJ/mmVc6oQyhGejjIq/hIWTdkYGdZh4Xz/wgAR3HZCAAAN8kA== Date: Mon, 30 Sep 2013 18:03:24 +0000 Message-ID: References: <20130923195223.GE23879@pfrc> <015201cebbca$30e00a20$92a01e60$@ndzh.com> <438B11A5EC21D347A63ACB77E58C78BA0B4A4D78@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <438B11A5EC21D347A63ACB77E58C78BA0B4A4D78@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.14.25] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F062D751AMISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=Rv1y2laK c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=RTI98BuLK7sA:10 a=0LHqpxDQv78A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=x6pz03Db4] X-AnalysisOut: [gAA:10 a=48vgC7mUAAAA:8 a=p8CSzJIwLWjX13C1Gb8A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=2TSDkfqdCjIA:10 a=lZB815dzVvQA:10 a=Ru7k1UIOsMl] X-AnalysisOut: [JsRma:21 a=oWGd6ePdbbpdw3nu:21 a=yMhMjlubAAAA:8 a=SSmOFEAC] X-AnalysisOut: [AAAA:8 a=ZnJmCdswW2owr75UwL8A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L] X-AnalysisOut: [4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=YwebJjqXD_] X-AnalysisOut: [8J4gHD:21 a=GpOa743b9MoUYrYM:21 a=M56KgwVP3RdItH2l:21] Cc: "idr@ietf.org" Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 18:03:58 -0000 --_000_B17A6910EEDD1F45980687268941550F062D751AMISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Jim Uttaro From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of SAAD,= SAMIR S Sent: Monday, September 30, 2013 1:53 PM To: Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rek= hter-mdcs ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Support the adoption of the drafts Samir Saad AT&T Labs -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Susan Hares Sent: Friday, September 27, 2013 5:41 PM To: 'Jeffrey Haas'; idr@ietf.org Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rek= hter-mdcs Jeff: The adoption request will be open for 2 weeks (9/23 - 10/7/13) for: draft-rekhter-mdcs - Multicast Distribution Control Signaling draft-rekhter-mdrs - Multicast Distribution Reachability Signaling Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, September 23, 2013 3:52 PM To: idr@ietf.org Subject: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs The authors of the following two drafts would like to request adoption of these drafts by the IDR working group: draft-rekhter-mdcs - Multicast Distribution Control Signaling draft-rekhter-mdrs - Multicast Distribution Reachability Signaling draft-rekhter-geo-distribution will be seeking adoption in mboned. These drafts were presented at the IDR session at the IETF 87 in Berlin. As noted during the presentation, the primary goal of soliciting WG adoptio= n is to get WG review of the drafts. The drafts primarily request additional SAFI codepoints while also noting an application of the RFC 5575 BGP Flowspec encoding for use in multicast control plane filtering. -- Jeff (for the authors) _______________________________________________ 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 --_000_B17A6910EEDD1F45980687268941550F062D751AMISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

Jim Uttaro

 <= /p>

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of SAAD, SAMIR S
Sent: Monday, September 30, 2013 1:53 PM
To: Susan Hares
Cc: idr@ietf.org
Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and dr= aft-rekhter-mdcs

 

***Security Advisory: This Message Originated Outside of= AT&T ***
Reference http://cso= .att.com/EmailSecurity/IDSP.html for more information.

Support the adoption of the dr= afts

 

Samir Saad=

AT&T Labs

 

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Be= half Of Susan Hares
Sent: Friday, September 27, 2013 5:41 PM
To: 'Jeffrey Haas'; idr@ietf.org
Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rek= hter-mdcs

 

Jeff:

 

The adoption request will be open for 2= weeks (9/23 - 10/7/13) for:

 

draft-rekhter-mdcs - Multicast Distribu= tion Control Signaling

draft-rekhter-mdrs - Multicast Distribu= tion Reachability Signaling

 

Sue

 

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

Jeffrey Haas

Sent: Monday, September 23, 2013 3:52 P= M

Subject: [Idr] Request WG adoption for = draft-rekhter-mdrs and

draft-rekhter-mdcs

 

The authors of the following two drafts= would like to request adoption of

these drafts by the IDR working group:<= /span>

 

draft-rekhter-mdcs - Multicast Distribu= tion Control Signaling

draft-rekhter-mdrs - Multicast Distribu= tion Reachability Signaling

 

draft-rekhter-geo-distribution will be = seeking adoption in mboned.

 

These drafts were presented at the IDR = session at the IETF 87 in Berlin.

 

As noted during the presentation, the p= rimary goal of soliciting WG adoption

is to get WG review of the drafts. = ; The drafts primarily request additional

SAFI codepoints while also noting an ap= plication of the RFC 5575 BGP

Flowspec encoding for use in multicast = control plane filtering.

 

-- Jeff (for the authors)

_______________________________________= ________

Idr mailing list=

 

_______________________________________= ________

Idr mailing list=

 

--_000_B17A6910EEDD1F45980687268941550F062D751AMISOUT7MSGUSR9I_-- From rbonica@juniper.net Mon Sep 30 12:17:46 2013 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 9C3AF21F9A6C for ; Mon, 30 Sep 2013 12:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cle9Qf+OIWR0 for ; Mon, 30 Sep 2013 12:17:41 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 0296521F9360 for ; Mon, 30 Sep 2013 12:17:40 -0700 (PDT) Received: from mail70-co1-R.bigfish.com (10.243.78.226) by CO1EHSOBE033.bigfish.com (10.243.66.98) with Microsoft SMTP Server id 14.1.225.22; Mon, 30 Sep 2013 19:17:40 +0000 Received: from mail70-co1 (localhost [127.0.0.1]) by mail70-co1-R.bigfish.com (Postfix) with ESMTP id 0440F1C00E2 for ; Mon, 30 Sep 2013 19:17:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzbb2dI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de097h18602eh8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail70-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(189002)(199002)(51704005)(79102001)(31966008)(74662001)(74502001)(47446002)(76786001)(76796001)(49866001)(4396001)(77096001)(63696002)(47736001)(56816003)(76576001)(76176001)(77982001)(59766001)(56776001)(54316002)(50986001)(76482001)(47976001)(81816001)(19580395003)(80976001)(83322001)(33646001)(81686001)(74316001)(54356001)(74366001)(74876001)(74706001)(83072001)(65816001)(80022001)(46102001)(15974865002)(81542001)(53806001)(66066001)(81342001)(51856001)(69226001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail70-co1 (localhost.localdomain [127.0.0.1]) by mail70-co1 (MessageSwitch) id 1380568626422821_19451; Mon, 30 Sep 2013 19:17:06 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.231]) by mail70-co1.bigfish.com (Postfix) with ESMTP id 63D7AB402C9 for ; Mon, 30 Sep 2013 19:17:06 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 30 Sep 2013 19:17:06 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.359.1; Mon, 30 Sep 2013 19:17:06 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 30 Sep 2013 19:17:03 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.55]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.55]) with mapi id 15.00.0775.005; Mon, 30 Sep 2013 19:17:03 +0000 From: Ronald Bonica To: "idr@ietf.org List" Thread-Topic: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs Thread-Index: Ac6+EaSisRIC69JSQhOLPL9wFpXiwQ== Date: Mon, 30 Sep 2013 19:17:03 +0000 Message-ID: <6fd9586a238746b19965623c881aa919@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0985DA2459 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 19:17:46 -0000 Also support >> Jeff: >>=20 >> The adoption request will be open for 2 weeks (9/23 - 10/7/13) for:=20 >> >> draft-rekhter-mdcs - Multicast Distribution Control Signaling >> draft-rekhter-mdrs - Multicast Distribution Reachability Signaling >>=20 >> Sue -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From jdrake@juniper.net Mon Sep 30 13:27:09 2013 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 19C4721F9DFB for ; Mon, 30 Sep 2013 13:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+kJXwahVEui for ; Mon, 30 Sep 2013 13:27:04 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 8486621F99E9 for ; Mon, 30 Sep 2013 13:27:03 -0700 (PDT) Received: from mail32-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.22; Mon, 30 Sep 2013 20:27:02 +0000 Received: from mail32-am1 (localhost [127.0.0.1]) by mail32-am1-R.bigfish.com (Postfix) with ESMTP id 765893E0312; Mon, 30 Sep 2013 20:27:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zzbb2dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail32-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(51704005)(189002)(199002)(13464003)(77982001)(59766001)(74706001)(81342001)(83072001)(66066001)(69226001)(74316001)(31966008)(54316002)(15975445006)(76482001)(76796001)(76786001)(76576001)(77096001)(83322001)(19580405001)(56776001)(74876001)(56816003)(63696002)(19580395003)(50986001)(46102001)(47446002)(47736001)(49866001)(4396001)(53806001)(74502001)(80976001)(81686001)(74366001)(81542001)(81816001)(47976001)(74662001)(80022001)(65816001)(33646001)(54356001)(51856001)(79102001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail32-am1 (localhost.localdomain [127.0.0.1]) by mail32-am1 (MessageSwitch) id 1380572820132798_11430; Mon, 30 Sep 2013 20:27:00 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.251]) by mail32-am1.bigfish.com (Postfix) with ESMTP id 0EBB5420061; Mon, 30 Sep 2013 20:27:00 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 30 Sep 2013 20:26:57 +0000 Received: from BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.359.1; Mon, 30 Sep 2013 20:26:51 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 30 Sep 2013 20:26:49 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) with mapi id 15.00.0775.005; Mon, 30 Sep 2013 20:26:49 +0000 From: John E Drake To: Susan Hares , 'Jeffrey Haas' , "idr@ietf.org" Thread-Topic: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs Thread-Index: AQHOu8o/8WX3eWV3X0quLfSTo+z9DZnevuxg Date: Mon, 30 Sep 2013 20:26:48 +0000 Message-ID: References: <20130923195223.GE23879@pfrc> <015201cebbca$30e00a20$92a01e60$@ndzh.com> In-Reply-To: <015201cebbca$30e00a20$92a01e60$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0985DA2459 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 20:27:09 -0000 I support the adoption of these two drafts by the WG. Yours Irrespectively, John > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Susan Hares > Sent: Friday, September 27, 2013 2:41 PM > To: 'Jeffrey Haas'; idr@ietf.org > Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft- > rekhter-mdcs >=20 > Jeff: >=20 > The adoption request will be open for 2 weeks (9/23 - 10/7/13) for: >=20 > draft-rekhter-mdcs - Multicast Distribution Control Signaling draft-rekht= er- > mdrs - Multicast Distribution Reachability Signaling >=20 > Sue >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Jeffrey Haas > Sent: Monday, September 23, 2013 3:52 PM > To: idr@ietf.org > Subject: [Idr] Request WG adoption for draft-rekhter-mdrs and draft- > rekhter-mdcs >=20 > The authors of the following two drafts would like to request adoption of > these drafts by the IDR working group: >=20 > draft-rekhter-mdcs - Multicast Distribution Control Signaling draft-rekht= er- > mdrs - Multicast Distribution Reachability Signaling >=20 > draft-rekhter-geo-distribution will be seeking adoption in mboned. >=20 > These drafts were presented at the IDR session at the IETF 87 in Berlin. >=20 > As noted during the presentation, the primary goal of soliciting WG adopt= ion > is to get WG review of the drafts. The drafts primarily request addition= al SAFI > codepoints while also noting an application of the RFC 5575 BGP Flowspec > encoding for use in multicast control plane filtering. >=20 > -- Jeff (for the authors) > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From erosen@cisco.com Mon Sep 30 14:02:35 2013 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 3468721F9D52 for ; Mon, 30 Sep 2013 14:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0x2cNzBvuuJ for ; Mon, 30 Sep 2013 14:02:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 99FDE21F9D0A for ; Mon, 30 Sep 2013 14:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=612; q=dns/txt; s=iport; t=1380574947; x=1381784547; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=qfP3ofNU6Ua4Bl8KsfUpDEfH4rCZf5ji/FyUMLId7T8=; b=dSxViKlZuZq1fqgIfK9+N48qnWwGcUUKEWntkfubEt+zQO7qEbung0Kv 5n52ldWy5M7cNZ/e2oPSJmaxeSMRLLx77TqGlJ9R/Nt37p/UiBYE2wDGz juORucepWliJMqkUrUqZl8/onaH0PN3P1CqS4Z+irZ56Iv5Dz6O/wBKxV E=; X-IronPort-AV: E=Sophos;i="4.90,1010,1371081600"; d="scan'208";a="266180136" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 30 Sep 2013 21:02:25 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8UL2OXD006476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Sep 2013 21:02:25 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r8UL2NdO001402; Mon, 30 Sep 2013 17:02:23 -0400 From: Eric Rosen To: Ilya Varlashkin In-reply-to: Your message of Sat, 28 Sep 2013 23:47:38 +0100. <1ECAC79F-4274-4CB1-996B-1988B8A661F8@nobulus.com> Date: Mon, 30 Sep 2013 17:02:23 -0400 Message-ID: <1401.1380574943@erosen-linux> Cc: idr wg , erosen@cisco.com, "UTTARO, JAMES" , Susan Hares , "John G. Scudder" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 21:02:35 -0000 > current draft should say how to handle AIGP Types an implementation > doesn't recognise We can add that unrecognized types have no impact on the bestpath selection. I don't think there's anything more to say about them. With regard to type 1, the draft should probably state what to do if there is more than a single type 1 TLV. I propose to add a statement saying that an implementation originating an AIGP attribute MUST NOT include more than one type 1 TLV, and that an implementation receiving an AIGP attribute with more than one type 1 TLV MUST use only the AIGP value in the first one.