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

Hiroshi Tsunoda <tsuno@m.ieice.org> Sat, 21 October 2017 16:15 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 B0CAD1241F3 for <bess@ietfa.amsl.com>; Sat, 21 Oct 2017 09:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 CpmJWWx_C39h for <bess@ietfa.amsl.com>; Sat, 21 Oct 2017 09:15:39 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 7379D1270AE for <bess@ietf.org>; Sat, 21 Oct 2017 09:15:39 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id 8so21801957qtv.1 for <bess@ietf.org>; Sat, 21 Oct 2017 09:15:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=4eq7QS/lf1pVzTtu6igfDBAS8fSJikHiAC+A7XvXM30=; b=uZIEIu2NhQcElO8+jRpx9SmvdDgTFNHwvQU+PdE+wIZTSX54wuSbgMK6panPJ6TXai vbUBApuKg71l7ynv9LJamPU/36lsEwHAa0zBXt2bC+gJiuHH1F//4IH9dIJfJSVsyPB7 l4x4Th6dO9bM7I3ab17TotrTC/1gXgFAdKBtdgTdLgA3tF4tp4XFSmQXyq/Wjg8yLqZQ lSr0fyVqR4QNBKCEaPgXoSlJ/QE0aYgN2rqLBFRdymqnAbm5RoXP0fJWsTKx+Y7hj/mO cG210UY0mZS9teqV2/zRZxO9rte+MZrMs7UYCcEVqYNIDY4YDFTx8EXngG2nYsvT3DVx fmwA==
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:from:date:message-id:subject :to:cc; bh=4eq7QS/lf1pVzTtu6igfDBAS8fSJikHiAC+A7XvXM30=; b=VYmtb8Xq843ivLGO7bDt32Te+LoC5RWzPCPe42y+J3pRnbGOqRckSoydBTE5BDcpjF jga+UWzBVbKWskmNnSju+Nvylnd/xM1UnsYki5bkpbwAXR/2dzVxsKvTDBFJoWiRZdCA sR97KDj2C1EOQPV5IuGOsTV8lEHmReF2KkU+/eZ4Nnv9rIChvzH2VBpEV0Mcp/Hq2vIj 1bhzPj0qjvABIbI7mYJGn3YeHuR8T33wU7mLD0tC6cQqQcPpE/4HHWx6rV/CTLWUG0hr kEX67k8DXYjHCR/7MY2YUO+RDtBm6LVb82U0/K4Hjb0gSGrAWBLXACbNPP4iiEILU+tA JKGg==
X-Gm-Message-State: AMCzsaWPp+FCI6tQwsJ7gaPE3bnaUElULXNrS5aRv2Wa3429iLcJc+JD io4Dql/2dYgnJQysdmvU7hBFrCvy9cqLSjhAjg6yuQ==
X-Google-Smtp-Source: ABhQp+TmEXOOX7H9WlxC0Qw8reNF4yVo/myMMBQC6yv7umMVmi2B2atXLY4UtwzPySojPZu/i8bfXQoMLlR//i0TfJ8=
X-Received: by 10.200.47.169 with SMTP id l38mr11662812qta.272.1508602538276; Sat, 21 Oct 2017 09:15:38 -0700 (PDT)
MIME-Version: 1.0
Sender: dr.h.t@ieee.org
Received: by 10.140.102.184 with HTTP; Sat, 21 Oct 2017 09:14:57 -0700 (PDT)
From: Hiroshi Tsunoda <tsuno@m.ieice.org>
Date: Sat, 21 Oct 2017 18:14:57 +0200
X-Google-Sender-Auth: plfRlFJBM7c25JoZcsy-JMH8qwg
Message-ID: <CAPbjwkyWVNw=2zb6DuO55JbLfa1xXxE0toWsKzSa=7Mrkh+M+A@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/Scep3pNwMj5AQZAwiH0h7-JYSVs>
Subject: [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: Sat, 21 Oct 2017 16:15:42 -0000

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