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

[Gregory Mirsky <[e-mail]>]

Hi Stewart,
apologize for delayed response.
I still believe that though defining new TLV that includes both IP address and port number is doable it is not the best approach to control MPLS PM sessions. RFC 6374 requires control of each and every test/query packet thus making some tests impossible to execute (e.g. SLM with smaller packet sizes when TLVs has to be used to provide explicit control). I believe that extending RFC 6374 with Session Control and Data Fetch commands may be reasonable alternative to controlling each test packet explicitly through TLVs.
True, I don't have document that describes the alternative approach at this time but would appreciate it be considered and welcome opportunity to discuss it in any format.

	Regards,
		Greg

-----Original Message-----
From: Stewart Bryant [mailto:[e-mail]] 
Sent: Wednesday, June 04, 2014 3:29 AM
To: Gregory Mirsky; MORTON, ALFRED C (AL); Eric Gray; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

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