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

[Peter Psenak <[e-mail]>]

Hi Gyan,

On 03/10/2020 18:54, Gyan Mishra wrote:
> 
> Thanks Peter for the responses to help clear up my flex algo understanding!!
> 
> On Sat, Oct 3, 2020 at 5:45 AM Peter Psenak <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Gyan,
> 
> 
> 
>     On 03/10/2020 02:14, Gyan Mishra wrote:
> 
>      >
> 
>      > Hi  Jeff
> 
>      >
> 
>      >  From a domain perspective where you have a group of nodes and
> 
>      > associated IP addressed and SID are part of a discrete underlay
>     instance
> 
>      > flex algo topology.  On those same set of nodes you could have
>     another
> 
>      > topology and associated address and SIDs for a different flex algo.
> 
> 
> 
>     above is right.
> 
> 
>     Gyan>  So per my response to Robert, what  I was thinking is that as 
> the algo 0 strict spf would be used as the base algo to provide 
> reachability to all nodes within the domain and all neighbors are formed 
> between all nodes in the domain to populate IGP rib providing base 
> connectivity reachability.  So then underneath of that you can have any 
> subset of nodes out of the superset all top layer domain nodes level 
>   that can run any other algo desired. Basically creating algo layers 
> under the top domain wide layer.

pretty much.


> 
> 
> 
> 
>      > How
> 
>      > this would work is that the topologies would have to be
>     segregated from
> 
>      > each other as different MT instances or routing process
>     instances.  Is
> 
>      > that correct?
> 
> 
> 
>     no MT at all. You can think of each flex-algo as a set of constraints
> 
>     that is used to calculate the path over the common topology. You can
> 
>     have many such felx-algos running on a common topology.
> 
> 
>      Gyan> Is it safe to say that we can think of it as RSVP TE “like” 
> cSPF constraints that we are build via traffic engineering PCALC 
> algorithms to run for dynamic LSP dyamic ERO that is built based on IGP 
> constraints from TEDs database of TE link attributes and TE or IGP 
> weights metric constraints to create the dynamic LSP path.  

you can think of a flex-algo as a TE like solution, but there are some 
major differences to RSVP-TE:

- automatic calculation of flex-algo constrained based paths from any 
source to any destination. This is in contrast to p2p nature of RSVP-TE.

- there is no TED, all information is stored in IGP LSDB.




> So we could 
> think of in TE framework analogy to flex algo In the per VRF TE next hop 
> vpn coloring use case with different loopback next hop rewrite per VRF 
> that normal IGP non TE BAU VPNs traffic would be like the flex algo base 
> strict algo 0 and the non zero discrete algo would be like the per VRF 
> next hop loopback rewrite where each per VRF te loopback rewrite would 
> be a different steering non zero discrete flex algo all running in 
> parallel as ships in the night with the base algo 0.   Sorry for the 
> complex analogy but I think I am getting it!!😃

steering the traffic to flex-algo paths can be done using different 
methods - per-destination, per flow, etc. Various coloring mechanism can 
be used as well, if needed.


> 
> Does a flex algo use case draft exist and if not I would not mind using 
> the analogy I said above and build out a use case draft.  Cheers! 😊


I'm not a fan of use case drafts. These should be vendor specific 
documents, no need to make them standards.

thanks,
Peter
> 
> 
> 
> 
>      >
> 
>      > Can two nodes that run two different flex algo become ospf or isis
> 
>      > neighbors?
> 
> 
> 
>     absolutely.
> 
> 
> 
>     Peter
> 
> 
> 
>      >
> 
>      > Kind Regards
> 
>      >
> 
>      > Gyan
> 
>      >
> 
>      > On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura
>     <[e-mail] <mailto:[e-mail]>
> 
>      > <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >     Hi Yingzhen,
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >     Yes, that’s the case.  The most important property of an algo
> 
>      >     computed path is that is has to be consecutive, as either SID
>     or IP
> 
>      >     address associated with a particular topology is only known
>     within
> 
>      >     that topology.
> 
>      >
> 
>      >
> 
>      >     Looking specifically at Ron’s draft (MPLS could be more
>     complex due
> 
>      >     to potential hierarchy) - the prefix itself defines the
> 
>      >     context(topology) and must be globally unique, since IPv4 header
> 
>      >     can’t have any additional meta-data attached.
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >     Cheers,
> 
>      >
> 
>      >     Jeff
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >     On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu
> 
>      >     <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>>>, wrote:
> 
>      >
> 
>      >
> 
>      >>     Hi Peter,
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     My understanding of flex-algo is that for traffic destined to a
> 
>      >>     prefix on a particular algo, it can only be routed on routers
> 
>      >>     belong to that algo, which also means only routers in that algo
> 
>      >>     calculates how to reach that prefix and install it into the
> 
>      >>     routing table. It seems to me that using flex-algo (section
>     12 of
> 
>      >>     the draft) it's possible to have a loopback address associated
> 
>      >>     with only one algo, please correct me if I'm missing or
> 
>      >>     misunderstood something.
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     Thanks,
> 
>      >>
> 
>      >>
> 
>      >>     Yingzhen
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak"
> 
>      >>     <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>> on behalf of
> 
>      >>     ppsenak=[e-mail]
>     <mailto:[e-mail]>
> 
>      >>     <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     Gyan,
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     On 02/10/2020 18:30, Gyan Mishra wrote:
> 
>      >>
> 
>      >>
> 
>      >>>     All,
> 
>      >>>
> 
>      >>>
> 
>      >>>
> 
>      >>>
> 
>      >>>
> 
>      >>>     With SRv6 and IP based flex algo a generic question as it
>     applies to
> 
>      >>>
> 
>      >>>
> 
>      >>>     both. Is it possible to have within a single IGP domain
>     different
> 
>      >>>     sets
> 
>      >>>
> 
>      >>>
> 
>      >>>     of nodes or segments of the network running different
>     algorithms.
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     absolutely.
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>>     From
> 
>      >>>
> 
>      >>>
> 
>      >>>     both drafts it sounds like all nodes have to agree on same
>     algorithm
> 
>      >>>
> 
>      >>>
> 
>      >>>     similar to concept of metric and reference bandwidth all
>     have to have
> 
>      >>>
> 
>      >>>
> 
>      >>>     the same style metric and play to the same sheet of music.
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     all participating nodes need to agree on the definition of the
> 
>      >>     flex-algo
> 
>      >>
> 
>      >>
> 
>      >>     and advertise the participation. That's it.
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>>     If there was
> 
>      >>>
> 
>      >>>
> 
>      >>>     a way to use multiple algorithms simultaneously based on SFC or
> 
>      >>>     services
> 
>      >>>
> 
>      >>>
> 
>      >>>     and instantiation of specific algorithm based on service to be
> 
>      >>>
> 
>      >>>
> 
>      >>>     rendered. Doing so without causing a routing loop or sub
>     optimal
> 
>      >>>
> 
>      >>>
> 
>      >>>     routing.
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     you can certainly use multiple algorithms simultaneously and
>     use algo
> 
>      >>
> 
>      >>
> 
>      >>     specific paths to forward specific traffic over it. How that
>     is done
> 
>      >>
> 
>      >>
> 
>      >>     from the forwarding perspective depends in which forwarding
>     plane you
> 
>      >>
> 
>      >>
> 
>      >>     use. Flex-algo control plane is independent of the
>     forwarding plane.
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>>     I thought with flex algo that there exists a feature that on
> 
>      >>>
> 
>      >>>
> 
>      >>>     each hop there is a way to specify which algo to use hop by hop
> 
>      >>>     similar
> 
>      >>>
> 
>      >>>
> 
>      >>>     to a hop by hop policy based routing.
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     no, there is no hop-by-hop classification, that is
>     problematic and
> 
>      >>     does
> 
>      >>
> 
>      >>
> 
>      >>     not scale for high speeds. Classification is done at the
>     ingress only.
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     thanks,
> 
>      >>
> 
>      >>
> 
>      >>     Peter
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >>     _______________________________________________
> 
>      >>
> 
>      >>
> 
>      >>     Lsr mailing list
> 
>      >>
> 
>      >>
> 
>      >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
> 
>      >>
> 
>      >>
> 
>      >>
>     https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&amp;sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&amp;reserved=0
> 
>      >>
> 
>      >>
> 
>      >>
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      > --
> 
>      >
> 
>      > <http://www.verizon.com/>
> 
>      >
> 
>      > *Gyan Mishra*
> 
>      >
> 
>      > /Network Solutions A//rchitect /
> 
>      >
> 
>      > /M 301 502-1347
> 
>      > 13101 Columbia Pike
> 
>      > /Silver Spring, MD
> 
>      >
> 
>      >
> 
> 
> 
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
>