Olivier,
On 19/08/2020 13:42, [email protected] wrote:
Hi all
I think the clarification is mandatory and not only in section 5.1 and
not only for the delay.
Indeed, section 5.1 makes reference to [I-D.ietf-isis-te-app] while
section 17.1.2 makes reference to RFC8570 with the same error. And what
ok, I will make the same clarification there.
about reference to RFC7471 for OSPF ?
will add that.
And, I also notice the same
problem with the TE metric (ref to draft te app in section 5.1 and
reference to RFC 5305 in section 17.1.2).
will fix that.
So, we need a clear reference to the same document/section/TLVs in both
section 5.1 and section 17.1.2 for both delay and TE metric.
But, the question behind, it is which documents ? Future RFC about TE
app ? RFC 8570 ? RFC 7471 ?
I don't understand. Min/Max Unidirectional Link Delay is clearly defined
in RFC 8570 RFC 7471. For flex-algo it is advertised using ASLA
advertisement. I don't see a problem.
As an operator, as of today, I have not the possibility to advertise
min/max delay in our network as requested in the draft just because it
is not available in all commercial routers. So, referring to a future
RFC which take months/years before it becomes
available/deploy/operational, leave flex algo with delay not ready
before a while.
sorry, but we are defining a new extension. This require new encodings
for flex-algo, so anyone implementing flex-algo needs to implement this
new encodings.
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.
regards,
Peter
Regards
Olivier
Le 18/08/2020 à 19:02, [email protected] 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 <[email protected]
<mailto:[email protected]>> 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)
<[email protected]
<mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>>
*On Behalf Of *[email protected] <mailto:[email protected]>
*Sent:* Tuesday, August 18, 2020 7:44 AM
*To:* Peter Psenak (ppsenak) <[email protected]
<mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>; Christian Hopps <[email protected]
<mailto:[email protected]>>; Acee Lindem (acee) <[email protected]
<mailto:[email protected]>>; [email protected]
<mailto:[email protected]>
*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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
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
[email protected] <mailto:[email protected]>
_________________________________________________________________________________________________________________________
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]
https://www.ietf.org/mailman/listinfo/lsr
