Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Aijun Wang]

Hi, Les:

As I stated clearly before, the appendix described in the draft is not the new 
use case. It is the start point of this draft.
Have you noticed that the introduction part is not the final usage of such 
protocol extension information? 
Certainly, we will not expand all the possible use cases in very detail, but 
putting some of them(some interesting, prominent use cases) in the appendix 
will not hamper the protocol extension itself.

If the statements/descriptions in the appendix are not correct, we can fix it, 
or remove it finally.  If not, why not let it be for reference to the user of 
such protocol extension?
For the body part of this draft, we are also welcome comments.

More replies inline below[WAJ]

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Monday, October 19, 2020 2:15 PM
To: Aijun Wang ; 'Christian Hopps' 

Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les Ginsberg 
(ginsberg)' ; lsr@ietf.org; 'Jeff 
Tantsura' ; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Aijun -

The "use case" for the protocol extensions is clearly stated in the 
Introduction:

"The primary use case for the extensions proposed in this document is
   to be able to identify the originator of the prefix in the network.
   In cases where multiple prefixes are advertised by a given router, it
   is also useful to be able to associate all these prefixes with a
   single router even when prefixes are advertised outside of the area
   in which they originated.  It also helps to determine when the same
   prefix is being originated by multiple routers across areas."

This is equivalent to language in RFC 7794 which defines the analogous 
extensions for IS-IS.

Everything you have in the Appendix is not related to the primary use case - 
and is fact a use case which many of us have objected to.
[WAJ] Very glad to know the false statements in the appendix.

You are entitled to write another draft advocating for your new use case if you 
wish, but requiring that the protocol extensions in support of the primary use 
case not go forward without your new use case is - as Chris has stated very 
clearly - holding approval of the protocol extensions hostage to your new use 
case.
[WAJ] It is not new use case. As I sated before, I am open to this part, but 
should on the conditions that the statements in this part are incorrect.

I am asking you (yet again) not to do this.

I cannot support the document moving forward with the content in the Appendices 
included.
[WAJ] Would like to hear more technical analysis.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Aijun Wang
> Sent: Sunday, October 18, 2020 7:08 PM
> To: 'Christian Hopps' 
> Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les 
> Ginsberg (ginsberg)' ; 
> lsr@ietf.org; 'Jeff Tantsura' ; 
> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call 
> draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Chris:
> 
> I think we have "put the cart before the horse". For protocol 
> extension draft, the origin is the use case.
> And I think we will not expand OSPF protocol, just because it lack 
> something as compared with ISIS, right?
> 
> As I stated before, the use case in current appendix is the main 
> motivation of this draft, you can see this in main body of the earlier 
> version of this draft(from version 0 to version 5).
> The reason that we move this part to the appendix, as that you said, 
> is to let person focus on the protocol extension itself.
> 
> Moving this part to appendix is acceptable, but removing it from the 
> draft will erase the origin of this document.
> Is it reasonable that one document discusses the "origin"(of the 
> prefix), can't keep its origin?
> 
> More replies inline below[WAJ].
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> -Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of 
> Christian Hopps
> Sent: Friday, October 16, 2020 10:47 PM
> To: 王爱俊 
> Cc: John E Drake ; Christian Hopps 
> ; lsr-cha...@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; Jeff Tantsura 
> ; 
> draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr- a...@ietf.org
> Subject: Re: [Lsr] WG Last Call 
> draft-ietf-lsr-ospf-prefix-originator-06
> 
> Isn't this just adding an analogous extension that already exists in RFC7794?
> [WAJ] No. RFC7794 is just one example that to illustrate, as the 
> companion IGP protocol, OSPF can also accomplish this. And, actually, 
> there are differences consideration in this draft for the protocol extension.
> 
> I don't think we need to do a lot of convincing at this point. I agree 
> with Les, if you want to talk about use cases (especially ones that 
> are controversial!) then the correct place for that is i

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Les Ginsberg (ginsberg)]

Aijun -

I am not going to continue these side discussions with you.

The primary purpose of the protocol extensions are as stated in the draft 
Introduction. This is analogous to the use cases for the equivalent extensions 
for IS-IS already approved in RFC 7794. We need the equivalent in OSPF.

You can show that you are listening to the concerns of WG members by removing 
the Appendices - in which case you have (I believe) broad support for moving 
the draft forward.
You can then write a separate draft to discuss other use cases and allow the WG 
to discuss those other use cases w/o preventing the extensions from being 
approved and deployed for the use cases which have already been demonstrated as 
useful by IS-IS.

If you remove the Appendices I can support the draft.
If you do not remove the Appendices I cannot support the draft.

Please discuss this with your co-authors and come to consensus on your next 
step.

   Les


> -Original Message-
> From: Aijun Wang 
> Sent: Monday, October 19, 2020 12:06 AM
> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
> 
> Cc: 'John E Drake' ; lsr-cha...@ietf.org; lsr@ietf.org;
> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org; lsr-...@ietf.org
> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Les:
> 
> As I stated clearly before, the appendix described in the draft is not the new
> use case. It is the start point of this draft.
> Have you noticed that the introduction part is not the final usage of such
> protocol extension information?
> Certainly, we will not expand all the possible use cases in very detail, but
> putting some of them(some interesting, prominent use cases) in the
> appendix will not hamper the protocol extension itself.
> 
> If the statements/descriptions in the appendix are not correct, we can fix it,
> or remove it finally.  If not, why not let it be for reference to the user of 
> such
> protocol extension?
> For the body part of this draft, we are also welcome comments.
> 
> More replies inline below[WAJ]
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Les
> Ginsberg (ginsberg)
> Sent: Monday, October 19, 2020 2:15 PM
> To: Aijun Wang ; 'Christian Hopps'
> 
> Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les Ginsberg
> (ginsberg)' ; lsr@ietf.org; 'Jeff
> Tantsura' ; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Aijun -
> 
> The "use case" for the protocol extensions is clearly stated in the
> Introduction:
> 
> "The primary use case for the extensions proposed in this document is
>to be able to identify the originator of the prefix in the network.
>In cases where multiple prefixes are advertised by a given router, it
>is also useful to be able to associate all these prefixes with a
>single router even when prefixes are advertised outside of the area
>in which they originated.  It also helps to determine when the same
>prefix is being originated by multiple routers across areas."
> 
> This is equivalent to language in RFC 7794 which defines the analogous
> extensions for IS-IS.
> 
> Everything you have in the Appendix is not related to the primary use case -
> and is fact a use case which many of us have objected to.
> [WAJ] Very glad to know the false statements in the appendix.
> 
> You are entitled to write another draft advocating for your new use case if
> you wish, but requiring that the protocol extensions in support of the
> primary use case not go forward without your new use case is - as Chris has
> stated very clearly - holding approval of the protocol extensions hostage to
> your new use case.
> [WAJ] It is not new use case. As I sated before, I am open to this part, but
> should on the conditions that the statements in this part are incorrect.
> 
> I am asking you (yet again) not to do this.
> 
> I cannot support the document moving forward with the content in the
> Appendices included.
> [WAJ] Would like to hear more technical analysis.
> 
>Les
> 
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Aijun Wang
> > Sent: Sunday, October 18, 2020 7:08 PM
> > To: 'Christian Hopps' 
> > Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les
> > Ginsberg (ginsberg)' ;
> > lsr@ietf.org; 'Jeff Tantsura' ;
> > draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
> > Subject: Re: [Lsr] WG Last Call
> > draft-ietf-lsr-ospf-prefix-originator-06
> >
> > Hi, Chris:
> >
> > I think we have "put the cart before the horse". For protocol
> > extension draft, the origin is the use case.
> > And I think we will not expand OSPF protocol, just because it lack
> > something as compared with ISIS, right?
> >
> > As I stated before, the use case in current appendix is the main
> > motivation of this draft, you can see this in main body of the earlier

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Peter Psenak]

Aijun,

On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:

Aijun -

I am not going to continue these side discussions with you.

The primary purpose of the protocol extensions are as stated in the draft 
Introduction. This is analogous to the use cases for the equivalent extensions 
for IS-IS already approved in RFC 7794. We need the equivalent in OSPF.

You can show that you are listening to the concerns of WG members by removing 
the Appendices - in which case you have (I believe) broad support for moving 
the draft forward.


I agree with Les.

As a co-author, I have asked you several times to get rid of the use 
case described in appendix. Trying to use prefix advertisement to derive 
topological data is simply broken. The reason we are adding the prefix 
originator extension to OSPF is NOT the broken use case in the appendix 
of the draft.


thanks,
Peter




You can then write a separate draft to discuss other use cases and allow the WG 
to discuss those other use cases w/o preventing the extensions from being 
approved and deployed for the use cases which have already been demonstrated as 
useful by IS-IS.

If you remove the Appendices I can support the draft.
If you do not remove the Appendices I cannot support the draft.

Please discuss this with your co-authors and come to consensus on your next 
step.

Les



-Original Message-
From: Aijun Wang 
Sent: Monday, October 19, 2020 12:06 AM
To: Les Ginsberg (ginsberg) ; 'Christian Hopps'

Cc: 'John E Drake' ; lsr-cha...@ietf.org; lsr@ietf.org;
'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix-
origina...@ietf.org; lsr-...@ietf.org
Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Hi, Les:

As I stated clearly before, the appendix described in the draft is not the new
use case. It is the start point of this draft.
Have you noticed that the introduction part is not the final usage of such
protocol extension information?
Certainly, we will not expand all the possible use cases in very detail, but
putting some of them(some interesting, prominent use cases) in the
appendix will not hamper the protocol extension itself.

If the statements/descriptions in the appendix are not correct, we can fix it,
or remove it finally.  If not, why not let it be for reference to the user of 
such
protocol extension?
For the body part of this draft, we are also welcome comments.

More replies inline below[WAJ]

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Les
Ginsberg (ginsberg)
Sent: Monday, October 19, 2020 2:15 PM
To: Aijun Wang ; 'Christian Hopps'

Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les Ginsberg
(ginsberg)' ; lsr@ietf.org; 'Jeff
Tantsura' ; draft-ietf-lsr-ospf-prefix-
origina...@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Aijun -

The "use case" for the protocol extensions is clearly stated in the
Introduction:

"The primary use case for the extensions proposed in this document is
to be able to identify the originator of the prefix in the network.
In cases where multiple prefixes are advertised by a given router, it
is also useful to be able to associate all these prefixes with a
single router even when prefixes are advertised outside of the area
in which they originated.  It also helps to determine when the same
prefix is being originated by multiple routers across areas."

This is equivalent to language in RFC 7794 which defines the analogous
extensions for IS-IS.

Everything you have in the Appendix is not related to the primary use case -
and is fact a use case which many of us have objected to.
[WAJ] Very glad to know the false statements in the appendix.

You are entitled to write another draft advocating for your new use case if
you wish, but requiring that the protocol extensions in support of the
primary use case not go forward without your new use case is - as Chris has
stated very clearly - holding approval of the protocol extensions hostage to
your new use case.
[WAJ] It is not new use case. As I sated before, I am open to this part, but
should on the conditions that the statements in this part are incorrect.

I am asking you (yet again) not to do this.

I cannot support the document moving forward with the content in the
Appendices included.
[WAJ] Would like to hear more technical analysis.

Les



-Original Message-
From: Lsr  On Behalf Of Aijun Wang
Sent: Sunday, October 18, 2020 7:08 PM
To: 'Christian Hopps' 
Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les
Ginsberg (ginsberg)' ;
lsr@ietf.org; 'Jeff Tantsura' ;
draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] WG Last Call
draft-ietf-lsr-ospf-prefix-originator-06

Hi, Chris:

I think we have "put the cart before the horse". For protocol
extension draft, the origin is the use case.
And I think we will not expand OSPF protocol, just because it lack
so

Re: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

[Peter Psenak]

Hi Eric,

thanks for the review, please see inline:


On 16/10/2020 20:48, Eric Gray wrote:

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see 
https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir.


Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.


Document: draft-ietf-lsr-flex-algo-12.txt

Reviewer: Eric Gray

Review Date: 16 October, 2020

IETF LC End Date: Unknown

Intended Status: Standards Track

Summary:

This document is well organized, relatively easy to read, and probably 
ready for publication, but has one potential minor issue and a very 
small number of NITs that might be considered prior to publication.


Major Issues:

None

Minor Issues:

The statement in section 15 (Backward Compatibility) - "This extension 
brings no new backward compatibility issues" - seems somewhat flip.


I suspect that a tiny bit of analysis would not hurt.

The extensions in this draft are clearly intended to work in an 
environment where routers that _do_not_ support these extensions are 
also deployed, but apparently relies on configuration of those routers 
that _do_ support the extensions to address this.


That seems correct.

 From my reading of the draft (which I have not closely followed for its 
entire development), while it introduces at least one new TLV, the OSPF 
routing protocol has well defined handling for TLVs that are not 
understood - hence the introduction of one or more new TLVs should not 
present a problem in OSPF.


Obviously Sub-TLVs of the new OSPF TLV type will not introduce 
compatibility issues.


I assume (but do not actually know) that a similar situation exists for 
the new ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS 
presumably has well defined handling for sub-TLVs (of at least type 242) 
that are not recognized.  If so, than the new Sub-TLV types defined are 
also not an issue.


Shouldn't this section say something along these lines?  I suspect that 
it would be more helpful if verifying the content of the 
"considerations" sections were not left as an exercise for the reader. 😊


What about the "Backward Compatibility" section to be updated to:


"This extension brings no new backward compatibility issues. ISIS, 
OSPFv2 and OSPFv3 all have well defined handling of unrecognized TLVs 
and sub-TLVs, that allows the introduction of the new extensions, 
similar to those defined here, without introducing any interoperability 
problems."





NITs:

In the Introduction, the phrase "must often be replaced" seems very 
slightly problematic (especially given this is a standards track RFC 
wanna-be).  Would it be better to say "is often replaced" instead?



done.



In section 17.1.2 and 17.2 - '... a "Interior Gateway ...' should 
probably be '... an "Interior Gateway ..." in both cases.


done.

thanks,
Peter





--

Eric



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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Aijun Wang]

Hi. Peter, Les:

We have defined many extensions for protocol, but only a small part of them are 
deployed. Have you ever considered the reason?

Adding more contents for their  potential usages can certainly be helpful for 
their influences, or else, they will just stay at the IETF repository.

More replies inline below.



Aijun Wang
China Telecom

> On Oct 19, 2020, at 17:14, Peter Psenak  
> wrote:
> 
> Aijun,
> 
>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
>> Aijun -
>> I am not going to continue these side discussions with you.
>> The primary purpose of the protocol extensions are as stated in the draft 
>> Introduction. This is analogous to the use cases for the equivalent 
>> extensions for IS-IS already approved in RFC 7794. We need the equivalent in 
>> OSPF.
>> You can show that you are listening to the concerns of WG members by 
>> removing the Appendices - in which case you have (I believe) broad support 
>> for moving the draft forward.
> 
> I agree with Les.
> 
> As a co-author, I have asked you several times to get rid of the use case 
> described in appendix.
[WAJ] Moving the expansion of this use case from body part of this draft to its 
appendix is our initial consensus, not remove it totally. We have discussed 
intensely for its application in vary situations. The discussion results are 
stated clearly in the appendix.
Wish to hear more technical analysis/comments for the current statements of 
this part from other experts, or from you if you have fresh consideration.

> Trying to use prefix advertisement to derive topological data is simply 
> broken. The reason we are adding the prefix originator extension to OSPF is 
> NOT the broken use case in the appendix of the draft.
> 
> thanks,
> Peter
> 
> 
> 
>> You can then write a separate draft to discuss other use cases and allow the 
>> WG to discuss those other use cases w/o preventing the extensions from being 
>> approved and deployed for the use cases which have already been demonstrated 
>> as useful by IS-IS.
>> If you remove the Appendices I can support the draft.
>> If you do not remove the Appendices I cannot support the draft.
>> Please discuss this with your co-authors and come to consensus on your next 
>> step.
>>Les
>>> -Original Message-
>>> From: Aijun Wang 
>>> Sent: Monday, October 19, 2020 12:06 AM
>>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
>>> 
>>> Cc: 'John E Drake' ; lsr-cha...@ietf.org; lsr@ietf.org;
>>> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix-
>>> origina...@ietf.org; lsr-...@ietf.org
>>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>>> 
>>> Hi, Les:
>>> 
>>> As I stated clearly before, the appendix described in the draft is not the 
>>> new
>>> use case. It is the start point of this draft.
>>> Have you noticed that the introduction part is not the final usage of such
>>> protocol extension information?
>>> Certainly, we will not expand all the possible use cases in very detail, but
>>> putting some of them(some interesting, prominent use cases) in the
>>> appendix will not hamper the protocol extension itself.
>>> 
>>> If the statements/descriptions in the appendix are not correct, we can fix 
>>> it,
>>> or remove it finally.  If not, why not let it be for reference to the user 
>>> of such
>>> protocol extension?
>>> For the body part of this draft, we are also welcome comments.
>>> 
>>> More replies inline below[WAJ]
>>> 
>>> Best Regards
>>> 
>>> Aijun Wang
>>> China Telecom
>>> 
>>> -Original Message-
>>> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Les
>>> Ginsberg (ginsberg)
>>> Sent: Monday, October 19, 2020 2:15 PM
>>> To: Aijun Wang ; 'Christian Hopps'
>>> 
>>> Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les Ginsberg
>>> (ginsberg)' ; lsr@ietf.org; 'Jeff
>>> Tantsura' ; draft-ietf-lsr-ospf-prefix-
>>> origina...@ietf.org; lsr-...@ietf.org
>>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>>> 
>>> Aijun -
>>> 
>>> The "use case" for the protocol extensions is clearly stated in the
>>> Introduction:
>>> 
>>> "The primary use case for the extensions proposed in this document is
>>>to be able to identify the originator of the prefix in the network.
>>>In cases where multiple prefixes are advertised by a given router, it
>>>is also useful to be able to associate all these prefixes with a
>>>single router even when prefixes are advertised outside of the area
>>>in which they originated.  It also helps to determine when the same
>>>prefix is being originated by multiple routers across areas."
>>> 
>>> This is equivalent to language in RFC 7794 which defines the analogous
>>> extensions for IS-IS.
>>> 
>>> Everything you have in the Appendix is not related to the primary use case -
>>> and is fact a use case which many of us have objected to.
>>> [WAJ] Very glad to know the false statements in the appendix.
>>> 
>>> You are entitled to write another draft advocati

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Peter Psenak]

Hi Aijun,

please see inline:


On 19/10/2020 12:10, Aijun Wang wrote:

Hi. Peter, Les:

We have defined many extensions for protocol, but only a small part of them are 
deployed. Have you ever considered the reason?

Adding more contents for their  potential usages can certainly be helpful for 
their influences, or else, they will just stay at the IETF repository.


I disagree. RFCs are not deployment or use case documents. They exists 
to address the interoperability.




More replies inline below.



Aijun Wang
China Telecom


On Oct 19, 2020, at 17:14, Peter Psenak  
wrote:

Aijun,


On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
Aijun -
I am not going to continue these side discussions with you.
The primary purpose of the protocol extensions are as stated in the draft 
Introduction. This is analogous to the use cases for the equivalent extensions 
for IS-IS already approved in RFC 7794. We need the equivalent in OSPF.
You can show that you are listening to the concerns of WG members by removing 
the Appendices - in which case you have (I believe) broad support for moving 
the draft forward.


I agree with Les.

As a co-author, I have asked you several times to get rid of the use case 
described in appendix.

[WAJ] Moving the expansion of this use case from body part of this draft to its 
appendix is our initial consensus, not remove it totally. We have discussed 
intensely for its application in vary situations. The discussion results are 
stated clearly in the appendix.


just because you insisted and did not listen to rest of us.


Wish to hear more technical analysis/comments for the current statements of 
this part from other experts, or from you if you have fresh consideration.


we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan, 
myself) are telling you that using IP address advertisement to derive 
topological data is broken and you keep repeating it is valid use case 
and ask for more reasoning.


thanks,
Peter




Trying to use prefix advertisement to derive topological data is simply broken. 
The reason we are adding the prefix originator extension to OSPF is NOT the 
broken use case in the appendix of the draft.

thanks,
Peter




You can then write a separate draft to discuss other use cases and allow the WG 
to discuss those other use cases w/o preventing the extensions from being 
approved and deployed for the use cases which have already been demonstrated as 
useful by IS-IS.
If you remove the Appendices I can support the draft.
If you do not remove the Appendices I cannot support the draft.
Please discuss this with your co-authors and come to consensus on your next 
step.
Les

-Original Message-
From: Aijun Wang 
Sent: Monday, October 19, 2020 12:06 AM
To: Les Ginsberg (ginsberg) ; 'Christian Hopps'

Cc: 'John E Drake' ; lsr-cha...@ietf.org; lsr@ietf.org;
'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix-
origina...@ietf.org; lsr-...@ietf.org
Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Hi, Les:

As I stated clearly before, the appendix described in the draft is not the new
use case. It is the start point of this draft.
Have you noticed that the introduction part is not the final usage of such
protocol extension information?
Certainly, we will not expand all the possible use cases in very detail, but
putting some of them(some interesting, prominent use cases) in the
appendix will not hamper the protocol extension itself.

If the statements/descriptions in the appendix are not correct, we can fix it,
or remove it finally.  If not, why not let it be for reference to the user of 
such
protocol extension?
For the body part of this draft, we are also welcome comments.

More replies inline below[WAJ]

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Les
Ginsberg (ginsberg)
Sent: Monday, October 19, 2020 2:15 PM
To: Aijun Wang ; 'Christian Hopps'

Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les Ginsberg
(ginsberg)' ; lsr@ietf.org; 'Jeff
Tantsura' ; draft-ietf-lsr-ospf-prefix-
origina...@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Aijun -

The "use case" for the protocol extensions is clearly stated in the
Introduction:

"The primary use case for the extensions proposed in this document is
to be able to identify the originator of the prefix in the network.
In cases where multiple prefixes are advertised by a given router, it
is also useful to be able to associate all these prefixes with a
single router even when prefixes are advertised outside of the area
in which they originated.  It also helps to determine when the same
prefix is being originated by multiple routers across areas."

This is equivalent to language in RFC 7794 which defines the analogous
extensions for IS-IS.

Everything you have in the Appendix is not related to the primary use case -
and is fact a use ca

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Robert Raszuk]

Aijun,

Regarding your appendix A -

* How can we "rebuild" topology based on comparison of prefixes and rtr-id
?

* If link between S1 & S2 is not in LSDB there may be a valid operational
reasons for it. "Rebuilding it" will be actually harmful from all points of
view.

* You should be exporting topology from all areas not just from backbone
and guessing the topology based on the prefix to rtr_id associations

* Imaging someone is using multiaccess in areas. Are you also going to
rebuild DR & BDR ?

I must agree with comments from Peter & Les here.

Cheers,
R.





On Mon, Oct 19, 2020 at 12:11 PM Aijun Wang  wrote:

> Hi. Peter, Les:
>
> We have defined many extensions for protocol, but only a small part of
> them are deployed. Have you ever considered the reason?
>
> Adding more contents for their  potential usages can certainly be helpful
> for their influences, or else, they will just stay at the IETF repository.
>
> More replies inline below.
>
>
>
> Aijun Wang
> China Telecom
>
> > On Oct 19, 2020, at 17:14, Peter Psenak  40cisco@dmarc.ietf.org> wrote:
> >
> > Aijun,
> >
> >> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> >> Aijun -
> >> I am not going to continue these side discussions with you.
> >> The primary purpose of the protocol extensions are as stated in the
> draft Introduction. This is analogous to the use cases for the equivalent
> extensions for IS-IS already approved in RFC 7794. We need the equivalent
> in OSPF.
> >> You can show that you are listening to the concerns of WG members by
> removing the Appendices - in which case you have (I believe) broad support
> for moving the draft forward.
> >
> > I agree with Les.
> >
> > As a co-author, I have asked you several times to get rid of the use
> case described in appendix.
> [WAJ] Moving the expansion of this use case from body part of this draft
> to its appendix is our initial consensus, not remove it totally. We have
> discussed intensely for its application in vary situations. The discussion
> results are stated clearly in the appendix.
> Wish to hear more technical analysis/comments for the current statements
> of this part from other experts, or from you if you have fresh
> consideration.
>
> > Trying to use prefix advertisement to derive topological data is simply
> broken. The reason we are adding the prefix originator extension to OSPF is
> NOT the broken use case in the appendix of the draft.
> >
> > thanks,
> > Peter
> >
> >
> >
> >> You can then write a separate draft to discuss other use cases and
> allow the WG to discuss those other use cases w/o preventing the extensions
> from being approved and deployed for the use cases which have already been
> demonstrated as useful by IS-IS.
> >> If you remove the Appendices I can support the draft.
> >> If you do not remove the Appendices I cannot support the draft.
> >> Please discuss this with your co-authors and come to consensus on your
> next step.
> >>Les
> >>> -Original Message-
> >>> From: Aijun Wang 
> >>> Sent: Monday, October 19, 2020 12:06 AM
> >>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
> >>> 
> >>> Cc: 'John E Drake' ; lsr-cha...@ietf.org;
> lsr@ietf.org;
> >>> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix-
> >>> origina...@ietf.org; lsr-...@ietf.org
> >>> Subject: RE: [Lsr] WG Last Call
> draft-ietf-lsr-ospf-prefix-originator-06
> >>>
> >>> Hi, Les:
> >>>
> >>> As I stated clearly before, the appendix described in the draft is not
> the new
> >>> use case. It is the start point of this draft.
> >>> Have you noticed that the introduction part is not the final usage of
> such
> >>> protocol extension information?
> >>> Certainly, we will not expand all the possible use cases in very
> detail, but
> >>> putting some of them(some interesting, prominent use cases) in the
> >>> appendix will not hamper the protocol extension itself.
> >>>
> >>> If the statements/descriptions in the appendix are not correct, we can
> fix it,
> >>> or remove it finally.  If not, why not let it be for reference to the
> user of such
> >>> protocol extension?
> >>> For the body part of this draft, we are also welcome comments.
> >>>
> >>> More replies inline below[WAJ]
> >>>
> >>> Best Regards
> >>>
> >>> Aijun Wang
> >>> China Telecom
> >>>
> >>> -Original Message-
> >>> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of
> Les
> >>> Ginsberg (ginsberg)
> >>> Sent: Monday, October 19, 2020 2:15 PM
> >>> To: Aijun Wang ; 'Christian Hopps'
> >>> 
> >>> Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les
> Ginsberg
> >>> (ginsberg)' ; lsr@ietf.org; 'Jeff
> >>> Tantsura' ; draft-ietf-lsr-ospf-prefix-
> >>> origina...@ietf.org; lsr-...@ietf.org
> >>> Subject: Re: [Lsr] WG Last Call
> draft-ietf-lsr-ospf-prefix-originator-06
> >>>
> >>> Aijun -
> >>>
> >>> The "use case" for the protocol extensions is clearly stated in the
> >>> Introduction:
> >>>
> >>> "The primary use case for the extensions proposed in this document is
> >>>to be able t

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Oct 19, 2020, at 18:34, Robert Raszuk  wrote:
> 
> 
> Aijun,
> 
> Regarding your appendix A - 
> 
> * How can we "rebuild" topology based on comparison of prefixes and rtr-id ? 

[WAJ]: The two ends of the link will advertise the same prefixes. The collector 
of BGP-LS can compare them and interconnect the two ends, which are identified 
by the originator of the said prefixes.
> 
> * If link between S1 & S2 is not in LSDB there may be a valid operational 
> reasons for it. "Rebuilding it" will be actually harmful from all points of 
> view. 

[WAJ] The rebuild process will also omit this link.

> 
> * You should be exporting topology from all areas not just from backbone and 
> guessing the topology based on the prefix to rtr_id associations 
> 
[WAJ] Exporting the topology from all areas requires the BGP-LS speakers in all 
areas, which is the burden of deployment.

> * Imaging someone is using multiaccess in areas. Are you also going to 
> rebuild DR & BDR ? 
> 
[WAJ] For OSPF, the DR/BDR is the real node. There will be no difference for 
the topology retrieval. For ISIS, the pseudo-nodes can be identified/excluded 
via the circuit-ID of LSP. 

> I must agree with comments from Peter & Les here. 
> 
> Cheers,
> R.
> 
> 
> 
> 
> 
>> On Mon, Oct 19, 2020 at 12:11 PM Aijun Wang  wrote:
>> Hi. Peter, Les:
>> 
>> We have defined many extensions for protocol, but only a small part of them 
>> are deployed. Have you ever considered the reason?
>> 
>> Adding more contents for their  potential usages can certainly be helpful 
>> for their influences, or else, they will just stay at the IETF repository.
>> 
>> More replies inline below.
>> 
>> 
>> 
>> Aijun Wang
>> China Telecom
>> 
>> > On Oct 19, 2020, at 17:14, Peter Psenak 
>> >  wrote:
>> > 
>> > Aijun,
>> > 
>> >> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
>> >> Aijun -
>> >> I am not going to continue these side discussions with you.
>> >> The primary purpose of the protocol extensions are as stated in the draft 
>> >> Introduction. This is analogous to the use cases for the equivalent 
>> >> extensions for IS-IS already approved in RFC 7794. We need the equivalent 
>> >> in OSPF.
>> >> You can show that you are listening to the concerns of WG members by 
>> >> removing the Appendices - in which case you have (I believe) broad 
>> >> support for moving the draft forward.
>> > 
>> > I agree with Les.
>> > 
>> > As a co-author, I have asked you several times to get rid of the use case 
>> > described in appendix.
>> [WAJ] Moving the expansion of this use case from body part of this draft to 
>> its appendix is our initial consensus, not remove it totally. We have 
>> discussed intensely for its application in vary situations. The discussion 
>> results are stated clearly in the appendix.
>> Wish to hear more technical analysis/comments for the current statements of 
>> this part from other experts, or from you if you have fresh consideration.
>> 
>> > Trying to use prefix advertisement to derive topological data is simply 
>> > broken. The reason we are adding the prefix originator extension to OSPF 
>> > is NOT the broken use case in the appendix of the draft.
>> > 
>> > thanks,
>> > Peter
>> > 
>> > 
>> > 
>> >> You can then write a separate draft to discuss other use cases and allow 
>> >> the WG to discuss those other use cases w/o preventing the extensions 
>> >> from being approved and deployed for the use cases which have already 
>> >> been demonstrated as useful by IS-IS.
>> >> If you remove the Appendices I can support the draft.
>> >> If you do not remove the Appendices I cannot support the draft.
>> >> Please discuss this with your co-authors and come to consensus on your 
>> >> next step.
>> >>Les
>> >>> -Original Message-
>> >>> From: Aijun Wang 
>> >>> Sent: Monday, October 19, 2020 12:06 AM
>> >>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
>> >>> 
>> >>> Cc: 'John E Drake' ; lsr-cha...@ietf.org; 
>> >>> lsr@ietf.org;
>> >>> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix-
>> >>> origina...@ietf.org; lsr-...@ietf.org
>> >>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>> >>> 
>> >>> Hi, Les:
>> >>> 
>> >>> As I stated clearly before, the appendix described in the draft is not 
>> >>> the new
>> >>> use case. It is the start point of this draft.
>> >>> Have you noticed that the introduction part is not the final usage of 
>> >>> such
>> >>> protocol extension information?
>> >>> Certainly, we will not expand all the possible use cases in very detail, 
>> >>> but
>> >>> putting some of them(some interesting, prominent use cases) in the
>> >>> appendix will not hamper the protocol extension itself.
>> >>> 
>> >>> If the statements/descriptions in the appendix are not correct, we can 
>> >>> fix it,
>> >>> or remove it finally.  If not, why not let it be for reference to the 
>> >>> user of such
>> >>> protocol extension?
>> >>> For the body part of thi

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[John E Drake]

I agree w/ Les, who I think has been extremely reasonable throughout this 
discussion.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Monday, October 19, 2020 3:32 AM
> To: Aijun Wang ; 'Christian Hopps'
> 
> Cc: John E Drake ; lsr-cha...@ietf.org; lsr@ietf.org; 
> 'Jeff
> Tantsura' ; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org; lsr-...@ietf.org
> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> [External Email. Be cautious of content]
> 
> 
> Aijun -
> 
> I am not going to continue these side discussions with you.
> 
> The primary purpose of the protocol extensions are as stated in the draft
> Introduction. This is analogous to the use cases for the equivalent 
> extensions for
> IS-IS already approved in RFC 7794. We need the equivalent in OSPF.
> 
> You can show that you are listening to the concerns of WG members by
> removing the Appendices - in which case you have (I believe) broad support for
> moving the draft forward.
> You can then write a separate draft to discuss other use cases and allow the 
> WG
> to discuss those other use cases w/o preventing the extensions from being
> approved and deployed for the use cases which have already been
> demonstrated as useful by IS-IS.
> 
> If you remove the Appendices I can support the draft.
> If you do not remove the Appendices I cannot support the draft.
> 
> Please discuss this with your co-authors and come to consensus on your next
> step.
> 
>Les
> 
> 
> > -Original Message-
> > From: Aijun Wang 
> > Sent: Monday, October 19, 2020 12:06 AM
> > To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
> > 
> > Cc: 'John E Drake' ; lsr-cha...@ietf.org;
> > lsr@ietf.org; 'Jeff Tantsura' ;
> > draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
> > Subject: RE: [Lsr] WG Last Call
> > draft-ietf-lsr-ospf-prefix-originator-06
> >
> > Hi, Les:
> >
> > As I stated clearly before, the appendix described in the draft is not
> > the new use case. It is the start point of this draft.
> > Have you noticed that the introduction part is not the final usage of
> > such protocol extension information?
> > Certainly, we will not expand all the possible use cases in very
> > detail, but putting some of them(some interesting, prominent use
> > cases) in the appendix will not hamper the protocol extension itself.
> >
> > If the statements/descriptions in the appendix are not correct, we can
> > fix it, or remove it finally.  If not, why not let it be for reference
> > to the user of such protocol extension?
> > For the body part of this draft, we are also welcome comments.
> >
> > More replies inline below[WAJ]
> >
> > Best Regards
> >
> > Aijun Wang
> > China Telecom
> >
> > -Original Message-
> > From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of
> > Les Ginsberg (ginsberg)
> > Sent: Monday, October 19, 2020 2:15 PM
> > To: Aijun Wang ; 'Christian Hopps'
> > 
> > Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les
> > Ginsberg (ginsberg)' ;
> > lsr@ietf.org; 'Jeff Tantsura' ;
> > draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
> > Subject: Re: [Lsr] WG Last Call
> > draft-ietf-lsr-ospf-prefix-originator-06
> >
> > Aijun -
> >
> > The "use case" for the protocol extensions is clearly stated in the
> > Introduction:
> >
> > "The primary use case for the extensions proposed in this document is
> >to be able to identify the originator of the prefix in the network.
> >In cases where multiple prefixes are advertised by a given router, it
> >is also useful to be able to associate all these prefixes with a
> >single router even when prefixes are advertised outside of the area
> >in which they originated.  It also helps to determine when the same
> >prefix is being originated by multiple routers across areas."
> >
> > This is equivalent to language in RFC 7794 which defines the analogous
> > extensions for IS-IS.
> >
> > Everything you have in the Appendix is not related to the primary use
> > case - and is fact a use case which many of us have objected to.
> > [WAJ] Very glad to know the false statements in the appendix.
> >
> > You are entitled to write another draft advocating for your new use
> > case if you wish, but requiring that the protocol extensions in
> > support of the primary use case not go forward without your new use
> > case is - as Chris has stated very clearly - holding approval of the
> > protocol extensions hostage to your new use case.
> > [WAJ] It is not new use case. As I sated before, I am open to this
> > part, but should on the conditions that the statements in this part are
> incorrect.
> >
> > I am asking you (yet again) not to do this.
> >
> > I cannot support the document moving forward with the content in the
> > Appendices included.
> > [WAJ] Would like to hear more technical analysis.
> >
> >Les
> >
> >
> > > -Original Message-
> > > From: 

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[John E Drake]

Aijun,

What part of "using IP address advertisement to derive topological data is 
broken" do you not understand?

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Peter Psenak 
> Sent: Monday, October 19, 2020 6:32 AM
> To: Aijun Wang ; Peter Psenak
> 
> Cc: Les Ginsberg (ginsberg) ; Aijun Wang
> ; Christian Hopps ; John E
> Drake ; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura
> ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; 
> lsr-
> a...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Aijun,
> 
> please see inline:
> 
> 
> On 19/10/2020 12:10, Aijun Wang wrote:
> > Hi. Peter, Les:
> >
> > We have defined many extensions for protocol, but only a small part of them
> are deployed. Have you ever considered the reason?
> >
> > Adding more contents for their  potential usages can certainly be helpful 
> > for
> their influences, or else, they will just stay at the IETF repository.
> 
> I disagree. RFCs are not deployment or use case documents. They exists to
> address the interoperability.
> 
> >
> > More replies inline below.
> >
> >
> >
> > Aijun Wang
> > China Telecom
> >
> >> On Oct 19, 2020, at 17:14, Peter Psenak
>  wrote:
> >>
> >> Aijun,
> >>
> >>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> >>> Aijun -
> >>> I am not going to continue these side discussions with you.
> >>> The primary purpose of the protocol extensions are as stated in the draft
> Introduction. This is analogous to the use cases for the equivalent 
> extensions for
> IS-IS already approved in RFC 7794. We need the equivalent in OSPF.
> >>> You can show that you are listening to the concerns of WG members by
> removing the Appendices - in which case you have (I believe) broad support for
> moving the draft forward.
> >>
> >> I agree with Les.
> >>
> >> As a co-author, I have asked you several times to get rid of the use case
> described in appendix.
> > [WAJ] Moving the expansion of this use case from body part of this draft to 
> > its
> appendix is our initial consensus, not remove it totally. We have discussed
> intensely for its application in vary situations. The discussion results are 
> stated
> clearly in the appendix.
> 
> just because you insisted and did not listen to rest of us.
> 
> > Wish to hear more technical analysis/comments for the current statements of
> this part from other experts, or from you if you have fresh consideration.
> 
> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan,
> myself) are telling you that using IP address advertisement to derive 
> topological
> data is broken and you keep repeating it is valid use case and ask for more
> reasoning.
> 
> thanks,
> Peter
> 
> >
> >> Trying to use prefix advertisement to derive topological data is simply
> broken. The reason we are adding the prefix originator extension to OSPF is 
> NOT
> the broken use case in the appendix of the draft.
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >>
> >>> You can then write a separate draft to discuss other use cases and allow 
> >>> the
> WG to discuss those other use cases w/o preventing the extensions from being
> approved and deployed for the use cases which have already been
> demonstrated as useful by IS-IS.
> >>> If you remove the Appendices I can support the draft.
> >>> If you do not remove the Appendices I cannot support the draft.
> >>> Please discuss this with your co-authors and come to consensus on your
> next step.
> >>> Les
>  -Original Message-
>  From: Aijun Wang 
>  Sent: Monday, October 19, 2020 12:06 AM
>  To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
>  
>  Cc: 'John E Drake' ; lsr-cha...@ietf.org;
>  lsr@ietf.org; 'Jeff Tantsura' ;
>  draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
>  Subject: RE: [Lsr] WG Last Call
>  draft-ietf-lsr-ospf-prefix-originator-06
> 
>  Hi, Les:
> 
>  As I stated clearly before, the appendix described in the draft is
>  not the new use case. It is the start point of this draft.
>  Have you noticed that the introduction part is not the final usage
>  of such protocol extension information?
>  Certainly, we will not expand all the possible use cases in very
>  detail, but putting some of them(some interesting, prominent use
>  cases) in the appendix will not hamper the protocol extension itself.
> 
>  If the statements/descriptions in the appendix are not correct, we
>  can fix it, or remove it finally.  If not, why not let it be for
>  reference to the user of such protocol extension?
>  For the body part of this draft, we are also welcome comments.
> 
>  More replies inline below[WAJ]
> 
>  Best Regards
> 
>  Aijun Wang
>  China Telecom
> 
>  -Original Message-
>  From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Aijun Wang]

Hi, John:

Would you like to illustrate your broken case more clearly and not make the 
conclusion so hurry?


Aijun Wang
China Telecom

> On Oct 19, 2020, at 22:15, John E Drake  
> wrote:
> 
> Aijun,
> 
> What part of "using IP address advertisement to derive topological data is 
> broken" do you not understand?
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: Peter Psenak 
>> Sent: Monday, October 19, 2020 6:32 AM
>> To: Aijun Wang ; Peter Psenak
>> 
>> Cc: Les Ginsberg (ginsberg) ; Aijun Wang
>> ; Christian Hopps ; John E
>> Drake ; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura
>> ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; 
>> lsr-
>> a...@ietf.org
>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>> [External Email. Be cautious of content]
>> Hi Aijun,
>> please see inline:
>>> On 19/10/2020 12:10, Aijun Wang wrote:
>>> Hi. Peter, Les:
>>> We have defined many extensions for protocol, but only a small part of them
>> are deployed. Have you ever considered the reason?
>>> Adding more contents for their  potential usages can certainly be helpful 
>>> for
>> their influences, or else, they will just stay at the IETF repository.
>> I disagree. RFCs are not deployment or use case documents. They exists to
>> address the interoperability.
>>> More replies inline below.
>>> Aijun Wang
>>> China Telecom
 On Oct 19, 2020, at 17:14, Peter Psenak
>>  wrote:
 Aijun,
> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> Aijun -
> I am not going to continue these side discussions with you.
> The primary purpose of the protocol extensions are as stated in the draft
>> Introduction. This is analogous to the use cases for the equivalent 
>> extensions for
>> IS-IS already approved in RFC 7794. We need the equivalent in OSPF.
> You can show that you are listening to the concerns of WG members by
>> removing the Appendices - in which case you have (I believe) broad support 
>> for
>> moving the draft forward.
 I agree with Les.
 As a co-author, I have asked you several times to get rid of the use case
>> described in appendix.
>>> [WAJ] Moving the expansion of this use case from body part of this draft to 
>>> its
>> appendix is our initial consensus, not remove it totally. We have discussed
>> intensely for its application in vary situations. The discussion results are 
>> stated
>> clearly in the appendix.
>> just because you insisted and did not listen to rest of us.
>>> Wish to hear more technical analysis/comments for the current statements of
>> this part from other experts, or from you if you have fresh consideration.
>> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan,
>> myself) are telling you that using IP address advertisement to derive 
>> topological
>> data is broken and you keep repeating it is valid use case and ask for more
>> reasoning.
>> thanks,
>> Peter
 Trying to use prefix advertisement to derive topological data is simply
>> broken. The reason we are adding the prefix originator extension to OSPF is 
>> NOT
>> the broken use case in the appendix of the draft.
 thanks,
 Peter
> You can then write a separate draft to discuss other use cases and allow 
> the
>> WG to discuss those other use cases w/o preventing the extensions from being
>> approved and deployed for the use cases which have already been
>> demonstrated as useful by IS-IS.
> If you remove the Appendices I can support the draft.
> If you do not remove the Appendices I cannot support the draft.
> Please discuss this with your co-authors and come to consensus on your
>> next step.
>  Les
>> -Original Message-
>> From: Aijun Wang 
>> Sent: Monday, October 19, 2020 12:06 AM
>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
>> 
>> Cc: 'John E Drake' ; lsr-cha...@ietf.org;
>> lsr@ietf.org; 'Jeff Tantsura' ;
>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
>> Subject: RE: [Lsr] WG Last Call
>> draft-ietf-lsr-ospf-prefix-originator-06
>> Hi, Les:
>> As I stated clearly before, the appendix described in the draft is
>> not the new use case. It is the start point of this draft.
>> Have you noticed that the introduction part is not the final usage
>> of such protocol extension information?
>> Certainly, we will not expand all the possible use cases in very
>> detail, but putting some of them(some interesting, prominent use
>> cases) in the appendix will not hamper the protocol extension itself.
>> If the statements/descriptions in the appendix are not correct, we
>> can fix it, or remove it finally.  If not, why not let it be for
>> reference to the user of such protocol extension?
>> For the body part of this draft, we are also welcome comments.
>> More replies inline below[WAJ]
>> Best Regards
>> Aijun Wang
>> China Telecom

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Aijun Wang]

Hi, John:

Would you like to illustrate your broken case more clearly and not make the 
conclusion so hurry?


Aijun Wang
China Telecom

> On Oct 19, 2020, at 22:15, John E Drake  
> wrote:
> 
> Aijun,
> 
> What part of "using IP address advertisement to derive topological data is 
> broken" do you not understand?
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: Peter Psenak 
>> Sent: Monday, October 19, 2020 6:32 AM
>> To: Aijun Wang ; Peter Psenak
>> 
>> Cc: Les Ginsberg (ginsberg) ; Aijun Wang
>> ; Christian Hopps ; John E
>> Drake ; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura
>> ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; 
>> lsr-
>> a...@ietf.org
>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>> [External Email. Be cautious of content]
>> Hi Aijun,
>> please see inline:
>>> On 19/10/2020 12:10, Aijun Wang wrote:
>>> Hi. Peter, Les:
>>> We have defined many extensions for protocol, but only a small part of them
>> are deployed. Have you ever considered the reason?
>>> Adding more contents for their  potential usages can certainly be helpful 
>>> for
>> their influences, or else, they will just stay at the IETF repository.
>> I disagree. RFCs are not deployment or use case documents. They exists to
>> address the interoperability.
>>> More replies inline below.
>>> Aijun Wang
>>> China Telecom
 On Oct 19, 2020, at 17:14, Peter Psenak
>>  wrote:
 Aijun,
> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> Aijun -
> I am not going to continue these side discussions with you.
> The primary purpose of the protocol extensions are as stated in the draft
>> Introduction. This is analogous to the use cases for the equivalent 
>> extensions for
>> IS-IS already approved in RFC 7794. We need the equivalent in OSPF.
> You can show that you are listening to the concerns of WG members by
>> removing the Appendices - in which case you have (I believe) broad support 
>> for
>> moving the draft forward.
 I agree with Les.
 As a co-author, I have asked you several times to get rid of the use case
>> described in appendix.
>>> [WAJ] Moving the expansion of this use case from body part of this draft to 
>>> its
>> appendix is our initial consensus, not remove it totally. We have discussed
>> intensely for its application in vary situations. The discussion results are 
>> stated
>> clearly in the appendix.
>> just because you insisted and did not listen to rest of us.
>>> Wish to hear more technical analysis/comments for the current statements of
>> this part from other experts, or from you if you have fresh consideration.
>> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan,
>> myself) are telling you that using IP address advertisement to derive 
>> topological
>> data is broken and you keep repeating it is valid use case and ask for more
>> reasoning.
>> thanks,
>> Peter
 Trying to use prefix advertisement to derive topological data is simply
>> broken. The reason we are adding the prefix originator extension to OSPF is 
>> NOT
>> the broken use case in the appendix of the draft.
 thanks,
 Peter
> You can then write a separate draft to discuss other use cases and allow 
> the
>> WG to discuss those other use cases w/o preventing the extensions from being
>> approved and deployed for the use cases which have already been
>> demonstrated as useful by IS-IS.
> If you remove the Appendices I can support the draft.
> If you do not remove the Appendices I cannot support the draft.
> Please discuss this with your co-authors and come to consensus on your
>> next step.
> Les
>> -Original Message-
>> From: Aijun Wang 
>> Sent: Monday, October 19, 2020 12:06 AM
>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
>> 
>> Cc: 'John E Drake' ; lsr-cha...@ietf.org;
>> lsr@ietf.org; 'Jeff Tantsura' ;
>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
>> Subject: RE: [Lsr] WG Last Call
>> draft-ietf-lsr-ospf-prefix-originator-06
>> Hi, Les:
>> As I stated clearly before, the appendix described in the draft is
>> not the new use case. It is the start point of this draft.
>> Have you noticed that the introduction part is not the final usage
>> of such protocol extension information?
>> Certainly, we will not expand all the possible use cases in very
>> detail, but putting some of them(some interesting, prominent use
>> cases) in the appendix will not hamper the protocol extension itself.
>> If the statements/descriptions in the appendix are not correct, we
>> can fix it, or remove it finally.  If not, why not let it be for
>> reference to the user of such protocol extension?
>> For the body part of this draft, we are also welcome comments.
>> More replies inline below[WAJ]
>> Best Regards
>> Aijun Wang
>> China Telecom

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Aijun Wang]

Hi, John:

Would you like to illustrate your broken case more clearly and not make the 
conclusion so hurry?


Aijun Wang
China Telecom

> On Oct 19, 2020, at 22:15, John E Drake  
> wrote:
> 
> Aijun,
> 
> What part of "using IP address advertisement to derive topological data is 
> broken" do you not understand?
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: Peter Psenak 
>> Sent: Monday, October 19, 2020 6:32 AM
>> To: Aijun Wang ; Peter Psenak
>> 
>> Cc: Les Ginsberg (ginsberg) ; Aijun Wang
>> ; Christian Hopps ; John E
>> Drake ; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura
>> ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; 
>> lsr-
>> a...@ietf.org
>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>> [External Email. Be cautious of content]
>> Hi Aijun,
>> please see inline:
>>> On 19/10/2020 12:10, Aijun Wang wrote:
>>> Hi. Peter, Les:
>>> We have defined many extensions for protocol, but only a small part of them
>> are deployed. Have you ever considered the reason?
>>> Adding more contents for their  potential usages can certainly be helpful 
>>> for
>> their influences, or else, they will just stay at the IETF repository.
>> I disagree. RFCs are not deployment or use case documents. They exists to
>> address the interoperability.
>>> More replies inline below.
>>> Aijun Wang
>>> China Telecom
 On Oct 19, 2020, at 17:14, Peter Psenak
>>  wrote:
 Aijun,
> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> Aijun -
> I am not going to continue these side discussions with you.
> The primary purpose of the protocol extensions are as stated in the draft
>> Introduction. This is analogous to the use cases for the equivalent 
>> extensions for
>> IS-IS already approved in RFC 7794. We need the equivalent in OSPF.
> You can show that you are listening to the concerns of WG members by
>> removing the Appendices - in which case you have (I believe) broad support 
>> for
>> moving the draft forward.
 I agree with Les.
 As a co-author, I have asked you several times to get rid of the use case
>> described in appendix.
>>> [WAJ] Moving the expansion of this use case from body part of this draft to 
>>> its
>> appendix is our initial consensus, not remove it totally. We have discussed
>> intensely for its application in vary situations. The discussion results are 
>> stated
>> clearly in the appendix.
>> just because you insisted and did not listen to rest of us.
>>> Wish to hear more technical analysis/comments for the current statements of
>> this part from other experts, or from you if you have fresh consideration.
>> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan,
>> myself) are telling you that using IP address advertisement to derive 
>> topological
>> data is broken and you keep repeating it is valid use case and ask for more
>> reasoning.
>> thanks,
>> Peter
 Trying to use prefix advertisement to derive topological data is simply
>> broken. The reason we are adding the prefix originator extension to OSPF is 
>> NOT
>> the broken use case in the appendix of the draft.
 thanks,
 Peter
> You can then write a separate draft to discuss other use cases and allow 
> the
>> WG to discuss those other use cases w/o preventing the extensions from being
>> approved and deployed for the use cases which have already been
>> demonstrated as useful by IS-IS.
> If you remove the Appendices I can support the draft.
> If you do not remove the Appendices I cannot support the draft.
> Please discuss this with your co-authors and come to consensus on your
>> next step.
> Les
>> -Original Message-
>> From: Aijun Wang 
>> Sent: Monday, October 19, 2020 12:06 AM
>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
>> 
>> Cc: 'John E Drake' ; lsr-cha...@ietf.org;
>> lsr@ietf.org; 'Jeff Tantsura' ;
>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
>> Subject: RE: [Lsr] WG Last Call
>> draft-ietf-lsr-ospf-prefix-originator-06
>> Hi, Les:
>> As I stated clearly before, the appendix described in the draft is
>> not the new use case. It is the start point of this draft.
>> Have you noticed that the introduction part is not the final usage
>> of such protocol extension information?
>> Certainly, we will not expand all the possible use cases in very
>> detail, but putting some of them(some interesting, prominent use
>> cases) in the appendix will not hamper the protocol extension itself.
>> If the statements/descriptions in the appendix are not correct, we
>> can fix it, or remove it finally.  If not, why not let it be for
>> reference to the user of such protocol extension?
>> For the body part of this draft, we are also welcome comments.
>> More replies inline below[WAJ]
>> Best Regards
>> Aijun Wang
>> China Telecom

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[John E Drake]

Hi,

It seems that we have been going around on this topic for an eternity, so to 
explain it again would simply be an exercise in pounding sand.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: wang...@chinatelecom.cn 
> Sent: Monday, October 19, 2020 10:41 AM
> To: John E Drake 
> Cc: Peter Psenak ; Peter Psenak ;
> Les Ginsberg (ginsberg) ; Christian Hopps
> ; Aijun Wang ; lsr-
> cha...@ietf.org; lsr@ietf.org; Jeff Tantsura ; draft-
> ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> [External Email. Be cautious of content]
> 
> 
> Hi, John:
> 
> Would you like to illustrate your broken case more clearly and not make the
> conclusion so hurry?
> 
> 
> Aijun Wang
> China Telecom
> 
> > On Oct 19, 2020, at 22:15, John E Drake
>  wrote:
> >
> > Aijun,
> >
> > What part of "using IP address advertisement to derive topological data is
> broken" do you not understand?
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> >> -Original Message-
> >> From: Peter Psenak 
> >> Sent: Monday, October 19, 2020 6:32 AM
> >> To: Aijun Wang ; Peter Psenak
> >> 
> >> Cc: Les Ginsberg (ginsberg) ; Aijun Wang
> >> ; Christian Hopps ;
> >> John E Drake ; lsr-cha...@ietf.org; lsr@ietf.org;
> >> Jeff Tantsura ;
> >> draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr- a...@ietf.org
> >> Subject: Re: [Lsr] WG Last Call
> >> draft-ietf-lsr-ospf-prefix-originator-06
> >> [External Email. Be cautious of content] Hi Aijun, please see inline:
> >>> On 19/10/2020 12:10, Aijun Wang wrote:
> >>> Hi. Peter, Les:
> >>> We have defined many extensions for protocol, but only a small part
> >>> of them
> >> are deployed. Have you ever considered the reason?
> >>> Adding more contents for their  potential usages can certainly be
> >>> helpful for
> >> their influences, or else, they will just stay at the IETF repository.
> >> I disagree. RFCs are not deployment or use case documents. They
> >> exists to address the interoperability.
> >>> More replies inline below.
> >>> Aijun Wang
> >>> China Telecom
>  On Oct 19, 2020, at 17:14, Peter Psenak
> >>  wrote:
>  Aijun,
> > On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> > Aijun -
> > I am not going to continue these side discussions with you.
> > The primary purpose of the protocol extensions are as stated in
> > the draft
> >> Introduction. This is analogous to the use cases for the equivalent
> >> extensions for IS-IS already approved in RFC 7794. We need the equivalent 
> >> in
> OSPF.
> > You can show that you are listening to the concerns of WG members
> > by
> >> removing the Appendices - in which case you have (I believe) broad
> >> support for moving the draft forward.
>  I agree with Les.
>  As a co-author, I have asked you several times to get rid of the
>  use case
> >> described in appendix.
> >>> [WAJ] Moving the expansion of this use case from body part of this
> >>> draft to its
> >> appendix is our initial consensus, not remove it totally. We have
> >> discussed intensely for its application in vary situations. The
> >> discussion results are stated clearly in the appendix.
> >> just because you insisted and did not listen to rest of us.
> >>> Wish to hear more technical analysis/comments for the current
> >>> statements of
> >> this part from other experts, or from you if you have fresh consideration.
> >> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan,
> >> myself) are telling you that using IP address advertisement to derive
> >> topological data is broken and you keep repeating it is valid use
> >> case and ask for more reasoning.
> >> thanks,
> >> Peter
>  Trying to use prefix advertisement to derive topological data is
>  simply
> >> broken. The reason we are adding the prefix originator extension to
> >> OSPF is NOT the broken use case in the appendix of the draft.
>  thanks,
>  Peter
> > You can then write a separate draft to discuss other use cases and
> > allow the
> >> WG to discuss those other use cases w/o preventing the extensions
> >> from being approved and deployed for the use cases which have already
> >> been demonstrated as useful by IS-IS.
> > If you remove the Appendices I can support the draft.
> > If you do not remove the Appendices I cannot support the draft.
> > Please discuss this with your co-authors and come to consensus on
> > your
> >> next step.
> >  Les
> >> -Original Message-
> >> From: Aijun Wang 
> >> Sent: Monday, October 19, 2020 12:06 AM
> >> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
> >> 
> >> Cc: 'John E Drake' ; lsr-cha...@ietf.org;
> >> lsr@ietf.org; 'Jeff Tantsura' ;
> >> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org
> >> Subject: RE: [Lsr] WG Last Call
> >> draft-ietf-lsr-

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Aijun Wang]

Would you like to refer the cases raised from Robert?
Such discussion can be fruitful for the refine or forwarding of this draft.
One should convince others based on the fact, not subjective opinion.

Aijun Wang
China Telecom

> On Oct 19, 2020, at 22:52, John E Drake  wrote:
> 
> Hi,
> 
> It seems that we have been going around on this topic for an eternity, so to 
> explain it again would simply be an exercise in pounding sand.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: wang...@chinatelecom.cn 
>> Sent: Monday, October 19, 2020 10:41 AM
>> To: John E Drake 
>> Cc: Peter Psenak ; Peter Psenak ;
>> Les Ginsberg (ginsberg) ; Christian Hopps
>> ; Aijun Wang ; lsr-
>> cha...@ietf.org; lsr@ietf.org; Jeff Tantsura ; 
>> draft-
>> ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-...@ietf.org
>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> Hi, John:
>> 
>> Would you like to illustrate your broken case more clearly and not make the
>> conclusion so hurry?
>> 
>> 
>> Aijun Wang
>> China Telecom
>> 
>>> On Oct 19, 2020, at 22:15, John E Drake
>>  wrote:
>>> 
>>> Aijun,
>>> 
>>> What part of "using IP address advertisement to derive topological data is
>> broken" do you not understand?
>>> 
>>> Yours Irrespectively,
>>> 
>>> John
>>> 
>>> 
>>> Juniper Business Use Only
>>> 
 -Original Message-
 From: Peter Psenak 
 Sent: Monday, October 19, 2020 6:32 AM
 To: Aijun Wang ; Peter Psenak
 
 Cc: Les Ginsberg (ginsberg) ; Aijun Wang
 ; Christian Hopps ;
 John E Drake ; lsr-cha...@ietf.org; lsr@ietf.org;
 Jeff Tantsura ;
 draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr- a...@ietf.org
 Subject: Re: [Lsr] WG Last Call
 draft-ietf-lsr-ospf-prefix-originator-06
 [External Email. Be cautious of content] Hi Aijun, please see inline:
> On 19/10/2020 12:10, Aijun Wang wrote:
> Hi. Peter, Les:
> We have defined many extensions for protocol, but only a small part
> of them
 are deployed. Have you ever considered the reason?
> Adding more contents for their  potential usages can certainly be
> helpful for
 their influences, or else, they will just stay at the IETF repository.
 I disagree. RFCs are not deployment or use case documents. They
 exists to address the interoperability.
> More replies inline below.
> Aijun Wang
> China Telecom
>> On Oct 19, 2020, at 17:14, Peter Psenak
  wrote:
>> Aijun,
>>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
>>> Aijun -
>>> I am not going to continue these side discussions with you.
>>> The primary purpose of the protocol extensions are as stated in
>>> the draft
 Introduction. This is analogous to the use cases for the equivalent
 extensions for IS-IS already approved in RFC 7794. We need the equivalent 
 in
>> OSPF.
>>> You can show that you are listening to the concerns of WG members
>>> by
 removing the Appendices - in which case you have (I believe) broad
 support for moving the draft forward.
>> I agree with Les.
>> As a co-author, I have asked you several times to get rid of the
>> use case
 described in appendix.
> [WAJ] Moving the expansion of this use case from body part of this
> draft to its
 appendix is our initial consensus, not remove it totally. We have
 discussed intensely for its application in vary situations. The
 discussion results are stated clearly in the appendix.
 just because you insisted and did not listen to rest of us.
> Wish to hear more technical analysis/comments for the current
> statements of
 this part from other experts, or from you if you have fresh consideration.
 we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan,
 myself) are telling you that using IP address advertisement to derive
 topological data is broken and you keep repeating it is valid use
 case and ask for more reasoning.
 thanks,
 Peter
>> Trying to use prefix advertisement to derive topological data is
>> simply
 broken. The reason we are adding the prefix originator extension to
 OSPF is NOT the broken use case in the appendix of the draft.
>> thanks,
>> Peter
>>> You can then write a separate draft to discuss other use cases and
>>> allow the
 WG to discuss those other use cases w/o preventing the extensions
 from being approved and deployed for the use cases which have already
 been demonstrated as useful by IS-IS.
>>> If you remove the Appendices I can support the draft.
>>> If you do not remove the Appendices I cannot support the draft.
>>> Please discuss this with your co-authors and come to consensus on
>>> your
 next step.
>>> Les
 -Original Message-
 From: Aijun Wang 
>>>

[Lsr] draft-xie-lsr-isis-sr-vtn-mt-02

[Huaimo Chen]

Hi Authors,

I have the following comments/questions:

In a network, can we use other methods to define VTNs while MTs are used as 
VTNs?

If so, other methods may be used to define VTNs in addition to using MTs as 
VTNs in the same network. The draft says that MT-ID could be used as VTN-ID. In 
this case, a block of VTN-IDs must be allocated/reserved specially for using 
MT-IDs as VTN-IDs. It seems better to state something about this in the draft.

An IS-IS MT has the attributes of a VTN, including the specific topology 
and resource. An IS-IS MT can be used as a VTN and MT-ID can be used as a VTN 
ID. Is it possible for an IS-IS MT to be used/shared by two or more VTNs? If 
so, it seems better to have some details about how the multiple VTNs use/share 
the resource in the same one MT.

In section 5 "Scalability Considerations", the draft says that while 
multiple VTNs share the same topology attribute, the same topology is 
identified by multiple different MT-IDs. This seems giving a way to let two or 
more VTNs to use/share one MT if IS-IS MT allows multiple MT-IDs to be used for 
the same one MT. It seems better to move the related text from section 5 to 
some of the previous sections.

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[John E Drake]

No, as I indicated previously, this discussion has been had many times - it 
reminds me of 'Groundhog Day'.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Aijun Wang 
> Sent: Monday, October 19, 2020 11:00 AM
> To: John E Drake 
> Cc: wang...@chinatelecom.cn; Peter Psenak ; Les
> Ginsberg (ginsberg) ; Christian Hopps
> ; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura
> ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; 
> lsr-
> a...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> [External Email. Be cautious of content]
> 
> 
> Would you like to refer the cases raised from Robert?
> Such discussion can be fruitful for the refine or forwarding of this draft.
> One should convince others based on the fact, not subjective opinion.
> 
> Aijun Wang
> China Telecom
> 
> > On Oct 19, 2020, at 22:52, John E Drake  wrote:
> >
> > Hi,
> >
> > It seems that we have been going around on this topic for an eternity, so to
> explain it again would simply be an exercise in pounding sand.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> >> -Original Message-
> >> From: wang...@chinatelecom.cn 
> >> Sent: Monday, October 19, 2020 10:41 AM
> >> To: John E Drake 
> >> Cc: Peter Psenak ; Peter Psenak
> >> ; Les Ginsberg (ginsberg) ;
> >> Christian Hopps ; Aijun Wang
> >> ; lsr- cha...@ietf.org; lsr@ietf.org; Jeff
> >> Tantsura ; draft-
> >> ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-...@ietf.org
> >> Subject: Re: [Lsr] WG Last Call
> >> draft-ietf-lsr-ospf-prefix-originator-06
> >>
> >> [External Email. Be cautious of content]
> >>
> >>
> >> Hi, John:
> >>
> >> Would you like to illustrate your broken case more clearly and not
> >> make the conclusion so hurry?
> >>
> >>
> >> Aijun Wang
> >> China Telecom
> >>
> >>> On Oct 19, 2020, at 22:15, John E Drake
> >>  wrote:
> >>>
> >>> Aijun,
> >>>
> >>> What part of "using IP address advertisement to derive topological
> >>> data is
> >> broken" do you not understand?
> >>>
> >>> Yours Irrespectively,
> >>>
> >>> John
> >>>
> >>>
> >>> Juniper Business Use Only
> >>>
>  -Original Message-
>  From: Peter Psenak 
>  Sent: Monday, October 19, 2020 6:32 AM
>  To: Aijun Wang ; Peter Psenak
>  
>  Cc: Les Ginsberg (ginsberg) ; Aijun Wang
>  ; Christian Hopps ;
>  John E Drake ; lsr-cha...@ietf.org;
>  lsr@ietf.org; Jeff Tantsura ;
>  draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr- a...@ietf.org
>  Subject: Re: [Lsr] WG Last Call
>  draft-ietf-lsr-ospf-prefix-originator-06
>  [External Email. Be cautious of content] Hi Aijun, please see inline:
> > On 19/10/2020 12:10, Aijun Wang wrote:
> > Hi. Peter, Les:
> > We have defined many extensions for protocol, but only a small
> > part of them
>  are deployed. Have you ever considered the reason?
> > Adding more contents for their  potential usages can certainly be
> > helpful for
>  their influences, or else, they will just stay at the IETF repository.
>  I disagree. RFCs are not deployment or use case documents. They
>  exists to address the interoperability.
> > More replies inline below.
> > Aijun Wang
> > China Telecom
> >> On Oct 19, 2020, at 17:14, Peter Psenak
>   wrote:
> >> Aijun,
> >>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> >>> Aijun -
> >>> I am not going to continue these side discussions with you.
> >>> The primary purpose of the protocol extensions are as stated in
> >>> the draft
>  Introduction. This is analogous to the use cases for the equivalent
>  extensions for IS-IS already approved in RFC 7794. We need the
>  equivalent in
> >> OSPF.
> >>> You can show that you are listening to the concerns of WG
> >>> members by
>  removing the Appendices - in which case you have (I believe) broad
>  support for moving the draft forward.
> >> I agree with Les.
> >> As a co-author, I have asked you several times to get rid of the
> >> use case
>  described in appendix.
> > [WAJ] Moving the expansion of this use case from body part of this
> > draft to its
>  appendix is our initial consensus, not remove it totally. We have
>  discussed intensely for its application in vary situations. The
>  discussion results are stated clearly in the appendix.
>  just because you insisted and did not listen to rest of us.
> > Wish to hear more technical analysis/comments for the current
> > statements of
>  this part from other experts, or from you if you have fresh 
>  consideration.
>  we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan,
>  myself) are telling you that using IP address advertisement to
>  derive topological data is broken and you keep repeating it is
>  valid use case and ask for more reasoning.
>  thanks,
>  Pet

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[bruno.decraene]

Ron, all,

>From a use case standpoint, I have a use case for having both SR-MPLS and IP 
>flexalgo in the same network.

>From a protocol standpoint, I think that the functionality could be equally 
>met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit 
>null) to instruct the LER/LSR to not use a label in the forwarding plane. 
>(while still advertising a label in the control plane because we have to).
I feel that this would be less change in the protocol (no new tlv), a good fit 
for network requiring both MPLS and IP flex algo, and would not require 
implementations/network operator to duplicate the "prefix sub-TLV" [1] on both 
advertisements (IP based and SR-MPLS based).

That would still requires a protocol extension/STD track RFC as RFC 8667 does 
not allow for this. That would still require change to implementations as only 
the signalling is different while the feature/behavior is the same (i.e. no 
magic).

Regards,
--Bruno

[1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT 
IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"


> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> Sent: Tuesday, September 29, 2020 3:38 PM
> To: lsr@ietf.org
> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-
> 00.txt
> 
> 
> Please review and comment
> 
>Ron
> 
> 
> 
> Juniper Business Use Only
> 
> > -Original Message-
> > From: internet-dra...@ietf.org 
> > Sent: Tuesday, September 29, 2020 9:36 AM
> > To: Parag Kaneriya ; Shraddha Hegde
> > ; Ron Bonica ; Rajesh M
> > ; William Britto A J 
> > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > [External Email. Be cautious of content]
> >
> >
> > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> > has been successfully submitted by Ron Bonica and posted to the IETF
> > repository.
> >
> > Name:   draft-bonica-lsr-ip-flexalgo
> > Revision:   00
> > Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> > Document date:  2020-09-29
> > Group:  Individual Submission
> > Pages:  14
> > URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft-
> bonica-
> > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> > Status:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> bonica-lsr-
> > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> > Htmlized:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> > Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
> >
> >
> > Abstract:
> >An IGP Flexible Algorithm computes a constraint-based path and maps
> >that path to an identifier.  As currently defined, Flexalgo can only
> >map the paths that it computes to Segment Routing (SR) identifiers.
> >Therefore, Flexalgo cannot be deployed in the absence of SR.
> >
> >This document extends Flexalgo, so that it can map the paths that it
> >computes to IP addresses.  This allows Flexalgo to be deployed in any
> >IP network, even in the absence of SR.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Christian Hopps]

> On Oct 16, 2020, at 4:47 AM, Aijun Wang  wrote:
> 
> Hi, Les and experts in LSR:
> 
> I am open to the removal of the this appendix to forward this draft.

That's good news, thank you Aijun.

Speaking for the chairs,

We believe we have reached WG consensus (seems better than just rough even with 
some authors asking for the change) at this point on the removal of the 
disputed use-case appendices.

Could you please republish the document w/o the disputed sections?

Thanks,
Chris.

> But as stated in previous mail, providing this can assist the user/reader of 
> the draft. We often encounter the questions in the mail list that what the 
> usage of protocol/bit definition in some drafts.
> 
> Actually, we did not expand the discussion of this part in this draft. The 
> description of this part is very concise.
> 
> If you insist this, I can update the draft in recent days, together with 
> other comments on this draft.
> 
> Other comments are welcome also!
> 
> Aijun Wang
> China Telecom
> 
>> On Oct 16, 2020, at 13:51, Les Ginsberg (ginsberg)  
>> wrote:
>> 
>> Aijun -
>> 
>> The point I am making is very focused.
>> 
>> This draft is defining a protocol extension. As such it is necessary that 
>> this be Standards track as adhering to the normative statements in the draft 
>> are necessary for interoperability.
>> 
>> What is discussed in the Appendix is a use case. It is not normative and 
>> there are strong opinions on both sides as to whether this is an appropriate 
>> use case or not.
>> In the context of this draft, I have no interest in trying to resolve our 
>> difference of opinion on this use case. I simply want the protocol extension 
>> to move forward so that we have another tool available.
>> 
>> If you want to write a draft on the use case discussed in the Appendix 
>> please feel free to do so. That draft may very well not be normative - 
>> Informational or BCP may be more appropriate - because it will be discussing 
>> a deployment scenario and a proposal to use defined protocol extensions as 
>> one way to solve problems in that deployment scenario. Such a draft might 
>> also be more appropriate in another WG (e.g., TEAS). The merits of using 
>> prefix advertisements to build a topology could then be discussed on its own.
>> 
>> Please do not try to avoid having a full discussion of the merits of using 
>> prefix advertisements to derive topology by adding it to a draft that is 
>> (and should be) focused on simple protocol extensions.
>> 
>> Thanx.
>> 
>>  Les
>> 
>> 
>>> -Original Message-
>>> From: Aijun Wang 
>>> Sent: Thursday, October 15, 2020 6:51 PM
>>> To: 'Jeff Tantsura' ; 'John E Drake'
>>> 
>>> Cc: 'Christian Hopps' ; lsr-cha...@ietf.org; Les Ginsberg
>>> (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; draft-ietf-
>>> lsr-ospf-prefix-origina...@ietf.org
>>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>>> 
>>> Hi, Les, John and Jeff:
>>> 
>>> Let's reply you all together.
>>> In my POV, The standard document should not define solely the protocol
>>> extension, but their usages in the network deployment. As I known, almost
>>> all the IETF documents following this style.
>>> And, before adopting one work, we have often intense discussion for what's
>>> their usages.
>>> Such discussion in the mail list and statements in the doc
> 



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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Acee Lindem (acee)]

Speaking as WG chair: 

On 10/19/20, 1:06 PM, "Christian Hopps"  wrote:



> On Oct 16, 2020, at 4:47 AM, Aijun Wang  wrote:
> 
> Hi, Les and experts in LSR:
> 
> I am open to the removal of the this appendix to forward this draft.

That's good news, thank you Aijun.

Speaking for the chairs,

We believe we have reached WG consensus (seems better than just rough even 
with some authors asking for the change) at this point on the removal of the 
disputed use-case appendices.

Could you please republish the document w/o the disputed sections?

Thanks,
Chris.

I'll add that RFC 7221, section 1.2 
https://tools.ietf.org/html/rfc7221#section-1.2  includes a very good 
description of the IETF process for WG document ownership and consensus. 

Thanks,
Acee

> But as stated in previous mail, providing this can assist the user/reader 
of the draft. We often encounter the questions in the mail list that what the 
usage of protocol/bit definition in some drafts.
> 
> Actually, we did not expand the discussion of this part in this draft. 
The description of this part is very concise.
> 
> If you insist this, I can update the draft in recent days, together with 
other comments on this draft.
> 
> Other comments are welcome also!
> 
> Aijun Wang
> China Telecom
> 
>> On Oct 16, 2020, at 13:51, Les Ginsberg (ginsberg)  
wrote:
>> 
>> Aijun -
>> 
>> The point I am making is very focused.
>> 
>> This draft is defining a protocol extension. As such it is necessary 
that this be Standards track as adhering to the normative statements in the 
draft are necessary for interoperability.
>> 
>> What is discussed in the Appendix is a use case. It is not normative and 
there are strong opinions on both sides as to whether this is an appropriate 
use case or not.
>> In the context of this draft, I have no interest in trying to resolve 
our difference of opinion on this use case. I simply want the protocol 
extension to move forward so that we have another tool available.
>> 
>> If you want to write a draft on the use case discussed in the Appendix 
please feel free to do so. That draft may very well not be normative - 
Informational or BCP may be more appropriate - because it will be discussing a 
deployment scenario and a proposal to use defined protocol extensions as one 
way to solve problems in that deployment scenario. Such a draft might also be 
more appropriate in another WG (e.g., TEAS). The merits of using prefix 
advertisements to build a topology could then be discussed on its own.
>> 
>> Please do not try to avoid having a full discussion of the merits of 
using prefix advertisements to derive topology by adding it to a draft that is 
(and should be) focused on simple protocol extensions.
>> 
>> Thanx.
>> 
>>  Les
>> 
>> 
>>> -Original Message-
>>> From: Aijun Wang 
>>> Sent: Thursday, October 15, 2020 6:51 PM
>>> To: 'Jeff Tantsura' ; 'John E Drake'
>>> 
>>> Cc: 'Christian Hopps' ; lsr-cha...@ietf.org; Les 
Ginsberg
>>> (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
draft-ietf-
>>> lsr-ospf-prefix-origina...@ietf.org
>>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>>> 
>>> Hi, Les, John and Jeff:
>>> 
>>> Let's reply you all together.
>>> In my POV, The standard document should not define solely the protocol
>>> extension, but their usages in the network deployment. As I known, 
almost
>>> all the IETF documents following this style.
>>> And, before adopting one work, we have often intense discussion for 
what's
>>> their usages.
>>> Such discussion in the mail list and statements in the doc
> 


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

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Peter Psenak]

Bruno,

On 19/10/2020 18:52, bruno.decra...@orange.com wrote:

Ron, all,


From a use case standpoint, I have a use case for having both SR-MPLS and IP 
flexalgo in the same network.



From a protocol standpoint, I think that the functionality could be equally met 
by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit null) 
to instruct the LER/LSR to not use a label in the forwarding plane. (while 
still advertising a label in the control plane because we have to).


does not work, as it does not allow you to associate the prefix with
Flex-algo without advertising the reachability in algo 0. Making the 
prefix reachability in default algo conditional based on the presence of 
the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack.


Not to mention that advertising a Prefix SID in pure IP network would be 
ugly.


thanks,
Peter




I feel that this would be less change in the protocol (no new tlv), a good fit for 
network requiring both MPLS and IP flex algo, and would not require 
implementations/network operator to duplicate the "prefix sub-TLV" [1] on both 
advertisements (IP based and SR-MPLS based).

That would still requires a protocol extension/STD track RFC as RFC 8667 does 
not allow for this. That would still require change to implementations as only 
the signalling is different while the feature/behavior is the same (i.e. no 
magic).

Regards,
--Bruno

[1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. 
Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"



-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: Tuesday, September 29, 2020 3:38 PM
To: lsr@ietf.org
Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-
00.txt


Please review and comment

Ron



Juniper Business Use Only


-Original Message-
From: internet-dra...@ietf.org 
Sent: Tuesday, September 29, 2020 9:36 AM
To: Parag Kaneriya ; Shraddha Hegde
; Ron Bonica ; Rajesh M
; William Britto A J 
Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]


A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
has been successfully submitted by Ron Bonica and posted to the IETF
repository.

Name:   draft-bonica-lsr-ip-flexalgo
Revision:   00
Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
Document date:  2020-09-29
Group:  Individual Submission
Pages:  14
URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft-

bonica-

lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
Status:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-

bonica-lsr-

ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
Htmlized:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
Htmlized:

https://urldefense.com/v3/__https://tools.ietf.org/html/draft-

bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$


Abstract:
An IGP Flexible Algorithm computes a constraint-based path and maps
that path to an identifier.  As currently defined, Flexalgo can only
map the paths that it computes to Segment Routing (SR) identifiers.
Therefore, Flexalgo cannot be deployed in the absence of SR.

This document extends Flexalgo, so that it can map the paths that it
computes to IP addresses.  This allows Flexalgo to be deployed in any
IP network, even in the absence of SR.




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

submission

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

The IETF Secretariat


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


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not

[Lsr] IS: draft-ietf-bier-bar-ipa review / WAS: Re: The Document Shepherd Write-Uo

[Greg Shepherd]

LSR-WG

The following draft has completed WGLC in BIER and the Shepherd doc is
published. Can you please review before we move to the queue?

https://datatracker.ietf.org/doc/draft-ietf-bier-bar-ipa/

Thanks,
The BIER WG
(Shep/Chairs)

On Thu, Sep 24, 2020 at 2:24 PM Greg Mirsky  wrote:

> Dear All,
> the first version of the Document Shepherd's Write-Up is ready for your
> review. Please let me know if you have any questions or comments.
>
> Regards,
> Greg
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] IETF 109 LSR Presentation Slot Requests

[Yingzhen Qu]

Hi all,



We're now accepting agenda requests for the LSR Working Grouping meeting
IETF 109. Please send your requests to lsr-cha...@ietf.org indicating draft
name, speaker, and desired duration (covering presentation and discussion).



LSR session is scheduled on Monday, Nov 16, 12:00-14:00 ICT.



Thanks,

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Baalajee S (basurend)]

Hello authors,



I have a couple of comments.



1.
   A received Prefix Originator Sub-TLV that has an invalid length (not
   4 or 16) or a Reachable Address containing an invalid IPv4 or IPv6
   address (dependent on address family of the associated prefix) MUST
   be considered invalid and ignored.  Additionally, reception of such
   Sub-TLV SHOULD be logged as an error (subject to rate-limiting).


Shouldn’t that be “Router address”?


2.
   If the originating node is advertising an OSPFv2 Router Address TLV
   [RFC3630] or an OSPFv3 Router IPv6 
Address TLV [RFC5329], then that
   value is set in the Router Address field of the Prefix Originator
   Sub-TLV.  When the orignating node is not advertising such an



Wang, et al. Expires January 1, 2021[Page 5]


Internet-Draft  OSPF Prefix Originator Extensions  June 2020


   address, implementations MAY support mechanisms to determine a
   reachable address belonging to the originating node to set in the
   Router Address field.  Such mechanisms are outside the scope of this
   document.


Originating -> originating



I assume that the “Router address” picked by a router could be one of the 
addresses advertised by it with “N-bit” (Node SID) set or some other reachable 
address which uniquely identifies the router.



Regards,

S. Baalajee



On 15/10/20, 11:46 AM, "Lsr on behalf of Christian Hopps" 
 wrote:



This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:



  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/



The following IPR has been filed https://datatracker.ietf.org/ipr/3448/



Authors,



  Please indicate to the list, your knowledge of any other IPR related to 
this work.



Thanks,

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