WG adoption of draft-dhrao-idr-4octet-extcomm-generic-subtype

Folks,

Please send your comments on the attached. The deadline for comments
is Nov 17, 2008.

Yakov.
------- Forwarded Message

Date:    Fri, 31 Oct 2008 18:29:47 -0400
From:    Jeffrey Haas <jhaas <at> pfrc.org>
To:      idr <at> ietf.org
Subject: [Idr] WG adoption of draft-dhrao-idr-4octet-extcomm-generic-subtype

Yakov and Sue,

We'd like to request the working group adopt the internet-draft
draft-dhrao-idr-4octet-extcomm-generic-subtype as a working group item.
This draft adds a generic 4 octet extended community to complement the
2-octet AS community behavior publised in RFC 1997.

Although very similar to draft-ietf-l3vpn-as4octet-ext-community, we'd
like to request adoption of this draft in IDR since it has no l3vpn
specific semantics.

- -- Jeff
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

draft-jakma-mrai as IDR WG document.

Folks,

While so far we received no objections, the number of folks who
expressed their support for accepting draft-jakma-mrai is not enough
to justify accepting it as IDR WG document.

With this in mind I'd like to extend the period of comments for
another week. If folks feel that this document should be accepted
as IDR WG document, please respond to this e-mail by no late than
Nov 10, 2008.

Yakov.
------- Forwarded Message

Date:    Thu, 16 Oct 2008 06:07:01 -0700
From:    Yakov Rekhter <yakov <at> juniper.net>
To:      idr <at> ietf.org
Subject: [Idr] draft-jakma-mrai as IDR WG document.

Folks,

Please send your comments on the attached. The deadline for comments
is Oct 30, 2008.

Yakov.
- ------- Forwarded Message

Date:    Wed, 15 Oct 2008 13:50:46 +0100
From:    Paul Jakma <paul <at> jakma.org>
To:      Inter-Domain Routing List <idr <at> ietf.org>

Re: draft-jakma-mrai as IDR WG document.

Support.

Thx,
R.

> Folks,
> 
> While so far we received no objections, the number of folks who
> expressed their support for accepting draft-jakma-mrai is not enough
> to justify accepting it as IDR WG document.
> 
> With this in mind I'd like to extend the period of comments for
> another week. If folks feel that this document should be accepted
> as IDR WG document, please respond to this e-mail by no late than
> Nov 10, 2008.
> 
> Yakov.
> ------- Forwarded Message
> 
> Date:    Thu, 16 Oct 2008 06:07:01 -0700
> From:    Yakov Rekhter <yakov <at> juniper.net>
> To:      idr <at> ietf.org
> Subject: [Idr] draft-jakma-mrai as IDR WG document.
> 
> Folks,
> 
> Please send your comments on the attached. The deadline for comments
> is Oct 30, 2008.

_______________________________________________

Re: draft on "Tunnel Endpoints in BGP"

On Oct 28, 2008, at 4:39 AM, Robert Raszuk wrote:

> <adding Lixia & Enke>

thanks for that, Robert.
catching up email after a very looooong trip

> Hi Paul/Xu ..
>
> This draft is just a middle step to what I and Enke Chen have been  
> working on few years back regarding tunneling to numerical  
> equivalent of 4 byte AS number IP address distributed as plain IPv4  
> address.
>
> It is also an anycast address and each ASBR if before had advertised  
> it can decapsulate packets to it and switch internally. It has a  
> number of nice properties as ASBR failures are not fatal and can be  
> repaired by closed by peering ASes. It also have the drawbacks of in  
> the simple case of one IP address per as not flexible peering BGP TE.
>
> I think this is important to take step back at this point as this is  
> also very much along the lines of APT approach Lixia and her team  
> from UCLA are driving into.

- The APT team is a collaboration among Memphis, CSU, Arizona and UCLA
- Robert is exactly right that APT team has been looking into this  
direction for an evolution path towards controllable BGP table/ 
dynamics growth

Re: draft-jakma-mrai as IDR WG document.

+1

On Sun, Nov 2, 2008 at 10:24 PM, Robert Raszuk <raszuk <at> juniper.net> wrote:
> Support.
>
> Thx,
> R.
>
>> Folks,
>>
>> While so far we received no objections, the number of folks who
>> expressed their support for accepting draft-jakma-mrai is not enough
>> to justify accepting it as IDR WG document.
>>
>> With this in mind I'd like to extend the period of comments for
>> another week. If folks feel that this document should be accepted
>> as IDR WG document, please respond to this e-mail by no late than
>> Nov 10, 2008.
>>
>> Yakov.
>> ------- Forwarded Message
>>
>> Date:    Thu, 16 Oct 2008 06:07:01 -0700
>> From:    Yakov Rekhter <yakov <at> juniper.net>
>> To:      idr <at> ietf.org
>> Subject: [Idr] draft-jakma-mrai as IDR WG document.
>>
>> Folks,
>>
>> Please send your comments on the attached. The deadline for comments

Re: draft on "Tunnel Endpoints in BGP"

On Oct 28, 2008, at 6:16 AM, Robert Raszuk wrote:

> Hi Paul,
>
> I see no harm in proposing this to IDR. In fact I see no harm in a  
> lot of elements from RRG being reflushed by IDR to be accepted as wg  
> docs or as BCP docs ...
>
> To be very honest I think RRG is working on revolution. IMHO here we  
> are just about to construct an evolution bridge.

that's a very precise statement.

sorry to spam IDR list for this (though I assume many people here are  
also on RRG list): the solution direction that got more attraction  
than others in RRG is map-and-encap.  APT is one design in that  
direction, LISP is another, and much better known

Over the last year or so, and inspired by Paul Francis work (started  
with CRIO, then virtual aggregation), we saw the light that map-n- 
encap does not have to be mapping space A to space B.  Look, the basic  
goal is to control the routing table growth, so map-n-encap should  
really be about mapping a big table to a smaller one, so that the  
latter can be used for routing.
This way of thinking opens an evolutionary path to roll out map-n-encap.

> I am very happy that so many folks are seeing the same path now.

I am even happier 

Re: draft on "Tunnel Endpoints in BGP"

On Oct 28, 2008, at 6:15 AM, Paul Francis wrote:
> By the way Robert, embedded in the Mapped-BGP document is the  
> following text about policies.  Do you think this is accurate?
>
>    We can divide policies into two types: policies that act at the
>    granularity of ASes, and those that act at the granularity of
>    prefixes.  AS-level policies are preserved in Mapped-BGP, because
>    these policies can be applied to TE-routes (of which there are,
>    roughly, one per AS).  Indeed, AS-granularity policies become  
> cheaper
>    to enact, because there are fewer routes to deal with.  Examples of
>    AS-based policies are: prefer routes to customers over other  
> routes.
>    Prefer routes to peers over routes to providers.  Do not export
>    routes received from peers to non-customers.
>
>    Most policies that act at the granularity of prefixes are for the
>    purpose of traffic engineering.  There are a number of such  
> examples.
>    For instance, one ISP may give per-prefex MEDs to its neighbor in
>    order to influence how packets enter each peering point.  This  
> may be
>    done either for the purpose of load balance, or in order to  
> minimize
>    the distance that packets need to travel within the receiving ISP.
>    Likewise an ISP might set loc-prefs on a per prefix basis to
>    influence the outgoing load on each peering point.  A multi-homed
>    site might deaggregate its prefix, and then use community  
> attributes
>    offered by its provider to do per-prefix path prepending or route

Re: draft-jakma-mrai as IDR WG document.

I support this draft to be a working group draft.
-Samita

> -----Original Message-----
> From: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] On Behalf Of Paul
> Jakma
> Sent: Tuesday, October 21, 2008 7:03 AM
> To: Inter-Domain Routing List
> Subject: Re: [Idr] draft-jakma-mrai as IDR WG document.
> 
> Hi,
> 
> Thanks to some comments received, I have added some clarifications to the
> document, and changed the 5s recommendation to "5s or less", for eBGP
MRAI.
> 
> Please see:
> 
> http://www.ietf.org/internet-drafts/draft-jakma-mrai-01.txt
> 
> regards,
> --
> Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
> Fortune:
> Aim for the moon.  If you miss, you may hit a star.
>  		-- W. Clement Stone
> _______________________________________________
> Idr mailing list
> Idr <at> ietf.org
> https://www.ietf.org/mailman/listinfo/idr

I-D Action:draft-ietf-idr-bgp4-mibv2-08.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           : Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version
	Author(s)       : J. Haas
	Filename        : draft-ietf-idr-bgp4-mibv2-08.txt
	Pages           : 46
	Date            : 2008-11-02

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols.  In particular it defines
objects for managing the Border Gateway Protocol, Version 4.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-08.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

Re: draft-jakma-mrai as IDR WG document.

On Sun, Nov 02, 2008 at 07:31:30AM -0800, Yakov Rekhter wrote:
> With this in mind I'd like to extend the period of comments for
> another week. If folks feel that this document should be accepted
> as IDR WG document, please respond to this e-mail by no late than
> Nov 10, 2008.

I'd like to express my reservations with this document.

I believe, in general, that we could lower MRAI and this would have good
benefits on convergence.

I also believe that various entities such as RIPE are basically telling
people "flap damping is likely bad and you should probably turn it off."
However, many people may still have defaults that would only have
damping exacerbated by these lower timers.

I was somewhat disappointed when previous language regarding what's
being called WRATE in the draft wasn't included in RFC 4271.  I believe
we can get most of the benefits of faster pruning of non-viable paths by
not limiting withdrawals with MRAI.  This would reduce overall churn of
paths that appear viable but are actually just waiting for a withdrawal
to show up.

So... I hear Yakov asking again, "Do you support this?"

In it's current form, no.  I'd love to see a different version
recommending WRATE and perhaps a modestly lower MRAI.

-- Jeff
_______________________________________________