Re: [mpls] Poll to see if we have support to make draft-bryant-mpls-oam-udp-return an mpls working group document

[Stewart Bryant <[e-mail]>]

On 18/07/2014 01:50, Nobo Akiya (nobo) wrote:
> Hi Loa,
>
> I have read the document and on-list discussions around this document.
>
> I believe this document solves a necessary problem, and I believe the desire to define a solution based on the LMAP framework should not block the progress of this document (i.e. the two should be pursued independently).
>
> Therefore, I support the adoption of this document as a WG document.
>
> Below lists few comments which I would like to see addressed, but not blockers before becoming a WG document.
>
> [snip from Section 4]
>     If the URO is expected but is not present in Query message and an
>     MPLS-PLDM Response is requested out-of-band, the Query message MUST
>     NOT be processed further.  If received over a bidirectional LSP, the
>     control code of the Response message MUST be set to "Error - Missing
>     TLV" and a Response SHOULD be sent over the reverse LSP.
>
> [snip from Section 4.3]
>     If an Out-of-band response is requested and the Address object or the
>     URO is missing, the Query SHOULD be dropped in the case of a
>     unidirectional LSP.  If both these TLVs are missing on a
>     bidirectional LSP, the control code of Response message should set to
>     "Invalid Message" and the response SHOULD be sent over the reverse
>     LSP.
>
> Both snippets are describing the same procedure but there's a conflict with control code value mandated.
>       => "Missing TLV" (TBD) vs. "Invalid Message" (0x1C)
Good catch.

Since we have combined port and address, invalid Msg is probably good 
enough.

> In the second snippet from Section 4.3 above, I believe the condition should be && and not ||.
I don't think so.

Address only was the original mode and although I have doubts about
whether there are deployments we need to support it until it is deprecated.
Thus you might find an address TLV indicating a response over IP is 
required or
a URO indicating a response over UDP/IP is required.

I think we agreed that we needed to support multiple UROs in certain
circumstances however I am wondering whether we need to support
both modes (IP and URO) or the same packet.

> s/and the Address object or the URO is missing/and the Address object and the URO are missing/
Please see above. Since we combined address and port in the URO
only one TLV needs to be present
> [snip from Section 5]
>     Nothing in this document precludes the use of a configured UDP/IP
>     return path in a deployment in which configuration is preferred to
>     signalling.  In these circumstances the URO MAY be omitted from the
>     MPLS-PLDM messages.
>
> I'd like to propose a slightly different text, because such configuration may be to setup a default target for the response, in which case URO will be more preferred.
>
> [suggested text]
>     Nothing in this document precludes the use of a configured UDP/IP
>     return path that is more preferred than the target specified in
>     received UROs.  In these circumstances, the UROs in received MPLS-PM
>     Query MAY be ignored.  Alternatively use of a configured UDP/IP
>     return path as a default target may be specified (i.e. less preferred
>     than UROs).  In these circumstances, the absence of the UROs in
>     received MPLS-PM Query SHOULD NOT be treated as an error.
That works for me.

I will fix the nits as needs

Thanks for the review

Stewart