[Lsr] Requesting NOMCOM Feedback

[Acee Lindem (acee)]

NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC Board, 
and IETF Trust. We need more input from the community both on specific nominees 
and on over-arching topics regarding what the community wants from these 
specific groups and wants from its leadership in general. We need *your* input.

** Deadline for community feedback is Friday November 20. **

We've paid attention to discussions on the ietf list. Issues raised there have 
been brought up in interviews.

We've also asked questions of nominees based on feedback received, and based on 
the "Topics" that people said were important.
We're listening to you.

But most of the input to date has come from a few consistently vocal people. We 
need to hear from more of you.

I scheduled our office hours during the 2 weeks before next week's IETF, 
because IETF week is so busy. We have one more left (18:00-19:00 UTC November 
11). No-one but NomCom members showed up for our first 3. ☹ If there is demand 
for more office hours, I'll schedule them; but this really doesn't seem to be 
the preferred format for input.

Most input is coming in as either
- email to nomco...@ietf.org
- feedback on https://datatracker.ietf.org/nomcom/2020/feedback/
On the feedback page, the specific nominees are all listed at the top. General 
Topics are at the bottom.
We pay attention to all the comments we get through these channels.

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

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

[Aijun Wang]

Hi, Acee:
I have updated the draft according to the discussion with Peter on the list. 
The updated draft will be uploaded once the IETF repository reopen.
We define new TLV to contain the stub-link related information within OSPFv2/v3 
and ISIS respectively. The presentation will also align with it.

Together with the use case that described in Linda’s draft 
https://tools.ietf.org/html/draft-dunbar-lsr-5g-edge-compute-ospf-ext-01, we 
think this extension is necessary and should be considered within IGP.
Thanks in advance.

Aijun Wang
China Telecom

> On Nov 11, 2020, at 02:01, Acee Lindem (acee)  wrote:
> 
> Aijun, 
> 
> Speaking as WG member:
> 
> At least for OSPF, passive interfaces are not standardized in RFC 2328 or RFC 
> 5340. Hence, this purely a vendor concept. 
> Additionally, it is a property, albeit a vendor property, of a link and not a 
> prefix. It would be both inappropriate and profligate (considering the 
> scarcity) to allocate a prefix option for the purpose of identifying a 
> passive link associated with the prefix. Given your narrow use case of 
> identifying the edge of an IGP domain, it would certainly be better to 
> allocate a new TLV specifically for purpose and perhaps this doesn't belong 
> in the IGPs at all and should be something you propose solely for BGP-LS 
> consumption. 
> 
> Speaking as WG Co-chair:
> 
> Given strong objections to this draft in its current form, I don't really see 
> a good reason for present it at IETF 109. I believe it would just be a rehash 
> of the discuss that has already taken place.
> 
> Thanks,
> Acee
> 
> On 11/9/20, 4:44 AM, "Peter Psenak"  wrote:
> 
>Hi Aijun,
> 
>>On 09/11/2020 07:35, Aijun Wang wrote:
>> Hi, Peter:
>> 
>> Currently, the inter-AS link TLV is advertised within the Inter-AS-TE-LSA 
>> for OSPF and Inter-AS Reachability TLV for ISIS.
>> But I think these two places are not suitable for the stub-link information.
>> 
>> It seems that separating the stub-link information from the inter-as link 
>> information is better, because not all of the stub-links are inter-as link.
>> If so, can we put the newly defined Stub-Link TLV within the Router LSA for 
>> OSPF and make it one new top TLV for ISIS?
> 
>Router LSA does not have TLVs, you would have to add the data to 
>Extended Prefix Link TLV (RFC7684), or define a net top-level TLV under 
>the OSPFv2 Extended Link Opaque LSA.
> 
>For ISIS you don't have a choice really, you need to define a new 
>top-level TLV.
> 
>thanks,
>Peter
> 
>> 
>> 
>> Best Regards
>> 
>> Aijun Wang
>> China Telecom
>> 
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Saturday, November 7, 2020 1:56 AM
>> To: Aijun Wang 
>> Cc: Aijun Wang ; Acee Lindem (acee) 
>> ; lsr@i
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

[Acee Lindem (acee)]

Aijun, 

Speaking as WG member:

At least for OSPF, passive interfaces are not standardized in RFC 2328 or RFC 
5340. Hence, this purely a vendor concept. 
Additionally, it is a property, albeit a vendor property, of a link and not a 
prefix. It would be both inappropriate and profligate (considering the 
scarcity) to allocate a prefix option for the purpose of identifying a passive 
link associated with the prefix. Given your narrow use case of identifying the 
edge of an IGP domain, it would certainly be better to allocate a new TLV 
specifically for purpose and perhaps this doesn't belong in the IGPs at all and 
should be something you propose solely for BGP-LS consumption. 

Speaking as WG Co-chair:

Given strong objections to this draft in its current form, I don't really see a 
good reason for present it at IETF 109. I believe it would just be a rehash of 
the discuss that has already taken place.
 
Thanks,
Acee

On 11/9/20, 4:44 AM, "Peter Psenak"  wrote:

Hi Aijun,

On 09/11/2020 07:35, Aijun Wang wrote:
> Hi, Peter:
> 
> Currently, the inter-AS link TLV is advertised within the Inter-AS-TE-LSA 
for OSPF and Inter-AS Reachability TLV for ISIS.
> But I think these two places are not suitable for the stub-link 
information.
> 
> It seems that separating the stub-link information from the inter-as link 
information is better, because not all of the stub-links are inter-as link.
> If so, can we put the newly defined Stub-Link TLV within the Router LSA 
for OSPF and make it one new top TLV for ISIS?

Router LSA does not have TLVs, you would have to add the data to 
Extended Prefix Link TLV (RFC7684), or define a net top-level TLV under 
the OSPFv2 Extended Link Opaque LSA.

For ISIS you don't have a choice really, you need to define a new 
top-level TLV.

thanks,
Peter

> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Saturday, November 7, 2020 1:56 AM
> To: Aijun Wang 
> Cc: Aijun Wang ; Acee Lindem (acee) 
; lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt
> 
> Aijun,
> 
> On 05/11/2020 12:04, Aijun Wang wrote:
>> Hi, Peter:
>> Then how about defines one new top TLV to flood such information within 
the IGP? Fox example, Stub-Link TLV? If so, other characteristics associated 
with the Link can also be advertised accordingly.
> 
> yes, unless you can use or extend the existing inter-AS link 
advertisement.
> 
> thanks,
> Peter
> 
>>
>> If acceptable, we can forward this draft along this direction.
>>
>>
>> Aijun Wang
>> China Telecom
>>
>>> On Nov 5, 2020, at 17:15, Peter Psenak 
 wrote:
>>>
>>> Aijun,
>>>
>>> the point I was trying to make was that you should think of a similar 
mechanism for your use cases - e.g. define something that advertises the link 
without advertising the IS adjacency and not mess up with the prefix 
advertisement.
>>>
>>> thanks,
>>> Peter
>>>
 On 05/11/2020 10:09, Aijun Wang wrote:
 Hi, Peter:
 Yes, RFC 5392 is the OSPF corresponding part for the inter-AS TE 
solution. But using these existing solutions has some limitation in deployment, 
as I explained in 
https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/.
 And, in some situations, not all of the passive interfaces are 
connected with another AS, then flag these interfaces using RFC 5316 or RFC 
5392 is not appropriate.
 Do you agree?
 Best Regards
 Aijun Wang
 China Telecom
 -Original Message-
 From: ppse...@cisco.com [mailto:ppse...@cisco.com]
 Sent: Thursday, November 5, 2020 4:26 PM
 To: Aijun Wang ; 'Acee Lindem (acee)'
 ; 'Aijun Wang' 
 Cc: lsr@ietf.org
 Subject: Re: [Lsr] FW: New Version Notification for
 draft-wang-lsr-passive-interface-attribute-04.txt
 Hi Aijun,
 please look at rfc5316, ISIS already have a way to advertise inter-AS 
link without forming an adjacency.
 thanks,
 Peter
> On 05/11/2020 02:15, Aijun Wang wrote:
> Hi, Acee:
>
> Thanks for this comments.
> The consideration for the position of flagging the passive interface 
have been stated in the updated 05 version 
https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-05#section-3,
 as the followings:
>
>   ISIS [RFC5029] defines the Link-Attributes Sub-TLV to carry the 
link
>   attribute information, but this Sub-TLV can only be carried 
within
>   the TLV 22, which is used to described the attached neighbor.  
For
>   passive interface, there is no ISIS neighbor, then