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

[Susan Hares <[e-mail]>]

Rob: 

Pulling your remaining question to the front:

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

This text is inherited from RFC5575. 

Originally (which is not in any document) 
this was set because prototype implementations of 
RFC5575 had set it to a 1 during a rushed deployment. 
  
Whether these implementation still exist in the 
smaller boxes boxes from major vendors - I do not know. 

One of the habits of IDR is not to break existing BGP. 

I was torn whether RFC5575bis state "MUST" and go on. 
I left it at "SHOULD" because it is a BIS.  

AFAIK the place this will change this is on the protocol testers. 
Older boxes will break. 

So that's the reasoning, and the author team was torn between 
fixing the "SHOULD" to a "MUST" and breaking things. 

Robert Razuk or other people on the IDR list might have additional comments on this one. 

Sue Hares 


-----Original Message-----
From: Rob Wilton (rwilton) [mailto:[e-mail]] 
Sent: Friday, April 24, 2020 9:44 AM
To: Susan Hares; 'The IESG'; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; 'Jie Dong'
Subject: RE: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)

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