Hi All,
draft-lsr-flex-algo-00 was created by combining
draft-hegdeppsenak-isis-sr-flex-algo-02 and
draft-ppsenak-ospf-sr-flex-algo-00.
When draft-lsr-flex-algo-00 was published as a WG document, it included
a requirement for using te-app encodings that did not exist in either
draft-hegdeppsenak-isis-sr-flex-algo-02 and
draft-ppsenak-ospf-sr-flex-algo-00.
Juniper's currently released implementation of flex-algo uses legacy
encodings,
as opposed to te-app encodings. I would like the following text added to
draft-lsr-flex-algo in order to record the history of these changes and
to make
operators aware of possible inter-op problems that may arise due to the
non-backward compatible nature of mandating ASLA encodings.
=====
11. Advertisement of Link Attributes for Flex-Algorithm
" Earlier versions of this draft did not mandate the use of ASLA TLVs
for encoding the
link attributes. There may be implementations that depend on legacy
encodings as defined in
RFC 5305, RFC 7810 , RC 3630 and RFC 7471. Implementations that look at
only ASLA encodings
for flex-algo based on this version of the document will not
interoperate with versions
that use legacy advertisements. "
========
Rgds
Shraddha
Juniper Business Use Only
*From:*olivier.dug...@orange.com <olivier.dug...@orange.com>
*Sent:* Thursday, August 20, 2020 7:56 PM
*To:* Peter Psenak <ppse...@cisco.com>; tony...@tony.li; Robert Raszuk
<rob...@raszuk.net>
*Cc:* Christian Hopps <cho...@chopps.org>;
draft-ietf-lsr-flex-algo....@ietf.org; Les Ginsberg (ginsberg)
<ginsberg=40cisco....@dmarc.ietf.org>; lsr@ietf.org; lsr-...@ietf.org;
Acee Lindem (acee) <a...@cisco.com>
*Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
*[External Email. Be cautious of content]*
Peter,
Le 20/08/2020 à 14:12, Peter Psenak a écrit :
Hi Olivier,
On 20/08/2020 13:58, olivier.dug...@orange.com
<mailto:olivier.dug...@orange.com> wrote:
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.
that's what people were asking for. And it is right because we are
mandating the usage of ALSA encoding for any flex-algo related link
attributes.
Here, it is confusing.
I don't see how much more clear we can make it.
Indeed, RFC 8570 and RFC 7471 also define the way to encode TE
metric and Min delay.
you have to distinguish between two things:
a) where Min delay and TE metric were defined - RFC 8570 and RFC 7471
b) how we encode it for flex-algo - isis-te-app,
ospf-te-link-attr-reuse
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.
no. This will not be done. We only allow ASLA advertisement for
these metrics and other link attributes that are used for flex-algo.
It is done for a reason and I have already explained that.
OK. Reading section 11 which clarify how metrics are convey, let me
suggest to make a reference to section 11 in section 5.1 and 5.2 instead
of reference to drafts.
In fact, in section 17.1.2, you mention only reference to RFC
8570 & RFC7471 for the IANA definition which is fine for me.
because in registry, we are defining a metric type, not how we are
going to advertise it for the link.
OK.
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.
please stop trying to make use of legacy RSVP-TE link advertisements
for flex-algo - it will not be allowed.
This raise to me a simple question: Is it possible to use 2 different
Flex Algo with delay metric, one for App A and another one for App B ?
if yes, how can we link metrics advertise in ALSA A from metrics
advertise in ALSA B ? The draft mention only one bit for Flex-Algo.
Regards,
Olivier
PS. I note a duplicate paragraph in section 12: "When computing the path
for a given Flex-Algorithm, the metric-type that is part of the
Flex-Algorithm definition (Section 5) MUST be used."
thanks,
Peter
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
<mailto: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>
<mailto: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:ginsberg=40cisco....@dmarc.ietf.org>
<mailto: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>
<mailto:lsr-boun...@ietf.org>
<mailto:lsr-boun...@ietf.org>>
*On Behalf Of *tony...@tony.li
<mailto:*tony...@tony.li>
<mailto: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>
<mailto:ppse...@cisco.com>
<mailto:ppse...@cisco.com>>
*Cc:* lsr@ietf.org <mailto:lsr@ietf.org>
<mailto:lsr@ietf.org> <mailto:lsr@ietf.org>;
lsr-...@ietf.org <mailto:lsr-...@ietf.org>
<mailto:lsr-...@ietf.org>
<mailto:lsr-...@ietf.org>; Christian Hopps
<cho...@chopps.org <mailto:cho...@chopps.org>
<mailto:cho...@chopps.org>
<mailto:cho...@chopps.org>>; Acee Lindem (acee)
<a...@cisco.com <mailto:a...@cisco.com>
<mailto:a...@cisco.com>
<mailto:a...@cisco.com>>;
draft-ietf-lsr-flex-algo....@ietf.org
<mailto:draft-ietf-lsr-flex-algo....@ietf.org>
<mailto: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>
<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8570__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ir2QDxsg$>
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>
<mailto:Lsr@ietf.org> <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ivswJmIk$>
_______________________________________________
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ivswJmIk$>
--
Orange logo <http://www.orange.com>
<https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
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>
<mailto: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>
<https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
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>
<mailto: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
<https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
*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.
