Hi Elwyn, Appreciate your comments response to various questions or comments from me.
Will try to get them incorporated by today and send a version across to you. Will reply to comments, if any, later in the day. Once Tom provides English review comments could incorporate them, later. Thanks for your patience and much appreciated. Cheers Sam Sent from my iPhone > On Dec 12, 2014, at 6:40 AM, Elwyn Davies <[email protected]> wrote: > > Hi, Sam. > > Thanks for the responses. > > On the subject of SNMP write, I understand that agreement has been reached > that the > the MIB should effectively adopt the same position as RFC 3812, i.e. having > read/write etc. > objects and describing the use of the MIB for configuration in the examples. > I suggest that > para 3 of s1 is rewritten to make this a bit clearer what the position is and > also to explain > what the phrase "as a way to provide the information model" means. My > suggestion... > > OLD: > It is understood that SNMP SET is not used for MPLS configuration these days, > however the read-write and read-create option is still specified for some > objects as a way to provide the information model. > > NEW: > At the time of writing, SNMP SET is no longer recommended as a way to > configure MPLS networks > as was described in [RFC3812]. However, since the MIBs specified in this > document extend > and are intended to work in parallel with the MIB for MPLS specified in > [RFC3812], certain objects > defined here are specified with MAX-ACCESS of read-write or read-create so > that specifications > of the base tables in [RFC3812] and the extensions in this document are > consistent. Although the > examples described in Section 9 specify means to configure MPLS-TP tunnels in > a similar way to > the examples in [RFC3812], this should be seen as indicating how the MIB > values would be returned > in the specified circumstances having been configured by alternative means. > > Further responses are embedded below. > > I see this draft has appeared on next week's IESG agenda. If you can get me > an updated snapshot > asap it would be helpful so I can do the telechat review as I am travelling > next week. > > Cheers, > Elwyn > > >> On 11/12/14 20:41, Sam K. Aldrin wrote: >> Hi Elwyn, >> >> Thanks for the review and comments. >> Please find the responses inline. >>> On Dec 11, 2014, at 10:36 AM, Elwyn Davies <[email protected]> wrote: >>> >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at >>> >>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> Document: draft-ietf-mpls-tp-te-mib-09.txt >>> Reviewer: Elwyn Davies >>> Review Date: 10 December 2014 >>> IETF LC End Date: 8 December 2014 >>> IESG Telechat date: (if known) - >>> >>> >>> Summary: >>> Not ready. I am not a MIB expert nor an MPLS(-TP) configuration expert, >>> so I have >>> assumed that the details of the MIB specification have been addressed by >>> Joan's MIB Doctor review and the configuration examples have been checked >>> by an >>> MPLS-TP expert. However, the introductory text needs significant work to >>> make it >>> easier for people who are not MPLS-TP experts to come to grips with the >>> document. >> This MIB is intended to be used for MPLS-TP tunnels and is done by the way >> of extending existing MPLS-TE MIB. The assumption is that reader is already >> aware of MPLS-TP. Hence we didn’t provide a primer for MPLS-TP in this MIB >> and I am not sure if it is the right place either. > Sure.. Reading some of the earlier reviews there were some terms which were > not very well defined. > The text below for para 2 of s1 gives enough background to help I think. >> >>> The major issue with this document is that it appears to go against the >>> current IETF view >>> that SNMP is not a satisfactory solution for configuring networks. The >>> document has >>> effectively reiterated the RFC 3812 situation from 10 years ago when the >>> IETF held its nose >>> and said that SNMP was the only game in town even if security sucked. As >>> I mention below, this was extensively discussed a year ago but I couldn't >>> determine whether this draft was given >>> a special dispensation even though consensus seemed to be that writeable >>> MIBs were >>> considered inappropriate. If this is the case, it will be sufficient to >>> adapt the end of s1. >> We have deliberated over this topic for more than two years and after >> multiple discussions along with Routing AD and OPS AD, we decided to go >> forward with the writable objects for this MIB. Additionally we added a >> small paragraph at the end of s1, as recommended, the reason for doing so. > OK.. see notes at start. >>> AFAICS this draft has not had the 'grammar review' recommended by its AD >>> about a year >>> ago and there are a number of areas in the object descriptions where >>> language >>> improvements would be desirable in addition to notes given here. That is it >>> still needs >>> the grammar review. >> We could take help of English reviewers and request WG chairs to help us out >> in this regard. > > Thanks Tom.. sorry I am a bit pushed for time as NFSv4 took up lots of tiem > last week :-( >>> There are some more minor issues, particularly as regards the description >>> of the types >>> of tunnel in s1, the discussion of the contents of the MIBs in s6 and >>> possibly in regard to >>> the interaction with the standard interface table. >>> >>> >>> Major issues: >>> >>> Support for configuration: >>> The issue of SNMPset (write) support was discussed at length in the context >>> of >>> the MIB doctors' review of v-05 of this draft. The consensus at that time >>> appeared >>> to be that provision of write support in new MIBs should be strongly >>> discouraged. >>> I am unclear what the outcome of that discussion in the context of this >>> draft was, >>> but it is clear that the draft is very much written from the point of using >>> the MIB >>> as a configuration tool, especially in s9 (examples of usage). Whilst this >>> technique >>> reflects the equivalent section is RFC 3813, that document was written over >>> 10 years >>> ago and considerable effort has been devoted to providing alternative and >>> more secure >>> ways of configuring networks in the intervening time. The body of the >>> document has not >>> been altered to reflect the discussion that occurred. >> Whether SNMP write should exist or not discussion is not within the scope of >> this document. Whether this MIB should support writable MIB objects was >> discussed and the conclusion was yes. The text at end of s1 was added as >> recommended by AD’s. On the contrary, if this MIB were to change the way >> RFC3813 is to implemented/interpreted along with the MIB i.e. from writable >> for TE but read-only for non MPLS-TE tunnels, then it should be documented. >> >>> "Lip service" is paid to the discouragement of the use of SNMPset by the >>> addition of >>> para 3 of s1: >>>> It is understood that SNMP SET is not used for MPLS configuration these >>>> days, however the read-write and read-create option is still specified >>>> for some objects as a way to provide the information model. >>> It is not clear to me why providing read-write or read-create options >>> enhance the >>> MIB or are "a way to provide the information model". >>> >>> I note that despite the extensive discussion of this topic by WG members >>> and MIB specialists >>> back in December 2013, this issue was not flagged up in the Shepherd's >>> write up. >>> >>> If it has now been agreed that the configuration "flavour" is to be >>> accepted as WG consensus >>> in spite of being contrary to current practice, it appears to me that the >>> word "configuration" >>> should be removed from the last sentence of para 2 of s1 and the last para >>> of s1 rewritten to >>> explain why write capabilities are used in a more convincing manner. >> As noted above, the write option was retained after discussing at length, >> both at the WG sessions and over emails. The statement in last part of s1 >> was added as per the advice we received to move forward with the writable >> objects [ref: email from OPS AD dated Mar 11 on MPLS mailing list]. The main >> reason for writable objects, is because the MPLS-TE had writable objects and >> MPLS-TP extensions leverage this existing MIB and also few vendors have >> implemented them. >> >> Having said that, we are open to any suggested text, in addition to the one, >> which you already did below, in regards to ‘writable’ objects. > See above. >>> Minor issues: >>> Abstract/s1: Needs to be clear in both places that is is intended for >>> MPLS-TP, this: >>> -- Abstract and s1: s/transport networks./MPLS networks conforming to the >>> MPLS Transport Profile (MPLS-TP)./ >>> >>> s1: What is a Non-MPLS-TP (transport) network? >> MPLS-TE and other MPLS networks which is not constrained by transport >> requirements. Assuming some new tunnel type comes up into the future like >> bi-directional TE. :D > In that case I would just call it a "basic MPLS" network or some such. > non-MPLS-TP is rather ambiguous. >>> s1: The explanation of what the MIB extensions in this document actually do >>> is not clear to the >>> general reader. I suggest replacing para 2 completely: >>> >>> OLD: >>> The existing MPLS Traffic Engineering (TE) Management Information Base >>> (MIB) [RFC3812] and Generalized Multiprotocol Label Switching (GMPLS) >>> Traffic Engineering Management Information Base [RFC4802] do not support >>> the management of transport network requirements of Tunnel end points >>> with non-IP based identifiers and static bidirectional tunnels. This >>> document focuses on static bidirectional MIB modules that should be used >>> in conjunction with [RFC3812] and companion document [RFC3813] for MPLS >>> Transport Profile (MPLS-TP) path configuration and management. >>> >>> NEW: >>> As described in the MPLS Traffic Engineering (TE) Management Information >>> Base (MIB) definition [RFC3812], MPLS traffic engineering is concerned with >>> the >>> creation and management of MPLS tunnels. This term is a shorthand for a >>> combination of one or one or explicitly routed LSPs (ERLSPs) linking an >>> ingress >>> and an egress LSR. Several types of point-to-point MPLS tunnels may be >>> constructed >>> between a pair of LSRs A and B: >>> >>> - Unidirectional with a single LSP (say) from A to B. >>> >>> - Associated bidirectional consisting of two separately routed ERLSPs, one >>> linking >>> A to B and the other linking B to A. Together the pair provide a single >>> logical >>> bidirectional transport path. >>> >>> - Corouted bidirectional consisting of an associated bidirectional tunnel >>> but with >>> the second ERLSP from B to A following the reverse of the path of the ERLSP >>> from A to B, in terms of both nodes and links. >>> >>> Tunnels may be either statically configured by management action or >>> dynamically created using >>> a LSP management protocol. >> what is ‘LSP management protocol’? > I meant either RSVP or LDP or anything else that might be used dynamically. > Not sure what the generic term is these days. >>> The existing MPLS TE MIB [RFC3812] and the Generalized Multiprotocol Label >>> Switching (GMPLS) Traffic Engineering Management Information Base [RFC4802] >>> address only a subset of the >>> combinations of statically and dynamically configured tunnel types, >>> catering for statically >>> configured unidirectional tunnels together with dynamically configured >>> unidirectional and >>> corouted bidirectional tunnels. They are alsorestricted to to end point >>> LSRs identified >>> by IP addresses. >>> >>> The MPLS-TP TE MIB defined in this document extends the MIB defined in >>> [RFC3812] to cover >>> all six combinations (that is adding support for statically configured >>> associated and >>> corouted bidirectional plus dynamically configured associated bidirectional >>> tunnels). It also >>> extends support to end points that are identified other than with IP >>> addresses. >>> >>> This support is provided by a suite of four MIB modules that are to be used >>> in conjunction >>> with the MIBS defined in [RFC3812] and the companion document [RFC3813] for >>> MPLS >>> Transport Profile (MPLS-TP) TE path [configuration and]* management. >>> >>> END NEW >> Thank you. Will go through the text again and replace as suggested. > OK. >>> * Note: Using the term 'configuration' is inconsistent with the discussion >>> in para 3. >>> See Major Issues above >>> >>> s5, bullet 1: s8 in RFC 3812 discusses the use of the Interface Table with >>> MPLS. It should be >>> made clear here: >>> 1. Whether, if the MPLS-TP Tunnel is treated as an interface, there is any >>> difference in the usage >>> of the ifTable fields as compared with standard MPLS. In particular if a >>> different interface type >>> should be applicable. >>> 2. Are there any issues if all or (more especially) a subset of the tunnels >>> are not treated as >>> interfaces >> Haven’t come across any different types as such. Do you see any specific >> type which is of contrary to RFC 3812, that MPLS-TP defines? Will ask my >> co-authors as well. > I don't see anything obvious except that there might be some reason to > declare a different > interface type rather than using type 150 defined in RFC 3812 especially for > non-IP interfaces. > I am not sure how the ifSpeed field is used on bidirectional tunnels (that is > also a point for RFC 3812). > Also whether the operational status could take on other values if one > direction of the tunnel is > not working but the other is. > > Otherwise it would be worth a statement that the interface table can be used > as in RFC 3812 (or not) as appropriate. >>> Row pointer usage: s9 of RFC 3812 considers Row Pointer usage - are there >>> any differences or >>> additional considerations for these MIBs? >> None that we are aware off. > > There are three RowPointer type objects: mplsTunnelExtOppositeDirPtr and two > in MplsXCExtEntry. Notes about consistent > use with the corresponding entries in the base tables would be desirable > perhaps. > >>> s6: Sections 6.1 to 6.4 are not MIBs (as indicated by the title and >>> prologue) but MIB objects in >>> the MPLS-TE-EXT-STD-MIB MIB. Please reorganize s6 accordingly. Looking back >>> at RFC3812, the >>> structure of the document in sections 5 and 6 appears to be more helpful to >>> the new reader with a >>> summary of the four MIB modules in one section (expanded from ss6.5 - 6.7) >>> followed by notes on >>> the key MIB objects in each MIB as necessary. It would also be helpful to >>> clarify where objects in >>> this MIB are expected to parallel those in the basic (RFC 3812) and note >>> that they are indexed >>> equivalently (notably in the case of mplsTunnelTable and >>> mplsTunnelExtTable). >>> Nits/editorial comments: >> Nod. >>> General: Consistent use of bi-directional or bidirectional: Please choose >>> one and use it throughout. >> Nod. >>> General: The qualifier "sparse" is used incorrectly in several places >>> (e.g., sparsely extended). >>> Presumably the intention is that the extensions are "slight" or "limited" . >>> In most cases the term >>> can be deleted: The degree of extension will ultimately be in the eyes of >>> the implementer! >>> (s5 - 2 cases, s6.4, s7 - 2 cases, s8, s9.1.6, s9.2.9, s9.3.6, s12 - 3 >>> cases) >>> General: The figures need number and captions. The numbers should be used >>> to refer to the figures. >> Will review and edit as suggested. >>> s4, para 1: s/unidirectional tunnel/unidirectional tunnels/ >> Nod. >>> s4, para 1, last sentence: s/re-use/re-use and extend/ >> Nod. >>> s4, para 2: >>> OLD: >>> retained in the same document, instead of a separate document. >>> NEW: >>> all defined in this document, rather than split over several documents. >>> >>> s5, para 1: s/This document identifies/The MIBs in this document satisfy/ >>> >>> s5, para 2: s/The MIB module supports/The MIB modules, taken together, >>> support/ >>> >>> s5, para 2: s/static and signaled/statically configured and dynamically >>> signaled/ >>> >>> s5, bullet 4: s/sparsely extended/extended/ >>> >>> s9.1.6, s9.2.9, s9.3.6: s/a sparse augmentation/a limited augmentation/ >> Nod for all the above. >>> s5, bullet 5: It would be helpful to explain how node identification >>> differs from >>> standard MPLS to understand why this mapping is needed. There appears to be >>> text in s6.1 that might help >>> but it is too late to make it easy to understand this section. >> Will add reference to s6.1. >>> ss10-13: It is conventional to give the RFCs used as references in the >>> docuement s/RFC 3812/[RFC3812]/ etc. >> Nod. >>> s14: This is a near duplicate of the security considerations in RFC 3812. >>> It might be easier to reference >>> that section and add a note that extra tables may provide further sensitive >>> information. >> Nod. >>> A brief discussion of whether the non-IP case makes any difference would be >>> useful. >> I do not think there is a difference as such. We have provided example for >> non-ip case anyway. > For security??? >>> s16: At the very least RFC 3811, RFC 3812 and RFC 3813 are normative. RFC >>> 6923 probably is. >>> RFC 6370 and RFC 4802 may also be. >> Nod. >> >> thanks again >> -sam >> >> _______________________________________________ >> Gen-art mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
