Subject: Extended community types, e.g. route-targets (was Re: I-D Action: draft-ietf-rtgwg-routing-types-08.txt)

From: Jeffrey Haas <[email-masked]>
Date: Mon, 10 Jul 2017 16:32:51 -0400

Acee (and other authors),

On Thu, Jun 29, 2017 at 02:42:01PM -0700, [email-masked] wrote:
> 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-08.txt
> 	Pages           : 40
> 	Date            : 2017-06-29
> 
> 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.

Thanks for the updates for the various route-target,origin and site of
origin extended community types.  I'll try to take some some to read the
regex in detail.

My lingering issue with the route-target types is that IETF work on VPNs
will continue to add extended communities to have route-target semantics
outside of the types originally defined in RFC 4360.  The current example of
this is the ES-Import community.

I believe we either need to:
1. Provide a generic format for types other than 0,1,2. Or,
2. Document how the relevant type is intended to be maintained.

For example, the module that route-targets is part of is not IANA
maintained.

If this issue is still unclear, let's plan on spending a small amount of
hallway time discussing this in Prague.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 10 Jul 2017 21:44:33 +0000

Hi Jeff, 

>this is the ES-Import community.

I think this is a type that would be shared across L2VPN and BGP modules.
We have this format for route-origin, we can add it for route-target
preceded by “6:”. 
>2. Document how the relevant type is intended to be maintained.

There is a trade-off here in providing strong typing and flexibility. I
don’t see how we can anticipate the textual conventions for all future
route target types in advance. If you want flexibility, we could just make
it a string ;^) 

>hallway time discussing this in Prague.

Sounds good.

Thanks,
Acee 

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

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 10 Jul 2017 16:12:12 -0700

+1 on f2f meeting in Prague (if needed)
I’d really like the draft to progress ASAP, so if there are any unaddressed issues, please bring them up.
 
Cheers,
Jeff

On 7/10/17, 14:44, "rtgwg on behalf of Acee Lindem (acee)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Jeff, 

    

    
    Sounds good.
    
    Thanks,
    Acee