Subject: Proposal for a charter for BESS

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Sep 2014 17:39:55 +0100

Hi,

L3VPN, L2VPN, IDR, MPLS, NVO3, and PWE3 are all Bcc'd. Please send your
responses on the routing-discussion list.

We have been working on a draft charter for the "BGP Enabled Services" working
group (BESS) that will take over the BGP VPN work from L3VPN, L2VPN, and NVO3.

You can see the working copy of this charter at
https://datatracker.ietf.org/doc/charter-ietf-bess/

We will need to make specific decisions about which documents go where, but that
will (hopefully) not change the discussion of the charter text.

To move this forward, the IESG will consider this on 2nd October with a view to
sending it out for formal IETF review. So your review comments now would be
really helpful.

Thanks,
Adrian

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 25 Sep 2014 17:02:06 -0400

Adrian: 

Three points give me pause:

1) Auto-discovery of sites that participate in BGP-Enabled service 

I would appreciate if we got to a place where auto-discovery were carefully
scanned against the previous auto-discoveries with BGP.  Perhaps we could
wordsmith to indicate "please check what's out there first". 

2) We have three different places looking at config/management models:  yang
(config), I2rs (ephemeral), IDR, and BESS.  Data Models more managing these
BGP-based services need to be reviewed by IDR to make sure we are using
correct BGP.  The current charter text has 90% covered that issues, but with
your fine editing skills please just tighten it.  

What's not covered is the how to coordinate these models for regular config,
i2rs quick state, OAM and resiliency.   If you agree, I will suggest text.

Sue 

-----Original Message-----
From: L3VPN [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, September 25, 2014 12:40 PM
To: [email-masked]
Cc: 'Alia Atlas'
Subject: Proposal for a charter for BESS

Hi,

We have been working on a draft charter for the "BGP Enabled Services"
working group (BESS) that will take over the BGP VPN work from L3VPN, L2VPN,
and NVO3.

You can see the working copy of this charter at
<https://datatracker.ietf.org/doc/charter-ietf-bess/>
https://datatracker.ietf.org/doc/charter-ietf-bess/

We will need to make specific decisions about which documents go where, but
that will (hopefully) not change the discussion of the charter text.

To move this forward, the IESG will consider this on 2nd October with a view
to sending it out for formal IETF review. So your review comments now would
be really helpful.

Thanks,

Adrian

---

From: Giles Heron <[email-masked]>
Date: Fri, 26 Sep 2014 11:37:41 +0100

Hi Susan,

re your second point, I thought the general principle was to move YANG model developement out of NETMOD and in to the various routing WGs?  So, for example, BESS would be responsible for BGP VPN models.  Those might augment or reference BGP models developed in IDR.  That's also where I think the PALS/BESS split makes sense in that IPVPN can hopefully share a lot model-wise with EVPN.

The role of NETMOD is then that of being the stewards of the YANG language, of NETCONF that of being the stewards of NETCONF and RESTCONF, and of I2RS that of generating requirements into NETCONF/NETMOD for doing ephemeral config.

So I would expect any BESS-developed models to be equally applicable to persistent and ephemeral config.   I'd also expect models to address OAM and resiliency - again perhaps referencing OAM models developed elsewhere.

Giles
 
On 25 Sep 2014, at 22:02, Susan Hares <[email-masked]> wrote:

> I would appreciate if we got to a place where auto-discovery were carefully scanned against the previous auto-discoveries with BGP.  Perhaps we could wordsmith to indicate "please check what's out there first".
>  
> 2) We have three different places looking at config/management models:  yang (config), I2rs (ephemeral), IDR, and BESS.  Data Models more managing these BGP-based services need to be reviewed by IDR to make sure we are using correct BGP.  The current charter text has 90% covered that issues, but with your fine editing skills please just tighten it.  
>  
> What’s not covered is the how to coordinate these models for regular config, i2rs quick state, OAM and resiliency.   If you agree, I will suggest text.
>  
> Sue
> L3VPN, L2VPN, IDR, MPLS, NVO3, and PWE3 are all Bcc'd. Please send your responses on the routing-discussion list.
>  
> We have been working on a draft charter for the "BGP Enabled Services" working group (BESS) that will take over the BGP VPN work from L3VPN, L2VPN, and NVO3.
>  
> You can see the working copy of this charter at https://datatracker.ietf.org/doc/charter-ietf-bess/
>  
> We will need to make specific decisions about which documents go where, but that will (hopefully) not change the discussion of the charter text.
>  
> To move this forward, the IESG will consider this on 2nd October with a view to sending it out for formal IETF review. So your review comments now would be really helpful.
>  
> Thanks,
> Adrian
>  
> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 26 Sep 2014 11:56:18 -0400

Giles:

Please see my problem statement below about things we did not correctly work
between IDR and L2VPN on the tunnels that help make up some VPNs.  It's not
really as simple as saying BESS would be responsible for the BGP VPN modules
- because we have proposals made in both cases that impact one another.
If you then took this case, and did netmod/yang  modules - you could run
into conflicting data entries. 

What I'm looking for is stop and say.. Why are we doing 2 RFCs and 2 new
drafts on the same function?  I'm sure the BESS chairs and IDR chairs will
work out these problems with a short conversation.  However, the issue was
we got out of sync because we did not set time aside to review it together. 

Sue 

============

Let me give you the scenario I am trying to fix, and let's see if we can
solve the problem by adjusting the charter.  I really just want a place
where we talk about higher issues relating to joint work - both in the BGP
protocol and in the yang modules.  The goal is to require less additional
running code to make BESS/BGP add new features work.  

Sue 

Problem summary: Between L2VPN and IDR there are 2 RFC and 2+ Drafts all of
these attempt to set next-hop values on tunnels.   

Specifics: 

Draft L2VPN tunnel attribute
(draft-sajassi-l2vpn-evpn-inter-subnet-forwarding) proposes a BGP attribute
with the format of: 

.             tunnel type (2 octets) of VXLAN (08), tunnel type (09), and
GTP (10);

.             length (2 octets), 

.             address length(1-octet), and 

.             address (n-octets) of IPv4, IPv6, and MAC 

This draft conflicts with RFC5512, RFC6514, and
draft-vandevelde-idr-remote-next-hop-07.  I am concerned that that we could
make one tunnel configuration rather than 4 drafts doing the same thing. At
the very least, we should have a joint rationale why we are doing this. 

Details:

------------

RFC 5512 has a tunnel ID with tunnel type (2 octets), length (2 bytes), and
value where the value is a field comprised of sub-tlv type (1 octet),
sub-tlv length (1 octet), sub-tlv value (variable).  The tunnel types (2
octets) can be the following:  

.             Tunnel type 1 - L2TPv3 over IP (RFC3931], 

.             Tunnel type 2 - GRE [RFC2784),

.             Tunnel type 7 - IP in IP [RFC2003, RFC4213] 

The sub-types can be: encapsulation (1), protocol (2), and color (4).  These
TLVs depend on the tunnel type.  

RFC6614 has an PMSI tunnel attribute with:

.             flags (1 octet)

.             Tunnel type (1-RSVP-TE P2MP LSP, 2-mLDP P2MP LSP, PIM-SSM
tree, PIM-SM tree, BIDIR-PIM Tree, Ingress replication, MLDP MP2MP LSP)

RFC6614 also has a NLRI for MCAST-VPN with Route types of: 

.             Intra-AS I-PMSI A-D route;  (RD (8), IP address (4/16))

.             Inter-AS I-PMSI A-D route; (RD (8), Source AS (4) 

.             S-PMSI A-D route; (RD (8), Multicast source length (1),
Multicast source (variable), Multicast group length (1), Multicast group
(variable), Original Routers IP address 

.             Leaf A-D route:  Route Key (variable), Originating Routers IP
address

.             Source Active A-D route : ; (RD (8), Multicast source length
(1), Multicast source (variable), Multicast group length (1), Multicast
group (variable),

.             C-Multicast route: (RD (8), Source-AS (4), ; Multicast source
length (1), and Multicast source (variable), Multicast group length (1),
Multicast group (variable). 

This conflicts with draft-vandevelde-idr-remote-next-hop-07 (which is up for
WG Adoption in IDR) with a format of: 

.             tunnel type (2 octets) of 

.             tunnel type 1 - L2TPv3 over IP (RFC3931], 

.             tunnel type 2 - GRE [RFC2784),

.             tunnel type 7 - IP in IP [RFC2003, RFC4213] 

.             tunnel type 8 - VXLAN, 

.             tunnel type 9 - NVGRE, 

-----Original Message-----
From: Giles Heron [mailto:[email-masked]] 
Sent: Friday, September 26, 2014 6:38 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]
Subject: Re: Proposal for a charter for BESS

Hi Susan,

re your second point, I thought the general principle was to move YANG model
developement out of NETMOD and in to the various routing WGs?  So, for
example, BESS would be responsible for BGP VPN models.  Those might augment
or reference BGP models developed in IDR.  That's also where I think the
PALS/BESS split makes sense in that IPVPN can hopefully share a lot
model-wise with EVPN.

The role of NETMOD is then that of being the stewards of the YANG language,
of NETCONF that of being the stewards of NETCONF and RESTCONF, and of I2RS
that of generating requirements into NETCONF/NETMOD for doing ephemeral
config.

So I would expect any BESS-developed models to be equally applicable to
persistent and ephemeral config.   I'd also expect models to address OAM and
resiliency - again perhaps referencing OAM models developed elsewhere.

Giles

> I would appreciate if we got to a place where auto-discovery were
carefully scanned against the previous auto-discoveries with BGP.  Perhaps
we could wordsmith to indicate "please check what's out there first".

> 2) We have three different places looking at config/management models:
yang (config), I2rs (ephemeral), IDR, and BESS.  Data Models more managing
these BGP-based services need to be reviewed by IDR to make sure we are
using correct BGP.  The current charter text has 90% covered that issues,
but with your fine editing skills please just tighten it.  

> What's not covered is the how to coordinate these models for regular
config, i2rs quick state, OAM and resiliency.   If you agree, I will suggest
text.

> From: L3VPN [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Adrian Farrel

> To:  <mailto:[email-masked]> [email-masked]

> We will need to make specific decisions about which documents go where,
but that will (hopefully) not change the discussion of the charter text.

> To move this forward, the IESG will consider this on 2nd October with a
view to sending it out for formal IETF review. So your review comments now
would be really helpful.

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/routing-discussion>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 29 Sep 2014 09:57:24 -0400

To add to Sue's observations:

> wordsmith to indicate "please check what's out there first". 

Two obvious examples I'm working on spring immediately to mind: Work on
RT-Constrain and work on BGP Flowspec.  RT-Constrain is an obvious fit for
this item and the charter text suggests that we may move this to BESS.
Flowspec includes a VPN-related component and this casts some doubt as to
which WG may be the place the work lands.

These hybrid cases are likely to lead to lots of fun in the next few years. 

> your fine editing skills please just tighten it.  

Even at a higher level, there's some interesting things that have to be
resolved for the models, in particular the structural semantics of multiple
instances of routing infrastructure.  (AKA "virtual routers", "logical
routers", VRFs, etc.)  A portion of this discussion is currently underway as
part of reconciling the OSPF yang model against the routing model, which is
great.  

Once we hit BESS related modeling issues, the partially optional nature of
reconciling multiple instances of routing for OSPF will become a mandatory
reconciliation for BESS purposes.

This isn't to say I have a specific thing to suggest here.  What I'll note
is that as all IETF WGs work through this issue, we're likely to need a
somewhat centralized model for this.  BESS isn't necessarily the specific
group for this - and for that matter neither is I2RS.  We're all
stakeholders.

-- Jeff