Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

[Stewart Bryant <[e-mail]>]

On 25/05/2014 01:14, Gregory Mirsky wrote:
> Dear Al,
> thank you for your analysis of the draft and its correlation with the LMAP framework.
> I think that the RFC 6374 gives option for the responder, Measurement Peer (MP) in LMAP framework terminology, to send measurement result to an arbitrary destination, not only to the Querier, Measurement Agent (MA).
Yes it does, although as written not to multiple collectors. Do you need 
that? If so I would need to use a modified TLV with the both the address 
and the port since the port will be address dependent.

- Stewart
>   Though such scenario is not considered for MP in the LMAP framework, I believe we can still refer to that node as Data Collector because MA instructed MP perhaps based on information received from the Measurement Controller.
> During our discussion Stewart asked if there could be case of multiple Data Collectors for the given Measurement Task. That is when I referred to the LMAP framework as I believe that it allows to associate  multiple Data Collectors with the Measurement Task. Is my understanding correct?
>
> 	Regards,
> 		Greg
>
> -----Original Message-----
> From: MORTON, ALFRED C (AL) [mailto:[e-mail]]
> Sent: Friday, May 23, 2014 10:14 AM
> To: Eric Gray; [e-mail]; Gregory Mirsky; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return
>
> Eric, Stewart,
>
> It seems to me (after scanning the draft) that the MPLS-PLDM could be treated as the out-of-scope measurement traffic/protocol in the LMAP Framework Figure 1 below (Where IPPM is currently used as the out-of-scope example):
>
>                                                                ^
>                                                                |
>                                   Active    +-------------+    IPPM
>              +---------------+  Measurement | Measurement |    Scope
>              | Measurement   |<------------>|     Peer    |    |
>              |   Agent       |   Traffic    +-------------+    v
>     +------->|               |                                 ^
>     |        +---------------+                                 |
>     |              ^      |                                    |
>     |  Instruction |      |  Report                            |
>     |              |      +-----------------+                  |
>     |              |                        |                  |
>     |              |                        v                  LMAP
>     |         +------------+             +------------+        Scope
>     |         | Controller |             |  Collector |        |
>     |         +------------+             +------------+        v
>     |                ^   ^                       |             ^
>     |                |   |                       |             |
>     |                |   +----------+            |             |
>     |                |              |            v             |
> +------------+   +----------+    +--------+    +----------+   |
> |Bootstrapper|   |Subscriber|--->|  data  |<---|repository|   Out
> +------------+   |parameter |    |analysis|    +----------+   of
>                   |database  |    | tools  |                   Scope
>                   +----------+    +--------+                   |
>                                                                |
>
> The MPLS-PLDM Querier could be co-located with a Measurement Agent, and assuming the Querier performs all the coordination, including arranging to return the response message to a port co-located with the same Measurement Agent (or configuration takes the role of signaling), then the MPLS-PLDM responder could be treated as a Measurement Peer.  The LMAP Control and Report protocols provision and collect results from the Querier, taking the role of a "management system" mentioned in the draft.
>
> hope this helps,
> Al
>
>
>
>
>> -----Original Message-----
>> From: Eric Gray [mailto:[e-mail]]
>> Sent: Friday, May 23, 2014 11:47 AM
>> To: [e-mail]; Gregory Mirsky; draft-bryant-mpls-oam-udp-
>> [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return
>>
>> Stewart,
>>
>> 	I understand your point.  But the question is not whether or not it
>> will work, but rather whether or not there is consensus to do it this
>> way.
>>
>> 	On any given day, it is trivial to come up with any number of
>> approaches for doing something (whatever that something is) that will
>> _work_ - which is not the same as saying that we should all pour
>> energy into any of those ideas.
>>
>> 	I also understand the pressures associated with customer
>> requirements, but don't see why the customer(s) behind your
>> requirements should have the last word on which approach should be
>> used - based solely on those requirements.
>>
>> 	That approach leads to a point-solution that has a definite non-zero
>> cost.  As a general approach, the continuous generation of point
>> solutions has its own scaling issues.
>>
>> 	It is my hope that someone will have the energy to put together a
>> draft to propose an alternative based on LMAP.  I personally do not
>> have either the energy or the bandwidth.  In fact, I don't have the
>> bandwidth or the energy to continue in
>> this discussion.   I sincerely hope and intend this will be my last post
>> on this topic.
>>
>> 	If there is insufficient interest in developing the scaled-down
>> version of an LMAP-based proposal - either within the MPLS working
>> group, or among the LMAP framework authors - before the Toronto
>> meeting, or there is not a number of like objections raised on the
>> MPLS mailing list, then it would seem that the WG default consensus
>> is to proceed with your draft.
>>
>> 	Believe it or not, I personally can live with that.
>>
>> --
>> Eric
>>
>> -----Original Message-----
>> From: Stewart Bryant [mailto:[e-mail]]
>> Sent: Friday, May 23, 2014 11:18 AM
>> To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-
>> [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return
>> Importance: High
>>
>> Eric
>>
>> I think the onus is on you as the objector to provide me with a
>> pointer to a specific protocol alternative not a framework, or to show
>> why this simple addition of four bytes will not work in the manner that I describe.
>>
>> Stewart
> .
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html