Subject: YANG [Was: Proposal for a charter for BESS]

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 26 Sep 2014 13:01:07 +0100

Yeah,

I think any tension that exists is:
- between BESS and IDR for BGP YANG models
- between BESS and I2RS for VPN YANG models

As/if LIME comes on stream we have a new overlap to manage:
- between BESS and LIME for YANG models to config and report VPN OAM
However, in this case, I think that LIME handles generic YANG models, and
technology-specific models will belong in BESS.

I think that NETMOD's role becomes:
- stabilising/extending YANG as needed
- making YANG best practices / usage guidelines
- acting as a resource for review of new YANG modules

Yes, Sue, I would welcome proposed text.

Adrian

> -----Original Message-----
> From: Giles Heron [mailto:[email-masked]]
> Sent: 26 September 2014 11:38
> 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
> 
> On 25 Sep 2014, at 22:02, Susan Hares <[email-masked]> wrote:
> 
> > 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,
> >
> > 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: Giles Heron <[email-masked]>
Date: Fri, 26 Sep 2014 13:36:29 +0100

> - between BESS and IDR for BGP YANG models

I'd think IDR would do these and BESS would augment for VPNs?  Or in an ideal world at least.

> - between BESS and I2RS for VPN YANG models

I can't see why I2RS can't just use the BESS models against the ephemeral datastore.

> technology-specific models will belong in BESS.

ok.

> - acting as a resource for review of new YANG modules

agreed.

Giles

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 26 Sep 2014 13:05:15 -0400

Adrian: 

I sent in the additions to the charter to Martin, but I repeat them here. 

-The BESS working group may develop extensions to BGP, but all such work
must be reviewed by the IDR working group and those modifications to BGP
(protocol and yang) must satisfy all IDR publication requirements before
being  forwarded to the IESG. 

Sue  
-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, September 26, 2014 8:01 AM
To: 'Giles Heron'; 'Susan Hares'
Cc: [email-masked]
Subject: YANG [Was: Proposal for a charter for BESS]

Yeah,

Adrian

> 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.
> 
> scanned against the previous auto-discoveries with BGP.  Perhaps we 
> could wordsmith to indicate "please check what's out there first".
> >
> (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
> working group (BESS) that will take over the BGP VPN work from L3VPN, 
> L2VPN, and NVO3.
> >
to
> sending it out for formal IETF review. So your review comments now 
> would be really helpful.
> >
> > Thanks,
> > Adrian
> >

---

From: Eric Rosen <[email-masked]>
Date: Fri, 26 Sep 2014 18:50:31 -0400

> those modifications to BGP (protocol and yang) must satisfy all IDR
> publication requirements before being forwarded to the IESG.

I would strongly disagree with this.  Right now, other WGs can develop
extensions to BGP, and can get them published without satisfying all IDR
publication requirements.  There was a rather lengthy discussion some years
ago about whether all the Routing WGs needed to have the same publication
requirements as IDR, and it was decided that they do not.  If we want to
revisit that issue again (and I don't know why we would), let's not hide it
behind the guise of "reorganizing the area".

---

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

Eric:

I'm not arguing for the same publishing requirements (2 implementations),
even though I think that is a good idea.  I am arguing for review by IDR of
all drafts that related to BGP protocol or BGP yang models. 

Sue

---

From: Loa Andersson <[email-masked]>
Date: Sat, 27 Sep 2014 13:36:12 +0200

Eric,

I'm not sure but I think the "publication requirements" were per
protocol rather than per working group.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Eric Rosen <[email-masked]>
Date: Mon, 29 Sep 2014 09:25:50 -0400

Sue> I'm not arguing for the same publishing requirements (2 implementations)
Sue> ... I am arguing for review by IDR of all drafts that related to BGP
Sue> protocol

I agree that drafts related to BGP should be reviewed by IDR.

Stewart> Work on the BGP protocol itself is outside the scope of the BESS
Stewart> WG.

This is the kind of statement that caused us a lot of difficulty when this
issue was last discussed.  If an i-d in another WG defines a new extended
community, and specifies some semantics for it, is that considered "work on
the BGP protocol itself" or not?  What about if a new SAFI is defined?  A
new attribute?

I really think it's best not to say anything more than "BGP work will be
reviewed by IDR".

Adrian> I have updated the paragraph to read:

     The BESS working group may develop extensions to BGP and extensions to
     YANG models for BGP, but all such work must be reviewed by the IDR
     working group and any such modifications to BGP must satisfy the IDR
     working group as being ready for publication before being forwarded to
     the IESG.

My suggestion would be to change this to:

     The BESS working group may develop extensions to BGP and extensions to
     YANG models for BGP.  All such work must be reviewed by the IDR WG, but
     the decision to request publication of such work remains with the BESS
     WG.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 29 Sep 2014 16:22:47 +0100

Thanks for the concrete suggestion, Eric.

I could be OK with this revised paragraph because it definitely gives IDR the
chance to shout "no, no, no" while allowing BESS to request publication. This
leaves the AD drawing the line which is fine with me (and will be even finer
after March next year).

Anyone want to object?

A

> Sent: 29 September 2014 14:26
> To: Susan Hares
> Cc: [email-masked]; 'Giles Heron'; [email-masked]; Stewart
> Bryant

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 29 Sep 2014 11:48:37 -0400

Eric:

Either text should work - because I trust the BESS chairs, ADs, and IESG to
the right thing if the process schedules in the reviews.  The important part
to me is the cross review at beginning (per Alia's process), WG LC, and
before IESG approval.  Your excellent comments on drafts have often caused
me to reconsider my own opinions. 

Just so I can be a listening IDR co-chair, if there is some incident that
causes you to be concern about the IDR review drop me a note. 

Cheerily 

Sue 

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Monday, September 29, 2014 9:26 AM
To: Susan Hares
Cc: [email-masked]; 'Giles Heron'; [email-masked]; Stewart
Bryant

Sue> I'm not arguing for the same publishing requirements (2 
Sue> implementations) ... I am arguing for review by IDR of all drafts 
Sue> that related to BGP protocol

Stewart> Work on the BGP protocol itself is outside the scope of the 
Stewart> BESS WG.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 29 Sep 2014 11:49:40 -0400

Adrian and Eric:

No objections.  

Sue 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Monday, September 29, 2014 11:23 AM
To: [email-masked]; 'Susan Hares'
Cc: 'Giles Heron'; [email-masked]; 'Stewart Bryant'
Subject: RE: YANG [Was: Proposal for a charter for BESS]

I could be OK with this revised paragraph because it definitely gives IDR
the chance to shout "no, no, no" while allowing BESS to request publication.
This leaves the AD drawing the line which is fine with me (and will be even
finer after March next year).

Anyone want to object?

A

> Cc: [email-masked]; 'Giles Heron'; [email-masked]; 
> Stewart Bryant
> This is the kind of statement that caused us a lot of difficulty when 
> this issue was last discussed.  If an i-d in another WG defines a new 
> extended community, and specifies some semantics for it, is that 
> considered "work on the BGP protocol itself" or not?  What about if a 
> new SAFI is defined?  A new attribute?
> 
> I really think it's best not to say anything more than "BGP work will 
> be reviewed by IDR".
>