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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Fri, 24 Apr 2020 02:49:29 -0700

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"?

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.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 24 Apr 2020 08:01:11 -0400

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:[email-masked]] 
Sent: Friday, April 24, 2020 5:49 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; Jie Dong; [email-masked]; [email-masked]
Subject: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)

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

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:

      0                   1                   2                   3

Hi,

4.1.  Length Encoding

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.

4.2.  NLRI Value Encoding

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

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.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 24 Apr 2020 13:43:36 +0000

Hi Susan,

Thanks for the quick response and explanation.

Please see inline ...

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

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

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

> Contribute to the resolutions.
[RW] 
That sounds fine, thank you.

Regards,
Rob

> Cc: [email-masked]; [email-masked]; [email-masked];
> Jie Dong; [email-masked]; [email-masked]
> 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:
> 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.
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 24 Apr 2020 11:04:18 -0400

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:[email-masked]] 
Sent: Friday, April 24, 2020 9:44 AM
To: Susan Hares; 'The IESG'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; 'Jie Dong'
Subject: RE: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)

Hi Susan,

Please see inline ...

> Cc: [email-masked]; [email-masked]; 
> [email-masked]; 'Jie Dong' <[email-masked]>; [email-masked]
[RW] 

> The "must be ignored" clause allows the transmitter to change to 
> something besides zero.
[RW]

> 
> This is a RFC5575bis document based past history of these statements 
> in routing code.
[RW]

> Our authoring team loads these comments into github, and you are 
> welcome to Contribute to the resolutions.
[RW]

Regards,
Rob

> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Jie Dong; [email-masked]; [email-masked]
> 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
> 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).
> 
> 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:
> 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./
> 
> 
> 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.
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 24 Apr 2020 16:24:24 +0000

Hi Sue,

We discussed this in the telechat today.  I think that Alvaro intends to comment.

Please see inline ...

> Sent: 24 April 2020 16:04
> To: Rob Wilton (rwilton) <[email-masked]>; 'The IESG' <[email-masked]>;
> [email-masked]
> 'Jie Dong' <[email-masked]>
[RW] 
Yes, and I fully support that pragmatic aim.

> AFAIK the place this will change this is on the protocol testers.
[RW] 
But that might be a good thing, right?  I.e. if the protocol tester flags up implementations that are still setting these values to 1 rather than 0 then they can be fixed?  Hence reducing the risk of interop problems if these bits are ever used for future extensions.

[RW] 
Regards,
Rob

> 'Jie Dong'
> 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. ;-)
> 
> 
> >
> 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.
> 
> 
> >
> 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.
> 
> 
> >

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 24 Apr 2020 10:00:27 -0700

Hi!

As Rob mentioned, we talked about his DISCUSS during today’s IESG Telechat.

We’re all in agreement that the last thing we want to do is to break any
existing implementations, specially because this document is a bis.

I looked at rfc5575, and I didn’t find the same text there — I found no
specification of the setting of the bits, specially the reserved ones.

[I also did a quick and unscientific search of other routing documents and
found a mix of SHOULD/MUST and MUST/MUST constructs…]

Note that there are two distinct cases (in rfc5575bis):

(1) A bit is defined as 0, but the definition is: "0 -  SHOULD be set to
0…” (§4.2.1.1).  If it’s 0, then I see no reason for that not to be a
MUST.  In fact, if always set to 0 we’re probably over specifying the
field.   There are 3 occurrences of this in the document.

(2) Unused (§7.3) or reserved (§7.5) defined as "SHOULD be set to 0...MUST
be ignored”.  Again, if unused/reserved, I see no reason not to change to
MUST.  I think Rob makes a good point about extensibility.

Before any changes, and in the spirit of not breaking anything, we should
check whether anyone has an implementation what would be impacted.  I
assume/hope that the prototype implementations have already been fixed.

Jie:  As Shepherd, can you please do a quick poll of the people who
reported implementations to confirm that these changes won’t have an
impact?

Thanks!

Alvaro.

[RW]

---

From: Susan Hares <[email-masked]>
Date: Fri, 24 Apr 2020 13:33:50 -0400

AlvaroThe author team will change to MUST per your comments.I know there is nothing in the text and I know there were problems.  Given the rush on the first version, I know things were down-played so the urgent problem could be fixed. My warning that the bit settings may be deep in code and current people may have trouble finding it.That said, it is the right thing to do.Did the iesg want by in same document?SueSent via the Samsung Galaxy S7 edge, an AT&T 4G LTE smartphone
-------- Original message --------From: Alvaro Retana <[email-masked]> Date: 4/24/20  1:00 PM  (GMT-05:00) To: Susan Hares <[email-masked]>, "Rob Wilton (rwilton)" <[email-masked]>, Jie Dong <[email-masked]> Cc: [email-masked], [email-masked], The IESG <[email-masked]>, [email-masked] Subject: Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) Hi!As Rob mentioned, we talked about his DISCUSS during today’s IESG Telechat.We’re all in agreement that the last thing we want to do is to break any existing implementations, specially because this document is a bis.I looked at rfc5575, and I didn’t find the same text there — I found no specification of the setting of the bits, specially the reserved ones.[I also did a quick and unscientific search of other routing documents and found a mix of SHOULD/MUST and MUST/MUST constructs…]Note that there are two distinct cases (in rfc5575bis):(1) A bit is defined as 0, but the definition is: "0 -  SHOULD be set to 0…” (§4.2.1.1).  If it’s 0, then I see no reason for that not to be a MUST.  In fact, if always set to 0 we’re probably over specifying the field.   There are 3 occurrences of this in the document.(2) Unused (§7.3) or reserved (§7.5) defined as "SHOULD be set to 0...MUST be ignored”.  Again, if unused/reserved, I see no reason not to change to MUST.  I think Rob makes a good point about extensibility.Before any changes, and in the spirit of not breaking anything, we should check whether anyone has an implementation what would be impacted.  I assume/hope that the prototype implementations have already been fixed.Jie:  As Shepherd, can you please do a quick poll of the people who reported implementations to confirm that these changes won’t have an impact?   Thanks!Alvaro. On April 24, 2020 at 12:24:28 PM, Rob Wilton (rwilton) ([email-masked]) wrote: > 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. [RW] Yes, and I fully support that pragmatic aim.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 24 Apr 2020 10:43:23 -0700

On April 24, 2020 at 1:34:02 PM, Susan Hares wrote:

Sue:

Hi!

> The author team will change to MUST per your comments.
>
> I know there is nothing in the text and I know there were problems. Given the
> rush on the first version, I know things were down-played so the urgent
> problem could be fixed.
>
> My warning that the bit settings may be deep in code and current people may
> have trouble finding it.
>
> That said, it is the right thing to do.

Thanks!   I still want to give Jie a chance to poll the
implementations just in case -- this should not take more than a few
days.

> Did the iesg want by in same document?

Sorry...I couldn't parse that.

Thanks!

Alvaro.