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

["Nobo Akiya (nobo)" <[e-mail]>]

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)

In the second snippet from Section 4.3 above, I believe the condition should be && and not ||.

s/and the Address object or the URO is missing/and the Address object and the URO are missing/

[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.

--- nits ---

[Abstract]
s/proceedure/procedure/

[Introduction, last paragraph]
s/reponse/response/

[Solution Overview, first paragraph]
s/querry/query/

[Sending an MPLS-PM Response, second paragraph]
s/incuded/included/

[Sending an MPLS-PM Response, second paragraph]
s/Session Indentifier/Session Identifier/

Thanks!

-Nobo

> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: Monday, July 07, 2014 9:59 AM
> To: [e-mail]; [e-mail]; Adrian Farrel
> Cc: [e-mail]
> Subject: [mpls] Poll to see if we have support to make draft-bryant-mpls-
> oam-udp-return an mpls working group document
> 
> Working Group,
> 
> 
> The authors of draft-bryant-mpls-oam-udp-return has informed us that the
> draft is ready to be polled to see if we have consensus to make it a working
> group document.
> 
> This mail starts a two week adoption poll.
> 
> We have not yet done the IPR poll, it will be done in parallel to the adoption
> poll.
> 
> There are no IPR disclosed against this draft.
> 
> Please send your comments to the mpls working group mailing list
> ([e-mail])
> 
> This adoption poll ends Juli 21, 2014!
> 
> /Loa
> for the mpls wg co-chairs
> 
> --
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls