Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

["Les Ginsberg (ginsberg)" <[e-mail]>]

Gunter -



You are very close to "the truth" with your post.



The point of the L-flag is to minimize duplicate advertisement of link attributes. In order to justify use of the L-flag all of the following needs to be true:



  *   Both a legacy application and a non-legacy application have to be in use
  *   For a given link, all of the link attribute values associated with the legacy application and with the non-legacy application have to be identical



How could this apply to Flex-algo? Only if (for example) both RSVP-TE and Flex-algo were in use and on a given link all link attribute values were shared.



Peter is absolutely correct in saying use of L-flag is allowed for non-legacy applications (such as flex-algo). But doing so in the absence of a legacy application is not at all what is intended. As the intent of L-flag is to avoid duplicate advertisements and in the absence of a legacy application there can be no duplicate advertisements there is no point in using the L-flag in such a situation.



   Les





> -----Original Message-----

> From: Van De Velde, Gunter (Nokia - BE/Antwerp)

> <[e-mail]>

> Sent: Thursday, September 03, 2020 5:50 AM

> To: Peter Psenak (ppsenak) <[e-mail]>; Selderslaghs, Rudy

> (Nokia - BE/Antwerp) <[e-mail]>; Shraddha Hegde

> <[e-mail]>; [e-mail]; [e-mail];

> Robert Raszuk <[e-mail]>

> Cc: Christian Hopps <[e-mail]>; draft-ietf-lsr-flex-

> [e-mail]; Les Ginsberg (ginsberg) <[e-mail]>;

> [e-mail]; [e-mail]; Acee Lindem (acee) <[e-mail]>

> Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

>

> I think that some misunderstanding comes from a different definition of "

> LEGACY ADVERTISEMENTS" between section 4.2 and 6.1

>

> In section 4.2:

> LEGACY ADVERTISEMENTS means that *ASLA is used* and point to the

> attributes found in legacy TLVs for example EAG, Delay and TE-metric

>

> In section 6.1:

> LEGACY ADVERTISEMENTS means that *ASLA is NOT used* and allows RSVP-

> TE, SR-Policy and LFA to interoperate between systems that do not, and do,

> support ASLA

>

> Taking this understanding to flex-algo:

> * Interop: traditionally we use the L-bit=SET for application interoperability

> when not all nodes understand valid ASLA encoding.

> * Interop: by design of flex-algorithm technology, we mandate ASLA

> encoding. No interop issues should exist with nodes not understanding ASLA

> encodings.

> * Why would a flex-algo node, ever, advertise legacy TLVs for flex-algo

> attributes? There seems no use-case and no logic for such.

> * OSPF has no existing L-bit

>

> For flex-algo simplicity, we could agree that legacy attribute advertisements

> MUST NOT be used and agree that flex-algo ASLA L-bit MUST be UNSET

> (This is unrelated that flex-algo ASLA with L-bit SET is semantically a valid

> ASLA. This also simplifies and align ISIS and OSPF routing protocol behavior. It

> reduce interop issues footprint with systems not supporting ASLA.)

>

> G/

>

>

>

>

>

>

> -----Original Message-----

> From: Peter Psenak <[e-mail]<mailto:[e-mail]>>

> Sent: Thursday, September 3, 2020 12:02

> To: Van De Velde, Gunter (Nokia - BE/Antwerp)

> <[e-mail]<mailto:[e-mail]>>; Selderslaghs, Rudy (Nokia -

> BE/Antwerp) <[e-mail]<mailto:[e-mail]>>; Shraddha Hegde

> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> Robert Raszuk <[e-mail]<mailto:[e-mail]>>

> Cc: Christian Hopps <[e-mail]<mailto:[e-mail]>>; draft-ietf-lsr-flex-<mailto:[e-mail]>

> [e-mail]<mailto:[e-mail]>; Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>;

> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>

> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

>

> Gunter,

>

> On 03/09/2020 11:53, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:

> > Hi Peter, All,

> >

> > Let me chime in.

> >

> > When the L-bit is set in an ASLA TLV, then for all applications marked,

> indeed only legacy attributes can be used.

> > Of course an ASLA TLV with the L-bit set is a valid ASLA advertisement. That

> is not the point.

> >

> > Read the text in chapter 4.2:

> >

> >>      When the L-flag is set in the Application Identifier Bit Mask, all of

> >>      the applications specified in the bit mask MUST use the legacy

> >>      advertisements for the corresponding link found in TLVs 22, 23, 25,

> >>      141, 222, and 223 or TLV 138 or TLV 139 as appropriate.

> >

> > This clearly says that when the L-bit is set, the LEGACY ADVERTISEMENTS

> have to be used.

> > However chapter 6.1 is saying that legacy advertisements can only be used

> for RSVP-TE, SR-Policy and LFA.

>

> where? Please point me to the text.

>

> If you are referring to the text:

>

> "New applications that future documents define to make use of the

> advertisements defined in this document MUST NOT make use of legacy

> advertisements."

>

> then it is NOT preventing L-bit with legacy advertisement for new apps,

> because ASLA with L-bit in combination with legacy advertisement is not

> considered as legacy advertisement, but as a valid ASLA advertisement.

>

>

> >

> > So in my opinion the draft is saying the opposite and legacy advertisements

> MUST NOT be used for flex-algo.

>

> again, L-bit with legacy advertisement is NOT a legacy advertisement. It is

> ASLA advertisement.

>

> > Hence, I suggest that we should make it explicit clear that L-bit set for flex-

> algo is MUST NOT be allowed.

>

> L-bit is allowed with any app, including the flex-algo.

>

> thanks,

> Peter

>

> >

> > G/

> >

> >

> >

> >

> > -----Original Message-----

> > From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of Peter Psenak

> > Sent: Thursday, September 3, 2020 11:19

> > To: Selderslaghs, Rudy (Nokia - BE/Antwerp)

> > <[e-mail]<mailto:[e-mail]>>; Peter Psenak

> > <ppsenak=[e-mail]<mailto:ppsenak=[e-mail]>>; Shraddha Hegde

> > <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> > Robert Raszuk <[e-mail]<mailto:[e-mail]>>

> > Cc: Christian Hopps <[e-mail]<mailto:[e-mail]>>;

> > [e-mail]<mailto:[e-mail]>; Les Ginsberg (ginsberg)

> > <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> > Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>

> > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

> >

> > Hi Rudy,

> >

> > On 03/09/2020 11:01, Selderslaghs, Rudy (Nokia - BE/Antwerp) wrote:

> >> Hi Peter,

> >>

> >> My interpretation of the isis-te-app draft is that an ASLA TLV with L-bit set

> to 1, cannot be used for Flex-Algo.

> >

> > no, that is not correct.

> >

> >> This can only be used for RSVP-TE, SR-Policy and LFA as specified in

> chapter 6.1.

> >

> > no.

> >

> >>

> >> >From chapter 6.1 Use of Legacy advertisements:

> >>      ...

> >>      New applications that future documents define to make use of the

> >>      advertisements defined in this document MUST NOT make use of

> legacy

> >>      advertisements.  This simplifies deployment of new applications by

> >>      eliminating the need to support multiple ways to advertise attributes

> >>      for the new applications.

> >

> > ASLA with L-bit pointing to legacy TLV is NOT considered legacy

> advertisement. It is valid ASLA advertisement.

> >

> >

> >>

> >> Chapter 4.2. states that ASLA TLV with L-bit set means "using legacy

> advertisements":

> >

> > no. It says that if L-flag is set, all apps mentioned in the bitmask

> > MUST use the legacy advertisement to derive the value of the attribute.

> > It does NOT say that ASLA TLV with L-bit set means "using legacy

> > advertisements". It does not.

> >

> > thanks,

> > Peter

> >

> >>      ...

> >>      When the L-flag is set in the Application Identifier Bit Mask, all of

> >>      the applications specified in the bit mask MUST use the legacy

> >>      advertisements for the corresponding link found in TLVs 22, 23, 25,

> >>      141, 222, and 223 or TLV 138 or TLV 139 as appropriate.

> >>

> >> Regards,

> >> Rudy

> >>

> >> -----Original Message-----

> >> From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of Peter Psenak

> >> Sent: Thursday, September 3, 2020 9:55 AM

> >> To: Shraddha Hegde <[e-mail]<mailto:[e-mail]>>;

> [e-mail]<mailto:[e-mail]>;

> >> [e-mail]<mailto:[e-mail]>; Robert Raszuk <[e-mail]<mailto:[e-mail]>>

> >> Cc: Christian Hopps <[e-mail]<mailto:[e-mail]>>;

> >> [e-mail]<mailto:[e-mail]>; Les Ginsberg (ginsberg)

> >> <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>; [e-mail]<mailto:[e-mail]>;

> >> [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>

> >> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

> >>

> >> Hi Shraddha,

> >>

> >> On 03/09/2020 05:39, Shraddha Hegde wrote:

> >>> 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.

> >>

> >>

> >> I can add the above, although, it's clear from the draft-ietf-isis-te-app that

> L-bit with legacy advertisement MAY be used for any app.

> >>

> >>>

> >>> 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."

> >>

> >> it is not true that "earlier versions of this document" did not mandate

> ASLA.

> >>

> >> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only

> supported the include/exclude Admin Groups, clearly stated:

> >>

> >>

> >> 9.  Advertisement of Link Attributes for Flex-Algorithm

> >>

> >>       Various link include or exclude rules can be part of the Flex-

> >>       Algorithm definition.  These rules use Admin Groups (AG) as defined

> >>       in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)

> >>       as defined in [RFC7308].

> >>

> >>       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.

> >>

> >>

> >> thanks,

> >> Peter

> >>

> >>

> >>

> >>> ============

> >>>

> >>>

> >>> Rgds

> >>> Shraddha

> >>>

> >>>

> >>> Juniper Business Use Only

> >>>

> >>> -----Original Message-----

> >>> From: Peter Psenak <[e-mail]<mailto:[e-mail]>>

> >>> Sent: Wednesday, September 2, 2020 2:43 PM

> >>> To: Shraddha Hegde <[e-mail]<mailto:[e-mail]>>;

> >>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Robert Raszuk

> >>> <[e-mail]<mailto:[e-mail]>>

> >>> Cc: Christian Hopps <[e-mail]<mailto:[e-mail]>>;

> >>> [e-mail]<mailto:[e-mail]>; Les Ginsberg (ginsberg)

> >>> <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>; [e-mail]<mailto:[e-mail]>;

> >>> [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>

> >>> 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 <[e-mail]<mailto:[e-mail]>>

> >>>> Sent: Thursday, August 27, 2020 3:34 PM

> >>>> To: Shraddha Hegde <[e-mail]<mailto:[e-mail]>>;

> >>>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Robert Raszuk

> >>>> <[e-mail]<mailto:[e-mail]>>

> >>>> Cc: Christian Hopps <[e-mail]<mailto:[e-mail]>>;

> >>>> [e-mail]<mailto:[e-mail]>; Les Ginsberg (ginsberg)

> >>>> <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>; [e-mail]<mailto:[e-mail]>;

> >>>> [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>

> >>>> 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-<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-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf->

> >>>> isi

> >>>> s-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-

> jnYKFPl7DWC_fZ

> >>>> CGD

> >>>> apvakBVKlZPth_09_HTtuT$  and

> >>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-<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:*[e-mail] <[e-mail]<mailto:[e-mail]>>

> >>>>> *Sent:* Thursday, August 20, 2020 7:56 PM

> >>>>> *To:* Peter Psenak <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Robert

> >>>>> Raszuk <[e-mail]<mailto:[e-mail]>>

> >>>>> *Cc:* Christian Hopps <[e-mail]<mailto:[e-mail]>>;

> >>>>> [e-mail]<mailto:[e-mail]>; Les Ginsberg (ginsberg)

> >>>>> <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>; [e-mail]<mailto:[e-mail]>;

> >>>>> [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>

> >>>>> *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, [e-mail]<mailto:[e-mail]>

> >>>>>         <mailto:[e-mail]> 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, [e-mail]<mailto:[e-mail]>

> >>>>>                     <mailto:[e-mail]> 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

> >>>>>                             <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>

> >>>>>                             <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>> 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=[e-mail]

> >>>>>                             <mailto:ginsberg=[e-mail]>

> >>>>>                             <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>> 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 <[e-mail]

> >>>>>                             <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>>

> >>>>>                                  *On Behalf Of *[e-mail]<mailto:*[e-mail]>

> >>>>>                             <mailto:*[e-mail]>

> >>>>>                             <mailto:[e-mail]> <mailto:[e-mail]>

> >>>>>                                  *Sent:* Tuesday, August 18, 2020 7:44 AM

> >>>>>                                  *To:* Peter Psenak (ppsenak)

> >>>>>                             <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>

> >>>>>                             <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>>

> >>>>>                                  *Cc:* [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]> <mailto:[e-mail]>;

> >>>>>                             [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>; Christian Hopps

> >>>>>                             <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>

> >>>>>                             <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>>; Acee Lindem (acee)

> >>>>>                             <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>

> >>>>>                             <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>>;

> >>>>>                             [e-mail]<mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>

> >>>>>                                  *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_fZCGDapvakBVKlZPt

> >>>>> h_0

> >>>>> 3pN2Sfl$ >

> >>>>>

> >>>>> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8570__;

> >>>>> !!N

> >>>>> E

> >>>>> t6yMaO-

> gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1

> >>>>> ir2

> >>>>> 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

> >>>>>                             [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

> >>>>>                             <mailto:[e-mail]>

> >>>>> <mailto:[e-mail]>

> >>>>>

> >>>>>

> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>

> >>>>> lsr

> >>>>> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-

> jnYKFPl7DWC_fZCGDapvakBV

> >>>>> KlZ

> >>>>> Pth_07ffIqQQ$

> >>>>>

> >>>>>

> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/

> >>>>> lsr

> >>>>> _

> >>>>> _;!!NEt6yMaO-

> gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAu

> >>>>> fXg

> >>>>> y

> >>>>> h1ivswJmIk$>

> >>>>>

> >>>>>

> >>>>>

> >>>>>

> >>>>>

> _______________________________________________

> >>>>>                         Lsr mailing list

> >>>>>                         [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

> >>>>>

> >>>>>

> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>

> >>>>> lsr

> >>>>> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-

> jnYKFPl7DWC_fZCGDapvakBV

> >>>>> KlZ

> >>>>> Pth_07ffIqQQ$

> >>>>>

> >>>>>

> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/

> >>>>> lsr

> >>>>> _

> >>>>> _;!!NEt6yMaO-

> gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAu

> >>>>> fXg

> >>>>> 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 : [phone]

> >>>>>                     mobile : [phone]

> >>>>>                     [e-mail]<mailto:[e-mail]>

> >>>>>                     <mailto:[e-mail]>

> >>>>>                     <mailto:[e-mail]>

> >>>>>                     <mailto:[e-mail]>

> >>>>>

> >>>>>

> >>>>>

> __________________________________________________________

> ________

> >>>>> ___ _

> ___________________________________________________

> >>>>>

> >>>>>

> >>>>>                     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 : [phone]

> >>>>>             mobile : [phone]

> >>>>>             [e-mail]<mailto:[e-mail]>

> <mailto:[e-mail]>

> >>>>>             <mailto:[e-mail]>

> >>>>>             <mailto:[e-mail]>

> >>>>>

> >>>>>

> >>>>>

> __________________________________________________________

> ________

> >>>>> ___ _

> ___________________________________________________

> >>>>>

> >>>>>

> >>>>>             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 : [phone]

> >>>>> mobile : [phone]

> >>>>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

> >>>>>

> >>>>>

> __________________________________________________________

> ________

> >>>>> ___ _

> ___________________________________________________

> >>>>>

> >>>>> 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

> >> [e-mail]<mailto:[e-mail]>

> >> https://www.ietf.org/mailman/listinfo/lsr

> >>

> >>

> >

> >

> > _______________________________________________

> > Lsr mailing list

> > [e-mail]<mailto:[e-mail]>

> > https://www.ietf.org/mailman/listinfo/lsr

> >

> >