Re: [IETFMIBS] SNMP bgpPeerTable IPV6

On Fri, Jul 30, 2010 at 02:29:19PM +0200, Simon Leinen wrote:
> The I-D has been active (growing and shrinking) over at least nine
> years: draft-ietf-idr-bgp4-mibv2-00 is from July 2001.  Since I cannot
> currently follow the IDR WG, I don't know what's holding it up right now.

There were several issues early on in its development:
- Requirements churn.  The original request was to bring "configurability"
  to the MIB.  You should find that several of the initial drafts thrashed
  around configuration objects.  Those were dropped ultimately due to both
  lack of support for it as a feature and resistance from implementors who
  simply didn't want writeable objects in the MIB.
- Structural representations with regard to BGP features that were lists of
  objects.  The usual example that tends to come up for this are
  communities.  The only way to represent communities in a human-readable
  format is to break them out into a separate table that has a loose
  relationship to the underlying path attributes table.  This is
  operationally unusable.  

  This particular issue drove me to eventually request the routing and OPS
  area to request MIB implementors to stop trying to put complex structural
  encodings in MIBs.  There was, IMO, very broad support for this action.
  The OPS groups at the time recognized that they needed to find a better
  representational mechanism.  I believe netconf/netmod was the general
  direction such things were pushed.

The MIB has been structurally stable for a while and is simply waiting for
implementations.  I have had one 95% done in Quagga for most of a few years
that I simply need to clean up and publish.  (And yes, I do recognize the
push I've gotten from several individuals in the last year to publish that
code.  I've simply had other life priorities.)

Re: draft-uttaro-idr-add-paths-guidelines-02

Uli, Martin,

Thanks for your input.

What do you mean by "generally improve consistency" ? I'm not sure about which 
consistency we're talking about.

Regarding the new proposed mode, we'll provide its analysis under the terms of 
the draft, to the ML, and based on feedback consider it for inclusion in the draft.

Regards,

Pierre.

Uli Bornhauser wrote:
> Hi Pierre, all,
> 
> as we discussed yesterday, my thoughts and remarks with respect to the draft version:
> 
> In section 4.2, the authors mention that receiving multiple paths improves convergence (cf. MED/IGP
oscillation section) and Expressiveness (cf. Path optimality section). At this point, you could also
mention that path diversity generally improves the consistency. As far as I see, this pro-argument is not
covered by the remarks.
> 
> With respect to the Path Selection Modes, cf. section 4.3.1: After reading the draft, it seems reasonable
to say that the mode described in section 4.3.1.5,
> 
> "Advertising Neighbor-AS Group Best Path", is a natural generalization of the common best path
advertisement to all neighbor-AS groups.

Re: draft-uttaro-idr-add-paths-guidelines-02

Hi Pierre, 

sorry for the delay.

Am 01.08.2010 um 21:33 schrieb Pierre Francois:

> What do you mean by "generally improve consistency" ? I'm not sure about which consistency we're talking about.

I am thinking of consistency in the sense of avoiding deflection and loops (which result from inconsistent
local views). By realizing path diversity, it becomes more likely that routers are aware of the same
(important) routing information, resulting in an increased probability for consistent routing decisions.

A very simple example may be found in [1], page 11, figure 14.

Regards

Uli

[1]
Timothy Griffin and Gordon T. Wilfong.
On the Correctness of IBGP Configuration.
SIGCOMM Comput. Commun. Rev., 32(4):17–29, August 2002.

--

-- 
_______________________________________________________
ULI BORNHAUSER
University of Bonn - Institute of Computer Science IV
c/o Bonn-Aachen International Center for Information Technology B-IT 
Dahlmannstr. 2 - D-53113 Bonn - Germany

Re: draft-uttaro-idr-add-paths-guidelines-02

Uli,

Uli Bornhauser wrote:
> Hi Pierre, 
> 
> sorry for the delay.

No problem.

If it's about avoiding deflection and loops, wouldn't you be pro
"AS Wide best + next best" in guidelines-02, or the variant described below ?

I'm failing to see what other gain you would get from advertising the additional 
paths as in [1] that you wouldn't find with one of these 2 modes.

Advertise Double AS Wide Best Paths

This variant of "Advertise AS Wide Best Paths" trades-off the number
of paths being propagated within the iBGP system for post-convergence
alternate paths availability and routing stability. A BGP speaker
running this mode will select for advertisement its AS Wide Best
paths, plus all the AS Wide Best paths obtained when removing the
first ones from consideration.

Under this mode, a BGP speaker knows multiple AS-Wide best paths or
the AS-Wide best path and all the second AS-Wide best paths, so
that routing optimality and backup path availability are ensured. Note that the
post-convergence paths will be known by each BGP node in an AS
supporting this mode.

Re: draft-uttaro-idr-add-paths-guidelines-02

Hi Pierre,

Am 04.08.2010 um 18:02 schrieb Pierre Francois:

> 
> Uli,
> 
> Uli Bornhauser wrote:
>> Hi Pierre, sorry for the delay.
> 
> No problem.
> 
> If it's about avoiding deflection and loops, wouldn't you be pro
> "AS Wide best + next best" in guidelines-02, or the variant described below ?
> 
> I'm failing to see what other gain you would get from advertising the additional paths as in [1] that you
wouldn't find with one of these 2 modes.

This seems to be a misunderstanding.
I only wanted to suggest to add the statement that path diversity helps to improve consistency within an AS
in section 3, Add-Paths Applications; it helps to avoid loops and deflection. This is an add-path
application the drafts does not mention so far.
"Advertise All AS-Wide Best Paths Plus Next-Best" is fine to reach this. With the reference to [1], I did not
want to suggest a(n) new/other mode. I only what to give you an example where "Advertise All AS-Wide Best
Paths Plus Next-Best" (and a lot of other modes the drafts proposed) helps to get consistent views.
So, no new mode, only another add-path application for the described modes.

Independently, I think that "Advertising Neighbor-AS Group Best External Path" as described in my email
of 2010-07-29 could be another mentionable concept.

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

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-02.txt

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

Re: draft-uttaro-idr-add-paths-guidelines-02

Uli,

Got it.

We will modify the draft accordingly, thanks for your input.

Pierre.

Uli Bornhauser wrote:
> Hi Pierre,
> 
> Am 04.08.2010 um 18:02 schrieb Pierre Francois:
> 
>> Uli,
>>
>> Uli Bornhauser wrote:
>>> Hi Pierre, sorry for the delay.
>> No problem.
>>
>> If it's about avoiding deflection and loops, wouldn't you be pro
>> "AS Wide best + next best" in guidelines-02, or the variant described below ?
>>
>> I'm failing to see what other gain you would get from advertising the additional paths as in [1] that you
wouldn't find with one of these 2 modes.
> 
> This seems to be a misunderstanding.
> I only wanted to suggest to add the statement that path diversity helps to improve consistency within an AS
in section 3, Add-Paths Applications; it helps to avoid loops and deflection. This is an add-path
application the drafts does not mention so far.

I-D Action:draft-ietf-idr-add-paths-04.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 Multiple Paths in BGP
	Author(s)       : D. Walton, et al.
	Filename        : draft-ietf-idr-add-paths-04.txt
	Pages           : 8
	Date            : 2010-08-09

In this document we propose a BGP extension that allows the
advertisement of multiple paths for the same address prefix without
the new paths implicitly replacing any previous ones.  The essence of
the extension is that each path is identified by a path identifier in
addition to the address prefix.

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

Re: Asking for adoption of draft-dong-idr-fsm-subcode-01 as a WGdocument

I Support.

Regards,
Ananth

> We would liketo ask for adoption of draft-dong-idr-fsm-subcode-01 as a WG
> document.
>
> The URL is: [1]http://tools.ietf.org/html/draft-dong-idr-fsm-subcode-01
>
> Best Regards,
> Jie & Mach

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

I-D Action:draft-ietf-idr-bgp-issues-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           : Issues in Revising BGP-4 (RFC1771 to RFC4271)
	Author(s)       : A. Lange
	Filename        : draft-ietf-idr-bgp-issues-03.txt
	Pages           : 170
	Date            : 2010-08-16

This document records the issues discussed and the consensus reached
in the Interdomain Routing (IDR) Working Group during its efforts to
revise and bring up to date the base specification for the BGP-4
protocol as documented in RFC1771.  The results of these efforts are
encoded in RFC4271.

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