Re: [Lime] Passive performance measurement methods

[Qin Wu <[e-mail]>]

Thanks for your clarification, Sri, your proposal sounds reasonable to me.

-Qin
发件人: Srihari Raghavan (srihari) [mailto:[e-mail]]
发送时间: 2016年7月5日 14:49
收件人: Qin Wu; Frank Brockners (fbrockne); Deepak Kumar (dekumar); Gregory Mirsky
抄送: Carlos Pignataro (cpignata); [e-mail]; [e-mail]; [e-mail]
主题: Re: [Lime] Passive performance measurement methods

Qin

Thanks. Pl. find replies inline.

/Srihari

From: Qin Wu <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 5 July 2016 at 11:48 AM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, "Frank Brockners (fbrockne)" <[e-mail]<mailto:[e-mail]>>, "Deepak Kumar (dekumar)" <[e-mail]<mailto:[e-mail]>>, Gregory Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Lime] Passive performance measurement methods

发件人: Srihari Raghavan (srihari) [mailto:[e-mail]]
发送时间: 2016年6月29日 20:37
收件人: Qin Wu; Frank Brockners (fbrockne); Deepak Kumar (dekumar); Gregory Mirsky
抄送: Carlos Pignataro (cpignata); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: Re: [Lime] Passive performance measurement methods

Qin et al.,

Agree.  Breaking down one model into OAM data model and the procedures/methods that work on the model as separate models sounds good where we can target the data model enhancements separately from the methods/procedures that can retrieve it.

It allows everybody in the future to define new methods/procedures to access the data from the node without changing the base data model module.  To gain full benefits, we can separate the draft document into two – where one targets the model and the other targets the methods.  This allows both to be evolved separately.

Thinking more on the data model, we can potentially have something like the following and if found appropriate after discussions, could be added to the model.  The fields are mostly taken out of the current path-discovery and continuity-check RPC methods' output information and once the model is separated out, the methods can reference this data model thus allowing each to be evolved independently.

[Qin]: Sounds like a modularity approach, broken down one model into two reusable components. I am wondering how method model component references data model component, define these fields as a set of groupings in the data model component? Use these groupings in the method model component?

In the current draft, we make use of the YANG “feature” construct in the module which allows implementation to support only those feature that lie within their capabilities.

[SR] Yes.  Exactly.  One can think of reusable groupings in the base model that gets imported and used in the methods model.

Regarding feature construct, yes...it does allow a way to prune the tree based on implemented features but IMHO, it does not make it easy to extend the model easily especially in this case, where model is tied to the IETF draft/text and new revisions need to touch the base model as well as the base draft text.  If the methods model AND the draft text that references the methods model reside separately, the methods can change/evolve without changing the base model/draft text.

Thoughts?

Thanks
Srihari

+ path-discovery-data
   - src-test-point
   - dst-test-point
   - sequence-number
   - hop-count
   + session statistics (delay etc.,)
   + path-verification (flow information that defines the path, path verification stats etc.,)
   + path-trace-info [index]
      - timestamp
      - ingress-interface-info
      - egress-interface-info
      - app-meta-data

+ continuity-check-data
   + src-test-point
       - egress-interface
   + dst-test-point
       - ingress-interface
   + sequence-number
   + hop-count
   + total-packets-sent
   + total-packets-recv
   + total-packets-lost
   + total-packets-reordered
   + total-packets-duplicated
   + min-delay
   + max-delay
   + average-delay etc.,

From: Qin Wu <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 29 June 2016 at 8:42 AM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, "Frank Brockners (fbrockne)" <[e-mail]<mailto:[e-mail]>>, "Deepak Kumar (dekumar)" <[e-mail]<mailto:[e-mail]>>, Gregory Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Lime] Passive performance measurement methods

I tend to agree with this top down approach.
This is also concurring what has been discussed earlier about what LIME is doing.
https://www.ietf.org/mail-archive/web/lime/current/msg00357.html

Breaking down one model into OAM data model and OAM data triggering and retrieving model make it easy to map to technology specific OAM control
On the network node.
In the current model, we just make some of OAM data triggering and retrieving command optional.

-Qin
发件人: Lime [mailto:[e-mail]] 代表 Srihari Raghavan (srihari)
发送时间: 2016年6月3日 17:50
收件人: Frank Brockners (fbrockne); Deepak Kumar (dekumar); Gregory Mirsky
抄送: Carlos Pignataro (cpignata); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: Re: [Lime] Passive performance measurement methods

Hi Frank et al.,

The top-down approach seems to be a good approach taking into account the intent and aims of the draft and the status quo.

Re-design of the model in the draft either as different sub-sections or potentially a set of related models would help evolve different facets independently.  IMHO, OAM in the context discussed in the draft as well as in the WG should embrace expectations from the industry as well as its usage.  For eg., netNORAD is a variant of OAM wherein a combination of ping and trace route has been enhanced and automated to serve current industry needs.  Many such variants currently and in future may require common configuration buckets like a way to configure config, oper or performance parameters, way to trigger them on or off, on a periodic basis based on external events or on a publish-subscribe model and allow both local or out-of-the box processing (thus influencing data export and data encap configuration parameters) etc.,

IMHO, what we define here, should take into account such industry needs and allow flexibility to enable future innovations in the OAM area to be incorporated and configured.

Thanks
Srihari

From: Lime <[e-mail]<mailto:[e-mail]>> on behalf of "Frank Brockners (fbrockne)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 1 June 2016 at 2:04 PM
To: "Deepak Kumar (dekumar)" <[e-mail]<mailto:[e-mail]>>, Gregory Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Lime] Passive performance measurement methods

Hi folks,

There are two types of logic we can follow when defining the model for connectionless OAM.


·       We could either approach things “bottoms up”, which means that we take the current OAM mechanisms and try to summarize them and genericize them into a model, or

·       We could approach things “top down” and define OAM procedures, OAM data, and OAM data retrieval methods – which would then map to OAM mechanisms like ping, traceroute, bfd, vccv, etc.

Reading through the latest rev of the draft, it mostly follows a “bottoms up” logic. While a feasible approach, we’ll always be bound by “what exists today” – and the discussion about “passive” (or whatever we call this) looks like a good example for what we eventually miss.

Given that models are typically driven by the desired state, i.e. top down, IMHO it would make sense to also follow this approach here. As part of this, we would most likely need to re-design the model in the current draft and even consider breaking it up into a set of related models:


·       Model for OAM data to be retrieved – i.e. path information, reachability information, path validity information, delay information (e2e, per hop)

·       Model for methods to trigger and retrieve the data – those could be NC RPC or NC notifications, but other methods are feasible as well and are already in use by the industry (e.g. retrieval using Kafka, IPFIX, gRPC, …). Let’s acknowledge that YANG is no longer married to Netconf only.

·       Models of the mechanisms – those would be protocol specific (which are prominently present in the document right now), where we’d have details on BFD, VCCV, etc. etc.

With such an approach, we could cover the future (i.e. do the top down approach), while being well grounded on existing protocols and mechanisms. Or in other terms, we could cover “passive/hybrid/…” from an OAM data perspective – but can leave the mechanism definition for when things are properly specified.

Thoughts?

Thanks, Frank

From: Lime [mailto:[e-mail]] On Behalf Of Deepak Kumar (dekumar)
Sent: Wednesday, June 01, 2016 8:26 AM
To: Gregory Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: Carlos Pignataro (cpignata) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Lime] Passive performance measurement methods

Hi Greg,

Thanks for comments.

Carlos/Ron,

Please provide guidance as we can move things that are not RFC based definition for passive oam to another draft so current draft is more acceptable for WG adoption as per working group comments few modifications are premature.

Thanks
Deepak

Sent from my iPhone

On Jun 1, 2016, at 11:05 AM, Gregory Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi Deepak,
thank you for providing the reference to the draft to which the YANG model has been added. I think that adding a data model of individual draft not yet adopted by the NVO3 WG  to the document that describes generic OAM mechanisms that are being used in the CL networks is premature step at this time. I’d not see the draft draft-kumar-lime-yang-connectionless-oam  in its current form as the reasonable foundation for the WG adoption.

                Regards,
                                Greg

From: Deepak Kumar (dekumar) [mailto:[e-mail]]
Sent: Tuesday, May 31, 2016 8:29 PM
To: Carlos Pignataro (cpignata); Gregory Mirsky
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Lime] Passive performance measurement methods

Hi,

If for protocol like LSP ping, TRILL, etc. response come out of band, but that's protocol behavior and data generated from both method for receive of frame is same which is what Yang objects are providing.
I can see RPC extension for Transmit in protocol specific part to add method to be carried in packet that reply mode is out of band, but then it's protocol specific augmentation.
I believe as this RPC driven it's Active OAM.

In case of Passive OAM ("Match and Mirror OAM" looks better term from forwarding) it's basically counting data packet(s) with Matching criterion configured throughout the network and no RPC in network is involved to generate the packets.
In this some OAM solution do increase the size of packet (piggy back) when certain capability is turned on, but some just redirect it to controller for processing (Alibaba OAM, https://tools.ietf.org/html/draft-pang-nvo3-vxlan-path-detection-02) without changing the data packet.

Thanks,
Deepak

From: Lime <[e-mail]<mailto:[e-mail]>> on behalf of "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, May 31, 2016 at 8:55 AM
To: Gregory Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Lime] Passive performance measurement methods

Hello, Huub,






On May 31, 2016, at 4:28 AM, Huub van Helvoort <[e-mail]<mailto:[e-mail]>> wrote:

Hello Carlos,

You wrote:






Should we then have an ‘in-band’ category instead of ‘passive’?

How would you categorise OAM that is sent in the data plane (in-band)
and the response is via the control plane (out-band)?

Good point. This is a very real question, given the ‘reply mode’ options in LSP Ping and BFD.

If a “response” is sent via the control plane, I tend to think that that’s separate from the forward direction, which gives the categorization. For example, LIME models include configuration. If we configure an inband probe at the originator, we can also configure a reply mode for that probe. For a PM case, for example, if the actual measurement is done on the forward direction but then a response is sent, somewhere, via whichever means, that is a collection of stats and not an instantiation of OAM.

The challenge I see is that there’s an important set of permutations of all these cases...






Cheers, Huub.

Hello, Greg,

On May 31, 2016, at 10:41 AM, Gregory Mirsky <[e-mail]<mailto:[e-mail]>> wrote:

Hi Huub,
this is very interesting question. In some aspect, we've tried to address it in BFD directed draft<https://tools.ietf.org/html/draft-ietf-mpls-bfd-directed-02> to control the reverse direction for BFD over MPLS LSP session. As for PM OAM, if the method is uni-directional, then we still can refer to it as in-band. If it is bi-directional, then, in my opinion, it is poorly designed and unreliable method as it would not produce useful metrics that reflect behavior of the bi-directional flow.

This is similar to what I alluded to — if the PM method acts on one direction, in-band, then I believe LIME should separate the actual ‘telemetry’ / PM from the collection of measurements.

Thanks,

— Carlos.







                Regards,
                                Greg

-----Original Message-----
From: Lime [mailto:[e-mail]] On Behalf Of Huub van Helvoort
Sent: Tuesday, May 31, 2016 1:29 AM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Lime] Passive performance measurement methods

Hello Carlos,

You wrote:

> Should we then have an ‘in-band’ category instead of ‘passive’?

How would you categorise OAM that is sent in the data plane (in-band) and the response is via the control plane (out-band)?

Cheers, Huub.


>> On May 30, 2016, at 3:56 AM, Gregory Mirsky
>> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>> wrote:
>>
>> Hi Qin,
>> I see the piggy-back as hybrid method, not passive as it changes
>> length of the data packet. Besides, the piggy-back is not the only
>> method to collect the telemetry. The telemetry collection can be
>> triggered by active OAM as documented in
>> thehttps://datatracker.ietf.org/doc/draft-lapukhov-dataplane-probe/
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dlapukhov-2Ddataplane-2Dprobe_&d=CwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=LU_vJaM_EQu1Ssm35j2xlA&m=V44pRh0rYL1WRMQ5huDqjeBi35jKHaB-WvC_3M_aNWg&s=QcOcy1X8UHfdzd975mnt7fXkUpO8_km4CIacav0m8i8&e=>.
>> Thus, as I believe, including particular method in the Common YANG
>> data model is questionable.
>>             Regards,
>>                                 Greg
>> *From:*Qin Wu [mailto:[e-mail]] *Sent:*Monday, May 30, 2016
>> 12:45 AM *To:*Gregory Mirsky; Carlos Pignataro (cpignata)
>> *Cc:*[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> *Subject:*RE: [Lime] Passive performance measurement methods Yes, in
>> band and out band is another angle to categorize the OAM methods. I
>> agree with your observation below.
>> So it looks to me piggyback method is also in band passive method.
>> -Qin
>> *发件人**:*Gregory Mirsky [mailto:[e-mail]]
>> *发送时间:*2016年5月30日15:26
>> *收件人:*Qin Wu; Carlos Pignataro (cpignata)
>> *抄送:*[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> *主题:*RE: [Lime] Passive performance measurement methods Hi Qin, in my
>> view, active/passive vs. in-band/out-band are orthogonal
>> characteristics of an OAM method. Passive OAM is always in-band as it
>> uses the data flow itself. Active may be in-band (highly desired as
>> it makes interpretation of OAM much unambiguous) or out-band. I think
>> that in regard to definition of active/passive (and hybrid in
>> between) RFC 7799 is as clear as it gets. And in-band vs. out-band is
>> different characteristic of the OAM in the particular layer. E.g.
>> Ethernet OAM is always in-band. So is MPLS if we use EL/ELI. IP – in
>> general case, is not guaranteed to be in-band for multi-hop.
>> Hope that clarifies the issue.
>>                 Regards,
>>                                 Greg
>> *From:*Qin Wu [mailto:[e-mail]] *Sent:*Monday, May 30, 2016
>> 12:15 AM *To:*Gregory Mirsky; Carlos Pignataro (cpignata)
>> *Cc:*[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> *Subject:*RE: [Lime] Passive performance measurement methods Hi,
>> Greg:
>> Thanks for your clarification, It looks you agree that MPLS PM
>> protocol provides active measurement method.
>> But unlike OWAMP, TWMAP(could be out band), MPLS PM provides an
>> in-band measurement method.
>> So we see the relation between active, passive and in-band and out-band.
>> Based on use cases you mentioned, not all the in-band methods are
>> active measurement methods. Not all passive method are out-band.
>> Unfortunately RFC7799 doesn’t clarify this or gives any criteria.
>> -Qin
>> *发件人**:*Gregory Mirsky [mailto:[e-mail]]
>> *发送时间:*2016年5月30日12:53
>> *收件人:*Qin Wu; Carlos Pignataro (cpignata)
>> *抄送:*[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> *主题:*RE: [Lime] Passive performance measurement methods Hi Qin, thank
>> you for your most expedient response. Please find my notes in-line
>> and tagged GIM>>.
>>                 Regards,
>>                                 Greg
>> *From:*Qin Wu [mailto:[e-mail]] *Sent:*Sunday, May 29, 2016
>> 8:31 PM *To:*Gregory Mirsky; Carlos Pignataro (cpignata)
>> *Cc:*[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> *Subject:*RE: [Lime] Passive performance measurement methods
>> *发件人**:*Lime [mailto:[e-mail]]*代表*Gregory Mirsky
>> *发送时间:*2016年5月30日10:59
>> *收件人:*Qin Wu; Carlos Pignataro (cpignata)
>> *抄送:*[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> *主题:*Re: [Lime] Passive performance measurement methods Hi Qin,
>> you’ve said:
>> “I read some drafts discussed in IPPM, it looks generating OAM packet
>> for measurement or defining dedicated PM protocol for measurement is
>> labeled as passive method …”
>> Generating special test packets is clearly characteristic of active OAM.
>> [Qin]: That’s my understanding.
>> Defining dedicated PM protocol is neither active, nor passive by itself.
>> [Qin]: I thought dedicated PM protocol message is one special example
>> of special test packet.
>> For example, draft-mirsky-bier-pmmm-oam describes how the marking
>> method can be applied in BIER domain. Since it proposes to use field
>> that neither used for determining the next hop, nor QoS treatment.
>> BIER network processes the marked packet absolutely the same way as
>> unmarked. But if we decide to apply the marking method, for example,
>> to IPv4 domain using , e.g. part of the DSCP field, then, obviously,
>> marked packets may be treated differently.
>> [Qin]: Not sure I get this. Usually dedicated PM protocol doesn’t
>> need to take the same path as user traffic.
>> GIM>> If OAM packets don’t share the path, i.e. are in-band, with the
>> data flow that is being monitored/measured that is a problem, not
>> desired behavior.
>> One example of dedicated PM protocol is OWAMP or TWAMP protocol.
>> GIM>> Yes, in ECMP environment OWAMP/TWAMP test packet not guaranteed
>> to follow the same path and the flow being monitored. Unfortunately.
>> Another example of dedicated PM protocol is MPLS PM protocol. MPLS PM
>> protocol define Loss measurement Message format, Delay Measurement
>> Message format.
>> GIM>> I cannot agree that MPLS PM would not follow the path of the
>> same LSP it shares label with if we use GAL label and do hashing
>> based on EL.
>> What you proposed in draft-mirsky-bier-pmmm-oam is you extend BIER
>> header with OAM support, which is in-band method. But you didn’t
>> define dedicated OAM protocol or PM protocol for measurement, based
>> on my understanding.
>> GIM>> You use terminology I’m not familiar with. Note, that the
>> PMMM-OAM draft doesn’t extend the BIER in MPLS network header but
>> proposes new field and thus there’s no impact on any experimental
>> implementation there may exist. Besides, BIER in MPLS network already
>> recognizes OAM as distinct payload and that ensures that all active
>> OAM, whether fault management or performance measurement, are in-band
>> with data transported over BIER. Which is what is required behavior.
>> And I curious, which drafts suggest that generating OAM packets
>> produces passive method?
>> [Qin]: See 3^rd paragraph of section 1 in
>> draft-chen-ippm-coloring-based-ipfpm-framework-06
>> You are also coauthor of this draft,J. In this draft, MPLS PM
>> protocol [RFC6374] is categorized as passive measurement which I
>> thought it should be active measurement.
>> GIM>> To be precise, the draft says “could be considered an example
>> GIM>> of
>> a passive performance measurement method”, i.e. assumes that it may
>> be viewed. It was written before we had discussion that resulted in
>> RFC
>> 7799 that clarified the definitions. We’ll discuss and update in the
>> next version, thank you.
>> Passive, in my understanding means you don’t change packet header or
>> payload, you don’t define new PM protocol, you just rely on network
>> probe to get a copy of user traffic and use them to collect some metrics.
>> GIM>> Copying traffic, i.e. mirroring it may or may not be classified
>> as passive method, in my opinion, as that would depend upon number of
>> copied packets and whether copies being transported in-band or over
>> separate management network.
>>                 Regards,
>>                                 Greg
>> *From:*Qin Wu [mailto:[e-mail]] *Sent:*Sunday, May 29, 2016
>> 7:23 PM *To:*Carlos Pignataro (cpignata); Gregory Mirsky
>> *Cc:*[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> *Subject:*RE: [Lime] Passive performance measurement methods
>> *发件人**:*Lime [mailto:[e-mail]]*代表*Carlos Pignataro
>> (cpignata)
>> *发送时间:*2016年5月30日6:35
>> *收件人:*Gregory Mirsky
>> *抄送:*[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>> *主题:*Re: [Lime] Passive performance measurement methods Thank you,
>> Greg.
>> In my view, this might still be a bit of a gray area, where we need
>> to early converge on definitions. I recommend linking with Al/ippm to review.
>> Here’s an additional variable on the definition equation: there’s an
>> area of measurement that is considered“passive marking methods”,
>> meaning use existing traffic (and not inject synthetic packets), but
>> slightly modify them / mark them. One such example is in
>> draft-tempia-ippm-p3m-03, and in particular an area where you are a
>> bit familiar with:
>> https://tools.ietf.org/html/draft-tempia-ippm-p3m-03#section-4.3:-)
>> So setting specific bits in packets that do not modify the protocol
>> behavior is not“truly passive”, but it is“kinda passive”.
>> Consequently, perhaps we need to find other definitions of in-band vs.
>> out-of-band.
>> Active—artificial packets injected.
>> Passive—existing unmodified packets.
>> ???—existing packets with slightly appended data.
>> Thoughts?
>> [Qin]: Is active passive only limited to PM?
>> What’s the difference between injecting the artificial packets and
>> appending data in the existing packets, it looks the latter is also
>> called piggyback method as mentioned by Greg.
>> For active, besides injecting artificial packets, you may also need
>> to consider generating OAM packet for measurement, if the OAM packet
>> generated goes the same way as user traffic, it is in band, if it
>> goes the different way, it is out-band.
>> I read some drafts discussed in IPPM, it looks generating OAM packet
>> for measurement or defining dedicated PM protocol for measurement is
>> labeled as passive method, which make me confused, can somebody
>> clarify this a little bit to me?
>> Also I want to understand whether piggyback method is passive or hybrid?
>> Thanks,
>> —Carlos.
>>
>>     On May 28, 2016, at 10:09 PM, Gregory Mirsky
>>     <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>
>>     wrote:
>>     Dear All,
>>     out of our review of the draft-kumar-lime-yang-connectionless-oam
>>     I took AP to provide reference to the definition of Passive
>>     Method.RFC 7799 <https://tools.ietf.org/html/rfc7799>Active and
>>     Passive Metrics and Methods  (with Hybrid Types In-Between) is
>>     product of discussions in IPPM WG. Section 3.6 opens with the
>>     detailed definition:
>>        Passive Methods of Measurement are:
>>        o  based solely on observations of an undisturbed and unmodified
>>           packet stream of interest (in other words, the method of
>>           measurement MUST NOT add, change, or remove packets or fields or
>>           change field values anywhere along the path).
>>        o  dependent on the existence of one or more packet streams to
>>     supply
>>           the stream of interest.
>>        o  dependent on the presence of the packet stream of interest
>>     at one
>>           or more designated Observation Points.
>>     We’ve discussed whether methods that do alter a flow can be
>>     considered truly Passive. The agreement was that if introduced
>>     change does not affect treatment of the flow in the network, then
>>     the method can be considered Passive. For example, marking method
>>     that uses special field that not used in forwarding and/or in
>>     policing/scheduling. At the same time, if the marking method
>>     changes treatment of the flow, then it cannot be considered
>>     Passive but likely can be characterized as Hybrid (see discussion
>>     in Section 3.8. To the same category belong methods that alter
>>     packet length.
>>                     Regards,
>>                                     Greg
>>     _______________________________________________
>>     Lime mailing list
>>     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/lime
>>
>
>
>
> _______________________________________________
> Lime mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/lime
>


--
================================================================
Always remember that you are unique...just like everyone else...

_______________________________________________
Lime mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lime
_______________________________________________
Lime mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lime