On Sat, Oct 3, 2020 at 4:20 AM Robert Raszuk <[email protected]> wrote:
>
> > Can two nodes that run two different flex algo become ospf or isis
> neighbors?
>
> It is my understanding that those nodes always will become ospf neighbours
> as you still run default topology on all of them. I have not seen a case
> where flex algo topology can be enabled without default topology.
>
Gyan>. That is what I was thinking as the algo 0 strict spf 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.
I think I am getting it now! š
>
> Thx,
> R.
>
> On Sat, Oct 3, 2020 at 2:14 AM Gyan Mishra <[email protected]> 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. 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?
>>
>> Can two nodes that run two different flex algo become ospf or isis
>> neighbors?
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura <[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]>,
>>> 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] on behalf of [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]
>>>
>>>
>>>
>>> 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-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>>
>>
>> _______________________________________________
>>
>>
>> Lsr mailing list
>>
>>
>> [email protected]
>>
>>
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>>
>>
>
> --
<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
