Re: [bess] 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: bess@ietfa.amsl.com
Delivered-To: bess@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, 2 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/bess/VSoFJ8yiFApxygieFGcA4pF2Irs>
Subject: Re: [bess] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-10
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-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>om>:
>>    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
>