[Lsr] 答复: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Lizhenbin]

Hi All,
I support the WGLC of the draft as the co-author. After several rounds of 
refining, the draft is stable and well-written. It is the time for WGLC.

Best Regards,
Zhenbin (Robin)



-邮件原件-
发件人: Lsr  代表 Acee Lindem
发送时间: 2024年1月9日 6:50
收件人: Lsr 
主题: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology 
(MT) for Segment Routing based Network Resource Partition (NRP)" - 
draft-ietf-lsr-isis-sr-vtn-mt-06

This begins a two week LSR Working Group last call for the “Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)”. Please express your support or objection prior to Tuesday, January 
23rd, 2024. 

Thanks,
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

[Lsr] 答复: IPR Poll for WG Last Call of "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)"

[Lizhenbin]

Hi All,

No, I'm not aware of any IPR regarding this document.

Best regards,
Zhenbin (Robin)



-邮件原件-
发件人: Acee Lindem  
发送时间: 2024年1月9日 6:43
收件人: draft-ietf-lsr-isis-sr-vtn...@ietf.org
抄送: Lsr 
主题: IPR Poll for WG Last Call of "Applicability of IS-IS Multi-Topology (MT) 
for Segment Routing based Network Resource Partition (NRP)"

Co-Authors, 

Are you aware of any IPR that applies to draft-ietf-lsr-isis-sr-vtn-mt-06.
If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3979, 4879, 3669 and 5378 for more details).
 
If you are listed as a document author or contributor please respond to this 
email regardless of whether or not you are aware of any relevant IPR. *The 
response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a response has 
been received from each author and contributor.
 
If you are on the LSR WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not been disclosed in conformance with IETF rules.

Thanks,
Acee

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

Re: [Lsr] AD review of draft-ietf-lsr-ospfv3-srv6-extensions-09

[Lizhenbin]

Hi John,
Thanks very much for your review. We will check the comments and reply soon.


Best Regards,
Zhenbin (Robin)





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

发件人：John Scudder 
收件人：draft-ietf-lsr-ospfv3-srv6-extensions 
;lsr 
抄 送：Huzhibo ;Lizhenbin ;Ketan 
Talaulikar ;Peter Psenak 
时 间：2023-04-21 20:28:29
主 题：AD review of draft-ietf-lsr-ospfv3-srv6-extensions-09

Hi Authors, WG,

Thanks for this spec.

I’ve supplied my questions and comments in the form of an edited copy of the 
draft. Minor editorial suggestions I’ve made in place without further comment, 
more substantive questions and comments are done in-line and prefixed with 
“jgs:”. You can use your favorite diff tool to review them; I’ve attached the 
iddiff output for your convenience if you’d like to use it. I’ve also pasted a 
traditional diff below in case you want to use it for in-line reply.

Thanks,

—John

--- draft-ietf-lsr-ospfv3-srv6-extensions-09.txt2023-04-21 
11:29:59.0 -0400
+++ draft-ietf-lsr-ospfv3-srv6-extensions-09-jgs-comments.txt   2023-04-21 
14:21:35.0 -0400
@@ -116,9 +116,9 @@

 1.  Introduction

-   Segment Routing (SR) architecture [RFC8402] specifies how a node can
-   steer a packet through an ordered list of instructions, called
-   segments.  These segments are identified through Segment Identifiers
+   The Segment Routing (SR) architecture [RFC8402] specifies how a node can
+   steer a packet using an ordered list of instructions, called
+   segments.  These segments are identified using Segment Identifiers
(SIDs).

Segment Routing can be instantiated on the IPv6 data plane through
@@ -144,7 +144,7 @@
1.  An SRv6 Capabilities TLV to advertise the SRv6 features and SRH
operations supported by an OSPFv3 router

-   2.  Several sub-TLVs are defined to advertise various SRv6 Maximum
+   2.  Several sub-TLVs to advertise various SRv6 Maximum
SID Depths.

3.  An SRv6 Locator TLV using an SRv6 Locator Link-State
@@ -179,6 +179,9 @@
be advertised by an SRv6-enabled router.

This TLV SHOULD be advertised only once in the OSPFv3 Router
+---
+jgs: What's the reason the above is a SHOULD and not a MUST?
+---
Information LSA.  When multiple SRv6 Capabilities TLVs are received
from a given router, the receiver MUST use the first occurrence of
the TLV in the OSPFv3 Router Information LSA.  If the SRv6
@@ -194,6 +197,10 @@
defined flooding scopes (link, area, or Autonomous System (AS)).  For
the purpose of SRv6 Capabilities TLV advertisement, area-scoped
flooding is REQUIRED.
+---
+jgs: I infer that link and AS scoped flooding is OPTIONAL. While this
+is implicit, might it be worth adding something to that effect?
+---

The format of OSPFv3 SRv6 Capabilities TLV is shown below:

@@ -208,6 +215,14 @@
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: SRv6 Capabilities TLV
+---
+jgs: In this and all subsequent figures, might it be worth filling in
+the type value in the figure, as in "Type = 20" in this case? FWIW I
+was first prompted to think about this by your Figure 3, where you
+embed the literal "1" for the U-bit instead of just relying on body
+text to tell the reader how to set it. ISTM if it's worth embedding one
+constant in the figure, it's probably worth doing so whenever feasible.
+---

Where:

@@ -245,6 +260,12 @@

The SRv6 Capabilities TLV may contain optional Sub-TLVs.  No Sub-TLVs
are defined in this specification.
+---
+jgs: Thank you for setting up registry creation for this flags field.
+However, I noticed that the registry says the O-flag has value 0x0001,
+whereas in the diagram you show it as having value 0x4000. Please
+correct one or the other, to be consistent.
+---

 3.  Advertisement of Supported Algorithms

@@ -254,7 +275,7 @@
 4.  Advertisement of Maximum SRv6 SID Depths

An SRv6-enabled router may have different capabilities and limits
-   related to SRH processing and this needs to be advertised to other
+   related to SRH processing and these need to be advertised to other
OSPFv3 routers in the SRv6 domain.

[RFC8476] defines the means to advertise node and link specific
@@ -269,6 +290,10 @@
OSPFv3.  These MSD Types are allocated under the IGP MSD Types
registry maintained by IANA that are shared by IS-IS and OSPF.  They
are described below:
+---
+jgs: Please update the reference for srv6-extensions throughout, to
+refer to [RFC9352].
+---



@@ -310,8 +335,8 @@
 4.4.  Maximum End D MSD Type

The Maximum End D MSD Type specifies the maximum number of SIDs
-   present in an SRH when performing decapsulation.  These include, but
-   not limited to, End.DX6, End.DT4, End.DT46, End with USD, End.X with
+   present in an SRH when performing decapsulation.  These include, but are
+   not limited to, End.DX6, End.DT4, End.DT46, End with USD, a

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Lizhenbin]

Hi All,
I support to publish the draft as the co-author. It has been stable and well 
written.

Best Regards,
Zhenbin (Robin)






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

发件人：Acee Lindem (acee) 
收件人：lsr 
抄 送：draft-ietf-lsr-ospfv3-srv6-extensions 

时 间：2022-07-30 01:17:42
主 题：Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

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


Thanks,
Acee & Chris


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

Re: [Lsr] IPR Poll Coincident with the Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

[Lizhenbin]

Hi All,

I am not aware of any undisclosed IPR that applies to this draft.



Thanks,
Zhenbin (Robin)





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

发件人：Acee Lindem (acee) 
收件人：Lizhenbin 
抄 送：lsr ;draft-ietf-lsr-ospfv3-srv6 

时 间：2022-08-06 03:02:10
主 题：Re: IPR Poll Coincident with the Working Group Last Call for "OSPFv3 
Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

Hi Robin,
I’m only missing your IPR declaration.
Thanks,
Acee

From: Huzhibo 
Date: Wednesday, August 3, 2022 at 11:08 PM
To: Acee Lindem , "draft-ietf-lsr-ospfv3-s...@ietf.org" 

Cc: lsr 
Subject: RE: IPR Poll Coincident with the Working Group Last Call for "OSPFv3 
Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt


Hi Acee,



I am not aware of any undisclosed IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt



thanks,

Zhibo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:15 AM
To: draft-ietf-lsr-ospfv3-s...@ietf.org
Cc: lsr 
Subject: [Lsr] IPR Poll Coincident with the Working Group Last Call for "OSPFv3 
Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

Co-authors,

Are you aware of any IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee & Chris


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

Re: [Lsr] FW: IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-lsr-ospfv3-srv6-extensions

[Lizhenbin]

Hi Acee,
Yes. I asked them to check the consistency with the IPR claims of SRV6 ISIS and 
if necessary disclose as the IETF rules.


Best Regards,
Robin





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

发件人：Acee Lindem (acee) 
收件人：Zhenbin Lin (zhenblin) 
抄 送：lsr 
时 间：2022-08-11 22:51:11
主 题：[Lsr] FW: IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR 
related to draft-ietf-lsr-ospfv3-srv6-extensions

Hey Robin,

Haven't received your WG last call IPR poll response yet - I guess you were 
waiting for this to be posted?

Thanks,
Acee

On 8/11/22, 10:47 AM, "Lsr on behalf of IETF Secretariat" 
 wrote:

Dear Zhenbin Li, Zhibo Hu, Ketan Talaulikar, Peter Psenak:


An IPR disclosure that pertains to your Internet-Draft entitled "OSPFv3
Extensions for SRv6" (draft-ietf-lsr-ospfv3-srv6-extensions) was submitted 
to
the IETF Secretariat on 2022-08-10 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures" (/ipr/5785/history/). The title of
the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR
related to draft-ietf-lsr-ospfv3-srv6-extensions"


Thank you

IETF Secretariat


___
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] Status of draft-ietf-lsr-ospv3-srv6-extensions

[Lizhenbin]

Hi Sue,
Sorry for the late response. Thanks very much for your reminding. We co-authors 
are updating the draft and will refresh it soon.
We will try to move it to WGLC in the IETF114. For the issue of moving BGP-LS 
without OSPFv3, I am not experienced enough to reply. Wish to learn the ADs and 
other's suggestion.


Best Regards,
Robin








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

发件人：Susan Hares 
收件人：lsr 
抄 送：draft-ietf-lsr-ospfv3-srv6-extensions 

时 间：2022-06-07 08:31:09
主 题：[Lsr] Status of draft-ietf-lsr-ospv3-srv6-extensions

What is the status of draft-ietf-lsr-ospfv3-srv6-extensions?  Is this draft 
ready for WG LC?  Do you anticipate WG LC soon?

This draft expired on 5/23/2022. It has not be updated since 5/23.   Is this 
just an oversight for the authors?

draft-ietf-idr-bgpls-srv6-ext-09 references 
draft-ietf-lsr-ospfv3-srv6-extensions, and cannot go forward until the status 
of this draft is resolved.

Should IDR move draft-ietf-idr-bgpls-srv6-ext-09.txt forward without 
draft-ietf-lsr-ospfv3-srv6-extensions?

Sue Hares
IDR Shepherd and chair
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts

[Lizhenbin]

Hi All,

I support the adoption of the two SRv6 YANG drafts.


Best Regards,
Zhenbin (Robin)




-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Yingzhen Qu
Sent: Friday, July 23, 2021 12:39 PM
To: Christian Hopps 
Cc: lsr@ietf.org; lsr-...@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts

I support the adoption of both drafts as a co-author.

I’m not aware of any IPR that applies to these drafts.

Thanks,
Yingzhen

> On Jul 22, 2021, at 3:48 AM, Christian Hopps  wrote:
> 
> 
> Hi Folks,
> 
> This begins a 3 week WG Adoption Call for the following related YANG drafts:
> 
> https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/
> https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/
> 
> Please indicate your support or objections by August 12th, 2021
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to these drafts.
> 
> 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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Lizhenbin]

Hi All,

I do not support the adoption. I am concerned that we are in the danger of 
re-inventing IGP multi-topology with Flex-Algo. I do not think it is necessary. 
If we have the requirements, we can either directly use the multi-topology or 
extend Flex-Algo without change its principle.


Best Regards,
Zhenbin (Robin)




-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

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

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

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[Lizhenbin]

Hi All,
I support the WG adoption.

Best Regards,
Zhenbin (Robin)




--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com
发件人：Christian Hopps 
收件人：lsr 
抄 送：lsr-ads ;Christian Hopps 
;draft-acee-lsr-ospf-transport-instance 

时 间：2021-05-02 16:47:33
主 题：[Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02


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

https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/

Please indicate your support or objection by May 16th, 2021.

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

Historical Note: The original OSPF transport instance document was adopted by 
the OSPF WG back in 2009, it was last updated in 2014, and then revived as an 
individual submission to LSR in Sep 2020. :)

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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Lizhenbin]

Hi All,
I support the WG adoption.

Best Regards,
Zhenbin (Robin)




--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com
发件人：Acee Lindem (acee) 
收件人：lsr 
抄 送：draft-hegde-lsr-flex-algo-bw-con 
时 间：2021-05-13 06:14:57
主 题：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
Please indicate your support or objection by May 27th, 2021.
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.
Thanks,
Chris and Acee

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

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Lizhenbin]

Hi Robert,
The draft tries to propose a lightweight isolated flooding solution capering 
the existing IGP multi-instance solutions. As the suggestion proposed by Acee, 
it should take more work. Now it focuses on ISIS firstly. Then OSPF may be 
taken into account depending on the research result of ISIS.

Best Regards,
Robin




From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, March 11, 2021 6:40 AM
To: Aijun Wang ; wangyali ; 
Tianran Zhou 
Cc: Les Ginsberg (ginsberg) ; Tony Li ; 
Gyan Mishra ; lsr 
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Dear Authors,

Looking at the bigger picture here I have two simple questions.

Q1: Do you plan to submit draft-x-lsr-ospf-mfi-00.txt any time soon ?

Q2: If No - why not ?
   If Yes - how would you choose to use either  
draft-x-lsr-ospf-mfi-00.txt or 
https://tools.ietf.org/html/draft-ietf-ospf-transport-instance-11 for your non
   routing application (opaque to routing) information flooding ?

Extra bonus question - It seems that the very same application (ifit) is 
proposed to be distributed using BGP too 
(https://tools.ietf.org/html/draft-wang-idr-bgp-ifit-capabilities-01). Can you 
provide pros and cons comparison of using link state flooding vs p2mp BGP model 
to distribute this type of data ?

Hint: Please do not respond .. Oh this is yet another way ... That is not a 
valid answer.

Many thx,
Robert.

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

[Lsr] Regarding the scalable network slicing solutions

[Lizhenbin]

Hi Tarek,
The draft draft-dong-teas-enhanced-vpn-vtn-scalability describes the more 
scalable solutions for network slicing. It is apparent that it has to introduce 
the new encapsulation using MPLS and/or IPv6 as the data plane which propose 
challenges for the hardware implementation. It has been discussed for a long 
time how many network slices the customer may need for a specific network. It 
seems now tens of slices can satisfy many requirements and the SR-based VTN 
solution is available quickly reusing the SR data plane. There should be 
trade-off.


Best Regards,
Zhenbin (Robin)
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Lizhenbin]

Hi All,
I support the adoption as the co-author. I believe MT can play an important 
role to build SR-based VTN and the current RFCs does not cover the topic. The 
draft will be an useful informational document.


Best Regards,
Zhenbin (Robin)



--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com
发件人：Acee Lindem (acee) 
收件人：lsr 
时 间：2021-03-03 07:28:17
主 题：[Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment 
Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.
This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.
Thanks,
Acee

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

Re: [Lsr] More responses required [Re: WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-03]

[Lizhenbin]

Hi All,
I support the adoption.

Best Regards,
Zhenbin (Robin)



--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com
发件人：Christian Hopps 
收件人：lsr 
抄 送：lsr-chairs ;Christian Hopps 
时 间：2021-01-22 21:13:22
主 题：[Lsr] More responses required [Re: WG adoption call for 
draft-acee-lsr-isis-yang-augmentation-v1-03]

Hi Folks, so far we've received only a single feedback on adopting this 
document, can we get a few more responses form the WG?

Thanks,
Chris.

> On Jan 5, 2021, at 4:19 AM, Christian Hopps < 
> cho...@chopps.org> wrote:
>
> Signed PGP part
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/
>
> Please indicate your support or objection by January 19th, 2021.
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Thanks,
> Chris.
>
>


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

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

[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

[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-

> ifit/

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

[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

[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

[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

[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

[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

[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

[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&id=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.

[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] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Lizhenbin]

Hi Chris,
1. I have doubt about "The aim of this document is to describe the problem 
space and standardize a way to signal dynamic flooding information.". Does the 
aim mean the draft describes the problem space and standardize the way for the 
centralized solution or mean the draft will standardize the way used for both 
the centralized solutions and the distributed solutions?
2. I explained in the previous mail 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. For example, 
it may define the standardized procedures for the distributed solutions. If 
there is such part, is it defined by draft-li-lsr-dynamic-flooding-02 or 
draft-cc-lsr-flooding-reduction?

I hope you could clarify the above issues firstly for the adoption.


Thanks & Regards,
Zhenbin (Robin) 





发件人: Lsr [lsr-boun...@ietf.org] 代表 Christian Hopps [cho...@chopps.org]
发送时间: 2019年2月11日 18:44
收件人: 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] 答复: Moving Forward [Re: Flooding Reduction Draft Redux]

[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&list=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

[Lizhenbin]

Hi Acee and Randy,
We do not think NMP is a competitive solutions. We also do not think NMP can 
solve all issues. From these point of view we are same with you. Similarly I do 
not think Yang models can solve all issues.
I would also like to propose following draft for your reference which trigger 
us to move forward for better network maintenance with multiple tools in which 
gRPC/NETCOF and NMP/BMP may play different roles:
https://datatracker.ietf.org/doc/draft-song-ntf/


Best Regards,
Robin





-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Friday, July 06, 2018 6:04 AM
To: Lizhenbin ; Jeff Tantsura ; 
Acee Lindem (acee) ; g...@ietf.org; 
ops...@ietf.org
Cc: lsr@ietf.org; rt...@ietf.org
Subject: Re: [GROW] [Lsr] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

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. 

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 Researc

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

[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 a

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

[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: 

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

[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

[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

[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"

[Lizhenbin]

Support


Best Regards,
Zhenbin (Robin)



From: Lsr mailto:lsr-boun...@ietf.org>> 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 mailto:lsr-boun...@ietf.org>> on behalf of Acee 
Lindem mailto:a...@cisco.com>>
Date: Tuesday, May 8, 2018 at 11:48 AM
To: "lsr@ietf.org" mailto: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

Re: [Lsr] WG Last Call for draft-ietf-isis-segment-routing-extensions-16

[Lizhenbin]

Support.

Best Regards,
Zhenbin (Robin)



-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Monday, April 23, 2018 10:03 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
Subject: [Lsr] WG Last Call for draft-ietf-isis-segment-routing-extensions-16

Hi Folks,

We are starting a new 2 week WG last call on

  https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/

as there have (*) been some changes to the document since our last WG last call 
last year. Here's the diff.

https://www.ietf.org/rfcdiff?url1=draft-ietf-isis-segment-routing-extensions-12&url2=draft-ietf-isis-segment-routing-extensions-16

Will end Monday May 7th.

Thanks,
Chris.

(*) contrary to what you may have heard from folks at the mic in London. :)

___
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