Re: AD review of draft-ietf-ccamp-gmpls-ted-mib
Masanori Miyazawa <ma-miyazawa <at> kddilabs.jp>
2012-06-06 06:54:25 GMT
Adrian,
Please find my response inline with respect to your comments.
Regards,
Masanori
>
> Per idnits, please change the header
> OLD
> Intended status: Standards Truck
> NEW
> Intended status: Proposed Standard
> END
>
[Masanori Miyazawa]
# Revise
> ---
>
> I am not comfortable with the two definitions
> OAM: Operations and Management
> OA&M: Operations, Administration and Maintenance.
> This is counter to RFC 6291which, although only guidelines, should be
> followed unless there is a good reason. That RFC has...
> o O&M - OAM and Management
> o OAM - Operations, Administration, and Maintenance Fortunately
> neither term is used in your document, and so they can be deleted.
>
[Masanori Miyazawa]
# Delete the words of OA&M and OAM in this document.
> ---
>
> There are some acronyms in 3.3 that are not used in the rest of the
> document: FSC, LDP, LSC, LSR, OAM, OA&M, RSVP,
>
[Masanori Miyazawa]
# Delete them in this document.
> ---
>
> Could you please sort out "MIB" versus "MIB module". There is only one
> MIB. There are many MIB modules - this document defines a MIB module.
>
[Masanori Miyazawa]
# I could not understand above comment. You mean that descriptions of "MIB
modules" exit in this document?
> ---
>
> Section 6 is missing a close brace "}" for tedTable
>
[Masanori Miyazawa]
# Add a close brace.
> ---
>
> The copyright date in the MODULE-IDENTITY is 2011.
>
[Masanori Miyazawa]
# Revise it to 2012.
> ---
>
> You need to avoid using citations (e.g. [RFC3630]) within the MIB module
> itself. MIB modules are extracted from their documents and stand alone.
>
> ---
>
> The DESCRIPTION for the tedTable is
> "This table indicates multiple TED information which has been
> supported by [RFC3630]."
>
> This seems to imply this doesn't apply to ISIS. Maybe update the text?
>
> Similarly, a number of objects only give references to OSPF or OSPF-TE.
> Not referencing the corresponding IS-IS specs looks like the object only
> has meaning for OSPF.
>
[Masanori Miyazawa]
# Add to descriptions of ISIS in the related entry.
> ---
>
> tedEntry OBJECT-TYPE
> SYNTAX TedEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This entry contains TED information commonly utilized in both
> MPLS and GMPLS."
> INDEX { tedLocalRouterId, tedRemoteRouterId,
> tedLinkInformationSource, tedLinkIndex }
> ::= { tedTable 1 }
>
> TedEntry ::= SEQUENCE {
> tedLinkInformationSource INTEGER,
> tedLocalRouterId TedRouterIdTC,
> tedRemoteRouterId TedRouterIdTC,
> tedLinkIndex TedLinkIndexTC,
>
> It is unusual to list the index fields in a different order from that
> which they appear in the table entry. Is this intended?
>
[Masanori Miyazawa]
# This is my mistake, we modify an order.
> ---
>
> Tom's surname is misspelled in several of the references!
>
[Masanori Miyazawa]
# Revise.
> ---
>
> I'm having some trouble with the use of 2119 language in the Description
> for tedLinkInformationData.
>
> Two examples...
>
> If tedLinkInformationSource has the value unknown(0), this
> object SHOULD contain a value of zeroDotZero.
>
> Under what circumstances can this use of "SHOULD" be varied?
[Masanori Miyazawa]
# At this time, we do not have a detailed situation to vary change to the
value unknown (0).
Should we delete the word "SHOULD"? or should the value unknown (0) be
deleted in this MIB if it is not used?
>
> If tedLinkInformationSource has the value
> locallyConfigured(1), this object MAY contain the identifier of
> the corresponding row entry in the teLinkTable of TE-LINK-STD-
> MIB[RFC4220], the identifier of the corresponding row in a local
> proprietary TE link MIB module, or the value of zeroDotZero
> otherwise.
>
> The use of "MAY" here implies that an implementation can choose to fill
> in the row pointer if it likes, but this is entirely an implementation
> choice. Is this what you are saying, or do you want to constrain the
> behavior more forcefully if TE-LINK-STD-MIB is implemented?
>
[Masanori Miyazawa]
# No, we think the implementation of this object is not constrained
forcefully. If the pointer is needed, we think this object should be used.
> ---
>
> tedRouterIdAddrType OBJECT-TYPE
> SYNTAX InetAddressType
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> " This object indicates the TE-Router ID address type. Only
> values unknown(0), ipv4(1) or ipv6(2) must be supported. "
>
> Do you mean s/must be/are/ ?
>
[Masanori Miyazawa]
# Revise.
> Similarly for tedLinkIdAddrType
>
> ---
>
> It's a small point, but I would have preferred you to rename
> tedRouterIdAddrType and tedRouterIdAddr as tedTeRouterIdAddrType and
> tedTeRouterIdAddr to distinguish them from the normal router ID.
>
[Masanori Miyazawa]
# Modify.
> ---
>
> I don't understand what values should be returned for objects that only
> apply in some circumstances. For example, in a non-GMPLS system, what
> would be returned for tedLinkProtectionType? In either a non-GMPLS system
> or one with numbered links, what values would be returned for tedLocalId
> and tedRemoteId? What about tedSwCapIndication for non-TDM links?
>
[Masanori Miyazawa]
# For instance, if we want to collect TED information from non-GMPLS system,
this mib is designed not to reply information of teLinkProtectionType from
SNMP agent. Likewise, if the system has the numbered links, the values of
tedLocalId and tedRemoteId are not returned.
> Section 6 says in these cases the objects are not supported, but I don't
> think it is that simple. Or is it?
>
> Even if it is that simple, I think the Description clauses should not
> the circumstances under which the object is not supported.
>
> (And yes, I do see the compliance statements which are very comprehensive,
> but I think they say what you have to support in specific circumstances,
> not how to behave if you support an object but have no information to
> return.)
>
[Masanori Miyazawa]
** Ok. I will add detail information which indicates whether the object
should be supported or not.
> ---
>
> tedLocalIfAddrEntry OBJECT-TYPE
> SYNTAX TedLocalIfAddrEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This entry contains the IP address information of the local
> TE
> link."
> INDEX { tedLinkIndex, tedLocalIfAddr }
> ::= { tedLocalIfAddrTable 1 }
>
> TedLocalIfAddrEntry ::= SEQUENCE {
> tedLocalIfAddrType InetAddressType,
> tedLocalIfAddr InetAddress
>
> }
>
> What would it look like to walk this table by increasing index value?
> Would all the shorter v4 addresses show first, or would the numerically
> smaller v6 addresses get mixed in with the v4 addresses?
>
> If the latter is possible, you should use the address type as an index
> as well.
>
[Masanori Miyazawa]
# As you know, note that tedLocalIfAddrTable as well as tedRemoteIfAddrTable
are independently defined, because the Interface IP Address sub-TLV may
appear more than once within the same Link-TLV.
Therefore, if the address is only used as index, another arbitrary index
such as tedIndex would be also needed to represent the relationship with
tedTable.
> ---
>
> A broader point about the use of addresses as indexes is found in RFC
> 4001 in the Description of the InetAddress TC...
>
> When this textual convention is used as the syntax of an
> index object, there may be issues with the limit of 128
> sub-identifiers specified in SMIv2, STD 58. In this case,
> the object definition MUST include a 'SIZE' clause to
> limit the number of potential instance sub-identifiers;
> otherwise the applicable constraints MUST be stated in
> the appropriate conceptual row DESCRIPTION clauses, or
> in the surrounding documentation if there is no single
> DESCRIPTION clause that is appropriate."
>
> ---
>
> tedStatusChangeNotificationMaxRate and
> tedCreatedDeletedNotificationMaxRate
>
> I am surprised that the Defval for these is 0 (no throttling) since the
> text recognises that this is a risky situation that may cause the box
> to blow up. Surely the default should be some safe setting.
>
> But then I wondered what a suitable safe setting would be and realised
> it would be "No Notifications". Except there is no way to say this with
> these objects.
>
> What do you think?
[Masanori Miyazawa]
#The reason for setting 0 as defval is to prevent sudden increase in
notification information. If we set the value as 10, the SNMP manager would
receive a number of alarms which is proportional to number of routers. For
instance, same ospf domain consists of 5 routers, the SNMP manager would
receive up to 50 alarms. So, I think that the optimal value of defval is 1.
>
> ---
>
> Would the Notifications be more helpful if they indicated the index of
> the entry in the tedTable to which they applied?
>
> ---
>
> For completeness, we usually get asked to state in the Security section
> what the risks are with write access objects. In this case it is really
> easy...
>
> There are only two write-access objects in this MIB module:
> tedStatusChangeNotificationMaxRate and
> tedCreatedDeletedNotificationMaxRate. Malicious modification of
> these objects could cause the management agent, the network, or the
> router to become overloaded with Notifications in cases of high
> churn within the network.
[Masanori Miyazawa]
# You mean that we only need to describe the above sentence in section
8[security consideration]?
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
Thanks
Fatai
-----邮件原件-----
发件人: Lou Berger [mailto:lberger <at> labn.net]
发送时间: 2012年6月4日 19:02
收件人: Fatai Zhang
抄送: ccamp <at> ietf.org
主题: Re: [CCAMP] 答复: I-D Action: draft-ietf-ccamp-gmpls-g709-framework-07.txt
On 6/4/2012 5:52 AM, Fatai Zhang wrote:
> Hi all,
>
> A new version of this draft has been submitted.
>
> The major change is the refinement in section 5.5 about control plane backward compatibility.
>
> In addition, some key words have been updated by [RFC2119] language.
>
Fatai,
Why add conformance language to an informational document? Are you
planning on changing its intended status? Changing to standards track,
which would be unusual for a FW document.
Thanks,
Lou
> Please check out for details.
>
>
> Thanks
>
> Fatai
>
> -----邮件原件-----
> 发件人: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] 代表 internet-drafts <at> ietf.org
> 发送时间: 2012年5月31日 14:31
> 收件人: i-d-announce <at> ietf.org
> 抄送: ccamp <at> ietf.org
> 主题: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-g709-framework-07.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
item of the Common Control and Measurement Plane Working Group of the IETF.
>
> Title : Framework for GMPLS and PCE Control of G.709 Optical Transport Networks
> Author(s) : Fatai Zhang
> Dan Li
> Han Li
> Sergio Belotti
> Daniele Ceccarelli
> Filename : draft-ietf-ccamp-gmpls-g709-framework-07.txt
> Pages : 29
> Date : 2012-05-30
>
> This document provides a framework to allow the development of
> protocol extensions to support Generalized Multi-Protocol Label
> Switching (GMPLS) and Path Computation Element (PCE) control of
> Optical Transport Networks (OTN) as specified in ITU-T Recommendation
> G.709 as consented in October 2009.
>
>
>
>
>
> A URL for this Internet-Draft is:
> 
RSS Feed