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

[Peter Psenak]

Robert,


On 13/10/2020 13:38, Robert Raszuk wrote:

Peter,

If this is per app how are the constraints shared across apps ?


FAD constraints are only used for calculating the flex-algo path.



See we have single physical resources (for example links) and single 
interface outbound queues. If I use per app flex-algo and do not have 
central controller how is this going to work in practice for any network 
which attempts to use more then one forwarding schema with dynamic 
constraints ?


flex-algo defines the way to calculate constraint based paths in a 
distributed manner and guarantees the loop free forwarding over such path.


Possible per app and/or per algo resource allocation at each hop is not 
something that flex-algo spec attempts to solve. That does not mean it 
is not possible. I don't see anything in the flex-algo spec that would 
prevent one to do that.


thanks,
Peter



Many thx,
R.



On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak 
mailto:40cisco@dmarc.ietf.org>> 
wrote:


Hi Jimmy,

On 13/10/2020 10:02, Dongjie (Jimmy) wrote:
 > Hi Peter,
 >
 > Thanks for your reply. Please see further inline:
 >
 >> -Original Message-
 >> From: Lsr [mailto:lsr-boun...@ietf.org
] On Behalf Of Peter Psenak
 >> Sent: Monday, October 12, 2020 4:39 PM
 >> To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Ron Bonica
 >> mailto:rbon...@juniper.net>>; Yingzhen Qu
mailto:yingzhen...@futurewei.com>>; Gyan
 >> Mishra mailto:hayabusa...@gmail.com>>
 >> Cc: lsr@ietf.org ; Jeff Tantsura
mailto:jefftant.i...@gmail.com>>
 >> Subject: Re: [Lsr] FW: New Version Notification for
 >> draft-bonica-lsr-ip-flexalgo-00.txt
 >>
 >> Hi Jimmy,
 >>
 >> On 10/10/2020 05:05, Dongjie (Jimmy) wrote:
 >>> Hi Peter,
 >>>
 >>> Thanks for your reply. It aligns with my understanding of FAD,
which is just a
 >> set of constraints for path computation. Thus one Flex-Algo ID
could be used
 >> with multiple different data planes. Is this understanding correct?
 >>
 >> correct.
 >>
 >>>
 >>> If so, my question is about the scenario below:
 >>>
 >>> A group of nodes in a network support FA-128, a sub-group of
them bind
 >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP
address.
 >>
 >> just to use the correct terminology, we should use "participate"
instead of
 >> "support".
 >
 > Agree.
 >
 >>
 >>> When one node compute an SR path to a destination, can it
compute the path
 >> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the
 >> nodes >which bind FA-128 to IP address? If so, how could this
node know the
 >> binding of FA to different data planes on other nodes?
 >>
 >> again, it is the participation problem.
 >>
 >> Nodes that participate in the SR Flex-algo 128 will advertise
the participation
 >> using the SR-Algorithm Sub-TLV. Only these nodes will be used
during the SR
 >> flex-algo computation for algo 128.
 >>
 >> Nodes that participate in IP flex-algo 128 will advertise the
participation using
 >> the IGP Algorithm Sub-TLV. Only these nodes will be used during
the IP flex-algo
 >> computation for algo 128.
 >
 > Agree that if participation to Flex-Algo is advertised in a data
plane specific manner, then path computation with Flex-Algo
constraints could be done only using nodes which bind the Flex-Algo
to the same data plane.

it's per app, not per data plane, but yes, that is what the base
flex-algo spec mandates.

 >
 > As Robert asked and you confirmed, this implies each data plane
needs to be treated as an independent application of Flex-Algo. We
have SR-Algorithm sub-TLV and IP Algorithm sub-TLV, while there are
actually more data planes to be considered: SR-MPLS, SRv6, IPv4,
IPv6, etc., does this mean that Flex-Algo participation needs to be
advertised for SR-MPLS, SRv6, IPv4, IPv6, etc. separately?

yes, it needs to be advertised per app. We have SR specific algo
participation, we need one for IP as proposed in Ron's draft.

Regarding IPv4 vs IPv6, it's up to the authors whether they want to
make
the participation for IP flex-algo topology specific or topology
independent, both could work.

Here's the text from the base flerx-algo draft:

10.2.  Advertisement of Node Participation for Other Applications

     This section describes considerations related to how other
     applications can advertise their participation in a specific Flex-
     Algorithm.

     Application-specific Flex-Algorithm participation
advertisements MAY
     be topology specific or MAY be topology independent, depending
on the
     application itself.

     Application-specific ad

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

[Robert Raszuk]

Peter,

If this is per app how are the constraints shared across apps ?

See we have single physical resources (for example links) and single
interface outbound queues. If I use per app flex-algo and do not have
central controller how is this going to work in practice for any network
which attempts to use more then one forwarding schema with dynamic
constraints ?

Many thx,
R.



On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak  wrote:

> Hi Jimmy,
>
> On 13/10/2020 10:02, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > Thanks for your reply. Please see further inline:
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Monday, October 12, 2020 4:39 PM
> >> To: Dongjie (Jimmy) ; Ron Bonica
> >> ; Yingzhen Qu ; Gyan
> >> Mishra 
> >> Cc: lsr@ietf.org; Jeff Tantsura 
> >> Subject: Re: [Lsr] FW: New Version Notification for
> >> draft-bonica-lsr-ip-flexalgo-00.txt
> >>
> >> Hi Jimmy,
> >>
> >> On 10/10/2020 05:05, Dongjie (Jimmy) wrote:
> >>> Hi Peter,
> >>>
> >>> Thanks for your reply. It aligns with my understanding of FAD, which
> is just a
> >> set of constraints for path computation. Thus one Flex-Algo ID could be
> used
> >> with multiple different data planes. Is this understanding correct?
> >>
> >> correct.
> >>
> >>>
> >>> If so, my question is about the scenario below:
> >>>
> >>> A group of nodes in a network support FA-128, a sub-group of them bind
> >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address.
> >>
> >> just to use the correct terminology, we should use "participate"
> instead of
> >> "support".
> >
> > Agree.
> >
> >>
> >>> When one node compute an SR path to a destination, can it compute the
> path
> >> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the
> >> nodes >which bind FA-128 to IP address? If so, how could this node know
> the
> >> binding of FA to different data planes on other nodes?
> >>
> >> again, it is the participation problem.
> >>
> >> Nodes that participate in the SR Flex-algo 128 will advertise the
> participation
> >> using the SR-Algorithm Sub-TLV. Only these nodes will be used during
> the SR
> >> flex-algo computation for algo 128.
> >>
> >> Nodes that participate in IP flex-algo 128 will advertise the
> participation using
> >> the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP
> flex-algo
> >> computation for algo 128.
> >
> > Agree that if participation to Flex-Algo is advertised in a data plane
> specific manner, then path computation with Flex-Algo constraints could be
> done only using nodes which bind the Flex-Algo to the same data plane.
>
> it's per app, not per data plane, but yes, that is what the base
> flex-algo spec mandates.
>
> >
> > As Robert asked and you confirmed, this implies each data plane needs to
> be treated as an independent application of Flex-Algo. We have SR-Algorithm
> sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes
> to be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that
> Flex-Algo participation needs to be advertised for SR-MPLS, SRv6, IPv4,
> IPv6, etc. separately?
>
> yes, it needs to be advertised per app. We have SR specific algo
> participation, we need one for IP as proposed in Ron's draft.
>
> Regarding IPv4 vs IPv6, it's up to the authors whether they want to make
> the participation for IP flex-algo topology specific or topology
> independent, both could work.
>
> Here's the text from the base flerx-algo draft:
>
> 10.2.  Advertisement of Node Participation for Other Applications
>
> This section describes considerations related to how other
> applications can advertise their participation in a specific Flex-
> Algorithm.
>
> Application-specific Flex-Algorithm participation advertisements MAY
> be topology specific or MAY be topology independent, depending on the
> application itself.
>
> Application-specific advertisement for Flex-Algorithm participation
> MUST be defined for each application and is outside of the scope of
> this document.
>
> thanks,
> Peter
>
>
> >
> > Best regards,
> > Jie
> >
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Best regards,
> >>> Jie
> >>>
>  -Original Message-
>  From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>  Sent: Friday, October 9, 2020 11:58 PM
>  To: Dongjie (Jimmy) ; Ron Bonica
>  ; Yingzhen Qu
>  ; Gyan Mishra 
>  Cc: lsr@ietf.org; Jeff Tantsura 
>  Subject: Re: [Lsr] FW: New Version Notification for
>  draft-bonica-lsr-ip-flexalgo-00.txt
> 
>  Hi Jimmy,
> 
> 
>  On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> > Hi Ron,
> >
> > Thanks for explaining the difference between IP Flex-Algo and SR
> > Flex-algo. As
>  you said, the major difference is the data plane.
> >
> > If my understanding is correct, for one Flex-Algo to be used
> > correctly, the set
>  of nodes n

Re: [Lsr] I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt

[tom petch]

From: Tony Li  on behalf of tony...@tony.li 

Sent: 15 September 2020 22:17

Our apologies.  We’re on it.


Thank you, -04 is much easier to digest although perhaps not easy:-(

I think that the I-D needs to decide what to do with OpenConfig which appears a 
lot in one module and makes it hard to read.  If this is going to be an IETF 
module, then I think that it all has to go, perhaps via an appendix while the 
I-D is under development.

The lack of text makes it hard to know what is intended.  I reverse engineer 
the YANG to find out what it is meant to do and lo and behold the YANG does 
just that.  I think that the base OSPF YANG module gets it just right with its 
mix of text and tree diagram, so I can see what it is trying to do, see at a 
high level and then go to the detail of the YANG.  Several other routing area 
I-D are similar although by no means all.

Also the lack of references, or the minimal descriptions, or both make it hard 
to follow. so algorithm is uint8, connection type is uint8, what is an ID in 
number of IDs?, index is uint16, priority is uint8 but what is high what low? 
and so on.  I should not need to know lsr-dynamic-flooding off by heart in 
order to make sense of this.

And
- Security Considerations is plain wrong; go read YANG Guidelines:-)
- IANA Considerations ditto
-  is used as a placeholder for two different I-D
-  ietf-ospf-dynflood would be consistent and less error prone IMHO
- RFC6991, RFC8349 need to be Normative references
- Introduction should reference OSPFv3
- objects and identities relating to TLV need references - they are ever harder 
to find in the IETF literature
- ospf should be capitalised, LEEF probably not
- several abbreviations need expanding on first use perhaps in a terminology 
section; usually there is one such for YANG terminology
- I wonder if ospf-dynamic-flooding would be a better feature name given there 
are the two of them side-by-side

Tom Petch



Tony


> On Sep 15, 2020, at 9:04 AM, Acee Lindem (acee) 
>  wrote:
>
> It looks like some unfortunate tab settings at least for the OSPF model...  
> Note that pyang can be used for formatting.
>
> pyang -f yang  --yang-line-length 68
>
> On 9/15/20, 11:47 AM, "Lsr on behalf of tom petch"  behalf of ie...@btconnect.com> wrote:
>
>The formatting of this I-D seems to have gone wrong making it hard to read 
> and review.  The indentation of successive lines of the YANG module is more 
> than it usually is.  This was a problem with -01 that was not present in -02 
> but has now returned in -03
>
>Tom Petch
>
>From: I-D-Announce  on behalf of 
> internet-dra...@ietf.org 
>Sent: 14 September 2020 22:15
>To: i-d-annou...@ietf.org
>Subject: I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
>Title   : YANG Data Model for Dynamic Flooding
>Authors : Srinath Dontula
>  Tony Li
>Filename: draft-dontula-lsr-yang-dynamic-flooding-03.txt
>Pages   : 26
>Date: 2020-09-14
>
>Abstract:
>   This document defins YANG data models that can be used to configure
>   and manage Dynamic Flooding for IS-IS and OSPF.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-dontula-lsr-yang-dynamic-flooding/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-dontula-lsr-yang-dynamic-flooding-03
>
> https://datatracker.ietf.org/doc/html/draft-dontula-lsr-yang-dynamic-flooding-03
>
>A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=draft-dontula-lsr-yang-dynamic-flooding-03
>
>
>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.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>___
>I-D-Announce mailing list
>i-d-annou...@ietf.org
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>___
>Lsr mailing list
>Lsr@ietf.org
>https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

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

[Peter Psenak]

Hi Jimmy,

On 13/10/2020 10:02, Dongjie (Jimmy) wrote:

Hi Peter,

Thanks for your reply. Please see further inline:


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Monday, October 12, 2020 4:39 PM
To: Dongjie (Jimmy) ; Ron Bonica
; Yingzhen Qu ; Gyan
Mishra 
Cc: lsr@ietf.org; Jeff Tantsura 
Subject: Re: [Lsr] FW: New Version Notification for
draft-bonica-lsr-ip-flexalgo-00.txt

Hi Jimmy,

On 10/10/2020 05:05, Dongjie (Jimmy) wrote:

Hi Peter,

Thanks for your reply. It aligns with my understanding of FAD, which is just a

set of constraints for path computation. Thus one Flex-Algo ID could be used
with multiple different data planes. Is this understanding correct?

correct.



If so, my question is about the scenario below:

A group of nodes in a network support FA-128, a sub-group of them bind

FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address.

just to use the correct terminology, we should use "participate" instead of
"support".


Agree.




When one node compute an SR path to a destination, can it compute the path

to only pass the nodes which bind FA-128 to SR SIDs, and avoid the
nodes >which bind FA-128 to IP address? If so, how could this node know the
binding of FA to different data planes on other nodes?

again, it is the participation problem.

Nodes that participate in the SR Flex-algo 128 will advertise the participation
using the SR-Algorithm Sub-TLV. Only these nodes will be used during the SR
flex-algo computation for algo 128.

Nodes that participate in IP flex-algo 128 will advertise the participation 
using
the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP flex-algo
computation for algo 128.


Agree that if participation to Flex-Algo is advertised in a data plane specific 
manner, then path computation with Flex-Algo constraints could be done only 
using nodes which bind the Flex-Algo to the same data plane.


it's per app, not per data plane, but yes, that is what the base 
flex-algo spec mandates.




As Robert asked and you confirmed, this implies each data plane needs to be 
treated as an independent application of Flex-Algo. We have SR-Algorithm 
sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes to 
be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that Flex-Algo 
participation needs to be advertised for SR-MPLS, SRv6, IPv4, IPv6, etc. 
separately?


yes, it needs to be advertised per app. We have SR specific algo 
participation, we need one for IP as proposed in Ron's draft.


Regarding IPv4 vs IPv6, it's up to the authors whether they want to make 
the participation for IP flex-algo topology specific or topology 
independent, both could work.


Here's the text from the base flerx-algo draft:

10.2.  Advertisement of Node Participation for Other Applications

   This section describes considerations related to how other
   applications can advertise their participation in a specific Flex-
   Algorithm.

   Application-specific Flex-Algorithm participation advertisements MAY
   be topology specific or MAY be topology independent, depending on the
   application itself.

   Application-specific advertisement for Flex-Algorithm participation
   MUST be defined for each application and is outside of the scope of
   this document.

thanks,
Peter




Best regards,
Jie



thanks,
Peter



Best regards,
Jie


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Friday, October 9, 2020 11:58 PM
To: Dongjie (Jimmy) ; Ron Bonica
; Yingzhen Qu
; Gyan Mishra 
Cc: lsr@ietf.org; Jeff Tantsura 
Subject: Re: [Lsr] FW: New Version Notification for
draft-bonica-lsr-ip-flexalgo-00.txt

Hi Jimmy,


On 09/10/2020 04:59, Dongjie (Jimmy) wrote:

Hi Ron,

Thanks for explaining the difference between IP Flex-Algo and SR
Flex-algo. As

you said, the major difference is the data plane.


If my understanding is correct, for one Flex-Algo to be used
correctly, the set

of nodes need to apply consistent constraints in computation, and
bind the FAD to the same data plane.


Is it possible that different nodes may use the same Flex-Algo with
different

data plane, e.g. some with SR-MPLS, some with SRv6, and some with
pure IP etc., or each Flex-Algo is always associated with only one
data plane? In the former case, should the flex-algo definition also
indicate the data plane(s) to be used with the flex-algo?

let me respond to this query, as this is not specific to Ron's draft.

FAD is data plane agnostic and is used by all of them.

thanks,
Peter



Best regards,
Jie


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: Sunday, October 4, 2020 4:34 AM
To: Yingzhen Qu ; Peter Psenak
; Gyan Mishra 
Cc: lsr@ietf.org; Jeff Tantsura 
Subject: Re: [Lsr] FW: New Version Notification for
draft-bonica-lsr-ip-flexalgo-00.txt

Hi Yingzhen,

IP Flexible Algorithms are like SR Flexible Algorithms in t

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

[Aijun Wang]

Hi, Dhruv:

-Original Message-
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Dhruv 
Dhody
Sent: Tuesday, October 13, 2020 1:48 PM
To: Aijun Wang 
Cc: lsr@ietf.org; Peter Psenak (ppsenak) ; Aijun Wang 
; Gyan Mishra ; Acee Lindem 
(acee) 
Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt

Hi Aijun,

I am not particularly sold on the argument that the configuration requirements 
of RFC 5316/RFC 5392 are especially burdensome.

A PCE relies on the TEDB which comprises nodes & links, and it makes sense to 
have an inter-AS link represented as a "Link". Moreover, these links are 
TE-enabled and thus carry the TE properties of the link. You cannot avoid using 
this mechanism if Inter-AS Link's TE-properties need to be advertised.
[WAJ] Yes. For deploying the inter-as TE based on RFC5316/RFC539, we must 
configure the properties parameters on every inter-AS link manually. Interface 
address/Remote Router ID/Remote AS are just part of these configuration. 

That is why I consider your proposal to be more applicable for non-TE use cases 
perhaps(?)!
[WAJ] To be exact, the proposal is more applicable for non-MPLS TE use case. 
But it can also relieve the configuration overhead for MPLS TE use case.

Thanks!
Dhruv

On Tue, Oct 13, 2020 at 8:03 AM Aijun Wang  wrote:
>
> Hi, Dhruv:
>
> Please see my explain to Jeff. 
> https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/
>
> The solutions described in RFC 5316 and RFC 5392 are possible and 
> straightforward, but they have some constraints, especially for the 
> operation/configuration of the network.
>
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
> -Original Message-
> From: dhruv.i...@gmail.com [mailto:dhruv.i...@gmail.com]
> Sent: Monday, October 12, 2020 3:25 PM
> To: Gyan Mishra 
> Cc: Acee Lindem (acee) ; 
> lsr@ietf.org; Aijun Wang ; Aijun Wang 
> ; Peter Psenak (ppsenak) 
> 
> Subject: Re: [Lsr] FW: New Version Notification for 
> draft-wang-lsr-passive-interface-attribute-04.txt
>
> Hi Gyan,
>
> As far as PCE is concerned, we have the inter-AS link information via RFC 
> 5316 and RFC 5392. Both of these include a section on PCE's BRPC procedure 
> for instance.
>
> I see you have other use cases, but it would be good to highlight why for the 
> PCE use case the above is deficient.
>
> Thanks!
> Dhruv
>
>
> On Mon, Oct 12, 2020 at 12:49 AM Gyan Mishra  wrote:
> >
> >
> > Hi Acee
> >
> > I believe what Aijun is trying to explain is that the primary purpose of 
> > PCE for active or passive path computation is for inter-as RSVP-TE PCALC 
> > path computation or SR-TE path computation.  So PCE is solving a well known 
> > PCALC bin packing problem due to pcalc over subscribing RSVP tunnel 
> > bandwidth which is inherent an RSVP issue, but a bigger problematic issue 
> > is with being able to build an inter-as TE path with a single or multiple 
> > PCE controllers that can take the LSDB link attributes in the TEDs dB 
> > opaque LSAs in the ospf case and ISIS TE TLVs and rebuild the topology 
> > topology from each TE domain to be able to build a congruent end to end 
> > RSVP TE or SR-TE traffic steered path instantiation.
> >
> > Without the use of PCE controllers as the LSDB link attribute information 
> > is not known as RSVP loose ERO static lsp is built or SR SR-TE prefix sid 
> > loose path is built, failover due to crank back is impacted for reroute, 
> > due to not having a complete depiction of the other AS Link state topology 
> > by the head end or SR source node.
> >
> > So to build that entire end to end inter-as path for that end to end RSVP 
> > TE or SR-TE path instantiation it is critical to indentify the inter-as 
> > link eBGP tie link that may have static routes or BGP LU for RSVP head end 
> > to tail end reachability and SR-TE reachability to build out the end to end 
> > path instantiation.  So the BGP-LS task to  rebuild the lsdb topology of 
> > each inter connected AS that the RSVP TE or SR-TE steered path traverses, 
> > we need the accurate depiction and that includes the Identification of the  
> > critical inter-as tie link eBGP peering link that is passive for the PCE 
> > path computation logic for the end to end inter-as path instantiation.
> >
> > As for other interfaces using passive in the context of a operator service 
> > provider or enterprise core P and PE routers all links are transit with 
> > neighbors except the inter-as tie so having this new IGP TLV will help to 
> > that end.  In the operator “core” network if there are other  interfaces 
> > that don’t need to be advertised as stub, they can easily be excluded from 
> > being added into IGP.
> >
> > Kind Regards
> >
> > Gyan
> >
> > On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) 
> >  wrote:
> >>
> >> Hi Aijun,
> >>
> >>
> >>
> >> From: Aijun Wang 
> >> Date: Friday, October 9, 2020 at 9:58 PM
> >> To: Acee Lindem , "Peter Psenak (ppsenak)"
> >> , 

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

[Dongjie (Jimmy)]

Hi Peter, 

Thanks for your reply. Please see further inline:

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Monday, October 12, 2020 4:39 PM
> To: Dongjie (Jimmy) ; Ron Bonica
> ; Yingzhen Qu ; Gyan
> Mishra 
> Cc: lsr@ietf.org; Jeff Tantsura 
> Subject: Re: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> Hi Jimmy,
> 
> On 10/10/2020 05:05, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > Thanks for your reply. It aligns with my understanding of FAD, which is 
> > just a
> set of constraints for path computation. Thus one Flex-Algo ID could be used
> with multiple different data planes. Is this understanding correct?
> 
> correct.
> 
> >
> > If so, my question is about the scenario below:
> >
> > A group of nodes in a network support FA-128, a sub-group of them bind
> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address.
> 
> just to use the correct terminology, we should use "participate" instead of
> "support".

Agree.

> 
> >When one node compute an SR path to a destination, can it compute the path
> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the
> nodes >which bind FA-128 to IP address? If so, how could this node know the
> binding of FA to different data planes on other nodes?
> 
> again, it is the participation problem.
> 
> Nodes that participate in the SR Flex-algo 128 will advertise the 
> participation
> using the SR-Algorithm Sub-TLV. Only these nodes will be used during the SR
> flex-algo computation for algo 128.
> 
> Nodes that participate in IP flex-algo 128 will advertise the participation 
> using
> the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP 
> flex-algo
> computation for algo 128.

Agree that if participation to Flex-Algo is advertised in a data plane specific 
manner, then path computation with Flex-Algo constraints could be done only 
using nodes which bind the Flex-Algo to the same data plane. 

As Robert asked and you confirmed, this implies each data plane needs to be 
treated as an independent application of Flex-Algo. We have SR-Algorithm 
sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes to 
be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that Flex-Algo 
participation needs to be advertised for SR-MPLS, SRv6, IPv4, IPv6, etc. 
separately?

Best regards,
Jie

> 
> thanks,
> Peter
> 
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Friday, October 9, 2020 11:58 PM
> >> To: Dongjie (Jimmy) ; Ron Bonica
> >> ; Yingzhen Qu
> >> ; Gyan Mishra 
> >> Cc: lsr@ietf.org; Jeff Tantsura 
> >> Subject: Re: [Lsr] FW: New Version Notification for
> >> draft-bonica-lsr-ip-flexalgo-00.txt
> >>
> >> Hi Jimmy,
> >>
> >>
> >>On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> >>> Hi Ron,
> >>>
> >>> Thanks for explaining the difference between IP Flex-Algo and SR
> >>> Flex-algo. As
> >> you said, the major difference is the data plane.
> >>>
> >>> If my understanding is correct, for one Flex-Algo to be used
> >>> correctly, the set
> >> of nodes need to apply consistent constraints in computation, and
> >> bind the FAD to the same data plane.
> >>>
> >>> Is it possible that different nodes may use the same Flex-Algo with
> >>> different
> >> data plane, e.g. some with SR-MPLS, some with SRv6, and some with
> >> pure IP etc., or each Flex-Algo is always associated with only one
> >> data plane? In the former case, should the flex-algo definition also
> >> indicate the data plane(s) to be used with the flex-algo?
> >>
> >> let me respond to this query, as this is not specific to Ron's draft.
> >>
> >> FAD is data plane agnostic and is used by all of them.
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Best regards,
> >>> Jie
> >>>
>  -Original Message-
>  From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
>  Sent: Sunday, October 4, 2020 4:34 AM
>  To: Yingzhen Qu ; Peter Psenak
>  ; Gyan Mishra 
>  Cc: lsr@ietf.org; Jeff Tantsura 
>  Subject: Re: [Lsr] FW: New Version Notification for
>  draft-bonica-lsr-ip-flexalgo-00.txt
> 
>  Hi Yingzhen,
> 
>  IP Flexible Algorithms are like SR Flexible Algorithms in the
>  following
> >> respects:
> 
>  - Links have IGP metrics, TE metrics, delay metrics and
>  administrative colors
>  - FADs define Flexible Algorithms
> 
>  More specifically, the FAD:
> 
>  - Indicates which metric type the Flexible Algorithm uses
>  - Specifies constraints in terms of link colors that are included
>  or excluded from the Flexible Algorithm.
> 
>  The significant difference between IP Flexible Algorithms and SR
>  Flexible Algorithms is:
> 
>  - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators
>  - IP Flexible Algorithms bind FADs to IPv4 or