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

Jeffrey Haas <jhaas@pfrc.org> Wed, 14 May 2008 14:16 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC083A68F4; Wed, 14 May 2008 07:16:18 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF673A68F4 for <idr@core3.amsl.com>; Wed, 14 May 2008 07:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM9UTsn9ZtJj for <idr@core3.amsl.com>; Wed, 14 May 2008 07:16:14 -0700 (PDT)
Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id A972F3A67D0 for <idr@ietf.org>; Wed, 14 May 2008 07:16:14 -0700 (PDT)
Received: by manos.scc.mi.org (Postfix, from userid 1025) id 4DF044E4A4; Wed, 14 May 2008 10:15:32 -0400 (EDT)
Date: Wed, 14 May 2008 10:15:32 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "tom.petch" <cfinss@dial.pipex.com>
Message-ID: <20080514141532.GA12883@scc.mi.org>
References: <06f701c88b5b$22622000$6601a8c0@JoanPC> <20080503223750.GG23560@scc.mi.org> <006b01c8b5a6$e92b8080$0601a8c0@allison>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <006b01c8b5a6$e92b8080$0601a8c0@allison>
User-Agent: Mutt/1.5.9i
Cc: idr@ietf.org
Subject: Re: [Idr] Early MIB Dr. Review of draft-ietf-idr-bgp4-mibv2-06.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Tom,

On Wed, May 14, 2008 at 11:41:15AM +0200, tom.petch wrote:
> Jeff
> 
> As far as I can see, there is but one place where working group feedback is
> requested and that is for
> > 5) InetAddress/InetAddressType
> but I am unclear what point you are asking about:-(

Specifically:

> OBJECT bgpPeerAfLocalAddr                                                     
> SYNTAX InetAddress (SIZE(4|16|20))                                            
> DESCRIPTION                                                                   
>     "An implementation is required to support IPv4 peering                    
>      sessions.  An implementation MAY support IPv6 peering                    
>      sessions.  IPv6 link-local peering sessions MAY                          
>      supported by this MIB."                                                  
>                                                                               
> The reason for this wording is that we've never come to proper
> consensus      
> about ipv6-only routers.  

I don't have any issues with moving the sizes into the conformance
statements.  My question specifically is about what we'd require in the MIB
for peering session support.

The BGP-4 spec pretty much says you're going to have your peering
sessions via TCP on IPv4.

We know you can do IPv6-only peering sessions.  Further, there has been
some experimentation (largely related to IXes I think) that were IPv6
link local only peering.

The above language is intended to say:
1) You must support IPv4 peering sessions.

I think this is implied by the BGP-4 spec.  However, that might be
inconsistent at a later date by people who have IPv6 only routers.  This
is, admittedly, looking far into the future.

2) You can support IPv6 peering sessions.  That's not really called out
in any specific spec but is bourne out by operational practice.  I don't
believe this is controversial.  However, the working group may not want
this in the MIB.  

3) You can support IPv6 link local peering sessions.  The only draft
that I remember on the topic is long expired.  There were some
operational details that weren't controversial but do have impact on 
RFC 2545 behaviors.  The working group may choose to say "no, we don't
want this in the MIB at all".

> Tom Petch

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