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

This should be clearer in the new version.

Stewart

On 21/05/2014 06:31, Loa Andersson wrote:
> Stewart,
>
> Redaing the Solution Overview in your document I find:
>
> "The Return Address TLV and the Return UDP PORT TLV carried in the
>  MPLS-PM query message are used to specify to the Responder how to
>  return the response message."
>
> I would have thought that the MPLS-PM query message would be defined
> in RFC 6474, but I can't find it. Where is it defined?
>
> Is it a joint name for:
>
> Loss Measurement Message, Delay Measurement Message, and Combined 
> Loss/Delay Measurement Message?
>
> /Loa
>
>
> On 2014-05-20 17:50, Stewart Bryant wrote:
>> Apropos the above, the proposal in the draft is simple and
>> satisfies a need that an operator has requested us to address.
>>
>> In this case I do not think a complete test protocol is needed or 
>> justified,
>> and in any case would be a lot more effort to implement compared
>> to the proposal on the table.
>>
>> I would like to understand how best to move forward with this.
>>
>> - Stewart
>>
>>
>>
>> On 10/04/2014 15:06, Eric Gray wrote:
>>>
>>> I agree with the port reviewers.  A well-known port would have been a
>>> target.
>>>
>>> *From:*Stewart Bryant [mailto:stbryant@cisco.com]
>>> *Sent:* Wednesday, April 09, 2014 10:31 AM
>>> *To:* Eric Gray; Gregory Mirsky;
>>> draft-bryant-mpls-oam-udp-return@tools.ietf.org
>>> *Cc:* mpls@ietf.org
>>> *Subject:* Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return
>>> *Importance:* High
>>>
>>> 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.
>>>
>>> Sure
>>>
>>> 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.
>>>
>>> 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
>>>
>>
>>
>> -- 
>> For corporate legal information go to:
>>
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>

-- 
For corporate legal information go to:

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