Sent: Tuesday, April 16, 2019 9:52 AM
To: Christian Hopps; lsr@ietf.org
Subject: Re: [Lsr] When to augment LSR base YANG modules...
Hi,
On one hand, I'm a bit worried about having too many tiny modules (finding the
right module name to get the right feature, managing prefixes...). The good
thin
Hi,
On one hand, I'm a bit worried about having too many tiny modules (finding the
right module name to get the right feature, managing prefixes...). The good
thing I see is that we could mandate in each LSR draft the YANG management part
so both are published at the same time. While YANG is
On 2019-04-02 12:08, tom petch wrote:
- Original Message -
From: "Mikael Abrahamsson"
Sent: Sunday, March 31, 2019 8:07 AM
On Sat, 30 Mar 2019, Acee Lindem (acee) wrote:
Additionally, I agree with Yingzhen's comment that it is not clear
that
we want a separate YANG module for
- Original Message -
From: "Mikael Abrahamsson"
Sent: Sunday, March 31, 2019 8:07 AM
> On Sat, 30 Mar 2019, Acee Lindem (acee) wrote:
>
> > Additionally, I agree with Yingzhen's comment that it is not clear
that
> > we want a separate YANG module for every OSPF/IS-IS feature.
>
> As an
y, March 31, 2019 at 7:15 AM
> To: 'Rob Shakir' , "'Acee Lindem (acee)'"
> Cc: "lsr@ietf.org" , "tony...@tony.li" ,
'Christian Hopps'
> Subject: Re: [Lsr] When to augment LSR base YANG modules...
>
> Rob and Acee:
>
n return?
Thanks,
Chris.
>
> Thanks,
> Yingzhen
>
> From: Lsr on behalf of Susan Hares
> Date: Sunday, March 31, 2019 at 7:15 AM
> To: 'Rob Shakir' , "'Acee Lindem (acee)'"
> Cc: "lsr@ietf.org" , "tony...@tony.li" ,
> 'Christian Hopps'
> S
he upcoming WG LC.
Sue
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Saturday, March 30, 2019 2:00 PM
To: Acee Lindem (acee)
Cc: lsr@ietf.org; tony...@tony.li; Christian Hopps
Subject: Re: [Lsr] When to augment LSR base YANG modules...
I think this is a generic challenge th
[mailto:lsr-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Saturday, March 30, 2019 2:00 PM
To: Acee Lindem (acee)
Cc: lsr@ietf.org; tony...@tony.li; Christian Hopps
Subject: Re: [Lsr] When to augment LSR base YANG modules...
I think this is a generic challenge that has to be solved across all
So to have something to look at while we discuss this I wrote a bare-bones
module document for IS-IS reverse metrics:
https://tools.ietf.org/html/draft-hopps-lsr-yang-isis-reverse-metric-00
If you look at the meat of that document and then imagine including it as an
appendix or whatever
On Sat, 30 Mar 2019, Rob Shakir wrote:
That being said -- this means one should probably expect each LSR base
module to be revised with most new LSR RFCs. With the current agility of
the review and publication process -- I'm not sure that is realistic
either..
I have discussed this with
On Sat, 30 Mar 2019, Acee Lindem (acee) wrote:
Additionally, I agree with Yingzhen's comment that it is not clear that
we want a separate YANG module for every OSPF/IS-IS feature.
As an operator, I expect to manage my routers using YANG modules. Thus,
every feature that is introduced that
I think this is a generic challenge that has to be solved across all
protocols -- and relies on a robust way to version and revise YANG modules
in the IETF.
In OpenConfig, as we're very lightweight for pushing a new revision, since
we're just specifying new versions of modules, adding new
Speaking as WG member:
For many of the new LSR WG documents, we are already included both OSPF and
IS-IS encodings in a single document. Now, we have agreed that documents
requiring simple BGP-LS changes will also include the BGP-LS encoding. Given
this, I don't want to add another requirement
Chris,
One concern is simply one of scale: doing this will increase the size of the
document. At what point do things become sufficiently awkward that we want to
have a separate, concurrent document.
In other words, if the requirement is for concurrent delivery, is co-location
really a
14 matches
Mail list logo
