Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Chris:
Thanks for your efforts.
Will try to update the draft again to resolve the concerns raised during the
adoption call and ask for adoption later.

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Christian
Hopps
Sent: Friday, March 11, 2022 12:19 AM
To: lsr 
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps
; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for
draft-wang-lsr-stub-link-attributes-02

The document is NOT adopted.

I was not able to convince myself that we have rough consensus of the WG to
adopt this work. The fact that the document was revised *during* the
adoption call (in part to deal with) the huge number of messages that have
been posted (approaching 100!), and then finally, and importantly, one of
the co-authors of the document itself not support it's adoption, all weighed
into this decision.

The authors of course are free to request adoption at a later date, after
working on convincing those who did not agree with the adoption right now,
perhaps through revising their document further or changing the solution,
and also getting their co-authors to agree to adoption; I would ask that the
authors consider doing so carefully as to not tie up even more WG resources
than have been used so far on this.

Thanks,
Chris.
[As WG Chair]

> On Jan 4, 2022, at 01:58, Christian Hopps  wrote:
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> 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

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Christian Hopps]

The document is NOT adopted.

I was not able to convince myself that we have rough consensus of the WG to 
adopt this work. The fact that the document was revised *during* the adoption 
call (in part to deal with) the huge number of messages that have been posted 
(approaching 100!), and then finally, and importantly, one of the co-authors of 
the document itself not support it's adoption, all weighed into this decision.

The authors of course are free to request adoption at a later date, after 
working on convincing those who did not agree with the adoption right now, 
perhaps through revising their document further or changing the solution, and 
also getting their co-authors to agree to adoption; I would ask that the 
authors consider doing so carefully as to not tie up even more WG resources 
than have been used so far on this.

Thanks,
Chris.
[As WG Chair]

> On Jan 4, 2022, at 01:58, Christian Hopps  wrote:
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> 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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Acee Lindem (acee)]

Hi Chris, 

I'm currently a co-author and provided input on the encoding and moving the 
encoding from the base LSAs/TLVs to the TE LSAs/TLVs given that the intended 
use is, in fact, traffic engineering. 

However, I do not support WG adoption unless the utility of advertising these 
external stub link prefixes as such is validated by the use cases. At this 
point, I don't believe that this is the case. 

Thanks,
Acee

On 1/4/22, 2:04 AM, "Christian Hopps"  wrote:

Hi Folks,

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

https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

Please indicate your support or objections by January 18th, 2022.

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Dongjie (Jimmy)]

Hi,

I've read this document and support its adoption.

My understanding of this document is that it aims to identify a link attached 
to an IGP node, while the link itself does not run IGP. Some attributes of such 
link may be used in determining the path to an external network via that link. 
This may apply both to the inter-AS cases and the data center cases as 
mentioned in the draft. It seems that define a generic mechanism for such case 
is a reasonable approach. 

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Tuesday, January 4, 2022 2:59 PM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org;
> draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> 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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[zhu.chun1]

Hi Everyone,
I support adoption and I am not aware of any IPR that applies to this draft
Best Regards,

--Original Message-
from：ChristianHopps
To：lsr@ietf.org;
CC：lsr-cha...@ietf.org;lsr-...@ietf.org;cho...@chopps.org;draft-wang-lsr-stub-link-attribu...@ietf.org;
Data ：2022-01-04 15:04
Subject ：[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
Please indicate your support or objections by January 18th, 2022.
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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[liupeng...@outlook.com]

Hi WG,

I support the adoption.

Regards,
Peng Liu



liupeng...@outlook.com
 
From: Christian Hopps
Date: 2022-01-04 14:58
To: lsr@ietf.org
CC: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Hi Folks,
 
This begins a 2 week WG Adoption Call for the following draft:
 
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
 
Please indicate your support or objections by January 18th, 2022.
 
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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[zhu...@chinatelecom.cn]

I support its adoption.
Based on the discussion on the list, we can know that following the guideline 
of RFC5316 and RFC5305 is not the efficient way to extract the inter-AS 
topology as that required by 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1。we
 should also consider the further usage of the informtion that associated the 
stub link.

B.R.
Yongqing Zhu



zhu...@chinatelecom.cn
 
From: Christian Hopps
Date: 2022-01-04 14:58
To: lsr@ietf.org
CC: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Hi Folks,
 
This begins a 2 week WG Adoption Call for the following draft:
 
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
 
Please indicate your support or objections by January 18th, 2022.
 
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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Weiqiang Cheng]

I support the adoption.

B.R.
Weiqiang Cheng

> -Original Message-
> From: lsr-boun...@ietf.org  On Behalf Of Christian
> Hopps
> Sent: Tuesday, January 4, 2022 2:59 PM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org;
> draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> 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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Les:
I do a short search work and find even for P2MP stub-link type, the process can 
be same as the numbered p2p interface.

 Please see the reference at your company’s doc site: 
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-2/iro-xe-2-book/iro-cfg.html

In these cases, you can configure the OSPF network type as a 
point-to-multipoint network. Routing between two routers not directly connected 
will go through the router that has VCs to both routers. Note that you need not 
configure neighbors when using this feature. 
An OSPF point-to-multipoint interface is defined as a numbered point-to-point 
interface having one or more neighbors. It creates multiple host routes. An 
OSPF point-to-multipoint network has the following benefits compared to NBMA 
and point-to-point networks: 

 Point-to-multipoint is easier to configure because it requires no 
configuration of neighbor commands, it consumes only one IP subnet, and it 
requires no designated router election.

Then all the neighbor should also under one common prefixes.

So, the proposed draft can meet the scenarios for all kinds of numbered 
interfaces.

Do you have other concerns then?
Also ask for John? Robert? Or other experts?

Aijun Wang
China Telecom

> On Jan 15, 2022, at 09:34, Aijun Wang  wrote:
> 
> Hi, Les:
> Thanks for your analysis. If these are your main concerns, here is my 
> responses:
> 
> I am hearing your every opposition points(also from others, same points or 
> not.)
> I am always trying to address the comments, although reluctant to some corner 
> cases(sorry if it irritated you). But as you insist the solution should cover 
> all possible scenarios, then how about the following considerations:
> 
> 1) We have updated the draft to reflect the solution to “unnumbered link”. 
> 
> 2) P2MP stub-link type, we can take the same approach.(the stub link type 
> “P2MP” should be added)
> 
> 3) For broadcast stub link, the nodes that share the same prefix can 
> certainly be connected together.
> 
>  Are the above considerations solve your concerns? If so, we can update the 
> draft again to reflect this.
> 
> 
> Aijun Wang
> China Telecom
> 
>>> On Jan 15, 2022, at 08:49, Les Ginsberg (ginsberg)  
>>> wrote:
>>> 
>> 
>> Aijun –
>>  
>> I believe there is a fundamental disagreement here which derives from your 
>> belief that it is correct/sufficient to describe a link interconnecting two 
>> or more nodes using a prefix.
>> This has been discussed on the list for a long time now. It has been pointed 
>> out to you that this is a broken model. It does not work for multiple cases 
>> (true broadcast links, unnumbered links, point to MP links).
>> Your response to date when this is pointed out to you is either:
>>  
>> “I don’t care about those cases”
>>  
>> Or
>>  
>> “I don’t think those cases are important.”
>>  
>> But I (and others) do not see the value of adopting a model that has limited 
>> applicability – especially when we already have a model that is much more 
>> robust.
>>  
>> Sure – if you think a prefix is enough to define the connection between two 
>> nodes, then you can view the identifiers for the neighbor as “unnecessary”.
>> But this is the wrong model.
>>  
>> So long as we disagree on this fundamental point, we are never going to 
>> agree on anything else and rehashing details is a waste of time for everyone.
>>  
>>Les
>>  
>>  
>> From: Aijun Wang  
>> Sent: Friday, January 14, 2022 4:10 PM
>> To: Robert Raszuk 
>> Cc: Les Ginsberg (ginsberg) ; lsr ; John E 
>> Drake 
>> Subject: Re: [Lsr] WG Adoption Call for 
>> draft-wang-lsr-stub-link-attributes-02
>>  
>> Hi, Robert:
>>  
>> Sorry, the correct description should be “For inter-AS stub link, we must 
>> generate unnecessary Remote-AS, Remote ASBR Router ID for scenarios that 
>> described in  
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1
>>  For non inter-AS stub link, we must generate Bogus-AS, and Bogus Remote 
>> ASBR Router ID”
>>  
>> Aijun Wang
>> China Telecom
>> 
>> 
>> On Jan 15, 2022, at 07:59, Robert Raszuk  wrote:
>> 
>> 
>>  
>> For the current scenarios and solutions, we have analyzed that RFC 5316 and 
>> RFC5392 are not suitable for such purposes—we must generate bogus AS, bogus 
>> Remote ASBR Router ID on every inter-AS, or non inter-AS boundary links.
>>  
>> Why do you think those values need to be "bogus" ? And Inter-AS is just a 
>> perfect example on

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Les:
Thanks for your analysis. If these are your main concerns, here is my responses:

I am hearing your every opposition points(also from others, same points or not.)
I am always trying to address the comments, although reluctant to some corner 
cases(sorry if it irritated you). But as you insist the solution should cover 
all possible scenarios, then how about the following considerations:

1) We have updated the draft to reflect the solution to “unnumbered link”. 

2) P2MP stub-link type, we can take the same approach.(the stub link type 
“P2MP” should be added)

3) For broadcast stub link, the nodes that share the same prefix can certainly 
be connected together.

 Are the above considerations solve your concerns? If so, we can update the 
draft again to reflect this.


Aijun Wang
China Telecom

> On Jan 15, 2022, at 08:49, Les Ginsberg (ginsberg)  wrote:
> 
> 
> Aijun –
>  
> I believe there is a fundamental disagreement here which derives from your 
> belief that it is correct/sufficient to describe a link interconnecting two 
> or more nodes using a prefix.
> This has been discussed on the list for a long time now. It has been pointed 
> out to you that this is a broken model. It does not work for multiple cases 
> (true broadcast links, unnumbered links, point to MP links).
> Your response to date when this is pointed out to you is either:
>  
> “I don’t care about those cases”
>  
> Or
>  
> “I don’t think those cases are important.”
>  
> But I (and others) do not see the value of adopting a model that has limited 
> applicability – especially when we already have a model that is much more 
> robust.
>  
> Sure – if you think a prefix is enough to define the connection between two 
> nodes, then you can view the identifiers for the neighbor as “unnecessary”.
> But this is the wrong model.
>  
> So long as we disagree on this fundamental point, we are never going to agree 
> on anything else and rehashing details is a waste of time for everyone.
>  
>Les
>  
>  
> From: Aijun Wang  
> Sent: Friday, January 14, 2022 4:10 PM
> To: Robert Raszuk 
> Cc: Les Ginsberg (ginsberg) ; lsr ; John E 
> Drake 
> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
>  
> Hi, Robert:
>  
> Sorry, the correct description should be “For inter-AS stub link, we must 
> generate unnecessary Remote-AS, Remote ASBR Router ID for scenarios that 
> described in  
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1
>  For non inter-AS stub link, we must generate Bogus-AS, and Bogus Remote ASBR 
> Router ID”
>  
> Aijun Wang
> China Telecom
> 
> 
> On Jan 15, 2022, at 07:59, Robert Raszuk  wrote:
> 
> 
>  
> For the current scenarios and solutions, we have analyzed that RFC 5316 and 
> RFC5392 are not suitable for such purposes—we must generate bogus AS, bogus 
> Remote ASBR Router ID on every inter-AS, or non inter-AS boundary links.
>  
> Why do you think those values need to be "bogus" ? And Inter-AS is just a 
> perfect example on what you call a "stub link" so I would not hold on that 
> much to the nomenclature. 
>  
> I would like to hear the constructive comments, or other solutions that 
> better the the one in this draft.
>  
> I think what has been suggested is just that, but of course you are entitled 
> to have your own opinion. 
>  
> Kind regards,
> Robert
>  
> ___
> 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-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Christian:

Actually, 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1
 is the main scenario that want to be solved by this adopting draft.
The reason that we mentioned 
https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute is that 
we should consider more possible scenarios to find the extensible solution. 
For standard activities and working group, we should look further. 

I admire everyone’s opinions and won’t expect everyone agree me. But knowing 
the reason or viable solution can certainly aid the solve of the problem, or 
make thing forward.
We all expect constructive suggestions, right?


Aijun Wang
China Telecom

> On Jan 15, 2022, at 08:19, Christian Hopps  wrote:
> 
> 
> 
>> On Jan 14, 2022, at 6:39 PM, Aijun Wang  wrote:
>> 
>> Hi, Robert:
>> 
>> I would say some people are likely to hear other’s explanations, some are 
>> reluctant. 
>> Anyway, I am eager to hear the independent technical analysis.
>> 
>> For the current scenarios and solutions, we have analyzed that RFC 5316 and 
>> RFC5392 are not suitable for such purposes—we must generate bogus AS, bogus 
>> Remote ASBR Router ID on every inter-AS, or non inter-AS boundary links.
>> 
>> I would like to hear the constructive comments, or other solutions that 
>> better the the one in this draft.
> 
> Chair Hat,
> 
> Just to be clear, whether this draft is adopted or not does not require that 
> people agree with your solution or provide better ones.
> 
> The WG has to decide if it actually thinks it's worthwhile to work on the 
> problem at all. Then it also has to decide if this draft in it's current form 
> is the right vehicle to do this work. Only if those 2 things are satisfied 
> will the document be adopted as a WG document.
> 
> Thanks,
> Chris.
> 
> 
>> 
>> Aijun Wang
>> China Telecom
>> 
 On Jan 15, 2022, at 07:15, Robert Raszuk  wrote:
>>> 
>>> 
>>> Hi Aijun,
>>> 
>>> If not, I would say both you and Les’s understanding of this draft is not 
>>> correct.
>>> 
>>> If two (or more) subject matter experts like Les & John can not understand 
>>> the IGP draft I would not draw an immediate conclusion that this is their 
>>> perception fault. 
>>> 
>>> Instead I would take a step back and see that perhaps there is something 
>>> wrong with the draft itself ? 
>>> 
>>> Thx,
>>> Robert.
>>> 
>> ___
>> 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-wang-lsr-stub-link-attributes-02

[Les Ginsberg (ginsberg)]

Aijun –

I believe there is a fundamental disagreement here which derives from your 
belief that it is correct/sufficient to describe a link interconnecting two or 
more nodes using a prefix.
This has been discussed on the list for a long time now. It has been pointed 
out to you that this is a broken model. It does not work for multiple cases 
(true broadcast links, unnumbered links, point to MP links).
Your response to date when this is pointed out to you is either:

“I don’t care about those cases”

Or

“I don’t think those cases are important.”

But I (and others) do not see the value of adopting a model that has limited 
applicability – especially when we already have a model that is much more 
robust.

Sure – if you think a prefix is enough to define the connection between two 
nodes, then you can view the identifiers for the neighbor as “unnecessary”.
But this is the wrong model.

So long as we disagree on this fundamental point, we are never going to agree 
on anything else and rehashing details is a waste of time for everyone.

   Les


From: Aijun Wang 
Sent: Friday, January 14, 2022 4:10 PM
To: Robert Raszuk 
Cc: Les Ginsberg (ginsberg) ; lsr ; John E 
Drake 
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Robert:

Sorry, the correct description should be “For inter-AS stub link, we must 
generate unnecessary Remote-AS, Remote ASBR Router ID for scenarios that 
described in  
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1
 For non inter-AS stub link, we must generate Bogus-AS, and Bogus Remote ASBR 
Router ID”

Aijun Wang
China Telecom


On Jan 15, 2022, at 07:59, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:


For the current scenarios and solutions, we have analyzed that RFC 5316 and 
RFC5392 are not suitable for such purposes—we must generate bogus AS, bogus 
Remote ASBR Router ID on every inter-AS, or non inter-AS boundary links.

Why do you think those values need to be "bogus" ? And Inter-AS is just a 
perfect example on what you call a "stub link" so I would not hold on that much 
to the nomenclature.

I would like to hear the constructive comments, or other solutions that better 
the the one in this draft.

I think what has been suggested is just that, but of course you are entitled to 
have your own opinion.

Kind regards,
Robert

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[John E Drake]

This seems to be argument by emphatic assertion.

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang 
Sent: Friday, January 14, 2022 7:45 PM
To: John E Drake 
Cc: Les Ginsberg (ginsberg) ; Christian Hopps 
; lsr-cha...@ietf.org; Tony Li ; lsr 
; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org; 
Peter Psenak 
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

OK, then I can conclude that you have no more comments for my responses to Les.

Then, you and Les should notice that RFC5316 and RFC5392 are not appropriate to 
solve the scenarios that described in 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09*section-5.1__;Iw!!NEt6yMaO-gk!VOQyl9lKgK7cbrw7Q4Ahv-o_EsmlaIkdOxBy-L6hQIQqtq6ZSZf1MfJrFwa1oKU$>.
 I have given the reasons in previous mail.
Aijun Wang
China Telecom

On Jan 15, 2022, at 08:31, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:

If I agree with Les, why do I need to repeat everything he has said?

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Friday, January 14, 2022 6:03 PM
To: John E Drake mailto:jdr...@juniper.net>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Peter Psenak mailto:ppse...@cisco.com>>; Christian Hopps 
mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; Tony Li 
mailto:tony...@tony.li>>; lsr 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

Hi, John:

Please gives concrete responses for my responses to Les’s comments at 
https://mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/__;!!NEt6yMaO-gk!TD39mWfi5WWuFscpR6z6DLsI3GKpQfu32CCnr0iF7kcS5HnJ6Lpe_7l9L6PY0ac$>

If not, I would say both you and Les’s understanding of this draft is not 
correct.

Aijun Wang
China Telecom

On Jan 14, 2022, at 23:43, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:

I agree with Les.  This draft is gratuitous and ill-considered.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Friday, January 14, 2022 2:22 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: 'Peter Psenak' 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 'Christian Hopps' mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 'Tony Li' 
mailto:tony...@tony.li>>; 'lsr' 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

Aijun -

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: 'Peter Psenak' 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 'Christian Hopps' mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 'Tony Li' 
mailto:tony...@tony.li>>; 'lsr' 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Peter Psenak 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun –

In my first post on this thread I indicated that I thought RFC 5316 is 
sufficient for the use cases described in this draft. The subsequent lengthy 
discussions on this thread has convinced me that RFC 5316 is indeed sufficient 
and there is no need for this draf

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

OK, then I can conclude that you have no more comments for my responses to Les.

Then, you and Les should notice that RFC5316 and RFC5392 are not appropriate to 
solve the scenarios that described in 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1.
 I have given the reasons in previous mail.

Aijun Wang
China Telecom

> On Jan 15, 2022, at 08:31, John E Drake  
> wrote:
> 
> 
> If I agree with Les, why do I need to repeat everything he has said?
>  
> Yours Irrespectively,
>  
> John
>  
>  
> Juniper Business Use Only
> From: Aijun Wang  
> Sent: Friday, January 14, 2022 6:03 PM
> To: John E Drake 
> Cc: Les Ginsberg (ginsberg) ; Peter Psenak 
> ; Christian Hopps ; 
> lsr-cha...@ietf.org; Tony Li ; lsr ; 
> lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
>  
> [External Email. Be cautious of content]
>  
> Hi, John:
>  
> Please gives concrete responses for my responses to Les’s comments at 
> https://mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/
>  
> If not, I would say both you and Les’s understanding of this draft is not 
> correct.
>  
> 
> Aijun Wang
> China Telecom
>  
> 
> On Jan 14, 2022, at 23:43, John E Drake  
> wrote:
> 
> 
> I agree with Les.  This draft is gratuitous and ill-considered.
>  
> Yours Irrespectively,
>  
> John
>  
>  
> Juniper Business Use Only
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Friday, January 14, 2022 2:22 AM
> To: Aijun Wang 
> Cc: 'Peter Psenak' ; 'Christian Hopps' 
> ; lsr-cha...@ietf.org; 'Tony Li' ; 'lsr' 
> ; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
>  
> [External Email. Be cautious of content]
>  
> Aijun -
>  
> From: Lsr  On Behalf Of Aijun Wang
> Sent: Thursday, January 13, 2022 6:45 PM
> To: Les Ginsberg (ginsberg) 
> Cc: 'Peter Psenak' ; 'Christian Hopps' 
> ; lsr-cha...@ietf.org; 'Tony Li' ; 'lsr' 
> ; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
>  
> Hi, Les:
>  
> From: Les Ginsberg (ginsberg)  
> Sent: Friday, January 14, 2022 9:18 AM
> To: Aijun Wang 
> Cc: Tony Li ; Christian Hopps ; Peter 
> Psenak ; lsr-cha...@ietf.org; lsr 
> ; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
>  
> Aijun –
>  
> In my first post on this thread I indicated that I thought RFC 5316 is 
> sufficient for the use cases described in this draft. The subsequent lengthy 
> discussions on this thread has convinced me that RFC 5316 is indeed 
> sufficient and there is no need for this draft.
>  
> Along the way some issues discussed were:
>  
> The requirement of RFC 5316 that AS # be advertised. It is true that in some 
> of the use cases you won’t have an AS #, but this can be addressed by using 
> one of the reserved ASNs (0 or 65535) or one of the private ASNs. So that 
> issue has been resolved.
> [WAJ] Not only the non-existing remote AS, but also the non-existing 
> IPv4/IPv6 Remote ASBR ID sub-TLV.  And, you may propose we can assign other 
> specific IPv4/IPv6 Remote ASBR ID.
> Not mentioned the unnecessary configuration on such kind links, the IGP will 
> also advertise such useless information for each boundary link.
> Considering also what the Robert has mentioned scenario(the product of (# of 
> PEs) * (N trunks from each PE) * (Max 4K VLANs) ), how many invalid 
> information will be advertised within the IGP?
> Why we must limit our deployment to the guideline of unsuitable RFCs?
>  
> [LES:] The ASBR ID is simply the router ID of the peer at the remote end of 
> the link. You need to know this in order to identify the peer since you do 
> not have a protocol identifier (IS-IS system ID or OSPF Router ID) as you 
> would if the IGP were enabled on the link.
> So there is no reason that this information should be bogus.
>  
> You continue to promote the need to use a new sub-TLV to advertise a link 
> type – but there is no demonstrated need for this nor any description of how 
> such information would be used. (I say this even after reading your responses 
> below.)
> [WAJ] It is the field within the Stub-Link TLV, not new sub-TLV.  It is not 
> like the Link Type Sub-TLV that defined in 
> https://datatracker.ietf.org/doc/html/rfc3630#section-2.5.1.
> If you view them from the controller POV(the consumer of the BGP-LS 
> information), you may 

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[John E Drake]

If I agree with Les, why do I need to repeat everything he has said?

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang 
Sent: Friday, January 14, 2022 6:03 PM
To: John E Drake 
Cc: Les Ginsberg (ginsberg) ; Peter Psenak 
; Christian Hopps ; lsr-cha...@ietf.org; 
Tony Li ; lsr ; lsr-...@ietf.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

Hi, John:

Please gives concrete responses for my responses to Les’s comments at 
https://mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/__;!!NEt6yMaO-gk!TD39mWfi5WWuFscpR6z6DLsI3GKpQfu32CCnr0iF7kcS5HnJ6Lpe_7l9L6PY0ac$>

If not, I would say both you and Les’s understanding of this draft is not 
correct.

Aijun Wang
China Telecom

On Jan 14, 2022, at 23:43, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:

I agree with Les.  This draft is gratuitous and ill-considered.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Friday, January 14, 2022 2:22 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: 'Peter Psenak' 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 'Christian Hopps' mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 'Tony Li' 
mailto:tony...@tony.li>>; 'lsr' 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

Aijun -

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: 'Peter Psenak' 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 'Christian Hopps' mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 'Tony Li' 
mailto:tony...@tony.li>>; 'lsr' 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Peter Psenak 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun –

In my first post on this thread I indicated that I thought RFC 5316 is 
sufficient for the use cases described in this draft. The subsequent lengthy 
discussions on this thread has convinced me that RFC 5316 is indeed sufficient 
and there is no need for this draft.

Along the way some issues discussed were:

The requirement of RFC 5316 that AS # be advertised. It is true that in some of 
the use cases you won’t have an AS #, but this can be addressed by using one of 
the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has 
been resolved.
[WAJ] Not only the non-existing remote AS, but also the non-existing IPv4/IPv6 
Remote ASBR ID sub-TLV.  And, you may propose we can assign other specific 
IPv4/IPv6 Remote ASBR ID.
Not mentioned the unnecessary configuration on such kind links, the IGP will 
also advertise such useless information for each boundary link.
Considering also what the Robert has mentioned scenario(the product of (# of 
PEs) * (N trunks from each PE) * (Max 4K VLANs) ), how many invalid information 
will be advertised within the IGP?
Why we must limit our deployment to the guideline of unsuitable RFCs?

[LES:] The ASBR ID is simply the router ID of the peer at the remote end of the 
link. You need to know this in order to identify the peer since you do not have 
a protocol identifier (IS-IS system ID or OSPF Router ID) as you would if the 
IGP were enabled on the link.
So there is no reason that this information should be bogus.

You continue to promote the need to use a new sub-TLV to advertise a link type 
– but there is no demonstrated need for this nor any description of how such 
information would be used. (I say this even after reading your responses below.)
[WAJ] It is the field within the Stub-Li

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Christian Hopps]

> On Jan 14, 2022, at 6:39 PM, Aijun Wang  wrote:
> 
> Hi, Robert:
> 
> I would say some people are likely to hear other’s explanations, some are 
> reluctant. 
> Anyway, I am eager to hear the independent technical analysis.
> 
> For the current scenarios and solutions, we have analyzed that RFC 5316 and 
> RFC5392 are not suitable for such purposes—we must generate bogus AS, bogus 
> Remote ASBR Router ID on every inter-AS, or non inter-AS boundary links.
> 
> I would like to hear the constructive comments, or other solutions that 
> better the the one in this draft.

Chair Hat,

Just to be clear, whether this draft is adopted or not does not require that 
people agree with your solution or provide better ones.

The WG has to decide if it actually thinks it's worthwhile to work on the 
problem at all. Then it also has to decide if this draft in it's current form 
is the right vehicle to do this work. Only if those 2 things are satisfied will 
the document be adopted as a WG document.

Thanks,
Chris.


> 
> Aijun Wang
> China Telecom
> 
>> On Jan 15, 2022, at 07:15, Robert Raszuk  wrote:
>> 
>> 
>> Hi Aijun,
>>  
>> If not, I would say both you and Les’s understanding of this draft is not 
>> correct.
>> 
>> If two (or more) subject matter experts like Les & John can not understand 
>> the IGP draft I would not draw an immediate conclusion that this is their 
>> perception fault. 
>> 
>> Instead I would take a step back and see that perhaps there is something 
>> wrong with the draft itself ? 
>> 
>> Thx,
>> Robert.
>> 
> ___
> 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-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Robert:

Sorry, the correct description should be “For inter-AS stub link, we must 
generate unnecessary Remote-AS, Remote ASBR Router ID for scenarios that 
described in  
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1
 For non inter-AS stub link, we must generate Bogus-AS, and Bogus Remote ASBR 
Router ID”

Aijun Wang
China Telecom

> On Jan 15, 2022, at 07:59, Robert Raszuk  wrote:
> 
> 
>  
>> For the current scenarios and solutions, we have analyzed that RFC 5316 and 
>> RFC5392 are not suitable for such purposes—we must generate bogus AS, bogus 
>> Remote ASBR Router ID on every inter-AS, or non inter-AS boundary links.
> 
> Why do you think those values need to be "bogus" ? And Inter-AS is just a 
> perfect example on what you call a "stub link" so I would not hold on that 
> much to the nomenclature. 
> 
>> I would like to hear the constructive comments, or other solutions that 
>> better the the one in this draft.
> 
> I think what has been suggested is just that, but of course you are entitled 
> to have your own opinion. 
> 
> Kind regards,
> Robert
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Robert Raszuk]

> For the current scenarios and solutions, we have analyzed that RFC 5316
> and RFC5392 are not suitable for such purposes—we must generate bogus AS,
> bogus Remote ASBR Router ID on every inter-AS, or non inter-AS boundary
> links.
>

Why do you think those values need to be "bogus" ? And Inter-AS is just a
perfect example on what you call a "stub link" so I would not hold on that
much to the nomenclature.

I would like to hear the constructive comments, or other solutions that
> better the the one in this draft.
>

I think what has been suggested is just that, but of course you are
entitled to have your own opinion.

Kind regards,
Robert
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Robert:

I would say some people are likely to hear other’s explanations, some are 
reluctant. 
Anyway, I am eager to hear the independent technical analysis.

For the current scenarios and solutions, we have analyzed that RFC 5316 and 
RFC5392 are not suitable for such purposes—we must generate bogus AS, bogus 
Remote ASBR Router ID on every inter-AS, or non inter-AS boundary links.

I would like to hear the constructive comments, or other solutions that better 
the the one in this draft.

Aijun Wang
China Telecom

> On Jan 15, 2022, at 07:15, Robert Raszuk  wrote:
> 
> 
> Hi Aijun,
>  
>> If not, I would say both you and Les’s understanding of this draft is not 
>> correct.
> 
> If two (or more) subject matter experts like Les & John can not understand 
> the IGP draft I would not draw an immediate conclusion that this is their 
> perception fault. 
> 
> Instead I would take a step back and see that perhaps there is something 
> wrong with the draft itself ? 
> 
> Thx,
> Robert.
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Robert Raszuk]

Hi Aijun,


> If not, I would say both you and Les’s understanding of this draft is not
> correct.
>

If two (or more) subject matter experts like Les & John can not understand
the IGP draft I would not draw an immediate conclusion that this is their
perception fault.

Instead I would take a step back and see that perhaps there is something
wrong with the draft itself ?

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, John:

Please gives concrete responses for my responses to Les’s comments at 
https://mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/

If not, I would say both you and Les’s understanding of this draft is not 
correct.


Aijun Wang
China Telecom

> On Jan 14, 2022, at 23:43, John E Drake  
> wrote:
> 
> 
> I agree with Les.  This draft is gratuitous and ill-considered.
>  
> Yours Irrespectively,
>  
> John
>  
>  
> Juniper Business Use Only
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Friday, January 14, 2022 2:22 AM
> To: Aijun Wang 
> Cc: 'Peter Psenak' ; 'Christian Hopps' 
> ; lsr-cha...@ietf.org; 'Tony Li' ; 'lsr' 
> ; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
>  
> [External Email. Be cautious of content]
>  
> Aijun -
>  
> From: Lsr  On Behalf Of Aijun Wang
> Sent: Thursday, January 13, 2022 6:45 PM
> To: Les Ginsberg (ginsberg) 
> Cc: 'Peter Psenak' ; 'Christian Hopps' 
> ; lsr-cha...@ietf.org; 'Tony Li' ; 'lsr' 
> ; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
>  
> Hi, Les:
>  
> From: Les Ginsberg (ginsberg)  
> Sent: Friday, January 14, 2022 9:18 AM
> To: Aijun Wang 
> Cc: Tony Li ; Christian Hopps ; Peter 
> Psenak ; lsr-cha...@ietf.org; lsr 
> ; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
>  
> Aijun –
>  
> In my first post on this thread I indicated that I thought RFC 5316 is 
> sufficient for the use cases described in this draft. The subsequent lengthy 
> discussions on this thread has convinced me that RFC 5316 is indeed 
> sufficient and there is no need for this draft.
>  
> Along the way some issues discussed were:
>  
> The requirement of RFC 5316 that AS # be advertised. It is true that in some 
> of the use cases you won’t have an AS #, but this can be addressed by using 
> one of the reserved ASNs (0 or 65535) or one of the private ASNs. So that 
> issue has been resolved.
> [WAJ] Not only the non-existing remote AS, but also the non-existing 
> IPv4/IPv6 Remote ASBR ID sub-TLV.  And, you may propose we can assign other 
> specific IPv4/IPv6 Remote ASBR ID.
> Not mentioned the unnecessary configuration on such kind links, the IGP will 
> also advertise such useless information for each boundary link.
> Considering also what the Robert has mentioned scenario(the product of (# of 
> PEs) * (N trunks from each PE) * (Max 4K VLANs) ), how many invalid 
> information will be advertised within the IGP?
> Why we must limit our deployment to the guideline of unsuitable RFCs?
>  
> [LES:] The ASBR ID is simply the router ID of the peer at the remote end of 
> the link. You need to know this in order to identify the peer since you do 
> not have a protocol identifier (IS-IS system ID or OSPF Router ID) as you 
> would if the IGP were enabled on the link.
> So there is no reason that this information should be bogus.
>  
> You continue to promote the need to use a new sub-TLV to advertise a link 
> type – but there is no demonstrated need for this nor any description of how 
> such information would be used. (I say this even after reading your responses 
> below.)
> [WAJ] It is the field within the Stub-Link TLV, not new sub-TLV.  It is not 
> like the Link Type Sub-TLV that defined in 
> https://datatracker.ietf.org/doc/html/rfc3630#section-2.5.1.
> If you view them from the controller POV(the consumer of the BGP-LS 
> information), you may know the below responses well.
>  
> [LES:] I called it a sub-TLV because that’s what it was in the previous 
> version of the draft – before you invented a new top level TLV to avoid using 
> TLV 141.
> But regardless of the encoding details, my point is this information is not 
> useful and not needed. There is no reason to advertise a loopback interface 
> as a link. And there is no value in knowing whether the non-loopback link is 
> a VLAN or top level ethernet or some type of P2P media. I have asked 
> repeatedly of what use this information is and you have failed to provide any 
> answer.
>  
> You also continue to promote the need to use an RFC 5316 like TLV to 
> advertise the address of loopbacks – but again there is no need. The prefix 
> associated with a loopback is advertised in Prefix Reachability TLVs. That 
> the prefix is associated with a loopback is identified by the presence of the 
> N flag in the associated RFC 7794 prefix attributes sub-TLV. The owner/source 
> of the loopback is identified by the RFC 7794 define

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[John E Drake]

I agree with Les.  This draft is gratuitous and ill-considered.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, January 14, 2022 2:22 AM
To: Aijun Wang 
Cc: 'Peter Psenak' ; 'Christian Hopps' 
; lsr-cha...@ietf.org; 'Tony Li' ; 'lsr' 
; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

Aijun -

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: 'Peter Psenak' 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 'Christian Hopps' mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 'Tony Li' 
mailto:tony...@tony.li>>; 'lsr' 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Peter Psenak 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun –

In my first post on this thread I indicated that I thought RFC 5316 is 
sufficient for the use cases described in this draft. The subsequent lengthy 
discussions on this thread has convinced me that RFC 5316 is indeed sufficient 
and there is no need for this draft.

Along the way some issues discussed were:

The requirement of RFC 5316 that AS # be advertised. It is true that in some of 
the use cases you won’t have an AS #, but this can be addressed by using one of 
the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has 
been resolved.
[WAJ] Not only the non-existing remote AS, but also the non-existing IPv4/IPv6 
Remote ASBR ID sub-TLV.  And, you may propose we can assign other specific 
IPv4/IPv6 Remote ASBR ID.
Not mentioned the unnecessary configuration on such kind links, the IGP will 
also advertise such useless information for each boundary link.
Considering also what the Robert has mentioned scenario(the product of (# of 
PEs) * (N trunks from each PE) * (Max 4K VLANs) ), how many invalid information 
will be advertised within the IGP?
Why we must limit our deployment to the guideline of unsuitable RFCs?

[LES:] The ASBR ID is simply the router ID of the peer at the remote end of the 
link. You need to know this in order to identify the peer since you do not have 
a protocol identifier (IS-IS system ID or OSPF Router ID) as you would if the 
IGP were enabled on the link.
So there is no reason that this information should be bogus.

You continue to promote the need to use a new sub-TLV to advertise a link type 
– but there is no demonstrated need for this nor any description of how such 
information would be used. (I say this even after reading your responses below.)
[WAJ] It is the field within the Stub-Link TLV, not new sub-TLV.  It is not 
like the Link Type Sub-TLV that defined in 
https://datatracker.ietf.org/doc/html/rfc3630#section-2.5.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630*section-2.5.1__;Iw!!NEt6yMaO-gk!X-98qsVOziyN85o3KP84-1xQm5tL-oRKaugF4f8e58Ieg_jojmKjo5n1GaZvI0g$>.
If you view them from the controller POV(the consumer of the BGP-LS 
information), you may know the below responses well.

[LES:] I called it a sub-TLV because that’s what it was in the previous version 
of the draft – before you invented a new top level TLV to avoid using TLV 141.
But regardless of the encoding details, my point is this information is not 
useful and not needed. There is no reason to advertise a loopback interface as 
a link. And there is no value in knowing whether the non-loopback link is a 
VLAN or top level ethernet or some type of P2P media. I have asked repeatedly 
of what use this information is and you have failed to provide any answer.

You also continue to promote the need to use an RFC 5316 like TLV to advertise 
the address of loopbacks – but again there is no need. The prefix associated 
with a loopback is advertised in Prefix Reachability TLVs. That the prefix is 
associated with a loopback is identified by the presence of the N flag in the 
associated RFC 7794 prefix attributes sub-TLV. The owner/source of the loopback 
is identifi

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[sun.jinsong]

Hi Everyone,
I support adoption and I am not aware of any IPR that applies to this draft
Best Regards,

--Original Message-
from：ChristianHopps
To：lsr@ietf.org;
CC：lsr-cha...@ietf.org;lsr-...@ietf.org;cho...@chopps.org;draft-wang-lsr-stub-link-attribu...@ietf.org;
Data ：2022-01-04 15:04
Subject ：[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
Please indicate your support or objections by January 18th, 2022.
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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Sorry，one correction:

It should be “For non-inter-AS stub link, the Remote ASBR doesn’t exist. Even 
in the inter-AS link, we don’t need it”

 

From: lsr-boun...@ietf.org  On Behalf Of Aijun Wang
Sent: Friday, January 14, 2022 5:03 PM
To: 'Les Ginsberg (ginsberg)' 
Cc: 'Peter Psenak' ; 'Christian Hopps' 
; lsr-cha...@ietf.org; 'Tony Li' ; 'lsr' 
; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

 

Hi, Les:

 

1) For non-inter-AS stub link, the 【Remote】ASBR doesn’t exist. Even in the 
inter-AS stub link, we don’t need it.

2） For the 5G edge scenario, I think you should also refer to 
https://datatracker.ietf.org/doc/html/draft-dunbar-idr-5g-edge-compute-app-meta-data-05#section-7
 about the process of “Soft Anchoring of ANYCAST FLOW”.

I think this will be also needed in the IGP scenario. To achieve this goal, the 
“AggCost” or “AppMetaData” shouldn’t be the metric of the prefix, it should be 
the metric of the stub link.  

The usage of such information is to differentiate the exit point of the LDN, 
not the prefix, which is same in the ANYCAST scenario.

 

And, we should also consider the situation when the Flexalgo is not used, but 
can also achieve the same goal(as described in the above reference)

 

Anyway, I think we can discuss this point in another thread in more thoroughly.

What I want to say it is hasty to conclude such metric should be associated to 
the prefixes.

 

3） For the “stub-link type”, the original consideration is that when one 
interface is configured as “passive”, the related information should be 
advertised via the “Stub-Link” TLV. 

Then the loopback address is one kind of such type and should be filtered out. 
If you advertise the loopback interface within the normal IGP LSA, such type 
can be eliminated. 

And we consider there are some differences for the logical VLAN 
interface and its associated Ethernet interface, for example, the bandwidth 
control and the isolation characteristic etc.

  These types can certainly be combined or separated later upon further 
discussion, and they are not the key part of this draft.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  mailto:lsr-boun...@ietf.org> > On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, January 14, 2022 3:22 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Cc: 'Peter Psenak' mailto:ppsenak=40cisco@dmarc.ietf.org> >; 'Christian Hopps' 
mailto:cho...@chopps.org> >; lsr-cha...@ietf.org 
<mailto:lsr-cha...@ietf.org> ; 'Tony Li' mailto:tony...@tony.li> >; 'lsr' mailto:lsr@ietf.org> >; 
lsr-...@ietf.org <mailto:lsr-...@ietf.org> ; 
draft-wang-lsr-stub-link-attribu...@ietf.org 
<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org> 
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

 

Aijun -

 

From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of 
Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >
Cc: 'Peter Psenak' mailto:ppsenak=40cisco@dmarc.ietf.org> >; 'Christian Hopps' 
mailto:cho...@chopps.org> >; lsr-cha...@ietf.org 
<mailto:lsr-cha...@ietf.org> ; 'Tony Li' mailto:tony...@tony.li> >; 'lsr' mailto:lsr@ietf.org> >; 
lsr-...@ietf.org <mailto:lsr-...@ietf.org> ; 
draft-wang-lsr-stub-link-attribu...@ietf.org 
<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org> 
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

 

Hi, Les:

 

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> > 
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Cc: Tony Li mailto:tony...@tony.li> >; Christian Hopps 
mailto:cho...@chopps.org> >; Peter Psenak 
mailto:ppsenak=40cisco@dmarc.ietf.org> 
>; lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org> ; lsr mailto:lsr@ietf.org> >; lsr-...@ietf.org <mailto:lsr-...@ietf.org> ; 
draft-wang-lsr-stub-link-attribu...@ietf.org 
<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org> 
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

 

Aijun –

 

In my first post on this thread I indicated that I thought RFC 5316 is 
sufficient for the use cases described in this draft. The subsequent lengthy 
discussions on this thread has convinced me that RFC 5316 is indeed sufficient 
and there is no need for this draft.

 

Along the way some issues discussed were:

 

The requirement of RFC 5316 that AS # be advertised. It is true that in some of 
the use cases you won’t have an AS #, but this can be addressed by using one of 
the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has 
been resolved.

[WAJ] Not only the non-existing remote AS, bu

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Les:

 

1) For non-inter-AS stub link, the ASBR doesn’t exist. Even in the inter-AS 
stub link, we don’t need it.

2） For the 5G edge scenario, I think you should also refer to 
https://datatracker.ietf.org/doc/html/draft-dunbar-idr-5g-edge-compute-app-meta-data-05#section-7
 about the process of “Soft Anchoring of ANYCAST FLOW”.

I think this will be also needed in the IGP scenario. To achieve this goal, the 
“AggCost” or “AppMetaData” shouldn’t be the metric of the prefix, it should be 
the metric of the stub link.  

The usage of such information is to differentiate the exit point of the LDN, 
not the prefix, which is same in the ANYCAST scenario.

 

And, we should also consider the situation when the Flexalgo is not used, but 
can also achieve the same goal(as described in the above reference)

 

Anyway, I think we can discuss this point in another thread in more thoroughly.

What I want to say it is hasty to conclude such metric should be associated to 
the prefixes.

 

3） For the “stub-link type”, the original consideration is that when one 
interface is configured as “passive”, the related information should be 
advertised via the “Stub-Link” TLV. 

Then the loopback address is one kind of such type and should be filtered out. 
If you advertise the loopback interface within the normal IGP LSA, such type 
can be eliminated. 

And we consider there are some differences for the logical VLAN 
interface and its associated Ethernet interface, for example, the bandwidth 
control and the isolation characteristic etc.

  These types can certainly be combined or separated later upon further 
discussion, and they are not the key part of this draft.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Friday, January 14, 2022 3:22 PM
To: Aijun Wang 
Cc: 'Peter Psenak' ; 'Christian Hopps' 
; lsr-cha...@ietf.org; 'Tony Li' ; 'lsr' 
; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

 

Aijun -

 

From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of 
Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >
Cc: 'Peter Psenak' mailto:ppsenak=40cisco@dmarc.ietf.org> >; 'Christian Hopps' 
mailto:cho...@chopps.org> >; lsr-cha...@ietf.org 
<mailto:lsr-cha...@ietf.org> ; 'Tony Li' mailto:tony...@tony.li> >; 'lsr' mailto:lsr@ietf.org> >; 
lsr-...@ietf.org <mailto:lsr-...@ietf.org> ; 
draft-wang-lsr-stub-link-attribu...@ietf.org 
<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org> 
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

 

Hi, Les:

 

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> > 
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Cc: Tony Li mailto:tony...@tony.li> >; Christian Hopps 
mailto:cho...@chopps.org> >; Peter Psenak 
mailto:ppsenak=40cisco@dmarc.ietf.org> 
>; lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org> ; lsr mailto:lsr@ietf.org> >; lsr-...@ietf.org <mailto:lsr-...@ietf.org> ; 
draft-wang-lsr-stub-link-attribu...@ietf.org 
<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org> 
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

 

Aijun –

 

In my first post on this thread I indicated that I thought RFC 5316 is 
sufficient for the use cases described in this draft. The subsequent lengthy 
discussions on this thread has convinced me that RFC 5316 is indeed sufficient 
and there is no need for this draft.

 

Along the way some issues discussed were:

 

The requirement of RFC 5316 that AS # be advertised. It is true that in some of 
the use cases you won’t have an AS #, but this can be addressed by using one of 
the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has 
been resolved.

[WAJ] Not only the non-existing remote AS, but also the non-existing IPv4/IPv6 
Remote ASBR ID sub-TLV.  And, you may propose we can assign other specific 
IPv4/IPv6 Remote ASBR ID. 

Not mentioned the unnecessary configuration on such kind links, the IGP will 
also advertise such useless information for each boundary link. 

Considering also what the Robert has mentioned scenario(the product of (# of 
PEs) * (N trunks from each PE) * (Max 4K VLANs) ), how many invalid information 
will be advertised within the IGP?

Why we must limit our deployment to the guideline of unsuitable RFCs?

 

[LES:] The ASBR ID is simply the router ID of the peer at the remote end of the 
link. You need to know this in order to identify the peer since you do not have 
a protocol identifier (IS-IS system ID or OSPF Router ID) as you would if the 
IGP were enabled on the link.

So there is no reason that this information should be bogus.

 

You con

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Les Ginsberg (ginsberg)]

Aijun -

From: Lsr  On Behalf Of Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) 
Cc: 'Peter Psenak' ; 'Christian Hopps' 
; lsr-cha...@ietf.org; 'Tony Li' ; 'lsr' 
; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Tony Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Peter Psenak 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr 
mailto:lsr@ietf.org>>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun –

In my first post on this thread I indicated that I thought RFC 5316 is 
sufficient for the use cases described in this draft. The subsequent lengthy 
discussions on this thread has convinced me that RFC 5316 is indeed sufficient 
and there is no need for this draft.

Along the way some issues discussed were:

The requirement of RFC 5316 that AS # be advertised. It is true that in some of 
the use cases you won’t have an AS #, but this can be addressed by using one of 
the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has 
been resolved.
[WAJ] Not only the non-existing remote AS, but also the non-existing IPv4/IPv6 
Remote ASBR ID sub-TLV.  And, you may propose we can assign other specific 
IPv4/IPv6 Remote ASBR ID.
Not mentioned the unnecessary configuration on such kind links, the IGP will 
also advertise such useless information for each boundary link.
Considering also what the Robert has mentioned scenario(the product of (# of 
PEs) * (N trunks from each PE) * (Max 4K VLANs) ), how many invalid information 
will be advertised within the IGP?
Why we must limit our deployment to the guideline of unsuitable RFCs?

[LES:] The ASBR ID is simply the router ID of the peer at the remote end of the 
link. You need to know this in order to identify the peer since you do not have 
a protocol identifier (IS-IS system ID or OSPF Router ID) as you would if the 
IGP were enabled on the link.
So there is no reason that this information should be bogus.

You continue to promote the need to use a new sub-TLV to advertise a link type 
– but there is no demonstrated need for this nor any description of how such 
information would be used. (I say this even after reading your responses below.)
[WAJ] It is the field within the Stub-Link TLV, not new sub-TLV.  It is not 
like the Link Type Sub-TLV that defined in 
https://datatracker.ietf.org/doc/html/rfc3630#section-2.5.1.
If you view them from the controller POV(the consumer of the BGP-LS 
information), you may know the below responses well.

[LES:] I called it a sub-TLV because that’s what it was in the previous version 
of the draft – before you invented a new top level TLV to avoid using TLV 141.
But regardless of the encoding details, my point is this information is not 
useful and not needed. There is no reason to advertise a loopback interface as 
a link. And there is no value in knowing whether the non-loopback link is a 
VLAN or top level ethernet or some type of P2P media. I have asked repeatedly 
of what use this information is and you have failed to provide any answer.

You also continue to promote the need to use an RFC 5316 like TLV to advertise 
the address of loopbacks – but again there is no need. The prefix associated 
with a loopback is advertised in Prefix Reachability TLVs. That the prefix is 
associated with a loopback is identified by the presence of the N flag in the 
associated RFC 7794 prefix attributes sub-TLV. The owner/source of the loopback 
is identified by the RFC 7794 defined Router-ID sub-TLV(s).
[WAJ] Yes, You are right on the above information and I also know this.
The primary thought for defining this type, is that we want to filter such kind 
stub interface from advertising to the BGP-LS Stub-Link NLRI( 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5)
 on the router that run BPG-LS, or filer it easily on the controller.

[LES:] If you never advertise loopbacks in the TLV then there is no need to 
filter them out.


As far as the relationship with draft-dunbar-lsr-5g-edge-compute, that draft 
only needs to advertise a new type of prefix metric – which is to be advertised 
in the Prefix Reachability TLVs. Mention in that draft of using the Stub Link 
TLV defined in this draft should be removed. It suggests that a Link TLV is the 
correct container for Prefix information – it is not.
[WAJ] Would you like to provide the reason, not just directly jump into to the 
conclusion?
[LES:

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Les:

 

From: Les Ginsberg (ginsberg)  
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang 
Cc: Tony Li ; Christian Hopps ; Peter 
Psenak ; lsr-cha...@ietf.org; lsr 
; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

 

Aijun –

 

In my first post on this thread I indicated that I thought RFC 5316 is 
sufficient for the use cases described in this draft. The subsequent lengthy 
discussions on this thread has convinced me that RFC 5316 is indeed sufficient 
and there is no need for this draft.

 

Along the way some issues discussed were:

 

The requirement of RFC 5316 that AS # be advertised. It is true that in some of 
the use cases you won’t have an AS #, but this can be addressed by using one of 
the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has 
been resolved.

[WAJ] Not only the non-existing remote AS, but also the non-existing IPv4/IPv6 
Remote ASBR ID sub-TLV.  And, you may propose we can assign other specific 
IPv4/IPv6 Remote ASBR ID. 

Not mentioned the unnecessary configuration on such kind links, the IGP will 
also advertise such useless information for each boundary link. 

Considering also what the Robert has mentioned scenario(the product of (# of 
PEs) * (N trunks from each PE) * (Max 4K VLANs) ), how many invalid information 
will be advertised within the IGP?

Why we must limit our deployment to the guideline of unsuitable RFCs?

 

You continue to promote the need to use a new sub-TLV to advertise a link type 
– but there is no demonstrated need for this nor any description of how such 
information would be used. (I say this even after reading your responses below.)

[WAJ] It is the field within the Stub-Link TLV, not new sub-TLV.  It is not 
like the Link Type Sub-TLV that defined in 
https://datatracker.ietf.org/doc/html/rfc3630#section-2.5.1. 

If you view them from the controller POV(the consumer of the BGP-LS 
information), you may know the below responses well.

 

You also continue to promote the need to use an RFC 5316 like TLV to advertise 
the address of loopbacks – but again there is no need. The prefix associated 
with a loopback is advertised in Prefix Reachability TLVs. That the prefix is 
associated with a loopback is identified by the presence of the N flag in the 
associated RFC 7794 prefix attributes sub-TLV. The owner/source of the loopback 
is identified by the RFC 7794 defined Router-ID sub-TLV(s). 

[WAJ] Yes, You are right on the above information and I also know this.

The primary thought for defining this type, is that we want to filter such kind 
stub interface from advertising to the BGP-LS Stub-Link NLRI( 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5)
 on the router that run BPG-LS, or filer it easily on the controller.

 

As far as the relationship with draft-dunbar-lsr-5g-edge-compute, that draft 
only needs to advertise a new type of prefix metric – which is to be advertised 
in the Prefix Reachability TLVs. Mention in that draft of using the Stub Link 
TLV defined in this draft should be removed. It suggests that a Link TLV is the 
correct container for Prefix information – it is not.

[WAJ] Would you like to provide the reason, not just directly jump into to the 
conclusion? 

 

There is no need for this draft – therefore it should not be adopted.

 

Les

 

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> 
> 
Sent: Thursday, January 13, 2022 6:13 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >
Cc: Tony Li mailto:tony...@tony.li> >; Christian Hopps 
mailto:cho...@chopps.org> >; Peter Psenak 
mailto:ppsenak=40cisco@dmarc.ietf.org> 
>; lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org> ; lsr mailto:lsr@ietf.org> >; lsr-...@ietf.org <mailto:lsr-...@ietf.org> ; 
draft-wang-lsr-stub-link-attribu...@ietf.org 
<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org> 
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

 

Hi, Les:

 

Aijun Wang

China Telecom

 

On Jan 13, 2022, at 11:04, Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> > wrote:

 

Here is my takeaway from this back-and-forth.

 

Several highly experienced routing folks have been looking at this draft in 
detail and they are unable to come to a common understanding on what the draft 
is trying to do. 


[WAJ] I think most of them have gotten the key points of this draft along the 
discussion and the reading of the related drafts. If they have still some 
questions, we can discuss and explain on the list.

 

This alone indicates that the draft needs more work. Maybe the authors have a 
clear idea on what they are trying to do but if expert readers cannot determine 
what it is then clearly the draft needs further revision.


[WAJ]This is the WG adoption call, not the WGLC. We certainly will update th

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Les Ginsberg (ginsberg)]

Aijun –

In my first post on this thread I indicated that I thought RFC 5316 is 
sufficient for the use cases described in this draft. The subsequent lengthy 
discussions on this thread has convinced me that RFC 5316 is indeed sufficient 
and there is no need for this draft.

Along the way some issues discussed were:

The requirement of RFC 5316 that AS # be advertised. It is true that in some of 
the use cases you won’t have an AS #, but this can be addressed by using one of 
the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has 
been resolved.

You continue to promote the need to use a new sub-TLV to advertise a link type 
– but there is no demonstrated need for this nor any description of how such 
information would be used. (I say this even after reading your responses below.)

You also continue to promote the need to use an RFC 5316 like TLV to advertise 
the address of loopbacks – but again there is no need. The prefix associated 
with a loopback is advertised in Prefix Reachability TLVs. That the prefix is 
associated with a loopback is identified by the presence of the N flag in the 
associated RFC 7794 prefix attributes sub-TLV. The owner/source of the loopback 
is identified by the RFC 7794 defined Router-ID sub-TLV(s).

As far as the relationship with draft-dunbar-lsr-5g-edge-compute, that draft 
only needs to advertise a new type of prefix metric – which is to be advertised 
in the Prefix Reachability TLVs. Mention in that draft of using the Stub Link 
TLV defined in this draft should be removed. It suggests that a Link TLV is the 
correct container for Prefix information – it is not.

There is no need for this draft – therefore it should not be adopted.

Les


From: Aijun Wang 
Sent: Thursday, January 13, 2022 6:13 AM
To: Les Ginsberg (ginsberg) 
Cc: Tony Li ; Christian Hopps ; Peter 
Psenak ; lsr-cha...@ietf.org; lsr 
; lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

Aijun Wang
China Telecom


On Jan 13, 2022, at 11:04, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Here is my takeaway from this back-and-forth.

Several highly experienced routing folks have been looking at this draft in 
detail and they are unable to come to a common understanding on what the draft 
is trying to do.

[WAJ] I think most of them have gotten the key points of this draft along the 
discussion and the reading of the related drafts. If they have still some 
questions, we can discuss and explain on the list.


This alone indicates that the draft needs more work. Maybe the authors have a 
clear idea on what they are trying to do but if expert readers cannot determine 
what it is then clearly the draft needs further revision.

[WAJ]This is the WG adoption call, not the WGLC. We certainly will update the 
draft according to the comments from the WG. For adoption call, I think enough 
interests is the main criteria for its adoption.



It also indicates to me that it is premature to determine whether the WG should 
adopt this or not. If experienced folks reading the draft can’t easily 
determine what the draft is trying to do, then it does not seem possible to 
make a judgment as to whether the WG should adopt it.

[WAJ] I think Gyan has given the good summary for the use cases, or motivation 
of this draft at 
https://mailarchive.ietf.org/arch/msg/lsr/R9JW8pHpNK1zt_jHx-KuMMOeJV8/.

I think if you read 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-10,
 you can get the key points of inter-AS use case.



Additional comments:

I tend to agree with Tony (and others) that the draft is aimed at advertising 
some form of TE information –

[WAJ] Yes. The proposed TLV is one container and aim to convey the attributes 
of the Stub-Link, also as stated in the draft name.


which is why I suggested even in my first post on this thread that RFC 5316 
seemed like it was enough. The problem that has been exposed during the 
discussion is that RFC 5316 requires an AS number and in this deployment case 
we may not have one. But perhaps this limitation can be addressed by using the 
reserved AS #0 – a la RFC 7607.  (BGP experts please comment – I do not claim 
to be a BGP expert.)

[WAJ]Reuse the existing TLVs need to  update RFC5316, RFC5392 or other 
potential RFC document , to relax the “MUST” rules that defined in these 
documents. It will also influence the existing implementation and deployment. 
Won’t it encounter more resistances?

And, as mentioned in your proposal, there still need some unproved bypass 
methods to solve the situations that not the original scenarios of RFC5316 and 
RFC5392.

Start from the clean state is the most efficient way. Isn’t it?



There is then the additional sub-TLV defined in the document:


Link Type: Define the type of the stub-link.

   o  1: Numbered AS boundary link

   o  2: Unnumbered AS boundary link

 

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Robert Raszuk]

And one more question - apologies if it was already discussed and I missed
it.

How will the PE / edge router receive information describing current (for
example) load of the compute or LB sitting behind the switch on one of the
VLANs ?

Many thx,
R.


On Thu, Jan 13, 2022 at 4:08 PM Robert Raszuk  wrote:

> HI Aijun,
>
> I am simply highlighting three points -
>
> * link is not the same as a leaf - prefix of the subnet
>
> * Today PE usually aggregates all subnets of VLANs into just one or few
> supernets. Links can not be aggregated.
>
> * Subnets are static. Here we are discussing adding dynamic data into this
> new amount of (stub) link information.
>
> Kind regards,
> R.
>
>
>
>
>
> On Thu, Jan 13, 2022 at 4:03 PM Aijun Wang 
> wrote:
>
>> Hi, Robert:
>>
>> Aijun Wang
>> China Telecom
>>
>> On Jan 13, 2022, at 22:29, Robert Raszuk  wrote:
>>
>> 
>>
>>
>>> [WAJ] VLAN interface is the logical interfaces that connected to servers
>>> that are out side of the IGP domain. It is also different from the inter-AS
>>> link that described in RFC5316 and RFC5392.
>>> Some information that related to the attached severs or some policy to
>>> these server can be applied to these kind stub link.
>>>
>>
>>
>> Let's observe that there can be 4K VLANs on each trunk interface on a
>> given PE. There can be multiple trunks attached to each edge node going to
>> switches then in form of subnets to physical or virtual computes/pods/VMs
>> etc... .
>>
>> Are we ready to take the product of (# of PEs) * (N trunks from each PE)
>> * (Max 4K VLANs)  in the form of new links into even local area IGP ?
>> Especially as we are learning that some of the values carried may be
>> dynamic in nature.
>>
>>
>> [WAJ]If there are so many of servers attached around all the PEs, we
>> certainly need all of the associated servers’ prefixes. Right?
>> If you want to some traffic engineering from/to these servers, or some
>> policies on the boundary, you should also need additional attributes of
>> them.
>>
>> Stub-Link TLV just the container for these information.
>>
>>
>> Thx,
>> R.
>>
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Robert Raszuk]

HI Aijun,

I am simply highlighting three points -

* link is not the same as a leaf - prefix of the subnet

* Today PE usually aggregates all subnets of VLANs into just one or few
supernets. Links can not be aggregated.

* Subnets are static. Here we are discussing adding dynamic data into this
new amount of (stub) link information.

Kind regards,
R.





On Thu, Jan 13, 2022 at 4:03 PM Aijun Wang 
wrote:

> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Jan 13, 2022, at 22:29, Robert Raszuk  wrote:
>
> 
>
>
>> [WAJ] VLAN interface is the logical interfaces that connected to servers
>> that are out side of the IGP domain. It is also different from the inter-AS
>> link that described in RFC5316 and RFC5392.
>> Some information that related to the attached severs or some policy to
>> these server can be applied to these kind stub link.
>>
>
>
> Let's observe that there can be 4K VLANs on each trunk interface on a
> given PE. There can be multiple trunks attached to each edge node going to
> switches then in form of subnets to physical or virtual computes/pods/VMs
> etc... .
>
> Are we ready to take the product of (# of PEs) * (N trunks from each PE) *
> (Max 4K VLANs)  in the form of new links into even local area IGP ?
> Especially as we are learning that some of the values carried may be
> dynamic in nature.
>
>
> [WAJ]If there are so many of servers attached around all the PEs, we
> certainly need all of the associated servers’ prefixes. Right?
> If you want to some traffic engineering from/to these servers, or some
> policies on the boundary, you should also need additional attributes of
> them.
>
> Stub-Link TLV just the container for these information.
>
>
> Thx,
> R.
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Jan 13, 2022, at 22:29, Robert Raszuk  wrote:
> 
> 
>  
>> [WAJ] VLAN interface is the logical interfaces that connected to servers 
>> that are out side of the IGP domain. It is also different from the inter-AS 
>> link that described in RFC5316 and RFC5392.
>> Some information that related to the attached severs or some policy to these 
>> server can be applied to these kind stub link.
> 
> 
> Let's observe that there can be 4K VLANs on each trunk interface on a given 
> PE. There can be multiple trunks attached to each edge node going to switches 
> then in form of subnets to physical or virtual computes/pods/VMs etc... . 
> 
> Are we ready to take the product of (# of PEs) * (N trunks from each PE) * 
> (Max 4K VLANs)  in the form of new links into even local area IGP ? 
> Especially as we are learning that some of the values carried may be dynamic 
> in nature. 

[WAJ]If there are so many of servers attached around all the PEs, we certainly 
need all of the associated servers’ prefixes. Right? 
If you want to some traffic engineering from/to these servers, or some policies 
on the boundary, you should also need additional attributes of them.

Stub-Link TLV just the container for these information.

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Robert Raszuk]

> [WAJ] VLAN interface is the logical interfaces that connected to servers
> that are out side of the IGP domain. It is also different from the inter-AS
> link that described in RFC5316 and RFC5392.
> Some information that related to the attached severs or some policy to
> these server can be applied to these kind stub link.
>


Let's observe that there can be 4K VLANs on each trunk interface on a given
PE. There can be multiple trunks attached to each edge node going to
switches then in form of subnets to physical or virtual computes/pods/VMs
etc... .

Are we ready to take the product of (# of PEs) * (N trunks from each PE) *
(Max 4K VLANs)  in the form of new links into even local area IGP ?
Especially as we are learning that some of the values carried may be
dynamic in nature.

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

adopt the draft at this time.
> The authors can then spend time revising the draft, addressing the many 
> issues which have been raised, continue to get feedback from the WG, and at a 
> future time decide whether the revised version is suitable for WG adoption.
>  
> Les
>  
>  
> From: Lsr  On Behalf Of Tony Li
> Sent: Wednesday, January 12, 2022 6:04 PM
> To: Christian Hopps 
> Cc: Peter Psenak ; Aijun Wang 
> ; lsr-cha...@ietf.org; lsr ; 
> lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
>  
>  
> Chris,
>  
> This isn't the same as TE information which can be/is based dynamic values on 
> the router.
>  
>  
> Are you sure? First, much of the TE information that we have distributed is 
> static (administrative group, SRLG, etc.).  The dynamic part has been 
> bandwidth reservation.  That still seems applicable to inter-AS stub links, 
> even tho Aijin hasn’t articulated that yet. It does seem inevitable, again 
> assuming I understand the use case.
>  
> 
> 
> I'm pretty sure that it isn't even using the 2-way connectivity check. It's 
> literally just saying "Router A has a stub link B (i.e., it has the config 
> 'isis passive' on it)".
>  
>  
> As the draft has it, you’re correct. However, there’s all that undefined 
> subTLV space just begging for TE information.  The current ‘link type’ 
> information seems somewhat pointless if it isn’t intended to be a item for TE 
> consideration.
>  
> 
> 
> That infomration is already a part of an operators NMS b/c that NMS is what 
> generated that router's configuration and stuck it on that router in the 
> first place. That same NMS is going to be configuring the other router that 
> would be looking for that "stub link" information in the IGP. Unless I've 
> mis-understood something here, the proposoal is literally just pushing static 
> configuration details around inside the IGP.
>  
>  
> Agreed 100%.  But it’s also what we do today with much of the static TE 
> information. Again, there’s precedent.
>  
> T
>  
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Chongfeng Xie]

Hi， all
I have read the draf and support its adoption.

Chongfeng 

> 2022年1月4日 下午2:58，Christian Hopps  写道：
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> 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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Christian: 

Tony’s explanations are correct.
The proposed TLV is mainly one container, in order to include the related 
attributes of the Stub-Link, not the configuration. Actually, such proposal can 
reduce the configuration headaches(no matter via NMS or Manual) when you want 
to do some kind of inter-AS TE.

The motivation we do this are for controlling , or optimization or engineering 
of the traffic in/out these stub links. 
It may have some relation to other AS(inter-AS scenarios), or the application 
server(5G Edge Computation scenarios), or only the AS boundary(security control 
scenarios)


Aijun Wang
China Telecom

> On Jan 13, 2022, at 10:32, Christian Hopps  wrote:
> 
> 
> 
>> On Jan 12, 2022, at 9:03 PM, Tony Li  wrote:
>> 
>> 
>> Chris,
>> 
>>> This isn't the same as TE information which can be/is based dynamic values 
>>> on the router.
>> 
>> 
>> Are you sure? First, much of the TE information that we have distributed is 
>> static (administrative group, SRLG, etc.).  The dynamic part has been 
>> bandwidth reservation.  That still seems applicable to inter-AS stub links, 
>> even tho Aijin hasn’t articulated that yet. It does seem inevitable, again 
>> assuming I understand the use case.
>> 
>> 
>>> I'm pretty sure that it isn't even using the 2-way connectivity check. It's 
>>> literally just saying "Router A has a stub link B (i.e., it has the config 
>>> 'isis passive' on it)".
>> 
>> 
>> As the draft has it, you’re correct. However, there’s all that undefined 
>> subTLV space just begging for TE information.  The current ‘link type’ 
>> information seems somewhat pointless if it isn’t intended to be a item for 
>> TE consideration.
>> 
>> 
>>> That infomration is already a part of an operators NMS b/c that NMS is what 
>>> generated that router's configuration and stuck it on that router in the 
>>> first place. That same NMS is going to be configuring the other router that 
>>> would be looking for that "stub link" information in the IGP. Unless I've 
>>> mis-understood something here, the proposoal is literally just pushing 
>>> static configuration details around inside the IGP.
>> 
>> 
>> Agreed 100%.  But it’s also what we do today with much of the static TE 
>> information. Again, there’s precedent.
> 
> The thing about the TE information is that it's being used to make live 
> routing decisions (i.e., in a CSPF). We have pretty consistently denied 
> requests to ship generic router configuration around using the IGPs.
> 
> Consider the case of configuring an inter-AS bgp connection, for that I'm 
> imagining configuring a "BGP peer" service in my NMS. Part of that service is 
> going to specify the neighbor AS and perhaps the router (or routers) to 
> connect over. The NMS is going to look inside it's router information DB and 
> use that information to construct the configurations for the service. If I 
> tell it to deploy that service, it's going to then push those generated 
> configuration files out to the affected routers, etc.
> 
> I'm not seeing any need yet for this information to be shipped around in the 
> IGP.
> 
> Thanks,
> Chris.
> 
>> 
>> T
>> 
> 

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Robert Raszuk]

Hi Aijun,

> But normally, we need only one router within IGP run BGP-LS.

True - if we keep adding opaque stuff to the IGP to limit the number of
BGP-LS sessions per area.

In my view BGP-LS should and perhaps will be replaced with a real pub-sub
mechanism sooner or later and that will be part of every edge node. Hence
trashing the IGP protocol is IMHO a wrong thing to do if the goal here is
just to export the information to the controller in the first place.

Best,
R.


On Thu, Jan 13, 2022 at 12:02 PM Aijun Wang 
wrote:

> Hi, Robert:
>
> I remembered we have discussed this. RFC9086 requires every border router
> run BGP-LS.
> But normally, we need only one router within IGP run BGP-LS.
>
> I think Tony has gotten one of key use use case for this draft. The
> difference between us is how to accomplish it.
>
> Aijun Wang
> China Telecom
>
> On Jan 13, 2022, at 18:40, Robert Raszuk  wrote:
>
> 
> Hi Tony,
>
> If you originate BGP-LS on the PE of interest it seems you can stuff it
> with whatever you like. I read RFC9086 as one example of it.
>
> Thx,
> R.
>
> On Thu, Jan 13, 2022 at 3:05 AM Tony Li  wrote:
>
>>
>> Robert,
>>
>> On Jan 12, 2022, at 5:06 PM, Robert Raszuk  wrote:
>>
>> Well if that would be controller based TE computation it seems that these
>> days BGP-LS (ugh!) would be used instead of IGP flooding to pass that info
>> around.
>>
>> Hence that makes (at least :) two of us pretty puzzled on the real use
>> case here.
>>
>>
>>
>> BGP-LS can’t pick it up unless it’s in the LSDB.  Thus, you inject it
>> into the LSDB and let BGP-LS convey it to the controller for you.
>>
>> Tony
>>
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Robert:

I remembered we have discussed this. RFC9086 requires every border router run 
BGP-LS.
But normally, we need only one router within IGP run BGP-LS.

I think Tony has gotten one of key use use case for this draft. The difference 
between us is how to accomplish it.

Aijun Wang
China Telecom

> On Jan 13, 2022, at 18:40, Robert Raszuk  wrote:
> 
> 
> Hi Tony,
> 
> If you originate BGP-LS on the PE of interest it seems you can stuff it with 
> whatever you like. I read RFC9086 as one example of it. 
> 
> Thx,
> R.
> 
>> On Thu, Jan 13, 2022 at 3:05 AM Tony Li  wrote:
>> 
>> Robert,
>> 
>>> On Jan 12, 2022, at 5:06 PM, Robert Raszuk  wrote:
>>> 
>>> Well if that would be controller based TE computation it seems that these 
>>> days BGP-LS (ugh!) would be used instead of IGP flooding to pass that info 
>>> around. 
>>> 
>>> Hence that makes (at least :) two of us pretty puzzled on the real use case 
>>> here. 
>> 
>> 
>> BGP-LS can’t pick it up unless it’s in the LSDB.  Thus, you inject it into 
>> the LSDB and let BGP-LS convey it to the controller for you.
>> 
>> Tony
>> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Robert Raszuk]

Hi Tony,

If you originate BGP-LS on the PE of interest it seems you can stuff it
with whatever you like. I read RFC9086 as one example of it.

Thx,
R.

On Thu, Jan 13, 2022 at 3:05 AM Tony Li  wrote:

>
> Robert,
>
> On Jan 12, 2022, at 5:06 PM, Robert Raszuk  wrote:
>
> Well if that would be controller based TE computation it seems that these
> days BGP-LS (ugh!) would be used instead of IGP flooding to pass that info
> around.
>
> Hence that makes (at least :) two of us pretty puzzled on the real use
> case here.
>
>
>
> BGP-LS can’t pick it up unless it’s in the LSDB.  Thus, you inject it into
> the LSDB and let BGP-LS convey it to the controller for you.
>
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Gyan Mishra]

Robert

The primary use case for Stub Link Attribute is defined in the section 1
introduction excerpt below:

So the stub link on inter-as connection needs to advertise this stub link
attribute in the IGP as a stub link TLV not TE information, so it can be
picked up by BGP-LS to build E2E network graph.

RFC 5392 and RFC 5316 define IGP extension to flood TE information about
the inter-as link for inter-as LSP to be instantiated.  So that is not the
same as what we are trying to accomplish here with this draft as here the
same stub inter-as link attribute is for BGP-LS to build network graph for
SDN controller to instantiate inter-as path.

So the bottom line for this to work with a centralized controller is we
need a stub link attribute information encoded in the IGP as a TLV.

   OSPF[RFC5392] defines the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA
   to carry the TE information about inter-AS links.  These LSAs can be
   used to transfer the information about the stub link which is located
   at the boundary of one AS.  This document defines the Stub-Link TLV
   within these LSAs to identify the stub link and transfer the
   associated attributes then.

   ISIS[RFC5316] defines the Inter-AS Reachability TLV to carry the TE
   information about inter-AS links.  This TLV can be used to transfer
   the information about the stub link which is located at the boundary
   of one AS.  This document defines the Stub-Link TLV to identify the
   stub link and transfer the associated attributes.


Section 1:

   For operator which runs different IGP domains that interconnect with
   each other via the stub links, there is desire to obtain the inter-AS
   topology information as described
in[I-D.ietf-idr-bgpls-inter-as-topology-ext
].
If the router that runs BGP-LS Within one IGP domain can distinguish
stub links from othernormal interfaces, it is then easy for the
router to report these stub links using BGP-LS to a centralized PCE
controller.



The second use case is Dunbar 5G being discussed on the other LSR thread.

  The third use case is for any stub links are  normally the boundary
of one IGP domain, knowing

   them can facilitate the operators to apply various policies on such
   interfaces, for example, to secure their networks, or filtering the
   incoming traffic with scrutiny.


This is using a centralized BGP policy controller.


Excerpts from draft below related to the primary use case to help further
explain the use case.

BGP LS Inter-AS Topology

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-10

   This document describes the process to build Border Gateway Protocol-
   Link State (BGP-LS) key parameters in inter-domain scenario, defines
   one new BGP-LS Network Layer Reachability Information (NLRI) type
   (Stub Link NLRI) and some new inter Autonomous (inter-AS) Traffic
   Engineering (TE) related Type-Length-Values (TLVs) for BGP-LS to let
   Software Definition Network (SDN) controller retrieve the network
   topology automatically under various inter-AS environments.

   Such extension and process can enable the network operator to collect
   the interconnect information between different domains and then
   calculate the overall network topology automatically based on the
   information provided by BGP-LS protocol.


Draft [I-D.ietf-idr-bgpls-segment-routing-epe
]
defines some
   extensions for exporting BGP peering node topology information
   (including its peers, interfaces and peering ASs) in a way that is
   exploitable in order to compute efficient BGP Peering Engineering
   policies and strategies.  Such information can also be used to
   calculate the interconnection topology among different IGP domains,
   but it requires every border router to run BGP-LS protocol and report
   the information to SDN controller.  Considering there will be several
   border routers on the network boundary, such solution restricts its
   deployment flexibility.


   This draft analysis the situations that the SDN controller needs to
   get the interconnected topology information between different AS
   domains, defines the new Stub Link NLRI and some new TLVs within the
   BGP-LS protocol to transfer the key information related to them.
   After that, the SDN controller can then deduce the multi-domain


5 
.
Stub Link NLRI

   [RFC7752] defines four NLRI types(No.  de NLRI, Link NLRI, IPv4 Topology
   Prefix NLRI, IPv6 Topology Prefix NLRI) to transfer the topology and
   prefix information.  For inter-as link, the two ends of the link
   locates in different IGP domains, then it is not appropriate to
   transfer 

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Les Ginsberg (ginsberg)]

Here is my takeaway from this back-and-forth.

Several highly experienced routing folks have been looking at this draft in 
detail and they are unable to come to a common understanding on what the draft 
is trying to do. This alone indicates that the draft needs more work. Maybe the 
authors have a clear idea on what they are trying to do but if expert readers 
cannot determine what it is then clearly the draft needs further revision.

It also indicates to me that it is premature to determine whether the WG should 
adopt this or not. If experienced folks reading the draft can’t easily 
determine what the draft is trying to do, then it does not seem possible to 
make a judgment as to whether the WG should adopt it.

Additional comments:

I tend to agree with Tony (and others) that the draft is aimed at advertising 
some form of TE information – which is why I suggested even in my first post on 
this thread that RFC 5316 seemed like it was enough. The problem that has been 
exposed during the discussion is that RFC 5316 requires an AS number and in 
this deployment case we may not have one. But perhaps this limitation can be 
addressed by using the reserved AS #0 – a la RFC 7607.  (BGP experts please 
comment – I do not claim to be a BGP expert.)

There is then the additional sub-TLV defined in the document:


Link Type: Define the type of the stub-link.

   o  1: Numbered AS boundary link

   o  2: Unnumbered AS boundary link

   o  3: Loopback link

   o  4: Vlan interface link


Ignoring the first two which were only added recently to try to address the 
lack of an AS #:

What is a “loopback link”? I have no idea.
And while I know what a VLAN is, I have no idea why advertising that a link is 
a VLAN is useful.
The draft provides no definition or clue as to the use case for this 
information.

Finally, there is the relationship between this draft and 
draft-dunbar-lsr-5g-edge-compute – which continues to mystify me. Given that 
the latest version of the 5G draft only defines a new metric to be advertised 
in Prefix Reachability advertisements, I have no idea what the relationship 
between the two drafts may be.

What makes sense to me is NOT to adopt the draft at this time.
The authors can then spend time revising the draft, addressing the many issues 
which have been raised, continue to get feedback from the WG, and at a future 
time decide whether the revised version is suitable for WG adoption.

Les


From: Lsr  On Behalf Of Tony Li
Sent: Wednesday, January 12, 2022 6:04 PM
To: Christian Hopps 
Cc: Peter Psenak ; Aijun Wang 
; lsr-cha...@ietf.org; lsr ; 
lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02


Chris,

This isn't the same as TE information which can be/is based dynamic values on 
the router.


Are you sure? First, much of the TE information that we have distributed is 
static (administrative group, SRLG, etc.).  The dynamic part has been bandwidth 
reservation.  That still seems applicable to inter-AS stub links, even tho 
Aijin hasn’t articulated that yet. It does seem inevitable, again assuming I 
understand the use case.



I'm pretty sure that it isn't even using the 2-way connectivity check. It's 
literally just saying "Router A has a stub link B (i.e., it has the config 
'isis passive' on it)".


As the draft has it, you’re correct. However, there’s all that undefined subTLV 
space just begging for TE information.  The current ‘link type’ information 
seems somewhat pointless if it isn’t intended to be a item for TE consideration.



That infomration is already a part of an operators NMS b/c that NMS is what 
generated that router's configuration and stuck it on that router in the first 
place. That same NMS is going to be configuring the other router that would be 
looking for that "stub link" information in the IGP. Unless I've mis-understood 
something here, the proposoal is literally just pushing static configuration 
details around inside the IGP.


Agreed 100%.  But it’s also what we do today with much of the static TE 
information. Again, there’s precedent.

T

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Christian Hopps]

> On Jan 12, 2022, at 9:03 PM, Tony Li  wrote:
> 
> 
> Chris,
> 
>> This isn't the same as TE information which can be/is based dynamic values 
>> on the router.
> 
> 
> Are you sure? First, much of the TE information that we have distributed is 
> static (administrative group, SRLG, etc.).  The dynamic part has been 
> bandwidth reservation.  That still seems applicable to inter-AS stub links, 
> even tho Aijin hasn’t articulated that yet. It does seem inevitable, again 
> assuming I understand the use case.
> 
> 
>> I'm pretty sure that it isn't even using the 2-way connectivity check. It's 
>> literally just saying "Router A has a stub link B (i.e., it has the config 
>> 'isis passive' on it)".
> 
> 
> As the draft has it, you’re correct. However, there’s all that undefined 
> subTLV space just begging for TE information.  The current ‘link type’ 
> information seems somewhat pointless if it isn’t intended to be a item for TE 
> consideration.
> 
> 
>> That infomration is already a part of an operators NMS b/c that NMS is what 
>> generated that router's configuration and stuck it on that router in the 
>> first place. That same NMS is going to be configuring the other router that 
>> would be looking for that "stub link" information in the IGP. Unless I've 
>> mis-understood something here, the proposoal is literally just pushing 
>> static configuration details around inside the IGP.
> 
> 
> Agreed 100%.  But it’s also what we do today with much of the static TE 
> information. Again, there’s precedent.

The thing about the TE information is that it's being used to make live routing 
decisions (i.e., in a CSPF). We have pretty consistently denied requests to 
ship generic router configuration around using the IGPs.

Consider the case of configuring an inter-AS bgp connection, for that I'm 
imagining configuring a "BGP peer" service in my NMS. Part of that service is 
going to specify the neighbor AS and perhaps the router (or routers) to connect 
over. The NMS is going to look inside it's router information DB and use that 
information to construct the configurations for the service. If I tell it to 
deploy that service, it's going to then push those generated configuration 
files out to the affected routers, etc.

I'm not seeing any need yet for this information to be shipped around in the 
IGP.

Thanks,
Chris.

> 
> T
> 

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Tony Li]

Robert,

> On Jan 12, 2022, at 5:06 PM, Robert Raszuk  wrote:
> 
> Well if that would be controller based TE computation it seems that these 
> days BGP-LS (ugh!) would be used instead of IGP flooding to pass that info 
> around. 
> 
> Hence that makes (at least :) two of us pretty puzzled on the real use case 
> here. 


BGP-LS can’t pick it up unless it’s in the LSDB.  Thus, you inject it into the 
LSDB and let BGP-LS convey it to the controller for you.

Tony

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Tony Li]

Chris,

> This isn't the same as TE information which can be/is based dynamic values on 
> the router.


Are you sure? First, much of the TE information that we have distributed is 
static (administrative group, SRLG, etc.).  The dynamic part has been bandwidth 
reservation.  That still seems applicable to inter-AS stub links, even tho 
Aijin hasn’t articulated that yet. It does seem inevitable, again assuming I 
understand the use case.


> I'm pretty sure that it isn't even using the 2-way connectivity check. It's 
> literally just saying "Router A has a stub link B (i.e., it has the config 
> 'isis passive' on it)".


As the draft has it, you’re correct. However, there’s all that undefined subTLV 
space just begging for TE information.  The current ‘link type’ information 
seems somewhat pointless if it isn’t intended to be a item for TE consideration.


> That infomration is already a part of an operators NMS b/c that NMS is what 
> generated that router's configuration and stuck it on that router in the 
> first place. That same NMS is going to be configuring the other router that 
> would be looking for that "stub link" information in the IGP. Unless I've 
> mis-understood something here, the proposoal is literally just pushing static 
> configuration details around inside the IGP.


Agreed 100%.  But it’s also what we do today with much of the static TE 
information. Again, there’s precedent.

T

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Robert Raszuk]

Hi Tony,

Well if that would be controller based TE computation it seems that these
days BGP-LS (ugh!) would be used instead of IGP flooding to pass that info
around.

Hence that makes (at least :) two of us pretty puzzled on the real use case
here.

Thx,
R.




On Thu, Jan 13, 2022 at 1:59 AM Tony Li  wrote:

>
>
> On Jan 12, 2022, at 4:01 PM, Robert Raszuk  wrote:
>
> Very honestly I must have missed that the objective here is to include
> those links in the TE constrained computation. You mean MPLS RSVP-TE ?
>
> Is that so in 2022 ?
>
>
>
> Robert,
>
> It is entirely possible that I have misunderstood the use case.
>
> I would also include SR-TE, SRv6 (ugh!), and any other controller based TE
> that you care to name.
>
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Tony Li]

> On Jan 12, 2022, at 4:01 PM, Robert Raszuk  wrote:
> 
> Very honestly I must have missed that the objective here is to include those 
> links in the TE constrained computation. You mean MPLS RSVP-TE ? 
> 
> Is that so in 2022 ? 


Robert,

It is entirely possible that I have misunderstood the use case. 

I would also include SR-TE, SRv6 (ugh!), and any other controller based TE that 
you care to name.

Tony

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Robert Raszuk]

Hi Tony,

Very honestly I must have missed that the objective here is to include
those links in the TE constrained computation. You mean MPLS RSVP-TE ?

Is that so in 2022 ?

Kind regards,
R.

On Thu, Jan 13, 2022 at 12:58 AM Tony Li  wrote:

>
>
> On Jan 12, 2022, at 3:54 PM, Robert Raszuk  wrote:
>
> What puzzles me in this proposal is why are you insisting on making a stub
> link not-so-stubby instead of treating it as a passive interface (as others
> already suggested) ?
>
>
>
> Robert,
>
> A pure passive interface results in the node advertising the prefixes
> associated with the interface, but no link attributes.
>
> This would give an implementation the option of advertiseing link
> attributes for TE to pick up.  Note that this would be a new feature even
> without any subTLVs.  One could advertise the administrative group (i.e.
> color) of an inter-AS link, for example.
>
> T
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Christian Hopps]

> On Jan 12, 2022, at 6:53 PM, Tony Li  wrote:
> 
> 
> 
>> On Jan 12, 2022, at 3:10 PM, Christian Hopps  wrote:
>> 
>> m having a little trouble fully understanding what you're saying here.
>> 
>> However, I think what is being done is the user configures one router (e.g., 
>> configures "isis passive" on "interfaec Foo0"), and the fact of that 
>> configuration is then transmitted inside the IGP. Other routers in the same 
>> domain then see and act on this configuration.
>> 
>> That is exactly what a network management system is for. This can and should 
>> all be done with a network management system not the routing protocol.
> 
> 
> Chris,
> 
> We have ample precedent for carrying TE information in the IGP.  While you 
> may regret that precedent, it is set.

This isn't the same as TE information which can be/is based dynamic values on 
the router. I'm pretty sure that it isn't even using the 2-way connectivity 
check. It's literally just saying "Router A has a stub link B (i.e., it has the 
config 'isis passive' on it)".

That infomration is already a part of an operators NMS b/c that NMS is what 
generated that router's configuration and stuck it on that router in the first 
place. That same NMS is going to be configuring the other router that would be 
looking for that "stub link" information in the IGP. Unless I've mis-understood 
something here, the proposoal is literally just pushing static configuration 
details around inside the IGP.

Thanks,
Chris.

> 
> AFAICT, the only thing different here is that there’s no actual adjacency on 
> the link.  I see no reason to treat it as anything other than a normal 
> adjacency (perhaps to system id ..?). The two-way check will 
> exclude it from within SPF.
> 
> Tony
> 

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Tony Li]

> On Jan 12, 2022, at 3:54 PM, Robert Raszuk  wrote:
> 
> What puzzles me in this proposal is why are you insisting on making a stub 
> link not-so-stubby instead of treating it as a passive interface (as others 
> already suggested) ? 


Robert,

A pure passive interface results in the node advertising the prefixes 
associated with the interface, but no link attributes.

This would give an implementation the option of advertiseing link attributes 
for TE to pick up.  Note that this would be a new feature even without any 
subTLVs.  One could advertise the administrative group (i.e. color) of an 
inter-AS link, for example.

T


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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Tony Li]

Hi Aijun,

>> Yes, I’m suggesting that you consider a way of using existing TLVs and 
>> adding subTLVs to them in order to convey the information.
>> 
>> A big point of using TLV encoding in the first place is to provide 
>> extensibility. It would be a design error not to use it, when appropriate. 
>> Creating a new entity every time you add a feature leads to more complexity 
>> in the design and in the resulting code.
> 
> [WAJ] If the proposed stub link follow the same rule as the existing link, we 
> can adding the new sub-TLV to achieve the goal.
> But current it is not.


Could you please be more specific? AFAICT, the whole point is to inject stuff 
into the LSDB for TE purposes.


> If we change or update the rule, we should consider the back compatibility or 
> the existing implementation.
> The TLV type design assure it can be extended at the same TLV level, and if 
> the router can’t recognize, it just ignores. The process of existing TLV is 
> not influenced. 


Correct, if you use existing TLVs, and extend the semantics with subTLVs, you 
can be reasonably well assured of backward compatibility.  New TLVs won’t do 
that for you.

Tony


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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Robert Raszuk]

Aijun,

[WAJ] If the proposed stub link follow the same rule as the existing link,
> we can adding the new sub-TLV to achieve the goal.
>

What puzzles me in this proposal is why are you insisting on making a stub
link not-so-stubby instead of treating it as a passive interface (as others
already suggested) ?

What additional (I infer dynamic) attributes are you planning to
advertise of this link ?

The draft is so focused on the mechanics and there is very little there
about the real use cases.

Frankly when watching this discussion and reading the draft I am asking
myself what is missing from already available encoding which you think is
necessary to be part of the IGP advertisements ?

Many thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Tony Li]

> On Jan 12, 2022, at 3:10 PM, Christian Hopps  wrote:
> 
> m having a little trouble fully understanding what you're saying here.
> 
> However, I think what is being done is the user configures one router (e.g., 
> configures "isis passive" on "interfaec Foo0"), and the fact of that 
> configuration is then transmitted inside the IGP. Other routers in the same 
> domain then see and act on this configuration.
> 
> That is exactly what a network management system is for. This can and should 
> all be done with a network management system not the routing protocol.


Chris,

We have ample precedent for carrying TE information in the IGP.  While you may 
regret that precedent, it is set.

AFAICT, the only thing different here is that there’s no actual adjacency on 
the link.  I see no reason to treat it as anything other than a normal 
adjacency (perhaps to system id ..?). The two-way check will 
exclude it from within SPF.

Tony

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Christian Hopps]

> On Jan 12, 2022, at 5:35 PM, Aijun Wang  wrote:
> 
> Hi, Christian:
> 
> Aijun Wang
> China Telecom
> 
>> On Jan 13, 2022, at 04:19, Christian Hopps  wrote:
>> 
>> Doesn't this reduce to: "The operator configures one of their routers with 
>> an IGP "passive" link config, and then uses this IGP extension so their 
>> other routers (in the same AS) can discover that configuration"?
> 
> [WAJ] Yes, this is same behavior for the normal link within IGP. 
> The difference is that we need not configure the remote end information(in 
> numbered AS boundary interface scenarios) again.
> The advertising information within the IGP is only information about its own.

I'm having a little trouble fully understanding what you're saying here.

However, I think what is being done is the user configures one router (e.g., 
configures "isis passive" on "interfaec Foo0"), and the fact of that 
configuration is then transmitted inside the IGP. Other routers in the same 
domain then see and act on this configuration.

That is exactly what a network management system is for. This can and should 
all be done with a network management system not the routing protocol.

Thanks,
Chris.
[as wg member]


> 
> Aijun Wang
> China Telecom
> 
>> 
>> Thanks,
>> Chris.
>> [as wg member]
>> 
>> 
>>> On Jan 11, 2022, at 8:51 AM, Aijun Wang  wrote:
>>> 
>>> Hi, Christian:
>>> 
>>> The benefit of the proposed solution is that for inter-AS scenarios, it can 
>>> accomplish the automatic pairing for the two ends of inter-AS link without 
>>> the explicitly configuration for the remote end information.
>>> In other scenarios,  it can also contain useful information for the edge 
>>> computation services, aid the operator know exactly the boundary of the 
>>> network and apply special security policy at such stub link if necessary 
>>> etc.
>>> 
>>> I have updated the draft today in order to address the concerns for 
>>> unnumbered interface and sub-TLV hierarchy that raised by Peter and Les. 
>>> Please review it if there exists any other concerns.
>>> 
>>> Thanks.
>>> 
>>> 
>>> Aijun Wang
>>> China Telecom
>>> 
> On Jan 11, 2022, at 20:55, Christian Hopps  wrote:
 
 
 Peter Psenak  writes:
 
> Aijun,
> 
>> On 05/01/2022 16:20, Aijun Wang wrote:
>> [WAJ] The above remote information must be configured manually on the 
>> local
>> device. It is paired by manual. Thinking there are many links among the 
>> ASBRs,
>> would you like to configure them manually for every remote ends on each 
>> link?
 
 No one with large scale networks, and/or routers with lots of links is 
 doing any sort of manual configuration. It seems to me that I keep seeing 
 this mentioned as justification for changes or extensions to the IGPs. It 
 is not reasonable justification b/c no-one is doing it.
 
 I think it would be very useful if manual configuration or the assumption 
 that we need to make that less painful, stopped being brought up so we can 
 focus on other reasonable justifications (or lack thereof :)
 
 Thanks,
 Chris.
 [as wg member]
 
 
>> The prefixes that associated with the stub link can assist to accomplish 
>> this task automatically.
> 
> If the ISIS/OSPF adjacency is not formed over the link, you need to 
> manually
> configure remote endpoint parameters. Defining a new TLV is not going to 
> make
> any difference.
> 
> Using the local subnet information for identifying two endpoints of the 
> same
> link does not sound appealing to me.
> 
> We have link local/remote IDs (and IP addresses) to pair the two 
> endpoints of
> the link in both OSPF and ISIS. We do not need another mechanism for the 
> same.
> In addition, what you propose does not work for unnumbered links.
> 
> I don't see a need for the new stub-link advertisement.
> 
> thanks,
> Peter
> 
> 
> ___
> 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-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Tony:

Aijun Wang
China Telecom

> On Jan 13, 2022, at 02:16, Tony Li  wrote:
> 
> 
> Hi Aijun,
> 
>> 
>> It would seem to me that if you re-used existing TLVs, you could be adding 
>> subTLVs to carry any additional information.  This would probably be a lot 
>> cleaner.
>> [WAJ] Then we should update RFC5316, RFC5292, RFC3630 etc. It may also 
>> influence the existing deployment. 
>> There are also other situations that the RFC5316 and RFC5292 does not cover, 
>> for example, for the associated information that the edge computing wants to 
>> utilize etc.
>> Start from the clean slate will be more acceptable?
> 
> 
> Yes, I’m suggesting that you consider a way of using existing TLVs and adding 
> subTLVs to them in order to convey the information.
> 
> A big point of using TLV encoding in the first place is to provide 
> extensibility. It would be a design error not to use it, when appropriate. 
> Creating a new entity every time you add a feature leads to more complexity 
> in the design and in the resulting code.

[WAJ] If the proposed stub link follow the same rule as the existing link, we 
can adding the new sub-TLV to achieve the goal.
But current it is not. If we change or update the rule, we should consider the 
back compatibility or the existing implementation.
The TLV type design assure it can be extended at the same TLV level, and if the 
router can’t recognize, it just ignores. The process of existing TLV is not 
influenced. 

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Christian:

Aijun Wang
China Telecom

> On Jan 13, 2022, at 04:19, Christian Hopps  wrote:
> 
> Doesn't this reduce to: "The operator configures one of their routers with 
> an IGP "passive" link config, and then uses this IGP extension so their other 
> routers (in the same AS) can discover that configuration"?

[WAJ] Yes, this is same behavior for the normal link within IGP. 
The difference is that we need not configure the remote end information(in 
numbered AS boundary interface scenarios) again.
The advertising information within the IGP is only information about its own.

Aijun Wang
China Telecom

> 
> Thanks,
> Chris.
> [as wg member]
> 
> 
>> On Jan 11, 2022, at 8:51 AM, Aijun Wang  wrote:
>> 
>> Hi, Christian:
>> 
>> The benefit of the proposed solution is that for inter-AS scenarios, it can 
>> accomplish the automatic pairing for the two ends of inter-AS link without 
>> the explicitly configuration for the remote end information.
>> In other scenarios,  it can also contain useful information for the edge 
>> computation services, aid the operator know exactly the boundary of the 
>> network and apply special security policy at such stub link if necessary etc.
>> 
>> I have updated the draft today in order to address the concerns for 
>> unnumbered interface and sub-TLV hierarchy that raised by Peter and Les. 
>> Please review it if there exists any other concerns.
>> 
>> Thanks.
>> 
>> 
>> Aijun Wang
>> China Telecom
>> 
 On Jan 11, 2022, at 20:55, Christian Hopps  wrote:
>>> 
>>> 
>>> Peter Psenak  writes:
>>> 
 Aijun,
 
> On 05/01/2022 16:20, Aijun Wang wrote:
> [WAJ] The above remote information must be configured manually on the 
> local
> device. It is paired by manual. Thinking there are many links among the 
> ASBRs,
> would you like to configure them manually for every remote ends on each 
> link?
>>> 
>>> No one with large scale networks, and/or routers with lots of links is 
>>> doing any sort of manual configuration. It seems to me that I keep seeing 
>>> this mentioned as justification for changes or extensions to the IGPs. It 
>>> is not reasonable justification b/c no-one is doing it.
>>> 
>>> I think it would be very useful if manual configuration or the assumption 
>>> that we need to make that less painful, stopped being brought up so we can 
>>> focus on other reasonable justifications (or lack thereof :)
>>> 
>>> Thanks,
>>> Chris.
>>> [as wg member]
>>> 
>>> 
> The prefixes that associated with the stub link can assist to accomplish 
> this task automatically.
 
 If the ISIS/OSPF adjacency is not formed over the link, you need to 
 manually
 configure remote endpoint parameters. Defining a new TLV is not going to 
 make
 any difference.
 
 Using the local subnet information for identifying two endpoints of the 
 same
 link does not sound appealing to me.
 
 We have link local/remote IDs (and IP addresses) to pair the two endpoints 
 of
 the link in both OSPF and ISIS. We do not need another mechanism for the 
 same.
 In addition, what you propose does not work for unnumbered links.
 
 I don't see a need for the new stub-link advertisement.
 
 thanks,
 Peter
 
 
 ___
 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-wang-lsr-stub-link-attributes-02

[Christian Hopps]

Doesn't this reduce to: "The operator configures one of their routers with an 
IGP "passive" link config, and then uses this IGP extension so their other 
routers (in the same AS) can discover that configuration"?

Thanks,
Chris.
[as wg member]


> On Jan 11, 2022, at 8:51 AM, Aijun Wang  wrote:
> 
> Hi, Christian:
> 
> The benefit of the proposed solution is that for inter-AS scenarios, it can 
> accomplish the automatic pairing for the two ends of inter-AS link without 
> the explicitly configuration for the remote end information.
> In other scenarios,  it can also contain useful information for the edge 
> computation services, aid the operator know exactly the boundary of the 
> network and apply special security policy at such stub link if necessary etc.
> 
> I have updated the draft today in order to address the concerns for 
> unnumbered interface and sub-TLV hierarchy that raised by Peter and Les. 
> Please review it if there exists any other concerns.
> 
> Thanks.
> 
> 
> Aijun Wang
> China Telecom
> 
>> On Jan 11, 2022, at 20:55, Christian Hopps  wrote:
>> 
>> 
>> Peter Psenak  writes:
>> 
>>> Aijun,
>>> 
 On 05/01/2022 16:20, Aijun Wang wrote:
 [WAJ] The above remote information must be configured manually on the local
 device. It is paired by manual. Thinking there are many links among the 
 ASBRs,
 would you like to configure them manually for every remote ends on each 
 link?
>> 
>> No one with large scale networks, and/or routers with lots of links is doing 
>> any sort of manual configuration. It seems to me that I keep seeing this 
>> mentioned as justification for changes or extensions to the IGPs. It is not 
>> reasonable justification b/c no-one is doing it.
>> 
>> I think it would be very useful if manual configuration or the assumption 
>> that we need to make that less painful, stopped being brought up so we can 
>> focus on other reasonable justifications (or lack thereof :)
>> 
>> Thanks,
>> Chris.
>> [as wg member]
>> 
>> 
 The prefixes that associated with the stub link can assist to accomplish 
 this task automatically.
>>> 
>>> If the ISIS/OSPF adjacency is not formed over the link, you need to manually
>>> configure remote endpoint parameters. Defining a new TLV is not going to 
>>> make
>>> any difference.
>>> 
>>> Using the local subnet information for identifying two endpoints of the same
>>> link does not sound appealing to me.
>>> 
>>> We have link local/remote IDs (and IP addresses) to pair the two endpoints 
>>> of
>>> the link in both OSPF and ISIS. We do not need another mechanism for the 
>>> same.
>>> In addition, what you propose does not work for unnumbered links.
>>> 
>>> I don't see a need for the new stub-link advertisement.
>>> 
>>> thanks,
>>> Peter
>>> 
>>> 
>>> ___
>>> 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-wang-lsr-stub-link-attributes-02

[Tony Li]

Hi Aijun,

> 
> It would seem to me that if you re-used existing TLVs, you could be adding 
> subTLVs to carry any additional information.  This would probably be a lot 
> cleaner.
> [WAJ] Then we should update RFC5316, RFC5292, RFC3630 etc. It may also 
> influence the existing deployment. 
> There are also other situations that the RFC5316 and RFC5292 does not cover, 
> for example, for the associated information that the edge computing wants to 
> utilize etc.
> Start from the clean slate will be more acceptable?


Yes, I’m suggesting that you consider a way of using existing TLVs and adding 
subTLVs to them in order to convey the information.

A big point of using TLV encoding in the first place is to provide 
extensibility. It would be a design error not to use it, when appropriate. 
Creating a new entity every time you add a feature leads to more complexity in 
the design and in the resulting code.

Tony

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Zhuangshunwan]

Hi WG,

I have read the updated draft and think it has already addressed the 
comments/issues that raised until now. It is an valuable work for the inter-AS 
topology recovery and the edge computing service optimization.
I support its adoption.

Best Regards,
Shunwan

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Tuesday, January 4, 2022 2:59 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

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

https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

Please indicate your support or objections by January 18th, 2022.

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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Chengli (Cheng Li)]

Hi 

This is a useful document, and it looks mature to  me though it is very short, 
so I support the adoption.

Thanks,
Cheng


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Tuesday, January 4, 2022 2:59 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

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

https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

Please indicate your support or objections by January 18th, 2022.

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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Tony:

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Wednesday, January 12, 2022 4:24 AM
To: Aijun Wang 
Cc: lsr ; lsr-...@ietf.org; Christian Hopps ; 
draft-wang-lsr-stub-link-attribu...@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02


Hi Aijun,

> We are trying to reuse the existing mechanism to solve such problem, but as 
> mentioned in 
> https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/:


This link doesn’t work.
[WAJ] I checked the above link again and it work from my side. Anyway, I have 
copied the key points of the above link in the following sentences.


> "[WAJ] Reuse the Link TLV that defined in inter-AS-TE-v2/v3 to contain such 
> information is possible, but we should still to define the link type(as that 
> in RFC3630) to identify the stub-link, also the prefixes related sub-TLV.  
> Comparing the two different approaches, we select to define one new sub-TLV 
> to contain the above information in one place together."
> 
> And as mentioned in Les, there are strict requirement for the inclusion of 
> "Remote-AS", "IPv4/IPv6 Remote ASBR ID" sub-TLV in RFC5316(similar for 
> RFC5292). In almost all of the inter-AS scenario(numbered inter-as links), 
> these information needn't be configured and transferred.
> 
> Then redefine the new stub-link TLV is the reasonable way, it also provides 
> the container for other possible information.



It would seem to me that if you re-used existing TLVs, you could be adding 
subTLVs to carry any additional information.  This would probably be a lot 
cleaner.
[WAJ] Then we should update RFC5316, RFC5292, RFC3630 etc. It may also 
influence the existing deployment. 
There are also other situations that the RFC5316 and RFC5292 does not cover, 
for example, for the associated information that the edge computing wants to 
utilize etc.
Start from the clean slate will be more acceptable?

T

___
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-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Les:

I think we should find the most efficient way to accomplish the work.
The draft that is adopting, or is adopted, or is in the WGLC or in the IESG 
view process is reasonable to be updated to address the comments during the 
process.
I think update the draft accordingly to address the issues raised during the 
call demonstrate the authors are listening the feedback, and it also help the 
following readers to review it on the latest version, and are not hindered by 
the past/solved issues.

Such interaction can certainly improve the quality and efficiency of our work.

We are glad to hear more comments on the updated version of this draft. 
I think defining such new TLV within OSPF/ISIS can give more flexibility for 
the application of IGP protocol/information, especially for constrained based 
SPF(flexalgo) or controller based application.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Tuesday, January 11, 2022 11:06 PM
To: Aijun Wang 
Cc: 'Christian Hopps' ; lsr@ietf.org; lsr-cha...@ietf.org; 
lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun -

I am aware that, subsequent to this email, you posted a revised version of the 
draft. But in regards to how I prefer to move forward I am choosing to respond 
to this email.

It is important to remember that this thread is a 2 week WG adoption call. The 
primary purpose of this thread is to determine the WG consensus as to whether 
the draft is ready for adoption - not to do major revisions of the draft. 

I believe you have received meaningful feedback from multiple WG members that 
indicate there are significant issues with the draft in its current form. The 
issues raised question not just the implementation details, but whether the 
goals of the draft as currently stated are desirable. This, in my mind, is 
sufficient to conclude that the draft in its current form is NOT ready for WG 
adoption. The new version you posted does not come close to fully addressing 
these issues.

The most practical way forward (IMO of course) is for you to voluntarily 
withdraw your request for WG adoption. This will give you an opportunity to 
address the substantive issues that have been raised. It will also demonstrate 
that you are listening to the feedback being given. 

You can, of course, choose not to follow this path - in which case it will fall 
to the WG Chairs to determine the outcome of the adoption call.

Thanx.

   Les


> -Original Message-
> From: Aijun Wang 
> Sent: Monday, January 10, 2022 10:19 PM
> To: Les Ginsberg (ginsberg) 
> Cc: 'Christian Hopps' ; lsr@ietf.org; 
> lsr-cha...@ietf.org; lsr-...@ietf.org; 
> draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: RE: [Lsr] WG Adoption Call for 
> draft-wang-lsr-stub-link-attributes-02
> 
> Hi, Les:
> 
> There is the way to solve your concern.
> 1. 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attribu
> tes-
> 02#section-4.1 and 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-
> stub-link-attributes-02#section-4.2 includes also the sub-TLVs field, 
> which is pointed to the corresponding part for TE-Link TLV(for OSPF) 
> and Inter-AS Reachability TLV (TLV 141).
>   That is to say, the draft doesn't preclude the inclusion of 
> Remote-AS,
> IPv4/IPv6 remote ASBR Identifier sub TLV.
>   So, if you insist that the unnumbered link will be used between the 
> ASes, then for such stub-link type(we can add one new stub link type), 
> the operator should configure the remote information manually. And for 
> such stub link type, the Remote-AS/IPv4/IPv6 Identifier sub TLV MUST 
> be included(same as the rules defined in RFC5316).
>   For other numbered interface, such information needn't be manually 
> configured. This can certainly save the cost for management of the 
> network, and also meet your mentioned scenario.
>   Is it OK for you?
> 
> 2. For the consideration of current extension violate the rules 
> defined in RFC5316, I have proposed another solution at 
> https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/
> upon the comments from Peter. That is to say:
>   "[WAJ] It seems to define one new TLV that at the same level of 
> “Inter-AS reachability TLV”, for example “Stub-Link reachability TLV” 
> is better. If acceptable, will update the draft."
> 
> For the above two proposals, do you have other comments? If not, will 
> update the draft to reflect it.
> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, January 11, 2022 3:50 AM
> To: Aijun Wang 
> Cc: Christian Hopps ; lsr@ietf.org; 
> lsr-cha...@ietf.org; lsr-

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Tony Li]

Hi Aijun,

> We are trying to reuse the existing mechanism to solve such problem, but as 
> mentioned in 
> https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/:


This link doesn’t work.


> "[WAJ] Reuse the Link TLV that defined in inter-AS-TE-v2/v3 to contain such 
> information is possible, but we should still to define the link type(as that 
> in RFC3630) to identify the stub-link, also the prefixes related sub-TLV.  
> Comparing the two different approaches, we select to define one new sub-TLV 
> to contain the above information in one place together."
> 
> And as mentioned in Les, there are strict requirement for the inclusion of 
> "Remote-AS", "IPv4/IPv6 Remote ASBR ID" sub-TLV in RFC5316(similar for 
> RFC5292). In almost all of the inter-AS scenario(numbered inter-as links), 
> these information needn't be configured and transferred.
> 
> Then redefine the new stub-link TLV is the reasonable way, it also provides 
> the container for other possible information.



It would seem to me that if you re-used existing TLVs, you could be adding 
subTLVs to carry any additional information.  This would probably be a lot 
cleaner.

T

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Les Ginsberg (ginsberg)]

Aijun -

I am aware that, subsequent to this email, you posted a revised version of the 
draft. But in regards to how I prefer to move forward I am choosing to respond 
to this email.

It is important to remember that this thread is a 2 week WG adoption call. The 
primary purpose of this thread is to determine the WG consensus as to whether 
the draft is ready for adoption - not to do major revisions of the draft. 

I believe you have received meaningful feedback from multiple WG members that 
indicate there are significant issues with the draft in its current form. The 
issues raised question not just the implementation details, but whether the 
goals of the draft as currently stated are desirable. This, in my mind, is 
sufficient to conclude that the draft in its current form is NOT ready for WG 
adoption. The new version you posted does not come close to fully addressing 
these issues.

The most practical way forward (IMO of course) is for you to voluntarily 
withdraw your request for WG adoption. This will give you an opportunity to 
address the substantive issues that have been raised. It will also demonstrate 
that you are listening to the feedback being given. 

You can, of course, choose not to follow this path - in which case it will fall 
to the WG Chairs to determine the outcome of the adoption call.

Thanx.

   Les


> -Original Message-
> From: Aijun Wang 
> Sent: Monday, January 10, 2022 10:19 PM
> To: Les Ginsberg (ginsberg) 
> Cc: 'Christian Hopps' ; lsr@ietf.org; lsr-cha...@ietf.org;
> lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> 
> Hi, Les:
> 
> There is the way to solve your concern.
> 1. https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-
> 02#section-4.1 and https://datatracker.ietf.org/doc/html/draft-wang-lsr-
> stub-link-attributes-02#section-4.2 includes also the sub-TLVs field, which is
> pointed to the corresponding part for TE-Link TLV(for OSPF) and Inter-AS
> Reachability TLV (TLV 141).
>   That is to say, the draft doesn't preclude the inclusion of Remote-AS,
> IPv4/IPv6 remote ASBR Identifier sub TLV.
>   So, if you insist that the unnumbered link will be used between the ASes,
> then for such stub-link type(we can add one new stub link type), the
> operator should configure the remote information manually. And for such
> stub link type, the Remote-AS/IPv4/IPv6 Identifier sub TLV MUST be
> included(same as the rules defined in RFC5316).
>   For other numbered interface, such information needn't be manually
> configured. This can certainly save the cost for management of the network,
> and also meet your mentioned scenario.
>   Is it OK for you?
> 
> 2. For the consideration of current extension violate the rules defined in
> RFC5316, I have proposed another solution at
> https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/
> upon the comments from Peter. That is to say:
>   "[WAJ] It seems to define one new TLV that at the same level of “Inter-AS
> reachability TLV”, for example “Stub-Link reachability TLV” is better. If
> acceptable, will update the draft."
> 
> For the above two proposals, do you have other comments? If not, will
> update the draft to reflect it.
> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, January 11, 2022 3:50 AM
> To: Aijun Wang 
> Cc: Christian Hopps ; lsr@ietf.org; lsr-cha...@ietf.org;
> lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> 
> Aijun -
> 
> Please see inline.
> 
> > -Original Message-
> > From: Aijun Wang 
> > Sent: Monday, January 10, 2022 8:34 AM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Christian Hopps ; lsr@ietf.org;
> > lsr-cha...@ietf.org; lsr-...@ietf.org;
> > draft-wang-lsr-stub-link-attribu...@ietf.org
> > Subject: Re: [Lsr] WG Adoption Call for
> > draft-wang-lsr-stub-link-attributes-02
> >
> > Hi, Les:
> >
> > Wish the below explanation can correct your understanding of this
> > draft, and also your conclusions.
> >
> > Aijun Wang
> > China Telecom
> >
> > > On Jan 10, 2022, at 23:13, Les Ginsberg (ginsberg)
> >  wrote:
> > >
> > > I oppose WG adoption of this draft.
> > >
> > > In addition to my comments below, I am in agreement with the points
> > made by Peter and Shraddha previously in this thread.
> > >
> > > My comments below are in the context of IS-IS/RFC5316, but I believe
> > > are
> > equally valid in t

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Christian:

The benefit of the proposed solution is that for inter-AS scenarios, it can 
accomplish the automatic pairing for the two ends of inter-AS link without the 
explicitly configuration for the remote end information.
In other scenarios,  it can also contain useful information for the edge 
computation services, aid the operator know exactly the boundary of the network 
and apply special security policy at such stub link if necessary etc.

I have updated the draft today in order to address the concerns for unnumbered 
interface and sub-TLV hierarchy that raised by Peter and Les. Please review it 
if there exists any other concerns.

Thanks.


Aijun Wang
China Telecom

> On Jan 11, 2022, at 20:55, Christian Hopps  wrote:
> 
> 
> Peter Psenak  writes:
> 
>> Aijun,
>> 
>>> On 05/01/2022 16:20, Aijun Wang wrote:
>>> [WAJ] The above remote information must be configured manually on the local
>>> device. It is paired by manual. Thinking there are many links among the 
>>> ASBRs,
>>> would you like to configure them manually for every remote ends on each 
>>> link?
> 
> No one with large scale networks, and/or routers with lots of links is doing 
> any sort of manual configuration. It seems to me that I keep seeing this 
> mentioned as justification for changes or extensions to the IGPs. It is not 
> reasonable justification b/c no-one is doing it.
> 
> I think it would be very useful if manual configuration or the assumption 
> that we need to make that less painful, stopped being brought up so we can 
> focus on other reasonable justifications (or lack thereof :)
> 
> Thanks,
> Chris.
> [as wg member]
> 
> 
>>> The prefixes that associated with the stub link can assist to accomplish 
>>> this task automatically.
>> 
>> If the ISIS/OSPF adjacency is not formed over the link, you need to manually
>> configure remote endpoint parameters. Defining a new TLV is not going to make
>> any difference.
>> 
>> Using the local subnet information for identifying two endpoints of the same
>> link does not sound appealing to me.
>> 
>> We have link local/remote IDs (and IP addresses) to pair the two endpoints of
>> the link in both OSPF and ISIS. We do not need another mechanism for the 
>> same.
>> In addition, what you propose does not work for unnumbered links.
>> 
>> I don't see a need for the new stub-link advertisement.
>> 
>> thanks,
>> Peter
>> 
>> 
>> ___
>> 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-wang-lsr-stub-link-attributes-02

[Christian Hopps]

Peter Psenak  writes:


Aijun,

On 05/01/2022 16:20, Aijun Wang wrote:

[WAJ] The above remote information must be configured manually on the local
device. It is paired by manual. Thinking there are many links among the ASBRs,
would you like to configure them manually for every remote ends on each link?


No one with large scale networks, and/or routers with lots of links is doing 
any sort of manual configuration. It seems to me that I keep seeing this 
mentioned as justification for changes or extensions to the IGPs. It is not 
reasonable justification b/c no-one is doing it.

I think it would be very useful if manual configuration or the assumption that 
we need to make that less painful, stopped being brought up so we can focus on 
other reasonable justifications (or lack thereof :)

Thanks,
Chris.
[as wg member]



The prefixes that associated with the stub link can assist to accomplish this 
task automatically.


If the ISIS/OSPF adjacency is not formed over the link, you need to manually
configure remote endpoint parameters. Defining a new TLV is not going to make
any difference.

Using the local subnet information for identifying two endpoints of the same
link does not sound appealing to me.

We have link local/remote IDs (and IP addresses) to pair the two endpoints of
the link in both OSPF and ISIS. We do not need another mechanism for the same.
In addition, what you propose does not work for unnumbered links.

I don't see a need for the new stub-link advertisement.

thanks,
Peter


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




signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[chen.ran]

Hi WG,Support adoption.Best Regards,


Ran






-Original Message-From: lsr-boun...@ietf.org  On 
Behalf Of ChristianHoppsSent: Tuesday, January 4, 2022 2:59 PMTo: 
lsr@ietf.orgCc: lsr-cha...@ietf.org; lsr-...@ietf.org; 
cho...@chopps.org;draft-wang-lsr-stub-link-attributes@ietf.orgSubject: [Lsr] WG 
Adoption Call for draft-wang-lsr-stub-link-attributes-02Hi Folks,This begins a 
2 week WG Adoption Call for the following 
draft:https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/Please
 indicate your support or objections by January 18th, 2022.Authors, please 
respond to the list indicating whether you are aware of anyIPR that applies to 
these drafts.Thanks,Chris.___Lsr 
mailing 
listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___Lsr
 mailing listLsr@ietf.orghttps://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-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, All experts:

Upon the responses from this adoption call, we have updated to the draft
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes to
address the comments received from now.
If you have still other concerns, please responses.
We are glad to address your concerns during the adoption call process.

The updated contents are mainly the followings:
1. Adding the description for the "Unnumbered AS boundary link" and the MUST
associated sub-TLVs.
2. Define the Top-Level TLV for IS-IS---"Stub-Link TLV", instead of putting
it under the inter-AS reachability TLV(141).

The above updates align the OSPF and IS-IS and the existing defined sub-TLVs
in more reasonable style.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Christian
Hopps
Sent: Tuesday, January 4, 2022 2:59 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org;
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

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

https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

Please indicate your support or objections by January 18th, 2022.

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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Tony:

We are trying to reuse the existing mechanism to solve such problem, but as 
mentioned in 
https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/:

"[WAJ] Reuse the Link TLV that defined in inter-AS-TE-v2/v3 to contain such 
information is possible, but we should still to define the link type(as that in 
RFC3630) to identify the stub-link, also the prefixes related sub-TLV.  
Comparing the two different approaches, we select to define one new sub-TLV to 
contain the above information in one place together."

And as mentioned in Les, there are strict requirement for the inclusion of 
"Remote-AS", "IPv4/IPv6 Remote ASBR ID" sub-TLV in RFC5316(similar for 
RFC5292). In almost all of the inter-AS scenario(numbered inter-as links), 
these information needn't be configured and transferred.

Then redefine the new stub-link TLV is the reasonable way, it also provides the 
container for other possible information.


Best Regards

Aijun Wang
China Telecom


-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Tuesday, January 11, 2022 2:39 PM
To: Aijun Wang 
Cc: lsr ; lsr-...@ietf.org; Christian Hopps ; 
lsr-cha...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02


Hi Aijun,

> For the AS boundary use case, do you have other better solution? 


Is there some way that this could be modeled as a normal link instead of a stub 
link?  In any case, I am not responsible for coming up with a better solution. 
The onus is on you to convince us that this is a Good Thing to do.


> I have responded to Les for his mentioned/insisted unnumbered link scenario. 
> if it is acceptable, is it the general design then?


I don’t understand this comment. I agree with Les that unnumbered links are 
important.

Tony

___
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-wang-lsr-stub-link-attributes-02

[Tony Li]

Hi Aijun,

> For the AS boundary use case, do you have other better solution? 


Is there some way that this could be modeled as a normal link instead of a stub 
link?  In any case, I am not responsible for coming up with a better solution. 
The onus is on you to convince us that this is a Good Thing to do.


> I have responded to Les for his mentioned/insisted unnumbered link scenario. 
> if it is acceptable, is it the general design then?


I don’t understand this comment. I agree with Les that unnumbered links are 
important.

Tony

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Tony:

For the AS boundary use case, do you have other better solution? 
I have responded to Les for his mentioned/insisted unnumbered link scenario. if 
it is acceptable, is it the general design then?

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Tuesday, January 11, 2022 4:38 AM
To: Christian Hopps 
Cc: lsr ; lsr-...@ietf.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02


I object to the adoption of this draft. 

I don’t think that it’s fundamentally a correct approach.

One of the important things that we’ve learned over the years is that we need 
to build general designs and not simply add new elements and mechanisms for 
each use case that we think of.

I understand the AS boundary use case. I agree that’s worthy of consideration. 
Not so much the others.

I would suggest that the authors spend a bit more time cogitating.

Regards,
Tony


> On Jan 3, 2022, at 10:58 PM, Christian Hopps  wrote:
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> 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

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Les:

There is the way to solve your concern.
1. 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02#section-4.1
 and 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02#section-4.2
 includes also the sub-TLVs field, which is pointed to the corresponding part 
for TE-Link TLV(for OSPF) and Inter-AS Reachability TLV (TLV 141).
  That is to say, the draft doesn't preclude the inclusion of Remote-AS, 
IPv4/IPv6 remote ASBR Identifier sub TLV.
  So, if you insist that the unnumbered link will be used between the ASes, 
then for such stub-link type(we can add one new stub link type), the operator 
should configure the remote information manually. And for such stub link type, 
the Remote-AS/IPv4/IPv6 Identifier sub TLV MUST be included(same as the rules 
defined in RFC5316).
  For other numbered interface, such information needn't be manually 
configured. This can certainly save the cost for management of the network, and 
also meet your mentioned scenario.
  Is it OK for you?

2. For the consideration of current extension violate the rules defined in 
RFC5316, I have proposed another solution at 
https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/ upon the 
comments from Peter. That is to say:
  "[WAJ] It seems to define one new TLV that at the same level of “Inter-AS 
reachability TLV”, for example “Stub-Link reachability TLV” is better. If 
acceptable, will update the draft."

For the above two proposals, do you have other comments? If not, will update 
the draft to reflect it.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Tuesday, January 11, 2022 3:50 AM
To: Aijun Wang 
Cc: Christian Hopps ; lsr@ietf.org; lsr-cha...@ietf.org; 
lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun -

Please see inline.

> -Original Message-
> From: Aijun Wang 
> Sent: Monday, January 10, 2022 8:34 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Christian Hopps ; lsr@ietf.org; 
> lsr-cha...@ietf.org; lsr-...@ietf.org; 
> draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for 
> draft-wang-lsr-stub-link-attributes-02
> 
> Hi, Les:
> 
> Wish the below explanation can correct your understanding of this 
> draft, and also your conclusions.
> 
> Aijun Wang
> China Telecom
> 
> > On Jan 10, 2022, at 23:13, Les Ginsberg (ginsberg)
>  wrote:
> >
> > I oppose WG adoption of this draft.
> >
> > In addition to my comments below, I am in agreement with the points
> made by Peter and Shraddha previously in this thread.
> >
> > My comments below are in the context of IS-IS/RFC5316, but I believe 
> > are
> equally valid in the context of OSPF/RFC5392.
> >
> > There are two types of new information the draft proposes to 
> > advertise
> under TLV 141:
> >
> > 1)Identifying a link by the prefix locally configured on the link 
> > rather than by
> the local/remote addresses.
> >
> > The motivation for this addition seems to be to avoid the need for 
> > the
> operator to locally configure the remote address.
> [WAJ] For inter-AS stub link type, it is. For other stub link type, it isn’t.
> 
> > But I think this is not a desirable change.
> >
> > As pointed out by Peter, this does not work for unnumbered links. 
> > (It also
> would not work for Pt-2-MP links). The authors assert that it is 
> unlikely that unnumbered links would be used in the expected use cases 
> - but I do not find this argument convincing.
> [WAJ] Is there any operator adopt unnumbered link at its boundary 
> network? There is even very rare case for the unnumbered interface be 
> used within the operator network. And, with the IPv6 deployment, what 
> is the usages of unnumbered interface? Won’t it be depreciated in future?
> Very curious you and Peter stick to this point, but not considering 
> its wider use scenarios.
> 
[LES:] Aijun - Unnumbered links are in common usage today. We should not define 
extensions which do not allow support for this.

> > Even if unnumbered links are not currently being used, the 
> > restriction that
> they could not be used in the future seems highly undesirable.
> 
> [WAJ] Would like to hear the reason and scenarios that the unnumbered 
> interface will be used in future. I think it should be deprecated instead.

[LES:] Deprecating the use of unnumbered is outside the scope of this 
specification - and I would argue is not something we (the WG) should be 
advocating in any case.

> 
> > It would put us in the position of having to revise this 
> > functionality in the
> future in an incompatib

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Tony Li]

I object to the adoption of this draft. 

I don’t think that it’s fundamentally a correct approach.

One of the important things that we’ve learned over the years is that we need 
to build general designs and not simply add new elements and mechanisms for 
each use case that we think of.

I understand the AS boundary use case. I agree that’s worthy of consideration. 
Not so much the others.

I would suggest that the authors spend a bit more time cogitating.

Regards,
Tony


> On Jan 3, 2022, at 10:58 PM, Christian Hopps  wrote:
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> 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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Les Ginsberg (ginsberg)]

Aijun -

Please see inline.

> -Original Message-
> From: Aijun Wang 
> Sent: Monday, January 10, 2022 8:34 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Christian Hopps ; lsr@ietf.org; lsr-cha...@ietf.org;
> lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> 
> Hi, Les:
> 
> Wish the below explanation can correct your understanding of this draft, and
> also your conclusions.
> 
> Aijun Wang
> China Telecom
> 
> > On Jan 10, 2022, at 23:13, Les Ginsberg (ginsberg)
>  wrote:
> >
> > I oppose WG adoption of this draft.
> >
> > In addition to my comments below, I am in agreement with the points
> made by Peter and Shraddha previously in this thread.
> >
> > My comments below are in the context of IS-IS/RFC5316, but I believe are
> equally valid in the context of OSPF/RFC5392.
> >
> > There are two types of new information the draft proposes to advertise
> under TLV 141:
> >
> > 1)Identifying a link by the prefix locally configured on the link rather 
> > than by
> the local/remote addresses.
> >
> > The motivation for this addition seems to be to avoid the need for the
> operator to locally configure the remote address.
> [WAJ] For inter-AS stub link type, it is. For other stub link type, it isn’t.
> 
> > But I think this is not a desirable change.
> >
> > As pointed out by Peter, this does not work for unnumbered links. (It also
> would not work for Pt-2-MP links). The authors assert that it is unlikely that
> unnumbered links would be used in the expected use cases - but I do not
> find this argument convincing.
> [WAJ] Is there any operator adopt unnumbered link at its boundary
> network? There is even very rare case for the unnumbered interface be
> used within the operator network. And, with the IPv6 deployment, what is
> the usages of unnumbered interface? Won’t it be depreciated in future?
> Very curious you and Peter stick to this point, but not considering its wider
> use scenarios.
> 
[LES:] Aijun - Unnumbered links are in common usage today. We should not define 
extensions which do not allow support for this.

> > Even if unnumbered links are not currently being used, the restriction that
> they could not be used in the future seems highly undesirable.
> 
> [WAJ] Would like to hear the reason and scenarios that the unnumbered
> interface will be used in future. I think it should be deprecated instead.

[LES:] Deprecating the use of unnumbered is outside the scope of this 
specification - and I would argue is not something we (the WG) should be 
advocating in any case.

> 
> > It would put us in the position of having to revise this functionality in 
> > the
> future in an incompatible way in order to add such support. This is a bad
> design choice.
> 
> [WAJ] We should keep the trend, not stick to the obsolete obstacles.

[LES:] Unnumbered is not obsolete - it is only you who have arbitrarily decided 
that it is no longer needed.

> 
> >
> > Aside: The assertion that unnumbered links will not be used seems at odds
> with the inclusion of "loopback" as a link type.
> 
> [WAJ] The loop back address won’t borrow address from others. Or if you
> consider it maybe, please give the reason.
> 
> > More on that below.
> >
> > Also, as the draft builds on top of existing RFC5316 functionality, it is 
> > still
> required to advertise remote AS Number and Remote ASBR ID as well as
> remote Router IDs (IPv4 and/or IPv6) (see
> https://datatracker.ietf.org/doc/html/rfc5316#section-3.3 )
> 
> [WAJ] No. With the newly defined TLV/sun-TLV, we need not configured the
> above information manually then. And for other stub link type(for example,
> the edge router that connects the server) there will be no remote-AS, no
> remote ASBR, how can you configure them?
>
[LES:] Indeed - which means your extensions to TLV 141 violate RFC 5316. Please 
read the referenced section I provided and pay attention to the normative 
statements ("MUST") there.
So, RFC 5316 conformant implementations will not accept the TLVs you apparently 
intend to send.
This is not something which can be ignored.

 
> > - all of which still need to be locally configured since there is no IGP
> operating on the link. So the suggestion that not having to configure the
> remote link address provides significant simplification in deployment does
> not stand up to scrutiny.
> 
> [WAJ] Please see the previous explanation.
> >
> > 2)New link type information (AS boundary link/Loopback link/Vlan
> interface link) to be advertised
> >
> > There is no mention in t

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Les:

Wish the below explanation can correct your understanding of this draft, and 
also your conclusions.

Aijun Wang
China Telecom

> On Jan 10, 2022, at 23:13, Les Ginsberg (ginsberg) 
>  wrote:
> 
> I oppose WG adoption of this draft.
> 
> In addition to my comments below, I am in agreement with the points made by 
> Peter and Shraddha previously in this thread.
> 
> My comments below are in the context of IS-IS/RFC5316, but I believe are 
> equally valid in the context of OSPF/RFC5392.
> 
> There are two types of new information the draft proposes to advertise under 
> TLV 141:
> 
> 1)Identifying a link by the prefix locally configured on the link rather than 
> by the local/remote addresses.
> 
> The motivation for this addition seems to be to avoid the need for the 
> operator to locally configure the remote address.
[WAJ] For inter-AS stub link type, it is. For other stub link type, it isn’t. 

> But I think this is not a desirable change.
> 
> As pointed out by Peter, this does not work for unnumbered links. (It also 
> would not work for Pt-2-MP links). The authors assert that it is unlikely 
> that unnumbered links would be used in the expected use cases - but I do not 
> find this argument convincing.
[WAJ] Is there any operator adopt unnumbered link at its boundary network? 
There is even very rare case for the unnumbered interface be used within the 
operator network. And, with the IPv6 deployment, what is the usages of 
unnumbered interface? Won’t it be depreciated in future? Very curious you and 
Peter stick to this point, but not considering its wider use scenarios.

> Even if unnumbered links are not currently being used, the restriction that 
> they could not be used in the future seems highly undesirable.

[WAJ] Would like to hear the reason and scenarios that the unnumbered interface 
will be used in future. I think it should be deprecated instead.

> It would put us in the position of having to revise this functionality in the 
> future in an incompatible way in order to add such support. This is a bad 
> design choice.

[WAJ] We should keep the trend, not stick to the obsolete obstacles.

> 
> Aside: The assertion that unnumbered links will not be used seems at odds 
> with the inclusion of "loopback" as a link type.

[WAJ] The loop back address won’t borrow address from others. Or if you 
consider it maybe, please give the reason.

> More on that below.
> 
> Also, as the draft builds on top of existing RFC5316 functionality, it is 
> still required to advertise remote AS Number and Remote ASBR ID as well as 
> remote Router IDs (IPv4 and/or IPv6) (see 
> https://datatracker.ietf.org/doc/html/rfc5316#section-3.3 )

[WAJ] No. With the newly defined TLV/sun-TLV, we need not configured the above 
information manually then. And for other stub link type(for example, the edge 
router that connects the server) there will be no remote-AS, no remote ASBR, 
how can you configure them?

> - all of which still need to be locally configured since there is no IGP 
> operating on the link. So the suggestion that not having to configure the 
> remote link address provides significant simplification in deployment does 
> not stand up to scrutiny.

[WAJ] Please see the previous explanation.
> 
> 2)New link type information (AS boundary link/Loopback link/Vlan interface 
> link) to be advertised
> 
> There is no mention in the draft as to how this information will be used.
[WAJ] The information about various stub link type is mainly for the 
controller. If necessary, we can add some potential use cases for such type 
information, but this is not the main points of this draft.

> Indeed, I do not even know what a "loopback link" is unless it is an 
> unnumbered link to which a loopback address has been associated - which makes 
> me wonder why the authors have dismissed the use of "unnumbered" in 
> deployments.

[WAJ] Actually, it is loopback interface, not loopback link, which you have 
imaged that one unnumbered link borrows the address from the loopback interface.
The loopback interface is one type of Stub Link, which has the characters that 
doesn’t send out IGP LSA.


> 
> I therefore conclude that existing functionality defined in RFC 5316/RFC5392 
> is sufficient and there is no need for the extensions defined in this draft.
[WAJ] Wish the above explanation can correct your conclusions.

> 
>Les
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Christian Hopps
>> Sent: Monday, January 3, 2022 10:59 PM
>> To: lsr@ietf.org
>> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; draft-wang-lsr-
>> stub-link-attribu...@ietf.org
>> Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
>> 
>> Hi

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Les Ginsberg (ginsberg)]

I oppose WG adoption of this draft.

In addition to my comments below, I am in agreement with the points made by 
Peter and Shraddha previously in this thread.

My comments below are in the context of IS-IS/RFC5316, but I believe are 
equally valid in the context of OSPF/RFC5392.

There are two types of new information the draft proposes to advertise under 
TLV 141:

1)Identifying a link by the prefix locally configured on the link rather than 
by the local/remote addresses.

The motivation for this addition seems to be to avoid the need for the operator 
to locally configure the remote address. But I think this is not a desirable 
change.

As pointed out by Peter, this does not work for unnumbered links. (It also 
would not work for Pt-2-MP links). The authors assert that it is unlikely that 
unnumbered links would be used in the expected use cases - but I do not find 
this argument convincing. Even if unnumbered links are not currently being 
used, the restriction that they could not be used in the future seems highly 
undesirable. It would put us in the position of having to revise this 
functionality in the future in an incompatible way in order to add such 
support. This is a bad design choice.

Aside: The assertion that unnumbered links will not be used seems at odds with 
the inclusion of "loopback" as a link type. More on that below.

Also, as the draft builds on top of existing RFC5316 functionality, it is still 
required to advertise remote AS Number and Remote ASBR ID as well as remote 
Router IDs (IPv4 and/or IPv6) (see 
https://datatracker.ietf.org/doc/html/rfc5316#section-3.3 ) - all of which 
still need to be locally configured since there is no IGP operating on the 
link. So the suggestion that not having to configure the remote link address 
provides significant simplification in deployment does not stand up to scrutiny.

2)New link type information (AS boundary link/Loopback link/Vlan interface 
link) to be advertised

There is no mention in the draft as to how this information will be used. 
Indeed, I do not even know what a "loopback link" is unless it is an unnumbered 
link to which a loopback address has been associated - which makes me wonder 
why the authors have dismissed the use of "unnumbered" in deployments.

I therefore conclude that existing functionality defined in RFC 5316/RFC5392 is 
sufficient and there is no need for the extensions defined in this draft.

Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Monday, January 3, 2022 10:59 PM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; draft-wang-lsr-
> stub-link-attribu...@ietf.org
> Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> 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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Linda Dunbar]

Hi Everyone,

I read the draft and support its adoption.

Best Regards,
Linda Dunbar


From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Christian Hopps mailto:cho...@chopps.org>>
Sent: Tuesday, January 4, 2022 1:58 AM
To: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> 
mailto:lsr-cha...@ietf.org>>; 
lsr-...@ietf.org<mailto:lsr-...@ietf.org> 
mailto:lsr-...@ietf.org>>; 
cho...@chopps.org<mailto:cho...@chopps.org> 
mailto:cho...@chopps.org>>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
 
mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>>
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

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

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-stub-link-attributes%2Fdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=KDGtq1muOp7w7TzMB2oc8gHF93GFFZJ2U2oArusK7rA%3Dreserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-stub-link-attributes%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C805a81c0cf464ba4e7e108d9d18773d1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637771201983574636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=uJHx3Vve%2F39dWPFLWX2Yf0TpM05Y0ltWtZhcH3UrHno%3D=0>

Please indicate your support or objections by January 18th, 2022.

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<mailto:Lsr@ietf.org>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=X1ic6sdRo2naXF2iDvAfbHgyitrwonRhGBmHTh6Kx6o%3Dreserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr=04%7C01%7Clinda.dunbar%40futurewei.com%7C805a81c0cf464ba4e7e108d9d18773d1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637771201983574636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=ldoBe47FMYzIx4Nrti%2FnNpiL3ZoXSGC0yv7NsVVq4rI%3D=0>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Shraddha Hegde]

Hello,

I read this document and have two basic questions.

1.  The advertisement of inter-AS TE LSA in OSPFV2/V3 itself indicates that the 
link is outside IGP domain.
  This information is good enough to apply special treatment to these 
links. 
  Why is it necessary to advertise additional stub-link TLV to indicate 
this same information?
2. The inter-As TE LSAs in OSPF carry the link TLV. All the TE attributes 
related to the link can be
 Advertised as part of this link TLV including interface addresses (in 
local interface address sub-TLV).
It is not clear reading the draft what additional value this new TLV is 
bringing in.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: Tuesday, January 4, 2022 12:29 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]


Hi Folks,

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

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/__;!!NEt6yMaO-gk!T4jYJBqpTXVICbt3k4d93C7fz-81ikudKyYJpnLHoGUxYTQDjMV428Z-gGZ1XObC$

Please indicate your support or objections by January 18th, 2022.

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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!T4jYJBqpTXVICbt3k4d93C7fz-81ikudKyYJpnLHoGUxYTQDjMV428Z-gEw6hnV4$

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Huaimo Chen]

Hi Everyone,

I read the draft and support its adoption.

Best Regards,
Huaimo

From: Lsr  on behalf of Christian Hopps 

Sent: Tuesday, January 4, 2022 1:58 AM
To: lsr@ietf.org 
Cc: lsr-cha...@ietf.org ; lsr-...@ietf.org 
; cho...@chopps.org ; 
draft-wang-lsr-stub-link-attribu...@ietf.org 

Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

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

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-stub-link-attributes%2Fdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=KDGtq1muOp7w7TzMB2oc8gHF93GFFZJ2U2oArusK7rA%3Dreserved=0

Please indicate your support or objections by January 18th, 2022.

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=X1ic6sdRo2naXF2iDvAfbHgyitrwonRhGBmHTh6Kx6o%3Dreserved=0
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Peter:

Aijun Wang
China Telecom

> On Jan 5, 2022, at 23:57, Peter Psenak  
> wrote:
> 
> Aijun,
> 
>> On 05/01/2022 16:20, Aijun Wang wrote:
>> [WAJ] The above remote information must be configured manually on the local 
>> device. It is paired by manual. Thinking there are many links among the 
>> ASBRs, would you like to configure them manually for every remote ends on 
>> each link? We are looking for the automatic pairing solution.
>> The prefixes that associated with the stub link can assist to accomplish 
>> this task automatically.
> 
> If the ISIS/OSPF adjacency is not formed over the link, you need to manually 
> configure remote endpoint parameters. Defining a new TLV is not going to make 
> any difference.

[WAJ] Automatic Pairing and Manual Pairing has big differences for operators. 

> 
> Using the local subnet information for identifying two endpoints of the same 
> link does not sound appealing to me.
> 
> We have link local/remote IDs (and IP addresses) to pair the two endpoints of 
> the link in both OSPF and ISIS. We do not need another mechanism for the 
> same. In addition, what you propose does not work for unnumbered links.

[WAJ] The unnumbered link is seldom used within the operator network, 
especially for the boundary link. The proposed solution can cover almost all 
the stub-link related scenarios. 

> 
> I don't see a need for the new stub-link advertisement.

[WAJ] Such TLV/sub-TLV can also be used to transfer the attributes that related 
to the edge computing servers.

> 
> thanks,
> Peter
> 
> 

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Acee Lindem (acee)]

I'm not aware of any IPR.
Thanks,
Acee

On 1/4/22, 2:04 AM, "Christian Hopps"  wrote:

Hi Folks,

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

https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

Please indicate your support or objections by January 18th, 2022.

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Peter Psenak]

Aijun,

On 05/01/2022 16:20, Aijun Wang wrote:

[WAJ] The above remote information must be configured manually on the local 
device. It is paired by manual. Thinking there are many links among the ASBRs, 
would you like to configure them manually for every remote ends on each link? 
We are looking for the automatic pairing solution.
The prefixes that associated with the stub link can assist to accomplish this 
task automatically.


If the ISIS/OSPF adjacency is not formed over the link, you need to 
manually configure remote endpoint parameters. Defining a new TLV is not 
going to make any difference.


Using the local subnet information for identifying two endpoints of the 
same link does not sound appealing to me.


We have link local/remote IDs (and IP addresses) to pair the two 
endpoints of the link in both OSPF and ISIS. We do not need another 
mechanism for the same. In addition, what you propose does not work for 
unnumbered links.


I don't see a need for the new stub-link advertisement.

thanks,
Peter


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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Peter:

Aijun Wang
China Telecom

> On Jan 5, 2022, at 21:54, Peter Psenak  
> wrote:
> 
> Hi Aijun,
> 
> please see inline (##PP):
> 
>> On 05/01/2022 13:01, Aijun Wang wrote:
>> Hi, Peter:
>> Thanks for your comments.
>> Please see replies inline.
>> Aijun Wang
>> China Telecom
 On Jan 5, 2022, at 18:45, Peter Psenak 
  wrote:
>>> 
>>> Hi,
>>> 
>>> I'm afraid the draft has some serious issues that would need to be 
>>> addressed if it is to become a WG document.
>>> 
>>> Below comments use ISIS as an example, but most of it applies to OSPF as 
>>> well.
>>> 
>>> 
>>> 1. The draft says:
>>> 
>>> "ISIS[RFC5316] defines the Inter-AS Reachability TLV to carry the TE
>>> information about inter-AS links.  This TLV can be used to transfer
>>> the information about the stub link which is located at the boundary
>>> of one AS.  This document defines the Stub-Link sub-TLV within this
>>> TLV to identify the stub link and transfer the associated attributes."
>>> 
>>> - there is an existing mechanisms to advertise inter-AS link. There is 
>>> existing mechanisms to advertise external prefix. What exactly is the 
>>> reason to define a new TLV?
>>> 
>>> It's still not clear to me what exactly is the use case for the new TLVs 
>>> defined in the document.
>> [WAJ] RFC 5392 and RFC 5316 defines the TLV to carry the information about 
>> other endpoint for the inter-AS link, for example , the remote ASBR ID, the 
>> remote AS etc.
>> Such information are normally derived from the manual configuration.
>> For stub link, there are situations that the above information can’t easily 
>> be obtained or doesn’t exist, what we can get only the information about the 
>> local end, not the information about the remote end.
> 
> ##PP
> 
> All link related TLVs, including Inter-AS Reachability TLV share the same 
> Sub-TLV space, including Link Local/Remote Identifiers IPv4/IPv6 local/remote 
> address, etc. What exactly is missing?
> 
> All you have defined is the prefix advertisement with the link? What is the 
> exact usage of the prefix that is advertised with the link?
[WAJ] Yes, they all share the same sub-TLV space, but there is no place to 
identify the link is one stub link. There is also no sub-TLV to define the 
associated prefixes for the stub-Link. 

> 
>> Then It is better to use different TLV to differentiate the local 
>> information from the remote information. Define the Stub-Link TLV to contain 
>> such local obtained information is then the reasonable way.
> 
> ##PP
> I don't understand the above. We have existing sub-TLVs that include both 
> local and remote link data.

[WAJ] Reuse the Link TLV that defined in inter-AS-TE-v2/v3 to contain such 
information is possible, but we should still to define the link type(as that in 
RFC3630) to identify the stub-link, also the prefixes related sub-TLV.  
Comparing the two different approaches, we select to define one new sub-TLV to 
contain the above information in one place together.

> 
> 
>> The use case of stub link can be referred at the introduction part of the 
>> draft.
> 
> ##PP
> the description in the draft is very high level. Please provide an exact use 
> case for the prefix that is advertised with the link.

[WAJ] it can be used to pair the two ends of the stub-link, it can also be used 
to identify the severs address that attached to the stub link.

> 
>>> 
>>> 2. Looking at the proposed ISIS Stub-link Sub-TLV, which is a sub-TLV of 
>>> the existing Inter-AS Reachability TLV:
>>> 
>>> - it advertises prefix. The advertisement of the prefix and link 
>>> information is strictly decoupled in ISIS. Here the proposal is to 
>>> advertise the prefix inside the Inter-AS Reachability TLV, which is 
>>> advertising a link. Why do we need the prefix of the inter-AS link to be 
>>> advertised inside the link advertisement?
>> [WAJ]For stub link, what we can get is only the interface addresses of the 
>> local end and its associated prefixes. The associated prefixes can be used 
>> to match the two ends of the stub-link, it can also indicate the server’s 
>> address as that described in 
> 
> ##PP
> 
> ok, so you want to use the prefix information of the Inter-AS Reachability 
> TLV to link the two endpoints of such link together?
> 
> Inter-AS Reachability TLV includes:
> 
> a) the "IPv4/v6 remote ASBR identifier" which identifies the remote
> end-point and should carry the TE Router ID (see sections 3.3.2 and 3.3.3 of 
> RFC5316).
> 
> b) The local end-point  ID is advertised in the form of the "IPv4/IPv6 TE 
> Router ID" in the IS-IS Router Capability TLV of the originator.
> 
> These two are sufficient to pair the two endpoints of the inter-AS link 
> together.

[WAJ] The above remote information must be configured manually on the local 
device. It is paired by manual. Thinking there are many links among the ASBRs, 
would you like to configure them manually for every remote ends on each link? 
We are looking for the automatic pairing solution.

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Peter Psenak]

Hi Aijun,

please see inline (##PP):

On 05/01/2022 13:01, Aijun Wang wrote:

Hi, Peter:

Thanks for your comments.
Please see replies inline.


Aijun Wang
China Telecom

On Jan 5, 2022, at 18:45, Peter Psenak 
 wrote:


Hi,

I'm afraid the draft has some serious issues that would need to be 
addressed if it is to become a WG document.


Below comments use ISIS as an example, but most of it applies to OSPF 
as well.



1. The draft says:

"ISIS[RFC5316] defines the Inter-AS Reachability TLV to carry the TE
information about inter-AS links.  This TLV can be used to transfer
the information about the stub link which is located at the boundary
of one AS.  This document defines the Stub-Link sub-TLV within this
TLV to identify the stub link and transfer the associated attributes."

- there is an existing mechanisms to advertise inter-AS link. There is 
existing mechanisms to advertise external prefix. What exactly is the 
reason to define a new TLV?


It's still not clear to me what exactly is the use case for the new 
TLVs defined in the document.


[WAJ] RFC 5392 and RFC 5316 defines the TLV to carry the information 
about other endpoint for the inter-AS link, for example , the remote 
ASBR ID, the remote AS etc.

Such information are normally derived from the manual configuration.

For stub link, there are situations that the above information can’t 
easily be obtained or doesn’t exist, what we can get only the 
information about the local end, not the information about the remote end.


##PP

All link related TLVs, including Inter-AS Reachability TLV share the 
same Sub-TLV space, including Link Local/Remote Identifiers IPv4/IPv6 
local/remote address, etc. What exactly is missing?


All you have defined is the prefix advertisement with the link? What is 
the exact usage of the prefix that is advertised with the link?




Then It is better to use different TLV to differentiate the local 
information from the remote information. Define the Stub-Link TLV to 
contain such local obtained information is then the reasonable way.


##PP
I don't understand the above. We have existing sub-TLVs that include 
both local and remote link data.





The use case of stub link can be referred at the introduction part of 
the draft.


##PP
the description in the draft is very high level. Please provide an exact 
use case for the prefix that is advertised with the link.




2. Looking at the proposed ISIS Stub-link Sub-TLV, which is a sub-TLV 
of the existing Inter-AS Reachability TLV:


- it advertises prefix. The advertisement of the prefix and link 
information is strictly decoupled in ISIS. Here the proposal is to 
advertise the prefix inside the Inter-AS Reachability TLV, which is 
advertising a link. Why do we need the prefix of the inter-AS link to 
be advertised inside the link advertisement?


[WAJ]For stub link, what we can get is only the interface addresses of 
the local end and its associated prefixes. The associated prefixes can 
be used to match the two ends of the stub-link, it can also indicate the 
server’s address as that described in 


##PP

ok, so you want to use the prefix information of the Inter-AS 
Reachability TLV to link the two endpoints of such link together?


Inter-AS Reachability TLV includes:

a) the "IPv4/v6 remote ASBR identifier" which identifies the remote
end-point and should carry the TE Router ID (see sections 3.3.2 and 
3.3.3 of RFC5316).


b) The local end-point  ID is advertised in the form of the "IPv4/IPv6 
TE Router ID" in the IS-IS Router Capability TLV of the originator.


These two are sufficient to pair the two endpoints of the inter-AS link 
together.



https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ 
.




2. The new ISIS Stub-link Sub-TLV includes sub-TLVs, the text says:

"Sub-TLVs: Existing sub-TLVs that defined within "Sub-TLVs for TLVs
  22, 23, 25, 141, 222, and 223" can be included if necessary."

The parent Inter-AS Reachability TLV already has Sub-TLVs from the 
exact same space. Not to mention that the new sub-TLV itself comes 
from the same space. 


[WAJ] 141(inter-AS reachability information) is mentioned in the above 
sentence.


##PP
what you have is:

Inter-AS Reachability TLV
 Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223
  ISIS Stub-link Sub-TLV
   Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223

where ISIS Stub-link Sub-TLV is part of the
 "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223"






3. Link Type in ISIS Stub-link Sub-TLV - what is it used for and why 
do we need it?


[WAJ] There are different kinds of stub link. Differentiate them via the 
link type can help the precise control and analyze these stub links.


##PP
exact use case please.

thanks,
Peter






thanks,
Peter



On 04/01/2022 07:58, Christian Hopps wrote:

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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Peter:

Thanks for your comments.
Please see replies inline.


Aijun Wang
China Telecom

> On Jan 5, 2022, at 18:45, Peter Psenak  
> wrote:
> 
> Hi,
> 
> I'm afraid the draft has some serious issues that would need to be addressed 
> if it is to become a WG document.
> 
> Below comments use ISIS as an example, but most of it applies to OSPF as well.
> 
> 
> 1. The draft says:
> 
> "ISIS[RFC5316] defines the Inter-AS Reachability TLV to carry the TE
> information about inter-AS links.  This TLV can be used to transfer
> the information about the stub link which is located at the boundary
> of one AS.  This document defines the Stub-Link sub-TLV within this
> TLV to identify the stub link and transfer the associated attributes."
> 
> - there is an existing mechanisms to advertise inter-AS link. There is 
> existing mechanisms to advertise external prefix. What exactly is the reason 
> to define a new TLV?
> 
> It's still not clear to me what exactly is the use case for the new TLVs 
> defined in the document.

[WAJ] RFC 5392 and RFC 5316 defines the TLV to carry the information about 
other endpoint for the inter-AS link, for example , the remote ASBR ID, the 
remote AS etc.
Such information are normally derived from the manual configuration.

For stub link, there are situations that the above information can’t easily be 
obtained or doesn’t exist, what we can get only the information about the local 
end, not the information about the remote end.

Then It is better to use different TLV to differentiate the local information 
from the remote information. Define the Stub-Link TLV to contain such local 
obtained information is then the reasonable way.

The use case of stub link can be referred at the introduction part of the draft.
> 
> 2. Looking at the proposed ISIS Stub-link Sub-TLV, which is a sub-TLV of the 
> existing Inter-AS Reachability TLV:
> 
> - it advertises prefix. The advertisement of the prefix and link information 
> is strictly decoupled in ISIS. Here the proposal is to advertise the prefix 
> inside the Inter-AS Reachability TLV, which is advertising a link. Why do we 
> need the prefix of the inter-AS link to be advertised inside the link 
> advertisement?

[WAJ]For stub link, what we can get is only the interface addresses of the 
local end and its associated prefixes. The associated prefixes can be used to 
match the two ends of the stub-link, it can also indicate the server’s address 
as that described in 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/.

> 
> 2. The new ISIS Stub-link Sub-TLV includes sub-TLVs, the text says:
> 
> "Sub-TLVs: Existing sub-TLVs that defined within "Sub-TLVs for TLVs
>   22, 23, 25, 141, 222, and 223" can be included if necessary."
> 
> The parent Inter-AS Reachability TLV already has Sub-TLVs from the exact same 
> space. Not to mention that the new sub-TLV itself comes from the same space. 

[WAJ] 141(inter-AS reachability information) is mentioned in the above sentence.

> 
> 3. Link Type in ISIS Stub-link Sub-TLV - what is it used for and why do we 
> need it?

[WAJ] There are different kinds of stub link. Differentiate them via the link 
type can help the precise control and analyze these stub links. 
> 
> 
> thanks,
> Peter
> 
> 
> 
>> On 04/01/2022 07:58, Christian Hopps wrote:
>> Hi Folks,
>> This begins a 2 week WG Adoption Call for the following draft:
>> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
>> Please indicate your support or objections by January 18th, 2022.
>> 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Peter Psenak]

Hi,

I'm afraid the draft has some serious issues that would need to be 
addressed if it is to become a WG document.


Below comments use ISIS as an example, but most of it applies to OSPF as 
well.



1. The draft says:

"ISIS[RFC5316] defines the Inter-AS Reachability TLV to carry the TE
 information about inter-AS links.  This TLV can be used to transfer
 the information about the stub link which is located at the boundary
 of one AS.  This document defines the Stub-Link sub-TLV within this
 TLV to identify the stub link and transfer the associated attributes."

- there is an existing mechanisms to advertise inter-AS link. There is 
existing mechanisms to advertise external prefix. What exactly is the 
reason to define a new TLV?


It's still not clear to me what exactly is the use case for the new TLVs 
defined in the document.


2. Looking at the proposed ISIS Stub-link Sub-TLV, which is a sub-TLV of 
the existing Inter-AS Reachability TLV:


- it advertises prefix. The advertisement of the prefix and link 
information is strictly decoupled in ISIS. Here the proposal is to 
advertise the prefix inside the Inter-AS Reachability TLV, which is 
advertising a link. Why do we need the prefix of the inter-AS link to be 
advertised inside the link advertisement?


2. The new ISIS Stub-link Sub-TLV includes sub-TLVs, the text says:

 "Sub-TLVs: Existing sub-TLVs that defined within "Sub-TLVs for TLVs
   22, 23, 25, 141, 222, and 223" can be included if necessary."

The parent Inter-AS Reachability TLV already has Sub-TLVs from the exact 
same space. Not to mention that the new sub-TLV itself comes from the 
same space. Looks broken.


3. Link Type in ISIS Stub-link Sub-TLV - what is it used for and why do 
we need it?



thanks,
Peter



On 04/01/2022 07:58, Christian Hopps wrote:

Hi Folks,

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

https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

Please indicate your support or objections by January 18th, 2022.

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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Huzhibo]

Hi, WG:

This draft provides a way to advertise the stub link and their associated 
attributes.
I support its adoption as a co-author.
 
I am not aware of any IPR that related to this draft.


Best Regards

Zhibo hu

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Tuesday, January 4, 2022 2:59 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

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

https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

Please indicate your support or objections by January 18th, 2022.

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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Gyan Mishra]

I am not aware of any undisclosed IPR.

I support WG adoption.

Thanks

Gyan

On Tue, Jan 4, 2022 at 2:04 AM Christian Hopps  wrote:

> Hi Folks,
>
> This begins a 2 week WG Adoption Call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
>
> Please indicate your support or objections by January 18th, 2022.
>
> 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
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[peng.shaofu]

Hi WG,

Support adoption.

Regards,
PSF


--原始邮件--
发件人：ChristianHopps
收件人：lsr@ietf.org;
抄送人：lsr-cha...@ietf.org;lsr-...@ietf.org;cho...@chopps.org;draft-wang-lsr-stub-link-attribu...@ietf.org;
日 期 ：2022年01月04日 15:04
主 题 ：[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
Please indicate your support or objections by January 18th, 2022.
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] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Aijun Wang]

Hi, Christian and all:

The stub links are used in widespread within the network, and it is useful
to identify them within the IGP in several scenarios (as described in
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02
#section-1).
I support its adoption.
 
I am not aware of any IPR that related to this draft.


Best Regards

Aijun Wang
China Telecom


-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Christian
Hopps
Sent: Tuesday, January 4, 2022 2:59 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org;
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

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

https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

Please indicate your support or objections by January 18th, 2022.

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

[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Christian Hopps]

Hi Folks,

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

https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

Please indicate your support or objections by January 18th, 2022.

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