Re: [mpls] FW: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-07.txt

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

Hi Greg,

> many thanks for your thoughtful comments and am terribly sorry it took me
> so long to get back with resolution. Please find my notes in-lined and
> tagged by GIM>>.

[NOBO] Thanks for considering my comments. Snipping in only those comments I had some responses to. Please look for [NOBO] in-line.

> PS. Attached is work-in progress with updates based on your review.

[NOBO] I appreciate you attaching that. I do plan to read the updated version soon, but do go ahead with publication, perhaps after one comment below is closed off.
 
> (1) In Section 2.1
> 
>    Typically intermediate nodes should not process or modify any of the
>    OAM configuration TLVs but simply forward them to the end-node.
> 
> Should above "should not" be upper case "SHOULD NOT"?
> GIM>> I think that "SHOULD NOT" is too restrictive particularly because the
> next sentence lists the exclusion.
> I've re-phrased the sentence to:
> Typically intermediate nodes simply forward OAM configuration TLVs to the
> end-node without any processing or modification. At least one exception to
> this is if the FMS sub-TLV is present.
> Would you agree?

[NOBO] Yes I agree with your point and the rephrased text looks good.

> (7) In Section 2.2.1
> 
>    PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic
>    continuity monitoring messages.
> 
> Perhaps I missed this, but I couldn't find what goes into the PHB bits (3 bits)
> and what behaviors are expected. Can you elaborate?
> GIM>> PHB, in this case and in 2.2.1.  BFD Configuration sub-TLV, meant as
> QoS setting. At the time the document was started, if I’m not mistaken, we
> still referred to the three bit-long field as EXP, not as TC. Would changing
> PHB to TC help?

[NOBO] I see. In that case, yes renaming the field from PHB to TC is a helpful change. I do have further questions which I hope will help you to cook up necessary change/texts to clarify this field.
- As for the expected behavior, the receiver of this TLV is to use the TC value specified in this TLV as the TC value in the label carrying transmitted BFD packets? If so, is that expected behavior a SHOULD or MUST for the receiver? SHOULD is probably more appropriate, as that will allow a node to override the suggested value if/when needed (i.e., via configuration).
- It doesn't look like there's any way for the sender of this TLV to say "you decide the TC field". If such instruction is more of the normal mode of operation, then perhaps moving this PHB/TC field into a Sub-TLV might be more appropriate. 

Thanks!

-Nobo