Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)

[Susan Hares <[e-mail]>]

Robert: 

Thank you for your question.   I'm pulling the DISCUSS to the front. 

The Discuss in the phrases: 

"SHOULD be set to 0 on encoding, and MUST be ignored during decoding." 

is actually language used in many past routing drafts for expansion purposes. 

The difficultly in deploying new code is in the partial deployments. 
The "must be ignored" clause allows the transmitter to change
to something besides zero. 

This is a RFC5575bis document based past history of these 
statements in routing code. 

I've taken the remainder of your comments as editorial comments. 
Our authoring team loads these comments into github, and you are welcome to 
Contribute to the resolutions. 

Susan Hares 

-----Original Message-----
From: Robert Wilton via Datatracker [mailto:[e-mail]] 
Sent: Friday, April 24, 2020 5:49 AM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; Jie Dong; [e-mail]; [e-mail]
Subject: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)

Robert Wilton has entered the following ballot position for
draft-ietf-idr-rfc5575bis-23: Discuss

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-idr-rfc5575bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I don't know if this is a valid discuss point, so happy to be educated that it is always written this way and I'll remove my discuss ...

I note that in 5 places this document has text that states the equivalent to "SHOULD be set to 0 on encoding, and MUST be ignored during decoding." (example given below).

Doesn't this make extending this in future more risky because if new meaning are given to these bits then there could be senders already transmitting non 0 values which a receiver might then misinterpret?

Hence, I was surprised that the constraints did not also include a MUST on the encoding side (i.e. be strict in what you send ...), i.e. "MUST be set to 0 on encoding, and MUST be ignored during decoding."

Example:
   The extended is encoded as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   reserved    |   reserved    |   reserved    |   reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   reserved    | r.|    DSCP   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 6: Traffic Marking Extended Community Encoding

   o  DSCP: new DSCP value for the transiting IP packet.

   o  reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored
      during decoding.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

I also had a few minor comments on this document:

4.1.  Length Encoding

   o  If the NLRI length is smaller than 240 (0xf0 hex) octets, the
      length field can be encoded as a single octet.

   o  Otherwise, it is encoded as an extended-length 2-octet value in
      which the most significant nibble of the first octet is all ones.

This describes the first nibble in binary, and then later it is shown in hex. 
It might be more clear to write ... in which the most significant nibble has the hex value 0xf.

   In Figure 1 above, values less-than 240 are encoded using two hex
   digits (0xnn).  Values above 239 are encoded using 3 hex digits
   (0xfnnn).  The highest value that can be represented with this
   encoding is 4095.  For example the length value of 239 is encoded as
   0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet).

4.2.  NLRI Value Encoding

   Components MUST follow strict type ordering by increasing numerical
   order.  A given component type may (exactly once) or may not be
   present in the Flow Specification.  If present, it MUST precede any
   component of higher numeric type value.

I wasn't sure, but wondering whether "may (exactly once) or may not be" should be "MAY (exactly once) be"?

Sue:  (treating as a "editorial)

Does this work for you? 
Old/A given component type may (exactly once) or may not be
present in the flow Specification/

New/Each given component type may or may not be present in the 
Flow Specification.  If a type is present, it may be present only once./


5.1.  Ordering of Flow Specifications

   For all other component types, unless otherwise specified, the
   comparison is performed by comparing the component data as a binary
   string using the memcmp() function as defined by [ISO_IEC_9899].  For
   strings with equal lengths the lowest string (memcmp) has higher
   precedence.  For strings of different lengths, the common prefix is
   compared.  If the common prefix is not equal the string with the
   lowest prefix has higher precedence.  If the common prefix is equal,
   the longest string is considered to have higher precedence than the
   shorter one.

I think that the intended comparison here is clear, but I was wondering whether this text should flag endian concerns at all.  E.g. if the component data has been stored in memory and any numeric values have had endian conversion performed on them then a naive memcmp() could give a different answer.

[Sue]:  (treating as a "editorial) 
If you have a suggestion on endian statements, please let us know. 
We  provide links to from other BGP specifications  for the types. 
Appendix A was intended to provide an example of the flow rule comparison. 
Do you think this helps? 

The example encodings in section 4 were intended to provide examples
for implementers.