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

[Ketan Talaulikar]

Hi Acee,

I am not aware of any IPR for this document other than the one already
reported.

Thanks,
Ketan


On Fri, 29 Jul, 2022, 10:48 pm Acee Lindem (acee),  wrote:

> Co-authors,
>
>
>
> Are you aware of any IPR that applies to
> draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?
>
>
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
>
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as a document author or contributor please respond
>
> to this email regardless of whether or not you are aware of any
>
> relevant IPR. *The response needs to be sent to the LSR WG mailing
>
> list.* The document will not advance to the next stage until a
>
> response has been received from each author and contributor.
>
>
>
> If you are on the LSR WG email list but are not listed as an author or
>
> contributor, then please explicitly respond only if you are aware of
>
> any IPR that has not yet been disclosed in conformance with IETF rules.
>
>
>
> Thanks,
>
> Acee & Chris
>
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments on draft-white-lsr-distoptflood-03

[Antoni Przygienda]

No Announce: thanks, we agree

Well, given LSP flooding is unrelible as well it seems no better and no worse 
if we RTX. The PSNP bits will be hanging there and I guess we have to put it on 
a RTX mechanism or we rely on CSNP. Good comment.

Yes, the PSNPs are _in addition_ so yes, I agree also here we can fall back on 
those. I kind of prefer those since it doesn’t change protocol behavior further 
than it already does by sending the additional PSNP

Thanks


  *   Tony

From: Les Ginsberg (ginsberg) 
Date: Friday, 29 July 2022 at 15:08
To: Antoni Przygienda , lsr@ietf.org 
Subject: Comments on draft-white-lsr-distoptflood-03
[External Email. Be cautious of content]


Tony (and everyone) -

Following up on the brief discussion about this draft at today's WG meeting...

I withdraw the comment regarding having to announce use of the algorithm. After 
rereading I agree this is not necessary.

Regarding my second comment about the use of PSNPs as a recovery mechanism in 
cases where topology changes temporarily compromise the optimized 
flooding...the draft says in Section 2.3


o  Set a short timer; the default should be one second

   o  When the timer expires, send Partial Sequence Number Packet (PSNP)
  of all LSPs that have not been reflooded during the timer runtime
  to all neighbors unless an up-to-date PSNP or CSNP has been
  already received from the neighbor


Given that PSNPs are unreliable, how can you guarantee that the neighbor has 
received the PSNP(s) required by the most recent set of LSP updates which were 
NOT flooded to that neighbor?

The traditional way of closing this gap is to send periodic CSNPs on interfaces 
where flooding may have been suppressed. In this way you guarantee the 
reliability of the update process.
The recovery time may be a bit slower as sending CSNPs every second is 
excessive - but I do not see how you guarantee reliability without periodic 
transmissions.

Or do you mean to say send the PSNP once IN ADDITION to periodic CSNPs?? This 
would allow quicker recovery in most cases while using a slower periodic timer 
for the CSNPs as protection in case the PSNP was lost.

   Les


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

[Huzhibo]

Hi Peter:
Supplement to yesterday's online questions, If a node that does not support IP 
Flexalgo, which has a default route, should the node process the IP Flexalgo 
prefix as a UPA?


Thanks

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

[Lsr] Comments on draft-white-lsr-distoptflood-03

[Les Ginsberg (ginsberg)]

Tony (and everyone) -

Following up on the brief discussion about this draft at today's WG meeting...

I withdraw the comment regarding having to announce use of the algorithm. After 
rereading I agree this is not necessary.

Regarding my second comment about the use of PSNPs as a recovery mechanism in 
cases where topology changes temporarily compromise the optimized 
flooding...the draft says in Section 2.3


o  Set a short timer; the default should be one second

   o  When the timer expires, send Partial Sequence Number Packet (PSNP)
  of all LSPs that have not been reflooded during the timer runtime
  to all neighbors unless an up-to-date PSNP or CSNP has been
  already received from the neighbor


Given that PSNPs are unreliable, how can you guarantee that the neighbor has 
received the PSNP(s) required by the most recent set of LSP updates which were 
NOT flooded to that neighbor?

The traditional way of closing this gap is to send periodic CSNPs on interfaces 
where flooding may have been suppressed. In this way you guarantee the 
reliability of the update process.
The recovery time may be a bit slower as sending CSNPs every second is 
excessive - but I do not see how you guarantee reliability without periodic 
transmissions.

Or do you mean to say send the PSNP once IN ADDITION to periodic CSNPs?? This 
would allow quicker recovery in most cases while using a slower periodic timer 
for the CSNPs as protection in case the PSNP was lost.

   Les

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

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

[Acee Lindem (acee)]

Co-authors,

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

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

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

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

Thanks,
Acee & Chris


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

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

[Acee Lindem (acee)]

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

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


Thanks,
Acee & Chris


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

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

[Acee Lindem (acee)]

Co-authors,

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

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

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

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

Thanks,
Acee & Chris


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

[Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

[Acee Lindem (acee)]

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

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


Thanks,
Acee & Chris


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

Re: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo

[Les Ginsberg (ginsberg)]

I fully agree with Shraddha.

In fact Section 4 of the draft makes clear why no protocol extensions are 
needed.

   Les

From: Lsr  On Behalf Of Shraddha Hegde
Sent: Friday, July 29, 2022 2:18 AM
To: lsr@ietf.org
Subject: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo

Authors,


I suggest that the usecase can be satisfied using the backward compatible
Maximum link metric mechanism defined in the draft.
I don't see any need to define protocol extensions,
that are backward incompatible and can cause serious issues in the network
in the presence of older implementations.

Rgds
Shraddha


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Peter Psenak]

On 29/07/2022 08:35, Aijun Wang wrote:

Hi, Peter:
I think you and all the subscribers of the LSR mail list have noticed not only 
Zhibo express the opinions that LSInfinity cannot be used to indicate the 
prefix is unreachable. There should exist other explicit indication.
Should we stop arguing this point then?


I have not seen any technical evidence why LSInfinity is not sufficient. 
Repeating same invalid arguments over and over will not make them valid.


Peter



Aijun Wang
China Telecom


On Jul 29, 2022, at 19:19, Peter Psenak  wrote:

Zhibo,


On 28/07/2022 22:07, Huzhibo wrote:
Peter

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Friday, July 29, 2022 8:33 AM
To: Aijun Wang ; Acee Lindem (acee)

Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg)
;
draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr 
Subject: Re: [Lsr] Comments on
draft-wang-lsr-prefix-unreachable-annoucement

Aijun,

On 28/07/2022 19:55, Aijun Wang wrote:

Hi, Acee:

Thanks for your comments, but most of them are indefensible,
especially the conclusion.
As you have also noticed, UPA mechanism doesn’t consider the network
partition scenarios, doesn’t consider how to control the number of
advertisement of unreachable messages, doesn’t provide the explicit
notification of unreachable statement(as also pointed out Ketan, Bruno
etc.), then how you hurry to get the conclusion that UPA is superior to PUA?


IETF documents are not deployment guides, nor design or implementation
documents, not the source of education for the other vendors.

IETF documents are there to specify the bare minimum to achieve
interoperability.

In other words, the fact that you put more content in your document, does not
make it any better. Contrary, the less you need to do to achieve the
interoperability, the better it is.

[HZB] More content you mentioned of the documents are addresses comments on the 
promotion of this document.
It is an essential part of a complete solution.
RFC 5305 define that LSInfinity metric is used for other purposes other than
building the normal routing table. UPA uses LSInfinity metric only to identify 
unreachable prefixes, which is contrary to RFC 5305.


no, it is in perfect compliance with RFC 5305.


[draft-ietf-lsr-ip-flexalgo] also uses LSInfinity metric. It may also be 
applied to other purposes.


which is orthogonal to our discussion here, because if the valid metric exists 
in IP Algorithm Prefix Reachability Sub-TLV, the metric in parent TLV is 
ignored. There is no problem here.


Therefore, using LSInfinity metric alone is not enough.


that's what you claim, bit that is not necessary true.

Peter



In conclusion, the PUA solution is more complete and the unreachable prefix is 
defined in a more reasonable manner.
Zhibo Hu

Peter




We have yet mentioned that PUA mechanism has been discussed two years
before the UPA solution.

More responses are inline. Anyway, I am glad that your comments have
some bases, although you misunderstood something.

Aijun Wang
China Telecom


On Jul 29, 2022, at 02:04, Acee Lindem (acee)  wrote:

Speaking as WG Member:

Hi Ketan,

Thanks for pointing out the similarities. Even after the recent
changes,  there are still some difference between the drafts which
I’ll describe in the baseless comments which follow. For conciseness,
I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak).

  1. Backward Compatibility – Now that PUA has appropriated the metric
 mechanisms from UPA, it is also backward compatible. However, PUA
 still proposes extensions the IGPs to advertise the PUA
 capabilities and says the nodes may misbehave if they don’t agree
 on these capabilities. I guess removing these was omitted when the
 UPA metric mechanisms were appropriated.


WAJ] No. the context in the document just describes why and when the
LSInfinity is necessary. The usages of LSInfinity in two drafts are
different: one(PUA) is to avoid the misbehavior(which is conform to
the RFC rules), another(UPA) is to indicate the unreachable
information(which is not described in the RFC rules)


1.
  2. Receive Router Behavior – For UPA, the unreachable prefix
 notification is solely for an event signal to be used by other
 routers in the IGP domain to trigger actions, e.g., BGP PIC
 excluding the unreachable prefix.  PUA is used for the switchover
 of services as well but is also used to modify persistent state.
 In section 4, the PUA advertisement will trigger the advertisement
 of the prefix by an ABR that does have a route to the unreachable
 prefix advertised by another ABR.

[WAJ] Is this one evidence that PUA covers UPA?


2.
  3. Advertisement Persistence – PUA is advertised like any other LSA
 and presumably advertised as long as the prefix is unreachable.
 Conversely, UPA is an ephemeral LSA that will be withdrawn after
 enough time is allowed for the event notification to 

Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Aijun Wang]

Hi, Peter:
I think you and all the subscribers of the LSR mail list have noticed not only 
Zhibo express the opinions that LSInfinity cannot be used to indicate the 
prefix is unreachable. There should exist other explicit indication.
Should we stop arguing this point then?

Aijun Wang
China Telecom

> On Jul 29, 2022, at 19:19, Peter Psenak  wrote:
> 
> Zhibo,
> 
>> On 28/07/2022 22:07, Huzhibo wrote:
>> Peter
>>> -Original Message-
>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>>> Sent: Friday, July 29, 2022 8:33 AM
>>> To: Aijun Wang ; Acee Lindem (acee)
>>> 
>>> Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg)
>>> ;
>>> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr 
>>> Subject: Re: [Lsr] Comments on
>>> draft-wang-lsr-prefix-unreachable-annoucement
>>> 
>>> Aijun,
>>> 
>>> On 28/07/2022 19:55, Aijun Wang wrote:
 Hi, Acee:
 
 Thanks for your comments, but most of them are indefensible,
 especially the conclusion.
 As you have also noticed, UPA mechanism doesn’t consider the network
 partition scenarios, doesn’t consider how to control the number of
 advertisement of unreachable messages, doesn’t provide the explicit
 notification of unreachable statement(as also pointed out Ketan, Bruno
 etc.), then how you hurry to get the conclusion that UPA is superior to 
 PUA?
>>> 
>>> IETF documents are not deployment guides, nor design or implementation
>>> documents, not the source of education for the other vendors.
>>> 
>>> IETF documents are there to specify the bare minimum to achieve
>>> interoperability.
>>> 
>>> In other words, the fact that you put more content in your document, does 
>>> not
>>> make it any better. Contrary, the less you need to do to achieve the
>>> interoperability, the better it is.
>> [HZB] More content you mentioned of the documents are addresses comments on 
>> the promotion of this document.
>> It is an essential part of a complete solution.
>> RFC 5305 define that LSInfinity metric is used for other purposes other than
>> building the normal routing table. UPA uses LSInfinity metric only to 
>> identify unreachable prefixes, which is contrary to RFC 5305.
> 
> no, it is in perfect compliance with RFC 5305.
> 
>> [draft-ietf-lsr-ip-flexalgo] also uses LSInfinity metric. It may also be 
>> applied to other purposes.
> 
> which is orthogonal to our discussion here, because if the valid metric 
> exists in IP Algorithm Prefix Reachability Sub-TLV, the metric in parent TLV 
> is ignored. There is no problem here.
> 
>> Therefore, using LSInfinity metric alone is not enough.
> 
> that's what you claim, bit that is not necessary true.
> 
> Peter
> 
> 
>> In conclusion, the PUA solution is more complete and the unreachable prefix 
>> is defined in a more reasonable manner.
>> Zhibo Hu
>>> Peter
>>> 
>>> 
 
 We have yet mentioned that PUA mechanism has been discussed two years
 before the UPA solution.
 
 More responses are inline. Anyway, I am glad that your comments have
 some bases, although you misunderstood something.
 
 Aijun Wang
 China Telecom
 
> On Jul 29, 2022, at 02:04, Acee Lindem (acee)  wrote:
> 
> Speaking as WG Member:
> 
> Hi Ketan,
> 
> Thanks for pointing out the similarities. Even after the recent
> changes,  there are still some difference between the drafts which
> I’ll describe in the baseless comments which follow. For conciseness,
> I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak).
> 
>  1. Backward Compatibility – Now that PUA has appropriated the metric
> mechanisms from UPA, it is also backward compatible. However, PUA
> still proposes extensions the IGPs to advertise the PUA
> capabilities and says the nodes may misbehave if they don’t agree
> on these capabilities. I guess removing these was omitted when the
> UPA metric mechanisms were appropriated.
 
 WAJ] No. the context in the document just describes why and when the
 LSInfinity is necessary. The usages of LSInfinity in two drafts are
 different: one(PUA) is to avoid the misbehavior(which is conform to
 the RFC rules), another(UPA) is to indicate the unreachable
 information(which is not described in the RFC rules)
 
> 1.
>  2. Receive Router Behavior – For UPA, the unreachable prefix
> notification is solely for an event signal to be used by other
> routers in the IGP domain to trigger actions, e.g., BGP PIC
> excluding the unreachable prefix.  PUA is used for the switchover
> of services as well but is also used to modify persistent state.
> In section 4, the PUA advertisement will trigger the advertisement
> of the prefix by an ABR that does have a route to the unreachable
> prefix advertised by another ABR.
 [WAJ] Is this one evidence that PUA covers UPA?
> 
> 2.

Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Peter Psenak]

Zhibo,

On 28/07/2022 22:07, Huzhibo wrote:

Peter


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Friday, July 29, 2022 8:33 AM
To: Aijun Wang ; Acee Lindem (acee)

Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg)
;
draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr 
Subject: Re: [Lsr] Comments on
draft-wang-lsr-prefix-unreachable-annoucement

Aijun,

On 28/07/2022 19:55, Aijun Wang wrote:

Hi, Acee:

Thanks for your comments, but most of them are indefensible,
especially the conclusion.
As you have also noticed, UPA mechanism doesn’t consider the network
partition scenarios, doesn’t consider how to control the number of
advertisement of unreachable messages, doesn’t provide the explicit
notification of unreachable statement(as also pointed out Ketan, Bruno
etc.), then how you hurry to get the conclusion that UPA is superior to PUA?


IETF documents are not deployment guides, nor design or implementation
documents, not the source of education for the other vendors.

IETF documents are there to specify the bare minimum to achieve
interoperability.

In other words, the fact that you put more content in your document, does not
make it any better. Contrary, the less you need to do to achieve the
interoperability, the better it is.


[HZB] More content you mentioned of the documents are addresses comments on the 
promotion of this document.
It is an essential part of a complete solution.
RFC 5305 define that LSInfinity metric is used for other purposes other than
building the normal routing table. UPA uses LSInfinity metric only to identify 
unreachable prefixes, which is contrary to RFC 5305.


no, it is in perfect compliance with RFC 5305.


[draft-ietf-lsr-ip-flexalgo] also uses LSInfinity metric. It may also be 
applied to other purposes.


which is orthogonal to our discussion here, because if the valid metric 
exists in IP Algorithm Prefix Reachability Sub-TLV, the metric in parent 
TLV is ignored. There is no problem here.



Therefore, using LSInfinity metric alone is not enough.


that's what you claim, bit that is not necessary true.

Peter



In conclusion, the PUA solution is more complete and the unreachable prefix is 
defined in a more reasonable manner.

Zhibo Hu



Peter




We have yet mentioned that PUA mechanism has been discussed two years
before the UPA solution.

More responses are inline. Anyway, I am glad that your comments have
some bases, although you misunderstood something.

Aijun Wang
China Telecom


On Jul 29, 2022, at 02:04, Acee Lindem (acee)  wrote:

Speaking as WG Member:

Hi Ketan,

Thanks for pointing out the similarities. Even after the recent
changes,  there are still some difference between the drafts which
I’ll describe in the baseless comments which follow. For conciseness,
I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak).

  1. Backward Compatibility – Now that PUA has appropriated the metric
 mechanisms from UPA, it is also backward compatible. However, PUA
 still proposes extensions the IGPs to advertise the PUA
 capabilities and says the nodes may misbehave if they don’t agree
 on these capabilities. I guess removing these was omitted when the
 UPA metric mechanisms were appropriated.


WAJ] No. the context in the document just describes why and when the
LSInfinity is necessary. The usages of LSInfinity in two drafts are
different: one(PUA) is to avoid the misbehavior(which is conform to
the RFC rules), another(UPA) is to indicate the unreachable
information(which is not described in the RFC rules)


1.
  2. Receive Router Behavior – For UPA, the unreachable prefix
 notification is solely for an event signal to be used by other
 routers in the IGP domain to trigger actions, e.g., BGP PIC
 excluding the unreachable prefix.  PUA is used for the switchover
 of services as well but is also used to modify persistent state.
 In section 4, the PUA advertisement will trigger the advertisement
 of the prefix by an ABR that does have a route to the unreachable
 prefix advertised by another ABR.

[WAJ] Is this one evidence that PUA covers UPA?


2.
  3. Advertisement Persistence – PUA is advertised like any other LSA
 and presumably advertised as long as the prefix is unreachable.
 Conversely, UPA is an ephemeral LSA that will be withdrawn after
 enough time is allowed for the event notification to propagate.

[WAJ] No. if there is no network update again, the PUA will not be
advertised “as long as the prefix is unreachable “. Actually, there is
description in the document:

 “The advertisement of PUAM message should only last one

configurable

 period to allow the services that run on the failure prefixes are
 switchovered.  If one prefix is missed before the PUAM takes effect,
 the ABR will not declare its absence via the PUAM.”


I think you may ignore them.


3.

In my opinion, UPA is superior to PUA since it is 

Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

[Aijun Wang]

Hi, Robert:
I think your proposal are valid. 
Option C like deployment can also use such information to select the optimized 
inter-AS link to reach the routers in other domain. 
The final effect will be like the EPE scenario.

Aijun Wang
China Telecom

> On Jul 29, 2022, at 16:44, Robert Raszuk  wrote:
> 
> 
> Hi Aijun,
> 
> How does this proposal impacts BGP path selection ? 
> 
> Note that it is common to do next hop self on the ASBRs towards the 
> intradomain. So your proposal would not require any signalling to be 
> effective on a given ASBR. Local decision. 
> 
> Originally I was under impression that you want to enhance TE for option C 
> like deployments. But if not then I see not much point of doing it. 
> 
> Thx,
> R.
> 
>> On Fri, Jul 29, 2022 at 4:09 AM Aijun Wang  wrote:
>> Hi, Ketan:
>> 
>>  
>> 
>> In the inter-AS scenario, we will not deploy BGP session on each p2p link. 
>> The BGP session exists only within the loopback address of each ASBR pair.
>> 
>> Such deployment is also same in the LAN scenario. Then there is no mesh or 
>> partial p2p link that congruent to the BGP sessions.
>> 
>> But such LAN interfaces are sharing the same prefixes.
>> 
>>  
>> 
>> And regarding to your comments on Prefix sub-TLV: yes, if we redistribute 
>> such external prefixes into the IGP, then they will be transported within 
>> the associated “External Prefixes TLV”.
>> 
>> But for these stub links, if we configure them as “passive” only( no 
>> redistributed action), then the prefixes of these stub links will not exists 
>> within the IGP LSA.
>> 
>> Attach the prefixes information with these stub links can certainly fill 
>> such gap. There will be no redundancy information.
>> 
>>  
>> 
>> And, regarding to your comments: “… …- at least let us not go overboard and 
>> repeat the same info in multiple places. ”, this is also the main reason 
>> that we don’t want to use the RFC5316/RFC5392 mechanism to accomplish the 
>> goal for the inter-as topology recovery--there will be many redundancy 
>> information being flooded within the IGP area.
>> 
>>  
>> 
>>  
>> 
>> Best Regards
>> 
>>  
>> 
>> Aijun Wang
>> 
>> China Telecom
>> 
>>  
>> 
>>  
>> 
>> From: Ketan Talaulikar  
>> Sent: Thursday, July 28, 2022 4:54 PM
>> To: Aijun Wang 
>> Cc: Les Ginsberg (ginsberg) ; Acee 
>> Lindem (acee) ; lsr 
>> Subject: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes
>> 
>>  
>> 
>> Hi Aijun,
>> 
>>  
>> 
>> Please check inline below.
>> 
>>  
>> 
>> On Thu, Jul 28, 2022 at 1:15 PM Aijun Wang  wrote:
>> 
>> Hi, Ketan:
>> 
>>  
>> 
>> There are situation that such information is necessary: 
>> 
>> When several ASes are connected via the LAN interface, it is impossible to 
>> describe the inter-AS relationship with the current descriptors that 
>> provided by RFC5316 and RFC5392.
>> 
>>  
>> 
>> KT> Note that we have BGP running on these Inter-AS links. Even when there 
>> is an underlying LAN, the BGP sessions are p-t-p and maybe a full or partial 
>> mesh. Therefore, I believe representing such a LAN as a mesh of p-t-p links 
>> that are congruent to the BGP sessions is the right approach. I am happy to 
>> be corrected. In any case, I still fail to see how a prefix associated with 
>> the links helps here.
>> 
>>  
>> 
>>  
>> 
>> And another scenario is that when these stub links are used to correct 
>> servers, there is no remote-AS, remote ASBR ID information. But we can 
>> distinguish different stub link via their associated prefixes.
>> 
>>  
>> 
>> KT> I disagree - such stub links can be identified by their local interface 
>> ids along with their local IP address. Note that we already have the 
>> corresponding prefix being advertised as prefix reachability. So I don't see 
>> the need to repeat. All of this is already overloading IGPs with info that 
>> is not used by IGPs - at least let us not go overboard and repeat the same 
>> info in multiple places. 
>> 
>>  
>> 
>> Please check the new fresh thread about use-cases.
>> 
>>  
>> 
>> Thanks,
>> 
>> Ketan
>> 
>>  
>> 
>>  
>> 
>> Aijun Wang
>> 
>> China Telecom
>> 
>> 
>> 
>> 
>> On Jul 28, 2022, at 15:03, Ketan Talaulikar  wrote:
>> 
>> 
>> 
>> Hi Aijun,
>> 
>>  
>> 
>> Similar to Les, I disagree with you on the use of Prefix TLV as an attribute 
>> of the "Stub Link". The reason is that this attribute is not required for 
>> the identification of a link in BGP-LS (or in IGPs for that matter) that was 
>> the main use case. I also don't see the use of that in Inter-AS links. 
>> Please justify this.
>> 
>>  
>> 
>> Thanks,
>> 
>> Ketan
>> 
>>  
>> 
>>  
>> 
>> On Thu, Jul 28, 2022 at 12:19 PM Aijun Wang  
>> wrote:
>> 
>> Hi, Les:
>> 
>>  
>> 
>> Please note the references to RFC5316/RFC5392 in 
>> draft-ietf-idr-bgpls-inter-as-topology-ext-11 is for TE scenarios, and what 
>> we are discussing are non-TE scenarios.
>> 
>> For prefixes sub-TLV, would you like to revisit my responses to Ketan, 
>> before make any comments? For your 

[Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo

[Shraddha Hegde]

Authors,


I suggest that the usecase can be satisfied using the backward compatible
Maximum link metric mechanism defined in the draft.
I don't see any need to define protocol extensions,
that are backward incompatible and can cause serious issues in the network
in the presence of older implementations.

Rgds
Shraddha


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

[Shraddha Hegde]

>It only mandates that this prefix not be used in SPF computation, and leave 
>the possibility of using it for other purposes,
>where "indicating the prefix is unreachable" could be one of the possible use 
>cases

I totally agree with that statement.
An indication of unreachability in the prefix-attribute flags in ISIS is useful.
In OSPF, we could use extended prefix opaque LSA to achieve it.

Rgds
Shraddha


Juniper Business Use Only
From: Lsr  On Behalf Of Dongjie (Jimmy)
Sent: Friday, July 29, 2022 10:24 AM
To: Ketan Talaulikar ; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
Cc: lsr 
Subject: Re: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

[External Email. Be cautious of content]

Hi authors, WG,

I also have some comments which aligns with Ketan's first and third points as 
below:

Firstly, both RFC 5305 and 5308 say that:

"If a prefix is advertised with a metric larger then MAX_PATH_METRIC (call it 
infinite metric), this prefix MUST NOT be considered during the normal SPF 
computation. This allows advertisement of a prefix for purposes other than 
building the normal IP routing table."

It only mandates that this prefix not be used in SPF computation, and leave the 
possibility of using it for other purposes, where "indicating the prefix is 
unreachable" could be one of the possible use cases.

According to these RFCs, a node which receives such a prefix with a metric 
larger than MAX_PATH_METRIC will not take it into consideration for SPF 
computation, but if there is another summary prefix which covers this one, this 
prefix will still be reachable based on the summary prefix.

To indicate this prefix is unreachable even if there is a summary prefix exist, 
additional behavior is required on the receiving node, and this needs to be 
indicated with some additional information in the prefix advertisement.

Secondly, section 2.1 of this document says

"...Such an advertisement can be interpreted by the receiver as a UPA."

And

 "Optionally, an implementation may use local configuration to limit the set of 
metric values which will be interpreted as UPA."

This shows that such an advertisement may be interpreted by the receiver as 
something else, and it is expected that not all of the metric values larger 
then MAX_PATH_METRIC will be interpreted as "prefix is unreachable".

To avoid possible mis-interpretation of the purpose of this prefix 
advertisement, and to save the effort of local configuration, a protocol 
mechanism is needed to carry the accurate indication of the purpose of this 
advertisement.

In summary,


1)   Treating such a prefix as unreachable is not the behavior defined in 
the existing RFCs, a standard track document would be needed for it.

2)   Additional information in the advertisement is needed to accurately 
reflect the purpose and the required behavior.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, July 28, 2022 2:27 PM
To: 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
Cc: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

Hello Authors,

Sharing some comments upfront on this draft given the packed LSR agenda.

1) There is currently no change in protocol encoding (see also further 
comment), however, there are protocol procedures at the ABR being specified 
using normative language. Specifically, the text related to the propagation of 
UPA across levels/areas/domains. Therefore, I believe that this draft should be 
moved to the standards track.

2) The document refers to "prefix reachability" in a generic sense. My 
understanding is that this refers to the "base" prefix reachability in the IGPs 
- i.e., Extended IP Reachability (TLV 135) and its MT & IPv6 siblings in ISIS, 
the OSPFv2 Type 3 LSA, and the OSPFv3 Inter-Area Prefix LSA (and its Extended 
LSA sibling). It would be good to specify these for clarity.

3) I also prefer (like some other WG members) that there is an explicit 
indication that is carried along with the UPAs. E.g., a UPA flag. This will 
help in more accurate monitoring and handling of these updates. It will also 
help differentiate the usual/existing max/infinite metric advertisements that 
may be triggered for other reasons from a UPA.

Thanks,
Ketan

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

Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

[Robert Raszuk]

Hi Aijun,

How does this proposal impacts BGP path selection ?

Note that it is common to do next hop self on the ASBRs towards the
intradomain. So your proposal would not require any signalling to be
effective on a given ASBR. Local decision.

Originally I was under impression that you want to enhance TE for option C
like deployments. But if not then I see not much point of doing it.

Thx,
R.

On Fri, Jul 29, 2022 at 4:09 AM Aijun Wang 
wrote:

> Hi, Ketan:
>
>
>
> In the inter-AS scenario, we will not deploy BGP session on each p2p link.
> The BGP session exists only within the loopback address of each ASBR pair.
>
> Such deployment is also same in the LAN scenario. Then there is no mesh or
> partial p2p link that congruent to the BGP sessions.
>
> But such LAN interfaces are sharing the same prefixes.
>
>
>
> And regarding to your comments on Prefix sub-TLV: yes, if we redistribute
> such external prefixes into the IGP, then they will be transported within
> the associated “External Prefixes TLV”.
>
> But for these stub links, if we configure them as “passive” only( no
> redistributed action), then the prefixes of these stub links will not
> exists within the IGP LSA.
>
> Attach the prefixes information with these stub links can certainly fill
> such gap. There will be no redundancy information.
>
>
>
> And, regarding to your comments: “… …- at least let us not go overboard
> and repeat the same info in multiple places. ”, this is also the main
> reason that we don’t want to use the RFC5316/RFC5392 mechanism to
> accomplish the goal for the inter-as topology recovery--there will be
> many redundancy information being flooded within the IGP area.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
> *From:* Ketan Talaulikar 
> *Sent:* Thursday, July 28, 2022 4:54 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Acee
> Lindem (acee) ; lsr 
> *Subject:* Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes
>
>
>
> Hi Aijun,
>
>
>
> Please check inline below.
>
>
>
> On Thu, Jul 28, 2022 at 1:15 PM Aijun Wang 
> wrote:
>
> Hi, Ketan:
>
>
>
> There are situation that such information is necessary:
>
> When several ASes are connected via the LAN interface, it is impossible to
> describe the inter-AS relationship with the current descriptors that
> provided by RFC5316 and RFC5392.
>
>
>
> KT> Note that we have BGP running on these Inter-AS links. Even when there
> is an underlying LAN, the BGP sessions are p-t-p and maybe a full or
> partial mesh. Therefore, I believe representing such a LAN as a mesh of
> p-t-p links that are congruent to the BGP sessions is the right approach. I
> am happy to be corrected. In any case, I still fail to see how a prefix
> associated with the links helps here.
>
>
>
>
>
> And another scenario is that when these stub links are used to correct
> servers, there is no remote-AS, remote ASBR ID information. But we can
> distinguish different stub link via their associated prefixes.
>
>
>
> KT> I disagree - such stub links can be identified by their local
> interface ids along with their local IP address. Note that we already have
> the corresponding prefix being advertised as prefix reachability. So I
> don't see the need to repeat. All of this is already overloading IGPs with
> info that is not used by IGPs - at least let us not go overboard and repeat
> the same info in multiple places.
>
>
>
> Please check the new fresh thread about use-cases.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Jul 28, 2022, at 15:03, Ketan Talaulikar  wrote:
>
> 
>
> Hi Aijun,
>
>
>
> Similar to Les, I disagree with you on the use of Prefix TLV as an
> attribute of the "Stub Link". The reason is that this attribute is not
> required for the identification of a link in BGP-LS (or in IGPs for that
> matter) that was the main use case. I also don't see the use of that in
> Inter-AS links. Please justify this.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Thu, Jul 28, 2022 at 12:19 PM Aijun Wang 
> wrote:
>
> Hi, Les:
>
>
>
> Please note the references to RFC5316/RFC5392 in
> draft-ietf-idr-bgpls-inter-as-topology-ext-11 is for TE scenarios, and
> what we are discussing are non-TE scenarios.
>
> For prefixes sub-TLV, would you like to revisit my responses to Ketan,
> before make any comments? For your convenience, I can elaborate again to
> you——-“The prefix sub-TLV is not the link identifier, it is just one kind
> of link attributes”. Is it clear enough?
>
>
>
> Based on these facts, I think it is unnecessary to response your other
> baseless comments.
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Jul 28, 2022, at 12:51, Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> 
>
> Acee –
>
>
>
> I have a somewhat different take on this draft.
>
>
>
> I agree with you that draft-ietf-idr-bgpls-inter-as-topology-ext-11 is
> relevant – but I disagree that the lsr-stub-link draft is needed at all.
>
> In fact one of the main points