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

[Gregory Mirsky <[e-mail]>]

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:[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_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]<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