headers
Joan Cucchiara | 5 Jul 02:52
Picon

Re: Early MIB Dr. Review of draft-ietf-idr-bgp4-mibv2-06.txt


Hi Jeff,

First want to apologize for the delay in responding.
I have deleted the parts of the email where we have agreed.
See inline below for more discussion.

Thanks,
  Joan

----- Original Message ----- 
From: "Jeffrey Haas" <jhaas <at> pfrc.org>
To: "Joan Cucchiara" <jcucchiara <at> mindspring.com>
Cc: "Jeffrey Haas" <jhaas <at> pfrc.org>; "Dan Romascanu (E-mail)" 
<dromasca <at> avaya.com>; "David

Ward" <dward <at> cisco.com>; <idr <at> ietf.org>; "MIB Doctors (E-mail)" 
<mib-doctors <at> ietf.org>
Sent: Tuesday, June 10, 2008 10:29 PM
Subject: Re: Early MIB Dr. Review of draft-ietf-idr-bgp4-mibv2-06.txt

>>>> E: f(BGP4-MIB), (1228,5) Item "bgpNlriPrefixType" has invalid
>>>> value for MAX-ACCESS
>>
>> This is not listed in the INDEX clause and it has a MAX-ACCESS of
>> "not-accessible".    Is this supposed to be part of the INDEX?  If not,
>> then it should have a different type of MAX-ACCESS.
>
> I've made this read-only and added it to the bgpAfPathAttributesGroup
> OBJECT-GROUP.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jeffrey Haas | 7 Jul 03:50

Configuration objects in BGP MIB v2: Call for consenus

Working Group,

Back around 2005 I had a number of discussions with people who had
provided input for the BGP MIBv2 work.  These conversations were
specifically regarding the configuration objects in the MIB.
draft-ietf-idr-bgp4-mibv2-05 was the last version of the MIB that
contained the proposed configuration objects.

The results of those discussions were effectively that the configuration
mechanisms in that MIB were too complex and had some potential issues.
In particular:

- Modern BGP implementations tend to be more complex than the feature
  set covered by the proposed MIBs.  It was not possible to
  configure all session specific features from the MIB.  Since the base
  MIB is not intended to cover all possible current and future features
  this is problematic.
- Configuration of peering sessions are not sufficient to fully
  implement BGP in an operational network.  BGP fundamentally requires
  policy for the population of the Ribs.  Policy elements and algebra
  vary considerably among vendors.  

  Providing a general policy engine for BGP in the MIB is likely out of
  scope of this work.

Presume that the structural issues from draft-05 may be addressed.
Should they be addressable, do we wish to pursue including configuration
objects in the BGP MIB?

Given the operational impact of this issue, I would appreciate it if
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jeffrey Haas | 7 Jul 04:33

RFC 1657 MIB errors/corrections

Joan,

I'm forking this particular thread regarding issues propagated from 
RFC 1657 so we can track it separately.

If someone could get Bert Wijnen and Sharon Chisholm's attention for
this thread it will help drive it to completion quicker.

Please excuse the long quoted sections ahead.

On Fri, Jul 04, 2008 at 08:52:24PM -0400, Joan Cucchiara wrote:
>>>>> W: f(BGP4-MIB), (2689,5) Table "bgpRcvdPathAttrTable" and
>>>>> Row "bgpPathAttrEntry" should have same name prefix
>>>>
>>>> This issue was previously existing for earlier versions of this MIB and
>>>> cannot be changed.
>>>>
>>>
>>> I would encourage the working group to fix these sorts of obvious 
>>> mistakes
>>> rather than carry them forward for a few reasons:
>>>
>>> 1) A great deal of this MIB is changing already so the working group may
>>> want
>>> to reconsider fixing this mistake,
>>> 2) MIB tools which generate code "might" find errors here and so 
>>> developers
>>> are left dealing with fixing these sorts of bugs by going in and editing
>>> files that are generated (usually not what we want to do).
>>> 3)  If the intention is to make this MIB one that is the basis for other
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Haas | 7 Jul 04:54

Factoring the bgpPeerAfTable in BGP MIBv2

Joan,

Forking this from the main thread for tracking:

On Fri, Jul 04, 2008 at 08:52:24PM -0400, Joan Cucchiara wrote:
> What I was thinking actually was to not separate Timer objects into
> specific "timer" tables, but to group these with their respective 
> categories
> (i.e. bgp manager instance, bgp peer, session).
>
> However, I say this assuming that there will be more separation than
> currently exists. For example, if the bgpPeerAfTable
> is observed, you have comments, Local, Remote, Session Status in one table.
> The Local refers to (I think?) what you call the "bgp manager instance",
> remote is the "peer" and session status is the "session".
> Timers could also be grouped in these categories.
>
> Taking this all a step farther, would suggest to create a
> Local (bgp manager instance table) and a remote table (which may or may not
> also include session objects).

I think you may be having a small amount of confusion regarding the
objects that constitute the indices of the peer table.

A BGP peer session is defined by a TCP connection between two BGP
speakers.  It is possible for a BGP speaker to have multiple parallel
BGP peering sessions with the same remote BGP speaker so long as the TCP
tuple is different.  See RFC 4271, Section 6.8 for the definition of a
session collision which occurs when two parallel sessions occur with the
same TCP IP address endpoints.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Haas | 7 Jul 05:24

BGP MIBv2 discontinuity objects

On Fri, Jul 04, 2008 at 08:52:24PM -0400, Joan Cucchiara wrote:
> DISCONTINUITY DISCUSSION:
>
>>    --
>>    -- Discontinuity
>>    --
>>    bgpDiscontinuityTime OBJECT-TYPE
>>        SYNTAX TimeStamp
>>        MAX-ACCESS read-only
>>        STATUS current
>>        DESCRIPTION
>>            "The value of sysUpTime at the most recent occasion at which
>>             this BGP management instance has suffered a discontinuity.
>>
>>             In particular, tables with abstract indexes such as
>>             bgpAfPathAttrIndex, bgpAsPathIndex and
>>             bgpAfPathAttrUnknownIndex are not guaranteed to contain the
>>             same data across discontinuities."
>>         ::= { bgp 13 }
>>
>
>
> If the value of the indices change
> and can be different from the objects, then what is the point of
> having the objects?

I'm not sure I understand your question.

Fundamentally, the problem is the inability of SMIv2 to represent
complex structured information.  If SMI had retained ASN.1's ability to
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Francis | 7 Jul 18:52
Picon
Favicon

draft on virtual aggregation


Gang,

At the following URL is a draft on virtual aggregation that I'm posting to
IETF (it'll show up in a day or two), and which I'll present at IDR in
Dublin.  

 http://www.cs.cornell.edu/people/francis/draft-francis-idr-intra-va-00.txt

Title and abstract are below.  I hope to create a work item on this in IDR.
I would characterize this as falling under the general charter of scaling
BGP.

Any comments and discussion on this prior to Dublin is of course greatly
appreciated.

PF

Title:  Intra-Domain Virtual Aggregation

   Virtual Aggregation (VA) is a technique for shrinking the DFZ FIB
   size in routers (both IPv4 and IPv6).  This allows ISPs to extend the
   lifetime of existing routers, and allows router vendors to build FIBs
   with much less concern about the growth of the DFZ routing table.  VA
   does not shrink the size of the RIB.  VA may be deployed autonomously
   by an ISP (cooperation between ISPs is not required).  While VA can
   be deployed without changes to existing routers, doing so requires
   significant new management tasks.  This document describes changes to
   routers and BGP that greatly simplify the operation of VA.
(Continue reading)

Permalink | Reply | 30 comments |
headers
Paul Francis | 7 Jul 22:47
Picon
Favicon

Re: draft on virtual aggregation

Its posted by IETF now.  At
http://www.ietf.org/internet-drafts/draft-francis-idr-intra-va-00.txt

PF

> -----Original Message-----
> From: Paul Francis
> Sent: Monday, July 07, 2008 12:53 PM
> To: 'idr <at> ietf.org'
> Subject: draft on virtual aggregation
> 
> 
> Gang,
> 
> At the following URL is a draft on virtual aggregation that I'm posting
> to IETF (it'll show up in a day or two), and which I'll present at IDR
> in Dublin.
> 
>  http://www.cs.cornell.edu/people/francis/draft-francis-idr-intra-va-
> 00.txt
> 
> Title and abstract are below.  I hope to create a work item on this in
> IDR.  I would characterize this as falling under the general charter of
> scaling BGP.
> 
> Any comments and discussion on this prior to Dublin is of course
> greatly appreciated.
> 
> PF
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
David Freedman | 8 Jul 15:44
Gravatar

RFC5065 - Section 5.3


Admittedly I'm a little late for this now that draft-ietf-idr-rfc3065bis
is now an RFC, but I'm unclear as to why Section 5.3 (3) states:

3) When comparing routes using AS_PATH length, CONFED_SEQUENCE and
      CONFED_SETs SHOULD NOT be counted.

I would rather have said:

When comparing routes using AS_PATH length, an implementation MAY
provide the ability to count CONFED_SEQUENCE and CONFED_SET.

Looking back through the archives, I see Ilya Varlashkin has commented
on this previously :

(http://www.nabble.com/BGP-best-path-selection-in-confederations-(draft-ietf-idr-rfc3065bis-06.txt)-td11081109.html#a11081109)

I too run a network where each subconfederation has a discrete IGP and I
do not wish them to interact, an implementation which provides the
ability to count CONFED_SEQUENCE / CONFED_SET and use this for route
comparison would be extremely useful, I do not understand why the
author(s) have used "SHOULD NOT" in this case, it seems silly.

Can somebody explain?

Regards,

David Freedman

--
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jeffrey Haas | 8 Jul 15:58

Re: RFC5065 - Section 5.3

David,

Some of this is my opinion and some my recollection of the events at the
time.  Your mileage may vary.

On Tue, Jul 08, 2008 at 02:44:21PM +0100, David Freedman wrote:
> I would rather have said:
> 
> When comparing routes using AS_PATH length, an implementation MAY
> provide the ability to count CONFED_SEQUENCE and CONFED_SET.
> 
> 
> Looking back through the archives, I see Ilya Varlashkin has commented
> on this previously :

And a few other people, including me.

There is nothing stopping a vendor from providing a knob to accomplish
this very feature.  However, as with everything else regarding BGP path
selection, the important thing is that route selection is done
consistently AS-wide.  As long as that is the case, you can do pretty
much anything you like.

The more widely deployed implementations of BGP ignored confederation
segment length as part of its route selection by default.  Thus this
became somewhat a matter of doing what the big vendors did.

The language thus was written to heavily favor interoperability over
flexibility.  This avoids having to discuss the picky issues of
consistent route selection across the AS within a specific extension.
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Freedman | 8 Jul 16:25
Gravatar

Re: RFC5065 - Section 5.3


> 
> There is nothing stopping a vendor from providing a knob to accomplish
> this very feature.  

Other than the RFC is now explicit about this behaviour (where RFC3065
was not previously).

> The language thus was written to heavily favor interoperability over
> flexibility.  This avoids having to discuss the picky issues of
> consistent route selection across the AS within a specific extension.

Thanks, I do indeed understand but believe it makes it harder now to
convince vendors to "enhance" implementations now that there is an
explicit "SHOULD NOT"

Dave.

> 
> -- Jeff

--
David Freedman
Group Network Engineering
Claranet Limited
http://www.clara.net
Permalink | Reply | 2 comments |

Gmane