Re: [Bier] Comments about Overlay OAM Drafts

["Nagendra Kumar Nainar (naikumar)" <[e-mail]>]

Hi Tal,

6.	Section 6 - certainly the OAM requirements have security implications.
For example, OAM protocols may be subject to DoS attacks and to network
recon. Some of these considerations are discussed in RFC 7276.


The draft is listing the requirements and does not discuss about any
solution or machinery. Accordingly, it does not introduce any security
implications. I think the security consideration is applicable on the
document that define the solutions. Does the below works:

"This document list the OAM requirement for various Overlay network and
does not raise any security considerations. Any document defining the
solution for the above requirement must consider and include the relevant
security mechanism².

Thanks,
Nagendra

On 6/26/16, 8:36 PM, "Gregory Mirsky" <[e-mail]> wrote:

>Hi Tal,
>many thanks for your thorough review of the documents by OOAM DT, greatly
>appreciated. Please find my answers and notes in-line and tagged GIM>>.
>We're preparing updates to both drafts and will reflect your comments in
>the coming updates.
>
>	Regards,
>		Greg
>
>-----Original Message-----
>From: Tal Mizrahi [mailto:[e-mail]]
>Sent: Sunday, June 26, 2016 7:20 AM
>To: Nagendra Kumar Nainar (naikumar);
>[e-mail];
>[e-mail]; [e-mail]
>Cc: [e-mail]; [e-mail]; [e-mail]
>Subject: RE: Comments about Overlay OAM Drafts
>
>Dear Nagendra,
>
>>The comments seems to be missing in the mail. Can you please share the
>>same?.
>
>Strange... The comments seem to be visible in the mail archive
>(https://mailarchive.ietf.org/arch/msg/rtgwg/EPxJQcw9lOAIHV2HkRwNE6GVxAU).
>
>Nevertheless, here goes again:
>
>
>Comments about draft-ooamdt-rtgwg-ooam-requirement:
>https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-requirement-00
>
>A general question about the draft: does the draft define requirements
>for operators, requirements for vendors, or requirements for IETF working
>groups? These are three significantly different scopes, and reading the
>document I was not able to assess who the requirements are intended for.
>
>Other comments:
>1.	Section 3: The term 'UCMP' is defined in Section 3, but not used in
>the document.
>GIM>> Good catch, will clear
>2.	The following terms are used in the draft without having been defined:
>-	'OAM session'
>-	'node'
>-	'centralized controller'
>-	'FM'
>GIM>> While Fault Management is straightforward
>3.	Section 4.1.1: 'Reverse Defect Indication (RDI)' ==> RDI usually
>stands for Remote Defect Indication.
>GIM>> Indeed, thank you. Will update.
>4.	Section 4.1.2: "Overlay OAM MAY support verification of the mapping
>between its data plane state and client layer services" - please clarify
>further.
>GIM>> We intend to provide solutions in the new document. But one use
>case discussed in draft-nordmark-nvo3-transcending-traceroute.
>5.	Section 4.2: the terms 'active' and 'passive' have not been defined in
>the current draft (you may want to cite RFC 7799).
>Specifically, this clarification is necessary since the term 'passive'
>according to RFC 7799 is slightly different than the term 'passive' in
>draft-ietf-ippm-alt-mark-00.
>GIM>> Yes, and we are talking about measurement methods that can be used
>"almost as passive" and explain the requirements toward the overlay to
>achieve such behavior.
>6.	Section 6 - certainly the OAM requirements have security implications.
>For example, OAM protocols may be subject to DoS attacks and to network
>recon. Some of these considerations are discussed in RFC 7276.
>
>
>Comments about draft-ooamdt-rtgwg-oam-gap-analysis:
>https://tools.ietf.org/html/draft-ooamdt-rtgwg-oam-gap-analysis-01
>
>1.	I believe having an OAM gap analysis draft is a good idea.
>GIM>> Thank you.
>2.	The current draft is still very preliminary, and some of the sections
>are still empty. 
>GIM>> we'll post update before the cut-off date to discuss it in Berlin.
>3.	Section 1: The introduction of the document goes way beyond the scope
>of the title (Gap Analysis). The intro actually defines the baseline of
>an Overlay OAM solution. Either this part should be removed from the
>document, or the scope of the document should be redefined.
>GIM>> I think it may justified as we list existing IETF OAM protocols.
>Though we may move them out of the Introduction and into the new section.
>4.	Section 3.3: this section is unclear, and should probably be rephrased.
>The section discusses both in-band telemetry and passive monitoring, and
>it is not clear whether the two are related or not.
>GIM>> We've discussed the telemetry and it could be collected using
>active OAM, i.e. using injected OAM packets, or using passive-like
>method. Interestingly to discussion in RFC 7799, telemetry collection may
>use methods that could be characterized as hybrid methods as well.
>5.	Section 5: it looks like this text was copied from another draft, and
>is not applicable to this document.
>GIM>> Indeed, we've removed it in the working version. Contributions are
>welcome and appreciated.
>
>Cheers,
>Tal.
>
>
>
>>-----Original Message-----
>>From: Nagendra Kumar Nainar (naikumar) [mailto:[e-mail]]
>>Sent: Sunday, June 26, 2016 5:16 PM
>>To: Tal Mizrahi; [e-mail];
>>draft- [e-mail]; [e-mail]
>>Cc: [e-mail]; [e-mail]; [e-mail]
>>Subject: Re: Comments about Overlay OAM Drafts
>>
>>Hi Tal,
>>
>>The comments seems to be missing in the mail. Can you please share the
>>same?.
>>
>>Thanks,
>>Nagendra
>>
>>On 6/26/16, 4:12 AM, "Tal Mizrahi" <[e-mail]> wrote:
>>
>>>Dear OOAM Authors,
>>>
>>>I have read the two OOAM drafts, and I have some comments. Please see
>>>below
>