IETF-80 agenda topics

Folks,

We're planning to meet at IETF-80.  On the draft agenda we are scheduled for Thursday, March 31 13:00 - 15:00. 
Please forward any IDR agenda items you might have to Sue and myself.  The deadline is two weeks from now --
March 15, 2011 by 13:00 U.S. Eastern Time.  I apologize for the tardy call for topics!

If you plan to make a presentation, please keep in mind the IDR tradition, "no Internet Draft - no time slot". 
You should also plan to send your slides to Sue and me no later than 24 hours prior to the meeting.

--John & Sue

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

I-D Action:draft-ietf-idr-best-external-03.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           : Advertisement of the best external route in BGP
	Author(s)       : P. Marques, et al.
	Filename        : draft-ietf-idr-best-external-03.txt
	Pages           : 11
	Date            : 2011-03-08

The base BGP specifications prevent a BGP speaker from advertising
any route that is not the best route for a BGP destination.  This
document specifies a modification of this rule.  Routes are divided
into two categories, "external" and "internal".  A specification is
provided for choosing a "best external route" (for a particular value
of the Network Layer Reachability Information).  A BGP speaker is
then allowed to advertise its "best external route" to its internal
BGP peers, even if that is not the best route for the destination.
The document explains why advertising the best external route can
improve convergence time without causing routing loops.  Additional
benefits include reduction of inter-domain churn and avoidance of
permanent route oscillation.  The document also generalizes the
notions of "internal" and "external" so that they can be applied to
Route Reflector Clusters and Autonomous System Confederations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-best-external-03.txt

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

Re: Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01

Support this work.

Jie

> -----Original Message-----
> From: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] On Behalf Of Colin
> Petrie
> Sent: Wednesday, February 23, 2011 5:25 PM
> To: idr <at> ietf.org
> Cc: grow <at> ietf.org
> Subject: Re: [Idr] Fwd: New Version Notification for
> draft-shakir-idr-ops-reqs-for-bgp-error-handling-01
> 
> On 22/02/11 14:50, Neil J. McRae wrote:
> > Rob,
> > This is a great document and as a network operator I think this is
> > something that I'd like to see implemented. The downsides of a minute
> > inconsistency are not great enough compared to a complete BGP failure
> with
> > my organisations network*
> >
> 
> I totally agree. This document is a pretty good summary of the
> requirements on this, and a reasonable suggested implementation to
> mitigate the problems we have seen before too many times.
> 
> Great work, thanks Rob :)
> 
> Cheers
> Colin

I-D Action:draft-ietf-idr-link-bandwidth-02.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 Link Bandwidth Extended Community
	Author(s)       : P. Mohapatra, R. Fernando
	Filename        : draft-ietf-idr-link-bandwidth-02.txt
	Pages           : 5
	Date            : 2011-03-09

This document describes an application of BGP extended communities
that allows a router to perform unequal cost load balancing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-link-bandwidth-02.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

draft-ietf-idr-reserved-extended-communities

Eric, all,

> From: DECRAENE Bruno 
> Sent: Monday, November 15, 2010 7:05 PM
> Subject: RE: [Idr] draft-decraene-idr-reserved-extended-communities-00
[...] 

> > I also think it's confusing to call these extended communities
"reserved",
> > as RFC 5226 ("Guidelines for Writing IANA Considerations") defines
the term
> > "reserved" as meaning "not to be assigned".
> 
> We can use a different name. Would you have any proposition?
> 

We could propose to use the name "Assigned extended communities". This
seems valid according to RFC 5226 (Guidelines for Writing an IANA
Considerations Section in RFCs point of view): "The binding or
association of a specific value with a particular purpose within a
namespace is called an assigned number (or assigned value, or sometimes
a "code point", "protocol constant", or "protocol parameter").  Each
assignment of a value in a namespace is called a registration"

Would this be fine for you? / Any comment on this proposition?

In the absence of any objections within the next two weeks I'll issue a
revised version which reflects the above proposition.

Thanks,

I-D Action:draft-ietf-idr-fsm-subcode-01.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           : Subcodes for BGP Finite State Machine Error
	Author(s)       : J. Dong, M. Chen
	Filename        : draft-ietf-idr-fsm-subcode-01.txt
	Pages           : 5
	Date            : 2011-03-14

This document defines several subcodes for BGP Finite State Machine 
Error that could provide more information to help network operators 
in diagnosing BGP FSM issues and correlating network events.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-fsm-subcode-01.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

draft-ymbk-bgp-extended-messages-01

Hi,

I would like to propose an amendment to the below document:

Title : Extended Message support for BGP
http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01

The document increases the max message size of BGP from 4096 octets to 
65535 octets. I agree that this is a good general idea.

However it follows the same notion as base spec and defines single max 
message size for all possible types of BGP messages.

As it has been previously recognized during WG meetings as well as on 
the list there are number of legitimate cases where during an error 
condition (for example: malformed UPDATE Msg, malformed BGP Attribute 
within UPDATE Msg etc ...) we should maintain a session's liveness while 
in the same time report the error condition to a peer.

Within the BGP build-in reporting facilities some operators found it 
valuable to be able to include the entire malformed UPDATE message to 
the peer who generated it to increase the awareness of the problem at 
hand as well as speed up the troubleshooting process.

This will be only possible if we differentiate maximum size of BGP 
UPDATE Massage to be less then any other BGP message's maximum size to 
allow room for a new message header. For all practical purposes it seems 
sufficient to allow the header size of 128 octets.

I welcome comments and opinions on the proposed above BGP messages size 

Fwd: New Version Notification for draft-jasinska-ix-bgp-route-server-02

Hi,

this in an updated version of draft-jasinska-ix-bgp-route-server-01. As
proposed at the last meeting, we split the document into two, separating
operational and standards track content.

The document posted with this email,
draft-jasinska-ix-bgp-route-server-02, includes the standards track
part: specification and protocol related considerations.

Feedback would be much appreciated!

Thanks and best regards
Elisa

-------- Original Message --------
Subject: New Version Notification for
draft-jasinska-ix-bgp-route-server-02
Date: Mon, 14 Mar 2011 16:29:33 -0700
From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
To: elisa <at> llnw.com
CC: nick <at> inex.ie,raszuk <at> cisco.com,niels.bakker <at> ams-ix.net

A new version of I-D, draft-jasinska-ix-bgp-route-server-02.txt has been
successfully submitted by Elisa Jasinska and posted to the IETF repository.

Filename:	 draft-jasinska-ix-bgp-route-server
Revision:	 02
Title:		 Internet Exchange Route Server
Creation_date:	 2011-03-15

Re: draft-ymbk-bgp-extended-messages-01 (length)

--------------------------------------------------
> The document increases the max message size of BGP from 4096 octets to 
> 65535 octets. I agree that this is a good general idea.
>
[...]
> This will be only possible if we differentiate maximum size of BGP UPDATE 
> Massage to be less then any other BGP message's maximum size to allow room 
> for a new message header. For all practical purposes it seems sufficient 
> to allow the header size of 128 octets.
>

From operator's perspective ability to return complete UPDATE message inside 
a diagnostic message is essential. So I support the proposal of limiting 
UPDATE Message length to something smaller than general MAX_SIZE. Whether it 
should be less by 128 octects or by some other value I'm not yet sure.

Kind regards,
iLya 

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

Re: draft-ymbk-bgp-extended-messages-01 (capability code)

--------------------------------------------------
> Title : Extended Message support for BGP
> http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01
>

Section 2 reads: "...This is an asymmetric capability.  I.e. one speaker 
could signal the capability and the other not..".

If one side does not signal capability then it may not prepared to receive 
messages longer than original specification dictates. In other words, even 
for asymmetric flow of big (>4096) messages both sides need to have support 
and announce that. Perhaps having 'receive' and 'send' flags in capability 
value and requiring each side to advertise new capability would be better 
approach than sending big messages to a speaker that didn't advertise 
'extended messages' capability.

Kind regards,
iLya 

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