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

[Hiroshi Tsunoda <[e-mail]>]

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 <[e-mail]>:
> 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 <[e-mail]>:
>>>
>>> 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 <[e-mail]>:
>>>
>>> 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 <[e-mail]>:
>>>>>
>>>>>
>>>>>     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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>
>>>
>>> _______________________________________________
>>> BESS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/bess
>
>