Peter, In order to make the document clearer on this point, I would like the text below to be added to section 11 to make it explicit that setting the L-bit is valid for flex-algo for ISIS.
============= Section 11. “The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 of [draft-ietf-isis-te-app]. When the L-bit is set, applications MUST use legacy advertisements for that link. Flex algorithm application MUST support sending and receiving link attributes with ASLA TLV having L-bit set. Note that earlier versions of this document did not mandate use of ASLA TLVs and hence may not inter-operate with early implementations that use legacy advertisements." ============ Rgds Shraddha Juniper Business Use Only -----Original Message----- From: Peter Psenak <[email protected]> Sent: Wednesday, September 2, 2020 2:43 PM To: Shraddha Hegde <[email protected]>; [email protected]; [email protected]; Robert Raszuk <[email protected]> Cc: Christian Hopps <[email protected]>; [email protected]; Les Ginsberg (ginsberg) <[email protected]>; [email protected]; [email protected]; Acee Lindem (acee) <[email protected]> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo [External Email. Be cautious of content] Hi Shraddha, please see inline: On 02/09/2020 06:45, Shraddha Hegde wrote: > Peter, > > It is worthwhile to note the history of the flex-algo draft and the > te-app draft and how many backward incompatible changes have been > introduced in the course of the flex-algo draft. > > The original drafts of flex-algo did not mention the te-app draft and > was completely based on legacy advertisements. > Two years ago, after the working group adopted the original drafts > without the ASLA TLV, the text was changed to require the ASLA TLV. draft-ietf-lsr-flex-algo-00, which was the initial version of the WG document already mandated the ASLA usage. I don't believe we have to go back to the individual drafts that predated the WG version. > > > ASLA TLV had the L-Bit and it was always valid to advertise link > attributes for flex-algo with L-bit set which means the link > attributes could still be sent in legacy TLVs. > In a conversation last year, you had agreed that advertising link > attributes with L-bit set is valid for Flex-algo. what we say in flex-algo draft in section 11 is: "Link attribute advertisements that are to be used during Flex- Algorithm calculation MUST use the Application-Specific Link Attribute (ASLA) advertisements defined in [I-D.ietf-isis-te-app] or [I-D.ietf-ospf-te-link-attr-reuse]." ietf-isis-te-app clearly allows the app specific value of the attribute to be advertised in legacy TLV and be pointed to by ASLA with L-bit. This is perfectly valid for Flex-algo with ISIS. Please note that etf-ospf-te-link-attr-reuse does not have the concept of L-bit. > > Towards the end of 2019, draft-ietf-isis-te-app-08 was posted. This > version said that only RSVP, SR-TE and LFA can use legacy advertisements. > This change in a different draft made using flex-algo with legacy > advertisements invalid. no, not really. From the version 00, the WG version of the flex-algo draft mandated the usage of ASLA. And from day one of the draft-ietf-isis-te-app draft we mandated the usage of the ALSA for new applications, including the flex-algo. And usage of ASLA with L-bit together with the legacy advertisement of the link attribute is valid for any new application. > > So implementations from 2 yrs ago may not inter-operate with the ones > implemented a year ago or the ones implemented based on published RFC. let's be more precise here. The implementation of the pre-WG version may not inter-operate with WG version. I don't see a problem there really. > Implementations from a year ago may not interoperate with published RFC. no, that is not true. > > I don’t agree with this series of backward incompatible changes that > have been made in this document. However, if the working group > decides to go ahead and request publication of the current version, > which has broken backward compatibility twice with previous versions, above statement is not correct. The WG document has been consistent in terms of ASLA usage from day one. thanks, Peter > I want the history to be accurately recorded. This allows network > operators to better understand the history and ensure interoperability across > vendors before deploying. > > > Rgds > Shraddha > > > Juniper Business Use Only > > -----Original Message----- > From: Peter Psenak <[email protected]> > Sent: Thursday, August 27, 2020 3:34 PM > To: Shraddha Hegde <[email protected]>; [email protected]; > [email protected]; Robert Raszuk <[email protected]> > Cc: Christian Hopps <[email protected]>; > [email protected]; Les Ginsberg (ginsberg) > <[email protected]>; [email protected]; [email protected]; > Acee Lindem (acee) <[email protected]> > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo > > [External Email. Be cautious of content] > > > Hi Shraddha, > > draft-ietf-lsr-flex-algo-00 was published May 15, 2018 (over two years ago). > > > > It clearly stated: > > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr > -flex-algo-00*section-9__;Iw!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnY > KFPl7DWC_fZCGDapvakBVKlZPth_03Sd1J7b$ > > "To advertise a link affinity in a form of the AG or EAG that is used > during Flex-Algorithm calculation, an Application Specific Link > Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV > of Extended Link TLV as described in [I-D.ietf-ospf-te-link-attr-reuse] > MUST be used. The advertisement MUST indicate that it is usable by the > Flex-Algorithm application." > > This is consistent with normative statements in both > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-isi > s-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGD > apvakBVKlZPth_09_HTtuT$ and > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet > f-ospf-te-link-attr-reuse/__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jn > YKFPl7DWC_fZCGDapvakBVKlZPth_08_P1Wmy$ > which REQUIRE the use of application specific advertisements by all > applications other than the legacy applications (RSVP-TE, Segment Routing > Policy, Loop Free Alternate). > > draft-hegdeppsenak-isis-sr-flex-algo had a lifetime of 10 months(V00 > published in July 2017) and draft-ppsenak-ospf-sr-flex-algo only 3 months > (V00 published in Feb 2018). > > Juniper may have its own reasons why over the course of the past two years it > has chosen not to modify its early implementation to be compatible with what > is defined in the WG adopted draft. We do not question this choice. But it > seems the most appropriate way to communicate this is for Juniper to document > in its vendor specific documents that its implementation is based on a pre-WG > draft and is incompatible with the IETF defined standard. IETF documents are > not the correct place for such proprietary information. > > It is obvious that the implementation that is not following the final > specification will not interoperate with other implementations that do so. > There is no need to mention that in the RFC. > > thanks, > Peter and Les > > > > On 25/08/2020 17:27, Shraddha Hegde wrote: >> 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:*[email protected] <[email protected]> >> *Sent:* Thursday, August 20, 2020 7:56 PM >> *To:* Peter Psenak <[email protected]>; [email protected]; Robert >> Raszuk <[email protected]> >> *Cc:* Christian Hopps <[email protected]>; >> [email protected]; Les Ginsberg (ginsberg) >> <[email protected]>; [email protected]; >> [email protected]; Acee Lindem (acee) <[email protected]> >> *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, [email protected] >> <mailto:[email protected]> 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, [email protected] >> <mailto:[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]> >> <mailto:[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]> >> <mailto:[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]> >> <mailto:[email protected]> >> <mailto:[email protected]>> >> *On Behalf Of *[email protected] >> <mailto:*[email protected]> >> <mailto:[email protected]> <mailto:[email protected]> >> *Sent:* Tuesday, August 18, 2020 7:44 AM >> *To:* Peter Psenak (ppsenak) >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected]> >> <mailto:[email protected]>> >> *Cc:* [email protected] <mailto:[email protected]> >> <mailto:[email protected]> <mailto:[email protected]>; >> [email protected] <mailto:[email protected]> >> <mailto:[email protected]> >> <mailto:[email protected]>; Christian Hopps >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected]> >> <mailto:[email protected]>>; Acee Lindem (acee) >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected]> >> <mailto:[email protected]>>; >> [email protected] >> <mailto:[email protected]> >> <mailto:[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://urldefense.com/v3/__https://tools.ietf.org/html/rfc8570__;!! >> NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0 >> 3pN2Sfl$ > >> >> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8570__;!!N >> E >> t6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ir2 >> Q >> Dxsg$> >> >> >> 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]> >> <mailto:[email protected]> <mailto:[email protected]> >> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZ >> Pth_07ffIqQQ$ >> >> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr >> _ >> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXg >> y >> h1ivswJmIk$> >> >> >> >> >> _______________________________________________ >> Lsr mailing list >> [email protected] <mailto:[email protected]> >> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZ >> Pth_07ffIqQQ$ >> >> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr >> _ >> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXg >> y >> h1ivswJmIk$> >> >> >> -- >> Orange logo >> <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk!U6 >> 9buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ > >> >> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKu >> L WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$> >> >> >> 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]> >> <mailto:[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. >> >> -- >> Orange logo >> <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk!U6 >> 9buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ > >> >> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKu >> L WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$> >> >> >> 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]> >> <mailto:[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. >> >> -- >> Orange logo >> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKu >> L WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$> >> >> *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
