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

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

Hi Sue,

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

Please see inline ...


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


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

> 
> 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
[RW] 
Regards,
Rob

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