Hi Peter, Thank for the new version.
Le 19/08/2020 à 14:00, Peter Psenak a écrit : > Olivier, [ ... ] >> So, to speed up the deployment, I would prefer a reference to a delay value >> that could be advertise by means of RFC7471, RFC8570 and/or TE-App draft. It >> is then up to the operator to ensure the coherency of what it is announced >> in its network by the different routers. > > I know you don't like the app specific link advertisement, but I'm afraid > what you ask for is absolutely wrong. > > We defined the ASLA encoding to address a real problems for advertising the > link attributes. We allow the link attributes to be advertised in both legacy > and ASLA advertisement for legacy application (RSVP-TE, SRTE) to address the > backward compatibility. Flex-algo is a new application, there is absolutely > no need to use the legacy advertisement. Doing so would just extend the > problem to the flex-algo application. Regarding the new version you provided, new section 5.1 (for IS-IS) and section 5.2 (for OSPF) mention respectively RFC 8570 and RFC 7471 for the definition of Min delay and TE metric which is fine for me. But, they also made reference to draft isis-te-app, respectively ospf-te-link-attr-reuse to encode these value. Here, it is confusing. Indeed, RFC 8570 and RFC 7471 also define the way to encode TE metric and Min delay. What I'm suggesting, is a clear reference to the RFC for TE metric and Min delay definition as well as the encoding (especially for the delay) while leaving open the door to how the router acquire these values: legacy a.k.a. RFC 8570 & 7471 or new draft a.k.a draft-isis-te-app & draft-ospf-link-attr-reuse. In fact, in section 17.1.2, you mention only reference to RFC 8570 & RFC7471 for the IANA definition which is fine for me. I would suggest the same wording for section 5.1. and 5.2 leaving operator free about how it collect the values from the neighbour routers: legacy or new method. Regards Olivier PS. We have a pre-alpha implementation of flex algo using the legacy metrics and I know that recent IOS-XR provided similar implementation of flex algo based on legacy metrics. > > regards, > Peter > >> >> Regards >> >> Olivier >> >> Le 18/08/2020 à 19:02, tony...@tony.li a écrit : >>> >>> Robert, >>> >>> Thank you, exactly. >>> >>> We just need a clarification of the document. I don’t understand why this >>> is such a big deal. >>> >>> Tony >>> >>> >>>> On Aug 18, 2020, at 9:22 AM, Robert Raszuk <rob...@raszuk.net >>>> <mailto:rob...@raszuk.net>> wrote: >>>> >>>> Les, >>>> >>>> I think this is not very obvious as Tony is pointing out. >>>> >>>> See RFC 8570 says: >>>> >>>> Type Description >>>> ---------------------------------------------------- >>>> 33 Unidirectional Link Delay >>>> >>>> 34 Min/Max Unidirectional Link Delay >>>> >>>> That means that is someone implementing it reads text in this draft >>>> literally (meaning Minimum value of Unidirectional Link Delay) it may pick >>>> minimum value from ULD type 33 :) >>>> >>>> If you want to be precise this draft may say minimum value of Min/Max >>>> Unidirectional Link Delay (34) and be done. >>>> >>>> That's all. >>>> >>>> Cheers, >>>> R. >>>> >>>> >>>> >>>> On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) >>>> <ginsberg=40cisco....@dmarc.ietf.org <mailto:40cisco....@dmarc.ietf.org>> >>>> wrote: >>>> >>>> Tony – >>>> >>>> As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not >>>> sure why you are confused – nor why you got misdirected to code >>>> point 33. >>>> >>>> RFC 8570 (and its predecessor RFC 7810) define: >>>> >>>> 34 Min/Max Unidirectional Link Delay >>>> >>>> This sub-TLV contains two values: >>>> >>>> “Min Delay: This 24-bit field carries the minimum measured link >>>> delay >>>> >>>> value (in microseconds) over a configurable interval, >>>> encoded as >>>> >>>> an integer value. >>>> >>>> Max Delay: This 24-bit field carries the maximum measured >>>> link delay >>>> >>>> value (in microseconds) over a configurable interval, >>>> encoded as >>>> >>>> an integer value.” >>>> >>>> It seems clear to me that the flex-draft is referring to Min >>>> Unidirectional Link Delay in codepoint 34. >>>> >>>> I agree it is important to be unambiguous in specifications, but >>>> I think Peter has been very clear. >>>> >>>> Please explain how you managed to end up at code point 33?? >>>> >>>> Les >>>> >>>> *From:* Lsr <lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> >>>> *On Behalf Of *tony...@tony.li <mailto:tony...@tony..li> >>>> *Sent:* Tuesday, August 18, 2020 7:44 AM >>>> *To:* Peter Psenak (ppsenak) <ppse...@cisco.com >>>> <mailto:ppse...@cisco.com>> >>>> *Cc:* lsr@ietf.org <mailto:lsr@ietf.org>; lsr-...@ietf.org >>>> <mailto:lsr-...@ietf.org>; Christian Hopps <cho...@chopps.org >>>> <mailto:cho...@chopps.org>>; Acee Lindem (acee) <a...@cisco.com >>>> <mailto:a...@cisco.com>>; draft-ietf-lsr-flex-algo....@ietf.org >>>> <mailto:draft-ietf-lsr-flex-algo....@ietf.org> >>>> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo >>>> >>>> Hi Peter, >>>> >>>> >>>> >>>> section 5.1 of the draft-ietf-lsr-flex-algo says: >>>> >>>> >>>> Min Unidirectional Link Delay as defined in >>>> [I-D.ietf-isis-te-app]. >>>> >>>> We explicitly say "Min Unidirectional Link Delay", so this >>>> cannot be mixed with other delay values (max, average). >>>> >>>> The problem is that that does not exactly match “Unidirectional >>>> Link Delay” or “Min/Max Unidirectional Link Delay”, leading to >>>> the ambiguity. Without a clear match, you leave things open to >>>> people guessing. Now, it’s a metriic, so of course, you always >>>> want to take the min. So type 33 seems like a better match. >>>> >>>> >>>> >>>> >>>> >>>> section 7.3. of ietf-isis-te-app says: >>>> >>>> Type Description Encoding >>>> Reference >>>> --------------------------------------------------------- >>>> 34 Min/Max Unidirectional Link Delay RFC8570 >>>> >>>> And it also says: >>>> >>>> 33 Unidirectional Link Delay RFC8570 >>>> <https://tools.ietf.org/html/rfc8570> >>>> >>>> This does not help. >>>> >>>> >>>> >>>> So, IMHO what we have now is correct and sufficient, but I >>>> have no issue adding the text you proposed below. >>>> >>>> What you have now is ambiguous. We have a responsibility, as >>>> writers of specifications, to be precise and clear. We are not >>>> there yet. >>>> >>>> >>>> >>>> BTW, before I posted 09 version of flex-algo draft, I asked >>>> if you were fine with just referencing ietf-isis-te-app in >>>> 5.1. I thought you were, as you did not indicate otherwise. >>>> >>>> My bad, I should have pressed the issue. >>>> >>>> >>>> >>>> Anyway, I consider this as a pure editorial issue and >>>> hopefully not something that would cause you to object the WG >>>> LC of the flex-algo draft. >>>> >>>> I’m sorry, I think that this is trivially resolved, but important >>>> clarification. >>>> >>>> You also have an author’s email that is bouncing, so at least one >>>> more spin is required. >>>> >>>> Sorry, >>>> >>>> Tony >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org <mailto:Lsr@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr >> -- >> Orange logo <http://www.orange.com> >> >> Olivier Dugeon >> Orange Expert, Future Networks >> Open Source Referent >> Orange/IMT/OLN/WTC/IEE/iTeQ >> >> fixe : +33 2 96 07 28 80 >> mobile : +33 6 82 90 37 85 >> olivier.dug...@orange.com <mailto:olivier.dug...@orange.com> >> >> _________________________________________________________________________________________________________________________ >> >> 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. >> > > -- Orange logo <http://www.orange.com> Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dug...@orange.com <mailto:olivier.dug...@orange.com> _________________________________________________________________________________________________________________________ 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
