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

[Eric Gray <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, May 22, 2014 6:30 PM
To: Gregory Mirsky; Eric Gray; [e-mail]
Cc: [e-mail]
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return
Importance: High

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_te
> xt=1
>
> Regards,
>
> Greg
>
> *From:*Stewart Bryant [mailto:[e-mail]]
> *Sent:* Thursday, May 22, 2014 10:03 AM
> *To:* Gregory Mirsky; Eric Gray;
> [e-mail]
> *Cc:* [e-mail]
> *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.
>
> And though LMAP framework
> <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.
>
> Is there an IETF draft you can point me to?
>
> - Stewart
>
> Regards,
>
> Greg
>
> *From:*Stewart Bryant [mailto:[e-mail]]
> *Sent:* Wednesday, May 21, 2014 8:12 AM
> *To:* Eric Gray; Gregory Mirsky;
> [e-mail]
> <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return
>
> 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.
>
>     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.
>
>     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
>
>
>
>
> --
> For corporate legal information go to:
>   
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>   


--
For corporate legal information go to:

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