Subject: [i2rs] Draft minutes for December 16, 2014 interim

From: Jeffrey Haas <[email-masked]>
Date: Tue, 16 Dec 2014 11:43:50 -0500

Two specific callouts:
Don, please clarify which documents could use further hamornization?

With regard to transport and subscription decoupling, this was a topic that had received some discussion at the NYC netmod interim.  It was agreed that this was potentially useful work and while this was a netmod interim, given the crossover of attendees with netmod vs. netconf it was suggested that I2RS should make a proposal as to how such a decoupled mechanism should be represented in netconf.  To this point, Alex Clemm, it may be worthwhile expanding your proposal to contain that feature.

Please review the minutes and please forgive some unusual typos.  I realized that Apple auto-correct was running for a while and I may have failed to catch some of the incorrect substitutions.

-- Jeff

---

From: "Fedyk, Don" <[email-masked]>
Date: Tue, 16 Dec 2014 17:18:05 +0000

Hi Jeff

My point was the Yang Model for L3 (as presented) seemed to outline L3, Service and Optical and missed L2 totally.  (Not saying this is one document but one architecture as presented).  Then the L2 Presentation had some L2 but missed several L2 capabilities. (VPLS, EVPN, VXLAN, PBB etc.)

If you look at this more generically each layer (l3,l2,l1) has:
Data path, Tunneling/Multiplexor/Virtual network, Topology, Topology data base, TE extensions, Control Plane
Each layer can and may use IS-IS or OSPF (and even BGP) for some address distribution VPN information, connection coordination, TE information, within the context of an Instance/VPN.
Each layer can and may offer a service, p2p, p2mp, mp2mp,(some type of persistent connection or set of connections that may have their own resiliency mechanisms) at the layer or up to a higher layer.

Layers can be skipped and upper layers may be unaware of lower layers.
HTH Cheers,
Don

From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, December 16, 2014 11:44 AM
To: [email-masked]
Subject: [i2rs] Draft minutes for December 16, 2014 interim

Two specific callouts:

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 16 Dec 2014 13:46:34 -0500

My comment on control plane vs data plane is very much in line with this
comment.  And Don has begun some of the discussion I was hoping to talk
a bit more about in Thursday's TEAS interim. (At least the TE aspects,
as well as the possible formal representation of control plane
separately from data plane.)

Lou

On 12/16/2014 12:18 PM, Fedyk, Don wrote:
>
> Hi Jeff
>
>  
>
> My point was the Yang Model for L3 (as presented) seemed to outline
> L3, Service and Optical and missed L2 totally.  (Not saying this is
> one document but one architecture as presented).  Then the L2
> Presentation had some L2 but missed several L2 capabilities. (VPLS,
> EVPN, VXLAN, PBB etc.)
>
>  
>
> Each layer can and may use IS-IS or OSPF (and even BGP) for some
> address distribution VPN information, connection coordination, TE
> information, within the context of an Instance/VPN.
>
> Each layer can and may offer a service, p2p, p2mp, mp2mp,(some type of
> persistent connection or set of connections that may have their own
> resiliency mechanisms) at the layer or up to a higher layer.
>
>  
>
> *From:*i2rs [mailto:[email-masked]] *On Behalf Of *Jeffrey Haas
> *Sent:* Tuesday, December 16, 2014 11:44 AM
> *To:* [email-masked]
> *Subject:* [i2rs] Draft minutes for December 16, 2014 interim
>
>  
>
> Two specific callouts:
> With regard to transport and subscription decoupling, this was a topic
> that had received some discussion at the NYC netmod interim.  It was
> agreed that this was potentially useful work and while this was a
> netmod interim, given the crossover of attendees with netmod vs.
> netconf it was suggested that I2RS should make a proposal as to how
> such a decoupled mechanism should be represented in netconf.  To this
> point, Alex Clemm, it may be worthwhile expanding your proposal to
> contain that feature.
>
> Please review the minutes and please forgive some unusual typos.  I
> realized that Apple auto-correct was running for a while and I may
> have failed to catch some of the incorrect substitutions.
>
> -- Jeff
>
> [email-masked] <mailto:[email-masked]>
> [email-masked]