Re: [MIB-DOCTORS] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-10
Glenn Mansfield Keeni <glenn@cysols.com> Sat, 02 September 2017 07:48 UTC
Return-Path: <glenn@cysols.com>
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBD613439B; Sat, 2 Sep 2017 00:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br7MTLzSsFWT; Sat, 2 Sep 2017 00:47:57 -0700 (PDT)
Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BFA13319E; Sat, 2 Sep 2017 00:47:57 -0700 (PDT)
Received: from [192.168.0.89] (cysvpn02.priv.cysol.co.jp [192.168.0.89]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id v827llmK001159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 2 Sep 2017 16:47:48 +0900 (JST) (envelope-from glenn@cysols.com)
To: Hiroshi Tsunoda <tsuno@m.ieice.org>
Cc: Mach Chen <mach.chen@huawei.com>, "mib-doctors@ietf.org" <mib-doctors@ietf.org>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>, Martin Vigoureux <martin.vigoureux@nokia.com>, "bess@ietf.org" <bess@ietf.org>
References: <CAPbjwkwajmkSJFLxk2Fk-F4zMROv_cG95XM9oE55W0J9RZQ6qA@mail.gmail.com>
From: Glenn Mansfield Keeni <glenn@cysols.com>
Message-ID: <f9f1b890-8564-5d9f-0860-22d806a9524c@cysols.com>
Date: Sat, 02 Sep 2017 16:47:42 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAPbjwkwajmkSJFLxk2Fk-F4zMROv_cG95XM9oE55W0J9RZQ6qA@mail.gmail.com>
Content-Type: text/plain; charset="iso-2022-jp"; format="flowed"; delsp="yes"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mib-doctors/jb5Pj6WxwOO9wxLHL-QW0xnNKI8>
Subject: Re: [MIB-DOCTORS] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-10
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mib-doctors/>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Sep 2017 07:48:00 -0000
Dear Tsuno, Thanks for the revised draft. I have reviewed the draft. Some issues remain. These are listed below Please consider the issues/comments and update the draft. Glenn +--------------------------------------------------------+ 1. Page-6: L2L3VpnMcastProviderTunnelType: DESCRIPTION 1.1 It will be good to give a reference (RFCNNNN) for noTunnelInfo (0) : no tunnel information present That will make it consistent with the other items. This change will require adding RFCNNNN to the REFERENCE clause. 1.2 pimBidir (5) : BIDIR-PIM Tree [RFC5015] RFC5015 needs to be added to the Reference section 2. Page-6: L2L3VpnMcastProviderTunnelType: SYNTAX The rewritten SYNTAX clause without the repetitions looks better. Thanks. 3. Page-7,8: says " A L2L3VpnMcastProviderTunnelType object of value noTunnelInfo(0) indicates that the corresponding Provider Multicast Service Interface (PMSI) Tunnel attribute does not have a Tunnel Identifier." It may be better to align the wording with RFC6514 (Page 11) ' When the Tunnel Type is set to "No tunnel information present", the PMSI Tunnel attribute carries no tunnel information (no Tunnel Identifier).' 4. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: DESCRIPTION: E: Extension flag [RFC7902] RFC7902 needs to be added to the Reference section 5. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: REFERENCE "RFC6514, Section 5 RFC7902 " It will be nice to have a section pointer for RFC7902 too. (User-friendly and consistency). Please check the same for all the REFERENCE clause pointers 6. Page-12: l2L3VpnMcastPmsiTunnelAttributeAddlFlags: DESCRIPTION "When UDP-based S-PMSI signaling is used, the value of this object is zero." This is actually a 48-bit string. What would be the representation of "zero" above be? Will it be a string of length 0, a string containing a single ascii character "0" 6 ascii "0"s, 48 '0' bits ? 7. Page-14: l2L3VpnMcastPmsiTunnelAttributeLabel: DESCRIPTION: "When UDP-based S-PMSI signaling is used, the value of this object is zero that indicates the absence of MPLS Label." Once again. "zero" above is imprecise. 8. Compliance: It would be good to design the compliance module as follows: l2L3VpnMcastCoreCompliance: MANDATORY-GROUPS { l2L3VpnMcastPmsiFieldGroup } l2L3VpnMcastFullCompliance: MANDATORY-GROUPS { l2L3VpnMcastPmsiFieldGroup l2L3VpnMcastOptionalGroup } General: 10 Page-2 Section-1 10.1 In BGP/MPLS Virtual Private Networks (VPN) In BGP/MPLS Virtual Private Networks (VPNs) ? 10.2 Throughout this document, we will use the term "L2L3VpnMCast" to mean BGP/MPLS L2 and L3 VPN that support multicast. Throughout this document, we will use the term "L2L3VpnMCast network" to mean a network that comprises of BGP/MPLS L2 and L3 VPNs and supports multicast. 10.3 Page-4 Section-3 bullet 2 Please review the paragraph for readability. 10.4 It will be good to avoid page-breaks within quoted clauses. example: Page-6 L2L3VpnMcastProviderTunnelType: REFERENCE On 2017/08/28 3:27, Hiroshi Tsunoda wrote: > Dear Glenn, > > Thank you for your comments and for waiting for the update. > I posted a new revision (-10) as follows. > > URL: > https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-10.txt > Htmlized: > https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-10 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-10 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-10 > > In the new revision, the following changes are made. > - Updated the description of following TC and objects > in order to clarify the role of this MIB and to improve > the readability > -- L2L3VpnMcastProviderTunnelId > -- l2L3VpnMcastPmsiTunnelAttributeTable > - Removed some redundant expressions > - Updated compliance statements > > Please see the responses for your comments > in the followings. > > 2017-07-09 14:11 GMT+02:00 Glenn Mansfield Keeni <glenn@cysols.com>: >> L2L3-VPN-MCAST-TC-MIB:112: [5] {type-without-format} warning: type >> `L2L3VpnMcastProviderTunnelId' has no format specification >> This may be avoided by specifying a format in which the >> L2L3VpnMcastProviderTunnelId should be printed. >> Is there a preferred format? How will this be printed? >> One continuous octet string? > > The size and format of TunnelID depends on Tunnel Type. > and no preferred format is exist as of now. > Therefore, I have decided to not give format specification > to L2L3VpnMcastProviderTunnelId. > >> A. The l2L3VpnMcastPmsiTunnelAttributeTable needs all of the following >> four MOs as index for its rows >> l2L3VpnMcastPmsiTunnelAttributeFlags, >> l2L3VpnMcastPmsiTunnelAttributeType, >> l2L3VpnMcastPmsiTunnelAttributeLabel, >> l2L3VpnMcastPmsiTunnelAttributeId >> The l2L3VpnMcastPmsiTunnelAttributeId by itself is inadequate? If yes >> please explain it to me. Or point to the text that contains the >> explanation. >> I have been unable to confirm the above from the draft - that is very >> likely due to my lack of understanding of the l2L3VpnMcast technology. > > According to Sec. 7.4.1.1 of RFC6513, > P-tunnel is identified by its type and id. > Thus, in the latest revision, the following two objects are used as > index of the table. > l2L3VpnMcastPmsiTunnelAttributeType, > l2L3VpnMcastPmsiTunnelAttributeId > > Thanks in advance, > > -- tsuno > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess >
- [MIB-DOCTORS] Update to draft-ietf-bess-l2l3-vpn-… Hiroshi Tsunoda
- Re: [MIB-DOCTORS] Update to draft-ietf-bess-l2l3-… Glenn Mansfield Keeni