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