Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

From: netmod <netmod-bounces@ietf.org> on behalf of "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>
Date: Friday, March 9, 2018 at 9:59 AM
To: Adam Roach <adam@nostrum.com>, Andy Bierman <andy@yumaworks.com>
Cc: NetMod WG Chairs <netmod-chairs@ietf.org>, "draft-ietf-netmod-rfc6087bis@ietf.org" <draft-ietf-netmod-rfc6087bis@ietf.org>, The IESG <iesg@ietf.org>, NetMod WG <netmod@ietf.org>
Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

Hi Adam,

On 08/03/2018 23:55, Adam Roach wrote:
Thanks for your quick response! I have some additional comments inline.
<snip>

Clearly, the items that have already been published can't be changed, but it seems like there is room for guidance about whether to optimize for simple regexes, or for more rigorous ones.
I agree with your general sentiment.  In fact I had a long protracted discussion on this point on the Netmod WG alias.

Sometimes pattern statements can be both correct and also concise and readable.  This is the easy case.

But for other regular expressions (e.g. route-target in rfc8294) there is a clear choice whether to make the regex as precise as possible (minimizing false values), or to make it concise and hopefully readable/verifiable but allowing for more false values.

My personal preference is for a simpler, but less precise regex over a more precise, but hard to visually verify, regex.  E.g. I'm not a fan of using regular expressions to limit the range of numerical values.  I know that validating regular expression matches is computationally expensive, so I wonder if implementations will end up replacing these larger regular expressions with custom written verification code that is more performant.  But, as I recall, I was in the rough on this issue.

If the consensus is that they should be as accurate as is feasible then I think that it would be helpful if the guidelines state this as a goal.  This would seem to ensure consistency in the YANG models that are being standardized.

As the editor of RFC 8294, I can confirm that we did not reach consensus on whether to use easily understandable regular expressions versus regular expressions that precisely validate the input string. During the protracted Working Group last call for this document, there were strong proponents of both lines of thinking. Given that we had started with the more complex precise regular expressions, that is what was retained (e.g., for BGP route-targets).

     typedef route-target {
       type string {
         pattern
           '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0):(429496729[0-5]|'
         +     '42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
         +     '42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
         +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0))|'
         + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
         +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
         +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
         +     '655[0-2][0-9]|'
         +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|'
         + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|'
         +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|'
         +     '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0):'
         +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|'
         + '(6(:[a-fA-F0-9]{2}){6})|'
         + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
         +     '[0-9a-fA-F]{1,12})';
       }

       description
         "A Route Target is an 8-octet BGP extended community
          initially identifying a set of sites in a BGP VPN
          (RFC 4364).  However, it has since taken on a more general
          role in BGP route filtering.  A Route Target consists of two
          or three fields: a 2-octet Type field, an administrator
          field, and, optionally, an assigned number field.

          According to the data formats for types 0, 1, 2, and 6 as
          defined in RFC 4360, RFC 5668, and RFC 7432, the encoding
          pattern is defined as:

          0:2-octet-asn:4-octet-number
          1:4-octet-ipv4addr:2-octet-number
          2:4-octet-asn:2-octet-number
          6:6-octet-mac-address

          Additionally, a generic pattern is defined for future
          Route Target types:

          2-octet-other-hex-number:6-octet-hex-number

          Some valid examples are 0:100:100, 1:1.1.1.1:100,
          2:1234567890:203, and 6:26:00:08:92:78:00.";
       reference
         "RFC 4360: BGP Extended Communities Attribute.
          RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs).
          RFC 5668: 4-Octet AS Specific BGP Extended Community.
          RFC 7432: BGP MPLS-Based Ethernet VPN.";
     }

I don’t know that we want to debate this again during the IESG comments for RFC6087BIS. .

Thanks,
Acee

Thanks,
Rob

/a

_______________________________________________

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod