Re: [netmod] draft netmod 94 minutes posted

[Kent Watsen]

All,

I have compiled Martin and Robert’s updates into the attached file, and below 
is the diff.  As far as I can tell, these updates are all well and good.   
Thank you Martin and Robert.

Given that it’s a holiday in the States, please send any final corrections by 
Monday, Nov 30th.

Kent


# diff minutes-94-netmod-new.txt minutes-94-netmod.txt
190,191c190,191
< [TC] Why did you chose to use intended/applied approach rather than using 
datastores?
< [RS] 1. No such thing as an applied datastore today.  This solution allows us 
to use YANG today. 2. Our solution allows for a single path that is not 
dependent on the datastore.
---
> [TC] Why did you chose to use intended/applied approach?
> [RS] This allows us to use YANG today.
194c194
< [AS] There is a section in our draft that addresses some of these questions.
---
> [AS] There is a section i a draft that addresses this.
203,204c203,204
< [RS] No changes to existing YANG models - that does not seem to be practical. 
There are vendor extensions anyway.
< [RW] if models are standardised in IETF, they should work in all cases.
---
> [RW]  no changes to existing YANG models - that does not seem to be 
> practical. There are vendor extensions anyway.
> [RW] Wilton  if models are standardised in IETF, they should work in all 
> cases.
206,208c206,207
< [RS] Would be nice to poll for who has read the solutions drafts?
< [KW] [Show of hands] About half the room have read the three drafts.
< [KW] Who would favor solution 1. Humm. 2. Humm (most). 3. Humm
---
> [RW] would be nice to poil for who has read the solutions drafts?
> [KW] who would favor solution 1. Humm. 2. Humm (most). 3. Humm
210,212c209,211
< [RS] Didn't we do that already? We seem not to going anywhere forward with 
this discussion. We did clarify wording, but that is mostly it. It is nothing 
for operator to help with configuring a network. Is it a perfection problem 
here? Can we produce something practically useful?
< [CM] There are large installations based on existing YANG and NETCONF 
specifications.
< [RS] I take that into account. I have none in my network though that use 
existing model. I am not saying that we should throw away the existing solution 
in favor of the future solution.
---
> [Rw] Didn't we do that already? We seem not to going anywhere forward with 
> this discussion. We did clarify wording, but that is mostly it. It is noting 
> for operator to help with configuring a network. Is it a perfection problem 
> here? Can we produce something practically useful?
> [CM] There are large installations based on existing YANG specifications.
> [RW] I take that into account. I have none in my network though that use 
> existing model. I am not saying that we should throw away the existing 
> solution in favor of the future solution.
214c213
< [CH] We are not forcing to implement some particular data store technology. 
This is more of a way of thinking of it.
---
> [CH] We are not forcing to implement some particular data store technology. 
> This is more of a way of thinking of it.
232d230
< [KW] [Humm]  It's important.
314,317c312,315
< [RS] if we want to simplify things, we need to remove choice completely.  I 
am not proposing that we do this.
< [MB] I agree.
< [RS] you need to track which branch gets used. It does not explicitly show in 
the tree. And for those who do not like they could not implement it.
< [MB] The data model designer needs to use these constructs carefully.  
"choice" is often used in very small trees only.
---
> [RS] if we want to simplify things, we need to remove choice completely.
> [MB] L that is likely a good idea.
> [RS] you need to track which branch gets used. It does not explicitly does 
> not show in the tree. And for those who do not like they could not implement 
> it.
> [MB] maybe it is only applicable to very small trees only.
401c399
< [RW] This is more of a label of the interface type.
---
> [RS] Wilton  this is more of a label of the interface type.
403,404c401,402
< [RW]  augmentation needs to be in the same module as the identity definition.
< [MB]   that is a side effect of allowing mandatory augments.
---
> [RS]  augmentation needs to be in the same ??
> [MB]   that is a side effect of allowing mandatory augments?
406,410c404,407
< [KW] [Support indicated].  OK, good.  Will confirm on the WG mailing list.
< [DR] waiting for IEEE 802.1Q WG chair - what is that
< [MJ]  Glen thinks that the extension of VLAN YANG model should be happening 
there
< [RW] Concern is overlap with the 802.1Q YANG model for bridges.  But this 
model doesn't overlap because it it only defines an interface based model for 
classification.
< [DR] do you have any mail exchanges for this? Maybe this could be raised in 
IEEE plenary. Please forward me any emails on this discussion.
---
> [DR] waiting for IEEE 802.1Q WG chair - what is that?
> [MJ]  Glen thinks that the extension of VLAN YANG model should be happening 
> there.
> [RS]  this is related to overlapping of 

Re: [netmod] [Rtg-dt-yang-arch] draft-ietf-netmod-routing-cfg

[Dean Bogdanovic]

Martin,
> n Nov 24, 2015, at 4:24 AM, Martin Bjorklund  wrote:
> 
> Hi,
> 
> "Acee Lindem (acee)"  wrote:
>> We had a lot of good discussions at IETF 94 with respect to the
>> ietf-routing and how it could be augmented in the future to support I2RS.
>> These discussions are ongoing.
>> 
>> One current change that I would like to propose is to change the base
>> instance container from routing-instance to networking-instance.
> 
> Is the idea to simply rename the "routing-instance" container to
> "networking-instance"?
> 
> Then we would have:
> 
>   +--rw routing
>  +--rw networking-instance
> 
> Would you keep the top-level name "routing”?

Yes, routing is not confined to IP only. TRILL and PBB do routing at MAC layer, 
so routing as top level domain can stay. OTH, routing instance is well defined 
term in the industry, so there is a need to have a term that can encompass L2 
and L3.

Dean

> 
> 
> 
> 
> /martin
> 
> 
> 
> 
>> This
>> would provide an instance definition that could be augmented for L2
>> protocols and service functionality as well as L3. It is also consistent
>> with the term used in both
>> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-01.txt and
>> https://www.ietf.org/id/draft-openconfig-rtgwg-network-instance-01.txt.
>> 
>> Thanks,
>> Acee 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 
> 
> ___
> Rtg-dt-yang-arch mailing list
> rtg-dt-yang-a...@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-routing-cfg

[Acee Lindem (acee)]

Hi Martin,
 
I think using the more generic term, “networking”, at the top would be
preferable. What we need is an instance abstraction that covers L3 (e.g.,
virtual router or VRF), L2 (e.g., Virtual Switch Instance), or a
combination (some EVPN, TRILL, etc). This could be used in lieu of each L2
model creating their own top separate list of instances. For example, the
networking-instance could be augmented with both the VPLS and VPWS
instances in https://tools.ietf.org/html/draft-shah-bess-l2vpn-yang-00.

Some YANG models ascribe greatness from the start, others achieve
greatness through refinement, while still others have greatness thrust
upon them. routing-cfg would fall into the last category…

Thanks,
Acee 

On 11/24/15, 4:24 AM, "Martin Bjorklund"  wrote:

>Hi,
>
>"Acee Lindem (acee)"  wrote:
>> We had a lot of good discussions at IETF 94 with respect to the
>> ietf-routing and how it could be augmented in the future to support
>>I2RS.
>> These discussions are ongoing.
>> 
>> One current change that I would like to propose is to change the base
>> instance container from routing-instance to networking-instance.
>
>Is the idea to simply rename the "routing-instance" container to
>"networking-instance"?
>
>Then we would have:
>
>   +--rw routing
>  +--rw networking-instance
>
>Would you keep the top-level name "routing"?
>
>
>
>
>/martin
>
>
>
>
>> This
>> would provide an instance definition that could be augmented for L2
>> protocols and service functionality as well as L3. It is also consistent
>> with the term used in both
>> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-01.txt and
>> https://www.ietf.org/id/draft-openconfig-rtgwg-network-instance-01.txt.
>> 
>> Thanks,
>> Acee 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft netmod 94 minutes posted

[Robert Wilton]

Hi Kent,

I've some minor modifications of some of the minutes, mainly just to 
clarify who was asking some of the questions/comments (mostly between 
Rob Shakir and myself), but also some other minor clarifications when I 
was listening back to the audio.


[Before]

10 min: draft-ietf-openconfig-netmod-opstate-01(Anees Shaikh or [RS] Shakir)
Rob Shakir presenting.
[LL] Would it be possible to have multiple management interfaces (NETCONF, 
RESTONF, other) - is the intended configuration supposed to be private per 
transport protocol?
[RS]  Would think no. There is one intended configuration per device.
[LL] this may have some locking implications.
[TC]  Why did you chose to use intended/applied approach?
[RS]  This allows us to use YANG today.
[KW] there were 3 solutions drafts.
[TC]we are doing the same thing in BBF, and would like to mimic the 
solution agreed here.
[AS] There is a section i a draft that addresses this.
[LB]  I am confused on the process for the requirements. You said you will make 
consensus call for requirements today?
[KW] we will do a consensus call on solutions. I believe there is consensus on 
requirements.
[LB]  on a list there was a discussion on planning to poll for consensus but 
that did not seem to happen.
[KW] confirming consensus on requirements now by humming - consensus achieved.


[After]
10 min: draft-ietf-openconfig-netmod-opstate-01(Anees Shaikh or [RS] 
Shakir)

Rob Shakir presenting.
[LL] Would it be possible to have multiple management interfaces 
(NETCONF, RESTONF, other) - is the intended configuration supposed to be 
private per transport protocol?

[RS]  Would think no. There is one intended configuration per device.
[LL] this may have some locking implications.
[TC]  Why did you chose to use intended/applied approach rather than 
using datastores?
[RS]  1. No such thing as an applied datastore today.  This solution 
allows us to use YANG today. 2. Our solution allows for a single path 
that is not dependent on the datastore.

[KW] there were 3 solutions drafts.
[TC]we are doing the same thing in BBF, and would like to mimic the 
solution agreed here.
[AS] There is a section in our draft that addresses some of these 
questions.
[LB]  I am confused on the process for the requirements. You said you 
will make consensus call for requirements today?
[KW] we will do a consensus call on solutions. I believe there is 
consensus on requirements.
[LB]  on a list there was a discussion on planning to poll for consensus 
but that did not seem to happen.
[KW] confirming consensus on requirements now by humming - consensus 
achieved.



[Before]

10 min: other solutions for the opstate-reqs (Robert Wilton)
Robert Wilton presenting.
[RW]  no changes to existing YANG models - that does not seem to be practical. 
There are vendor extensions anyway.
[RW] Wilton  if models are standardised in IETF, they should work in all cases.

[KW] we would like to know which of those solutions should progress forward.
[Rw]  would be nice to poil for who has read the solutions drafts?
[KW] who would favor solution 1. Humm. 2. Humm (most). 3. Humm
[KW] Does anyone object to solution 2? Please go to mike?
[Rw]  Didn't we do that already? We seem not to going anywhere forward with 
this discussion. We did clarify wording, but that is mostly it. It is noting 
for operator to help with configuring a network. Is it a perfection problem 
here? Can we produce something practically useful?
[CM] There are large installations based on existing YANG specifications.
[RW]I take that into account. I have none in my network though that use 
existing model. I am not saying that we should throw away the existing solution 
in favor of the future solution.
[CM] There is a technology shift.
[CH] We are not forcing to implement some particular data store technology. 
This is more of a way of thinking of it.


[After]
10 min: other solutions for the opstate-reqs (Robert Wilton)
Robert Wilton presenting.
[RS] No changes to existing YANG models - that does not seem to be 
practical. There are vendor extensions anyway.

[RW]   if models are standardised in IETF, they should work in all cases.

[KW] we would like to know which of those solutions should progress 
forward.

[RS] Would be nice to poll for who has read the solutions drafts?
[KW] [Show of hands] About half the room have read the three drafts.
[KW] Who would favor solution 1. Humm. 2. Humm (most). 3. Humm
[KW] Does anyone object to solution 2? Please go to mike?
[RS]  Didn't we do that already? We seem not to going anywhere forward 
with this discussion. We did clarify wording, but that is mostly it. It 
is nothing for operator to help with configuring a network. Is it a 
perfection problem here? Can we produce something practically useful?
[CM] There are large installations based on existing YANG and NETCONF 
specifications.
[RS]I take that into account. I have none in my network though that 
use existing model. I am not saying 

Re: [netmod] draft-ietf-netmod-routing-cfg

[Martin Bjorklund]

Hi,

"Acee Lindem (acee)"  wrote:
> We had a lot of good discussions at IETF 94 with respect to the
> ietf-routing and how it could be augmented in the future to support I2RS.
> These discussions are ongoing.
> 
> One current change that I would like to propose is to change the base
> instance container from routing-instance to networking-instance.

Is the idea to simply rename the "routing-instance" container to
"networking-instance"?

Then we would have:

   +--rw routing
  +--rw networking-instance

Would you keep the top-level name "routing"?




/martin




> This
> would provide an instance definition that could be augmented for L2
> protocols and service functionality as well as L3. It is also consistent
> with the term used in both
> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-01.txt and
> https://www.ietf.org/id/draft-openconfig-rtgwg-network-instance-01.txt.
> 
> Thanks,
> Acee 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft netmod 94 minutes posted

[Robert Wilton]

Hi Kent, Andrew

Do you have a pointer to the recordings please?  I tried the audio 
streams on the link below, but I can't seem to get them to work.


https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html

Thanks,
Rob


On 17/11/2015 18:32, Kent Watsen wrote:


All,

The minutes for the two NETMOD sessions have been posted:

https://www.ietf.org/proceedings/94/minutes/minutes-94-netmod

Please provide comments/corrections on these draft minutes by Wed, Nov 
25th.


PS: huge thanks to Ignas and Andrew for putting these together!

Thanks,
Kent



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft netmod 94 minutes posted

[Nadeau Thomas]

It doesn't work for me either. I’ll file a case with the support folks 
to take a look.

—Tom

> On Nov 24, 2015:9:22 AM, at 9:22 AM, Robert Wilton  wrote:
> 
> Hi Kent, Andrew
> 
> Do you have a pointer to the recordings please?  I tried the audio streams on 
> the link below, but I can't seem to get them to work.
> 
> https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html 
> 
> 
> Thanks,
> Rob
> 
> 
> On 17/11/2015 18:32, Kent Watsen wrote:
>> 
>> All,
>> 
>> The minutes for the two NETMOD sessions have been posted:
>> 
>> https://www.ietf.org/proceedings/94/minutes/minutes-94-netmod 
>> 
>> 
>> Please provide comments/corrections on these draft minutes by Wed, Nov 25th.
>> 
>> PS: huge thanks to Ignas and Andrew for putting these together!
>> 
>> Thanks,
>> Kent
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod 
>> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft netmod 94 minutes posted

[Robert Wilton]

Thanks, Martin.  That works.

Rob


On 24/11/2015 14:36, Martin Bjorklund wrote:

Robert Wilton  wrote:

Hi Kent, Andrew

Do you have a pointer to the recordings please?  I tried the audio
streams on the link below, but I can't seem to get them to work.

https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html

Try this one:

http://ietf94.conf.meetecho.com/index.php/Recordings


/martin
.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft netmod 94 minutes posted

[Kent Watsen]

On 11/24/15, 9:36 AM, "Martin Bjorklund"  wrote:

>Robert Wilton  wrote:
>> Hi Kent, Andrew
>> 
>> Do you have a pointer to the recordings please?  I tried the audio
>> streams on the link below, but I can't seem to get them to work.
>> 
>> https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html


When clicking on the “audio stream” link:

  - Safari says “ This webpage has content that requires an Internet plug-in.
This page contains content of “audio/x-mpegurl” type. You do not have the
plug-in required to view this content.  I clicked the “missing plugin”
link, but it didn’t do anything.

  - Firefox offers to save the file or load with iTunes.  Loading with iTunes
doesn’t work.  Saving to file and then examining its contents shows
"http://icecast-ietf.conf.meetecho.com:8000/room301.mp3”, which looks
like it’s more for the live stream as oppose for a recorded stream.




>Try this one:
>
>http://ietf94.conf.meetecho.com/index.php/Recordings
>
>
>/martin


This worked for me in Firefox, but not Safari (it spins forever trying to load 
the page)

Thanks,
Kent



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod