Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-08-31 Thread Lizhenbin
Hi All,

I support the adoption.


Best Regards,

Zhenbin (Robin)

--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com

发件人:Acee Lindem (acee) 
收件人:lsr 
时 间:2020-08-18 22:17:38
主 题:[Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.

These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.

Thanks,
Acee and Chris

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


[Lsr] 答复: New Version Notification for draft-wang-lsr-igp-extensions-ifit-00.txt

2020-07-17 Thread Lizhenbin
Hi Les,

I add one more case for your reference. There are several SR-Policy/SR-Tunnel 
implementations which depend on the configuration on the devices other than the 
controller. If the IFIT capability is enabled for these SR-Policy/Tunnels, IGP 
will be helpful for the ingress node to learn the capabilities of other nodes 
along the SR-Policy/Tunnel.





Best Regards,

Robin










发件人: Lsr [lsr-boun...@ietf.org] 代表 wangyali [wangyal...@huawei.com]
发送时间: 2020年7月17日 20:19
收件人: Les Ginsberg (ginsberg); lsr@ietf.org
主题: Re: [Lsr] New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt

Dear Les,

Many thanks for your quick feedback. We are very appreciate all of your 
insightful comments and advices. ☺

Please let me clarify the one of requirements is that the ingress node cannot 
insert IFIT instruction for packets going into a path unless the egress node 
signals its capability of processing IFIT data fields.

Actually, taking your suggestions and those of others into account, we tried to 
use NETCONF for query node capability.  However, in the scenario of SR-BE, the 
ingress node controls a path along which packets are transmitted, which is not 
included in a centralized controller. Therefore, extensions to IGP for node’s 
capability advertisement is considered as an efficient way but NETCONF doesn't 
work.

Best regards,
Yali

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, July 17, 2020 5:25 AM
To: wangyali ; lsr@ietf.org
Subject: RE: New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt


Yali -



While it is kind of you to acknowledge many of us for our comments, in many 
cases (myself included) what we told you is that this does not belong in the 
IGPs.

Putting out a new draft which continues to push for advertising ifit in IGPs 
(even if in different TLVs) does not indicate that you are heeding our message. 






   Les





> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> wangyali

> Sent: Thursday, July 16, 2020 8:20 AM

> To: lsr@ietf.org

> Subject: [Lsr] FW: New Version Notification for draft-wang-lsr-igp-

> extensions-ifit-00.txt

>

> Dear LSR WG,

>

> We've uploaded a new revision of draft-wang-lsr-igp-extensions-ifit-00 to

> replace draft-wang-lsr-ifit-node-capability-advertisement. In this new

> revision, Node and Link Attribute TLVs are extended to IGP for signaling the

> supported IFIT capability of egress and/or intermediate nodes to the ingress

> nodes.

>

> The changes in this revision are:

>

> 1. added Link Attribute TLVs extension to IGP to signal IFIT Capability at 
> link

> granularity.

> 2. updated Application section, which illustrates such advertisements would

> helpful for avoiding the leak of IFIT-specific header and metadata, as well 
> as,

> for ingress routers to gather each router's IFIT capability for achieving the

> computation of TE paths or loose TE paths that be able to fulfill the 
> visibility of

> on-path OAM data.

> 3. updated Acknowledgements sections, in which, the authors would like to

> thank Acee Lindem, Christian Hopps, Robert Raszuk, Les Ginsberg, Jeff

> Tantsura, Rakesh Gandhi, Tony Li and Greg Mirsky for the comments.

> 4. adding China Telecom into the author list.

>

> We are looking forward to hearing your feedback and comments, and try to

> achieve consensus.

>

> Thanks,

> Yali

>

>

> -Original Message-

> From: internet-dra...@ietf.org 
> [mailto:internet-dra...@ietf.org]

> Sent: Monday, July 13, 2020 9:15 PM

> To: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
> wangyali

> mailto:wangyal...@huawei.com>>; Huanan Chen 
> mailto:chenhu...@chinatelecom.cn>>;

> Liumin (Lucy) mailto:lucy.liu...@huawei.com>>; Ran 
> Pang

> mailto:pang...@chinaunicom.cn>>; Liumin (Lucy) 
> mailto:lucy.liu...@huawei.com>>

> Subject: New Version Notification for draft-wang-lsr-igp-extensions-ifit-

> 00.txt

>

>

> A new version of I-D, draft-wang-lsr-igp-extensions-ifit-00.txt

> has been successfully submitted by Yali Wang and posted to the IETF

> repository.

>

> Name:   draft-wang-lsr-igp-extensions-ifit

> Revision:  00

> Title:  IGP Extensions for In-situ Flow Information Telemetry 
> (IFIT)

> Capability Advertisement

> Document date:2020-07-12

> Group:  Individual Submission

> Pages:   12

> URL:
> https://www.ietf.org/internet-drafts/draft-wang-lsr-igp-

> extensions-ifit-00.txt

> Status: 
> https://datatracker.ietf.org/doc/draft-wang-lsr-igp-extensions-

> 

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

2020-01-26 Thread Lizhenbin

Support. Not aware of any undisclosed IPR.

Best Regards,
Zhenbin (Robin)

--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com

发件人:Christian Hopps 
收件人:lsr 
抄 送:Christian Hopps ;Acee Lindem (acee) 
;lsr-ads ;draft-li-lsr-ospfv3-srv6-extensions 

时 间:2020-01-24 04:24:51
主 题:WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/

Please indicate your support or objection by Feb 6, 2020.

Authors, please respond indicating whether you are aware of any IPR that 
applies to this draft.

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


Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

2020-01-26 Thread Lizhenbin

I support the last call. There have been multiple implementations and 
deployment. The solution is stable and the draft is well written.

Best Regards,
Zhenbin (Robin)

--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com

发件人:Christian Hopps 
收件人:lsr 
抄 送:lsr-ads ;Christian Hopps ;Acee Lindem 
(acee) 
时 间:2020-01-22 08:15:23
主 题:[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
draft-ietf-lsr-isis-srv6-extensions

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Authors please indicate if you aware of any other IPR beyond what is posted:

  https://datatracker.ietf.org/ipr/3796/

Thanks,
Chris & Acee.
___
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] Comments on draft-li-ospf-ospfv3-srv6-extensions-07.txt

2019-12-16 Thread Lizhenbin
Hi Acee,
Thanks very much for your help to refine the draft. You suggestion also makes 
sense. We will update accordingly.

Best Regards,
Robin



From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, December 13, 2019 5:44 AM
To: draft-li-ospf-ospfv3-srv6-extensi...@ietf.org
Cc: lsr@ietf.org
Subject: Comments on draft-li-ospf-ospfv3-srv6-extensions-07.txt

Hi Robin, et al,
One thing I’d like to see is incorporation of the text for the MSD types in the 
draft. It is less than one and a half pages and it doesn’t make sense to 
reference the IS-IS draft. I’ve also attached my editorial comments.

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


[Lsr] 答复: WG Adoption poll for draft-acee-lsr-ospf-yang-augmentation-v1-01

2019-10-05 Thread Lizhenbin


yes/support.

Best Regards,
Zhenbin(Robin)



On Oct 2, 2019, 2:28 PM -0700, Christian Hopps , wrote:
Hi Folks,

This begins a 2 week WG adoption poll for the following:

https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-yang-augmentation-v1/

Please send any comments to the list by Wednesday Oct 16th, 2019.

Thanks,
Chris.

___
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


[Lsr] 答复: WG Adoption Poll for draft-acee-lsr-ospfv3-extended-lsa-yang-06

2019-10-05 Thread Lizhenbin
yes/support

Best Regards,
Zhenbin (Robin)



On Oct 2, 2019, 2:27 PM -0700, Christian Hopps , wrote:
Hi Folks,

This begins a 2 week WG adoption poll for the following:

https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-extended-lsa-yang/

Please send any comments to the list by Wednesday Oct 16th, 2019.

Thanks,
Chris.

___
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


[Lsr] 答复: Working Group Adoption Call for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

2019-05-13 Thread Lizhenbin
I support the adoption. There are also implementations on the drafts. The 
adoption will be very helpful on SRv6 work.





Best Regards,

Zhenbin (Robin)








发件人: Lsr [lsr-boun...@ietf.org] 代表 Acee Lindem (acee) [a...@cisco.com]
发送时间: 2019年5月9日 21:49
收件人: lsr@ietf.org
主题: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support Routing 
over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

We been holding off WG adoption until the base SRv6 draft was adopted in 
SPRING. Now that 
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ 
has been adopted, we are starting a two week LSR WG adoption poll for the 
subject draft. Please register your support or objection prior to 12:00 AM UTC, 
on May 25th, 2019.

For your convenience, here is a URL for the draft:

https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/

Thanks,
Acee

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


Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

2019-02-18 Thread Lizhenbin
Yes/support.

Best Regards,
Zhenbin (Robin)


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Wednesday, February 13, 2019 5:26 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee

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


Re: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

2019-02-13 Thread Lizhenbin
Hi Chris & Acee,
I have explained my concerns the previous mails. In order to avoid unnecessary 
overlap, I supports the adoption of the drafts like follows:
- both drafts are adopted at the same time keeping draft-li-dynamic-flooding 
focus on the centralized solution and draft-cc-lsr-flooding-reduction on the 
distributed solution.
- draft-li-dynamic-flooding can keep on refining the centralized solution 
without mentioning distributed solutions.
- draft-cc-lsr-flooding-reduction can keep on refining the distributed 
solutions. For the signaling which can be shared by the two modes, the draft 
can indicate the distributed solutions reuse the signaling defined in 
draft-li-dynamic-flooding without defining new signaling. 
- both drafts change the draft names to reflect different solutions without 
causing confusion.


Thanks & Regards,
Zhenbin (Robin)



-邮件原件-
发件人: Christian Hopps [mailto:cho...@chopps.org]
发送时间: 2019年2月11日 18:45
收件人: lsr@ietf.org
抄送: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
主题: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.


Hi Folks,

We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.

The aim of this document is to describe the problem space and standardize a
way to signal dynamic flooding information. It does not standardize any
specific algorithm for flooding topology creation.

Authors please respond indicating if you are aware of any IPR related to
this work.

We also have another draft (draft-cc-lsr-flooding-reduction-01) that started
as a distributed flooding topology algorithm and morphed into that plus
competing ideas on signaling of flooding topology information. The intent
after adoption of draft-li-lsr-dynamic-flooding-02 is two-fold. One, the WG
can discuss adding any signaling ideas from this work to the adopted
signaling draft (with proper attribution given as appropriate), and two, for
the authors of draft-cc-lsr-flooding-reduction-01 to publish a new document
without the signaling portion and instead focus on their flooding topology
algorithm. This new focused document can be considered in parallel along
with the other algorithm work that has been proposed.

Flooding topology creation is seen as a hard problem for which we don't
expect a one-size-fits-all solution. Taking the steps outlined above will
help us move forward on the solutions.

Thanks,
Chris & Acee.
LSR WG Chairs.

___
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


[Lsr] 答复: Moving Forward [Re: Flooding Reduction Draft Redux]

2019-02-04 Thread Lizhenbin
Hi Chris & Acee,

> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and 
> drfat-li-dynamic-flooding-isis
>   published centralized solution.
>
> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
> draft-cc-ospf-flooding-reduction
>   published distributed solution

Thanks for your summary we know the fact that at beginning there was not any 
confliction between the two drafts.


> - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
>   - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
>   - Does not specify distributed algorithm only how to indicate one in use, 
> small change.

I do not think it is a small change. It is to introduced the totally new 
solution which was already defined in the other existing draft. It is not an 
appropariate behavior and the root cause of the potential confliction. 


I also think the distributed solution includes more than the algorithms defined 
in the draft-cc-lsr-flooding-reduction-00  and the overlapped signallings  
defined in the draft-cc-lsr-flooding-reduction-00/draft-li-dynamic-flooding-03. 
Since the co-authors could not merge the draft, though the existing suggestion 
proposed is try to separate the two drafts, there is still overlap on the 
distributed solution between the two drafts which may be the source of 
continuous confliction in the future. In order to avoid the situation I would 
like to propose following suggestions:
- move both the two drafts forward in parallel keeping 
draft-li-dynamic-flooding focus on the centralized solution and 
draft-cc-lsr-flooding-reduction on the distributed solution.
- draft-li-dynamic-flooding can keep on refining the centralized solution 
without mentioning distibuted solutions.
- draft-cc-lsr-flooding-reduction can keep on refining the distributed 
solutions. For the sigalling which can be shared by the two modes, the draft 
can indicate the distributed solutions reuse the signalling defined in 
draft-li-dynamic-flooding without defining new signalling. 
- both drafts change the draft names to reflect different solutions without 
causing confusion.


Thanks & Regards,
Zhenbin (Robin)

  




发件人: Lsr [lsr-boun...@ietf.org] 代表 Christian Hopps [cho...@chopps.org]
发送时间: 2019年2月1日 20:25
收件人: lsr@ietf.org
抄送: cho...@chopps.org
主题: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Summary of where we are at with dynamic flooding reduction:

 - We have a well written original work that came first and described the 
problems as well as a TLVs to allow for a centralized solution 
(draft-li-dyanmic-flooding). We do not need to standardize the centralized 
algorithm.

 - A small change to this work allowed for distributed algorithms and for 
outside work on distributed algorithms to continue in parallel.

 - We have another original work that started primarily as a distributed 
algorithm
   (draft-cc-ospf-flooding-reduction)

 - Finally we also have:
   - Cross-pollination of ideas.
   - Failed attempts at merging.
   - An authors list "Arms-Race".

Moving forward:

- During IETF 103 I proposed we have no conflict if we:

   1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
   2) have authors of draft-cc-lsr-flooding-reduction work on a distributed 
algorithm as they started with.

- Acee agreed during the meeting (as chair) that this was the best way forward. 
We had some agreement form the floor as well.

- Any good ideas regarding the distribution of a centralized topology can be 
debated and added (with appropriate attribution) to the base document after we 
adopt one.

- This is what happens when we adopt a document as WG work, we work on it.

- The original authors of the distributed solution can continue to work on 
their distributed algorithm in a separate document which would also need 
standardization.

Does anyone see a serious problem with this path forward?

Thanks,
Chris & Acee.
LSR Chairs.

Christian Hopps  writes:

> We've had the authors of the individual conflicting drafts take a shot at 
> merging their work.
>
>This has failed.
>
> Here is the full history (which I also summarized during IETF103 as well). I 
> will send a second email discussing this.
>
> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and 
> drfat-li-dynamic-flooding-isis
>   published centralized solution.
>
> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
> draft-cc-ospf-flooding-reduction
>   published distributed solution.
>   - mention of centralized solution asserting it is not good choice.
>
> - IETF 101 (Mar 2018)
>   - Video: 
> https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS
>   - Minutes: 
> https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00
>   - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
> - Generally well received.
>   - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
> - Serious problems immediately found during 

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

2018-07-05 Thread Lizhenbin
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

Hi Yunan, Shunwan, and Zhenbin, 

What are the advantages of inventing a new protocol over just using 
YANG and NETCONF, RESTCONF, or gNMI? 
[Robin] In the draft we simply mention the difference between NMP and 
protocols you mentioned for the management plane. Though there is maybe some 
overlap between the two types of protocols, the protocols you mentioned is not 
enough for monitoring the control protocol. For example, would we like to use 
YANG and NETCONF, RESTCONF, or gNMI to export the packets of control protocols 
such as update message of BGP and/or ISIS PDU, etc. for the purpose of 
monitoring?


Operators and vendors are doing this anyway. A second alternative would 
be to listen passively in IS-IS (or OSPF for that matter). Why would anyone 
want this? 
[Robin] In fact we tried the method you proposed. From our point of 
view, the basic design principle should be that the monitoring entity should be 
decoupled from the monitored entity. This is to avoid following cases:
1. The failure of operation of the control protocol may affect the 
monitoring at the same time.
2. The limitation of the control protocol will also have effect on the 
monitoring. For example, for the method of listening passively, if there are 
multiple hops between the listener and the network devices, it has to set up a 
tunnel as the virtual link for direct connection. But the TCP-based monitoring 
protocol need not care about it. 


As far as where it belongs, we have a rather full agenda in LSR so I 
don't think we want to devote time to it there at IETF 102.  
[Robin] Though the WG the draft should belong to is not determined yet, 
we think the work belongs to OPS area and send the notice to GROW WG 

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

2018-07-05 Thread Lizhenbin
Hi Acee,
It is not described clearly in the draft that reusing BMP is also a possible 
option for monitoring IGP. We will refine the draft. 
Expect to have more discussion with you in IETF 102.


Thanks,
Robin





-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Wednesday, July 04, 2018 12:09 AM
To: Lizhenbin ; g...@ietf.org; ops...@ietf.org
Cc: Guyunan (Yunan Gu, IP Technology Research Dept. NW) ; 
lsr@ietf.org; rt...@ietf.org
Subject: Re: [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

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

Hi Yunan, Shunwan, and Zhenbin, 

What are the advantages of inventing a new protocol over just using YANG 
and NETCONF, RESTCONF, or gNMI? 
[Robin] In the draft we simply mention the difference between NMP and 
protocols you mentioned for the management plane. Though there is maybe some 
overlap between the two types of protocols, the protocols you mentioned is not 
enough for monitoring the control protocol. For example, would we like to use 
YANG and NETCONF, RESTCONF, or gNMI to export the packets of control protocols 
such as update message of BGP and/or ISIS PDU, etc. for the purpose of 
monitoring?


Operators and vendors are doing this anyway. A second alternative would be 
to listen passively in IS-IS (or OSPF for that matter). Why would anyone want 
this? 
[Robin] In fact we tried the method you proposed. From our point of view, 
the basic design principle should be that the monitoring entity should be 
decoupled from the monitored entity. This is to avoid following cases:
1. The failure of operation of the control protocol may affect the 
monitoring at the same time.
2. The limitation of the control protocol will also have effect on the 
monitoring. For example, for the method of listening passively, if there are 
multiple hops between the listener and the network devices, it has to set up a 
tunnel as the virtual link for direct connection. But the TCP-based monitoring 
protocol need not care about it. 


As far as where it belongs, we have a rather full agenda in LSR so I don't 
think we want to devote time to it there at IETF 102.  
[Robin] Though the WG the draft should belong to is not determined yet, we 
think the work belongs to OPS area and send the notice to GROW WG and OPSAWG. 
We also applied for the presentation in the two WGs. We should have copied the 
notice to the related WGs of RTG area. So the LSR WG and RTGWG WG mailing list 
are added. More comments and suggestions are welcome.

Thanks,
Acee



On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology 
Research Dept. NW)"  
wrote:

Dear GROW & OPSAWG WGs,

We have proposed a Network Monitoring Protocol (NMP) for the control 
plane OAM. NMP for ISIS is illustrated in this draft to showcase the benefit 
and operation of NMP. Yet, we haven't decided which WG it belongs to. 

   
Comments and suggestions are very welcome! 

Thank you!


Yunan Gu
Huawei Technologies Co. Ltd

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: 2018年7月2日 20:07
To: Zhuangshunwan ; Lizhenbin 
; Guyunan (Yunan Gu, IP Technology Research Dept. NW) 

Subject: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt


A new version of I-D, draft-gu-network-mornitoring-protol-00.txt
has been successfully submitted by Yunan Gu and posted to the IETF 
repository.

Name:   draft-gu-network-mornitoring-protol
Revision:   00
Title:  Network Monitoring Protocol (NMP)
Document date:  2018-07-02
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/

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

2018-07-03 Thread Lizhenbin
Hi Randy,
Since BMP is promoted in GROW WG, the work has much similarity with BMP. So we 
applied for the presentation here.

Best Regards,
Robin



-Original Message-
From: Randy Bush [mailto:ra...@psg.com] 
Sent: Wednesday, July 04, 2018 2:46 AM
To: Acee Lindem (acee) 
Cc: Lizhenbin ; g...@ietf.org; ops...@ietf.org; 
lsr@ietf.org; rt...@ietf.org
Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

i am confused as why this is in grow.  it's protocol.

randy

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


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

2018-07-03 Thread Lizhenbin
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

Hi Yunan, Shunwan, and Zhenbin, 

What are the advantages of inventing a new protocol over just using YANG and 
NETCONF, RESTCONF, or gNMI? 
[Robin] In the draft we simply mention the difference between NMP and protocols 
you mentioned for the management plane. Though there is maybe some overlap 
between the two types of protocols, the protocols you mentioned is not enough 
for monitoring the control protocol. For example, would we like to use YANG and 
NETCONF, RESTCONF, or gNMI to export the packets of control protocols such as 
update message of BGP and/or ISIS PDU, etc. for the purpose of monitoring?


Operators and vendors are doing this anyway. A second alternative would be to 
listen passively in IS-IS (or OSPF for that matter). Why would anyone want 
this? 
[Robin] In fact we tried the method you proposed. From our point of view, the 
basic design principle should be that the monitoring entity should be decoupled 
from the monitored entity. This is to avoid following cases:
1. The failure of operation of the control protocol may affect the monitoring 
at the same time.
2. The limitation of the control protocol will also have effect on the 
monitoring. For example, for the method of listening passively, if there are 
multiple hops between the listener and the network devices, it has to set up a 
tunnel as the virtual link for direct connection. But the TCP-based monitoring 
protocol need not care about it. 


As far as where it belongs, we have a rather full agenda in LSR so I don't 
think we want to devote time to it there at IETF 102.  
[Robin] Though the WG the draft should belong to is not determined yet, we 
think the work belongs to OPS area and send the notice to GROW WG and OPSAWG. 
We also applied for the presentation in the two WGs. We should have copied the 
notice to the related WGs of RTG area. So the LSR WG and RTGWG WG mailing list 
are added. More comments and suggestions are welcome.

Thanks,
Acee



On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology 
Research Dept. NW)"  
wrote:

Dear GROW & OPSAWG WGs,

We have proposed a Network Monitoring Protocol (NMP) for the control plane 
OAM. NMP for ISIS is illustrated in this draft to showcase the benefit and 
operation of NMP. Yet, we haven't decided which WG it belongs to. 

   
Comments and suggestions are very welcome! 

Thank you!


Yunan Gu
Huawei Technologies Co. Ltd

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: 2018年7月2日 20:07
To: Zhuangshunwan ; Lizhenbin 
; Guyunan (Yunan Gu, IP Technology Research Dept. NW) 

Subject: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt


A new version of I-D, draft-gu-network-mornitoring-protol-00.txt
has been successfully submitted by Yunan Gu and posted to the IETF 
repository.

Name:   draft-gu-network-mornitoring-protol
Revision:   00
Title:  Network Monitoring Protocol (NMP)
Document date:  2018-07-02
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/internet-drafts/draft-gu-network-mornitoring-protol-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-gu-network-mornitoring-protol/
Htmlized:   
https://tools.ietf.org/html/draft-gu-network-mornitoring-protol-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gu-network-mornitoring-protol


Abstract:
   To enable automated network OAM (Operations, administration and
   management), the availability of network protocol running status
   information is a fundamental step.  In this document, a network
   monitoring protocol (NMP) is proposed to provision the information
   related to running status of IGP (Interior Gateway Protocol) and
   other control protocols.  It can facilitate the network
   troubleshooting of control protocols in a network domain.  Typical
   network issues are illustrated as the usecases of NMP for ISIS to
   showcase the necessity of NMP.  Then the operations and the message
   formats of NMP for ISIS are defined.  In this document ISIS is used
   as the illustration protocol, and the case of OSPF and other control
   protocols will be included in the future version.



  


 

[Lsr] 答复: LSR Working Group Last Call for "OSPFv3 Extensions for Segment Routing" - draft-ietf-ospf-ospfv3-segment-routing-extensions-13

2018-05-24 Thread Lizhenbin

Support.

Best Regards,
Zhenbin (Robin)


On 23/05/18 17:03 , Acee Lindem (acee) wrote:
> This begins an LSR WG last call for the subject draft. Please send your
>
> comments to this list prior to 12:00 AM GMT, June 7th, 2018.
>
> Thanks,
>
> Acee and Chris
>
>
>
> ___
> 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Working Group Last Call on "Signaling MSD (Maximum SID Depth) using OSPF"

2018-05-14 Thread Lizhenbin
Support


Best Regards,
Zhenbin (Robin)



From: Lsr > On Behalf Of Acee 
Lindem (acee)
Sent: 10 May 2018 20:50
To: lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call on "Signaling MSD (Maximum SID 
Depth) using OSPF"

All,

Note that a new version,  -12, was posted today.

Thanks,
Acee

From: Lsr > on behalf of Acee 
Lindem >
Date: Tuesday, May 8, 2018 at 11:48 AM
To: "lsr@ietf.org" >
Subject: [Lsr] Working Group Last Call on "Signaling MSD (Maximum SID Depth) 
using OSPF"

We’ve had consensus on the scope and definition of MSD since the Chicago IETF. 
Since that time, this document has evolved and been improved. It is now ready 
for Working Group Last Call. Please post your objections or support before 
12:00 AM on Wednesday, May 23rd, 2018. For your convenience, here is a URL 
link: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/

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