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

From: Stewart Bryant <[email-masked]>
Date: Wed, 04 Jun 2014 11:29:02 +0100

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:[email-masked]]
> Sent: Friday, May 23, 2014 10:14 AM
> To: Eric Gray; [email-masked]; Gregory Mirsky; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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:[email-masked]]
>> Sent: Friday, May 23, 2014 11:47 AM
>> To: [email-masked]; Gregory Mirsky; draft-bryant-mpls-oam-udp-
>> [email-masked]
>> Cc: [email-masked]; [email-masked]
>> 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:[email-masked]]
>> Sent: Friday, May 23, 2014 11:18 AM
>> To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-
>> [email-masked]
>> Cc: [email-masked]; [email-masked]
>> 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

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 13 Jun 2014 00:36:15 +0000

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:[email-masked]] 
Sent: Wednesday, June 04, 2014 3:29 AM
To: Gregory Mirsky; MORTON, ALFRED C (AL); Eric Gray; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

> 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, Measu…
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
> To: Eric Gray; [email-masked]; Gregory Mirsky; 
> [email-masked]
>> 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
> .
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 13 Jun 2014 01:26:38 -0400

Greg,

I have to admit to not really having read the draft until I saw this
discussion, which got me curious to see what all of the fuss was about. So
I went and read RFC 6374 and this draft, and also 4656.

Given the existence and presumed implementations of 6374, my intuition is
that this draft is a small addition to 6374 to fix a case that that had
escaped the authors at that time. I would bet that if the Return UDP Port
object had originally been included in 6374 to complement the Return
Address object, no one would have batted an eyelash.

Thus, I have no objection to this draft. The time to have discussed a
different approach was during the formation of RFC 6374, not now. Trying to
switch to an approach like RFC 4656 now is an extremely heavyweight fix to
a very small problem.

Cheers,
Andy

On Thu, Jun 12, 2014 at 8:36 PM, Gregory Mirsky <[email-masked]
> wrote:

> 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
>
> To: Gregory Mirsky; MORTON, ALFRED C (AL); Eric Gray;
> > 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).
> >   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
> >
> > 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):
> >
> >                                                                ^
> >                                                                |
> > 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
> >
> >
> >
> >
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>