headers
John Scudder | 2 Jun 2011 21:15
Favicon

draft-keyur-bgp-enhanced-route-refresh as WG document

Folks,

draft-keyur-bgp-enhanced-route-refresh is accepted as an IDR working group document.  Authors, please
resubmit as draft-ietf-idr-bgp-enhanced-route-refresh-00.

The chairs will consult with the AD regarding adding this to our charter.

--John
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
John Scudder | 2 Jun 2011 21:17
Favicon

draft-ymbk-bgp-extended-messages as WG document

Folks,

draft-ymbk-bgp-extended-messages is accepted as an IDR working group document.  Authors, please
resubmit as draft-ietf-idr-bgp-extended-messages-00.

The chairs will consult with the AD regarding adding this to our charter.

--John
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
John Scudder | 2 Jun 2011 21:22
Favicon

Re: WGLC for draft-ietf-idr-deprecate-as-sets-04

The WGLC has concluded.  We will send the draft to the IESG for publication as an RFC after consulting with the AD.

Thanks,

--John

On May 2, 2011, at 5:36 PM, John Scudder wrote:

> Folks,
> 
> This is to start a (new) working group last call for draft-ietf-idr-deprecate-as-sets-04.  Please send
comments by May 17, 2011.
> 
> http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-04
> 
> Thanks,
> 
> --John
> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
John Scudder | 2 Jun 2011 22:33
Favicon

Re: Dissemination of Flow Specification Rules for IPv6

Folks,

This is accepted as an IDR working group document.  Authors, please resubmit as draft-ietf-idr-flow-spec-v6-00.

The chairs will consult with the AD regarding adding this to our charter.

--John

On Mar 31, 2011, at 9:31 AM, Robert Raszuk wrote:

> 
> Authors of "Dissemination of Flow Specification Rules for IPv6" draft 
> document would like to propose the adoption of this work as the IDR WG item.
> 
> Ref:
> http://tools.ietf.org/html/draft-raszuk-idr-flow-spec-v6-01
> 
> Rgs,
> R. Raszuk
> B. Pithawala
> D. McPherson
> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
(Continue reading)

Permalink | Reply | 0 comments |
headers
internet-drafts | 3 Jun 2011 07:36
Picon
Favicon

I-D Action: draft-ietf-idr-dynamic-cap-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Inter-Domain Routing Working Group of the IETF.

	Title           : Dynamic Capability for BGP-4
	Author(s)       : Enke Chen
                          Srihari R. Sangli
	Filename        : draft-ietf-idr-dynamic-cap-13.txt
	Pages           : 7
	Date            : 2011-06-02

   This document defines a new BGP capability termed &quot;Dynamic
   Capability&quot;, which would allow the dynamic update of capabilities
   over an established BGP session. This capability would facilitate
   non-disruptive capability changes by BGP speakers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-13.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-13.txt
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
John Scudder | 3 Jun 2011 17:24
Favicon

Re: WG adoption of "IPv6 AF Extensions for Route Target Distribution"

Folks,

This is accepted as an IDR working group document.  Authors, please resubmit as draft-ietf-idr-af-specific-rt-constrain-00.

The chairs will consult with the AD regarding adding this to our charter.

--John

On Mar 31, 2011, at 11:54 AM, Jie Dong wrote:

> Dear all, 
> 
> Authors of "IPv6 AF Extensions for Route Target Distribution" would like to propose to adopt this draft as
IDR WG document.
> 
> The draft could be found at: 
> http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01
> 
> 
> Best regards,
> Keyur Patel
> Robert Raszuk
> Martine Djernaes
> Jie Dong
> Mach Chen
> 
> 
> 
> _______________________________________________
> Idr mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Scudder | 3 Jun 2011 17:26
Favicon

New WG documents

Folks,

FYI there seems to be some delay in the new WG draft approval process.  I have a ticket open with the
Secretariat to investigate.  FYI, this is the reason you're not seeing new WG -00 drafts for those that have
recently been accepted.

--John
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 3 Jun 2011 23:30
Picon
Favicon

I-D ACTION:draft-ietf-idr-bgp-optimal-route-reflection-00.txt

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

    Title         : BGP Optimal Route Reflection (BGP-ORR)
    Author(s)     : R. Raszuk, et al
    Filename      : draft-ietf-idr-bgp-optimal-route-reflection-00.txt
    Pages         : 19
    Date          : 2011-06-03

   [RFC4456] asserts that, because the Interior Gateway Protocol (IGP)
   cost to a given point in the network will vary across routers, "the
   route reflection approach may not yield the same route selection
   result as that of the full IBGP mesh approach."  One practical
   implication of this assertion is that the deployment of route
   reflection may thwart the ability to achieve hot potato routing.  Hot
   potato routing attempts to direct traffic to the closest AS egress
   point in cases where no higher priority policy dictates otherwise.
   As a consequence of the route reflection method, the choice of exit
   point for a route reflector and its clients will be the egress point
   closest to the route reflector - and not necessarily closest to the
   RR clients.

   Section 11 of [RFC4456] describes a deployment approach and a set of
   constraints which, if satsified, would result in the deployment of
   route reflection yielding the same results as the iBGP full mesh
   approach.  Such a deployment approach would make route reflection
   compatible with the application of hot potato routing policy.

   As networks evolved to accommodate architectural requirements of new
   services, tunneled (LSP/IP tunneling) networks with centralized route
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Raszuk | 5 Jun 2011 00:51
Picon
Favicon

draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt

Hi,

Attracted by the title I could not resit to read this draft. Here are 
some of the comments and questions I have regarding the document.

* Up front to make it very clear for all readers can authors explicitly 
confirm that the applicability of this draft is only limited to networks 
which use some form of tunneling (for example: MPLS) between each PE and 
ASBRs ?

* The idea of community based route selection on RRs is nothing new. 
Using RT extended community as well as RT Constrain while does automates 
the preference push from PE to RR to limit number of paths to be 
received. However if also comes along with the following issues:

  - It does it in pure static way putting all burden of what can be 
automated into the operator's NOC. Note that all information required 
for optimal path selection is already present on RR without any need for 
operational configuration burden today.

  - The networks topologies change dynamically which will not be 
reflected in the static RT based preference.

  - Addition and deletion of new ASBR both planned and unplanned require 
full reconfiguration of each PE to get to the same level of BGP path 
redundancy reception.

  - Addition and deletion of new service POP both planned and unplanned 
require full reconfiguration of each PE to get to the same level of BGP 
path redundancy reception.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeff Tantsura | 5 Jun 2011 04:05
Picon
Favicon

Re: draft-vinod-lavallee-bgp-optimal-route-reflection-00.txt

+1

Regards,
Jeff

On Jun 4, 2011, at 15:51, "Robert Raszuk" <raszuk <at> cisco.com> wrote:

> Hi,
> 
> Attracted by the title I could not resit to read this draft. Here are 
> some of the comments and questions I have regarding the document.
> 
> * Up front to make it very clear for all readers can authors explicitly 
> confirm that the applicability of this draft is only limited to networks 
> which use some form of tunneling (for example: MPLS) between each PE and 
> ASBRs ?
> 
> * The idea of community based route selection on RRs is nothing new. 
> Using RT extended community as well as RT Constrain while does automates 
> the preference push from PE to RR to limit number of paths to be 
> received. However if also comes along with the following issues:
> 
>  - It does it in pure static way putting all burden of what can be 
> automated into the operator's NOC. Note that all information required 
> for optimal path selection is already present on RR without any need for 
> operational configuration burden today.
> 
>  - The networks topologies change dynamically which will not be 
> reflected in the static RT based preference.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane