From stbryant@cisco.com Fri Apr 5 11:02:04 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CABF21F9865; Fri, 5 Apr 2013 11:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TUKDNd3Kk5k; Fri, 5 Apr 2013 11:02:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5765121F9863; Fri, 5 Apr 2013 11:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6479; q=dns/txt; s=iport; t=1365184922; x=1366394522; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=T0DRyczVvExjmGtArYJr+6XEZeIQN42LckVe8xleX9M=; b=JvTvPQm3bH3Kw1WBzui3W8AhAN7kqszQVS/auciawfI24xDcIf/ZIuzo 4hsa1U4qp+ICXzf4VjMgyOYvnvB7/opHiui9UqyUfdn4w0IOdNrRcTOJb iqx30w5j7CvzuPTFNWQIETqQYR8c5I7YF1FfdexX+mByyA2lrG4/A4fFz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJcQX1GQ/khN/2dsb2JhbABLgwY2wSWBDRZ0gh8BAQEDAThAARALDgYECRYPCQMCAQIBRQYNAQcBAQWIBQYMwX+PGweDQAOTKINGkQ2DDA X-IronPort-AV: E=Sophos;i="4.87,416,1363132800"; d="scan'208";a="152559307" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2013 18:01:58 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r35I1us0032606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Apr 2013 18:01:56 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r35I1te6004298; Fri, 5 Apr 2013 19:01:55 +0100 (BST) Message-ID: <515F1193.8070305@cisco.com> Date: Fri, 05 Apr 2013 19:01:55 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Lou Berger References: <5120E158.8080705@labn.net> In-Reply-To: <5120E158.8080705@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, mpls@ietf.org, draft-ietf-mpls-tp-ethernet-addressing.all@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-ethernet-addressing-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 18:02:04 -0000 Lou Thanks for the review. Please see inline. On 17/02/2013 13:55, Lou Berger wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-mpls-tp-ethernet-addressing-05.txt > Reviewer: Lou Berger > Review Date: 2013-02-17 > IETF LC End Date: 2013-02-18 > Intended Status: Standards Track > > Summary: > > I have some minor concerns about this document that I think should be > resolved before publication. > > Comments: > > This document is pretty straight forward and I don't have any major > issues with it. I found the "MAC address discovery" a bit thinly > defined. This document relies on the mechanisms defined in > draft-ietf-mpls-gach-adv which has just entered last call. > > > Major Issues: > > I think the "MAC address discovery" mechanisms defined in Section 4, > need some additional details in order to ensure independent > interoperable implementations. I don't think any of these issues should > difficult or controversial, but I think they should be blocking. > > I think the following really needs to be covered: > > - The frequency in which the discovery information needs to be (re)sent > & retained. (I think this is simply 1 or 2 sentences that relate back > to Lifetime defined in gach-adv.) I have added The choice of lifetime for the TLV is an operational issue and not an inter-working issue, and thus the operator is free to set the lifetime according to their own preference. There is no requirement for the lifetime to be symmetric. To expedite the initialization of a link it is RECOMMENDED that a node that has been reconfigured, rebooted or is aware that it have been disconnected from its peer send a GAP Ethernet Interface Parameter message, and that it issues a GAP request message for the Ethernet parameters at the earliest opportunity. > > - Some guidance on how address changes should be handled. I have added When the MAC address in the received Source MAC Address TLV changes the new MAC address MUST be used (see Section 5.2 of [I-D.ietf-mpls-gach-adv]. > > - Some guidance on how MTU changes should be handled. I have added If a minimum MTU is configured for a link and the MTU advertised by the peer is lower than that minimum, the link the NMS MUST notified of the event. Under these circumstances the operator may choose to configure the LSR to shut the link and trigger thereby triggereing a fault and causing the end-to-end path to be repaired, or they may choose to leave the link up so that an OAM message can is used to verify the actual MTU. > > - MTU scope needs to be defined. It is completely unclear if MTU is > intended to be the MTU based on the maximum frame size supported by the > sending physical interface represented in the Source MAC Address TLV, or > the MTU supported by the logical (IP) interface associated with the > Source Address TLV. The ability to advertise the latter is IMO the > minimum required, which I assume was the intent of the document, and > just needs to be clarified. Also the basic term should be defined (via > appropriate reference). The MTU definition now says: MTU (type = 1, length = 4): The Value of this object is a 32-bit unsigned integer encoded in network byte order that specifies the maximum transmission unit size in octets of an MPLS label stack plus payload that can be sent over the sending interface. I am unconvinced that a reference is needed, although if you can find one that fits this description I am not averse to including it. However the new definition seems self defining. > > > Minor Issues: > > Section 4: > - since assignment of the mac address is not in this document: > s/01-00-5e-80-00-0d/defined in Section 7 of [mpls-gach-adv] Ref added > > - TLV formats should be provided for the defined TLVs Done > > - "Persistent loss" should be defined in quantitative terms. Also which > GAP messages, all? What about handling of the case where GAP messages > are received, but no MAC address TLVs are included? The degree of loss is a matter for the operator. The latter point is already covered in the text. > > Section 5: > - Earlier in Section 4 you say, "...must behave as configured for this > eventuality.", but such configuration isn't mentioned in section 5. I am beginning to think that manageability consideration sections are more of a liability than they are worth. I would assume that the implementer will read the whole text and provide the required controls without the need to list them in this section. This section is a reminder of text in the GAP protocol document and could if you prefer be deleted. > > - Reporting of MTU mismatch counts and/or details is probably worth > mentioning (and optionally reporting). That is now with the MTU text. > > Section 6: > - I think it would be worth mentioning that Section 5 based Address > Discovery allows the advertised MAC to be different than the MAC frame > source address, and covering related security implications. That would surely be a strange thing to do, but presumably is what the operator intended. I would leave it to the implementation to choose if and how it logged such an event. > > Nits: > > Section 2: > - for clarity, > s/these forms of/broadcast or multicast > in > "not known to be point-to-point, these forms of addressing MUST ..." done. > > One final comment: While I'm sure it's too late to make such a change, I > think including MTU in the [mpls-gach-adv] Source Address TLV (in place > of the reserved field) would have simplified the protocol. -- clearly > this is not a blocking comment or one that really needs to be addressed. It is a bit late, but will discuss with the others. - Stewart From eric.gray@ericsson.com Tue Apr 16 07:18:35 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756DC21F96F2 for ; Tue, 16 Apr 2013 07:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM+CDSV3Ojz2 for ; Tue, 16 Apr 2013 07:18:28 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id EC11021F9726 for ; Tue, 16 Apr 2013 07:18:27 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-9e-516d5db23b15 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 30.4C.02411.2BD5D615; Tue, 16 Apr 2013 16:18:27 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 10:18:26 -0400 From: Eric Gray To: "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" , "rtg-ads@tools-ietf.org" Thread-Topic: Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05 Thread-Index: Ac46I/L2HHXp8Uk5T2ussJve4WIn1A== Date: Tue, 16 Apr 2013 14:18:25 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF6090EF7@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF6090EF7eusaamb107ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPuO7m2NxAgzn7pS3O7K212HnmOrPF gjVP2R2YPZYs+cnk8eNkiseXy5/ZApijuGxSUnMyy1KL9O0SuDKaz99hL1g/lani7fsTzA2M 994xdjFyckgImEhsW/sbyhaTuHBvPVsXIxeHkMBRRolZ/zYxQjjLGSX6Nk9mB6liE9CQOHZn LVhCRGARUOLaRqYuRg4OZgFNibWXuUBqhAWCJSaufM0MYosIREi8/vWXEcLWk3jbup4JxGYR UJW4tmgf2ExeAW+JF2/+sIHYjEBXfD+1BqyGWUBc4taT+UwQ1wlILNlznhnCFpV4+fgfK4St LLHkyX4WiPp8iQ9T97FAzBSUODnzCcsERuFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHs MwceMyGLL2BkX8XIUVqcWpabbmS4iREYO8ck2Bx3MC74ZHmIUZqDRUmcN9T1QoCQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGxvjQuEvNC3tUmfd8mdUS/NhUtzxw5w/nta/yQ2+sX3VvnVXj hNOJ8x7mevzUObA6Zd22TOnsnwen2DmdSfLykP9q1Jjp9HanMbe9evo8qYkbP/Ss35BZz9d7 fIXjE04j25Pqm0okQk5sffrhBBPzhacT5vTeCWV+pTK1qHvWkn9uyttWJZQ1rVViKc5INNRi LipOBAAEvfOJawIAAA== Cc: "rtg-dir@ietf.org" Subject: [RTG-DIR] Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 14:18:35 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF6090EF7eusaamb107ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on speci= al request. The purpose of the review is to provide assistance to the Routing= ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other comments that yo= u receive, and strive to resolve them through discussion or by updating the d= raft. Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-05 Reviewer: Eric Gray Review Date: 17 April, 2013 Intended Status: Informational There is at least one major issue with this document, as it is now written. Comments/Questions: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The "disclaimer" at the end of the Introduction misses a case related to th= e cases excluded from the scope of this document - which is itself presumably out o= f scope. The text currently talks to protection of a path prior to entry to the ring= , or after exit from the ring. The missing case is when the path is part of a protect= ed service that involves one or more alternative paths external to the ring. It is no= t difficult to think of a scenario in which a protection event outside of the ring will= require that data forwarded across the ring will need to enter the ring at a differ= ent point, leave the ring at a different point, or both. While this would seem to impact the protection of the ring itself (possibly= requiring setup of similar protection for the new path traversing the ring), it shoul= d be quite easy to represent such an occurrence as a set of discrete event/operations = that would not be significantly different when compared to initial setup of prot= ection for the previous path in the ring. If for any reason folks feel that this may not be the case under some circu= mstances this document should either address those cases or explicitly state that th= ey will not be addressed by this document. Alternatively, the issue may be addressed by simply removing the 2nd senten= ce of the "disclaimer" paragraph, or the cases explicitly stated should be expres= sed as "examples." ---------------------------------------------------------------------------= ---------------------------------- Bullet 4 of section 1.3 is confusing as written. The meaning of "LI" is cl= ear enough, but "LE" presents some problems. Suppose that PHP is used; in this case, t= here is no label "expected" at the egress point from the ring (although a label may= be present and will be used by the LSR at that point, that label may not alway= s be the same label). Is PHP never permitted? Also, under what circumstances would the ring egress point SPME exit LSR no= t be the same? Based on subsequent reading, I believe this would be the case= for use of an SPME to provide "Wrapping" protection - it would probably therefo= re be a good idea to either say something to this effect (if that is the case)= or provide a forward reference (to section 2.3.2, 2.3.3 and 2.3.4, for example, or pos= sibly just to section 2.3). I would suggest adding a sentence to this bullet, along the lines of: "See section 2.3 for examples of where the SPME egress and ring exit might = not be the same." ---------------------------------------------------------------------------= ---------------------------------- Section 2 appears to ignore 1+1 protection, which would (similar to "Steeri= ng") use pre-established protection paths from an ingress LSR/node to each egres= s LSR/node but would send that traffic both ways at all times. The main differences between this approach and Steering are: o the need to notify the ingress node is eliminated as a consid= eration for protection switching latency o there is (therefore) no reliance on the existence of a failur= e detection method that is able to notify the ingress of a failure in t= he ring o double bandwidth is required This is carried forward in all subsequent sections/subsections. ---------------------------------------------------------------------------= ---------------------------------- Sections 2.1 and 2.2 do not exactly provide an "apples-to-apples" compariso= n basis in the bullets relating to "considerations" in each subsection. In o= rder to allow this comparison, both sections would need to provide an indication of= the order of protection paths required in a protection domain. Because - in the "Wrapping" case - it is necessary to provide protection SP= ME for each node and link (in a ring the number of links is exactly the same a= s the number of nodes), the number of protection SPME is O(2N). For the "Steering" case, however, it is necessary to provide protection SPM= E for each ingress node to each egress node (except for the last one) - which= is O(N^2). This statement is actually made in the introductory text in sectio= n 2.4. I would suggest either adding a bullet in section 2.2 and including forward references in these bullets to the analysis in section 2.4, or removing the= bullet in section 2.1. ---------------------------------------------------------------------------= ---------------------------------- Section 2.3 appears to assume that the desired protection scheme will be ba= sed on "Steering" rather than "Wrapping." This assumption is made without any effort/analysis to justify why this assumption is made (at least as far as = I can see). If that is the intention, minimally, section 2.3 should start with a statem= ent that this is the assumption made. Reading further, however, subsequent subsection 2.3.2 describes how the SPM= E concept - as outlined in the introductory text of section 2.3 - may be used= for the "Wrapping" approach. The confusion arises as a result of figure 3 and the text that describes it= in the preceding paragraph, as this figure/text is what most contributes to an imp= ression that an SPME would start at the ingress and end at an egress. I would suggest that this figure and the preceding paragraph would find a b= etter home on section 2.3.1. This would also align subsections of section 2.3 be= tter as there is a similar figure in section 2.3.2, 2.3.3 and 2.3.4. ---------------------------------------------------------------------------= ---------------------------------- The last paragraph in introductory text in section 2.3 (immediately prior t= o the start of section 2.3.1) appears to ignore the case where the egress LSR wou= ld use labels to "steer" delivery of labeled packets it receives over the SPME= to specific egress ports (of the egress LSR). These labels would most likely not be a part of the label stack received by= the ingress LSR (there is no need for these labels to be known outside of the r= ing) and would have to be pushed onto the stack before pushing on the label for = an SPME to the egress LSR/node. ---------------------------------------------------------------------------= ---------------------------------- I believe the text in the last paragraph of section 2.3.4 is incorrect in s= tating that protected traffic might not share the same protection path in both directio= ns. If both LSR-B and LSR-F detect that LSR-A is not available, then both will = use the protection SPME between LSR-B and LSR-F. If both LSR-A and LSR-E detect that LSR-F is not available, then both will = use the protection SPME between LSR-A and LSR-E. If both LSR-A and LSR-F detect that the link between them is not available,= then both will use the protection SPME between them. All that is required is that both LSRs in each case agree as to the nature = of the failure (node or link) - which may be easily and consistently determined by monitoring the status of the working and protection SPME. While it is possible for the end-point LSRs in each case to have an inconsi= stent view of the nature of the failure, this inconsistency should be short lived= (based on the periodicity of OAM monitoring of SPMEs). Depending on the OAM monitoring periodicity used - and the length of links = in the ring - this inconsistency may exist for a period of time that is less t= han the latency to be expected for "Steering" based protection. Note that this is a major issue with the current text as it impacts on anal= ysis in subsequent section 2.4 and the conclusion/recommendations of this document. ---------------------------------------------------------------------------= ---------------------------------- The analysis in section 2.4 is incomplete or based on an incorrect assertio= n made in section 2.3.4. If the alternative suggested in section 2.3.4 were used, the number of SPME= that will be required would be O(4N) - which is still O(N) and would be less tha= n O(N^2) for fewer than the 16-node limit assumption made for the analysis. ---------------------------------------------------------------------------= ---------------------------------- In the 1st sentence of the last paragraph in the introductory text of secti= on 2.4, the sentence mentions the use of additional resources but does not mention = the additional latency. Is there any reason for the omission? I suggest removing the text in this sentence that starts with "even though"= as it might otherwise be necessary to attempt an exhaustive list of detraction= s. ---------------------------------------------------------------------------= ---------------------------------- Also in the last paragraph of the introductory text in section 2.4, I imagi= ne that the case where one or more pairs of SPME may be eliminated because of LSRs that are not ingress-egress pairs is most likely of trivial value in any de= ployment involving a ring topology. Perhaps the last sentence in the last paragraph of this text in section 2.4= could be removed? NITs: =3D=3D=3D=3D In the Introduction section, 5th bullet in (or after) the 2nd paragraph - " Impact of signaling and routing information exchanged during protection, in presence of control plane." - the phrase "in presence of control plane" should probably be "in the presence of a control plane." ---------------------------------------------------------------------------= ---------------------------------- In the 2nd bullet in section 2.1, I believe it is the case that O(2N) =3D O= (N). ---------------------------------------------------------------------------= ---------------------------------- In the 1st paragraph of section 2.3.1, where it says "there is always an al= ternative path ..." - at the SPME level (as described in this document), there's alwa= ys exactly one alternative path. ---------------------------------------------------------------------------= ---------------------------------- In the 1st bullet in section 2.4, I believe it is the case that O(2N^2) =3D= O(N^2). ---------------------------------------------------------------------------= ---------------------------------- In the 1st and 2nd bullets in section 2.4, I believe it is the case that O(= 2N) =3D O(N). ---------------------------------------------------------------------------= ---------------------------------- --_000_48E1A67CB9CA044EADFEAB87D814BFF6090EF7eusaamb107ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have been selected as the Routing Directorate revi= ewer for this draft.

 

The Routing Directorate seeks to review all routing = or routing-related drafts

as they pass through IETF last call and IESG review,= and sometimes on special

request. The purpose of the review is to provide ass= istance to  the Routing ADs.

 

For more information about the Routing Directorate, = please see

http://www.ietf.org/iesg/directorate/routing.html<= /p>

 

Although these comments are primarily for the use of= the Routing ADs, it would

be helpful if you could consider them along with any= other comments that you

receive, and strive to resolve them through discussi= on or by updating the draft.

 

Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-05

Reviewer: Eric Gray

Review Date: 17 April, 2013

Intended Status: Informational

 

There is at least one major issue with this document= , as it is now written.

 

Comments/Questions:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= o:p>

 

The "disclaimer" at the end of the Introdu= ction misses a case related to the cases

excluded from the scope of this document – whi= ch is itself presumably out of scope. 

 

The text currently talks to protection of a path pri= or to entry to the ring, or after

exit from the ring.  The missing case is when t= he path is part of a protected service

that involves one or more alternative paths external= to the ring.  It is not difficult

to think of a scenario in which a protection event o= utside of the ring will require

that data forwarded across the ring will need to ent= er the ring at a different point,

leave the ring at a different point, or both.

 

While this would seem to impact the protection of th= e ring itself (possibly requiring

setup of similar protection for the new path travers= ing the ring), it should be quite

easy to represent such an occurrence as a set of dis= crete event/operations that

would not be significantly different when compared t= o initial setup of protection for

the previous path in the ring.

 

If for any reason folks feel that this may not be th= e case under some circumstances

this document should either address those cases or e= xplicitly state that they will not

be addressed by this document.

 

Alternatively, the issue may be addressed by simply = removing the 2nd sentence of

the "disclaimer" paragraph, or the cases e= xplicitly stated should be expressed as

"examples."

----------------------------------------------------= ---------------------------------------------------------

 

Bullet 4 of section 1.3 is confusing as written.&nbs= p; The meaning of "LI" is clear enough,

but "LE" presents some problems.  Sup= pose that PHP is used; in this case, there is

no label "expected" at the egress point fr= om the ring (although a label may be

present and will be used by the LSR at that point, t= hat label may not always be the

same label).

 

Is PHP never permitted?

 

Also, under what circumstances would the ring egress= point SPME exit LSR not

be the same?  Based on subsequent reading, I be= lieve this would be the case for

use of an SPME to provide "Wrapping" prote= ction – it would probably therefore

be a good idea to either say something to this effec= t (if that is the case) or provide

a forward reference (to section 2.3.2, 2.3.3 and 2.3= .4, for example, or possibly

just to section 2.3).

 

I would suggest adding a sentence to this bullet, al= ong the lines of:

 

"See section 2.3 for examples of where the SPME= egress and ring exit might not

be the same."

----------------------------------------------------= ---------------------------------------------------------

 

Section 2 appears to ignore 1+1 protection, whic= h would (similar to "Steering")

use pre-established protection paths from an ingress= LSR/node to each egress

LSR/node but would send that traffic both ways at al= l times. 

 

The main differences between this approach and Steer= ing are:

 

o        &nb= sp;    the need to notify the ingress node is eliminated as = a consideration for

        &nbs= p;       protection switching latency

o        &nb= sp;    there is (therefore) no reliance on the existence of = a failure detection

        &nbs= p;       method that is able to notify the in= gress of a failure in the ring

o        &nb= sp;    double bandwidth is required

 

This is carried forward in all subsequent sections/s= ubsections.

----------------------------------------------------= ---------------------------------------------------------

 

Sections 2.1 and 2.2 do not exactly provide an "= ;apples-to-apples" comparison

basis in the bullets relating to "consideration= s" in each subsection.  In order to

allow this comparison, both sections would need to p= rovide an indication of the

order of protection paths required in a protec= tion domain.

 

Because – in the "Wrapping" case = 211; it is necessary to provide protection SPME

for each node and link (in a ring the number of link= s is exactly the same as the

number of nodes), the number of protection SPME is O= (2N).

 

For the "Steering" case, however, it is ne= cessary to provide protection SPME

for each ingress node to each egress node (except fo= r the last one) – which is

O(N^2).  This statement is actually made in the= introductory text in section 2.4.

 

I would suggest either adding a bullet in section 2.= 2 and including forward

references in these bullets to the analysis in secti= on 2.4, or removing the bullet

in section 2.1.

----------------------------------------------------= ---------------------------------------------------------

 

Section 2.3 appears to assume that the desired prote= ction scheme will be based

on "Steering" rather than "Wrapping.&= quot;  This assumption is made without any

effort/analysis to justify why this assumption is ma= de (at least as far as I can see).

 

If that is the intention, minimally, section 2.3 sho= uld start with a statement that

this is the assumption made.

 

Reading further, however, subsequent subsection 2.3.= 2 describes how the SPME

concept – as outlined in the introductory text= of section 2.3 – may be used for the

"Wrapping" approach.

 

The confusion arises as a result of figure 3 and the= text that describes it in the

preceding paragraph, as this figure/text is what mos= t contributes to an impression

that an SPME would start at the ingress and end at a= n egress.

 

I would suggest that this figure and the preceding p= aragraph would find a better

home on section 2.3.1.  This would also align s= ubsections of section 2.3 better as

there is a similar figure in section 2.3.2, 2.3.3 an= d 2.3.4.

----------------------------------------------------= ---------------------------------------------------------

 

The last paragraph in introductory text in section 2= .3 (immediately prior to the

start of section 2.3.1) appears to ignore the case w= here the egress LSR would

use labels to "steer" delivery of labeled = packets it receives over the SPME to

specific egress ports (of the egress LSR). 

 

These labels would most likely not be a part of the = label stack received by the

ingress LSR (there is no need for these labels to be= known outside of the ring)

and would have to be pushed onto the stack before pu= shing on the label for an

SPME to the egress LSR/node.

----------------------------------------------------= ---------------------------------------------------------

 

I believe the text in the last paragraph of section = 2.3.4 is incorrect in stating that

protected traffic might not share the same protectio= n path in both directions.

 

If both LSR-B and LSR-F detect that LSR-A is not ava= ilable, then both will use the

protection SPME between LSR-B and LSR-F.<= /p>

 

If both LSR-A and LSR-E detect that LSR-F is not ava= ilable, then both will use the

protection SPME between LSR-A and LSR-E.<= /p>

 

If both LSR-A and LSR-F detect that the link between= them is not available, then

both will use the protection SPME between them.=

 

All that is required is that both LSRs in each case = agree as to the nature of the

failure (node or link) – which may be easily a= nd consistently determined by

monitoring the status of the working and protection = SPME.

 

While it is possible for the end-point LSRs in each = case to have an inconsistent

view of the nature of the failure, this inconsistenc= y should be short lived (based

on the periodicity of OAM monitoring of SPMEs).=

 

Depending on the OAM monitoring periodicity used = 211; and the length of links in

the ring – this inconsistency may exist for a = period of time that is less than the

latency to be expected for "Steering" base= d protection.

 

Note that this is a major issue with the cu= rrent text as it impacts on analysis in

subsequent section 2.4 and the conclusion/r= ecommendations of this document.

----------------------------------------------------= ---------------------------------------------------------

 

The analysis in section 2.4 is incomplete or based o= n an incorrect assertion made

in section 2.3.4.

 

If the alternative suggested in section 2.3.4 were u= sed, the number of SPME that

will be required would be O(4N) – which is sti= ll O(N) and would be less than O(N^2)

for fewer than the 16-node limit assumption made for= the analysis.

----------------------------------------------------= ---------------------------------------------------------

 

In the 1st sentence of the last paragraph= in the introductory text of section 2.4,

the sentence mentions the use of additional resource= s but does not mention the

additional latency.

 

Is there any reason for the omission?

 

I suggest removing the text in this sentence that st= arts with "even though" as

it might otherwise be necessary to attempt an exhaus= tive list of detractions.

----------------------------------------------------= ---------------------------------------------------------

 

Also in the last paragraph of the introductory text = in section 2.4, I imagine that

the case where one or more pairs of SPME may be elim= inated because of LSRs

that are not ingress-egress pairs is most likely of = trivial value in any deployment

involving a ring topology. 

 

Perhaps the last sentence in the last paragraph of t= his text in section 2.4 could be

removed?

 

NITs:

=3D=3D=3D=3D

 

In the Introduction section, 5th bullet i= n (or after) the 2nd paragraph –

 

   " Impact of signaling and routing = information exchanged during

      protection, in presen= ce of control plane."

 

- the phrase "in presence of control plane"= ; should probably be "in the

presence of a control plane.&qu= ot;

----------------------------------------------------= ---------------------------------------------------------

 

In the 2nd bullet in section 2.1, I belie= ve it is the case that O(2N) =3D O(N). 

----------------------------------------------------= ---------------------------------------------------------

 

In the 1st paragraph of section 2.3.1, wh= ere it says "there is always an alternative

path …" – at the SPME level (as des= cribed in this document), there's always exactly

one  alternative path.

----------------------------------------------------= ---------------------------------------------------------

 

In the 1st bullet in section 2.4, I belie= ve it is the case that O(2N^2) =3D O(N^2).

----------------------------------------------------= ---------------------------------------------------------

 

In the 1st and 2nd bullets in = section 2.4, I believe it is the case that O(2N) =3D O(N).

----------------------------------------------------= ---------------------------------------------------------

 

 

 

 

--_000_48E1A67CB9CA044EADFEAB87D814BFF6090EF7eusaamb107ericsso_-- From wyaacov@gmail.com Wed Apr 17 05:56:12 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B675021E8048 for ; Wed, 17 Apr 2013 05:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8e-jT+d5cOm for ; Wed, 17 Apr 2013 05:56:07 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id D490721F8E5A for ; Wed, 17 Apr 2013 05:56:06 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so1531134wgg.28 for ; Wed, 17 Apr 2013 05:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=v/LXhSX8m9sjaJKs16+QofWfBi2ENjtJCAIZ7XNXz60=; b=oXK5aemzMNjv2QRgBkUqWGQJFgrJGJvL6qVTXMArA1X/DfvxpSdIljLgodMw78blsM Bo50zgt52WMI/v3wEedzqRGHpeC7z7mBYJVKxbeZCdunDOpCSIqlqpbpPGBX7pvUfRAQ sZFeWKTyvhWAUtKBB5JnTfVz5/bTZBlgdXmbN77yiRDpsIsiqx2RycC+JQP6KLWqVs8P +o08FV3hb5UsPUop2r4ZNrFZmYE6TC87ecgxPe2jyzaDJ9jXTZa6TnRePZ8+tvp1GV+N +ivYJvhgwMO2aA57lF8Ep6v4Um9+aPCzDZtb/xJ0NTKUV+QHKX6tS7ewZrJezOj4L8ks 3r4g== MIME-Version: 1.0 X-Received: by 10.194.123.168 with SMTP id mb8mr11184861wjb.24.1366203365933; Wed, 17 Apr 2013 05:56:05 -0700 (PDT) Received: by 10.194.13.104 with HTTP; Wed, 17 Apr 2013 05:56:05 -0700 (PDT) In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF6090EF7@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF6090EF7@eusaamb107.ericsson.se> Date: Wed, 17 Apr 2013 15:56:05 +0300 Message-ID: From: Yaacov Weingarten To: Eric Gray Content-Type: multipart/alternative; boundary=089e01183112514a4504da8e0220 X-Mailman-Approved-At: Wed, 17 Apr 2013 07:54:06 -0700 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools-ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [RTG-DIR] Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 12:56:14 -0000 --089e01183112514a4504da8e0220 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Eric, hi Thank you for your review and very in-depth comments, I will try to address some of them inline below (indicated by "yw>>" before the comment. Hope this helps, yaacov On Tue, Apr 16, 2013 at 5:18 PM, Eric Gray wrote: > Hello,**** > > ** ** > > I have been selected as the Routing Directorate reviewer for this draft. = * > *** > > ** ** > > The Routing Directorate seeks to review all routing or routing-related > drafts **** > > as they pass through IETF last call and IESG review, and sometimes on > special **** > > request. The purpose of the review is to provide assistance to the > Routing ADs. **** > > ** ** > > For more information about the Routing Directorate, please see **** > > http://www.ietf.org/iesg/directorate/routing.html**** > > ** ** > > Although these comments are primarily for the use of the Routing ADs, it > would **** > > be helpful if you could consider them along with any other comments that > you **** > > receive, and strive to resolve them through discussion or by updating the > draft. **** > > ** ** > > Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-0= 5 > **** > > Reviewer: Eric Gray**** > > Review Date: 17 April, 2013**** > > Intended Status: Informational**** > > ** ** > > There is at least one major issue with this document, as it is now writte= n. > **** > > ** ** > > Comments/Questions:**** > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D**** > > ** ** > > The "disclaimer" at the end of the Introduction misses a case related to > the cases**** > > excluded from the scope of this document =96 which is itself presumably o= ut > of scope. > > > yw>> Assume that you are referring to the disclaimer at the end of section 1.1 (as opposed to the one at the end of section 1) > > > ** ** > > The text currently talks to protection of a path prior to entry to the > ring, or after **** > > exit from the ring. The missing case is when the path is part of a > protected service**** > > that involves one or more alternative paths external to the ring. It is > not difficult**** > > to think of a scenario in which a protection event outside of the ring > will require**** > > that data forwarded across the ring will need to enter the ring at a > different point,**** > > leave the ring at a different point, or both.**** > > ** ** > > While this would seem to impact the protection of the ring itself > (possibly requiring**** > > setup of similar protection for the new path traversing the ring), it > should be quite**** > > easy to represent such an occurrence as a set of discrete event/operation= s > that **** > > would not be significantly different when compared to initial setup of > protection for**** > > the previous path in the ring.**** > > ** ** > > If for any reason folks feel that this may not be the case under some > circumstances**** > > this document should either address those cases or explicitly state that > they will not**** > > be addressed by this document.**** > > ** ** > > Alternatively, the issue may be addressed by simply removing the 2ndsente= nce of > **** > > the "disclaimer" paragraph, or the cases explicitly stated should be > expressed as**** > > "examples." > > > yw>> How about if I change the text of the second sentence to read: "Protection triggers on the transport path prior to the ring ingress node or beyond the egress nodes may be protected by some other mechanism."? > > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > Bullet 4 of section 1.3 is confusing as written. The meaning of "LI" is > clear enough,**** > > but "LE" presents some problems. Suppose that PHP is used; in this case, > there is **** > > no label "expected" at the egress point from the ring (although a label > may be **** > > present and will be used by the LSR at that point, that label may not > always be the**** > > same label).**** > > ** ** > > Is PHP never permitted? > > > yw>> regarding this, I seem to recall such a discussion regarding MPLS-TP and PHP. However, in any case if there is no such label, why couldn't LE=3Dnull? It is just being presented for discussion, not as an actual labe= l. > > > ** ** > > Also, under what circumstances would the ring egress point SPME exit LSR > not**** > > be the same? Based on subsequent reading, I believe this would be the > case for**** > > use of an SPME to provide "Wrapping" protection =96 it would probably > therefore**** > > be a good idea to either say something to this effect (if that is the > case) or provide**** > > a forward reference (to section 2.3.2, 2.3.3 and 2.3.4, for example, or > possibly**** > > just to section 2.3).**** > > ** ** > > I would suggest adding a sentence to this bullet, along the lines of:**** > > ** ** > > "See section 2.3 for examples of where the SPME egress and ring exit migh= t > not**** > > be the same." > > > yw>> How about if I add ", for example as described in Section 2.3" to the parenthetical phrase? > > > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > Section 2 appears to ignore 1+1 protection, which would (similar to > "Steering")**** > > use pre-established protection paths from an ingress LSR/node to each > egress**** > > LSR/node but would send that traffic both ways at all times. **** > > ** ** > > The main differences between this approach and Steering are:**** > > ** ** > > o the need to notify the ingress node is eliminated as a > consideration for **** > > protection switching latency**** > > o there is (therefore) no reliance on the existence of a > failure detection **** > > method that is able to notify the ingress of a failure in > the ring**** > > o double bandwidth *is* required **** > > ** ** > > This is carried forward in all subsequent sections/subsections. > > > yw>> 1+1 protection is a linear protection methodology, and Section 2 is describing basic Transport Network ring protection as defined in the ITU - which include Steering and Wrapping. 1+1 does not seem to be popular in rings, since historically SDH seemed to shun this alternative. We do reference 1+1 transmission in section 3.2 and in the conclusions. > > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > Sections 2.1 and 2.2 do not exactly provide an "apples-to-apples" > comparison**** > > basis in the bullets relating to "considerations" in each subsection. In > order to **** > > allow this comparison, both sections would need to provide an indication > of the**** > > order of protection paths required *in a protection domain*. **** > > ** ** > > Because =96 in the "Wrapping" case =96 it is necessary to provide protect= ion > SPME**** > > for each node and link (in a ring the number of links is exactly the same > as the **** > > number of nodes), the number of protection SPME is O(2N).**** > > ** ** > > For the "Steering" case, however, it is necessary to provide protection > SPME**** > > for each ingress node to each egress node (except for the last one) =96 > which is**** > > O(N^2). This statement is actually made in the introductory text in > section 2.4.**** > > ** ** > > I would suggest either adding a bullet in section 2.2 and including forwa= rd > **** > > references in these bullets to the analysis in section 2.4, or removing > the bullet**** > > in section 2.1. > > > yw>> Could you please specify which bullet you are suggesting to delete? Thanx > > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > Section 2.3 appears to assume that the desired protection scheme will be > based**** > > on "Steering" rather than "Wrapping." This assumption is made without an= y > **** > > effort/analysis to justify why this assumption is made (at least as far a= s > I can see). **** > > ** ** > > If that is the intention, minimally, section 2.3 should start with a > statement that **** > > this is the assumption made.**** > > ** ** > > Reading further, however, subsequent subsection 2.3.2 describes how the > SPME**** > > concept =96 as outlined in the introductory text of section 2.3 =96 may b= e > used for the**** > > "Wrapping" approach.**** > > ** ** > > The confusion arises as a result of figure 3 and the text that describes > it in the **** > > preceding paragraph, as this figure/text is what most contributes to an > impression**** > > that an SPME would start at the ingress and end at an egress.**** > > ** ** > > I would suggest that this figure and the preceding paragraph would find a > better **** > > home on section 2.3.1. This would also align subsections of section 2.3 > better as **** > > there is a similar figure in section 2.3.2, 2.3.3 and 2.3.4. > > > yw>> Will move the paragraph and figure, as you suggest. > > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > The last paragraph in introductory text in section 2.3 (immediately prior > to the**** > > start of section 2.3.1) appears to ignore the case where the egress LSR > would**** > > use labels to "steer" delivery of labeled packets it receives over the > SPME to**** > > specific egress ports (of the egress LSR). **** > > ** ** > > These labels would most likely not be a part of the label stack received > by the **** > > ingress LSR (there is no need for these labels to be known outside of the > ring)**** > > and would have to be pushed onto the stack before pushing on the label fo= r > an**** > > SPME to the egress LSR/node. > yw>> Do you have a suggestion on how better to include this consideration? > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > I believe the text in the last paragraph of section 2.3.4 is incorrect in > stating that**** > > protected traffic might not share the same protection path in both > directions.**** > > ** ** > > If both LSR-B and LSR-F detect that LSR-A is not available, then both wil= l > use the**** > > protection SPME between LSR-B and LSR-F.**** > > ** ** > > If both LSR-A and LSR-E detect that LSR-F is not available, then both wil= l > use the**** > > protection SPME between LSR-A and LSR-E.**** > > ** ** > > If both LSR-A and LSR-F detect that the link between them is not > available, then**** > > both will use the protection SPME between them.**** > > ** ** > > All that is required is that both LSRs in each case agree as to the natur= e > of the **** > > failure (node or link) =96 which may be easily and consistently determine= d by > **** > > monitoring the status of the working and protection SPME. ** ** > > ** ** > > While it is possible for the end-point LSRs in each case to have an > inconsistent**** > > view of the nature of the failure, this inconsistency should be short > lived (based**** > > on the periodicity of OAM monitoring of SPMEs).**** > > ** ** > > Depending on the OAM monitoring periodicity used =96 and the length of li= nks > in **** > > the ring =96 this inconsistency may exist for a period of time that is le= ss > than the **** > > latency to be expected for "Steering" based protection.**** > > ** ** > > *Note that this is a major issue with the current text as it impacts on > analysis in* > > *subsequent section 2.4 and the conclusion/recommendations of this > document.* > > > yw>> This statement is the result of review comments that we received during an earlier review of the document, and I am wary of removing it from the document at this late stage in the review process. In any case, there are other considerations for limiting both types of protection. I am sure that your analysis is correct although I am not sure that I understand your emphatic objection to the text and how it is related to the analysis in section 2.4. > > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > The analysis in section 2.4 is incomplete or based on an incorrect > assertion made**** > > in section 2.3.4.**** > > ** ** > > If the alternative suggested in section 2.3.4 were used, the number of > SPME that**** > > will be required would be O(4N) =96 which is still O(N) and would be less > than O(N^2)**** > > for fewer than the 16-node limit assumption made for the analysis. > > > yw>> This is correct and is certainly correct when the comparison is between O(2N) and O(N^2). Therefore whether the statement (reiterated in parenthesis here) is correct or not does not really affect the conclusions. This is based on the simplicity of Steering and the avoidance of wasted resources by transmitting the traffic twice over certain links. > > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > In the 1st sentence of the last paragraph in the introductory text of > section 2.4,**** > > the sentence mentions the use of additional resources but does not mentio= n > the**** > > additional latency.**** > > ** ** > > Is there any reason for the omission? > > > yw>> not really > > > ** ** > > I suggest removing the text in this sentence that starts with "even > though" as**** > > it might otherwise be necessary to attempt an exhaustive list of > detractions. > > > yw>> I have no problem with this suggestion > > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > Also in the last paragraph of the introductory text in section 2.4, I > imagine that**** > > the case where one or more pairs of SPME may be eliminated because of LSR= s > **** > > that are not ingress-egress pairs is most likely of trivial value in any > deployment**** > > involving a ring topology. **** > > ** ** > > Perhaps the last sentence in the last paragraph of this text in section > 2.4 could be**** > > removed? > > > yw>> Again, I have no problem with this > > > ** ** > > NITs:**** > > =3D=3D=3D=3D**** > > ** ** > > In the Introduction section, 5th bullet in (or after) the 2nd paragraph = =96 > **** > > ** ** > > " Impact of signaling and routing information exchanged during**** > > protection, in presence of control plane."**** > > ** ** > > - the phrase "in presence of control plane" should probably be "in *the* = * > *** > > presence of *a* control plane." > > > yw>> will fix > > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > In the 2nd bullet in section 2.1, I believe it is the case that O(2N) =3D > O(N). > yw>> while this is true, I think it is significant to mention the 2N > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > In the 1st paragraph of section 2.3.1, where it says "there is always an > alternative**** > > path =85" =96 at the SPME level (as described in this document), there's > always *exactly * > > *one* alternative path. > yw>> This is not 100% true. What is true is that there is exactly on alternative path within the ring (there may be additional alternatives that go outside the ring). This is why I did not originally add the "exactly" in the first place. > **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > In the 1st bullet in section 2.4, I believe it is the case that O(2N^2) = =3D > O(N^2). > > > yw>> see above, same applies to next statement. > > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > In the 1st and 2nd bullets in section 2.4, I believe it is the case that > O(2N) =3D O(N). **** > > > -------------------------------------------------------------------------= ------------------------------------ > **** > > ** ** > > ** ** > > ** ** > > ** ** > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --089e01183112514a4504da8e0220 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Eric, hi
=A0
Thank you for your r= eview and very in-depth comments, I will try to address some of them inline= below (indicated by "yw>>" before the comment.
= =A0
Hope this helps,
yaacov

On Tue, Apr 16, 2013 at 5:18 PM, Eric Gray <eric.gray@ericsson.co= m> wrote:

Hello,

=A0

I have been selected as the Routing Directorate revi= ewer for this draft.

=A0

The Routing Directorate seeks to review all routing = or routing-related drafts

as they pass through IETF last call and IESG review,= and sometimes on special

request. The purpose of the review is to provide ass= istance to =A0the Routing ADs.

=A0

For more information about the Routing Directorate, = please see

http://www.ietf.org/iesg/directorate/routing.ht= ml

=A0

Although these comments are primarily for the use of= the Routing ADs, it would

be helpful if you could consider them along with any= other comments that you

receive, and strive to resolve them through discussi= on or by updating the draft.

=A0

Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-05=

Reviewer: Eric Gray

Review Date: 17 April, 2013

Intended Status: Informational

=A0

There is at least one major issue with this document= , as it is now written.

=A0

Comments/Questions:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= u>

=A0

The "disclaimer" at the end of the Introdu= ction misses a case related to the cases

excluded from the scope of this document =96 which i= s itself presumably out of scope.=A0

=A0

yw>> = Assume that you are referring to the disclaimer at the end of section 1.1 (= as opposed to the one at the end of section 1)=A0

=A0

=A0

The text currently talks to protection of a path pri= or to entry to the ring, or after

exit from the ring.=A0 The missing case is when the = path is part of a protected service

that involves one or more alternative paths external= to the ring.=A0 It is not difficult

to think of a scenario in which a protection event o= utside of the ring will require

that data forwarded across the ring will need to ent= er the ring at a different point,

leave the ring at a different point, or both.=

=A0

While this would seem to impact the protection of th= e ring itself (possibly requiring

setup of similar protection for the new path travers= ing the ring), it should be quite

easy to represent such an occurrence as a set of dis= crete event/operations that

would not be significantly different when compared t= o initial setup of protection for

the previous path in the ring.

=A0

If for any reason folks feel that this may not be th= e case under some circumstances

this document should either address those cases or e= xplicitly state that they will not

be addressed by this document.

=A0

Alternatively, the issue may be addressed by simply = removing the 2nd sentence of

the "disclaimer" paragraph, or the cases e= xplicitly stated should be expressed as

"examples."

=A0<= /p>

yw>> How about if I change the text = of the second sentence to read:=A0 "Protection triggers on the transpo= rt path
=A0=A0 prior to the ring ingress node or beyond the egress nodes may be pro= tected by some other mechanism."?

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

Bullet 4 of section 1.3 is confusing as written.=A0 = The meaning of "LI" is clear enough,

but "LE" presents some problems.=A0 Suppos= e that PHP is used; in this case, there is

no label "expected" at the egress point fr= om the ring (although a label may be

present and will be used by the LSR at that point, t= hat label may not always be the

same label).

=A0

Is PHP never permitted?

= =A0

yw>> regarding this, I seem to r= ecall such a discussion regarding MPLS-TP and PHP.=A0 However, in any case= =A0if there is no such label, why couldn't LE=3Dnull? It is just being = presented for discussion, not as an actual label.=A0
=A0

=A0

Also, under what circumstances would the ring egress= point SPME exit LSR not

be the same?=A0 Based on subsequent reading, I belie= ve this would be the case for

use of an SPME to provide "Wrapping" prote= ction =96 it would probably therefore

be a good idea to either say something to this effec= t (if that is the case) or provide

a forward reference (to section 2.3.2, 2.3.3 and 2.3= .4, for example, or possibly

just to section 2.3).

=A0

I would suggest adding a sentence to this bullet, al= ong the lines of:

=A0

"See section 2.3 for examples of where the SPME= egress and ring exit might not

be the same."

=A0

=
yw>> How about if I=A0add ", for e= xample=A0as described in Section 2.3" to the parenthetical phrase?

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

Section 2 appears to ignore 1+1 protection, which wo= uld (similar to "Steering")

use pre-established protection paths from an ingress= LSR/node to each egress

LSR/node but would send that traffic both ways at al= l times.=A0

=A0

The main differences between this approach and Steer= ing are:

=A0

o=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the need to no= tify the ingress node is eliminated as a consideration for

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 protec= tion switching latency

o=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 there is (ther= efore) no reliance on the existence of a failure detection

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 method= that is able to notify the ingress of a failure in the ring<= /p>

o=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 double bandwid= th is required

=A0

This is carried forward in all subsequent sections/s= ubsections.

=A0

= yw>> 1+1 protection is a linear protection methodology, and Section 2= is describing basic Transport Network ring protection as defined in =A0the= ITU - which include Steering and Wrapping.=A0 1+1 does not seem to be popu= lar in rings, since historically SDH seemed to shun this alternative.=A0We = do reference 1+1 transmission in section 3.2 and in the conclusions.
=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

Sections 2.1 and 2.2 do not exactly provide an "= ;apples-to-apples" comparison

basis in the bullets relating to "consideration= s" in each subsection.=A0 In order to

allow this comparison, both sections would need to p= rovide an indication of the

order of protection paths required in a protec= tion domain.

=A0

Because =96 in the "Wrapping" case =96 it = is necessary to provide protection SPME

for each node and link (in a ring the number of link= s is exactly the same as the

number of nodes), the number of protection SPME is O= (2N).

=A0

For the "Steering" case, however, it is ne= cessary to provide protection SPME

for each ingress node to each egress node (except fo= r the last one) =96 which is

O(N^2).=A0 This statement is actually made in the in= troductory text in section 2.4.

=A0

I would suggest either adding a bullet in section 2.= 2 and including forward

references in these bullets to the analysis in secti= on 2.4, or removing the bullet

in section 2.1.

=A0

yw>> Could you please specify which bullet= you are suggesting to delete? Thanx=A0

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

Section 2.3 appears to assume that the desired prote= ction scheme will be based

on "Steering" rather than "Wrapping.&= quot;=A0 This assumption is made without any

effort/analysis to justify why this assumption is ma= de (at least as far as I can see).

=A0

If that is the intention, minimally, section 2.3 sho= uld start with a statement that

this is the assumption made.

=A0

Reading further, however, subsequent subsection 2.3.= 2 describes how the SPME

concept =96 as outlined in the introductory text of = section 2.3 =96 may be used for the

"Wrapping" approach.

=A0

The confusion arises as a result of figure 3 and the= text that describes it in the

preceding paragraph, as this figure/text is what mos= t contributes to an impression

that an SPME would start at the ingress and end at a= n egress.

=A0

I would suggest that this figure and the preceding p= aragraph would find a better

home on section 2.3.1.=A0 This would also align subs= ections of section 2.3 better as

there is a similar figure in section 2.3.2, 2.3.3 an= d 2.3.4.

=A0

yw&= gt;> Will move the paragraph and figure, as you suggest.=A0

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

The last paragraph in introductory text in section 2= .3 (immediately prior to the

start of section 2.3.1) appears to ignore the case w= here the egress LSR would

use labels to "steer" delivery of labeled = packets it receives over the SPME to

specific egress ports (of the egress LSR).=A0

=A0

These labels would most likely not be a part of the = label stack received by the

ingress LSR (there is no need for these labels to be= known outside of the ring)

and would have to be pushed onto the stack before pu= shing on the label for an

SPME to the egress LSR/node.

=A0
yw>> Do you have a suggestion on how better t= o include this consideration?=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

I believe the text in the last paragraph of section = 2.3.4 is incorrect in stating that

protected traffic might not share the same protectio= n path in both directions.

=A0

If both LSR-B and LSR-F detect that LSR-A is not ava= ilable, then both will use the

protection SPME between LSR-B and LSR-F.

=A0

If both LSR-A and LSR-E detect that LSR-F is not ava= ilable, then both will use the

protection SPME between LSR-A and LSR-E.

=A0

If both LSR-A and LSR-F detect that the link between= them is not available, then

both will use the protection SPME between them.

=A0

All that is required is that both LSRs in each case = agree as to the nature of the

failure (node or link) =96 which may be easily and c= onsistently determined by

monitoring the status of the working and protection = SPME.

=A0

While it is possible for the end-point LSRs in each = case to have an inconsistent

view of the nature of the failure, this inconsistenc= y should be short lived (based

on the periodicity of OAM monitoring of SPMEs).

=A0

Depending on the OAM monitoring periodicity used =96= and the length of links in

the ring =96 this inconsistency may exist for a peri= od of time that is less than the

latency to be expected for "Steering" base= d protection.

=A0

Note that this is a major issue with the cu= rrent text as it impacts on analysis in

subsequent section 2.4 and the conclusion/r= ecommendations of this document.

=A0<= /p>

yw>> This statement is the result of= review comments that we received during an earlier review of the document,= and I am wary of removing it from the document at this late stage in the r= eview process.=A0 In any case, there are other considerations for limiting = both types of protection.=A0 I am sure that your analysis is correct althou= gh I am not sure that I understand your emphatic objection to the text and = how it is related to the analysis in section 2.4.
=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

The analysis in section 2.4 is incomplete or based o= n an incorrect assertion made

in section 2.3.4.

=A0

If the alternative suggested in section 2.3.4 were u= sed, the number of SPME that

will be required would be O(4N) =96 which is still O= (N) and would be less than O(N^2)

for fewer than the 16-node limit assumption made for= the analysis.

=A0

yw>> = This is correct and is certainly correct when the comparison is between O(2= N) and O(N^2).=A0 Therefore=A0whether the=A0statement (reiterated in parent= hesis here) is correct or not does not really affect the conclusions.=A0 Th= is is based on the simplicity of Steering and the avoidance of wasted resou= rces by transmitting the traffic twice over certain links.
=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

In the 1st sentence of the last paragraph= in the introductory text of section 2.4,

the sentence mentions the use of additional resource= s but does not mention the

additional latency.

=A0

Is there any reason for the omission?

=A0

yw>> not really=A0

=A0

=A0

I suggest removing the text in this sentence that st= arts with "even though" as

it might otherwise be necessary to attempt an exhaus= tive list of detractions.

=A0

yw>> = I have no problem with this suggestion=A0

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

Also in the last paragraph of the introductory text = in section 2.4, I imagine that

the case where one or more pairs of SPME may be elim= inated because of LSRs

that are not ingress-egress pairs is most likely of = trivial value in any deployment

involving a ring topology.=A0

=A0

Perhaps the last sentence in the last paragraph of t= his text in section 2.4 could be

removed?

=A0

yw>> Again, I have no problem with this=A0
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-c= olor:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class= =3D"gmail_quote">

=A0

=A0

NITs:

=3D=3D=3D=3D

=A0

In the Introduction section, 5th bullet i= n (or after) the 2nd paragraph =96

=A0

=A0=A0 " Impact of signaling and routing inform= ation exchanged during

=A0=A0=A0=A0=A0 protection, in presence of control p= lane."

=A0

- the phrase "in presence of control plane"= ; should probably be "in the

presence of a control plane.&qu= ot;

=A0

yw>&= gt; will fix=A0

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

In the 2nd bullet in section 2.1, I belie= ve it is the case that O(2N) =3D O(N).

=A0=
yw>> while this is true, I think it is significant to ment= ion the=A02N=A0
=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

In the 1st paragraph of section 2.3.1, wh= ere it says "there is always an alternative

path =85" =96 at the SPME level (as described i= n this document), there's always exactly

one=A0 alternative path.

yw>> This is not 100% true.=A0 What is true=A0is = that there is exactly on alternative path within the ring (there may be add= itional alternatives that go outside the ring). This is why I did not origi= nally add the "exactly" in the first place.=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

In the 1st bullet in section 2.4, I belie= ve it is the case that O(2N^2) =3D O(N^2).

=A0

yw>> = see above, same applies to next statement.=A0

=A0

----------------------------------------------------= ---------------------------------------------------------

=A0

In the 1st and 2nd bullets in = section 2.4, I believe it is the case that O(2N) =3D O(N).

----------------------------------------------------= ---------------------------------------------------------

=A0

=A0

=A0

=A0




--
Thanx = and BR,
yaacov

Still looking for new opport= unity
--089e01183112514a4504da8e0220-- From cpignata@cisco.com Mon Apr 29 08:32:32 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1E221F9DFE; Mon, 29 Apr 2013 08:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xM1bX7LwO3U; Mon, 29 Apr 2013 08:32:31 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 098F921F9DDF; Mon, 29 Apr 2013 08:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15772; q=dns/txt; s=iport; t=1367249551; x=1368459151; h=from:to:cc:subject:date:message-id:mime-version; bh=KMFEolU1O1/uKedL/AeJc8o47q0OsdtIQ7wV+XU+XBM=; b=BGTVGBZFpviJrlcOCCk4KyQrpL0QTeMRQARwEjg/aGZsDg2IV0MDA6Zi ZlmgyitbNZ/9XSY9HUidsvSsT5sLf2xMYcBZvM+RRrCiP51dWrLs80vip a4/da454daQKSt+8C4ryJ+oWEQY4GQB76b9TvRfXp1ByBxHAwEwUAELL9 0=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwHACmSflGtJV2d/2dsb2JhbABJAgiDBza+QYEGFm0HgiEBBCdLBxIBHA4dORQTBA4DAggBBYgIDLtXjVYIBgp7IBECgnNhA49pgSmHMpAEgxFAgSoBHx4 X-IronPort-AV: E=Sophos;i="4.87,574,1363132800"; d="asc'?scan'208";a="204421095" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 29 Apr 2013 15:32:30 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3TFWU40017687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Apr 2013 15:32:30 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 10:32:29 -0500 From: "Carlos Pignataro (cpignata)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt Thread-Index: AQHORO7C2y3SdVUEW027VIOCZsJnvA== Date: Mon, 29 Apr 2013 15:32:29 +0000 Message-ID: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.8] Content-Type: multipart/signed; boundary="Apple-Mail=_928E38FA-CF0B-4B38-B59F-541EF53AF88B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org" , "netmod@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:32:32 -0000 --Apple-Mail=_928E38FA-CF0B-4B38-B59F-541EF53AF88B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-netmod-interfaces-cfg-10.txt Reviewer: Carlos Pignataro Review Date: 01 May 2013 IETF LC End Date: 03 May 2013 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be = resolved before publication. Comments: This document is very well written, and sensible. It certainly achieves = what its Abstract sets up to do, cleanly. Thank you for writing it!=20 However, I do believe that there are a few set of gaps that need to be = resolved before publication. I identify some localized major issues = below. Since I do not have context on some decisions that shaped the = document, an explanation of the rational might suffice if sensible. = Other of the identified issues, I believe, will require modifications or = textual clarifications. In particular, I have a couple general concerns, = about the generality of the data model defined in this document, details = below. I hope these review comments are clear and useful! Major Issues: 3. Interfaces Data Model =85 +--ro if-index? int32 The "?" indicates that the lead is optional. =46rom a routing = perspective, the if-index plays an important role when for example the = network layer address does not identify a specific interface (e.g., IP = unnumbered), or when there is no network layer address (LAG member, = etc.). Why is this optional? In which case you envision it would not be = present? Additionally, a stronger relationship or at least a more detailed = description of the relationship with ifIndex would help interoperable = implementations. Does this "if-index" leaf follow ifIndex if it changes = upon reload of interface recreation? It seems from the definition that = it is the same? 3. Interfaces Data Model =85 +--rw location? string ... 3.1. The interface List =85 The "location" leaf is a string. It is optional in the data model, but if the type represents a physical interface, it is mandatory. The format of this string is device- and type-dependent. The device uses the location string to identify the physical or logical entity that the configuration applies to. For example, if a device has a single array of 8 ethernet ports, the location can be one of the strings "1" to "8". As another example, if a device has N cards of M ports, the location can be on the form "n/m", such as "1/0". I think that "location" is a poorly chosen label, a misnomer. This seems = to be closer to an identifier than a locator. For example, some devices = number slots left to right, and some number slots right to left :-) This = does not answer "where" something is; I do not mean geo-location, but I = strongly suggest getting more precision on how this leaf is called. For = example, interface numbering, instance id, type identifier, etc. 3. Interfaces Data Model =85 +--rw interfaces +--rw interface [name] +--rw =85 Is there a specific reason why there is no lead with the interface's = MTU? It is quite important from a routing perspective for some = protocols. MTU is not included even in the examples of ethernet-specific = data models augmenting this base spec and appendices, which leaves it a = bit underspecified=85 General: As a general major comment: it is not clear how general or how specific = this definition and document is. In terms of the definition, this definition does not include information = that applies to all interfaces (e.g., MTU), but it does include very = specific non-general things like is_promiscuous. What is the information = model on which this data model stands? If there was not RFC 2863, would = a leaf be defined as ifPromiscuousMode or phys-address? Or would that = belong in an ethernet-specific module? In terms of the examples, basically all examples are some form of = ethernet interface. For a document that aims at being general for = managing network interfaces, this choice seems not inclusive. Minor Issues: 2. Objectives ... o The data model should support the pre-provisioning of interface configuration, i.e., it should be possible to configure an interface whose physical interface hardware is not present on the device. It is recommended that devices that support dynamic addition and removal of physical interfaces also support pre- provisioning. It is interesting that these design criteria do not call out the = applicability to "physical" and "virtual" interfaces. Moreover, the text = above seems to imply that the only "dynamic creation and deletion" of = interfaces happens with the "addition and removal of physical = interfaces" and does not call out tunnels, loopbacks, virtuals, and = other logical entities instantiated as "interfaces". 3. Interfaces Data Model Do some of the strings need to be described as maximum access parameter? = Some rw attributes cannot be changed in all practical terms. The "type" = leaf is RW. However, with what applicability (different speeds of = "ethernet", different serials, how can it be changed)? 3. Interfaces Data Model =85 +--rw enabled? boolean +--ro oper-status? enumeration I would have expected these two not to be optional ("?"). 3. Interfaces Data Model =85 +--rw interfaces +--rw interface [name] +--ro statistics +--ro in-discards? yang:counter32 +--ro in-errors? yang:counter32 +--ro in-unknown-protos? yang:counter32 +--ro out-discards? yang:counter32 +--ro out-errors? yang:counter32 It seems like some statistics are counter32 while others are counter64. = The ones that are counter64 seem to coincide with the ones that have HC = (High Capacity) counters in RFC 2863 (this is from memory, might be = incorrect). Is that the reason? Is there any (other) specific reason why = these are 32-bit counters while the rest of the statistics are 64 bit = counters? I do wonder, however, if these should still be defined here as = 64 bit... 4. Relationship to the IF-MIB =85 The following table lists the YANG data nodes with corresponding objects in the IF-MIB. ... Mapping of YANG data nodes to IF-MIB objects This section explains how name cannot always map to ifName. However, the = table shows a 1:1 mapping of name <-> ifName. I suggest marking with a = footnote or "*" the elements that might not always may 1:1. For example, "enabled" also cannot map to ifAdminStatus. "enabled" is a = boolean, and ifAdminStatus is an INTEGER with at least 3 values = specified (up, down, testing).=20 In summary, which ones map 1:1 and which ones do not? 4. Relationship to the IF-MIB =85 | description | ifAlias | This is also a bit confusing -- the "description" maps to the ifAlias, = and nothing maps to ifDescr. 4. Relationship to the IF-MIB The IF-MIB also defines the writable object ifPromiscuousMode. Since this object typically is not a configuration object, it is not mapped to the "ietf-interfaces" module. ifPromiscuousMode can actually be changed in many cases. Is that the = only reason why attributes are being mapped to the "ietf-interfaces" = module or not? 5. Interfaces YANG Module ... organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; contact "WG Web: WG List: WG Chair: David Kessens Does the definition of the module, anchoring on a Working Group, put = requirements or constraints on the existence of netmod? Meaning: what = happens to these pointers when the WG ceases to exist, and the maling = list is locked? Perhaps this is the usual way of defining contact for = the YANG modules, but I suspect a time invariant pointer would help. =85 leaf name { type string; description "The name of the interface. A device MAY restrict the allowed values for this leaf, possibly depending on the type and location. If the device allows arbitrarily named interfaces, the feature 'arbitrary-names' is advertised. This leaf MAY be mapped to ifName by an implementation. Such an implementation MAY restrict the allowed values for this leaf so that it matches the restrictions of ifName. If a NETCONF server that implements this restriction is sent a value that doesn't match the restriction, it MUST reply with an rpc-error with the error-tag 'invalid-value'."; Should the description of a YANG leaf be tied to NETCONF? Or are there = potential uses outside NETCONF? Please note that although this comment = is made once, it applies to all the descriptions that say "If a NETCONF = server=85", as there are quite a number of these. leaf location { type string; description "The device-specific location of the interface of a particular type. The format of the location string As mentioned above, this is not a "location". leaf phys-address { type yang:phys-address; config false; description "The interface's address at its protocol sub-layer. For example, for an 802.x interface, this object normally contains a MAC address. The interface's media-specific modules must define the bit and byte ordering and the format of the value of this object. For interfaces that do not have such an address (e.g., a serial line), this node is not present."; reference "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; } Just by reading the description of this leaf, shouldn't this be part of = an augmentation type-specific module? For example, for an Ethernet = interface module, instead of the main YANG interface management = top-level. Meaning: this specific leaf, by definition, cannot be = generically specified to what it means for each type of interfaces. All = the others can=85 if this cannot be specified outside a media-specific = module, why define it here? leaf oper-status { type enumeration { =85 The description of the leaf as well as the enum values for the = oper-status seem to be a bit under-defined. For example, "Ready to pass = packets" seems too literal from the MIB, while I believe there are more = precise definitions. Also, the description is actually listing usage of = values instead of a real description. 7. Security Considerations The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242]. Are there security considerations for other aspects of this language = definition? For example, what if YANG is used via a different method? = What about storage of the data? What about AAA aspects for RW or RO = leafs? 9.1. Normative References [I-D.ietf-netmod-iana-if-type] This document points normatively to draft-ietf-netmod-iana-if-type-02. = However, there are four additional revisions to the document and a most = recent that is a year later than draft-ietf-netmod-iana-if-type-02. = While things should be in sync given a common author and a hard = dependency, just calling it out here since there are a few differences = between those revisions of the normative reference: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-if-type-06.txt= &url1=3Ddraft-ietf-netmod-iana-if-type-02.txt Appendix A. Example: Ethernet Interface Module Do these appendices need to explicitly say that are non-normative? I = would add a one-liner about it. Appendix A. Example: Ethernet Interface Module This applies to all appendices. I find it a bit incomplete that a = specification for a language for "Interface Management" chose to ignore = the richness of types of interfaces to show in the appendices :-) = Basically, all of the ten (I think) different examples in the appendices = are about Ethernet interfaces. While there is nothing underspecified, it = is under-exemplified. How would a serial interface with sub interfaces = loop like? How about a GRE Tunnel interface? Or a point-to-point = satellite? Or a 3G interface? Or =85=20 Nits:=20 2. Objectives ... o The model must support interface layering, both simple layering where one interface is layered on top of exactly one other interface, and more complex scenarios where one interface is aggregated over N other interfaces, or when N interfaces are multiplexed over one other interface. This is a nit: are "aggregated" and "multiplexed" the right words here? = I believe I understand what is meant, but at the same time, it's not = clear how "one interface" can be "aggregated" (i.e., aggregate a = plurality/collection of elements into one). Perhaps: "and more complex = scenarios where one interface results from the aggregation of N other = interfaces, or when N interfaces are multiplexed over one other = interface."? 5. Interfaces YANG Module leaf oper-status { type enumeration { =85 The description of the leaf as well as the enum values for the = oper-status seem to be a bit under-defined. For example, "Ready to pass = packets" seems too literal from the MIB, while I believe there are more = precise definitions (s/packets/traffic/ at least?). Also, the = description is actually listing usage of values instead of a real = description. I hope these are clear and useful! Thank you, Carlos Pignataro. --Apple-Mail=_928E38FA-CF0B-4B38-B59F-541EF53AF88B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iEYEARECAAYFAlF+ko0ACgkQtfDPGTp3USzkIgCfXK+mBxl7Xea+SUQidSrOSdXp WKEAn3pQrDuA4eHTI0WQlF87ivPEIM6a =kzhO -----END PGP SIGNATURE----- --Apple-Mail=_928E38FA-CF0B-4B38-B59F-541EF53AF88B-- From mbj@tail-f.com Mon Apr 29 13:46:50 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0298221F9A79; Mon, 29 Apr 2013 13:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJMkqe0qdJue; Mon, 29 Apr 2013 13:46:45 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C47CB21F9A58; Mon, 29 Apr 2013 13:46:44 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 913411200089; Mon, 29 Apr 2013 22:46:42 +0200 (CEST) Date: Mon, 29 Apr 2013 22:46:41 +0200 (CEST) Message-Id: <20130429.224641.08727383.mbj@tail-f.com> To: cpignata@cisco.com From: Martin Bjorklund In-Reply-To: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com> References: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 29 Apr 2013 13:52:13 -0700 Cc: rtg-dir@ietf.org, draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, netmod@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 20:46:50 -0000 Hi, Thank you for your detailed review! Comments inline. "Carlos Pignataro (cpignata)" wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing > ADs. For more information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > > Document: draft-ietf-netmod-interfaces-cfg-10.txt > Reviewer: Carlos Pignataro > Review Date: 01 May 2013 > IETF LC End Date: 03 May 2013 > Intended Status: Proposed Standard > > Summary: > > I have some minor concerns about this document that I think should be resolved > before publication. > > Comments: > > This document is very well written, and sensible. It certainly achieves what > its Abstract sets up to do, cleanly. Thank you for writing it! > > However, I do believe that there are a few set of gaps that need to be resolved > before publication. I identify some localized major issues below. Since I do > not have context on some decisions that shaped the document, an explanation of > the rational might suffice if sensible. Other of the identified issues, I > believe, will require modifications or textual clarifications. In particular, I > have a couple general concerns, about the generality of the data model defined > in this document, details below. > > I hope these review comments are clear and useful! > > > Major Issues: > > 3. Interfaces Data Model > … > +--ro if-index? int32 > > The "?" indicates that the lead is optional. From a routing perspective, the > if-index plays an important role when for example the network layer address > does not identify a specific interface (e.g., IP unnumbered), or when there is > no network layer address (LAG member, etc.). Why is this optional? In which > case you envision it would not be present? I think you are right; this leaf should be mandatory. This works since it has an 'if-feature' statement. But I would like to understand what role ifIndex plays - do you have any pointers? > Additionally, a stronger relationship or at least a more detailed description > of the relationship with ifIndex would help interoperable implementations. Does > this "if-index" leaf follow ifIndex if it changes upon reload of interface > recreation? It seems from the definition that it is the same? Yes, that is the intention. The description says: The ifIndex value for the ifEntry represented by this interface. > 3. Interfaces Data Model > … > +--rw location? string > ... > 3.1. The interface List > … > The "location" leaf is a string. It is optional in the data model, > but if the type represents a physical interface, it is mandatory. > The format of this string is device- and type-dependent. The device > uses the location string to identify the physical or logical entity > that the configuration applies to. For example, if a device has a > single array of 8 ethernet ports, the location can be one of the > strings "1" to "8". As another example, if a device has N cards of M > ports, the location can be on the form "n/m", such as "1/0". > > I think that "location" is a poorly chosen label, a misnomer. This seems to be > closer to an identifier than a locator. For example, some devices number slots > left to right, and some number slots right to left :-) Correct, and we do not try to get into this at all. Some devices has 2 ports called A and B, and some have chassis of cards with rows of ports... > This does not answer > "where" something is; I do not mean geo-location, but I strongly suggest > getting more precision on how this leaf is called. For example, interface > numbering, instance id, type identifier, etc. The intention is really to be "where" the port is. It is not intended to be a virtual id. If the operator plugs in a cable in a certain port, he has to know how to configure this port so there must be something in the config that connects to the physical port. We use the name "location" for this purpose. > 3. Interfaces Data Model > … > +--rw interfaces > +--rw interface [name] > +--rw … > > Is there a specific reason why there is no lead with the interface's MTU? It is > quite important from a routing perspective for some protocols. MTU is not > included even in the examples of ethernet-specific data models augmenting this > base spec and appendices, which leaves it a bit underspecified… The mtu is specified in an accompanying document draft-ietf-netmod-ip. > General: > > As a general major comment: it is not clear how general or how specific this > definition and document is. It is a generic model. We tried to capture the intention in the Introduction: This document defines a YANG ^RFC6020^ data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. > In terms of the definition, this definition does not include information that > applies to all interfaces (e.g., MTU), but it does include very specific > non-general things like is_promiscuous. Actually, ifPromiscuousMode is not part of this model. > What is the information model on which > this data model stands? If there was not RFC 2863, would a leaf be defined as > ifPromiscuousMode or phys-address? Or would that belong in an ethernet-specific > module? You are right that phys-address might not have been included. > In terms of the examples, basically all examples are some form of ethernet > interface. For a document that aims at being general for managing network > interfaces, this choice seems not inclusive. > > > Minor Issues: > > 2. Objectives > ... > o The data model should support the pre-provisioning of interface > configuration, i.e., it should be possible to configure an > interface whose physical interface hardware is not present on the > device. It is recommended that devices that support dynamic > addition and removal of physical interfaces also support pre- > provisioning. > > It is interesting that these design criteria do not call out the applicability > to "physical" and "virtual" interfaces. Moreover, the text above seems to imply > that the only "dynamic creation and deletion" of interfaces happens with the > "addition and removal of physical interfaces" and does not call out tunnels, > loopbacks, virtuals, and other logical entities instantiated as "interfaces". I think you are reading too much into the statement above. It says that IF you support addition and removal of physical interfaces, then ... This does NOT mean that devices cannot support tunnels, loobacks etc. But maybe I misunderstood your point. > 3. Interfaces Data Model > > Do some of the strings need to be described as maximum access parameter? Some > rw attributes cannot be changed in all practical terms. The "type" leaf is > RW. However, with what applicability (different speeds of "ethernet", different > serials, how can it be changed)? Implementations that cannot for some reason support changing certain parameters simply won't support it. But that's not a reason for the standard to not support it. In general, there is nothing wrong in changing the type of an interface in the configuration - if there's physical hardware that doesn't match the type at the moment, the oper-status will be 'not-present'. > 3. Interfaces Data Model > … > +--rw enabled? boolean > +--ro oper-status? enumeration > > I would have expected these two not to be optional ("?"). Actually, 'enabled' has a default value, so that's why it is marked as optional. For oper-status I believe you are right; since it has the state 'unknown' it does not have to be optional. I think we should change this. > 3. Interfaces Data Model > … > +--rw interfaces > +--rw interface [name] > +--ro statistics > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > It seems like some statistics are counter32 while others are counter64. The > ones that are counter64 seem to coincide with the ones that have HC (High > Capacity) counters in RFC 2863 (this is from memory, might be incorrect). Is > that the reason? Yes. > Is there any (other) specific reason why these are 32-bit > counters while the rest of the statistics are 64 bit counters? I do wonder, > however, if these should still be defined here as 64 bit... The idea was that 64 bits are probably not needed for these counters. > 4. Relationship to the IF-MIB > … > The following table lists the YANG data nodes with corresponding > objects in the IF-MIB. > ... > Mapping of YANG data nodes to IF-MIB objects > > This section explains how name cannot always map to ifName. However, the table > shows a 1:1 mapping of name <-> ifName. I suggest marking with a footnote or > "*" the elements that might not always may 1:1. > > For example, "enabled" also cannot map to ifAdminStatus. "enabled" is a > boolean, and ifAdminStatus is an INTEGER with at least 3 values specified (up, > down, testing). > > In summary, which ones map 1:1 and which ones do not? This table is supposed to be an overview. I think I would prefer to add a sentence that says something like "For details about thae mappings, please see the corresponding definition in the YANG module". > 4. Relationship to the IF-MIB > … > | description | ifAlias | > > This is also a bit confusing -- the "description" maps to the ifAlias, and > nothing maps to ifDescr. Yes, this is b/c ifDescr is a read-only object defined as: This string should include the name of the manufacturer, the product name and the version of the interface hardware/software. The only reason the "description" leaf is mapped to ifAlias is b/c this is what many implementations do. So we wanted to point out the differences in the value space for these objects so that implementers are aware of this. > 4. Relationship to the IF-MIB > > The IF-MIB also defines the writable object ifPromiscuousMode. Since > this object typically is not a configuration object, it is not mapped > to the "ietf-interfaces" module. > > ifPromiscuousMode can actually be changed in many cases. Right, but it is not typically a configuration parameter. > Is that the only > reason why attributes are being mapped to the "ietf-interfaces" module or not? I wouldn't say that, bur for this particular object, the WG felt it should be left out. > 5. Interfaces YANG Module > ... > organization > "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; > > contact > "WG Web: > WG List: > > WG Chair: David Kessens > > > Does the definition of the module, anchoring on a Working Group, put > requirements or constraints on the existence of netmod? Meaning: what happens > to these pointers when the WG ceases to exist, and the maling list is locked? > Perhaps this is the usual way of defining contact for the YANG modules, but I > suspect a time invariant pointer would help. This also seems to be the usual way of defining contact info in MIBs... > … > leaf name { > type string; > description > "The name of the interface. > > A device MAY restrict the allowed values for this leaf, > possibly depending on the type and location. > > If the device allows arbitrarily named interfaces, the > feature 'arbitrary-names' is advertised. > > This leaf MAY be mapped to ifName by an implementation. > Such an implementation MAY restrict the allowed values for > this leaf so that it matches the restrictions of ifName. > If a NETCONF server that implements this restriction is > sent a value that doesn't match the restriction, it MUST > reply with an rpc-error with the error-tag > 'invalid-value'."; > > Should the description of a YANG leaf be tied to NETCONF? Or are there > potential uses outside NETCONF? Currently the only standardized usage is NETCONF. But vendors use YANG for other purposes, and there's an individual draft that use YANG for a RESTful api. But the sentence really just specifies what a NETCONF server would do. It would be difficult to write this in a generic way, and at the same time it is useful to specify this for NETCONF implementations. > Please note that although this comment is made > once, it applies to all the descriptions that say "If a NETCONF server…", as > there are quite a number of these. Yes, but it is only used when we specify the NETCONF protocol behavior. > leaf location { > type string; > description > "The device-specific location of the interface of a > particular type. The format of the location string > > As mentioned above, this is not a "location". > > leaf phys-address { > type yang:phys-address; > config false; > description > "The interface's address at its protocol sub-layer. For > example, for an 802.x interface, this object normally > contains a MAC address. The interface's media-specific > modules must define the bit and byte ordering and the > format of the value of this object. For interfaces that do > not have such an address (e.g., a serial line), this node > is not present."; > reference > "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; > } > > Just by reading the description of this leaf, shouldn't this be part of an > augmentation type-specific module? For example, for an Ethernet interface > module, instead of the main YANG interface management top-level. Meaning: this > specific leaf, by definition, cannot be generically specified to what it means > for each type of interfaces. All the others can… if this cannot be specified > outside a media-specific module, why define it here? See above - I think the reason is the relation to ifPhysAddress. > > leaf oper-status { > type enumeration { > … > > The description of the leaf as well as the enum values for the oper-status seem > to be a bit under-defined. For example, "Ready to pass packets" seems too > literal from the MIB Yes. > while I believe there are more precise definitions. Also, > the description is actually listing usage of values instead of a real > description. > > 7. Security Considerations > > > The YANG module defined in this memo is designed to be accessed via > the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the > secure transport layer and the mandatory-to-implement secure > transport is SSH [RFC6242]. > > Are there security considerations for other aspects of this language > definition? For example, what if YANG is used via a different method? What > about storage of the data? What about AAA aspects for RW or RO leafs? The WG recently added a note about AAA aspects to the Security Considerations template for YANG modules. I will update this document as well with the new text. > 9.1. Normative References > > [I-D.ietf-netmod-iana-if-type] > > This document points normatively to draft-ietf-netmod-iana-if-type-02. However, > there are four additional revisions to the document and a most recent that is a > year later than draft-ietf-netmod-iana-if-type-02. While things should be in > sync given a common author and a hard dependency, just calling it out here > since there are a few differences between those revisions of the normative > reference: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-iana-if-type-06.txt&url1=draft-ietf-netmod-iana-if-type-02.txt These documents are advanced together; but you are right, the reference is pretty old. I simply forgot to update it. > Appendix A. Example: Ethernet Interface Module > > Do these appendices need to explicitly say that are non-normative? I would add > a one-liner about it. Ok... but are examples ever normative? > Appendix A. Example: Ethernet Interface Module > > This applies to all appendices. I find it a bit incomplete that a specification > for a language for "Interface Management" chose to ignore the richness of types > of interfaces to show in the appendices :-) Basically, all of the ten (I think) > different examples in the appendices are about Ethernet interfaces. While there > is nothing underspecified, it is under-exemplified. How would a serial > interface with sub interfaces loop like? How about a GRE Tunnel interface? Or a > point-to-point satellite? Or a 3G interface? Or … It is always tricky with examples... In this case we wanted to examplify different features of the model, and we picked examples that build on each other. > Nits: > > 2. Objectives > ... > o The model must support interface layering, both simple layering > where one interface is layered on top of exactly one other > interface, and more complex scenarios where one interface is > aggregated over N other interfaces, or when N interfaces are > multiplexed over one other interface. > > This is a nit: are "aggregated" and "multiplexed" the right words here? I > believe I understand what is meant, but at the same time, it's not clear how > "one interface" can be "aggregated" (i.e., aggregate a plurality/collection of > elements into one). Perhaps: "and more complex scenarios where one interface > results from the aggregation of N other interfaces, or when N interfaces are > multiplexed over one other interface."? Yes, this is much better. Thanks for the suggestion! > 5. Interfaces YANG Module > > leaf oper-status { > type enumeration { > … > > The description of the leaf as well as the enum values for the oper-status seem > to be a bit under-defined. For example, "Ready to pass packets" seems too > literal from the MIB, while I believe there are more precise definitions > (s/packets/traffic/ at least?). Also, the description is actually listing usage > of values instead of a real description. [this seems to be a duplicate comment] > I hope these are clear and useful! It was; thank you! /martin From cpignata@cisco.com Mon Apr 29 16:03:11 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB9021F9820; Mon, 29 Apr 2013 16:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8+-szYpOFDO; Mon, 29 Apr 2013 16:02:54 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 07FF521F9B8D; Mon, 29 Apr 2013 16:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24255; q=dns/txt; s=iport; t=1367276566; x=1368486166; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SkbFE1fhTSYzqgsjY7QUFwEgGqAF9WhZAKLxLPAeRrE=; b=TY8MvYLHTobxe2dd0KAzPPtcJ4u7XwIWX6m2fkbca5q+Mb8+1MobwOT2 /J4vu5MUDRGtHDtnLf74/7Rkm1+27DlRYlZSsginlyseV3eRoptFiygtD edVS3wSOuvg9OA2Xr/UMNGAXyHvOteueG9HeIkZ5vxD6UXSxocvRcXGUM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAGj6flGtJV2a/2dsb2JhbABIAgiDBzaDN7sYgQYWdIIfAQEBAwEaBwEFSwcFCwIBCA4GBAEDBgUYAgMCMhQRAgQOAwIIAYgHBgyTDpsDAZBwgSCMNggGCnkCMQIFZIFVNWEDmESQBIMEDUCBKgEfHg X-IronPort-AV: E=Sophos;i="4.87,576,1363132800"; d="scan'208";a="204308915" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 29 Apr 2013 23:02:45 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3TN2idq028497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Apr 2013 23:02:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 18:02:44 -0500 From: "Carlos Pignataro (cpignata)" To: Martin Bjorklund Thread-Topic: RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt Thread-Index: AQHORO7C2y3SdVUEW027VIOCZsJnvJjt/0GAgAAmAoA= Date: Mon, 29 Apr 2013 23:02:44 +0000 Message-ID: <95067C434CE250468B77282634C96ED322AF7636@xmb-aln-x02.cisco.com> References: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com> <20130429.224641.08727383.mbj@tail-f.com> In-Reply-To: <20130429.224641.08727383.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <156DB78B2B75754DBA6CAD1DA12DBE58@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , "" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 23:03:11 -0000 Hi, Martin, Thanks for the quick response! Please find some follow-ups inline. I believ= e some items are closed, but others need further discussion. On Apr 29, 2013, at 4:46 PM, Martin Bjorklund wrote: > Hi, >=20 > Thank you for your detailed review! Comments inline. >=20 > "Carlos Pignataro (cpignata)" wrote: >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this draft.= The >> Routing Directorate seeks to review all routing or routing-related draft= s as >> they pass through IETF last call and IESG review, and sometimes on speci= al >> request. The purpose of the review is to provide assistance to the Routi= ng >> ADs. For more information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >>=20 >> Although these comments are primarily for the use of the Routing ADs, it= would >> be helpful if you could consider them along with any other IETF Last Cal= l >> comments that you receive, and strive to resolve them through discussion= or by >> updating the draft. >>=20 >> Document: draft-ietf-netmod-interfaces-cfg-10.txt >> Reviewer: Carlos Pignataro >> Review Date: 01 May 2013 >> IETF LC End Date: 03 May 2013 >> Intended Status: Proposed Standard >>=20 >> Summary: >>=20 >> I have some minor concerns about this document that I think should be re= solved >> before publication. >>=20 >> Comments: >>=20 >> This document is very well written, and sensible. It certainly achieves = what >> its Abstract sets up to do, cleanly. Thank you for writing it! >>=20 >> However, I do believe that there are a few set of gaps that need to be r= esolved >> before publication. I identify some localized major issues below. Since = I do >> not have context on some decisions that shaped the document, an explanat= ion of >> the rational might suffice if sensible. Other of the identified issues, = I >> believe, will require modifications or textual clarifications. In partic= ular, I >> have a couple general concerns, about the generality of the data model d= efined >> in this document, details below. >>=20 >> I hope these review comments are clear and useful! >>=20 >>=20 >> Major Issues: >>=20 >> 3. Interfaces Data Model >> =1B$B!D=1B(B >> +--ro if-index? int32 >>=20 >> The "?" indicates that the lead is optional. From a routing perspective,= the >> if-index plays an important role when for example the network layer addr= ess >> does not identify a specific interface (e.g., IP unnumbered), or when th= ere is >> no network layer address (LAG member, etc.). Why is this optional? In wh= ich >> case you envision it would not be present? >=20 > I think you are right; this leaf should be mandatory. This works > since it has an 'if-feature' statement. >=20 Thanks. Even if it works because of the clause, I'd make this mandatory. > But I would like to understand what role ifIndex plays - do you have > any pointers? >=20 Sure, you can grep for ifIndex in RFC 2328 (OSPFv2), e.g., Section 12.4.1.1= ., or RFC 5837. >> Additionally, a stronger relationship or at least a more detailed descri= ption >> of the relationship with ifIndex would help interoperable implementation= s. Does >> this "if-index" leaf follow ifIndex if it changes upon reload of interfa= ce >> recreation? It seems from the definition that it is the same? >=20 > Yes, that is the intention. The description says: >=20 > The ifIndex value for the ifEntry represented by this > interface. >=20 Ack.=20 >> 3. Interfaces Data Model >> =1B$B!D=1B(B >> +--rw location? string >> ... >> 3.1. The interface List >> =1B$B!D=1B(B >> The "location" leaf is a string. It is optional in the data model, >> but if the type represents a physical interface, it is mandatory. >> The format of this string is device- and type-dependent. The device >> uses the location string to identify the physical or logical entity >> that the configuration applies to. For example, if a device has a >> single array of 8 ethernet ports, the location can be one of the >> strings "1" to "8". As another example, if a device has N cards of M >> ports, the location can be on the form "n/m", such as "1/0". >>=20 >> I think that "location" is a poorly chosen label, a misnomer. This seems= to be >> closer to an identifier than a locator. For example, some devices number= slots >> left to right, and some number slots right to left :-) >=20 > Correct, and we do not try to get into this at all. Some > devices has 2 ports called A and B, and some have chassis of cards > with rows of ports... >=20 >> This does not answer >> "where" something is; I do not mean geo-location, but I strongly suggest >> getting more precision on how this leaf is called. For example, interfac= e >> numbering, instance id, type identifier, etc. >=20 > The intention is really to be "where" the port is. It is not intended > to be a virtual id. If the operator plugs in a cable in a certain > port, he has to know how to configure this port so there must be > something in the config that connects to the physical port. We use > the name "location" for this purpose. Thanks for the explanation. While I appreciate (and I agree) that you do no= t get into interpreting or parsing the syntax of the field, I still think i= t is not a "location". I believe there is still an underlying assumption that the language is defi= ned for the physical world. If you have an Ethernet1/0, versus an Ethernet1= /2, that identifies (not locates) which interface. Yes, you can use that to= physically find them. But what if you have a "loopback123" vs "loopback112= 358 or a "Serial1/4:5.123"? I do not think we can "locate" the loopback, or= the subinterface. If the operator creates a "loopback", "Tunnel", or virtual interface, he or= she does not need to physically locate it. I believe that labeling the leaf as "location" can be harmful as it implies= a specific meaning and shows assumptions.=20 >=20 >> 3. Interfaces Data Model >> =1B$B!D=1B(B >> +--rw interfaces >> +--rw interface [name] >> +--rw =1B$B!D=1B(B >>=20 >> Is there a specific reason why there is no lead with the interface's MTU= ? It is >> quite important from a routing perspective for some protocols. MTU is no= t >> included even in the examples of ethernet-specific data models augmentin= g this >> base spec and appendices, which leaves it a bit underspecified=1B$B!D=1B= (B >=20 > The mtu is specified in an accompanying document draft-ietf-netmod-ip. >=20 What draft-ietf-netmod-ip describes is the network-layer IPv4 MTU and IPv6 = MTU. It does not describe the interface MTU. If that interface is used to r= un IS-IS, or to run MPLS, what is the MTU? It's neither the IPv4 MTU nor th= e IPv6 MTU. >=20 >> General: >>=20 >> As a general major comment: it is not clear how general or how specific = this >> definition and document is. >=20 > It is a generic model. We tried to capture the intention in the > Introduction: >=20 > This document defines a YANG ^RFC6020^ data model for the management > of network interfaces. It is expected that interface type specific > data models augment the generic interfaces data model defined in > this document. This is great, I agree with this intention and scope. My comment however wa= s that the examples and some leafs specified make it more specific for some= interfaces than others. >=20 >> In terms of the definition, this definition does not include information= that >> applies to all interfaces (e.g., MTU), but it does include very specific >> non-general things like is_promiscuous. >=20 > Actually, ifPromiscuousMode is not part of this model. >=20 You are correct, thank you. Sorry my bad. >> What is the information model on which >> this data model stands? If there was not RFC 2863, would a leaf be defin= ed as >> ifPromiscuousMode or phys-address? Or would that belong in an ethernet-s= pecific >> module? >=20 > You are right that phys-address might not have been included. >=20 OK, thanks. Do you mean that you will be removing it? >> In terms of the examples, basically all examples are some form of ethern= et >> interface. For a document that aims at being general for managing networ= k >> interfaces, this choice seems not inclusive. >>=20 >>=20 >> Minor Issues: >>=20 >> 2. Objectives >> ... >> o The data model should support the pre-provisioning of interface >> configuration, i.e., it should be possible to configure an >> interface whose physical interface hardware is not present on the >> device. It is recommended that devices that support dynamic >> addition and removal of physical interfaces also support pre- >> provisioning. >>=20 >> It is interesting that these design criteria do not call out the applica= bility >> to "physical" and "virtual" interfaces. Moreover, the text above seems t= o imply >> that the only "dynamic creation and deletion" of interfaces happens with= the >> "addition and removal of physical interfaces" and does not call out tunn= els, >> loopbacks, virtuals, and other logical entities instantiated as "interfa= ces". >=20 > I think you are reading too much into the statement above. It says > that IF you support addition and removal of physical interfaces, then > ... This does NOT mean that devices cannot support tunnels, loobacks > etc. But maybe I misunderstood your point. >=20 I was not clear. Yes, that is an important statement. I was suggesting that= an addition of something like this would help: "o The dat amodel should support virtual interfaces as well as physical int= erfaces blah blah". >=20 >> 3. Interfaces Data Model >>=20 >> Do some of the strings need to be described as maximum access parameter?= Some >> rw attributes cannot be changed in all practical terms. The "type" leaf = is >> RW. However, with what applicability (different speeds of "ethernet", di= fferent >> serials, how can it be changed)? >=20 > Implementations that cannot for some reason support changing certain > parameters simply won't support it. But that's not a reason for the > standard to not support it. In general, there is nothing wrong in > changing the type of an interface in the configuration - if there's > physical hardware that doesn't match the type at the moment, the > oper-status will be 'not-present'. Fair enough. Thank you. >=20 >> 3. Interfaces Data Model >> =1B$B!D=1B(B >> +--rw enabled? boolean >> +--ro oper-status? enumeration >>=20 >> I would have expected these two not to be optional ("?"). >=20 > Actually, 'enabled' has a default value, so that's why it is marked as > optional. For oper-status I believe you are right; since it has the > state 'unknown' it does not have to be optional. I think we should > change this. Perfect. Thank you. >=20 >> 3. Interfaces Data Model >> =1B$B!D=1B(B >> +--rw interfaces >> +--rw interface [name] >> +--ro statistics >> +--ro in-discards? yang:counter32 >> +--ro in-errors? yang:counter32 >> +--ro in-unknown-protos? yang:counter32 >> +--ro out-discards? yang:counter32 >> +--ro out-errors? yang:counter32 >>=20 >> It seems like some statistics are counter32 while others are counter64. = The >> ones that are counter64 seem to coincide with the ones that have HC (Hig= h >> Capacity) counters in RFC 2863 (this is from memory, might be incorrect)= . Is >> that the reason? >=20 > Yes. >=20 OK. >> Is there any (other) specific reason why these are 32-bit >> counters while the rest of the statistics are 64 bit counters? I do wond= er, >> however, if these should still be defined here as 64 bit... >=20 > The idea was that 64 bits are probably not needed for these counters. >=20 I tend to disagree with this. But as long as the WG explicitly discussed it= (as opposed to blindly carry it over from the MIB). >> 4. Relationship to the IF-MIB >> =1B$B!D=1B(B >> The following table lists the YANG data nodes with corresponding >> objects in the IF-MIB. >> ... >> Mapping of YANG data nodes to IF-MIB objects >>=20 >> This section explains how name cannot always map to ifName. However, the= table >> shows a 1:1 mapping of name <-> ifName. I suggest marking with a footnot= e or >> "*" the elements that might not always may 1:1. >>=20 >> For example, "enabled" also cannot map to ifAdminStatus. "enabled" is a >> boolean, and ifAdminStatus is an INTEGER with at least 3 values specifie= d (up, >> down, testing). >>=20 >> In summary, which ones map 1:1 and which ones do not? >=20 > This table is supposed to be an overview. I think I would prefer to > add a sentence that says something like "For details about thae > mappings, please see the corresponding definition in the YANG module". No. I think that the table is a bit misleading when it says it described th= e "Mapping of YANG data nodes to IF-MIB objects", but some of these are rel= ated but do not really map. >=20 >> 4. Relationship to the IF-MIB >> =1B$B!D=1B(B >> | description | ifAlias | >>=20 >> This is also a bit confusing -- the "description" maps to the ifAlias, a= nd >> nothing maps to ifDescr. >=20 > Yes, this is b/c ifDescr is a read-only object defined as: >=20 > This string should include the name of the > manufacturer, the product name and the version of the > interface hardware/software. >=20 > The only reason the "description" leaf is mapped to ifAlias is b/c > this is what many implementations do. So we wanted to point out the > differences in the value space for these objects so that implementers > are aware of this. >=20 Thanks for this clarification. >=20 >> 4. Relationship to the IF-MIB >>=20 >> The IF-MIB also defines the writable object ifPromiscuousMode. Since >> this object typically is not a configuration object, it is not mapped >> to the "ietf-interfaces" module. >>=20 >> ifPromiscuousMode can actually be changed in many cases. >=20 > Right, but it is not typically a configuration parameter. >=20 >> Is that the only >> reason why attributes are being mapped to the "ietf-interfaces" module o= r not? >=20 > I wouldn't say that, bur for this particular object, the WG felt it > should be left out. >=20 >=20 >> 5. Interfaces YANG Module >> ... >> organization >> "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; >>=20 >> contact >> "WG Web: >> WG List: >>=20 >> WG Chair: David Kessens >> >>=20 >> Does the definition of the module, anchoring on a Working Group, put >> requirements or constraints on the existence of netmod? Meaning: what ha= ppens >> to these pointers when the WG ceases to exist, and the maling list is lo= cked? >> Perhaps this is the usual way of defining contact for the YANG modules, = but I >> suspect a time invariant pointer would help. >=20 > This also seems to be the usual way of defining contact info in > MIBs... >=20 But not for others. Is there value in defining the contact this way? I am j= ust asking. >> =1B$B!D=1B(B >> leaf name { >> type string; >> description >> "The name of the interface. >>=20 >> A device MAY restrict the allowed values for this leaf, >> possibly depending on the type and location. >>=20 >> If the device allows arbitrarily named interfaces, the >> feature 'arbitrary-names' is advertised. >>=20 >> This leaf MAY be mapped to ifName by an implementation. >> Such an implementation MAY restrict the allowed values for >> this leaf so that it matches the restrictions of ifName. >> If a NETCONF server that implements this restriction is >> sent a value that doesn't match the restriction, it MUST >> reply with an rpc-error with the error-tag >> 'invalid-value'."; >>=20 >> Should the description of a YANG leaf be tied to NETCONF? Or are there >> potential uses outside NETCONF? >=20 > Currently the only standardized usage is NETCONF. But vendors use > YANG for other purposes, and there's an individual draft that use YANG > for a RESTful api. >=20 > But the sentence really just specifies what a NETCONF server would > do. It would be difficult to write this in a generic way, and at the > same time it is useful to specify this for NETCONF implementations. >=20 I still find it a bit odd that the description intertwines protocol directi= ves.=20 >=20 >> Please note that although this comment is made >> once, it applies to all the descriptions that say "If a NETCONF server= =1B$B!D=1B(B", as >> there are quite a number of these. >=20 > Yes, but it is only used when we specify the NETCONF protocol behavior. >=20 >> leaf location { >> type string; >> description >> "The device-specific location of the interface of a >> particular type. The format of the location string >>=20 >> As mentioned above, this is not a "location". >>=20 >> leaf phys-address { >> type yang:phys-address; >> config false; >> description >> "The interface's address at its protocol sub-layer. For >> example, for an 802.x interface, this object normally >> contains a MAC address. The interface's media-specific >> modules must define the bit and byte ordering and the >> format of the value of this object. For interfaces that do >> not have such an address (e.g., a serial line), this node >> is not present."; >> reference >> "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; >> } >>=20 >> Just by reading the description of this leaf, shouldn't this be part of = an >> augmentation type-specific module? For example, for an Ethernet interfac= e >> module, instead of the main YANG interface management top-level. Meaning= : this >> specific leaf, by definition, cannot be generically specified to what it= means >> for each type of interfaces. All the others can=1B$B!D=1B(B if this cann= ot be specified >> outside a media-specific module, why define it here? >=20 > See above - I think the reason is the relation to ifPhysAddress. >=20 THe question still stands -- if this is not a generic interface parameter, = and instead is specific to some types of interfaces, should it be defined h= ere or in type-specific submodules? >>=20 >> leaf oper-status { >> type enumeration { >> =1B$B!D=1B(B >>=20 >> The description of the leaf as well as the enum values for the oper-stat= us seem >> to be a bit under-defined. For example, "Ready to pass packets" seems to= o >> literal from the MIB >=20 > Yes. >=20 >> while I believe there are more precise definitions. Also, >> the description is actually listing usage of values instead of a real >> description. >>=20 >> 7. Security Considerations >>=20 >>=20 >> The YANG module defined in this memo is designed to be accessed via >> the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the >> secure transport layer and the mandatory-to-implement secure >> transport is SSH [RFC6242]. >>=20 >> Are there security considerations for other aspects of this language >> definition? For example, what if YANG is used via a different method? Wh= at >> about storage of the data? What about AAA aspects for RW or RO leafs? >=20 > The WG recently added a note about AAA aspects to the Security > Considerations template for YANG modules. I will update this document > as well with the new text. Thank you. >=20 >> 9.1. Normative References >>=20 >> [I-D.ietf-netmod-iana-if-type] >>=20 >> This document points normatively to draft-ietf-netmod-iana-if-type-02. H= owever, >> there are four additional revisions to the document and a most recent th= at is a >> year later than draft-ietf-netmod-iana-if-type-02. While things should b= e in >> sync given a common author and a hard dependency, just calling it out he= re >> since there are a few differences between those revisions of the normati= ve >> reference: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-if-type-06.t= xt&url1=3Ddraft-ietf-netmod-iana-if-type-02.txt >=20 > These documents are advanced together; but you are right, the > reference is pretty old. I simply forgot to update it. >=20 Thank you. >=20 >> Appendix A. Example: Ethernet Interface Module >>=20 >> Do these appendices need to explicitly say that are non-normative? I wou= ld add >> a one-liner about it. >=20 > Ok... but are examples ever normative? Not typically. I was just suggesting demarcating normative vs. informative = chunks of text. >=20 >> Appendix A. Example: Ethernet Interface Module >>=20 >> This applies to all appendices. I find it a bit incomplete that a specif= ication >> for a language for "Interface Management" chose to ignore the richness o= f types >> of interfaces to show in the appendices :-) Basically, all of the ten (I= think) >> different examples in the appendices are about Ethernet interfaces. Whil= e there >> is nothing underspecified, it is under-exemplified. How would a serial >> interface with sub interfaces loop like? How about a GRE Tunnel interfac= e? Or a >> point-to-point satellite? Or a 3G interface? Or =1B$B!D=1B(B >=20 > It is always tricky with examples... In this case we wanted to > examplify different features of the model, and we picked examples that > build on each other. >=20 >> Nits:=20 >>=20 >> 2. Objectives >> ... >> o The model must support interface layering, both simple layering >> where one interface is layered on top of exactly one other >> interface, and more complex scenarios where one interface is >> aggregated over N other interfaces, or when N interfaces are >> multiplexed over one other interface. >>=20 >> This is a nit: are "aggregated" and "multiplexed" the right words here? = I >> believe I understand what is meant, but at the same time, it's not clear= how >> "one interface" can be "aggregated" (i.e., aggregate a plurality/collect= ion of >> elements into one). Perhaps: "and more complex scenarios where one inter= face >> results from the aggregation of N other interfaces, or when N interfaces= are >> multiplexed over one other interface."? >=20 > Yes, this is much better. Thanks for the suggestion! >=20 :-) >=20 >> 5. Interfaces YANG Module >>=20 >> leaf oper-status { >> type enumeration { >> =1B$B!D=1B(B >>=20 >> The description of the leaf as well as the enum values for the oper-stat= us seem >> to be a bit under-defined. For example, "Ready to pass packets" seems to= o >> literal from the MIB, while I believe there are more precise definitions >> (s/packets/traffic/ at least?). Also, the description is actually listin= g usage >> of values instead of a real description. >=20 > [this seems to be a duplicate comment] >=20 Yes, sorry. Are you planning on updating the description of the values? >=20 >> I hope these are clear and useful! >=20 > It was; thank you! >=20 I am glad about it. Thank you for your throughout responses. -- Carlos. >=20 > /martin >=20 From mbj@tail-f.com Tue Apr 30 00:18:21 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3445E21F9B45; Tue, 30 Apr 2013 00:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFnLk8wBBO01; Tue, 30 Apr 2013 00:18:16 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2E99121F9B5A; Tue, 30 Apr 2013 00:18:11 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F1DD51200045; Tue, 30 Apr 2013 09:18:09 +0200 (CEST) Date: Tue, 30 Apr 2013 09:18:09 +0200 (CEST) Message-Id: <20130430.091809.2283109543662828002.mbj@tail-f.com> To: cpignata@cisco.com From: Martin Bjorklund In-Reply-To: <95067C434CE250468B77282634C96ED322AF7636@xmb-aln-x02.cisco.com> References: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com> <20130429.224641.08727383.mbj@tail-f.com> <95067C434CE250468B77282634C96ED322AF7636@xmb-aln-x02.cisco.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, netmod@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 07:18:21 -0000 Hi, Comments to the remaining issues inline. "Carlos Pignataro (cpignata)" wrote: > On Apr 29, 2013, at 4:46 PM, Martin Bjorklund wrote: > > "Carlos Pignataro (cpignata)" wrote: > >> 3. Interfaces Data Model > >> … > >> +--ro if-index? int32 > >> > >> The "?" indicates that the lead is optional. From a routing > >> perspective, the > >> if-index plays an important role when for example the network layer > >> address > >> does not identify a specific interface (e.g., IP unnumbered), or when > >> there is > >> no network layer address (LAG member, etc.). Why is this optional? In > >> which > >> case you envision it would not be present? > > > > I think you are right; this leaf should be mandatory. This works > > since it has an 'if-feature' statement. > > > > Thanks. Even if it works because of the clause, I'd make this > mandatory. Yes, sorry for not being clear - it should be made mandatory, and I meant that it is ok to make it mandatory since we have the 'if-feature' statement. > >> 3. Interfaces Data Model > >> … > >> +--rw location? string > >> ... > >> 3.1. The interface List > >> … > >> The "location" leaf is a string. It is optional in the data model, > >> but if the type represents a physical interface, it is mandatory. > >> The format of this string is device- and type-dependent. The device > >> uses the location string to identify the physical or logical entity > >> that the configuration applies to. For example, if a device has a > >> single array of 8 ethernet ports, the location can be one of the > >> strings "1" to "8". As another example, if a device has N cards of M > >> ports, the location can be on the form "n/m", such as "1/0". > >> > >> I think that "location" is a poorly chosen label, a misnomer. This > >> seems to be > >> closer to an identifier than a locator. For example, some devices > >> number slots > >> left to right, and some number slots right to left :-) > > > > Correct, and we do not try to get into this at all. Some > > devices has 2 ports called A and B, and some have chassis of cards > > with rows of ports... > > > >> This does not answer > >> "where" something is; I do not mean geo-location, but I strongly > >> suggest > >> getting more precision on how this leaf is called. For example, > >> interface > >> numbering, instance id, type identifier, etc. > > > > The intention is really to be "where" the port is. It is not intended > > to be a virtual id. If the operator plugs in a cable in a certain > > port, he has to know how to configure this port so there must be > > something in the config that connects to the physical port. We use > > the name "location" for this purpose. > > Thanks for the explanation. While I appreciate (and I agree) that you > do not get into interpreting or parsing the syntax of the field, I > still think it is not a "location". > > I believe there is still an underlying assumption that the language is > defined for the physical world. If you have an Ethernet1/0, versus an > Ethernet1/2, that identifies (not locates) which interface. Yes, you > can use that to physically find them. But what if you have a > "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not > think we can "locate" the loopback, or the subinterface. > > If the operator creates a "loopback", "Tunnel", or virtual interface, > he or she does not need to physically locate it. > > I believe that labeling the leaf as "location" can be harmful as it > implies a specific meaning and shows assumptions. Ok I think I understand your concern. Personally, I think "location" works also in this case, but we should pick a name that is as useful as possible. Let me bring this issue back to the WG. > >> 3. Interfaces Data Model > >> … > >> +--rw interfaces > >> +--rw interface [name] > >> +--rw … > >> > >> Is there a specific reason why there is no lead with the interface's > >> MTU? It is > >> quite important from a routing perspective for some protocols. MTU is > >> not > >> included even in the examples of ethernet-specific data models > >> augmenting this > >> base spec and appendices, which leaves it a bit underspecified… > > > > The mtu is specified in an accompanying document draft-ietf-netmod-ip. > > > > What draft-ietf-netmod-ip describes is the network-layer IPv4 MTU and > IPv6 MTU. It does not describe the interface MTU. If that interface is > used to run IS-IS, or to run MPLS, what is the MTU? It's neither the > IPv4 MTU nor the IPv6 MTU. This topic was discussed in the WG. The result was that we did not beleive we could define a generic mtu on the interface that would be applicable to all types of interfaces. Media-specific modules can define this (maybe both configuration knobs and operational values). > >> What is the information model on which > >> this data model stands? If there was not RFC 2863, would a leaf be > >> defined as > >> ifPromiscuousMode or phys-address? Or would that belong in an > >> ethernet-specific > >> module? > > > > You are right that phys-address might not have been included. > > > > OK, thanks. Do you mean that you will be removing it? I will have to bring this to the WG. > >> In terms of the examples, basically all examples are some form of > >> ethernet > >> interface. For a document that aims at being general for managing > >> network > >> interfaces, this choice seems not inclusive. > >> > >> > >> Minor Issues: > >> > >> 2. Objectives > >> ... > >> o The data model should support the pre-provisioning of interface > >> configuration, i.e., it should be possible to configure an > >> interface whose physical interface hardware is not present on the > >> device. It is recommended that devices that support dynamic > >> addition and removal of physical interfaces also support pre- > >> provisioning. > >> > >> It is interesting that these design criteria do not call out the > >> applicability > >> to "physical" and "virtual" interfaces. Moreover, the text above seems > >> to imply > >> that the only "dynamic creation and deletion" of interfaces happens > >> with the > >> "addition and removal of physical interfaces" and does not call out > >> tunnels, > >> loopbacks, virtuals, and other logical entities instantiated as > >> "interfaces". > > > > I think you are reading too much into the statement above. It says > > that IF you support addition and removal of physical interfaces, then > > ... This does NOT mean that devices cannot support tunnels, loobacks > > etc. But maybe I misunderstood your point. > > > > I was not clear. Yes, that is an important statement. I was suggesting > that an addition of something like this would help: > > "o The dat amodel should support virtual interfaces as well as > physical interfaces blah blah". Ok, this makese sense. I will add this. > >> 4. Relationship to the IF-MIB > >> … > >> The following table lists the YANG data nodes with corresponding > >> objects in the IF-MIB. > >> ... > >> Mapping of YANG data nodes to IF-MIB objects > >> > >> This section explains how name cannot always map to ifName. However, > >> the table > >> shows a 1:1 mapping of name <-> ifName. I suggest marking with a > >> footnote or > >> "*" the elements that might not always may 1:1. > >> > >> For example, "enabled" also cannot map to ifAdminStatus. "enabled" is > >> a > >> boolean, and ifAdminStatus is an INTEGER with at least 3 values > >> specified (up, > >> down, testing). > >> > >> In summary, which ones map 1:1 and which ones do not? > > > > This table is supposed to be an overview. I think I would prefer to > > add a sentence that says something like "For details about thae > > mappings, please see the corresponding definition in the YANG module". > > No. I think that the table is a bit misleading when it says it > described the "Mapping of YANG data nodes to IF-MIB objects", but some > of these are related but do not really map. It seems you react to the word "Mapping" here. I am not sure why this word would imply a one-to-one mapping, but if it helps we can change this. Mapping of YANG data nodes to IF-MIB objects YANG data nodes and their corresponding IF-MIB objects YANG data nodes and their related IF-MIB objects ...? > >> 5. Interfaces YANG Module > >> ... > >> organization > >> "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; > >> > >> contact > >> "WG Web: > >> WG List: > >> > >> WG Chair: David Kessens > >> > >> > >> Does the definition of the module, anchoring on a Working Group, put > >> requirements or constraints on the existence of netmod? Meaning: what > >> happens > >> to these pointers when the WG ceases to exist, and the maling list is > >> locked? > >> Perhaps this is the usual way of defining contact for the YANG > >> modules, but I > >> suspect a time invariant pointer would help. > > > > This also seems to be the usual way of defining contact info in > > MIBs... > > > > But not for others. Is there value in defining the contact this way? I > am just asking. This is the currect practice that was decided (and documented in RFC 6087). > >> 5. Interfaces YANG Module > >> > >> leaf oper-status { > >> type enumeration { > >> … > >> > >> The description of the leaf as well as the enum values for the > >> oper-status seem > >> to be a bit under-defined. For example, "Ready to pass packets" seems > >> too > >> literal from the MIB, while I believe there are more precise > >> definitions > >> (s/packets/traffic/ at least?). Also, the description is actually > >> listing usage > >> of values instead of a real description. > > > > [this seems to be a duplicate comment] > > > > Yes, sorry. Are you planning on updating the description of the > values? Oh, you actually wrote: The description of the leaf as well as the enum values for the oper-status seem to be a bit under-defined. For example, "Ready to pass packets" seems too literal from the MIB, while I believe there are more precise definitions. Maybe we can provde more precise defintions, but I am not sure it helps. Since this leaf is supposed to reflect the ifOperStatus, what happens if we have a different description of the values than the MIB? /martin From cpignata@cisco.com Tue Apr 30 06:16:31 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B0921F9820; Tue, 30 Apr 2013 06:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy9YAUhjI3Dp; Tue, 30 Apr 2013 06:16:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 844EB21F9A31; Tue, 30 Apr 2013 06:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12449; q=dns/txt; s=iport; t=1367327785; x=1368537385; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+5/I9U2tWMaTKb1KPqmRgzSzPImRvma8EP5QWYKZ08w=; b=IkRRhZrZ4jiH/mE9pj+jMZ5AOo01xcWmkJmW9VbH9q/jkn2aw5myII0n XrDXMXuuIKeBVlFgp3QIS9SqeWfSNEq6fHCyrqEBw3BHGzgmokvJR7WZ+ YlSNQqZgyiO8izdWmkkviuptM8+Fr6o5H3OyMiiIOgBAgWXHKr4+guNvk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAGHDf1GtJXHB/2dsb2JhbABIAgiDBzaDN7sgfxZ0gh8BAQEDASEBBUsHBQsCAQgOCgEDBgUYAgMCMhQRAgQOAwIIAYgHBgyUA5sDAYJEjj+BIIw2CAYEfwIxAgWCOTVhA5hEkASDEUCBKgkXHg X-IronPort-AV: E=Sophos;i="4.87,582,1363132800"; d="scan'208";a="204766871" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 30 Apr 2013 13:16:24 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3UDGNnC003938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Apr 2013 13:16:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 30 Apr 2013 08:16:23 -0500 From: "Carlos Pignataro (cpignata)" To: Martin Bjorklund Thread-Topic: RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt Thread-Index: AQHORO7C2y3SdVUEW027VIOCZsJnvJjt/0GAgAAmAoCAAIpsgIAAZBeA Date: Tue, 30 Apr 2013 13:16:23 +0000 Message-ID: <95067C434CE250468B77282634C96ED322AF88A9@xmb-aln-x02.cisco.com> References: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com> <20130429.224641.08727383.mbj@tail-f.com> <95067C434CE250468B77282634C96ED322AF7636@xmb-aln-x02.cisco.com> <20130430.091809.2283109543662828002.mbj@tail-f.com> In-Reply-To: <20130430.091809.2283109543662828002.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.44.101] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , "" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 13:16:31 -0000 Martin, Thanks again for the short RTT and the details in your response. I think th= is addresses most/all my concerns; details inline closing the loop.=20 On Apr 30, 2013, at 3:18 AM, Martin Bjorklund wrote: > Hi, >=20 > Comments to the remaining issues inline. >=20 > "Carlos Pignataro (cpignata)" wrote: >> On Apr 29, 2013, at 4:46 PM, Martin Bjorklund wrote: >>> "Carlos Pignataro (cpignata)" wrote: >>>> 3. Interfaces Data Model >>>> =1B$B!D=1B(B >>>> +--ro if-index? int32 >>>>=20 >>>> The "?" indicates that the lead is optional. From a routing >>>> perspective, the >>>> if-index plays an important role when for example the network layer >>>> address >>>> does not identify a specific interface (e.g., IP unnumbered), or when >>>> there is >>>> no network layer address (LAG member, etc.). Why is this optional? In >>>> which >>>> case you envision it would not be present? >>>=20 >>> I think you are right; this leaf should be mandatory. This works >>> since it has an 'if-feature' statement. >>>=20 >>=20 >> Thanks. Even if it works because of the clause, I'd make this >> mandatory. >=20 > Yes, sorry for not being clear - it should be made mandatory, and I > meant that it is ok to make it mandatory since we have the > 'if-feature' statement. >=20 >=20 >>>> 3. Interfaces Data Model >>>> =1B$B!D=1B(B >>>> +--rw location? string >>>> ... >>>> 3.1. The interface List >>>> =1B$B!D=1B(B >>>> The "location" leaf is a string. It is optional in the data model, >>>> but if the type represents a physical interface, it is mandatory. >>>> The format of this string is device- and type-dependent. The device >>>> uses the location string to identify the physical or logical entity >>>> that the configuration applies to. For example, if a device has a >>>> single array of 8 ethernet ports, the location can be one of the >>>> strings "1" to "8". As another example, if a device has N cards of M >>>> ports, the location can be on the form "n/m", such as "1/0". >>>>=20 >>>> I think that "location" is a poorly chosen label, a misnomer. This >>>> seems to be >>>> closer to an identifier than a locator. For example, some devices >>>> number slots >>>> left to right, and some number slots right to left :-) >>>=20 >>> Correct, and we do not try to get into this at all. Some >>> devices has 2 ports called A and B, and some have chassis of cards >>> with rows of ports... >>>=20 >>>> This does not answer >>>> "where" something is; I do not mean geo-location, but I strongly >>>> suggest >>>> getting more precision on how this leaf is called. For example, >>>> interface >>>> numbering, instance id, type identifier, etc. >>>=20 >>> The intention is really to be "where" the port is. It is not intended >>> to be a virtual id. If the operator plugs in a cable in a certain >>> port, he has to know how to configure this port so there must be >>> something in the config that connects to the physical port. We use >>> the name "location" for this purpose. >>=20 >> Thanks for the explanation. While I appreciate (and I agree) that you >> do not get into interpreting or parsing the syntax of the field, I >> still think it is not a "location". >>=20 >> I believe there is still an underlying assumption that the language is >> defined for the physical world. If you have an Ethernet1/0, versus an >> Ethernet1/2, that identifies (not locates) which interface. Yes, you >> can use that to physically find them. But what if you have a >> "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not >> think we can "locate" the loopback, or the subinterface. >>=20 >> If the operator creates a "loopback", "Tunnel", or virtual interface, >> he or she does not need to physically locate it. >>=20 >> I believe that labeling the leaf as "location" can be harmful as it >> implies a specific meaning and shows assumptions. >=20 > Ok I think I understand your concern. Personally, I think "location" > works also in this case, but we should pick a name that is as useful > as possible. Let me bring this issue back to the WG. >=20 Thank you. It seems to me you are "identifying" the instance. >>>> 3. Interfaces Data Model >>>> =1B$B!D=1B(B >>>> +--rw interfaces >>>> +--rw interface [name] >>>> +--rw =1B$B!D=1B(B >>>>=20 >>>> Is there a specific reason why there is no lead with the interface's >>>> MTU? It is >>>> quite important from a routing perspective for some protocols. MTU is >>>> not >>>> included even in the examples of ethernet-specific data models >>>> augmenting this >>>> base spec and appendices, which leaves it a bit underspecified=1B$B!D= =1B(B >>>=20 >>> The mtu is specified in an accompanying document draft-ietf-netmod-ip. >>>=20 >>=20 >> What draft-ietf-netmod-ip describes is the network-layer IPv4 MTU and >> IPv6 MTU. It does not describe the interface MTU. If that interface is >> used to run IS-IS, or to run MPLS, what is the MTU? It's neither the >> IPv4 MTU nor the IPv6 MTU. >=20 > This topic was discussed in the WG. The result was that we did not > beleive we could define a generic mtu on the interface that would be > applicable to all types of interfaces. Media-specific modules can > define this (maybe both configuration knobs and operational values). >=20 >=20 OK, thanks. I still think that this is a big gap. Even the ethernet-specifi= c examples that the document includes, do not include MTU configuration. A = number of protocols break without MTU defined. I agree with defining IPv4 a= nd IPv6 specific MTUs in the netmod-ip document, but it still seems to me t= hat the interface MTU is fundamental and generic enough to be defined (that= might not be applicable to every interface but enough ubiquitousness to be= defined and call out exceptions). That said, I just read the thread at http://www.ietf.org/mail-archive/web/n= etmod/current/msg07422.html and I can see it fit in media-specific modules.= However, those are not defined (and I expect that might not be defined for= every media, tunneling encap, etc.)=20 >>>> What is the information model on which >>>> this data model stands? If there was not RFC 2863, would a leaf be >>>> defined as >>>> ifPromiscuousMode or phys-address? Or would that belong in an >>>> ethernet-specific >>>> module? >>>=20 >>> You are right that phys-address might not have been included. >>>=20 >>=20 >> OK, thanks. Do you mean that you will be removing it? >=20 > I will have to bring this to the WG. >=20 Thank you. >>>> In terms of the examples, basically all examples are some form of >>>> ethernet >>>> interface. For a document that aims at being general for managing >>>> network >>>> interfaces, this choice seems not inclusive. >>>>=20 >>>>=20 >>>> Minor Issues: >>>>=20 >>>> 2. Objectives >>>> ... >>>> o The data model should support the pre-provisioning of interface >>>> configuration, i.e., it should be possible to configure an >>>> interface whose physical interface hardware is not present on the >>>> device. It is recommended that devices that support dynamic >>>> addition and removal of physical interfaces also support pre- >>>> provisioning. >>>>=20 >>>> It is interesting that these design criteria do not call out the >>>> applicability >>>> to "physical" and "virtual" interfaces. Moreover, the text above seems >>>> to imply >>>> that the only "dynamic creation and deletion" of interfaces happens >>>> with the >>>> "addition and removal of physical interfaces" and does not call out >>>> tunnels, >>>> loopbacks, virtuals, and other logical entities instantiated as >>>> "interfaces". >>>=20 >>> I think you are reading too much into the statement above. It says >>> that IF you support addition and removal of physical interfaces, then >>> ... This does NOT mean that devices cannot support tunnels, loobacks >>> etc. But maybe I misunderstood your point. >>>=20 >>=20 >> I was not clear. Yes, that is an important statement. I was suggesting >> that an addition of something like this would help: >>=20 >> "o The dat amodel should support virtual interfaces as well as >> physical interfaces blah blah". >=20 > Ok, this makese sense. I will add this. Thank you. >=20 >>>> 4. Relationship to the IF-MIB >>>> =1B$B!D=1B(B >>>> The following table lists the YANG data nodes with corresponding >>>> objects in the IF-MIB. >>>> ... >>>> Mapping of YANG data nodes to IF-MIB objects >>>>=20 >>>> This section explains how name cannot always map to ifName. However, >>>> the table >>>> shows a 1:1 mapping of name <-> ifName. I suggest marking with a >>>> footnote or >>>> "*" the elements that might not always may 1:1. >>>>=20 >>>> For example, "enabled" also cannot map to ifAdminStatus. "enabled" is >>>> a >>>> boolean, and ifAdminStatus is an INTEGER with at least 3 values >>>> specified (up, >>>> down, testing). >>>>=20 >>>> In summary, which ones map 1:1 and which ones do not? >>>=20 >>> This table is supposed to be an overview. I think I would prefer to >>> add a sentence that says something like "For details about thae >>> mappings, please see the corresponding definition in the YANG module". >>=20 >> No. I think that the table is a bit misleading when it says it >> described the "Mapping of YANG data nodes to IF-MIB objects", but some >> of these are related but do not really map. >=20 > It seems you react to the word "Mapping" here. I am not sure why this > word would imply a one-to-one mapping, but if it helps we can change > this. >=20 > Mapping of YANG data nodes to IF-MIB objects > YANG data nodes and their corresponding IF-MIB objects > YANG data nodes and their related IF-MIB objects > ...? Thank you. >=20 >>>> 5. Interfaces YANG Module >>>> ... >>>> organization >>>> "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; >>>>=20 >>>> contact >>>> "WG Web: >>>> WG List: >>>>=20 >>>> WG Chair: David Kessens >>>> >>>>=20 >>>> Does the definition of the module, anchoring on a Working Group, put >>>> requirements or constraints on the existence of netmod? Meaning: what >>>> happens >>>> to these pointers when the WG ceases to exist, and the maling list is >>>> locked? >>>> Perhaps this is the usual way of defining contact for the YANG >>>> modules, but I >>>> suspect a time invariant pointer would help. >>>=20 >>> This also seems to be the usual way of defining contact info in >>> MIBs... >>>=20 >>=20 >> But not for others. Is there value in defining the contact this way? I >> am just asking. >=20 > This is the currect practice that was decided (and documented in RFC > 6087). Thanks much for this pointer, I have not seen it. >=20 >>>> 5. Interfaces YANG Module >>>>=20 >>>> leaf oper-status { >>>> type enumeration { >>>> =1B$B!D=1B(B >>>>=20 >>>> The description of the leaf as well as the enum values for the >>>> oper-status seem >>>> to be a bit under-defined. For example, "Ready to pass packets" seems >>>> too >>>> literal from the MIB, while I believe there are more precise >>>> definitions >>>> (s/packets/traffic/ at least?). Also, the description is actually >>>> listing usage >>>> of values instead of a real description. >>>=20 >>> [this seems to be a duplicate comment] >>>=20 >>=20 >> Yes, sorry. Are you planning on updating the description of the >> values? >=20 > Oh, you actually wrote: >=20 > The description of the leaf as well as the enum values for the > oper-status seem to be a bit under-defined. For example, "Ready to > pass packets" seems too literal from the MIB, while I believe there > are more precise definitions. >=20 > Maybe we can provde more precise defintions, but I am not sure it > helps. Since this leaf is supposed to reflect the ifOperStatus, what > happens if we have a different description of the values than the MIB? >=20 >=20 Many thanks again! -- Carlos. >=20 >=20 > /martin >=20