Hi Acee,
On 15/09/2021 20:09, Acee Lindem (acee) wrote:
Hi Peter,
I had too long of a context switch on flex algo.... See inline.
On 9/12/21, 2:15 PM, "Lsr on behalf of Peter Psenak" <[email protected] on
behalf of [email protected]> wrote:
Hi Acee,
On 11/09/2021 16:59, Acee Lindem (acee) wrote:
> Hi Peter,
>
> On 9/10/21, 1:46 AM, "Lsr on behalf of Peter Psenak" <[email protected]
on behalf of [email protected]> wrote:
>
> Linda,
>
> On 09/09/2021 22:17, Linda Dunbar wrote:
> > Peter and Tony,
> >
> > Thank you very much for the explanation.
> >
> > Is it necessary to register with IANA on individual Flex-Algo
value (a value between 128-255)?
>
> no.
>
> But if the corresponding algorithm is in another standards track
document, it would need to be registered and part of the standard range.
sure, the question was if "individual Flex-Algo value" needs to be
registered and the answer to that is no. We have reserved the range of
algos from 128 to 255 to flex-algos and there is no further IANA
registration needed for those.
So, if someone wants to define new constraints (e.g., Linda's
server/application metrics), they would need to define the semantics and
encodings similar to what is being done for bandwidth metrics in
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/ . Then the
flex algos could be defined using these metrics. Correct?
yes, they would need to define a new FAD constraint and/or metric only.
thanks,
Peter
Thanks,
Acee
thanks,
Peter
>
> Thanks,
> Acee
>
>
> > Say there are 5 properties associated with the Stub link, one
Flex algo uses weighted values of 4 properties, another Flex Algo uses Weighted
values of 5 properties. Can operator use any value they want? As long as the value is
consistent among all nodes in one IGP domain?
>
> that is right.
>
> >
> > How is Calc-Type used, especially combined with Flex-Algo?
>
> we only have a single calculation type for now which is SPF. We
added it
> for future if anyone wants to use a different one.
>
>
> >
> > Does the Flex-Algo type already indicate how Metric are to be included in
the algorithm? Why need to explicit indicate the "Metric-Type" in the FAD Sub-TLV?
>
> It's the Calc-Type which indicates how metric is used. Metric-Type
> indicates which metric is used.
>
> thanks,
> Peter
>
> >
> >
> > Linda
> >
> > -----Original Message-----
> > From: Peter Psenak <[email protected]>
> > Sent: Thursday, September 9, 2021 1:00 PM
> > To: Tony Li <[email protected]>; Linda Dunbar
<[email protected]>
> > Cc: [email protected]; [email protected]
> > Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
> >
> > Hi Linda, Tony,
> >
> >
> > On 09/09/2021 19:37, Tony Li wrote:
> >>
> >>
> >> Hi Linda,
> >>
> >> Algorithm types 128-255 are intended to be used with the
constraints
> >> that are advertised inside of a FlexAlgo definition.
> >>
> >> I think what you're proposing is not captured there, so you
would need
> >> to have a defined algorithm from 2-127.
> >
> > eventually, the usage of the "weighted value of a Stub Link
property"
> > can be added to the FAD and be used with flex-algo.
> >
> > thanks,
> > Peter
> >
> >
> >>
> >> Tony
> >>
> >>
> >>> On Sep 9, 2021, at 9:51 AM, Linda Dunbar
<[email protected]
> >>> <mailto:[email protected]>> wrote:
> >>>
> >>> Peter,
> >>>
> >>> draft-ietf-lsr-flex-algo-17 currently has registered Algorithm
Types
> >>> 128-255 with IANA.
> >>> If we need to add a new Algorithm Type, e.g. using a weighted
value
> >>> of a Stub Link property in calculating the shortest path, do we
need
> >>> to use one of the value within 128-255 or need to ask IANA to
assign
> >>> one of the values within 2-127 (currently shown unassigned on
IANA page)?
> >>>
> >>> Linda Dunbar
> >>>
> >>> -----Original Message-----
> >>> From: Lsr <[email protected] <mailto:[email protected]>>
On
> >>> Behalf Of Peter Psenak
> >>> Sent: Thursday, September 9, 2021 7:52 AM
> >>> To:[email protected]
> >>> <mailto:[email protected]>;[email protected]
<mailto:[email protected]>
> >>> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
> >>>
> >>> Hi Bruno,
> >>>
> >>> On 09/09/2021 14:43, [email protected]
> >>> <mailto:[email protected]> wrote:
> >>>> Hi authors, all,
> >>>>
> >>>> I have a question related to the two-way connectivity check
> >>>> performed on each link during the FlexAlgo SPF.
> >>>
> >>> flex-algo is defined as set of:
> >>>
> >>> (a) calculation-type
> >>> (b) metric-type,
> >>> (c) a set of constraints
> >>>
> >>> Two way connectivity check for any link in the MT topology is
> >>> orthogonal to flex-algo and is done once only and used for all
algorithms.
> >>>
> >>> Flex-algo calculation using (a), (b), and (c) is done on top of
MT
> >>> topology using only links for which the 2WCC has already been
performed.
> >>>
> >>>
> >>>>
> >>>> Is this point documented in the document? I could not find it
so far.
> >>>> If not, what is the (reverse connectivity) check that need to
be
> >>>> performed on the reverse link?
> >>>
> >>>
> >>> none.
> >>>
> >>> thanks,
> >>> Peter
> >>>
> >>>
> >>>>
> >>>> A priori I could see multiple options:
> >>>> a) link exist
> >>>> b) link exist with a standard IGP metric (seem the option
defined
> >>>> in the ISO spec §7.2.8.2)
> >>>> c) link exist with the FlexAlgo metric used by FlexAlgo
> >>>> d) link exist with the FlexAlgo metric used by FlexAlgo and
link
> >>>> complies to FlexAlgo constraints.
> >>>>
> >>>> I think we'll agree that this point requires uniformity across
nodes
> >>>> hence standardization.
> >>>>
> >>>> Personally, I don't have significant preference, but the algo
> >>>> defined in §13 "Calculation of Flexible Algorithm Paths" could
be
> >>>> read as defining option "d" (as links not following the
constraints
> >>>> are "pruned from the computation") but I'm not sure that this
is
> >>>> intended for the two-way connectivity check.
> >>>>
> >>>> Thanks,
> >>>> Regards,
> >>>> --Bruno
> >>>>
> >>>>
> >>>>
> >>>>
____________________________________________________________________
> >>>> _____________________________________________________
> >>>>
> >>>> Ce message et ses pieces jointes peuvent contenir des
informations
> >>>> confidentielles ou privilegiees et ne doivent donc pas etre
> >>>> diffuses, exploites ou copies sans autorisation. Si vous avez
recu
> >>>> ce message par erreur, veuillez le signaler a l'expediteur et
le
> >>>> detruire ainsi que les pieces jointes. Les messages
electroniques
> >>>> etant susceptibles d'alteration, Orange decline toute
responsabilite
> >>>> si ce message a ete altere, deforme ou falsifie. Merci.
> >>>>
> >>>> This message and its attachments may contain confidential or
> >>>> privileged information that may be protected by law; they
should not
> >>>> be distributed, used or copied without authorisation.
> >>>> If you have received this email in error, please notify the
sender
> >>>> and delete this message and its attachments.
> >>>> As emails may be altered, Orange is not liable for messages
that
> >>>> have been modified, changed or falsified.
> >>>> Thank you.
> >>>>
> >>>> _______________________________________________
> >>>> Lsr mailing list
> >>>> [email protected] <mailto:[email protected]>
> >>>>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> >>>>
w.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunba
> >>>>
r%40futurewei.com%7Cca978044a7ba440ec77108d973bba407%7C0fee8ff2a3b24
> >>>>
0189c753a1d5591fedc%7C1%7C0%7C637668072069634742%7CUnknown%7CTWFpbGZ
> >>>>
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> >>>>
%3D%7C1000&sdata=tTyS4ZyXQiylM%2B5e%2BM6qytL0P3wBTMDw%2FVJnLjqz2
> >>>> K0%3D&reserved=0
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Lsr mailing list
> >>> [email protected] <mailto:[email protected]>
> >>>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> >>>
.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%
> >>>
40futurewei.com%7Cca978044a7ba440ec77108d973bba407%7C0fee8ff2a3b24018
> >>>
9c753a1d5591fedc%7C1%7C0%7C637668072069634742%7CUnknown%7CTWFpbGZsb3d
> >>>
8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> >>>
C1000&sdata=tTyS4ZyXQiylM%2B5e%2BM6qytL0P3wBTMDw%2FVJnLjqz2K0%3D&
> >>> amp;reserved=0
> >>>
> >>> _______________________________________________
> >>> Lsr mailing list
> >>> [email protected] <mailto:[email protected]>
> >>>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> >>>
.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%
> >>>
40futurewei.com%7Cca978044a7ba440ec77108d973bba407%7C0fee8ff2a3b24018
> >>>
9c753a1d5591fedc%7C1%7C0%7C637668072069634742%7CUnknown%7CTWFpbGZsb3d
> >>>
8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> >>>
C1000&sdata=tTyS4ZyXQiylM%2B5e%2BM6qytL0P3wBTMDw%2FVJnLjqz2K0%3D&
> >>> amp;reserved=0
> >>
> >
> >
> >
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
