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

2020-07-20 Thread Christian Hopps
So full speed ahead and ignoring the views expressed in the LSR WG? This is not 
a recipe for success if you are basing your implementation on using LSR 
protocols.

Thanks,
Chris.
[As WG member]

> On Jul 19, 2020, at 9:30 PM, qinfengwei  wrote:
> 
> Hi,
>   IFIT Capability Advertisement accurately tracks the urgent requirements 
> and real challenges when IFIT implementation.
>   Right now, the IFIT test has been performed and is under 
> implementation. We found that signaling Node IFIT capability to ingress nodes 
> is indeed helpful for determining whether IFIT header and data fields could 
> be encapsulated in packets.
> 
> 
> 
> Thanks,
> Fengwei Qin
> 
> -邮件原件-
> 发件人: wangyali [mailto:wangyal...@huawei.com]
> 发送时间: 2020年7月16日 23:20
> 收件人: 'lsr@ietf.org'
> 主题: 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 ; wangyali ; 
> Huanan Chen ; Liumin (Lucy) 
> ; Ran Pang ; Liumin (Lucy) 
> 
> 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/
> Htmlized:   
> https://tools.ietf.org/html/draft-wang-lsr-igp-extensions-ifit-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-igp-extensions-ifit
> 
> 
> Abstract:
>   This document extends Node and Link Attribute TLVs to Interior
>   Gateway Protocols (IGP) to advertise supported In-situ Flow
>   Information Telemetry (IFIT) capabilities at node and/or link
>   granularity.  An ingress router cannot insert IFIT-Data-Fields for
>   packets going into a path unless an egress router has indicated via
>   signaling that it has the capability to process IFIT-Data-Fields.  In
>   addition, such advertisements would be useful for ingress routers to
>   gather each router's IFIT capability for achieving the computation of
>   Traffic Engineering (TE) paths or loose TE paths that be able to
>   fulfill the visibility of on-path OAM data.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-07-17 Thread Tianran Zhou
There is no convincable reason why IGP can not.

Some suggestions are about Netconf.

But Yali showed Netconf can not meet the requirement.


Tianran

--
Sent from WeLink

发件人:Les Ginsberg (ginsberg) 
收件人:Lizhenbin ;lsr 
抄 送:wangyali 
时 间:2020-07-18 04:34:51
主 题:Re: [Lsr] New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt

Robin/Yali –
The argument here is circular.
You are saying “if the IGPs advertised ifit information/capability then it 
would be used”.
Sure.
But the question that was discussed three back was whether IGPs were the right 
vehicle to advertise this information or whether it should be done in other 
ways.
Please reread the thread: 
https://mailarchive.ietf.org/arch/browse/lsr/?gbt=1=5GdFCy7zg8eCIGvQZpmAbOtrTjQ
Les
From: Lizhenbin mailto:lizhen...@huawei.com>>
Sent: Friday, July 17, 2020 6:12 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: wangyali mailto:wangyal...@huawei.com>>
Subject: 答复: New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt

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<mailto:lsr-boun...@ietf.org>] 代表 wangyali 
[wangyal...@huawei.com<mailto:wangyal...@huawei.com>]
发送时间: 2020年7月17日 20:19
收件人: Les Ginsberg (ginsberg); lsr@ietf.org<mailto: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 mailto:wangyal...@huawei.com>>; 
lsr@ietf.org<mailto: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<mailto: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: <mailto:internet-dra...@ietf.org> 
> internet-d

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

2020-07-17 Thread Les Ginsberg (ginsberg)
Robin/Yali –

The argument here is circular.
You are saying “if the IGPs advertised ifit information/capability then it 
would be used”.

Sure.

But the question that was discussed three months back was whether IGPs were the 
right vehicle to advertise this information or whether it should be done in 
other ways.

Please reread the thread:  
https://mailarchive.ietf.org/arch/browse/lsr/?gbt=1=5GdFCy7zg8eCIGvQZpmAbOtrTjQ

   Les


From: Lizhenbin 
Sent: Friday, July 17, 2020 6:12 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: wangyali 
Subject: 答复: New Version Notification for 
draft-wang-lsr-igp-extensions-ifit-00.txt


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<mailto: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 mailto:wangyal...@huawei.com>>; 
lsr@ietf.org<mailto: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<mailto: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> 
> [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

>

>


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

2020-07-17 Thread wangyali
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<mailto: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> 
> [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-<https://www.ietf.org/internet-drafts/draft-wang-lsr-igp-extensions-ifit-00.txt>

> extensions-ifit-00.txt<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-<https://datatracker.ietf.org/doc/draft-wang-lsr-igp-extensions-ifit/>

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

> Htmlized:   
> https://tools.ietf.org/html/draft-wang-lsr-igp-extensions-ifit-00

> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-igp-<https://datatracker.ietf.org/doc/html/draft-wang-lsr-igp-extensions-ifit>

> extensio

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

2020-07-16 Thread Les Ginsberg (ginsberg)
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  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/

> Htmlized:   
> https://tools.ietf.org/html/draft-wang-lsr-igp-extensions-ifit-00

> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-igp-

> extensions-ifit

>

>

> Abstract:

>This document extends Node and Link Attribute TLVs to Interior

>Gateway Protocols (IGP) to advertise supported In-situ Flow

>Information Telemetry (IFIT) capabilities at node and/or link

>granularity.  An ingress router cannot insert IFIT-Data-Fields for

>packets going into a path unless an egress router has indicated via

>signaling that it has the capability to process IFIT-Data-Fields.  In

>addition, such advertisements would be useful for ingress routers to

>gather each router's IFIT capability for achieving the computation of

>Traffic Engineering (TE) paths or loose TE paths that be able to

>fulfill the visibility of on-path OAM data.

>

>

>

>

>

> Please note that it may take a couple of minutes from the time of submission

> until the htmlized version and diff are available at tools.ietf.org.

>

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