Thanks Peter! On Sun, Oct 4, 2020 at 5:51 AM Peter Psenak <[email protected]> wrote:
> 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 <[email protected] > > > <mailto:[email protected]>> 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 > > > <[email protected] <mailto:[email protected]> > > > > > > > <mailto:[email protected] > > > <mailto:[email protected]>>> 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 > > > > > > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] > > > <mailto:[email protected]>>>, 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" > > > > > > >> <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> on > behalf of > > > > > > >> [email protected] > > > <mailto:[email protected]> > > > > > > >> <mailto:[email protected] > > > <mailto:[email protected]>>> 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 > > > > > > >> > > > > > > >> > > > > > > >> [email protected] <mailto:[email protected]> <mailto:[email protected] > > > <mailto:[email protected]>> > > > > > > >> > > > > > > >> > > > > > > >> > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&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 > > > > > > > > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
