Re: [bess] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-11

Hiroshi Tsunoda <tsuno@m.ieice.org> Thu, 02 November 2017 08:54 UTC

Return-Path: <dr.h.t@ieee.org>
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 C201A13F848 for <bess@ietfa.amsl.com>; Thu, 2 Nov 2017 01:54:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com
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 10FkDlUoETWB for <bess@ietfa.amsl.com>; Thu, 2 Nov 2017 01:54:02 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3D913F441 for <bess@ietf.org>; Thu, 2 Nov 2017 01:54:01 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id h4so5571523qtk.8 for <bess@ietf.org>; Thu, 02 Nov 2017 01:54:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dn/vmIORy9P3PGm97KXzW184IChfgip+XE+qUfM536w=; b=o/gZ2urBscwMOwZ0ITgKLsYDB35fQY216gr++KzZO1TNkTC3R2IASgvaaJaPU4bRpy Hdw4I5wih2enfmNNPToTv3vcGG48iGrzskMPM33CORXN8LkB4csLy5fMd7Bq46j76uoc eHUiCU/71O1t2z+eCpjHn9mhsRwaAVsLrocG2VaDB7dX4eHEZSOG4Fga62WVp6DHQAoA jdE4hM6a3DXV/elC1fciMgamxPbsSEBevPEyh210JE2KupN1H/0iwaHjDRX9WFEepdR9 UuHtDTruvxAFd2FOOoclp0NUHbr8oNF6bE2STsgzyDrs1ALCKYEIzJIay6zAGS0uTbum pocA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dn/vmIORy9P3PGm97KXzW184IChfgip+XE+qUfM536w=; b=VfE8vz4pldvObmxHH8vkhDzyiamXrvfD3xijvNId9XH6WAI0lxZZqWNDq1HSr7XKcr tN1rHkKWStPd4OKpARcAritFu8GJ2cs9169mAamDNvcdxk4qgAB3AM7IzOi+DXudo/LP O/B4bQ7st3TcUvVyuCUf0Vl0oY2fZyWiu7NyqRQKBPHDrbQ/CpSwH0uuqGPoYir0FeQF +cL5vsnC7btWvlW0ZcHJwLmVHgE4uhE077R5i9v/BLFELguSNvI9xIxv4bcHgNLZddFj n5oONJ0+Vl+lzKefmPJLsFjD9ueCDBTk48uZ5x108XrHpYj1+v+TabctcmJQLV7B6389 zc+w==
X-Gm-Message-State: AMCzsaW/JeGNBF3dD3NI6b9PIBzChIBPw7kAgCB4pPXaC0jzz35R8+d/ cB6Km132YUAQ9x+hMB2MLiHNCfnYDwdUmPxj/Ys0jQ==
X-Google-Smtp-Source: ABhQp+T9O4MCFnRpr8Pa5aiSLy/jVeq9pNyvo16eWm7YwQI5ONOi5+GCT4t1OL1A5pjM0t1TX86PeVYAB9mziKp9iI0=
X-Received: by 10.200.63.242 with SMTP id v47mr4070303qtk.29.1509612839943; Thu, 02 Nov 2017 01:53:59 -0700 (PDT)
MIME-Version: 1.0
Sender: dr.h.t@ieee.org
Received: by 10.140.102.184 with HTTP; Thu, 2 Nov 2017 01:53:19 -0700 (PDT)
In-Reply-To: <730a8e1b-2a90-426b-3497-dab406376ebf@cysols.com>
References: <CAPbjwkyWVNw=2zb6DuO55JbLfa1xXxE0toWsKzSa=7Mrkh+M+A@mail.gmail.com> <730a8e1b-2a90-426b-3497-dab406376ebf@cysols.com>
From: Hiroshi Tsunoda <tsuno@m.ieice.org>
Date: Thu, 2 Nov 2017 09:53:19 +0100
X-Google-Sender-Auth: dOorzb7hZRRgHJxSAJo0hIrpUgE
Message-ID: <CAPbjwkxWcjr_VCtqYpp5_+xQthHht06ytBvtf9jvtRWCk9ZQtw@mail.gmail.com>
To: Glenn Mansfield Keeni <glenn@cysols.com>
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>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/TuS1Zay8iNLEOBQARRuqBopG28o>
Subject: Re: [bess] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-11
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: Thu, 02 Nov 2017 08:54:05 -0000

Dear Glenn,

Thank you very much for your very elaborate review.
I will do another editorial check for nits according to your suggestions.

Best regards,

-- tsuno

2017-11-01 5:07 GMT+01:00 Glenn Mansfield Keeni <glenn@cysols.com>om>:
> Hi Tsuno,
>    Thanks for addressing the issues in the new draft. It
> looks good. I do not have any major issues with the MIB.
> But before we give a go-ahead I would like to ask to you
> do another editorial check for nits.These are basically
>               s/network/networks/
> type of fixes.
> A minor issue with the MIB on naming related mater-
> I would suggest
>       s/l2L3VpnMcastPmsiFieldGroup/l2L3VpnMcastCoreGroup/
>
> Glenn
>
>
> On 2017/10/22 1:14, Hiroshi Tsunoda wrote:
>>
>> Dear Glenn,
>>
>> Thank you for your comments and for waiting for the update.
>> I posted a new revision (-11) as follows.
>>
>> URL:
>>
>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-11.txt
>> Htmlized:
>>        https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-11
>> Htmlized:
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-11
>> Diff:
>>
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-11
>>
>> Please see the responses for your comments in the followings.
>>
>> 2017-09-02 9:47 GMT+02:00 Glenn Mansfield Keeni <glenn@cysols.com>om>:
>>>
>>> 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.
>>
>>
>> Fixed.
>>
>>> 1.2      pimBidir           (5) : BIDIR-PIM Tree      [RFC5015]
>>>        RFC5015 needs to be added to the Reference section
>>
>>
>> RFC5015 added to the Reference section.
>>
>>> 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).'
>>
>>
>> Fixed. Thank you for your advice.
>>
>>> 4. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: DESCRIPTION:
>>>           E: Extension flag [RFC7902]
>>>        RFC7902 needs to be added to the Reference section
>>
>>
>> Fixed. RFC7902 is now in 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
>>
>>
>> Added a section point for Sec.3 of RFC7902.
>>
>>> 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.
>>
>>
>> In the current revision, these parts are revised as follows.
>>    When the P-tunnel does not have a correspondent PMSI tunnel
>>    attribute, the value of this object will be 0.
>>
>>> 8. Compliance:
>>>     It would be good to design the compliance module as follows:
>>>        l2L3VpnMcastCoreCompliance:
>>>            MANDATORY-GROUPS {
>>>                 l2L3VpnMcastPmsiFieldGroup
>>>            }
>>>        l2L3VpnMcastFullCompliance:
>>>            MANDATORY-GROUPS {
>>>                 l2L3VpnMcastPmsiFieldGroup
>>>                 l2L3VpnMcastOptionalGroup
>>>            }
>>
>>
>> Fixed along with your comments. Thank you.
>>
>>> General:
>>> 10    Page-2 Section-1
>>> 10.1    In BGP/MPLS Virtual Private Networks (VPN)
>>>          In BGP/MPLS Virtual Private Networks (VPNs) ?
>>
>>
>> Fixed.
>>
>>> 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.
>>
>>
>> Fixed. Now, the term "L2L3VpnMCast network" is used throughout the
>> document.
>>
>>> 10.3  Page-4 Section-3 bullet 2
>>>        Please review the paragraph for readability.
>>
>>
>> Revised the paragraph in order to improve readability.
>>
>>> 10.4  It will be good to avoid page-breaks within quoted clauses.
>>>        example: Page-6 L2L3VpnMcastProviderTunnelType: REFERENCE
>>
>>
>> Thank you for your comments. I adjusted the page-breaks along with this
>> comment.
>>
>> Thanks again.
>>
>> -- tsuno
>>
>> 2017-09-02 9:47 GMT+02:00 Glenn Mansfield Keeni <glenn@cysols.com>om>:
>>>
>>> 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
>>>>
>>>
>>> _______________________________________________
>>> BESS mailing list
>>> BESS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bess
>
>