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

From: Gregory Mirsky <[email-masked]>
Date: Tue, 8 Apr 2014 16:04:50 +0000

Dear Authors, et. al,
I think this is interesting and timely proposal. But I think that this is only part of bigger puzzle, part of MPLS PM Control Protocol. I think that need to retrieve, fetch PM data is the most common in one-way active PM. If that is the case, then there may be good reason to look at RFC 4656 One-Way Active Measurement Protocol (OWAMP)<http://tools.ietf.org/html/rfc4656> by IPPM WG. True, RFC 4656 has two protocols in itself - Control and Test. And with RFC 6374 being MPLS PM OAM Test protocol we might look at RFC 4656 as example of PM OAM Control protocol. And yes, there's Fetch function defined.

                Regards,
                                Greg

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 09 Apr 2014 12:58:48 +0100

On 08/04/2014 17:04, Gregory Mirsky wrote:
>
> Dear Authors, et. al,
>
> I think this is interesting and timely proposal. But I think that this 
> is only part of bigger puzzle, part of MPLS PM Control Protocol. I 
> think that need to retrieve, fetch PM data is the most common in 
> one-way active PM. If that is the case, then there may be good reason 
> to look at RFC 4656 One-Way Active Measurement Protocol (OWAMP) 
> <http://tools.ietf.org/html/rfc4656> by IPPM WG. True, RFC 4656 has 
> two protocols in itself - Control and Test. And with RFC 6374 being 
> MPLS PM OAM Test protocol we might look at RFC 4656 as example of PM 
> OAM Control protocol. And yes, there's Fetch function defined.
>
>                 Regards,
>
>                                 Greg
>

Greg

That is a very heavyweight approach to apply to RFC6374 compared to 
adding 4 bytes of data to the outgoing message to describe to the 
Responder how it should steer its response back.

Stewart

---

From: Eric Gray <[email-masked]>
Date: Wed, 9 Apr 2014 12:58:52 +0000

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

From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, April 09, 2014 7:59 AM
To: Gregory Mirsky; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

                Regards,
                                Greg

Greg

That is a very heavyweight approach to apply to RFC6374 compared to adding 4 bytes of data to the outgoing message to describe to the Responder how it should steer its response back.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 09 Apr 2014 15:30:46 +0100

> in the message as defined by RFC 6374.
Sure

> 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

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 9 Apr 2014 21:18:47 +0000

Hi Stewart,
I agree with characterization of RFC 4656 and RFC 5357 in RFC 6374 in the last paragraph of Introduction. But will point that both OWAMP and TWAMP RFCs define two protocols: PM OAM control and PM OAM test protocols. I see RFC 6374 as MPLS PM OAM test protocol, i.e. data plane, and think that there's benefit in discussion of MPLS PM OAM control protocol.
Regarding roles of Sender and Receiver/Responder. I think that proposal addresses one-way performance measurement and then far end is Receiver, not Responder. Fetching measurement data from Receiver may be viewed as operation of PM OAM control protocol, not test protocol.

                Regards,
                                Greg

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, April 09, 2014 4:59 AM
To: Gregory Mirsky; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

                Regards,
                                Greg

Greg

Stewart

---

From: Eric Gray <[email-masked]>
Date: Thu, 10 Apr 2014 14:06:20 +0000

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

Stewart