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

[Stewart Bryant <[e-mail]>]

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
>
> Regards,
>
> Greg
>
> *From:*Stewart Bryant [mailto:[e-mail]]
> *Sent:* Wednesday, May 21, 2014 8:12 AM
> *To:* Eric Gray; Gregory Mirsky; 
> [e-mail]
> *Cc:* [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