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

From: Stewart Bryant <[email-masked]>
Date: Tue, 20 May 2014 16:50:20 +0100

Apropos the above, the proposal in the draft is simple and
satisfies a need that an operator has requested us to address.

In this case I do not think a complete test protocol is needed or justified,
and in any case would be a lot more effort to implement compared
to the proposal on the table.

I would like to understand how best to move forward with this.

- Stewart

On 10/04/2014 15:06, Eric Gray wrote:
>
> I agree with the port reviewers.  A well-known port would have been a 
> target.
>
> *From:*Stewart Bryant [mailto:[email-masked]]
> *Sent:* Wednesday, April 09, 2014 10:31 AM
> *To:* Eric Gray; Gregory Mirsky; 
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return
> *Importance:* High
>
> On 09/04/2014 13:58, Eric Gray wrote:
>
>     Stewart,
>
>     Well, you're adding 4 bytes to handle the case where the response
>     is to be
>
>     returned using UDP.  This is in addition to the address
>     information already included
>
>     in the message as defined by RFC 6374.
>
> Sure
>
> It's certainly arguable that this new information does not need to be 
> carried
>
> in the test messages, assuming that there might be a control protocol 
> used instead.
>
>
>
> The question as to whether or not this is "heavy-weight" depends on how
>
> many additional ways one might envision returning the response.
>
> Well I am not convinced that you would want to send it over TCP.
> We already have a way to return it over MPLS - via LSP association
> or via the use of a first hop label encoded in the address field.
> That leaves UDP/IP which this draft deals with.
>
> Our first thoughts were BTW to request a UDP port, and we submitted
> a port request, but the port reviewers suggested that we should find a
> way to do it using dynamic ports, and that is what the draft describes.
>
> Stewart
>

-- 
For corporate legal information go to:

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

---

From: Loa Andersson <[email-masked]>
Date: Wed, 21 May 2014 07:00:51 +0200

Stewart,

I can give you the more formal part of the answer on how to
proceed.

- if the authors think this is ready for wg adoption, they
   should tell the chairs

- the chairs will the start the following process
   -- a chair review to see if we agree with the authors that
      it is time to start the wg adoption process (usually
      results in a set of comments that need to be address)
   -- IPR poll
   -- MPLS-RT review (more comments to be addressed)
   -- wg adoption poll

/Loa

On 2014-05-20 17:50, Stewart Bryant wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Loa Andersson <[email-masked]>
Date: Wed, 21 May 2014 07:31:26 +0200

Stewart,

Redaing the Solution Overview in your document I find:

"The Return Address TLV and the Return UDP PORT TLV carried in the
  MPLS-PM query message are used to specify to the Responder how to
  return the response message."

I would have thought that the MPLS-PM query message would be defined
in RFC 6474, but I can't find it. Where is it defined?

Is it a joint name for:

Loss Measurement Message, Delay Measurement Message, and Combined 
Loss/Delay Measurement Message?

/Loa

--

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 May 2014 14:29:46 +0100

This should be clearer in the new version.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 May 2014 15:51:21 +0100

> - if the authors think this is ready for wg adoption, they
I have uploaded a new version, and I think it is ready for adoption.
>      results in a set of comments that need to be address) 
Your comments were addressed in version 1, plus a few
clarifications that I considered consequential to these
comments.

>   -- IPR poll
No IPR from this author.
>   -- MPLS-RT review (more comments to be addressed)
That sounds a bit pessimistic.
>   -- wg adoption poll 
We had some comments on the list but none so far are actionable
on this document.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 May 2014 16:12:10 +0100

On 09/04/2014 13:58, Eric Gray wrote:
>
> Stewart,
>
> Well, you're adding 4 bytes to handle the case where the response is to be
>
> returned using UDP.  This is in addition to the address information 
> already included
>
> I suspect this is the "bigger puzzle" that Greg refers to...
>
Eric

In terms of bytes which seems to be the focus of your initial para
and considering the packet loss case, the base message is 84 bytes.
Add an ACH, a delivery label and a GAL that is 96 bytes. It will
probably go over Ethernet so that is 110 bytes.

Considering the IPv4 case, and noting that the address object
is already an agreed TLV the total goes to 118 bytes. So the
additional UDP port object which is 4 bytes is a little over 3%
If you take the address in IPv6 and the UDP compared to base
without an address the increase is 20/110 which is 18% which
is a little irritating but not out of this world.

In contrasting this with any other approach you would need
to compare the per packet measurement overhead with the
session maintenance overhead of the other method.

My assumption is that for any measurement request there
would only be one method of responding. Can you see a
deployment scenario where it would be beneficial to give
the responder a choice of methods of responding in every
request?

- Stewart

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 22 May 2014 00:59:25 +0000

Hi Stewart,
I think that need for the extension you've proposed is indication that per query control approach taken in RFC 6374 may not be the most efficient in longer run. I think that establishing a test session through dedicated Command message, as extension/update to RFCs 6374/6375, is possible and is more flexible way. And I think that maintaining a session would make upload of measurement results more efficient when compared with uploading one measurement at the time.
And though LMAP framework<https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/?include_text=1> concentrates on performance measurement in massive IP access networks its model may be used as reference. I believe that there're plausible scenarios when multiple Collectors request upload of measurement results from an Measurement Agent.

                Regards,
                                Greg

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, May 21, 2014 8:12 AM
To: Eric Gray; Gregory Mirsky; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

                Well, you're adding 4 bytes to handle the case where the response is to be
returned using UDP.  This is in addition to the address information already included
in the message as defined by RFC 6374.

                It's certainly arguable that this new information does not need to be carried
in the test messages, assuming that there might be a control protocol used instead.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 22 May 2014 18:03:19 +0100

On 22/05/2014 01:59, Gregory Mirsky wrote:
>
> Hi Stewart,
>
> I think that need for the extension you've proposed is indication that 
> per query control approach taken in RFC 6374 may not be the most 
> efficient in longer run.
>
Clearly I disagree. The proposed extension is a simple extension to an 
existing standards track specification.
>
> I think that establishing a test session through dedicated Command 
> message, as extension/update to RFCs 6374/6375, is possible and is 
> more flexible way.
>
You need to put a design on table and prove your point here. Do you have 
a draft I can read?
>
> And I think that maintaining a session would make upload of 
> measurement results more efficient when compared with uploading one 
> measurement at the time.
>
We make no comment about the upload, or any other relationship to an 
NMS, just the text protocol.
>
> And though LMAP framework 
> <https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/?include_text=1> 
> concentrates on performance measurement in massive IP access networks 
> its model may be used as reference. I believe that there're plausible 
> scenarios when multiple Collectors request upload of measurement 
> results from an Measurement Agent.
>
Is there an IETF draft you can point me to?

- Stewart
> *Sent:* Wednesday, May 21, 2014 8:12 AM

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 22 May 2014 18:10:32 +0000

Hi Stewart,
the LMAP framework is the link to the https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/?include_text=1

                Regards,
                                Greg

From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, May 22, 2014 10:03 AM
To: Gregory Mirsky; Eric Gray; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

On 22/05/2014 01:59, Gregory Mirsky wrote:
Hi Stewart,
I think that need for the extension you've proposed is indication that per query control approach taken in RFC 6374 may not be the most efficient in longer run.
Clearly I disagree. The proposed extension is a simple extension to an existing standards track specification.

I think that establishing a test session through dedicated Command message, as extension/update to RFCs 6374/6375, is possible and is more flexible way.
You need to put a design on table and prove your point here. Do you have a draft I can read?

And I think that maintaining a session would make upload of measurement results more efficient when compared with uploading one measurement at the time.
We make no comment about the upload, or any other relationship to an NMS, just the text protocol.

- Stewart

                Regards,
                                Greg

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, May 21, 2014 8:12 AM
To: Eric Gray; Gregory Mirsky; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

- Stewart

--

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 22 May 2014 23:29:39 +0100

That is way outside the scale and scope of this measurement.

Stewart

On 22/05/2014 19:10, Gregory Mirsky wrote:
>
> Hi Stewart,
>
> the LMAP framework is the link to the 
> https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/?include_text=1
>
> Regards,
>
> Greg
>
> *Sent:* Thursday, May 22, 2014 10:03 AM
> *To:* Gregory Mirsky; Eric Gray; 
>     I think that need for the extension you’ve proposed is indication
>     that per query control approach taken in RFC 6374 may not be the
>     most efficient in longer run.
>
> its model may be used as reference. I believe that there’re plausible 
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
>     I suspect this is the "bigger puzzle" that Greg refers to…
>
> Eric
>

---

From: Eric Gray <[email-masked]>
Date: Fri, 23 May 2014 13:47:38 +0000

Stewart,

	I disagree with the characterization of a reference to the LMAP approach as 
"way outside the scale and scope of this measurement."

	It may require more energy than any of us have, but the LMAP Framework
draft merely defines a generic protocol model.  It is certainly possible to define the
limited subset of messages required specifically for this application, while leaving
the possibility of defining others to be done later, if needed.

	That approach establishes roughly the same "scale and scope" as does your
proposal, without requiring changes to every implementation's forwarding plane to
process one more bit of information.

	Perhaps - if we dig around a bit - we can find someone who does have the
energy to work on this?  Two of the authors of the LMAP draft are your colleagues
after all.

	One issue is that you mention a customer requirement.  Yet, if you looked
at the LMAP draft (which I assume you did), you must have noticed the author list
also includes folks from BT and AT&T (as well as Universidad Carlos III Madrid, and
Cisco).

	Perhaps it is a good idea to determine if your approach would meet their
requirements as well?

	Isn't it worth checking with other customers to determine if they are okay 
with the approach in your draft, and possibly trying to find someone with energy 
(and bandwidth) to pursue a quick proposal (scoped to this specific measurement 
and based on LMAP) - if it turns out some customers would prefer that approach?

--
Eric

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, May 22, 2014 6:30 PM
To: Gregory Mirsky; Eric Gray; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return
Importance: High

Stewart

On 22/05/2014 19:10, Gregory Mirsky wrote:
>     I think that need for the extension you've proposed is indication
> <https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/?include_t
> ext=1> concentrates on performance measurement in massive IP access 
> networks its model may be used as reference. I believe that there're 
> plausible scenarios when multiple Collectors request upload of 
> measurement results from an Measurement Agent.
>
> In terms of bytes which seems to be the focus of your initial para and 
> considering the packet loss case, the base message is 84 bytes.
> Considering the IPv4 case, and noting that the address object is 
> already an agreed TLV the total goes to 118 bytes. So the additional 
> UDP port object which is 4 bytes is a little over 3% If you take the 
> address in IPv6 and the UDP compared to base without an address the 
> increase is 20/110 which is 18% which is a little irritating but not 
> out of this world.
>
> In contrasting this with any other approach you would need to compare 
> the per packet measurement overhead with the session maintenance 
> overhead of the other method.
>
> My assumption is that for any measurement request there would only be 
> one method of responding. Can you see a deployment scenario where it 
> would be beneficial to give the responder a choice of methods of 
> responding in every request?
>
> - Stewart
>
>
>
>
> --

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 23 May 2014 16:18:27 +0100

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

---

From: Eric Gray <[email-masked]>
Date: Fri, 23 May 2014 15:47:08 +0000

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; [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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 23 May 2014 13:13:55 -0400

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

> 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]
> Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return
> 
> Stewart,
> 
> 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

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 25 May 2014 00:14:22 +0000

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). 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):

                                                              ^
                                                              |

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

> 	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
> 	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.
> 
> 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