[Lsr] Publication has been requested for draft-ietf-isis-reverse-metric-11

[Christian Hopps]

Christian Hopps has requested publication of draft-ietf-isis-reverse-metric-11 
as Proposed Standard on behalf of the LSR working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/

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

Re: [Lsr] Working Group Last Call for OSPF LLS Extensions for Local Interface ID Advertisement - draft-ietf-ospf-lls-interface-id-02

[Acee Lindem (acee)]

All,

The WG Last Call has completed and we will request publication.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Monday, June 18, 2018 at 12:07 PM
To: "lsr@ietf.org" 
Subject: [Lsr] Working Group Last Call for OSPF LLS Extensions for Local 
Interface ID Advertisement - draft-ietf-ospf-lls-interface-id-02

This begins an LSR WG last call for the subject draft. Please send your
comments to this list prior to 12:00 AM GMT, July 3rd, 2018.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

[Acee Lindem (acee)]

HI Zhibo,
Also note that there are other ways to solve this problem without the 
controller dynamically modifying metrics for distributed SPF computation. 
However, I’ll let others closer to those alternatives engage in this discussion.
Thanks,
Acee

From: Acee Lindem 
Date: Friday, July 6, 2018 at 9:44 AM
To: Huzhibo 
Cc: "lsr@ietf.org" 
Subject: Re: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi Zhibo,

As I told you, the LSR WG agenda is fully subscribed for IETF 102. Note that 
dynamic metric adjustment is not a new idea and is supported by many wireless 
routing protocols (e.g., BABEL) as well as EIGRP. However, I realize that you 
are proposed a controller framework as opposed to local network adjustments. 
Perhaps, you could request a slot in the Routing Working Group as they are 
meeting twice.

Thanks,
Acee


On Jul 6, 2018, at 3:15 AM, Huzhibo 
mailto:huzh...@huawei.com>> wrote:

Hi,

Request a slot to discuss Network Automatic Optimization Based on Dynamic 
Adjustment of IGP Metrics:

Drafts:
https://datatracker.ietf.org/doc/draft-hu-lsr-network-automatic-optimization/
Presenter: ZhiBo Hu

Duration: 15 mins

Thanks!
ZHiBo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, June 18, 2018 9:45 PM
To: lsr@ietf.org
Subject: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi Folks,

The LSR (link-state-routing) WG will be meeting on Monday, July 16, 2018 from 
9:30 to 12:00 (the first WG slot of IETF 102).

Please send us (lsr-cha...@ietf.org) any requests 
for presentation slots.

Thanks,
Acee

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

Re: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

[Acee Lindem (acee)]

Hi Zhibo,

As I told you, the LSR WG agenda is fully subscribed for IETF 102. Note that 
dynamic metric adjustment is not a new idea and is supported by many wireless 
routing protocols (e.g., BABEL) as well as EIGRP. However, I realize that you 
are proposed a controller framework as opposed to local network adjustments. 
Perhaps, you could request a slot in the Routing Working Group as they are 
meeting twice.

Thanks,
Acee

On Jul 6, 2018, at 3:15 AM, Huzhibo 
mailto:huzh...@huawei.com>> wrote:

Hi,

Request a slot to discuss Network Automatic Optimization Based on Dynamic 
Adjustment of IGP Metrics:

Drafts:
https://datatracker.ietf.org/doc/draft-hu-lsr-network-automatic-optimization/
Presenter: ZhiBo Hu

Duration: 15 mins

Thanks!
ZHiBo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, June 18, 2018 9:45 PM
To: lsr@ietf.org
Subject: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi Folks,

The LSR (link-state-routing) WG will be meeting on Monday, July 16, 2018 from 
9:30 to 12:00 (the first WG slot of IETF 102).

Please send us (lsr-cha...@ietf.org) any requests 
for presentation slots.

Thanks,
Acee

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

Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Acee Lindem (acee)]

> On Jul 6, 2018, at 8:59 AM, Randy Bush  wrote:
> 
>> ​Why anyone would need BMP wrapper to monitor IGP ?
> 
> probably similar reasons that folk seem to need bgp-ls to get the
> is-is/ospf databases.  is-is and ospf have decades of complexity
> layered on un-simple bases.  so we seek yet another layer of gunk
> through which to see them more 'simply.'
> 
> i would say an optimistic view might be that it will take a couple
> more decades to gunk up bgp-ls and bmp so that we want yet another
> layer.  but it would appear that my optimism is not warranted.


Those who forget the past are condemned to repeat it…

Acee



> 
> randy
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

[Acee Lindem (acee)]

Hi Zhibo,

I’m sorry but our agenda is already full for IETF 102. As LSR is one of the 
most popular WGs, you need to get your requests in early. With respect to this 
draft, there is already an IS-IS sub-TLV MTU advertisement defined in RFC 7176. 
While the RFC is specific to TRILL, I don’t see any reason why the sub-TLV 
couldn’t be used in non-TRILL deploymennts.

Thanks,
Acee

From: Huzhibo 
Date: Friday, July 6, 2018 at 3:08 AM
To: Acee Lindem , "lsr@ietf.org" 
Cc: "zh...@gsta.com" , Robin Li , 
"Dailongfei (Larry, IP Research)" 
Subject: RE: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi,

Request a slot to discuss ISIS extended for PathMTU:

Drafts:
https://datatracker.ietf.org/doc/draft-hu-lsr-isis-path-mtu/
Presenter: ZhiBo Hu

Duration: 10 mins

Thanks!
ZHiBo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, June 18, 2018 9:45 PM
To: lsr@ietf.org
Subject: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi Folks,

The LSR (link-state-routing) WG will be meeting on Monday, July 16, 2018 from 
9:30 to 12:00 (the first WG slot of IETF 102).

Please send us (lsr-cha...@ietf.org) any requests 
for presentation slots.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Randy Bush]

> ​Why anyone would need BMP wrapper to monitor IGP ?

probably similar reasons that folk seem to need bgp-ls to get the
is-is/ospf databases.  is-is and ospf have decades of complexity
layered on un-simple bases.  so we seek yet another layer of gunk
through which to see them more 'simply.'

i would say an optimistic view might be that it will take a couple
more decades to gunk up bgp-ls and bmp so that we want yet another
layer.  but it would appear that my optimism is not warranted.

randy

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

Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Einar Nilsen-Nygaard (einarnn)]

+1

On 6 Jul 2018, at 10:46, Robert Wilton 
mailto:rwilton=40cisco@dmarc.ietf.org>> 
wrote:



On 05/07/2018 23:03, Acee Lindem (acee) wrote:
Hi Robin,

I know for a fact that there have been applications written that do passive 
monitoring using IS-IS and simply advertising yourself in overload mode. 
Additionally, given that all routes in an area have the same LSDB, you don't 
really have the same requirements as BGP.

With respect to scalability, I believe the advantage of the YANG models is more 
in terms of consumption and having a single network programmability paradigm 
rather unique per-protocol monitoring. Additionally, YANG, NETCONF, RESTCONF, 
gNMI, and streaming telemetry are happening now irrespective of your proposal.

I agree that a custom protocol will result in fewer bits on the wire and 
potentially less processing on the network device. However, I certainly don't 
believe that this alone is a reason to do it.
If we want less bits on the wire, then adding support for a binary encoding 
(e.g. CBOR) to the existing YANG management protocols seems like a better path 
forwards to me since that seems to have the widest benefit.  CBOR encoded YANG 
(if using numerical "SIDs" rather than strings for the field names, 
draft-ietf-core-yang-cbor) is a pretty tight encoding, and is designed for IOT 
and constrained devices.  A CBOR encoding probably won't be quite as compact as 
custom TLVs, but I doubt that it would be significantly bigger either, and it 
has quite a few other benefits (code reuse, can be generically decoded).

Thanks,
Rob



Thanks,
Acee


On 7/5/18, 6:49 AM, "GROW on behalf of Lizhenbin" 
mailto:grow-boun...@ietf.org> on behalf of 
lizhen...@huawei.com> wrote:

Hi Jeff,
Before we propose the NMP idea, we carefully compared it with the existing 
NETCONF, gRPC and YANG models work:
1. Based on my experience in the YANG model work, it may be not 
satisfactory for these models does not define config/oper of all features of 
specific protocol and these models have much relation with each other and it is 
difficult to stabilize the definition.
2. For monitoring the control protocol, it is not enough based on the 
existing YANG models such as the packets of control protocol which should be 
monitored but not defined in YANG models.
3. Performance concern on the existing NETCONF.
4. Standardization of the existing gRPC.
 We would like to define the NMP based on the usecases. That is, a 
specific set of parameters exported by NMP can satisfy the purpose of a 
specific usecase. Thus the protocol can be deployed incrementally.
  Best Regards,
Robin
   -Original Message-
From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Wednesday, July 04, 2018 5:15 AM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
Lizhenbin mailto:lizhen...@huawei.com>>; 
g...@ietf.org; ops...@ietf.org
Cc: lsr@ietf.org; 
rt...@ietf.org; Guyunan (Yunan Gu, IP Technology 
Research Dept. NW) mailto:guyu...@huawei.com>>
Subject: Re: [Lsr] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt
 Robin,
 Pretty much same comment as Acee - I'm not clear as to why...
Protocol YANG models developed in the last years clearly provide much 
better and more scalable approach to what has been proposed in the draft, since 
we are talking is-is - look at notifications in draft-ietf-isis-yang-isis-cfg. 
How do you propose to corelate operational state to configuration?
 gRPC provides high performance RPC framework  to streaming the 
telemetry data that is structured, easy to consume and extend.
 I'm not going to go into technical discussion, however would 
appreciate your response as to why NMP (please do not restate the points in the 
section 4 of the draft, they are quite incorrect)
 Thanks!
 Cheers,
Jeff
 On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)" 
mailto:lsr-boun...@ietf.org> on behalf of 
acee=40cisco@dmarc.ietf.org> wrote:
 Hi Robin,
I'm not arguing to deprecate BMP. What I am arguing is that the fact 
that BMP was created 15 years ago doesn't necessarily mean we should create an 
analogous IMP for IS-IS given the current IETF OPS technologies and the fact 
that faster link speeds and Moore's law facilitate deployment of these new OPS 
technologies. Anyway, I looked at the agenda and I will definitely attend GROW 
on Wednesday afternoon for the discussion.
Thanks,
Acee
 On 7/3/18, 6:40 AM, "Lizhenbin" 
mailto:lizhen...@huawei.com>> wrote:
 Hi Acee,
Thank for your attention to the new draft. Please refer to my reply 
inline.
 Best Regards,
   

Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Robert Wilton]

On 05/07/2018 23:03, Acee Lindem (acee) wrote:

Hi Robin,

I know for a fact that there have been applications written that do passive 
monitoring using IS-IS and simply advertising yourself in overload mode. 
Additionally, given that all routes in an area have the same LSDB, you don't 
really have the same requirements as BGP.

With respect to scalability, I believe the advantage of the YANG models is more 
in terms of consumption and having a single network programmability paradigm 
rather unique per-protocol monitoring. Additionally, YANG, NETCONF, RESTCONF, 
gNMI, and streaming telemetry are happening now irrespective of your proposal.

I agree that a custom protocol will result in fewer bits on the wire and 
potentially less processing on the network device. However, I certainly don't 
believe that this alone is a reason to do it.
If we want less bits on the wire, then adding support for a binary 
encoding (e.g. CBOR) to the existing YANG management protocols seems 
like a better path forwards to me since that seems to have the widest 
benefit.  CBOR encoded YANG (if using numerical "SIDs" rather than 
strings for the field names, draft-ietf-core-yang-cbor) is a pretty 
tight encoding, and is designed for IOT and constrained devices.  A CBOR 
encoding probably won't be quite as compact as custom TLVs, but I doubt 
that it would be significantly bigger either, and it has quite a few 
other benefits (code reuse, can be generically decoded).


Thanks,
Rob


  


Thanks,
Acee


On 7/5/18, 6:49 AM, "GROW on behalf of Lizhenbin"  wrote:

 Hi Jeff,
 Before we propose the NMP idea, we carefully compared it with the existing 
NETCONF, gRPC and YANG models work:
 1. Based on my experience in the YANG model work, it may be not 
satisfactory for these models does not define config/oper of all features of 
specific protocol and these models have much relation with each other and it is 
difficult to stabilize the definition.
 2. For monitoring the control protocol, it is not enough based on the 
existing YANG models such as the packets of control protocol which should be 
monitored but not defined in YANG models.
 3. Performance concern on the existing NETCONF.
 4. Standardization of the existing gRPC.
 
 We would like to define the NMP based on the usecases. That is, a specific set of parameters exported by NMP can satisfy the purpose of a specific usecase. Thus the protocol can be deployed incrementally.
 
 
 Best Regards,

 Robin
 
 
 
 -Original Message-

 From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
 Sent: Wednesday, July 04, 2018 5:15 AM
 To: Acee Lindem (acee) ; Lizhenbin 
; g...@ietf.org; ops...@ietf.org
 Cc: lsr@ietf.org; rt...@ietf.org; Guyunan (Yunan Gu, IP Technology Research 
Dept. NW) 
 Subject: Re: [Lsr] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt
 
 Robin,
 
 Pretty much same comment as Acee - I'm not clear as to why...

 Protocol YANG models developed in the last years clearly provide much 
better and more scalable approach to what has been proposed in the draft, since 
we are talking is-is - look at notifications in draft-ietf-isis-yang-isis-cfg. 
How do you propose to corelate operational state to configuration?
 
 gRPC provides high performance RPC framework  to streaming the telemetry data that is structured, easy to consume and extend.
 
 I'm not going to go into technical discussion, however would appreciate your response as to why NMP (please do not restate the points in the section 4 of the draft, they are quite incorrect)
 
 Thanks!
 
 Cheers,

 Jeff
 
 On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)"  wrote:
 
 Hi Robin,

 I'm not arguing to deprecate BMP. What I am arguing is that the fact 
that BMP was created 15 years ago doesn't necessarily mean we should create an 
analogous IMP for IS-IS given the current IETF OPS technologies and the fact 
that faster link speeds and Moore's law facilitate deployment of these new OPS 
technologies. Anyway, I looked at the agenda and I will definitely attend GROW 
on Wednesday afternoon for the discussion.
 Thanks,
 Acee
 
 On 7/3/18, 6:40 AM, "Lizhenbin"  wrote:
 
 Hi Acee,

 Thank for your attention to the new draft. Please refer to my 
reply inline.
 
 Best Regards,

 Robin
 
 
 
 -Original Message-

 From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Acee 
Lindem (acee)
 Sent: Monday, July 02, 2018 9:24 PM
 To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
; g...@ietf.org; ops...@ietf.org
 Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt
  

Re: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

[Huzhibo]

Hi,

Request a slot to discuss Network Automatic Optimization Based on Dynamic 
Adjustment of IGP Metrics:

Drafts:
https://datatracker.ietf.org/doc/draft-hu-lsr-network-automatic-optimization/
Presenter: ZhiBo Hu

Duration: 15 mins

Thanks!
ZHiBo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, June 18, 2018 9:45 PM
To: lsr@ietf.org
Subject: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi Folks,

The LSR (link-state-routing) WG will be meeting on Monday, July 16, 2018 from 
9:30 to 12:00 (the first WG slot of IETF 102).

Please send us (lsr-cha...@ietf.org) any requests 
for presentation slots.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

[Huzhibo]

Hi,

Request a slot to discuss ISIS extended for PathMTU:

Drafts:
https://datatracker.ietf.org/doc/draft-hu-lsr-isis-path-mtu/
Presenter: ZhiBo Hu

Duration: 10 mins

Thanks!
ZHiBo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, June 18, 2018 9:45 PM
To: lsr@ietf.org
Subject: [Lsr] IETF 102 LSR Working Group Call for Agenda Items

Hi Folks,

The LSR (link-state-routing) WG will be meeting on Monday, July 16, 2018 from 
9:30 to 12:00 (the first WG slot of IETF 102).

Please send us (lsr-cha...@ietf.org) any requests 
for presentation slots.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr