Re: [trill] my comments on draft-ietf-trill-oam-framework

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi Samer, 

Thank you for addressing my concerns. All proposed resolutions and clarifications look acceptable to me, I am looking forward to the submission of the revised I-D. 

Regards,

Dan




> -----Original Message-----
> From: Samer Salam (ssalam) [mailto:[e-mail]]
> Sent: Tuesday, May 07, 2013 4:08 AM
> To: Romascanu, Dan (Dan); TRILL Working Group
> Subject: Re: [trill] my comments on draft-ietf-trill-oam-framework
> 
> Hi Dan,
> 
> Thank you for the detailed review. Please find comment resolution
> responses inline.
> 
> On 13-04-04 1:56 AM, "Romascanu, Dan (Dan)" <[e-mail]> wrote:
> 
> >Hi,
> >
> >Here are my comments on draft-ietf-trill-oam-framework-01.txt
> >
> >I have divided them in Technical and Editorial.
> >
> >
> >Technical
> >
> >T1. The references are broken in many ways. Many references in the text
> >are not included in the References sections - runing id-nits shows this
> >immediately. Listed references point to documents that do not exist
> >[TRILL-OAM], [TRILL-IP].
> 
> Fixed. id-nits is still complaining about two of the references, even
> though their names are correct...
> 
> >
> >T2. I have mixed feelings about the usage of RFC 2119 capitalized
> >keywords in this document. My preference would be to drop them
> >completely, especially as the document is targeting Informational
> status.
> >If they stay, we need to carefully review the usage, right now it's
> >quite inconsistent.
> 
> We have completely dropped capitalized keywords from the draft.
> 
> >
> >
> >T3. The document does not include a section on operational and
> >manageability considerations. I believe that this is necessary, and
> >this section should include as a minimum:
> >- what parameters need to be configured on Rbridges in order to
> >activate TRILL OAM - activation of specific OAM functions, periodicity
> >of OAM messages, activation of synthetic traffic (periodic or on
> >demand)
> >- how are these parameters configured? Are there recommended default
> >values?
> >- how are results of Performance Management used or retrieved?
> 
> Section 6 was added to this effect.
> 
> >
> >T4. Several terms are used according to the terminology defined in RFC
> >6905 - Section, Flow, Connectivity, Continuity Indication, etc. I
> >suggest to mention this in Section 1.2
> 
> Done.
> 
> >
> >T5. Are the references to L2VPN and MPLS-TP (and the respective
> >[RFC6136] and [RFC6371]) in Section 1.2 needed at all? I do not see
> >these technologies mentioned in any other part of the document, and if
> >there is no relevant relationship with the OAM functions on these
> >layers I would suggest to drop these.
> 
> All references to L2VPN and MPLS-TP had been removed.
> 
> >
> >T6. In 2.4 we have an example why using 2119 capitalized keywords is
> >problematic:
> >
> >> When considering multi-domain scenarios, the following
> >   rules must be followed: TRILL OAM domains MUST NOT overlap, but MUST
> >   either be disjoint or nest to form a hierarchy (i.e. a higher
> >   Maintenance Domain MAY completely engulf a lower Domain).
> >
> >If I was to chose, I would prefer not to use capitalization, or use
> >capitalization only for the first 'must' which is not capitalized in
> >the text. 'MUST either ...' is a strange combination. One may argue
> >that nesting is a form of overlapping, and actually 'MUST not overlap'
> >is should rather be 'MUST not partially intersect'.
> 
> Removed 2119 capitalized keywords from the document.
> 
> >
> >T.7 In Section 3.1:
> >
> >> Additionally
> >   methods must be provided to prevent OAM packets from being
> >   transmitted out as native frames.
> >
> >If capitalized RFC 2119 keywords are to be kept, this 'must' must be a
> >'MUST' (because of the critical impact on the bits on wire)
> 
> Same as above.
> 
> >
> >T.8 In section 3.2:
> >
> >>  When running OAM functions over Test Flows, the TRILL OAM should
> >   provide a mechanism for discovering the flow entropy parameters by
> >   querying the RBridges dynamically.
> >
> >I am wondering why this is a 'should' and not a 'must'. Are there any
> >exception cases?
> 
> 
> The intent is to keep discovery optional, since an operator may, for
> example, configure the test flow parameters manually.
> 
> >
> >T.9 Section 3.4:
> >
> >>  RBridges must be able to identify OAM messages that are destined to
> >   them, either individually or as a group, so as to properly process
> >   those messages.
> >
> >OK - so a method must be in place.
> >
> >   It may be possible to use a combination of one of the unused fields
> >   or bits in the TRILL Header and the OAM EtherType to identify TRILL
> >   OAM messages.
> >
> >' one of the unused fields or bits in the TRILL Header' - which ones?
> >Are we talking about an update to RFC 6395? Where is this defined?
> >
> >Is the 'and' between the TRILL header combinations and the OAM
> >EtherType really an 'and' or rather an 'or'? 'OAM EtherType' is rather
> >'TRILL OAM EtherType'?
> >
> >   [RFC6325] does not specify any method of identifying OAM messages.
> >   Hence, for backwards compatibility reasons, TRILL OAM solutions must
> >   provide methods to identify OAM messages through the use of well-
> >   known patterns in the Flow Entropy field; for e.g., by using a
> >   reserved MAC address as the inner MAC SA.
> >
> >Is this an alternate method to the ones described in the previous
> >paragraph? Then, the 'must' is probably rather a 'may' or should'. What
> '
> >reserved MAC address' are we talking about? Is this something that we
> >should ask from the IEEE RAC? Where is this specified?
> 
> This section was rewritten since several reviewers raised similar
> comments. Please let us know if there is any ambiguity in the new text.
> 
> >
> >
> >T.10 Section 4.1.1 - What does 'Period mis-configuration' mean? Is this
> >about the periodicity of the OAM messages? If so this defect is about
> >OAM configuration, not about continuity check. If it's something
> >different, please explain or provide a reference.
> 
> It is about mis-configuration of the continuity check timers between
> MEPs.
> Added text to clarify.
> 
> >
> >T.11 Section 4.2:
> >
> >>  On-demand fault management functions are initiated manually by the
> >   network operator and continue for a time bound period.
> >
> >The last part of the statement is not always true, as some fault
> >management functions may be one-time actions or tests.
> 
> Fixed the text.
> 
> >
> >T.12 Section 5. - Performance Management - I am not thrilled about this
> >section at all. Note that RFC 6905 talks about Performance Monitoring
> >(not Management) and it's not a mandatory function. Terminology aside,
> >I dislike generating synthetic traffic in order to measure packet loss
> >- how much traffic? Limiting this seems mandatory. Who compares what
> >was sent with what was received?  5.2 talks about hardware-based
> >time-stamping to measure Packet Delay. This implies some kind of clocks
> >synchronization between RBridges. What are the requirements?
> 
> Have added details to address all the above.
> 
> >
> >
> >T.13 The Security Considerations section should be more explicit on
> >what 'exploitation of the OAM message channel' means. Specifically the
> >threats related to overloading the network and the Rbridges with OAM
> >messages should be mentioned, as well as the impact of interrupting the
> >OAM services.
> 
> Added text to clarify.
> 
> >
> >
> >
> >Editorial
> 
> 
> All the editorial comments below were incorporated into the updated
> draft.
> We will be sending the draft to the workgroup mailing list shortly.
> 
> Regards,
> Samer
> 
> >
> >E1. In Section 1:
> >
> >>  Some
> >   characteristics of a TRILL network that are different from Ethernet
> >   bridging ...
> >
> >s/Ethernet bridging/IEEE 802.1 bridging/
> >
> >E2. Check for completeness of the acronyms list in section 1.1. For
> >example ECMP is used a few times in the document, but not listed here
> >and never expanded.
> >
> >E3. In several places (2.1.3 is the first) I found 'For e.g.,'. I
> >believe that this is a pleonasm, either use 'For example', or just e.g.
> >
> >E4. In section 2.2: s/TRILL OAM processing can be modeled as a
> >layer/TRILL OAM processing can be represented as a layer/
> >
> >E5. In Section 2.3:
> >
> >>  Network OAM mechanisms provide fault and performance management
> >   functions in the context of a representative 'test' VLAN or fine-
> >   grained label [TRILL-FGL].
> >
> >What does 'representative' mean here?
> >
> >E6. 'faults in connectivity or performance' - 'connectivity faults and
> >performance degradation' is probably better
> >
> >E7. In Section 2.6:
> >
> >> MEPs are the active components of TRILL OAM: MEPs source TRILL OAM
> >   messages proactively or on-demand based on operator invocation.
> >
> >The usage of the term 'proactively' seems to me to be incorrect. I
> >would rather use 'periodically'. Also s/operator invocation/operator
> >configuration actions/
> >
> >
> >
> >E8. In Section 2.6:
> >
> >> - MUST support the UP MEP function on a TRILL virtual port (to
> >     support OAM functions on Sections)
> >
> >I would add for clarity inside the brackets '... as defined in
> 'rfc6905'
> >
> >Regards,
> >
> >Dan
> >
> >_______________________________________________
> >trill mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/trill