Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

From: <[email-masked]>
Date: Fri, 12 Nov 2021 12:42:47 +0000

Hi Peter,

> From: Peter Psenak <[email-masked]>
> Sent: Thursday, September 9, 2021 3:30 PM
> To: DECRAENE Bruno INNOV/NET <[email-masked]>; [email-masked]
> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
> 
> Hi Bruno,
> 
> On 09/09/2021 15:27, [email-masked] wrote:
> > Hi Peter,
> >
> > Thanks for your answer.
> > Please see inline
> >
> >> -----Original Message-----
> >> From: Peter Psenak [mailto:[email-masked]]
> >> Sent: Thursday, September 9, 2021 2:52 PM
> >> To: DECRAENE Bruno INNOV/NET <[email-masked]>;
> [email-masked]
> >> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
> >>
> >> Hi Bruno,
> >>
> >> On 09/09/2021 14:43, [email-masked] 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.
> >
> > OK. Excellent.
> > Could the above be added in the specification, so that we have consistent
> behaviour across implementations?
> 
> sure, I will push it with the next revision - after the AD review.

Thanks for the update.
-18 addresses my comment.

Thank you,
--Bruno

> thanks,
> Peter
> 
> 
> >
> > Thanks,
> > Regards,
> > Bruno
> >>
> >> 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-masked]
> >>> https://www.ietf.org/mailman/listinfo/lsr
> >>>
> >>>
> >
> >
> >
> ______________________________________________________________________
> ___________________________________________________
> >
> > 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.
> >
> >
> >

_________________________________________________________________________________________________________________________

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.