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
- [Idr] Early MIB Dr. Review of draft-ietf-idr-bgp4… Joan Cucchiara
- Re: [Idr] Early MIB Dr. Review of draft-ietf-idr-… Jeffrey Haas
- Re: [Idr] Early MIB Dr. Review of draft-ietf-idr-… Joan Cucchiara
- Re: [Idr] Early MIB Dr. Review of draft-ietf-idr-… tom.petch
- Re: [Idr] Early MIB Dr. Review of draft-ietf-idr-… Jeffrey Haas
- Re: [Idr] Early MIB Dr. Review of draft-ietf-idr-… tom.petch
- Re: [Idr] Early MIB Dr. Review of draft-ietf-idr-… Jeffrey Haas
- Re: [Idr] Early MIB Dr. Review of draft-ietf-idr-… Joan Cucchiara
- [Idr] RFC 1657 MIB errors/corrections Jeffrey Haas
- [Idr] Factoring the bgpPeerAfTable in BGP MIBv2 Jeffrey Haas
- [Idr] BGP MIBv2 discontinuity objects Jeffrey Haas
- Re: [Idr] BGP MIBv2 discontinuity objects Joan Cucchiara
- Re: [Idr] BGP MIBv2 discontinuity objects Jeffrey Haas
- Re: [Idr] BGP MIBv2 discontinuity objects Joan Cucchiara
- Re: [Idr] [MIB-DOCTORS] BGP MIBv2 discontinuity o… Jeffrey Haas
- Re: [Idr] [MIB-DOCTORS] BGP MIBv2 discontinuity o… Jeffrey Haas
- Re: [Idr] BGP MIBv2 discontinuity objects Jeffrey Haas