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

[Gyan Mishra <[e-mail]>]

Thanks Peter!

On Sun, Oct 4, 2020 at 5:51 AM Peter Psenak <[e-mail]> 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 <[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
>
> >
>
> >
>
>
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD