Subject: I-D Action: draft-ietf-rtgwg-routing-types-06.txt

From: [email-masked]
Date: Tue, 13 Jun 2017 08:27:14 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Area Working Group of the IETF.

        Title           : Routing Area Common YANG Data Types
        Authors         : Xufeng Liu
                          Yingzhen Qu
                          Acee Lindem
                          Christian Hopps
                          Lou Berger
	Filename        : draft-ietf-rtgwg-routing-types-06.txt
	Pages           : 33
	Date            : 2017-06-13

Abstract:
   This document defines a collection of common data types using the
   YANG data modeling language.  These derived common types are designed
   to be imported by other modules defined in the routing area.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-routing-types/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-06
https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-routing-types-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-routing-types-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Jun 2017 16:51:15 +0000

This version addresses a couple indicts -
https://tools.ietf.org/tools/idnits/
Thanks,
Acee 

On 6/13/17, 11:27 AM, "rtgwg on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>rtgwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 20 Jun 2017 15:26:16 -0400

I had a chance to followup on my email of April 2 regarding the route-target
type.  I am including a paste of it from the draft below for reference.

The type covers core RFC 4360 route-target types and this is needed.  In
particular, it does a nice job in covering the common expressions of the
typed route-targets in that RFC.

There are other extended communities that have over time picked up semantics
of route targets.  The ES-Import route target type is an example of this,
and would not be covered by the type described in the draft.

It's my recommendation that while accommodating the well known types is
laudible, some accommodation should be made for future types.

A final note is that RFC 5701 defines an IPv6 specific route target type.  I
don't believe this is currently implemented, but will likely be a cause to
update this module when it is.  I believe is structurally problematic for
the vpn-route-targets grouping, which only includes the route-target type as
a leaf.

:      typedef route-target {
:        type string {
:          pattern
:            '(0:(6553[0-5]|655[0-2]\d|65[0-4]\d{2}|6[0-4]\d{3}|'
:          + '[0-5]?\d{0,3}\d):(429496729[0-5]|42949672[0-8]\d|'
:          + '4294967[01]\d{2}|429496[0-6]\d{3}|42949[0-5]\d{4}|'
:          + '4294[0-8]\d{5}|429[0-3]\d{6}|42[0-8]\d{7}|4[01]\d{8}|'
:          + '[0-3]?\d{0,8}\d))|'
:          + '(1:(((\d|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])\.){3}(\d|[1-9]\d|'
:          + '1\d{2}|2[0-4]\d|25[0-5])):(6553[0-5]|655[0-2]\d|'
:          + '65[0-4]\d{2}|6[0-4]\d{3}|[0-5]?\d{0,3}\d))|'
:          + '(2:(429496729[0-5]|42949672[0-8]\d|4294967[01]\d{2}|'
:          + '429496[0-6]\d{3}|42949[0-5]\d{4}|4294[0-8]\d{5}|'
:          + '429[0-3]\d{6}|42[0-8]\d{7}|4[01]\d{8}|[0-3]?\d{0,8}\d):'
:          + '(6553[0-5]|655[0-2]\d|65[0-4]\d{2}|6[0-4]\d{3}|'
:          + '[0-5]?\d{0,3}\d))';
:        }
:        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 three fields:
:           a 2-octet type field, an administrator field,
:           and an assigned number field.
:           According to the data formats for type 0, 1, and 2 defined in
:           RFC4360 and RFC5668, 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.
: 
:           Some valid examples are: 0:100:100, 1:1.1.1.1:100, and
:           2:1234567890:203.";
:        reference
:          "RFC4360: BGP Extended Communities Attribute.
:           RFC5668: 4-Octet AS Specific BGP Extended Community.";
:      }

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 20 Jun 2017 21:25:51 +0200

Jeff,

Let's note that I had similar concerns on RT definition and more expressed
to the list in Nov 2016 however they were not considered :(.

FWD of my msg follows:

---------- Forwarded message ----------
From: Robert Raszuk <[email-masked]>
Date: Sat, Nov 19, 2016 at 12:34 PM
Subject: Re: Draft-rtgyangdt-rtgwg-routing-types
To: "Acee Lindem (acee)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

Hi Acee,

SOO has similar format to RT however RT is defined only partially. There is
existing extension to RFC4360 in the form of RFC5668 which defines new
structure of both RT and SOO (Route Origin).

Also I think there important this draft needs to define type for VRF as VRF
as such is used across a lot of different applications way beyond original
L3VPN use intention.

And I think there is many more common elements ... just think of recent geo
coordinates shred by 4 WGs (if not more ...).

Thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 20 Jun 2017 15:43:57 -0400

Robert,

> to the list in Nov 2016 however they were not considered :(.

I'm in my typical far behind on list mode, so I may have missed this. :-)

I agree the other structured formats are worth considering.

A challenge the authors of the draft have is canonical formatting for new
structured formats while at the same time providing access to the opaquely
until they have been thus defined.

I would urge the chairs to request attention from IDR and BESS as part of
the WGLC on this document.  Sue Hares responded earlier in the thread, so it
at least has her attention.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 21 Jun 2017 20:37:16 +0000

Hi Jeff, Robert, 

We weren’t sure that SOO would be used beyond the BGP model. I can add
typedef site-of-origin with format <4-octet-asn:2-octet-number>.

As far as RFC 5701 is concerned, we could add types ipv6-route-target and
ipv6-site-of-origin with format <ipv6-address:2-octet-number>.

Note that the intent is to progress this quickly so that usage doesn’t
block other models. It is not to get every present and future common
routing type that might be useful prior to progression.

Thanks,
Acee

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Jun 2017 23:06:15 +0200

Hi Acee,

Progressing it quickly and incomplete will result in each independent
routing model coming with their own likely creating pretty massive
conflicts and confusion.

So IMHO we should really make sure all necessary and common between
different protocols elements are defined here even if as result it would
get delayed few more weeks.

Cheers,
R,

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 21 Jun 2017 21:15:07 +0000

Hi Robert,

Feel free to suggest validated common YANG typedefs for consideration by the Routing Design Team…. I’m not worried about adding needed types for a few more weeks. It is the few more quarters that I’m worried about. This is also consistent with the direction we are receiving from the ADs.
Thanks,
Acee

From: <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 21, 2017 at 5:06 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Haas <[email-masked]<mailto:[email-masked]>>, Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: I-D Action: draft-ietf-rtgwg-routing-types-06.txt

Hi Acee,

Progressing it quickly and incomplete will result in each independent routing model coming with their own likely creating pretty massive conflicts and confusion.

So IMHO we should really make sure all necessary and common between different protocols elements are defined here even if as result it would get delayed few more weeks.

Cheers,
R,

On Wed, Jun 21, 2017 at 10:37 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jeff, Robert,

Thanks,
Acee

On 6/20/17, 3:43 PM, "rtgwg on behalf of Jeffrey Haas"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

>> From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
>> To: "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>>
>> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>>
>> Hi Acee,
>>
>[email-masked]<mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Jun 2017 23:18:13 +0200

In addition to already discussed typedefs how about unified GPS coordinates
which is common across number of working groups for starter ?

Have Routing Design Team considered it ?

Best,
RR.

On Wed, Jun 21, 2017 at 11:15 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Robert,
>
> Feel free to suggest validated common YANG typedefs for consideration by
> the Routing Design Team…. I’m not worried about adding needed types for a
> few more weeks. It is the few more quarters that I’m worried about. This is
> also consistent with the direction we are receiving from the ADs.
> Thanks,
> Acee
>
> From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
> To: Acee Lindem <[email-masked]>
> Cc: Jeff Haas <[email-masked]>, Routing WG <[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 21 Jun 2017 21:32:40 +0000

I’m a co-author on some of these geo-location drafts but they are not yet WG documents. However, we did get a lot of people involved in the definitions and feel they are stable. I would not be opposed to adding them at the risk they could change after publication.

Thanks,
Acee

Date: Wednesday, June 21, 2017 at 5:18 PM

In addition to already discussed typedefs how about unified GPS coordinates which is common across number of working groups for starter ?

Best,
RR.

On Wed, Jun 21, 2017 at 11:15 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Hi Acee,

Cheers,
R,

Thanks,
Acee

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 Jun 2017 00:01:50 +0200

Also isn't MD5 / TCP-AO or security certificates common across multiple
routing components ?

You have IPX address family and you do not have RIP one which was way more
common over PE-CE then IPX :) ?

I see bunch of labels but quite useful context label as defined in RFC5331
is not really there.

And frankly I think we could just go on and on providing missing examples
from various common to routing areas.

Thanks,
R.

On Wed, Jun 21, 2017 at 11:32 PM, Acee Lindem (acee) <[email-masked]> wrote:

> I’m a co-author on some of these geo-location drafts but they are not yet
> WG documents. However, we did get a lot of people involved in the
> definitions and feel they are stable. I would not be opposed to adding them
> at the risk they could change after publication.
>
> Thanks,
> Acee
>
> In addition to already discussed typedefs how about unified GPS
> coordinates which is common across number of working groups for starter ?
>
>>> >the WGLC on this document.  Sue Hares responded earlier in the thread,
>>> so
>>> >it
>>> >> Also I think there important this draft needs to define type for VRF
>>> as
>>> >>VRF
>>> >> And I think there is many more common elements ... just think of
>>> recent
>>> >>geo

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 21 Jun 2017 23:42:39 +0000

Date: Wednesday, June 21, 2017 at 6:01 PM

Also isn't MD5 / TCP-AO or security certificates common across multiple routing components ?

Videre RFC 8177…

You have IPX address family and you do not have RIP one which was way more common over PE-CE then IPX :) ?

RIP is not an address family, RIPv2 advertises AFs IPv4 and IPv6 (at least that is all I’ve ever implemented)….

I see bunch of labels but quite useful context label as defined in RFC5331 is not really there.

I’m missing this – these labels don’t appear to me to be a separate type but rather a way of classifying labels. based on context. Perhaps, you can provide what you are looking for here.

And frankly I think we could just go on and on providing missing examples from various common to routing areas.

And frankly it would be more useful to provide valid YANG types than to rant about the glass not being filled to the brim ;^)

Thanks,
Acee

Thanks,
R.

On Wed, Jun 21, 2017 at 11:32 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
I’m a co-author on some of these geo-location drafts but they are not yet WG documents. However, we did get a lot of people involved in the definitions and feel they are stable. I would not be opposed to adding them at the risk they could change after publication.

Thanks,
Acee

Best,
RR.

Hi Acee,

Cheers,
R,

Thanks,
Acee

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 Jun 2017 21:12:36 -0400

Acee,

Just so I have your intent right:

> Feel free to suggest validated common YANG typedefs for consideration by the Routing Design Team…. I’m not worried about adding needed types for a few more weeks. It is the few more quarters that I…

Are you saying that for the issues that have been raised about the
route-target type (existing) that no action will happen without getting
supplied a diff?

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 Jun 2017 10:26:30 +0200

Acee,

> Videre RFC 8177…

​I was under assumption that this work aims at providing a comprehensive
​reference to common (used across protocols) elements either by defining
them directly or providing references if they were already defined
elsewhere.

Apparently the latter part is missing from this document.

> that is all I’ve ever implemented)….

​Oh please ... It seemed obvious especially in this context. It is like
mocking from someone who said "BGP" in the context of multi-protocol
extensions rather then spelling BGPv4 each time.

Thx,
R.​

​​

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 22 Jun 2017 13:10:51 +0000

Hi Robert,

Date: Thursday, June 22, 2017 at 4:26 AM

Acee,

​I was under assumption that this work aims at providing a comprehensive ​reference to common (used across protocols) elements either by defining them directly or providing references if they were already defined elsewhere.

​Oh please ... It seemed obvious especially in this context. It is like mocking from someone who said "BGP" in the context of multi-protocol extensions rather then spelling BGPv4 each time.

Sorry – I thought it was clear that these definitions in iana-routing-types.yang corresponding directly to the IANA registries for Address Families and Subsequent Address Families. IPX is an IANA registered AF. See Normative references in the draft:

   [IANA-ADDRESS-FAMILY-REGISTRY]
              "IANA Address Family Registry",
              <https://www.iana.org/assignments/address-family-numbers/
              address-family-numbers.xhtml#address-family-numbers-2>.

   [IANA-SAFI-REGISTRY]
              "IANA Subsequent Address Family Identities (SAFI)
              Parameters Registry", <https://www.iana.org/assignments/
              safi-namespace/safi-namespace.xhtml#safi-namespace-2>.

Thanks,
Acee

Thx,
R.​

​​

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 22 Jun 2017 13:14:05 +0000

Hi Jeff, 

On 6/21/17, 9:12 PM, "Jeffrey Haas" <[email-masked]> wrote:

>> Feel free to suggest validated common YANG typedefs for consideration
>>by the Routing Design Team…. I’m not worried about adding needed types
>>for a few more weeks. It is the few more quarters that I’m worried
>>about. This is also consistent with the direction we are receiving from
>>the ADs.
>

Yes - I’ll add the site-of-origin, ipv6-site-of-origin, and
ipv6-route-target types. I’ll also look at the geo-location as suggested
by Robert and come back on the outcome.

Thanks,
Acee