From Adrian.Farrel@huawei.com Wed Apr 6 02:59:05 2011 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97EC728C105 for ; Wed, 6 Apr 2011 02:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.266 X-Spam-Level: X-Spam-Status: No, score=-104.266 tagged_above=-999 required=5 tests=[AWL=1.714, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] 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 TMxev5upU+jQ for ; Wed, 6 Apr 2011 02:59:04 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 7DDD43A68E6 for ; Wed, 6 Apr 2011 02:59:04 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ80084K6HBL8@usaga03-in.huawei.com> for vrrp@ietf.org; Wed, 06 Apr 2011 05:00:48 -0500 (CDT) Received: from 950129200 (28.Red-213-96-54.staticIP.rima-tde.net [213.96.54.28]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJ800DYD6H85X@usaga03-in.huawei.com> for vrrp@ietf.org; Wed, 06 Apr 2011 05:00:47 -0500 (CDT) Date: Wed, 06 Apr 2011 12:00:46 +0200 From: Adrian Farrel In-reply-to: <9FFC3234F1B7F0439C9B8BF94A83F48215326C4534@USEXCHANGE.ad.checkpoint.com> To: "'Kalyan (Srinivas)Tata'" , draft-ietf-vrrp-unified-mib@tools.ietf.org Message-id: <02d901cbf441$81427960$83c76c20$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQJpH+xhvhccnkER8FVizp8VUMATpQHheBPtkwcshlA= References: <00a701cbaf6b$6dfdc460$49f94d20$@huawei.com> <9FFC3234F1B7F0439C9B8BF94A83F48215326C4534@USEXCHANGE.ad.checkpoint.com> Cc: vrrp-chairs@tools.ietf.org, vrrp@ietf.org Subject: Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 09:59:05 -0000 Hi, Sorry for the delay around the IETF meeting. All agreed with a small suggestion around RFC 3413 > Thanks again for the review - I made most of the changes suggested by you - I > listed some of the changes for any comments & > I have couple of questions/clarifications inline: > >> Creation and deletion of a vrrpv3OperationsTable row > > [kalyan>>>] This is what i have based on your suggestions. Please comment if this > looks OK > > vrrpv3OperationsEntry OBJECT-TYPE > SYNTAX Vrrpv3OperationsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in the vrrpv3OperationsTable containing the > operational characteristics of a virtual router. On a > VRRP router, a given virtual router is identified by a > combination of ifIndex, VRID and the IP version. > ifIndex represents a interface of the router. > > A row must be created with vrrpv3OperationsStatus > set to initialize(1) and cannot transition to > backup(2) or master(3) until vrrpv3OperationsRowStatus > is transitioned to active(1). > > The information in this table is persistent and when > written the entity SHOULD save the change to non- > volatile storage." > > INDEX { ifIndex, vrrpv3OperationsVrId, > vrrpv3OperationsInetAddrType > } > ::= { vrrpv3OperationsTable 1 } > > ======================================= > vrrpv3OperationsRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The RowStatus variable should be used in accordance to > installation and removal conventions for conceptual > rows. > > To create a row in this table, a manager sets this > object to either createAndGo(4) or createAndWait(5). > Until instances of all corresponding columns are > appropriately configured, the value of the > Corresponding instance of the > `vrrpv3OperationsRowStatus' column will be read as > notReady(3). > > In particular, a newly created row cannot be made > active(1) until (minimally) the corresponding instance > of vrrpv3OperationsInetAddrType, vrrpv3OperationsVrId > and vrrpv3OperationsPrimaryIpAddr has been set and > there is at least one active row in the > `vrrpv3AssociatedIpAddrTable' defining an associated > IP address. > > notInService(2) should be used to administratively > bring the row down. > > A typical order of operation to add a row is: > 1. Create a row in vrrpv3OperationsTable with > createAndWait(5). > 2. Create one or more corresponding rows in > vrrpv3AssociatedIpAddrTable. > 3. Populate the vrrpv3OperationsEntry. > 4. set vrrpv3OperationsRowStatus to active(1). > > A typical order of operation to delete an entry is: > 1. Set vrrpv3OperationsRowStatus to notInService(2). > 2. Set the corresponding rows in > vrrpv3AssociatedIpAddrTable to destroy(6) to delete the > entry. > 3. set vrrpv3OperationsRowStatus to destroy(6) to > delete the entry." > ::= { vrrpv3OperationsEntry 13 } Looks good. >> vrrpv3AssociatedIpAddr >> >> You should add a statement the description that says that the content >> of the object is to be interpreted in the context of the setting of >> vrrpv3OperationsInetAddrType in the index of this row. > > [kalyan>>>] Following is what i added : > vrrpv3AssociatedIpAddrAddress OBJECT-TYPE > SYNTAX InetAddress (SIZE (0|4|16)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The assigned IP addresses that a virtual router is > responsible for backing up. > > The IP address type is determined by the value of > vrrpv3OperationsInetAddrType in the index of this > row" > REFERENCE " RFC 5798 " > ::= { vrrpv3AssociatedIpAddrEntry 1 } OK >> VRRP Router Statistics >> >> Do you need a discontinuity timer for the three global objects: >> - vrrpv3RouterChecksumErrors >> - vrrpv3RouterVersionErrors >> - vrrpv3RouterVrIdErrors > > [kalyan>>>] I added the following : > > vrrpv3GlobalStatisticsDiscontinuityTime OBJECT-TYPE > SYNTAX TimeStamp > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of sysUpTime on the most recent occasion at > which one of vrrpv3RouterChecksumErrors, > vrrpv3RouterVersionErrors and vrrpv3RouterVrIdErrors > suffered a discontinuity. > > If no such discontinuities have occurred since the last > re-initialization of the local management subsystem, > then this object contains a zero value." > > ::= { vrrpv3Statistics 4 } Fine >> VRRP Router Statistics >> >> In the presence of an attack or a broken router or host nearby, is it possible >> that Countr32 will not be large enough for the up-time of this router? >> >> You can choose to use Counter64 or describe wrapping conditions. > > [kalyan>>>] Changed all the statistics counters to Counter64 except for > vrrpv3StatisticsMasterTransitions Great >> vrrpv3StatisticsAdvIntervalErrors >> >> "The total number of VRRP advertisement packets >> received for which the advertisement interval is >> different than the one configured for the local virtual >> router. >> >> Can you add a reference to vrrpv3OperationsAdvInterval > > [kalyan>>>] Following is the new text i have : > > The total number of VRRP advertisement packets > received for which the advertisement interval is > different from the vrrpv3OperationsAdvInterval > configured on this virtual router. Perfect >> vrrpv3ProtoError >> >> Don't you think this is a *really* dangerous notification? >> >> If a VR is under attack or receiving packets from a faulty speaker, it >> will spew notifications. >> >> You should probably either add some thresholding objects (which is a fair >> bit of work) or a single object to turn notifications on and off (with the >> default being "off"). > > [kalyan>>>] I agree. I had a notification control object in earlier drafts but was > asked to be removed during MIB DR. review. Following is the > cut and paste of the comments: > > > > >> * vrrpTrapNewMasterCntl, vrrpTrapProtoErrorCntl > >> > >> Could notifications be generated or not, using > >> RFC3413? > >> > > [Kalyan>] Notifications could be filtered/generated using RFC3413. I added > > these to conveniently control notifications within this MIB (Based on > > request from some one on the mailing list) You suggest we get rid of these? > > > > Yes, I think that most operators would likely use rfc3413. Having this in 2 > places may create some confusion... OK, we can go with 3413 if that is what you are happy with. But I think you need a reference to 3413. - Add it to the normative references - Add it to some text early in the draft. There is not a lot of option. I suggest a new paragraph in the into saying: Notifications in this MIB module are controlled using the mechanisms defined in [RFC3413]. - Add a comment within the MIB module as: OLD -- Notification Definitions NEW -- Notification Definitions -- Notifications may be controlled using SNMP-NOTIFICATION-MIB END >> Notifications >> >> As currently specified, both of the notifications will come from the management >> agent which will identify the physical router that sourced the notification, but not >> the VR. >> >> Don't you need to add some index values to the notifications as well? > > [kalyan>>>] Good point. Added the Following to uniquely identify row in > vrrpv3OperationsTable: > > vrrpv3NewMaster NOTIFICATION-TYPE > OBJECTS { ifIndex, > vrrpv3OperationsVrId, > vrrpv3OperationsInetAddrType, > vrrpv3OperationsMasterIpAddr, > vrrpv3StatisticsNewMasterReason > } > STATUS current > DESCRIPTION > "The newMaster notification indicates that the sending > agent has transitioned to 'Master' state." > ::= { vrrpv3Notifications 1 } > > vrrpv3ProtoError NOTIFICATION-TYPE > OBJECTS { ifIndex, > vrrpv3OperationsVrId, > vrrpv3OperationsInetAddrType, > vrrpv3StatisticsProtoErrReason > } > STATUS current > DESCRIPTION > "The notification indicates that the sending agent has > encountered the protocol error indicated by > vrrpv3StatisticsProtoErrReason." > ::= { vrrpv3Notifications 2 } OK >> Section 11 >> >> Since you are obsoleting RFC 2787, is it your intention to ask IANA to deprecate >> {mib-2 68} ? > > [kalyan>>>] Yes. I added the following to IANA considerations : > > [Editor's Note (to be removed prior to publication): The IANA is > requested to assign a value for "ZZZ" under the 'mib-2' subtree > and to record the assignment in the SMI Numbers registry. When > the assignment has been made, the RFC Editor is asked to replace > "ZZZ" (here and in the MIB module) with the assigned value. > > This document obsoletes RFC 2787 and the IANA is requested to > deprecate the value 68 under 'mib-2' assigned to VRRP-MIB.] OK >> Would you please consider adding a short section on migrating from >> VRRP-MIB to VRRPV3-MIB? > > [kalyan>>>] I am not sure there is a smooth migration path from VRRP-MIB to > VRRPV3-MIB - I think we made a conscious decision that VRRV3 MIB will only > support RFC5798 and will not support earlier versions. > > The way i see it - Routers that implement RFC2338 and VRRP-MIB will > have to first migrate to RFC5798 and then make changes to > VRRP-MIB implementation to conform to VRRPv3-MIB. > > Should i mention this fact in the section? No need. Your explanation here is clear. Looking forward to seeing the revision. Cheers, Adrian From stata@checkpoint.com Wed Apr 6 11:20:07 2011 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2A928C0D6 for ; Wed, 6 Apr 2011 11:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[AWL=1.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 1X7FM9g4iq3Y for ; Wed, 6 Apr 2011 11:20:05 -0700 (PDT) Received: from us.checkpoint.com (usmail2.us.checkpoint.com [216.200.240.146]) by core3.amsl.com (Postfix) with ESMTP id 5A3F53A690A for ; Wed, 6 Apr 2011 11:20:05 -0700 (PDT) X-CheckPoint: {4D9CAF85-2-8AF0C8D8-FFFF} Received: from us-ex01.ad.checkpoint.com (us-ex01.ad.checkpoint.com [216.200.240.139]) by us.checkpoint.com (8.14.4/8.14.4) with ESMTP id p36ILGf8023236; Wed, 6 Apr 2011 11:21:16 -0700 Received: from USEXCHANGE.ad.checkpoint.com ([216.200.240.132]) by US-EX01.ad.checkpoint.com ([216.200.240.139]) with mapi; Wed, 6 Apr 2011 11:21:49 -0700 From: "Kalyan (Srinivas)Tata" To: "Adrian.Farrel@huawei.com" , "draft-ietf-vrrp-unified-mib@tools.ietf.org" Date: Wed, 6 Apr 2011 11:21:18 -0700 Thread-Topic: [VRRP] AD review of draft-ietf-vrrp-unified-mib Thread-Index: AQJpH+xhvhccnkER8FVizp8VUMATpQHheBPtkwcshlCAAJZqoA== Message-ID: <9FFC3234F1B7F0439C9B8BF94A83F48215327F3B8E@USEXCHANGE.ad.checkpoint.com> References: <00a701cbaf6b$6dfdc460$49f94d20$@huawei.com> <9FFC3234F1B7F0439C9B8BF94A83F48215326C4534@USEXCHANGE.ad.checkpoint.com> <02d901cbf441$81427960$83c76c20$@huawei.com> In-Reply-To: <02d901cbf441$81427960$83c76c20$@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "vrrp-chairs@tools.ietf.org" , "vrrp@ietf.org" Subject: Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 18:20:07 -0000 Thanks Adrian, I will have new draft ready this weekend. Thanks Kalyan -----Original Message----- From: Adrian Farrel [mailto:Adrian.Farrel@huawei.com]=20 Sent: Wednesday, April 06, 2011 3:01 AM To: Kalyan (Srinivas)Tata; draft-ietf-vrrp-unified-mib@tools.ietf.org Cc: vrrp-chairs@tools.ietf.org; vrrp@ietf.org Subject: RE: [VRRP] AD review of draft-ietf-vrrp-unified-mib Hi, Sorry for the delay around the IETF meeting. All agreed with a small suggestion around RFC 3413 > Thanks again for the review - I made most of the changes suggested by=20 > you - I listed some of the changes for any comments & I have couple of=20 > questions/clarifications inline: >=20 >> Creation and deletion of a vrrpv3OperationsTable row >=20 > [kalyan>>>] This is what i have based on your suggestions. Please=20 > comment if this > looks OK >=20 > vrrpv3OperationsEntry OBJECT-TYPE > SYNTAX Vrrpv3OperationsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in the vrrpv3OperationsTable containing the > operational characteristics of a virtual router. On a > VRRP router, a given virtual router is identified by a > combination of ifIndex, VRID and the IP version. > ifIndex represents a interface of the router. >=20 > A row must be created with vrrpv3OperationsStatus > set to initialize(1) and cannot transition to > backup(2) or master(3) until vrrpv3OperationsRowStatus > is transitioned to active(1). >=20 > The information in this table is persistent and when > written the entity SHOULD save the change to non- > volatile storage." >=20 > INDEX { ifIndex, vrrpv3OperationsVrId, > vrrpv3OperationsInetAddrType > } > ::=3D { vrrpv3OperationsTable 1 } >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > vrrpv3OperationsRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The RowStatus variable should be used in accordance to > installation and removal conventions for conceptual > rows. >=20 > To create a row in this table, a manager sets this > object to either createAndGo(4) or createAndWait(5). > Until instances of all corresponding columns are > appropriately configured, the value of the > Corresponding instance of the > `vrrpv3OperationsRowStatus' column will be read as > notReady(3). >=20 > In particular, a newly created row cannot be made > active(1) until (minimally) the corresponding instance > of vrrpv3OperationsInetAddrType, vrrpv3OperationsVrId > and vrrpv3OperationsPrimaryIpAddr has been set and > there is at least one active row in the > `vrrpv3AssociatedIpAddrTable' defining an associated > IP address. >=20 > notInService(2) should be used to administratively > bring the row down. >=20 > A typical order of operation to add a row is: > 1. Create a row in vrrpv3OperationsTable with > createAndWait(5). > 2. Create one or more corresponding rows in > vrrpv3AssociatedIpAddrTable. > 3. Populate the vrrpv3OperationsEntry. > 4. set vrrpv3OperationsRowStatus to active(1). >=20 > A typical order of operation to delete an entry is: > 1. Set vrrpv3OperationsRowStatus to notInService(2). > 2. Set the corresponding rows in > vrrpv3AssociatedIpAddrTable to destroy(6) to delete the > entry. > 3. set vrrpv3OperationsRowStatus to destroy(6) to > delete the entry." > ::=3D { vrrpv3OperationsEntry 13 } Looks good. >> vrrpv3AssociatedIpAddr >>=20 >> You should add a statement the description that says that the content=20 >> of the object is to be interpreted in the context of the setting of=20 >> vrrpv3OperationsInetAddrType in the index of this row. >=20 > [kalyan>>>] Following is what i added : > vrrpv3AssociatedIpAddrAddress OBJECT-TYPE > SYNTAX InetAddress (SIZE (0|4|16)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The assigned IP addresses that a virtual router is > responsible for backing up. >=20 > The IP address type is determined by the value of > vrrpv3OperationsInetAddrType in the index of this > row" > REFERENCE " RFC 5798 " > ::=3D { vrrpv3AssociatedIpAddrEntry 1 } OK >> VRRP Router Statistics >>=20 >> Do you need a discontinuity timer for the three global objects: >> - vrrpv3RouterChecksumErrors >> - vrrpv3RouterVersionErrors >> - vrrpv3RouterVrIdErrors >=20 > [kalyan>>>] I added the following : >=20 > vrrpv3GlobalStatisticsDiscontinuityTime OBJECT-TYPE > SYNTAX TimeStamp > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of sysUpTime on the most recent occasion at > which one of vrrpv3RouterChecksumErrors, > vrrpv3RouterVersionErrors and vrrpv3RouterVrIdErrors > suffered a discontinuity. >=20 > If no such discontinuities have occurred since the last > re-initialization of the local management subsystem, > then this object contains a zero value." >=20 > ::=3D { vrrpv3Statistics 4 } Fine >> VRRP Router Statistics >>=20 >> In the presence of an attack or a broken router or host nearby, is it possible >> that Countr32 will not be large enough for the up-time of this router? >>=20 >> You can choose to use Counter64 or describe wrapping conditions. >=20 > [kalyan>>>] Changed all the statistics counters to Counter64 except for > vrrpv3StatisticsMasterTransitions Great >> vrrpv3StatisticsAdvIntervalErrors >>=20 >> "The total number of VRRP advertisement packets >> received for which the advertisement interval is >> different than the one configured for the local virtual >> router. >>=20 >> Can you add a reference to vrrpv3OperationsAdvInterval >=20 > [kalyan>>>] Following is the new text i have : >=20 > The total number of VRRP advertisement packets > received for which the advertisement interval is > different from the vrrpv3OperationsAdvInterval > configured on this virtual router. Perfect >> vrrpv3ProtoError >>=20 >> Don't you think this is a *really* dangerous notification? >>=20 >> If a VR is under attack or receiving packets from a faulty speaker,=20 >> it will spew notifications. >>=20 >> You should probably either add some thresholding objects (which is a=20 >> fair bit of work) or a single object to turn notifications on and off=20 >> (with the default being "off"). >=20 > [kalyan>>>] I agree. I had a notification control object in earlier=20 > drafts but was > asked to be removed during MIB DR. review. Following is the cut and=20 > paste of the comments: >=20 > > > >> * vrrpTrapNewMasterCntl, vrrpTrapProtoErrorCntl > >> > >> Could notifications be generated or not, using RFC3413? > >> > > [Kalyan>] Notifications could be filtered/generated using RFC3413. I=20 > > added these to conveniently control notifications within this MIB=20 > > (Based on request from some one on the mailing list) You suggest we get= rid of these? > > >=20 > Yes, I think that most operators would likely use rfc3413. Having=20 > this in 2 places may create some confusion... OK, we can go with 3413 if that is what you are happy with. But I think you need a reference to 3413. - Add it to the normative references - Add it to some text early in the draft. There is not a lot of option. I suggest a new paragraph in the into saying: Notifications in this MIB module are controlled using the mechanisms defined in [RFC3413]. - Add a comment within the MIB module as: OLD -- Notification Definitions NEW -- Notification Definitions -- Notifications may be controlled using SNMP-NOTIFICATION-MIB END >> Notifications >>=20 >> As currently specified, both of the notifications will come from the management >> agent which will identify the physical router that sourced the=20 >> notification, but not >> the VR. >>=20 >> Don't you need to add some index values to the notifications as well? >=20 > [kalyan>>>] Good point. Added the Following to uniquely identify row=20 > in > vrrpv3OperationsTable: >=20 > vrrpv3NewMaster NOTIFICATION-TYPE > OBJECTS { ifIndex, > vrrpv3OperationsVrId, > vrrpv3OperationsInetAddrType, > vrrpv3OperationsMasterIpAddr, > vrrpv3StatisticsNewMasterReason > } > STATUS current > DESCRIPTION > "The newMaster notification indicates that the sending > agent has transitioned to 'Master' state." > ::=3D { vrrpv3Notifications 1 } >=20 > vrrpv3ProtoError NOTIFICATION-TYPE > OBJECTS { ifIndex, > vrrpv3OperationsVrId, > vrrpv3OperationsInetAddrType, > vrrpv3StatisticsProtoErrReason > } > STATUS current > DESCRIPTION > "The notification indicates that the sending agent has > encountered the protocol error indicated by > vrrpv3StatisticsProtoErrReason." > ::=3D { vrrpv3Notifications 2 } OK >> Section 11 >>=20 >> Since you are obsoleting RFC 2787, is it your intention to ask IANA=20 >> to deprecate >> {mib-2 68} ? >=20 > [kalyan>>>] Yes. I added the following to IANA considerations : >=20 > [Editor's Note (to be removed prior to publication): The IANA is > requested to assign a value for "ZZZ" under the 'mib-2' subtree > and to record the assignment in the SMI Numbers registry. When > the assignment has been made, the RFC Editor is asked to replace > "ZZZ" (here and in the MIB module) with the assigned value. >=20 > This document obsoletes RFC 2787 and the IANA is requested to > deprecate the value 68 under 'mib-2' assigned to VRRP-MIB.] OK >> Would you please consider adding a short section on migrating from=20 >> VRRP-MIB to VRRPV3-MIB? >=20 > [kalyan>>>] I am not sure there is a smooth migration path from=20 > VRRP-MIB to VRRPV3-MIB - I think we made a conscious decision that=20 > VRRV3 MIB will only support RFC5798 and will not support earlier version= s. >=20 > The way i see it - Routers that implement RFC2338 and VRRP-MIB will=20 > have to first migrate to RFC5798 and then make changes to VRRP-MIB=20 > implementation to conform to VRRPv3-MIB. >=20 > Should i mention this fact in the section? No need. Your explanation here is clear. Looking forward to seeing the revision. Cheers, Adrian Scanned by Check Point Total Security Gateway. From dr@cluenet.de Fri Apr 15 01:57:10 2011 Return-Path: X-Original-To: vrrp@ietfc.amsl.com Delivered-To: vrrp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 55708E0694 for ; Fri, 15 Apr 2011 01:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.191 X-Spam-Level: X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za3zJV1j6plu for ; Fri, 15 Apr 2011 01:57:09 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfc.amsl.com (Postfix) with ESMTP id AE08CE065A for ; Fri, 15 Apr 2011 01:57:09 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 422B8108094; Fri, 15 Apr 2011 10:57:09 +0200 (CEST) Date: Fri, 15 Apr 2011 10:57:09 +0200 From: Daniel Roesen To: vrrp@ietf.org Message-ID: <20110415085709.GA3742@srv03.cluenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [VRRP] RFC5798 requires usage of RAs? X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 08:57:10 -0000 Hi, JUNOS (Juniper router firmware) issues warnings when committing config changes, noting that RAs are not configured for an interface where VRRP for IPv6 is configured: vrrpd[15299]: %CONFLICT-0-WARNING: 'router-advertisement' is not configured for interface ge-9/2/2.662 RFC5798 states: 6.4.3. Master ... (630) ++ MUST send ND Router Advertisements for the virtual router. That makes no sense to us when RAs are generally not used on the segment, and hosts are manually configured to point to the VRRP virtual address as default gateway. We do not want to use RAs in some scenarios at all. I've found an older posting on this list, where someone raised the same question (Q-2): http://www.ietf.org/mail-archive/web/vrrp/current/msg00763.html John Cruz' answer seems to clarify, but noone seemed to have envisioned that the spec lingo actually motivates vendors to assume RAs as being mandatory when implementing VRRPv6... :-/ RFC5798 states in the introductory section about IPv6 (1.3): IPv6 hosts on a LAN will usually learn about one or more default routers by receiving Router Advertisements sent using the IPv6 Neighbor Discovery (ND) protocol [RFC4861]. Given that it says "usually", it recognizes that there are scenarios where RAs are NOT being used. Unfortunately several bits of language in the RFC doesn't reflect that, so I would like to suggest changing specifically rule 630 and section 8.2.3 to reflect no-RA scenarios. Best regards, Daniel From Internet-Drafts@ietf.org Tue Apr 26 10:15:03 2011 Return-Path: X-Original-To: vrrp@ietfa.amsl.com Delivered-To: vrrp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72A8E07FA; Tue, 26 Apr 2011 10:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0oFIqDIQ6-o; Tue, 26 Apr 2011 10:15:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DF8E07FE; Tue, 26 Apr 2011 10:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110426171502.14187.17595.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2011 10:15:02 -0700 Cc: vrrp@ietf.org Subject: [VRRP] I-D ACTION:draft-ietf-vrrp-unified-mib-09.txt X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 17:15:03 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Definitions of Managed Objects for VRRPv3 Author(s) : K. Tata Filename : draft-ietf-vrrp-unified-mib-09.txt Pages : 29 Date : 2011-04-26 This specification defines a portion of the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC 2787. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vrrp-unified-mib-09.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-vrrp-unified-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-26101318.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Wed Apr 27 16:16:02 2011 Return-Path: X-Original-To: vrrp@ietfa.amsl.com Delivered-To: vrrp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B21E07F4; Wed, 27 Apr 2011 16:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQnYjJpIW3WI; Wed, 27 Apr 2011 16:16:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4393EE0675; Wed, 27 Apr 2011 16:16:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110427231602.15482.95465.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2011 16:16:02 -0700 Cc: vrrp@ietf.org Subject: [VRRP] Last Call: (Definitions of Managed Objects for VRRPv3) to Proposed Standard X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 23:16:02 -0000 The IESG has received a request from the Virtual Router Redundancy Protocol WG (vrrp) to consider the following document: - 'Definitions of Managed Objects for VRRPv3' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-05-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-vrrp-unified-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-vrrp-unified-mib/ No IPR declarations have been submitted directly on this I-D. From stephen.nadas@ericsson.com Thu Apr 28 08:36:56 2011 Return-Path: X-Original-To: vrrp@ietfa.amsl.com Delivered-To: vrrp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B71AE070C for ; Thu, 28 Apr 2011 08:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edu4yiii7k4m for ; Thu, 28 Apr 2011 08:36:55 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0C9E0685 for ; Thu, 28 Apr 2011 08:36:55 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3SFapfP006102; Thu, 28 Apr 2011 10:36:53 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 28 Apr 2011 11:36:45 -0400 From: Stephen Nadas To: Daniel Roesen , "vrrp@ietf.org" Date: Thu, 28 Apr 2011 11:36:44 -0400 Thread-Topic: [VRRP] RFC5798 requires usage of RAs? Thread-Index: AcwFaj37M9QqFuWcSXWSfZnlCKprzgAT1/og Message-ID: <450AE4BEC513614F96969DDA34F35934192892832D@EUSAACMS0701.eamcs.ericsson.se> References: <20110415085709.GA3742@srv03.cluenet.de> In-Reply-To: <20110415085709.GA3742@srv03.cluenet.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [VRRP] RFC5798 requires usage of RAs? X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 15:36:56 -0000 Hi Daniel,=20 Sorry for the delay. I think the spec language could be better-=20 (630) etc probably should have said something more like=20 "if ND RAs are in use, MUST send ND Router Advertisements for the virtual r= outer.=20 Thanks, Steve=20 -----Original Message----- From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Dan= iel Roesen Sent: Friday, April 15, 2011 4:57 AM To: vrrp@ietf.org Subject: [VRRP] RFC5798 requires usage of RAs? Hi, JUNOS (Juniper router firmware) issues warnings when committing config chan= ges, noting that RAs are not configured for an interface where VRRP for IPv= 6 is configured: vrrpd[15299]: %CONFLICT-0-WARNING: 'router-advertisement' is not configured= for interface ge-9/2/2.662 RFC5798 states: 6.4.3. Master ... (630) ++ MUST send ND Router Advertisements for the virtual router. That makes no sense to us when RAs are generally not used on the segment, a= nd hosts are manually configured to point to the VRRP virtual address as de= fault gateway. We do not want to use RAs in some scenarios at all. I've found an older posting on this list, where someone raised the same que= stion (Q-2): http://www.ietf.org/mail-archive/web/vrrp/current/msg00763.html John Cruz' answer seems to clarify, but noone seemed to have envisioned tha= t the spec lingo actually motivates vendors to assume RAs as being mandator= y when implementing VRRPv6... :-/ RFC5798 states in the introductory section about IPv6 (1.3): IPv6 hosts on a LAN will usually learn about one or more default routers by receiving Router Advertisements sent using the IPv6 Neighbor Discovery (ND) protocol [RFC4861]. Given that it says "usually", it recognizes that there are scenarios where = RAs are NOT being used. Unfortunately several bits of language in the RFC d= oesn't reflect that, so I would like to suggest changing specifically rule = 630 and section 8.2.3 to reflect no-RA scenarios. Best regards, Daniel _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From Adrian.Farrel@huawei.com Thu Apr 28 10:00:04 2011 Return-Path: X-Original-To: vrrp@ietfa.amsl.com Delivered-To: vrrp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D62E0670 for ; Thu, 28 Apr 2011 10:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.742 X-Spam-Level: X-Spam-Status: No, score=-105.742 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP5jOrwJJAPU for ; Thu, 28 Apr 2011 10:00:03 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfa.amsl.com (Postfix) with ESMTP id 98953E06D7 for ; Thu, 28 Apr 2011 10:00:03 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKD008YVGK2NH@usaga03-in.huawei.com> for vrrp@ietf.org; Thu, 28 Apr 2011 12:00:02 -0500 (CDT) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKD0080CGK01F@usaga03-in.huawei.com> for vrrp@ietf.org; Thu, 28 Apr 2011 12:00:02 -0500 (CDT) Date: Thu, 28 Apr 2011 17:59:59 +0100 From: Adrian Farrel In-reply-to: <4DB989B2.4050006@joelhalpern.com> To: vrrp@ietf.org Message-id: <092701cc05c5$b6e503e0$24af0ba0$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQIZ8W5wLM1ZIaRTi8V/JMr7fUyUZZPXoktw References: <4DB989B2.4050006@joelhalpern.com> Subject: [VRRP] FW: [RTG-DIR] RtgDir review: draft-ietf-vrrp-unified-mib-09.txt X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 17:00:04 -0000 Hi WG This is for your information. The review forms part of the IETF last call. Thanks, Adrian > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of > Joel M. Halpern > Sent: 28 April 2011 16:37 > To: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-vrrp-unified- > mib.all@tools.ietf.org > Subject: [RTG-DIR] RtgDir review: draft-ietf-vrrp-unified-mib-09.txt > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > > Document: draft-ietf-vrrp-unified-mib-09.txt > Reviewer: Joel Halpern > Review Date: 28-April-2011 > IETF LC End Date: 2011-05-11 > Intended Status: Proposed Standard > > Summary: I have significant concerns about this document and recommend > that the Routing ADs discuss these issues further with the authors. > > Note: The document is very readable, and quite clear on its > architecture. I appreciate that. > > Major issue: > There seems to be an architectural disconnect between this MIB and RFC > 5798. WHile I can understand the design in the MIB, and would not have > any concern if that were the design in 5798, they appear not to match. > > Specifically, Section 6.1 of RFC 5798 says that a given Virtual Router > has a Virtual Router ID (VRID) and a priority. That virtual router then > has a list of Ipv4 addresses it is associated and a list of IPv6 > addresses addresses it is associated with. There is a single priority > for the entire virtual router. (As documented, conceptually, all VRs > serve all address types, even if some of them may be configured with > only IPv4 addresses or only IPv6 addresses.) > > In contrast, the MIB document goes to great trouble to diagram the > virtual router as being dedicated to a single address family. In the > MIB, conceptually, they are two routers for a given VRID. This is shown > in the diagrams by having two different priorities for these two > different routers, and different states (master vs backup) for the two > virtual routers in the same box, even though they are using the same > VRID. This is reflected in the base keying structure of the MIB. > > For all I know, this is the actual practice in deploying the protocol. > But it is NOT what the RFC says. (And no, this can not be fixed as an > errata to RFC 5798.) > > > Minor issues: > (These assume the structure as given in the MIB. If I am correct about > the major issue needing to be addressesd, many of these will become OBE.) > In the example in section 8, in the vrrpv3AssociatedIpAddrTable for > VR1, it shows address Z as being active on rotuer VR1. However, the > diagram shows address Z as only active on VR2. (And the table for VR2 > shows Z as active there.) I presume this is a cut-and-paste error, and > the line for Z in VR1 just needs to be removed. > > I presume that there is a good reason why vrrpv3RouterChecksumErrors, > vrrpv3RouterVersionErrors, vrrpv3RouterVrIdErrors, and > vrrpv3GlobalStatisticsDiscontinuityTime do not exist per interface? (I > can understand why they are not per VRID, since with these errors, one > could not associate them with a specific VRID. But they can be > associated with a specific Interface.) > Also, whether they remain associated with the physical router, or become > a per-interface table, it would seem that they should be described in > section 7 on the structure of the MIB. This description should also > explain the scoping. > > > Nit: > Should the description of vrrpv3OperationsAcceptMode include a > REFERENCE " RFC 5798 section 6.1" > It seems odd to have one table Augment another in the same MIB document. > Is this just for human readability? > > > Yours, > Joel M. Halpern > > line? From dr@cluenet.de Thu Apr 28 10:19:44 2011 Return-Path: X-Original-To: vrrp@ietfa.amsl.com Delivered-To: vrrp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBD7E06EF for ; Thu, 28 Apr 2011 10:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPmGtSdmk+IP for ; Thu, 28 Apr 2011 10:19:43 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB58E06AF for ; Thu, 28 Apr 2011 10:19:43 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 77A781080DD; Thu, 28 Apr 2011 19:19:41 +0200 (CEST) Date: Thu, 28 Apr 2011 19:19:41 +0200 From: Daniel Roesen To: "vrrp@ietf.org" Message-ID: <20110428171941.GA3937@srv03.cluenet.de> Mail-Followup-To: "vrrp@ietf.org" References: <20110415085709.GA3742@srv03.cluenet.de> <450AE4BEC513614F96969DDA34F35934192892832D@EUSAACMS0701.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450AE4BEC513614F96969DDA34F35934192892832D@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [VRRP] RFC5798 requires usage of RAs? X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 17:19:44 -0000 Hi, On Thu, Apr 28, 2011 at 11:36:44AM -0400, Stephen Nadas wrote: > Sorry for the delay. I think the spec language could be better- > (630) etc probably should have said something more like > > "if ND RAs are in use, MUST send ND Router Advertisements for the virtual router. Indeed. Thanks for the confirmation. My understanding of IETF procedures is, that an Errata submission would be possible, valid way to unambiguate that language - which is advisable to prevent further implementation confusion. Shall I go ahead and draft up an erratum or do you want to take up on that yourself? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From stephen.nadas@ericsson.com Thu Apr 28 10:48:46 2011 Return-Path: X-Original-To: vrrp@ietfa.amsl.com Delivered-To: vrrp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CCDE0670 for ; Thu, 28 Apr 2011 10:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ2DZtJehqEm for ; Thu, 28 Apr 2011 10:48:45 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0849EE067F for ; Thu, 28 Apr 2011 10:48:44 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3SHmf3i026360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Apr 2011 12:48:42 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 28 Apr 2011 13:48:41 -0400 From: Stephen Nadas To: Daniel Roesen , "vrrp@ietf.org" Date: Thu, 28 Apr 2011 13:48:40 -0400 Thread-Topic: [VRRP] RFC5798 requires usage of RAs? Thread-Index: AcwFyI4+57w2MNduSAKo+TJ/LX6YcAAA87dQ Message-ID: <450AE4BEC513614F96969DDA34F359341928928499@EUSAACMS0701.eamcs.ericsson.se> References: <20110415085709.GA3742@srv03.cluenet.de> <450AE4BEC513614F96969DDA34F35934192892832D@EUSAACMS0701.eamcs.ericsson.se> <20110428171941.GA3937@srv03.cluenet.de> In-Reply-To: <20110428171941.GA3937@srv03.cluenet.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [VRRP] RFC5798 requires usage of RAs? X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 17:48:46 -0000 If you have cycles to propose text, that would be helpful, IMO.=20 Thanks, Steve =20 -----Original Message----- From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Dan= iel Roesen Sent: Thursday, April 28, 2011 1:20 PM To: vrrp@ietf.org Subject: Re: [VRRP] RFC5798 requires usage of RAs? Hi, On Thu, Apr 28, 2011 at 11:36:44AM -0400, Stephen Nadas wrote: > Sorry for the delay. I think the spec language could be better- > (630) etc probably should have said something more like >=20 > "if ND RAs are in use, MUST send ND Router Advertisements for the virtual= router.=20 Indeed. Thanks for the confirmation. My understanding of IETF procedures is, that an Errata submission would be = possible, valid way to unambiguate that language - which is advisable to pr= event further implementation confusion. Shall I go ahead and draft up an erratum or do you want to take up on that = yourself? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ________= _______________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp