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 <ppse...@cisco.com
<mailto:ppse...@cisco.com>> 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
<jefftant.i...@gmail.com <mailto:jefftant.i...@gmail.com>
> <mailto:jefftant.i...@gmail.com
<mailto:jefftant.i...@gmail.com>>> 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
> <yingzhen...@futurewei.com <mailto:yingzhen...@futurewei.com>
<mailto:yingzhen...@futurewei.com
<mailto:yingzhen...@futurewei.com>>>, 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"
>> <lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>
<mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> on behalf of
>> ppsenak=40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>
>> <mailto:40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>>> 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
>>
>>
>> Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto:Lsr@ietf.org
<mailto:Lsr@ietf.org>>
>>
>>
>>
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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
