Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Ketan Talaulikar (ketant)]

I support the WG adoption of this document. It covers an important piece of the 
FlexAlgorith solution space.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 02 December 2020 02:43
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Aijun Wang]

Hello Parag:

 

From: Parag Kaneriya  
Sent: Thursday, December 3, 2020 2:08 PM
To: Aijun Wang ; 'Acee Lindem (acee)'
; 'lsr' 
Subject: RE: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

Hello Aijun,

 

Every router by default support algo 0.  When router support IP-FLEX algo
along with default algo, we need to be deterministic when there is conflict
of prefix advertise in both algo. This conflict might be due to mis config.
So when such condition arise, prefix belong to default algo should give
priority to be install in forwarding table. 

[WAJ] Why not prefer to the prefixes belong to the IP-FLEX?

And, let's consider its relation with BGP Prefixes. When the sub-topology
within the IP-FLEX is broken, because you don't support (BGP nexthop)
automatic fallback to the default algo,  traffic to these prefixes  that
advertised by the BGP will also be broken?

Is there any mechanism to support the automatic fallback from IP-FLEX to
default algo?   

 

Regards

Parag

 

Juniper Business Use Only

From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of
Aijun Wang
Sent: Thursday, December 3, 2020 7:02 AM
To: 'Acee Lindem (acee)' mailto:acee=40cisco@dmarc.ietf.org> >; 'lsr' mailto:lsr@ietf.org> >
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

[External Email. Be cautious of content]

 

Hi, authors:

 

Want to confirm one thing:

Does the mechanism described in this draft support the automatic fallback
from "flex algorithm" to the "traditional least-cost algorithm"?  

That is to say, can one prefix exists both in the "flex algorithm" table and
"traditional least-cost algorithm" table, the router prefer to forwarding
the packet based on the former table, and if not hit, then lookup the latter
table?

 

>From the context of the document, the answer seems not, or even on the
contrary?

In cases where a prefix advertisement is received in both a IPv4

   Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability

   TLV, the IPv4 Prefix Reachability advertisement MUST be preferred

   when installing entries in the forwarding plane.

 

If so, what the value to deploy such flexible algorithm within the network?
>From my POV, the reason that we want to deploy such mechanism is that we
want to differentiate the path(result of flex algorithm) of some traffic
from that(result of traditional least-cost algorithm) of most other normal
traffic.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org 
mailto:lsr-boun...@ietf.org> > On Behalf Of Acee
Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr mailto:lsr@ietf.org> >
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

This IP Flex Algorithm draft generated quite a bit of discussion on use
cases and deployment prior to IETF 109 and there was generally support for
WG adoption. This begins a two week WG adoption call. Please indicate your
support or objection to WG adoption on this list prior to 12:00 AM UTC on
December 16th, 2020. Also, review comments are certainly welcome.

Thanks,

Acee

 

 

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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Parag Kaneriya]

Hello Aijun,

Every router by default support algo 0.  When router support IP-FLEX algo along 
with default algo, we need to be deterministic when there is conflict of prefix 
advertise in both algo. This conflict might be due to mis config. So when such 
condition arise, prefix belong to default algo should give priority to be 
install in forwarding table.

Regards
Parag


Juniper Business Use Only
From: Lsr  On Behalf Of Aijun Wang
Sent: Thursday, December 3, 2020 7:02 AM
To: 'Acee Lindem (acee)' ; 'lsr' 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[External Email. Be cautious of content]

Hi, authors:

Want to confirm one thing:
Does the mechanism described in this draft support the automatic fallback from 
"flex algorithm" to the "traditional least-cost algorithm"?
That is to say, can one prefix exists both in the "flex algorithm" table and 
"traditional least-cost algorithm" table, the router prefer to forwarding the 
packet based on the former table, and if not hit, then lookup the latter table?

>From the context of the document, the answer seems not, or even on the 
>contrary?
In cases where a prefix advertisement is received in both a IPv4
   Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
   TLV, the IPv4 Prefix Reachability advertisement MUST be preferred
   when installing entries in the forwarding plane.

If so, what the value to deploy such flexible algorithm within the network? 
From my POV, the reason that we want to deploy such mechanism is that we want 
to differentiate the path(result of flex algorithm) of some traffic from 
that(result of traditional least-cost algorithm) of most other normal traffic.

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Gyan Mishra]

I support WG adoption.  This is a much needed traffic engineering
capability independent of MPLS.

Thanks

Gyan

On Wed, Dec 2, 2020 at 8:32 PM Aijun Wang  wrote:

> Hi, authors:
>
>
>
> Want to confirm one thing:
>
> Does the mechanism described in this draft support the automatic fallback
> from “flex algorithm” to the “traditional least-cost algorithm”?
>
> That is to say, can one prefix exists both in the “flex algorithm” table
> and “traditional least-cost algorithm” table, the router prefer to
> forwarding the packet based on the former table, and if not hit, then
> lookup the latter table?
>
>
>
> From the context of the document, the answer seems not, or even on the
> contrary?
>
> In cases where a prefix advertisement is received in both a IPv4
>
>Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
>
>TLV, the IPv4 Prefix Reachability advertisement MUST be preferred
>
>when installing entries in the forwarding plane.
>
>
>
> If so, what the value to deploy such flexible algorithm within the
> network? From my POV, the reason that we want to deploy such mechanism is
> that we want to differentiate the path(result of flex algorithm) of some
> traffic from that(result of traditional least-cost algorithm) of most other
> normal traffic.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org  *On Behalf Of *Acee
> Lindem (acee)
> *Sent:* Wednesday, December 2, 2020 5:13 AM
> *To:* lsr 
> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>
>
>
> This IP Flex Algorithm draft generated quite a bit of discussion on use
> cases and deployment prior to IETF 109 and there was generally support for
> WG adoption. This begins a two week WG adoption call. Please indicate your
> support or objection to WG adoption on this list prior to 12:00 AM UTC on
> December 16th, 2020. Also, review comments are certainly welcome.
>
> Thanks,
>
> Acee
>
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Aijun Wang]

Hi, authors:

 

Want to confirm one thing:

Does the mechanism described in this draft support the automatic fallback from 
“flex algorithm” to the “traditional least-cost algorithm”?  

That is to say, can one prefix exists both in the “flex algorithm” table and 
“traditional least-cost algorithm” table, the router prefer to forwarding the 
packet based on the former table, and if not hit, then lookup the latter table?

 

>From the context of the document, the answer seems not, or even on the 
>contrary?

In cases where a prefix advertisement is received in both a IPv4

   Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability

   TLV, the IPv4 Prefix Reachability advertisement MUST be preferred

   when installing entries in the forwarding plane.

 

If so, what the value to deploy such flexible algorithm within the network? 
From my POV, the reason that we want to deploy such mechanism is that we want 
to differentiate the path(result of flex algorithm) of some traffic from 
that(result of traditional least-cost algorithm) of most other normal traffic.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

 

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.

Thanks,

Acee

 

 

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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Yingzhen Qu]

I have read the draft and support its adoption.

Thanks,
Yingzhen

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Wednesday, December 2, 2020 at 9:49 AM
To: "Acee Lindem (acee)" , lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Resent-From: 
Resent-Date: Wednesday, December 2, 2020 at 9:49 AM

Speaking as WG member:

I have read this draft and support adoption.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, December 1, 2020 at 4:13 PM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee

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

[Lsr] IPR Disclosure Juniper Networks, Inc.'s Statement about IPR related to draft-bonica-lsr-ip-flexalgo

[IETF Secretariat]

Dear William Britto, Shraddha Hegde, Parag Kaneriya, Rejesh Shetty, Ron Bonica, 
Peter Psenak:


An IPR disclosure that pertains to your Internet-Draft entitled "IGP Flexible
Algorithms (Flex-Algorithm) In IP Networks" (draft-bonica-lsr-ip-flexalgo)
was submitted to the IETF Secretariat on 2020-12-02 and has been posted on
the "IETF Page of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/4519/). The title of the IPR disclosure is
"Juniper Networks, Inc.'s Statement about IPR related to
draft-bonica-lsr-ip-flexalgo"


Thank you

IETF Secretariat


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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Tarek Saad]

I read this draft and I support its adoption.

Regards,
Tarek


> On Dec 1, 2020, at 1:12 PM, Acee Lindem (acee) 
> 
>  wrote:

>

> This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
> and deployment prior to IETF 109 and there was generally support for WG 
> adoption. This begins a two week WG adoption call. Please indicate your 
> support or objection to WG adoption on this list prior to 12:00 AM UTC on 
> December 16th, 2020. Also, review comments are certainly welcome.

> Thanks,

> Acee





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

[Lsr] IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Tarek Saad]

I am aware of an IPR that applies to this. Its disclosure is being worked on -- 
in conformance with IETF rules.

Regards,
Tarek

Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Tuesday, December 1, 2020 4:21 PM
To: 
draft-bonica-lsr-ip-flexa...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" 
- draft-bonica-lsr-ip-flexalgo-01

Authors,

Are you aware of any IPR that applies to draft-bonica-lsr-ip-flexalgo-01?

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



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

Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt

[Les Ginsberg (ginsberg)]

Shraddha -

Thanx for the responses.

Please see inline.

From: Shraddha Hegde 
Sent: Wednesday, December 02, 2020 9:30 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: RE: New Version Notification for draft-white-lsr-distoptflood-00.txt

Hi Les,

Thanks for the review and comments.
Pls see inline for replies.



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Monday, November 30, 2020 11:44 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; 
lsr@ietf.org
Subject: RE: New Version Notification for draft-white-lsr-distoptflood-00.txt

[External Email. Be cautious of content]


Draft authors -



I note that as the draft has evolved over the years a number of mechanisms have 
been removed (revised adjacency formation and auto tier detection) and the 
draft now focuses exclusively on flooding optimizations.

The draft now also references the recent work done in 
draft-ietf-lsr-dynamic-flooding.



A couple of things are not clear to me.



1)Is it your intent to use the mechanisms defined in 
draft-ietf-lsr-dynamic-flooding? I am specifically - though not exclusively - 
referring to how flooding adapts to topology changes.

It isn't clear from Section 3 whether you are actually intending to use the 
mechanisms defined in 
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07#section-6.8
 or whether you simply want to use the Flooding sub-TLV defined in 
draft-ietf-lsr-dynamic-flooding to (optionally??) advertise your algorithm and 
all other procedures are specific to your algorithm.

 We want to use the " IS-IS Dynamic Flooding Sub-TLV" defined in sec 
5.1.2 of the lsr-dynamic-flooding draft just to flood the information
that nodes support the algorithm specified in draft-white-lsr-distoptflood. I 
agree it's not writen very well. I'll update that section in next version.





2)The text at the end of 
https://tools.ietf.org/html/draft-white-lsr-distoptflood-00#section-2.1
 states:



" LSPs transmitted to adjacent

   neighbors on the DNR list, however, MUST be transmitted using a

   circuit scope PDU as described in [RFC7356]."



Although this text is not new to this revision, it raises a number of 
questions/concerns - some of which relate to how this draft fits with 
draft-ietf-lsr-dynamic-flooding.



For "DNR neighbors", although a circuit scoped LSP was received, the actual 
content is a traditional area scoped LSP.

 yes.

This presumably needs to be used internally (e.g., when running the Decision 
Process) in the same way as an area scoped LSP.

 yes.

So there are now two internal databases (traditional area LSPs and Circuit 
Scoped LSPs) which have to be used as if they are a single database?

 Yes that is correct

When a node sends a traditional CSNP does it include the LSPs it received as 
Circuit-Scoped LSPs?

If not, how is resynchronization achieved when necessary?

 yes. CSNPs includes circuit scoped LSPs.

Since you raised this point, I am thinking that we need a protocol extension to 
indicate that "this circuit scoped LSP" should be treated

In this special way.



Given the base work defined in draft-ietf-lsr-dynamic-flooding why is the use 
of Circuit Scoped LSPs required/useful?

 I am not sure which base work you are suggesting to use. Could you 
pls provide details?

The flooding algorithm as written in the draft breaks if circuit scoped 
flooding is not done.

Because, the distributed algorithm does not flood the LSP back in the direction 
from where it was originated.



[Les:] If you use the mechanisms defined in draft-ietf-lsr-dynamic-flooding 
there would be no need to use Circuit Scoped Flooding to send normal area 
scoped LSPs.

Each node in the topology would know to which neighbors it should have flooding 
enabled - either because you operate in centralized mode and the Area Leader 
distributes the flooding topology or because you operate in distributed mode 
and all nodes employ the same algorithm. (The latter assumes the algorithm 
supports deterministic choices for each node.) And when topology changes occur 
the mechanisms defined in 
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07#section-6.8
 assure that flooding continues to be reliable during the transition period 
(i.e., until a new flooding topology is calculated).



The fact that you apparently do NOT want to use the extensions defined in the 

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Acee Lindem (acee)]

Speaking as WG member:

I have read this draft and support adoption.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, December 1, 2020 at 4:13 PM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee

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

Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt

[Shraddha Hegde]

Hi Les,

Thanks for the review and comments.
Pls see inline for replies.



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Monday, November 30, 2020 11:44 AM
To: Shraddha Hegde ; lsr@ietf.org
Subject: RE: New Version Notification for draft-white-lsr-distoptflood-00.txt

[External Email. Be cautious of content]


Draft authors -



I note that as the draft has evolved over the years a number of mechanisms have 
been removed (revised adjacency formation and auto tier detection) and the 
draft now focuses exclusively on flooding optimizations.

The draft now also references the recent work done in 
draft-ietf-lsr-dynamic-flooding.



A couple of things are not clear to me.



1)Is it your intent to use the mechanisms defined in 
draft-ietf-lsr-dynamic-flooding? I am specifically - though not exclusively - 
referring to how flooding adapts to topology changes.

It isn't clear from Section 3 whether you are actually intending to use the 
mechanisms defined in 
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07#section-6.8
 or whether you simply want to use the Flooding sub-TLV defined in 
draft-ietf-lsr-dynamic-flooding to (optionally??) advertise your algorithm and 
all other procedures are specific to your algorithm.

 We want to use the " IS-IS Dynamic Flooding Sub-TLV" defined in sec 
5.1.2 of the lsr-dynamic-flooding draft just to flood the information
that nodes support the algorithm specified in draft-white-lsr-distoptflood. I 
agree it's not writen very well. I'll update that section in next version.





2)The text at the end of 
https://tools.ietf.org/html/draft-white-lsr-distoptflood-00#section-2.1
 states:



" LSPs transmitted to adjacent

   neighbors on the DNR list, however, MUST be transmitted using a

   circuit scope PDU as described in [RFC7356]."



Although this text is not new to this revision, it raises a number of 
questions/concerns - some of which relate to how this draft fits with 
draft-ietf-lsr-dynamic-flooding.



For "DNR neighbors", although a circuit scoped LSP was received, the actual 
content is a traditional area scoped LSP.

 yes.

This presumably needs to be used internally (e.g., when running the Decision 
Process) in the same way as an area scoped LSP.

 yes.

So there are now two internal databases (traditional area LSPs and Circuit 
Scoped LSPs) which have to be used as if they are a single database?

 Yes that is correct

When a node sends a traditional CSNP does it include the LSPs it received as 
Circuit-Scoped LSPs?

If not, how is resynchronization achieved when necessary?

 yes. CSNPs includes circuit scoped LSPs.

Since you raised this point, I am thinking that we need a protocol extension to 
indicate that "this circuit scoped LSP" should be treated

In this special way.



Given the base work defined in draft-ietf-lsr-dynamic-flooding why is the use 
of Circuit Scoped LSPs required/useful?

 I am not sure which base work you are suggesting to use. Could you 
pls provide details?

The flooding algorithm as written in the draft breaks if circuit scoped 
flooding is not done.

Because, the distributed algorithm does not flood the LSP back in the direction 
from where it was originated.



In general, it would be helpful to more completely define the relationship 
between this draft and draft-ietf-lsr-dynamic-flooding.

 yes. I'll produce next version soon.



Thanx.



   Les





> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Shraddha Hegde

> Sent: Sunday, November 29, 2020 8:36 PM

> To: lsr@ietf.org

> Subject: [Lsr] FW: New Version Notification for draft-white-lsr-distoptflood-

> 00.txt

>

> WG members,

>

>

> We have posted new version of the draft-white-lsr-distoptflood.

> This draft has been around for sometime by name openfabric and

> draft-white-distoptflood. The current revision has the name changed

> to reflect LSR WG.

> This draft describes a flood reduction mechanism in ISIS which is based on

> similar mechanisms implemented in OSPF for mobile-ad-hoc Networks

> ([RFC5449], [RFC5614], and [RFC7182]).

>

> Request working group to review and provide inputs.

>

> Rgds

> Shraddha

>

>

> Juniper Business Use Only

>

> -Original Message-

> From: internet-dra...@ietf.org 
> mailto:internet-dra...@ietf.org>>

> Sent: Monday, November 30, 2020 9:59 AM

> To: Shraddha Hegde mailto:shrad...@juniper.net>>; Russ 
> White mailto:r...@riw.us>>;

> Shawn Zandi mailto:sza...@linkedin.com>>

> Subject: New Version Notification for 

Re: [Lsr] IRP Poll for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01 (Resent with Corrected Subject)

[Christian Hopps]

I am not aware of any IPR that applies to 
draft-ietf-lsr-yang-isis-reverse-metric-01. This draft defines a YANG model for 
the base work defined in RFC8500 which does have an IPR disclosure.

Thanks,
Chris.

> On Dec 1, 2020, at 4:20 PM, Acee Lindem (acee)  wrote:
> 
> Chris, 
>  
> Are you aware of any IPR that applies to 
> draft-ietf-lsr-yang-isis-reverse-metric-01?
>  
> 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

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

Re: [Lsr] IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[William Britto A J]

Hi Acee,

I am not aware of any IPR, other than the one disclosed by Juniper.

Regards,
William


From: Acee Lindem (acee) 
Date: Wednesday, 2 December 2020 at 2:51 AM
To: draft-bonica-lsr-ip-flexa...@ietf.org 

Cc: lsr@ietf.org 
Subject: IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" 
- draft-bonica-lsr-ip-flexalgo-01
[External Email. Be cautious of content]

Authors,

Are you aware of any IPR that applies to draft-bonica-lsr-ip-flexalgo-01?

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




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

Re: [Lsr] IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Peter Psenak]

Hi Acee,

I am not aware of any undisclosed IPRs related to this draft.

thanks,
Peter

On 01/12/2020 22:21, Acee Lindem (acee) wrote:

Authors,

Are you aware of any IPR that applies to draft-bonica-lsr-ip-flexalgo-01?

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



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