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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Susan,

Thanks for the quick response and explanation.

Please see inline ...


> -----Original Message-----
> From: Susan Hares <[e-mail]>
> Sent: 24 April 2020 13:01
> To: Rob Wilton (rwilton) <[e-mail]>; 'The IESG' <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> 'Jie Dong' <[e-mail]>; [e-mail]
> Subject: RE: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23:
> (with DISCUSS and COMMENT)
> 
> 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.
[RW] 

Yes. I appreciate that historical precedent holds a lot of weight.  Prior to my discuss I had tried to quickly find examples of this, but was looking in the wrong documents. ;-)


> 
> 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.
[RW] 
Yes, it is the partial deployments that is concerning me.

But I don't understand why that means the sender is a "SHOULD be 0" not a "MUST be 0"?

In the interop case either sender or receiver could be upgraded, so why the asymmetry?

My understanding is that these fields should be set to 0 unless there is a new specification that gives them meaning which affects both sender and receiver.


> 
> This is a RFC5575bis document based past history of these
> statements in routing code.
[RW]
I agree, and I have no intention of unduly holding up a document, but just want to check that this is being expressed in the most correct and understandable way.


> 
> 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.
[RW] 
That sounds fine, thank you.

Regards,
Rob


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