Re: Adam Roach's No Objection on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)

Hi Adam,

Please see inline below for responses to your comments and questions.

        Kerry


> On Jan 24, 2018, at 9:10 PM, Adam Roach <[email protected]> wrote:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-mboned-mtrace-v2-22: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to everyone who put in the work to improve the overall mtrace mechanism.
> I have a handful of substantive questions and comments, most of which I believe
> require clarifying text in the document.
> 
> ---------------------------------------------------------------------------
> 
> §3:
> 
>> All Mtrace2 messages are UDP packets.  For IPv4, Mtrace2 Query and
>> Request messages MUST NOT be fragmented.
> 
> Since Query messages can transit intermediate routers on the way to the LHR,
> this requirement seems to imply that Mtrace2 clients MUST set the IP
> do-not-fragment (DF) bit in Query messages. That should probably be called out
> explicitly here.
> 
> To be clear, the above text seems to intentionally allow fragmentation of Reply
> messages. Was that on purpose?
> 
> Finally, the corresponding IPv6 text puts a parallel restriction of 1280 bytes
> on "the Mtrace2 messages", which would imply all message types, not just Query
> and Request.  Again: is that the intention?
> 

We agree that for consistency and simplicity, it should be explicitly specified that
the IP do-not-fragment (DF) bit MUST be set for all Mtrace2 messages. We propose
the following re-wording of the paragraph quoted above:

*******

For IPv4, Mtrace2 Query/Request/Reply messages MUST NOT be fragmented. Therefore Mtrace2 clients and LHRs/RPs MUST set the IP header do-not-fragment (DF) bit for all Mtrace2 messages.   
> ---------------------------------------------------------------------------
> 
> §3.1:
> 
> All of the TLVs defined in this document appear to take pains to end on
> four-byte boundaries (e.g., inserting "must be zero" bytes as necessary). This
> document establishes an IANA registry for TLVs, presumably so new ones can be
> defined elsewhere. When new TLVs are defined, is is a requirement that their
> lengths are a multiple of four? If so, please indicate as much here, as it
> allows implementations to make certain simplifying assumptions.
> 
> If this isn't the case, it should also be indicated here so that implementations
> don't make such assumptions based on the six TLVs defined in this document.
> 

We agree to re-word the “Length” paragraph in the “3.1.  Mtrace2 TLV format” section as follows:

Current:

Length of Type, Length, and Value fields in octets.  Minimum
     length required is 3 octets.  The maximum TLV length is not
     defined; however the entire Mtrace2 packet length SHOULD NOT
     exceed the available MTU.

———

Proposed:

Length of Type, Length, and Value fields in octets.  Minimum
     length required is 4 octets.  The length MUST be a multiple
     of 4 octets. The maximum TLV length is not
     defined; however the entire Mtrace2 packet length MUST NOT
     exceed the available MTU.
> ---------------------------------------------------------------------------
> 
> §3.2.4:
> 
>>    This field contains a forwarding information/error code.  Values
>>    with the high order bit set (0x80-0xff) are intended for use as
>>    error or exception codes.
> 
> ...
> 
>>   0x06   WRONG_LAST_HOP  This router is not the proper LHR.
> 
> Given that the "WRONG_LAST_HOP" forwarding code appears to be a fatal
> condition based on client misconfiguration (per the description in §4.1.1),
> I'm a bit confused about what is meant by "error or exception codes." Assuming
> the assignment of 0x06 (rather than, say, 0x86) was intentional, I believe the
> description of when the high order bit is set needs additional text to explain
> more precisely what criteria is used to make such a determination.
> 

To more clearly differentiate and explain the cases for setting or not setting
the high order bit in the forwarding code, we propose the following change to the
paragraph describing the forwarding code in section 3.2.4:

Current:

This field contains a forwarding information/error code.  Values
 with the high order bit set (0x80-0xff) are intended for use as
 error or exception codes.  Section 4.1 and Section 4.2 explain how
 and when the Forwarding Code is filled.  Defined values are as
 follows:

Proposed:

This field contains a forwarding information/error code.  Values
with the high order bit set (0x80-0xff) are intended for use with conditions
that are transitory or automatically recovered. Other forwarding code values
indicate a need to fix a problem in the Query or a need to redirect the Query.
Section 4.1 and Section 4.2 explain how and when the Forwarding Code is
filled.  Defined values are as follows:

> ---------------------------------------------------------------------------
> 
> §3.2.6:
> 
>>     The Augmented Response Type is defined as follows:
>> 
>>        Code    Type
>>        ====    ===============================================
>>        0x01    # of the returned Standard Response Blocks
> 
> As this is a 16-byte field, it would be less confusing if this were:
> 
>>        Code      Type
>>        ======    ===============================================
>>        0x0001    # of the returned Standard Response Blocks
> 
> 

We agree and will make the recommended change.

> ---------------------------------------------------------------------------
> 
> §8:
> 
> I am surprised not to see an IANA registry created for the 16-bit "Augmented
> Response Type" field defined in §3.2.6. How are these values intended to be
> managed?
> 
We agree that it is appropriate to create an IANA registry for the “Augmented
Response Type”. We will request it and modify the document accordingly.

> 

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned