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

[Stewart Bryant <[e-mail]>]

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