subject:"\[Lsr\] WG Last Call for draft\-ietf\-lsr\-flex\-algo"

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

2020-10-21 Thread Acee Lindem (acee)

Now the Routing Directorate review is complete, I will request publication. 
Thanks,
Acee

On 10/1/20, 11:32 AM, "Acee Lindem (acee)"  wrote:

The WG last call has ended. All comments have been addressed or concluded. 
There was considerable discussion regarding the requirement that alternate link 
metrics come from Application-Specific Link Attributes (ASLAs) and whether to 
allow them from TE advertisements as well. The consensus was to since this is a 
new application mandating a single source of truth for ASLAs. From a technical 
standpoint, this is especially true with OSPF where allowing them to come from 
TE advertisements requires correlation of an additional LSA per link and all 
the attendant complexity. 

The document will be submitted to the IESG for publication as soon as I 
complete the shepherd writeup. 

Thanks,
Acee 

On 8/17/20, 7:30 PM, "Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after September 1st, 2020, 
for draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether 
you aware of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2020-10-01 Thread Acee Lindem (acee)

The WG last call has ended. All comments have been addressed or concluded. 
There was considerable discussion regarding the requirement that alternate link 
metrics come from Application-Specific Link Attributes (ASLAs) and whether to 
allow them from TE advertisements as well. The consensus was to since this is a 
new application mandating a single source of truth for ASLAs. From a technical 
standpoint, this is especially true with OSPF where allowing them to come from 
TE advertisements requires correlation of an additional LSA per link and all 
the attendant complexity. 

The document will be submitted to the IESG for publication as soon as I 
complete the shepherd writeup. 

Thanks,
Acee 

On 8/17/20, 7:30 PM, "Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you 
aware of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2020-09-11 Thread Peter Psenak

 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  
Sent: Thursday, September 3, 2020 12:02

To: Van De Velde, Gunter (Nokia - BE/Antwerp); Selderslaghs, Rudy 
(Nokia - BE/Antwerp); Shraddha 
Hegde;olivier.dug...@orange.com;tony...@tony.li; Robert 
Raszuk
Cc: Christian Hopps;draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg 
(ginsberg);lsr@ietf.org;lsr-...@ietf.org; Acee Lindem 
(acee)
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  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 11:19
To: Selderslaghs, Rudy (Nokia - BE/Antwerp)
; Peter Psenak
; Shraddha Hegde
;olivier.dug...@orange.com;tony...@tony.li;
Robert Raszuk
Cc: Christian Hopps;
draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg)
;lsr@ietf.org;lsr-...@ietf.org;
Acee Lindem (acee)
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  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 9:55 AM
To: Shraddha Hegde;olivier.dug...@orange.com;
tony...@tony.li; Robert Raszuk
Cc: Christian Hopps;
draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg)
;lsr@ietf.org;
lsr-...@ietf.org; Acee Lindem (acee)
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 suppor

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

2020-09-11 Thread olivier.dugeon

Hi all,

Well, re-reading again the draft, I'm finally a bit confused about this thread 
around the metric. If I correctly summarise, the goal of this draft is to 
standardised flex algo, and consequently, new opcode allocated by IANA that are 
convey in IS-IS and OSPF. Looking to IANA section, let me think that the major 
point is to be agree on code point to specify algo and for SID, reference to a 
particular algo.

So, IETF is standardized protocol, not architecture, nor algorithm. So, the way 
a router compute nexthop route for flex algo X is normally out of scope of the 
draft. Thus, for delay or TE flex algo, an implementer would be free to pick 
delay or TE metric to compute the nexthop route. What must be standardized for 
interoperability purpose if the code point to convey flex algo value. Indeed, 
the metrics value used by the router are completely orthogonal from the flex 
algo code point and the algorithm that compute the route. For example, a flex 
algo could used legacy metric or new ALSA announce by the IGP itself or a 
static value configured locally or through a management system.

In fact, I'm referring to PCE and PCEP protocol which more or less do the same 
thing i.e. compute a route based on topology and metrics. In any RFCs related 
to  PCE you will find a mention about how PCE must acquire the topology and a 
specific metric. it is up to the implementer. This is the same for the various 
algorithm. Only objective functions are standardized and only code point to 
convey metrics in PCEP Request and Response are standardized.

So, I'm a bit surprised that this draft *impose* the origin of the metric for 
the flex algo route computation and not be more flexible letting the 
implementer free to select metrics from which it would. And don't argue that it 
is for interoperability (the draft will not define how to convey metric used by 
flex algo) nor to achieve a global coherent route as each router take a local 
decision to compute nexthop router which absolutely doesn't guarantee that the 
route follow by a packet from A to Z is the shortest from a TE metric or a 
delay metric. Only a central path computation e.g. with a PCE could guarantee 
that.

Regards

Olivier

Le 03/09/2020 à 14:49, Van De Velde, Gunter (Nokia - BE/Antwerp) a écrit :
> 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  
> Sent: Thursday, September 3, 2020 12:02
> To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
> ; Selderslaghs, Rudy (Nokia - BE/Antwerp) 
> ; Shraddha Hegde ; 
> olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; Acee Lindem (acee) 
> 
> 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
>>>

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

2020-09-08 Thread Christian Hopps



> On Sep 7, 2020, at 11:43 PM, Shraddha Hegde 
>  wrote:
> 
> Peter,
> 
> 
> Thanks for the conclusion on adding L-bit clarification in the 
> draft-ietf-lsr-flex-algo.
> 
> Snip to open comments.
> 
>> 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-
>   >gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$ , 
> which only supported the >  >include/exclude Admin Groups, clearly stated:
> 
> https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
> https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/
> 
> https://mailarchive.ietf.org/arch/browse/lsr/?q=LSR%20Working%20Group%20Adoption%20Poll%20for%20Flex%20Algorithm%20Drafts
> 
> The above two drafts were polled for WG adoption. These two drafts did not 
> have any reference to te-app draft.
> 
> There was no discussion in the WG about ASLA TLV during the adoption call. 
> When the WG adopted draft was posted, that merged the ISIS and OSPF drafts 
> and the non-backward compatible text mandating ASLA TLV was introduced. The 
> link to this draft, you have copied in the mail above.
> 
> 
> I think it is fair to warn the operators on the possible inter-op issues this 
> could cause.
> I would like to see the above sentence added to the draft.

Hi Shraddha,


I believe that early code-point allocations were made in June 2018 after the 
publication of the -00 WG document. If behavioral changes had been made after 
the early allocation I think you might have a case to make about adding 
warnings; however, it does not appear to be the case here, unless I've missed 
something.

Thanks,
Chris.
[chair hat]

> 
> 
> Rgds
> Shraddha
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Thursday, September 3, 2020 1:25 PM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; Acee 
> Lindem (acee) 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> 
> [External Email. Be cautious of content]
> 
> 
> 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$
>  , 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
> 
> 
> 
>> ====

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

2020-09-08 Thread Van De Velde, Gunter (Nokia - BE/Antwerp)

Flex-algo application MUST be able to encode flex-algo link attributes using 
valid ASLA for flex-algo.
Flex-algo application MUST be able to decode flex-algo link attributes using 
valid ASLA for flex-algo.

A valid IS-IS ASLA may be encoded with L-bit SET or UNSET. The setting of L-bit 
is a choice from the flex-algo application implementation and/or encoding 
capabilities.
A flex-algo node MUST NOT make assumption on the L-bit encoding capabilities of 
any other flex-algo, and SHOULD expect to receive valid ASLA encodings from 
other flex-algo nodes.

I agree with Peter to adhere flex-algo implementations as documented in latest 
WG document. 

G/

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Tuesday, September 8, 2020 10:53
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Shraddha,

when documents get adopted by the WG when they are still subject to changes. 
Based on WG feedback and implementation experience the drafts evolve to the 
point where they are considered mature and stable. Then they are ready to 
become RFCs and be used as the standard definition to be followed by 
interoperable implementations. Earlier versions are simply steps on the way.

For whatever reason, you and your company have apparently chosen NOT to have 
your flex-algo implementation adhere to the draft as it has been defined in the 
latest WG document. That is your choice. But I do not think you have the right 
to ask the IETF to document this proprietary choice and by doing so imply that 
this is a supported variation endorsed by the IETF.

thanks,
Peter

On 08/09/2020 05:43, Shraddha Hegde wrote:
> Peter,
> 
> 
> Thanks for the conclusion on adding L-bit clarification in the 
> draft-ietf-lsr-flex-algo.
> 
> Snip to open comments.
> 
>> 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-
>   >gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$ , 
> which only supported the >  >include/exclude Admin Groups, clearly stated:
> 
> https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
> https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/
> 
> https://mailarchive.ietf.org/arch/browse/lsr/?q=LSR%20Working%20Group%
> 20Adoption%20Poll%20for%20Flex%20Algorithm%20Drafts
> 
> The above two drafts were polled for WG adoption. These two drafts did not 
> have any reference to te-app draft.
> 
> There was no discussion in the WG about ASLA TLV during the adoption call. 
> When the WG adopted draft was posted, that merged the ISIS and OSPF drafts 
> and the non-backward compatible text mandating ASLA TLV was introduced. The 
> link to this draft, you have copied in the mail above.
> 
> 
> I think it is fair to warn the operators on the possible inter-op issues this 
> could cause.
> I would like to see the above sentence added to the draft.
> 
> 
> Rgds
> Shraddha
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Thursday, September 3, 2020 1:25 PM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; 
> Acee Lindem (acee) 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> 
> [External Email. Be cautious of content]
> 
> 
> 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

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

2020-09-08 Thread bruno.decraene

Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> please see inline:
> 
> On 07/09/2020 17:31, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Thursday, September 3, 2020 9:55 AM
> >>
> >> 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,
> >
> > Yes please. (It's not clear to me whether "can add" means "will add" or
> "could add". So better safe than sorry).
> >
> > Also in §5.1:
> >
> > " 1: Min Unidirectional Link Delay as defined in [RFC8570],
> >   section 4.2, encoded in the Application Specific Link
> >   Attributes Sub-TLV [I-D.ietf-isis-te-app]."
> >
> > It could be read as the delay (value) needs to be encoded in the ASLA
> Attributes Sub-TLV, while when the L-bit is set, the delay (value) is encoded
> in the RFC8570 sub-TLV.
> > So in order to avoid interop issues, I'd appreciate if you could clarify.
> > May be :s/in/as per
> > Or :s/./or in the RFC8570 Sub-TLV when the ASLA L-Flag is set.
> > Or whatever change at your preference.
> 
> 
> what about:
> 
> "Min Unidirectional Link Delay as defined in [RFC8570],
>   section 4.2, encoded as specified in [I-D.ietf-isis-te-app]."
> 
> That covers the L-bit with delay in legacy TLV.

Looks good.

Thank you.

--Bruno

> >
> > Then same comment for Metric-Type 2 (TE Metric), in the next sentence.
> 
> sure.
> 
> thanks,
> Peter
> 
> >
> >
> > Thank you,
> > Regards,
> > --Bruno
> >
> >
> >> 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 
> >>> Sent: Wednesday, September 2, 2020 2:43 PM
> >>> To: Shraddha Hegde ;
> >> olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk
> >> 
> >>> Cc: Christian Hopps ; draf

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

2020-09-08 Thread Peter Psenak


Hi Bruno,

please see inline:

On 07/09/2020 17:31, bruno.decra...@orange.com wrote:

Hi Peter,


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 9:55 AM

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,


Yes please. (It's not clear to me whether "can add" means "will add" or "could 
add". So better safe than sorry).

Also in §5.1:

" 1: Min Unidirectional Link Delay as defined in [RFC8570],
  section 4.2, encoded in the Application Specific Link
  Attributes Sub-TLV [I-D.ietf-isis-te-app]."

It could be read as the delay (value) needs to be encoded in the ASLA 
Attributes Sub-TLV, while when the L-bit is set, the delay (value) is encoded 
in the RFC8570 sub-TLV.
So in order to avoid interop issues, I'd appreciate if you could clarify.
May be :s/in/as per
Or :s/./or in the RFC8570 Sub-TLV when the ASLA L-Flag is set.
Or whatever change at your preference.



what about:

"Min Unidirectional Link Delay as defined in [RFC8570],
 section 4.2, encoded as specified in [I-D.ietf-isis-te-app]."

That covers the L-bit with delay in legacy TLV.



Then same comment for Metric-Type 2 (TE Metric), in the next sentence.


sure.

thanks,
Peter




Thank you,
Regards,
--Bruno



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 
Sent: Wednesday, September 2, 2020 2:43 PM
To: Shraddha Hegde ;

olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk


Cc: Christian Hopps ; draft-ietf-lsr-flex-

algo@ietf.org; Les Ginsberg (ginsberg)
; lsr@ietf.org; lsr-...@ietf.org;
Acee Lindem (acee) 

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

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

2020-09-08 Thread Peter Psenak

Hi Shraddha,

when documents get adopted by the WG when they are still subject to 
changes. Based on WG feedback and implementation experience the drafts 
evolve to the point where they are considered mature and stable. Then 
they are ready to become RFCs and be used as the standard definition to 
be followed by interoperable implementations. Earlier versions are 
simply steps on the way.

For whatever reason, you and your company have apparently chosen NOT to 
have your flex-algo implementation adhere to the draft as it has been 
defined in the latest WG document. That is your choice. But I do not 
think you have the right to ask the IETF to document this proprietary 
choice and by doing so imply that this is a supported variation endorsed 
by the IETF.

thanks,
Peter

On 08/09/2020 05:43, Shraddha Hegde wrote:

Peter,

Thanks for the conclusion on adding L-bit clarification in the 
draft-ietf-lsr-flex-algo.

Snip to open comments.

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://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-
   >gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$ , which only 
supported the >>include/exclude Admin Groups, clearly stated:

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/

https://mailarchive.ietf.org/arch/browse/lsr/?q=LSR%20Working%20Group%20Adoption%20Poll%20for%20Flex%20Algorithm%20Drafts

The above two drafts were polled for WG adoption. These two drafts did not have 
any reference to te-app draft.

There was no discussion in the WG about ASLA TLV during the adoption call. When 
the WG adopted draft was posted, that merged the ISIS and OSPF drafts and the 
non-backward compatible text mandating ASLA TLV was introduced. The link to 
this draft, you have copied in the mail above.

I think it is fair to warn the operators on the possible inter-op issues this 
could cause.
I would like to see the above sentence added to the draft.

Rgds
Shraddha

Juniper Business Use Only

-Original Message-
From: Peter Psenak 
Sent: Thursday, September 3, 2020 1:25 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; Les 
Ginsberg (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[External Email. Be cautious of content]

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://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$
 , 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 
Sent: Wednesday, September 2, 2020 2:43 PM
To: Shraddha Hegde ; olivier.dug...@orange.com;
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ;
d

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

2020-09-07 Thread Shraddha Hegde

Peter,

Thanks for the conclusion on adding L-bit clarification in the 
draft-ietf-lsr-flex-algo.

Snip to open comments.

> 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-
  >gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$ , 
which only supported the >  >include/exclude Admin Groups, clearly stated:

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/

https://mailarchive.ietf.org/arch/browse/lsr/?q=LSR%20Working%20Group%20Adoption%20Poll%20for%20Flex%20Algorithm%20Drafts

The above two drafts were polled for WG adoption. These two drafts did not have 
any reference to te-app draft.

There was no discussion in the WG about ASLA TLV during the adoption call. When 
the WG adopted draft was posted, that merged the ISIS and OSPF drafts and the 
non-backward compatible text mandating ASLA TLV was introduced. The link to 
this draft, you have copied in the mail above.

I think it is fair to warn the operators on the possible inter-op issues this 
could cause.
I would like to see the above sentence added to the draft.

Rgds
Shraddha

Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Thursday, September 3, 2020 1:25 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[External Email. Be cautious of content]

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://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$
 , 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 
> Sent: Wednesday, September 2, 2020 2:43 PM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; 
> Acee Lindem (acee) 
> 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

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

2020-09-07 Thread bruno.decraene

Hi Peter,

> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 9:55 AM
> 
> 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, 

Yes please. (It's not clear to me whether "can add" means "will add" or "could 
add". So better safe than sorry).

Also in §5.1:

" 1: Min Unidirectional Link Delay as defined in [RFC8570],
 section 4.2, encoded in the Application Specific Link
 Attributes Sub-TLV [I-D.ietf-isis-te-app]."

It could be read as the delay (value) needs to be encoded in the ASLA 
Attributes Sub-TLV, while when the L-bit is set, the delay (value) is encoded 
in the RFC8570 sub-TLV.
So in order to avoid interop issues, I'd appreciate if you could clarify.
May be :s/in/as per
Or :s/./or in the RFC8570 Sub-TLV when the ASLA L-Flag is set.
Or whatever change at your preference. 

Then same comment for Metric-Type 2 (TE Metric), in the next sentence.


Thank you,
Regards,
--Bruno


> 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 
> > Sent: Wednesday, September 2, 2020 2:43 PM
> > To: Shraddha Hegde ;
> olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk
> 
> > Cc: Christian Hopps ; draft-ietf-lsr-flex-
> algo@ietf.org; Les Ginsberg (ginsberg)
> ; lsr@ietf.org; lsr-...@ietf.org;
> Acee Lindem (acee) 
> > 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

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

2020-09-03 Thread Peter Psenak


Gunter,

On 03/09/2020 14:49, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:

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.


because the draft-ietf-isis-te-app allows it.



* 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


not really. Flex-algo draft simply refers to draft-ietf-isis-te-app, 
which allows L-bit (with legacy adv) to be used for any application.
There are vendors that have implemented flex-algo this way and we MUST 
be able to interoperate.


thanks,
Peter


(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 
Sent: Thursday, September 3, 2020 12:02
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; Selderslaghs, Rudy 
(Nokia - BE/Antwerp) ; Shraddha Hegde ; 
olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; Les 
Ginsberg (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; Acee Lindem 
(acee) 
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  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 11:19
To: Selderslaghs, Rudy (Nokia - BE/Antwerp)
; Peter Psenak
; Shraddha Hegde
; olivier.dug...@orange.com; tony...@tony.li;
Robert Raszuk 
Cc: Christian Hopps ;
draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg)
; lsr@ietf.org; lsr-...@ietf.org;
Acee Lindem (acee) 
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 attri

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

2020-09-03 Thread Van De Velde, Gunter (Nokia - BE/Antwerp)

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  
Sent: Thursday, September 3, 2020 12:02
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
Selderslaghs, Rudy (Nokia - BE/Antwerp) ; Shraddha 
Hegde ; olivier.dug...@orange.com; tony...@tony.li; 
Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 
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  On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 11:19
> To: Selderslaghs, Rudy (Nokia - BE/Antwerp) 
> ; Peter Psenak 
> ; Shraddha Hegde 
> ; olivier.dug...@orange.com; tony...@tony.li; 
> Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo....@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; 
> Acee Lindem (acee) 
> 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 at

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

2020-09-03 Thread Selderslaghs, Rudy (Nokia - BE/Antwerp)

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.
This can only be used for RSVP-TE, SR-Policy and LFA as specified in chapter 
6.1.

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.

Chapter 4.2. states that ASLA TLV with L-bit set means "using legacy 
advertisements":
   ...
   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  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 9:55 AM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
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 
> Sent: Wednesday, September 2, 2020 2:43 PM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo....@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; Acee 
> Lindem (acee) 
> 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 ye

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

2020-09-03 Thread Peter Psenak


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  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 11:19
To: Selderslaghs, Rudy (Nokia - BE/Antwerp) ; Peter Psenak 
; Shraddha Hegde ; 
olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; Les 
Ginsberg (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 
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  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 9:55 AM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; Les 
Ginsberg (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 
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 mand

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

2020-09-03 Thread Van De Velde, Gunter (Nokia - BE/Antwerp)

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.

So in my opinion the draft is saying the opposite and legacy advertisements 
MUST NOT be used for flex-algo.
Hence, I suggest that we should make it explicit clear that L-bit set for 
flex-algo is MUST NOT be allowed.

G/




-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 11:19
To: Selderslaghs, Rudy (Nokia - BE/Antwerp) ; 
Peter Psenak ; Shraddha Hegde 
; olivier.dug...@orange.com; tony...@tony.li; Robert 
Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
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  On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 9:55 AM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo....@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; Acee 
> Lindem (acee) 
> 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 defin

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

2020-09-03 Thread Peter Psenak


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  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 9:55 AM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; Les 
Ginsberg (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 
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 
Sent: Wednesday, September 2, 2020 2:43 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; Les 
Ginsberg (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 
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
attrib

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

2020-09-03 Thread Peter Psenak


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 
Sent: Wednesday, September 2, 2020 2:43 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; Les 
Ginsberg (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 
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

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

2020-09-02 Thread Shraddha Hegde

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  
Sent: Wednesday, September 2, 2020 2:43 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
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 
> Sent: Thursday, August 27, 2020 3:34 PM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; 
> Acee Lindem (acee) 
> Subject: Re: [Lsr] WG Last Call for dr

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

2020-09-02 Thread Peter Psenak


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 
Sent: Thursday, August 27, 2020 3:34 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; Les 
Ginsberg (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 
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-jnYKFPl7DWC_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-isis-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_09_HTtuT$
  and 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_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 mont

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

2020-09-01 Thread Shraddha Hegde

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.  

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.

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.

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.
Implementations from a year ago may not interoperate with published RFC.

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,
 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  
Sent: Thursday, August 27, 2020 3:34 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
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-jnYKFPl7DWC_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-isis-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_09_HTtuT$
  and 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_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 o

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

2020-08-27 Thread Peter Psenak


Hi Shraddha,

draft-ietf-lsr-flex-algo-00 was published May 15, 2018 (over two years 
ago). 




It clearly stated:

https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00#section-9

"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://tools.ietf.org/html/draft-ietf-isis-te-app-19 and 
https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/ 
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:*olivier.dug...@orange.com 
*Sent:* Thursday, August 20, 2020 7:56 PM
*To:* Peter Psenak ; tony...@tony.li; Robert Raszuk 

*Cc:* Christian Hopps ; 
draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 

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

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

2020-08-25 Thread Shraddha Hegde

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 
Sent: Thursday, August 20, 2020 7:56 PM
To: Peter Psenak ; tony...@tony.li; Robert Raszuk 

Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
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 on

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

2020-08-20 Thread tony . li


I have reviewed the change in -10 and it seems fine to me.  Objection 
withdrawn. I support publication.

Tony


> On Aug 17, 2020, at 4:47 PM, tony...@tony.li wrote:
> 
> 
> 
>> This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
>> draft-ietf-lsr-flex-algo
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/
> 
> 
> 
> Hi,
> 
> I’d like to raise an objection.
> 
> Recently, I requested (and I thought that Peter agreed to) a clarification of 
> the Min Unidirectional Link Delay.
> 
> As of version -08, the draft references RFC 7810 for the Metric-type in 
> Section 5.1.  
> 
> That RFC defines both a “Unidirectional Link Delay” (section 4.1) and 
> “Min/Max Unidirectional Link Delay” (section 4.2).
> 
> I requested that the reference be extended to specify the section.
> 
> Instead, as of -09, the reference has been changed to refer to 
> ietf-isis-te-app.  This is somewhat helpful becuase it makes it clear that 
> this should be found
> in the Application Specific Link Attributes Sub-TLV, but it still does not 
> resolve the ambiguity of which sub-sub-TLV should be used.
> 
> I would again request that this be clarified.  Proposed text:
> 
>   1: Min Unidirectional Link Delay as defined in [RFC 7810], section 4.2, 
> encoded in the Application Specific Link Attributes Sub-TLV 
> [I-D.ietf-isis-te-app].
> 
> 
> Thank you.
> 
> Regards,
> Tony
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2020-08-20 Thread Peter Psenak

s 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)
<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 mailto:lsr-boun...@ietf.org>>
*On Behalf Of *tony...@tony.li <mailto:tony...@tony.li>
*Sent:* Tuesday, August 18, 2020 7:44 AM
*To:* Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
*Cc:* lsr@ietf.org <mailto:lsr@ietf.org>; lsr-...@ietf.org
<mailto:lsr-...@ietf.org>; Christian Hopps mailto:cho...@chopps.org>>; Acee Lindem (acee) mailto:a...@cisco.com>>; draft-ietf-lsr-flex-algo....@ietf.org
<mailto:draft-ietf-lsr-flex-algo@ietf.org>
*Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Peter,

section 5.1 of the draft-ietf-lsr-flex-algo says:

Min Unidirectional Link Delay as defined in
[I-D.ietf-isis-te-app].

We explicitly say "Min Unidirectional Link Delay", so this
cannot be mixed with other delay values (max, average).

The problem is that that does not exactly match “Unidirectional
Link Delay” or “Min/Max Unidirectional Link Delay”, leading to
the ambiguity. Without a clear match, you leave things open to
people guessing. Now, it’s a metriic, so of course, you always
want to take the min. So type 33 seems like a better match.

section 7.3. of ietf-isis-te-app says:

Type Description Encoding
Reference
-
34 Min/Max Unidirectional Link Delay RFC8570

And it also says:

33 Unidirectional Link Delay RFC8570
<https://tools.ietf.org/html/rfc8570>

This does not help.

So, IMHO what we have now is correct and sufficient, but I
have no issue adding the text you proposed below.

What you have now is ambiguous. We have a responsibility, as
writers of specifications, to be precise and clear. We are not
there yet.

BTW, before I posted 09 version of flex-algo draft, I asked
if you were fine with just referencing ietf-isis-te-app in
5.1. I thought you were, as you did not indicate otherwise.

My bad, I should have pressed the issue.

Anyway, I consider this as a pure editorial issue and
hopefully not something that would cause you to object
the WG

LC of the flex-algo draft.

I’m sorry, I think that this is trivially resolved, but
important

clarification.

You also have an author’s email that is bouncing, so at least
one

more spin is required.

Sorry,

Tony

___
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

--
Orange logo <http://www.orange.com>

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dug...@orange.com <mailto:olivier.dug...@orange.com>

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous
avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques et

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

2020-08-20 Thread olivier.dugeon

>>>
>>>>> Tony
>>>>>
>>>>>
>>>>>> On Aug 18, 2020, at 9:22 AM, Robert Raszuk >>>>> <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) 
>>>>>> >>>>> <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 mailto:lsr-boun...@ietf.org>>
>>>>>>     *On Behalf Of *tony...@tony.li <mailto:tony...@tony.li>
>>>>>>     *Sent:* Tuesday, August 18, 2020 7:44 AM
>>>>>>     *To:* Peter Psenak (ppsenak) >>>>> <mailto:ppse...@cisco.com>>
>>>>>>     *Cc:* lsr@ietf.org <mailto:lsr@ietf.org>; lsr-...@ietf.org
>>>>>> <mailto:lsr-...@ietf.org>; Christian Hopps >>>>> <mailto:cho...@chopps.org>>; Acee Lindem (acee) >>>>> <mailto:a...@cisco.com>>; draft-ietf-lsr-flex-algo@ietf.org
>>>>>> <mailto:draft-ietf-lsr-flex-algo@ietf.org>
>>>>>>     *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>>>>>>
>>>>>>     Hi Peter,
>>>>>>
>>>>>>
>>>>>>
>>>>>>     section 5.1 of the draft-ietf-lsr-flex-algo says:
>>>>>>
>>>>>>
>>>>>>     Min Unidirectional Link Delay as defined in
>>>>>>     [I-D.ietf-isis-te-app].
>>>>>>
>>>>>>     We explicitly say "Min Unidirectional Link Delay", so this
>

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

2020-08-20 Thread Peter Psenak

think Peter has been very clear.

Please explain how you managed to end up at code point 33??

Les

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

section 7.3. of ietf-isis-te-app says:

Type Description Encoding
Reference
-
34 Min/Max Unidirectional Link Delay RFC8570

And it also says:

33 Unidirectional Link Delay RFC8570
<https://tools.ietf.org/html/rfc8570>

This does not help.

So, IMHO what we have now is correct and sufficient, but I
have no issue adding the text you proposed below.

What you have now is ambiguous. We have a responsibility, as
writers of specifications, to be precise and clear. We are not
there yet.

BTW, before I posted 09 version of flex-algo draft, I asked
if you were fine with just referencing ietf-isis-te-app in
5.1. I thought you were, as you did not indicate otherwise.

My bad, I should have pressed the issue.

Anyway, I consider this as a pure editorial issue and
hopefully not something that would cause you to object the WG
LC of the flex-algo draft.

I’m sorry, I think that this is trivially resolved, but important
clarification.

You also have an author’s email that is bouncing, so at least one
more spin is required.

Sorry,

Tony

___
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

--
Orange logo <http://www.orange.com>

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dug...@orange.com <mailto:olivier.dug...@orange.com>

This message and its attachments may contain confidential or
privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender
and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.

Thank you.

--
Orange logo <http://www.orange.com>

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dug...@orange.com <mailto:olivier.dug...@orange.com>

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alt

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

2020-08-20 Thread olivier.dugeon

    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 mailto:lsr-boun...@ietf.org>>
>>>>     *On Behalf Of *tony...@tony.li <mailto:tony...@tony..li>
>>>>     *Sent:* Tuesday, August 18, 2020 7:44 AM
>>>>     *To:* Peter Psenak (ppsenak) >>>     <mailto:ppse...@cisco.com>>
>>>>     *Cc:* lsr@ietf.org <mailto:lsr@ietf.org>; lsr-...@ietf.org
>>>>     <mailto:lsr-...@ietf.org>; Christian Hopps >>>     <mailto:cho...@chopps.org>>; Acee Lindem (acee) >>>     <mailto:a...@cisco.com>>; draft-ietf-lsr-flex-algo@ietf.org
>>>>     <mailto:draft-ietf-lsr-flex-algo@ietf.org>
>>>>     *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>>>>
>>>>     Hi Peter,
>>>>
>>>>
>>>>
>>>>     section 5.1 of the draft-ietf-lsr-flex-algo says:
>>>>
>>>>
>>>>     Min Unidirectional Link Delay as defined in
>>>>     [I-D.ietf-isis-te-app].
>>>>
>>>>     We explicitly say "Min Unidirectional Link Delay", so this
>>>>     cannot be mixed with other delay values (max, average).
>>>>
>>>>     The problem is that that does not exactly match “Unidirectional
>>>>     Link Delay” or “Min/Max Unidirectional Link Delay”, leading to
>>>>     the ambiguity. Without a clear match, you leave things open to
>>>>     people guessing. Now, it’s a metriic, so of course, you always
>>>>     want to take the min.  So type 33 seems like a better match.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     section 7.3. of ietf-isis-te-app says:
>>>>
>>>>     Type   Description  Encoding
>>>>        Reference
>>>>     -
>>>>     34  Min/Max Unidirectional Link Delay    RFC8570
>>>>
>>>>     And it also says:
>>>>
>>>>     33  Unidirectional Link Delay RFC8570
>>>>     <https://tools.ietf.org/html/rfc8570>
>>>>
>>>>     This does not help.
>>>>
>>>>
>>>>
>>>>     So, IMHO what we have now is correct and sufficient, but I
>>>>     have no issue adding the text you proposed below.
>>>>
>>>>     What you have now is ambiguous. We have a responsibility, as
>>>>     writers of specifications, to be precise and clear.  We are not
>>>>     there yet.
>>>>
>>>>
>>>>
>>>>     BTW, before I posted 09 version of flex-algo draft, I asked
>>>>     if you were fine with just referencing ietf-isis-te-app in
>>>>     5.1. I thought you were, as you did not indicate otherwise.
>>>>
>>>>     My bad, I should have pressed the issue.
>>>>
>>>>
>>>>
>>>>     Anyway, I consider this as a pure editorial issue and
>>>>     hopefully not something that would cause you to object the WG
>>>>     LC of the flex-algo draft.
>>>>
>>>>     I’m sorry, I think that this is trivially resolved, but important
>>>>     clarification.
>>>>
>>>>     You also have an author’s email that is bouncing, so at least one
>>>>     more spin is required.
>>>>
>>>>     Sorry,
>>>>
>>>>     Tony
>>>>
>>>>     ___
>>>>     Lsr mailing list
>>>>     Lsr@ietf.org <mailto:Lsr@ietf.org>
>>>>     https://www.ietf.org/mailman/listinfo/lsr
>>>
>>>
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https:

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

2020-08-19 Thread Peter Psenak

Olivier,

On 19/08/2020 13:42, olivier.dug...@orange.com 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, 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 <mailto:rob...@raszuk.net>> wrote:

Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:

TypeDescription

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

Hi Peter,

section 5.1 of the draf

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

2020-08-19 Thread olivier.dugeon

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 about reference 
to RFC7471 for OSPF ? 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).

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 ?

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.

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.

Regards

Olivier

Le 18/08/2020 à 19:02, tony...@tony.li a écrit :
>
> Robert,
>
> Thank you, exactly.
>
> We just need a clarification of the document.  I don’t understand why this is 
> such a big deal.
>
> Tony
>
>
>> On Aug 18, 2020, at 9:22 AM, Robert Raszuk > <mailto:rob...@raszuk.net>> wrote:
>>
>> Les,
>>
>> I think this is not very obvious as Tony is pointing out. 
>>
>> See RFC 8570 says: 
>>
>>   TypeDescription
>>   
>>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) 
>> 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 mailto:lsr-boun...@ietf.org>> *On 
>> Behalf Of * tony...@tony.li <mailto:tony...@tony.li>
>> *Sent:* Tuesday, August 18, 2020 7:44 AM
>> *To:* Peter Psenak (ppsenak) > <mailto:ppse...@cisco.com>>
>> *Cc:* lsr@ietf.org <mailto:lsr@ietf.org>; lsr-...@ietf.org 
>> <mailto:lsr-...@ietf.org>; Christian Hopps > <mailto:cho...@chopps.org>>; Acee Lindem (acee) > <mailto:a...@cisco.com>>; draft-ietf-lsr-flex-algo@ietf.org 
>> <mailto:draft-ietf-lsr-flex-algo@ietf.org>
>> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>>
>>  
>>
>>  
>>
>> Hi Peter,
>>
>>  
>>
>>
>>
>

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

2020-08-18 Thread Les Ginsberg (ginsberg)

Tony –

I am not “fighting”.
I just found your interpretation very hard to follow.

Moving on…

   Les


From: Tony Li  On Behalf Of tony...@tony.li
Sent: Tuesday, August 18, 2020 12:33 PM
To: Les Ginsberg (ginsberg) 
Cc: Robert Raszuk ; Christian Hopps ; 
draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
; lsr@ietf.org; lsr-...@ietf.org; Acee 
Lindem (acee) ; Peter Psenak (ppsenak) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo


Les,

There is no TLV called the Min Unidirectional Link Delay.

If the document had said “The min delay of the Min/Max Unidirectional Link 
Delay” then there would be no confusion.

Instead, it is the sloppy writing of ignoring the full name of the TLV that has 
created ambiguity.

Now, Peter has agreed to make a clarification, so:

  Why are we still fighting?

Tony



On Aug 18, 2020, at 12:18 PM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Tony/Robert –

Whatever clarification Peter may choose to make would be fine – but I do 
question your casual ignoring of adjectives. 😊

There are three values being advertised:

33 - Unidirectional Link Delay
34 – Min/Max Unidirectional Link Delay
 Meaning two values are advertised in this codepoint:
 Min Unidirectional Link Delay
 Max Unidirectional Link Delay

Now, the flex algo draft states: Min Unidirectional Link Delay

If you want to argue that “Min Unidirectional Link Delay” != “Min/Max 
Unidirectional Link Delay” – I think you are pedantically correct.

But how that leads you to simply truncate “Min” and conclude that this is 
really “Unidirectional Link Delay” is a leap that I cannot follow.

Perhaps you don’t really like the fact that RFC 8570 encoding combined Min/Max 
in a single codepoint – but that ship sailed years ago.

Given that RFC 8570 is very clear in showing that the encoding includes:


   0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type| Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED|   Min Delay   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   RESERVED|   Max Delay   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


my ability to see your POV is somewhat limited.

Perhaps you could own that a more careful reading is possible?

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
tony...@tony.li<mailto:tony...@tony.li>
Sent: Tuesday, August 18, 2020 10:03 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; 
draft-ietf-lsr-flex-algo@ietf.org<mailto:draft-ietf-lsr-flex-algo@ietf.org>;
 Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 lsr@ietf.org<mailto:lsr@ietf.org>; lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 
Acee Lindem (acee) mailto:a...@cisco.com>>; Peter Psenak 
(ppsenak) mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo


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 
mailto:rob...@raszuk.net>> wrote:

Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:


  TypeDescription

  

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

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

2020-08-18 Thread tony . li


Les,

There is no TLV called the Min Unidirectional Link Delay.   

If the document had said “The min delay of the Min/Max Unidirectional Link 
Delay” then there would be no confusion.

Instead, it is the sloppy writing of ignoring the full name of the TLV that has 
created ambiguity.

Now, Peter has agreed to make a clarification, so:

Why are we still fighting?

Tony


> On Aug 18, 2020, at 12:18 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> Tony/Robert –
>  
> Whatever clarification Peter may choose to make would be fine – but I do 
> question your casual ignoring of adjectives. 😊
>  
> There are three values being advertised:
>  
> 33 - Unidirectional Link Delay
> 34 – Min/Max Unidirectional Link Delay 
>  Meaning two values are advertised in this codepoint:
>  Min Unidirectional Link Delay
>  Max Unidirectional Link Delay
>  
> Now, the flex algo draft states: Min Unidirectional Link Delay
>  
> If you want to argue that “Min Unidirectional Link Delay” != “Min/Max 
> Unidirectional Link Delay” – I think you are pedantically correct.
>  
> But how that leads you to simply truncate “Min” and conclude that this is 
> really “Unidirectional Link Delay” is a leap that I cannot follow.
>  
> Perhaps you don’t really like the fact that RFC 8570 encoding combined 
> Min/Max in a single codepoint – but that ship sailed years ago.
>  
> Given that RFC 8570 is very clear in showing that the encoding includes:
>  
> 
>0   1   2   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   Type| Length|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |A| RESERVED|   Min Delay   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   RESERVED|   Max Delay   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>  
> my ability to see your POV is somewhat limited.
>  
> Perhaps you could own that a more careful reading is possible?
>  
>Les
>  
>  
> From: Lsr  On Behalf Of tony...@tony.li
> Sent: Tuesday, August 18, 2020 10:03 AM
> To: Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo....@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; Acee 
> Lindem (acee) ; Peter Psenak (ppsenak) 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>  
>  
> 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  <mailto:rob...@raszuk.net>> wrote:
>  
> Les,
>  
> I think this is not very obvious as Tony is pointing out. 
>  
> See RFC 8570 says: 
>  
>   TypeDescription
>   
>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) 
> 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 mailto:lsr-boun...@ietf.org>> On Behalf Of 
> tony

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

2020-08-18 Thread Robert Raszuk

Les,

> and conclude that this is really “Unidirectional Link Delay” is a leap
that I cannot follow.

I would never suggest to do that.

My suggestion was to rename "Min Unidirectional Link Delay" to "minimum
value of Min/Max Unidirectional Link Delay" and move on.

Cheers,
R.



On Tue, Aug 18, 2020 at 9:18 PM Les Ginsberg (ginsberg) 
wrote:

> Tony/Robert –
>
>
>
> Whatever clarification Peter may choose to make would be fine – but I do
> question your casual ignoring of adjectives. 😊
>
>
>
> There are three values being advertised:
>
>
>
> 33 - Unidirectional Link Delay
>
> 34 – Min/Max Unidirectional Link Delay
>
>  Meaning two values are advertised in this codepoint:
>
>  Min Unidirectional Link Delay
>
>  Max Unidirectional Link Delay
>
>
>
> Now, the flex algo draft states: Min Unidirectional Link Delay
>
>
>
> If you want to argue that “Min Unidirectional Link Delay” != “Min/Max
> Unidirectional Link Delay” – I think you are pedantically correct.
>
>
>
> But how that leads you to simply truncate “Min” and conclude that this is
> really “Unidirectional Link Delay” is a leap that I cannot follow.
>
>
>
> Perhaps you don’t really like the fact that RFC 8570 encoding combined
> Min/Max in a single codepoint – but that ship sailed years ago.
>
>
>
> Given that RFC 8570 is very clear in showing that the encoding includes:
>
>
>
> 
>
>0   1   2   3
>
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |   Type| Length|
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |A| RESERVED|   Min Delay   |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |   RESERVED|   Max Delay   |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 
>
>
>
> my ability to see your POV is somewhat limited.
>
>
>
> Perhaps you could own that a more careful reading is possible?
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * tony...@tony.li
> *Sent:* Tuesday, August 18, 2020 10:03 AM
> *To:* Robert Raszuk 
> *Cc:* Christian Hopps ;
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org>; lsr@ietf.org; lsr-...@ietf.org; Acee Lindem
> (acee) ; Peter Psenak (ppsenak) 
> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>
>
>
>
>
> 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  wrote:
>
>
>
> Les,
>
>
>
> I think this is not very obvious as Tony is pointing out.
>
>
>
> See RFC 8570 says:
>
>
>
>   TypeDescription
>
>   
>
>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)  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

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

2020-08-18 Thread Les Ginsberg (ginsberg)

Tony/Robert –

Whatever clarification Peter may choose to make would be fine – but I do 
question your casual ignoring of adjectives. 😊

There are three values being advertised:

33 - Unidirectional Link Delay
34 – Min/Max Unidirectional Link Delay
 Meaning two values are advertised in this codepoint:
 Min Unidirectional Link Delay
 Max Unidirectional Link Delay

Now, the flex algo draft states: Min Unidirectional Link Delay

If you want to argue that “Min Unidirectional Link Delay” != “Min/Max 
Unidirectional Link Delay” – I think you are pedantically correct.

But how that leads you to simply truncate “Min” and conclude that this is 
really “Unidirectional Link Delay” is a leap that I cannot follow.

Perhaps you don’t really like the fact that RFC 8570 encoding combined Min/Max 
in a single codepoint – but that ship sailed years ago.

Given that RFC 8570 is very clear in showing that the encoding includes:


   0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type| Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED|   Min Delay   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   RESERVED|   Max Delay   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


my ability to see your POV is somewhat limited.

Perhaps you could own that a more careful reading is possible?

   Les


From: Lsr  On Behalf Of tony...@tony.li
Sent: Tuesday, August 18, 2020 10:03 AM
To: Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) ; Peter Psenak (ppsenak) 

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


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 
mailto:rob...@raszuk.net>> wrote:

Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:


  TypeDescription

  

   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) 
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 mailto:lsr-boun...@ietf.org>> On Behalf Of 
tony...@tony.li<mailto:tony...@tony.li>
Sent: Tuesday, August 18, 2020 7:44 AM
To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-...@ietf.org<mailto:lsr-...@ietf.org>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; 
draft-ietf-lsr-flex-algo@ietf.org<mailto:draft-ietf-lsr-flex-algo....@ietf.org>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo


Hi Peter,


section 5.1 of the draft-ietf-lsr-flex-algo says:

Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].

We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed with 
other delay values (max, average).


The problem is that that does not exactly match “Unidirectional Link Delay” or 
“Min/Max Unidirectional Link Delay”, leading to the ambiguity. Without a clear 
match, you leave things open to people guessing. Now, it’s a metriic, so of 
course, you always want to take the min.  So type 33 seems like a better match.



section 7.3. of ietf-isis-te-app says:

Type   Description

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

2020-08-18 Thread Peter Psenak


Hi Robert,

On 18/08/2020 19:10, Robert Raszuk wrote:

Hi Tony,

I am not sure what the deal is :)

But fact is that we never defined a type which this draft is referring to

"Min Unidirectional Link Delay" just does not exist in any IANA registry 
so even any search for that will fail.


Perhaps authors assumed that:

Min/Max Unidirectional Link Delay means both "Min Unidirectional Link 
Delay" & "Max Unidirectional Link Delay" but this is just asking 
for ambiguity.


yes, Min/Max Unidirectional Link Delay advertise both Min and Max and we 
use Min out of that.


I'll make the clarification in the draft, so we can close this discussion.

thanks,
Peter



Cheers,
R.

On Tue, Aug 18, 2020 at 7:02 PM > wrote:



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 mailto:rob...@raszuk.net>> wrote:

Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:

   TypeDescription
   
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)
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 mailto:lsr-boun...@ietf.org>> *On Behalf Of *tony...@tony.li

*Sent:* Tuesday, August 18, 2020 7:44 AM
*To:* Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
*Cc:* lsr@ietf.org ; lsr-...@ietf.org
; Christian Hopps mailto:cho...@chopps.org>>; Acee Lindem (acee)
mailto:a...@cisco.com>>;
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


__ __

__ __

Th

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

2020-08-18 Thread Robert Raszuk

Hi Tony,

I am not sure what the deal is :)

But fact is that we never defined a type which this draft is referring to

"Min Unidirectional Link Delay" just does not exist in any IANA registry so
even any search for that will fail.

Perhaps authors assumed that:

Min/Max Unidirectional Link Delay means both "Min Unidirectional Link
Delay" & "Max Unidirectional Link Delay" but this is just asking
for ambiguity.

Cheers,
R.

On Tue, Aug 18, 2020 at 7:02 PM  wrote:

>
> 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  wrote:
>
> Les,
>
> I think this is not very obvious as Tony is pointing out.
>
> See RFC 8570 says:
>
>   TypeDescription
>   
>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)  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  *On Behalf Of * tony...@tony.li
>> *Sent:* Tuesday, August 18, 2020 7:44 AM
>> *To:* Peter Psenak (ppsenak) 
>> *Cc:* lsr@ietf.org; lsr-...@ietf.org; Christian Hopps ;
>> Acee Lindem (acee) ;
>> 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 DelayRFC8570
>>
>>
>>
>>
>>
>> And it also says:
>>
>>
>>
>> 33  Unidirectional Link DelayRFC8570 
>> <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.
>>
&

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

2020-08-18 Thread tony . li


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  wrote:
> 
> Les,
> 
> I think this is not very obvious as Tony is pointing out. 
> 
> See RFC 8570 says: 
> 
>   TypeDescription
>   
>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) 
> 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 mailto:lsr-boun...@ietf.org>> On Behalf Of 
> tony...@tony.li <mailto:tony...@tony.li>
> Sent: Tuesday, August 18, 2020 7:44 AM
> To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
> Cc: lsr@ietf.org <mailto:lsr@ietf.org>; lsr-...@ietf.org 
> <mailto:lsr-...@ietf.org>; Christian Hopps  <mailto:cho...@chopps.org>>; Acee Lindem (acee)  <mailto:a...@cisco.com>>; draft-ietf-lsr-flex-algo@ietf.org 
> <mailto:draft-ietf-lsr-flex-algo@ietf.org>
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> 
>  
> 
>  
> 
> Hi Peter,
> 
>  
> 
> 
> 
> 
> section 5.1 of the draft-ietf-lsr-flex-algo says:
> 
> 
> Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].
> 
> We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed 
> with other delay values (max, average).
> 
>  
> 
>  
> 
> The problem is that that does not exactly match “Unidirectional Link Delay” 
> or “Min/Max Unidirectional Link Delay”, leading to the ambiguity. Without a 
> clear match, you leave things open to people guessing. Now, it’s a metriic, 
> so of course, you always want to take the min.  So type 33 seems like a 
> better match.
> 
> 
> 
> 
> 
> 
> section 7.3. of ietf-isis-te-app says:
> 
> Type   Description  Encoding
>Reference
> -
> 34  Min/Max Unidirectional Link DelayRFC8570
> 
>  
> 
>  
> 
> And it also says:
> 
>  
> 
> 33  Unidirectional Link DelayRFC8570 
> <https://tools.ietf.org/html/rfc8570>
>  
> 
>  
> 
> This does not help.
> 
>  
> 
> 
> 
> 
> So, IMHO what we have now is correct and sufficient, but I have no issue 
> adding the text you proposed below.
> 
>  
> 
>  
> 
> What you have now is ambiguous. We have a responsibility, as writers of 
> specifications, to be precise and clear.  We are not there yet.
> 
>  
> 
> 
> 
> 
> BTW, before I posted 09 version of flex-algo draft, I asked if you were fine 
> with just referencing ietf-isis-te-app in 5.1. I thought you were, as you did 
> not indicate otherwise.
> 
>  
> 
>  
> 
> My bad, I should have pressed the issue.
> 
>  
> 
> 
> 
> 
> Anyway, I consider this as a pure editorial issue and hopefully not something 
> that would cause you to object the WG LC of the flex-algo draft.
> 
>  
> 
>  
> 
> I’m sorry, I think that this is trivially resolved, but important 
> clarification.
> 
>  
> 
> You also have an author’s email that is bouncing, so at least one more spin 
> is required.
> 
>  
> 
> Sorry,
> 
> Tony
> 
>  
> 
> ___
> Lsr mailing list
> Lsr@ietf.org <mailto:Lsr@ietf.org>
> https://www.ietf.org/mailman/listinfo/lsr 
> <https://www.ietf.org/mailman/listinfo/lsr>

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2020-08-18 Thread Robert Raszuk

Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:

  TypeDescription
  
   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)  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  *On Behalf Of * tony...@tony.li
> *Sent:* Tuesday, August 18, 2020 7:44 AM
> *To:* Peter Psenak (ppsenak) 
> *Cc:* lsr@ietf.org; lsr-...@ietf.org; Christian Hopps ;
> Acee Lindem (acee) ; 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 DelayRFC8570
>
>
>
>
>
> And it also says:
>
>
>
> 33  Unidirectional Link DelayRFC8570 
> <https://tools.ietf.org/html/rfc8570>
>
>
>
>
>
> This does not help.
>
>
>
>
>
> So, IMHO what we have now is correct and sufficient, but I have no issue
> adding the text you proposed below.
>
>
>
>
>
> What you have now is ambiguous. We have a responsibility, as writers of
> specifications, to be precise and clear.  We are not there yet.
>
>
>
>
>
> BTW, before I posted 09 version of flex-algo draft, I asked if you were
> fine with just referencing ietf-isis-te-app in 5.1. I thought you were, as
> you did not indicate otherwise.
>
>
>
>
>
> My bad, I should have pressed the issue.
>
>
>
>
>
> Anyway, I consider this as a pure editorial issue and hopefully not
> something that would cause you to object the WG LC of the flex-algo draft..
>
>
>
>
>
> I’m sorry, I think that this is trivially resolved, but important
> clarification.
>
>
>
> You also have an author’s email that is bouncing, so at least one more
> spin is required.
>
>
>
> Sorry,
>
> Tony
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2020-08-18 Thread Les Ginsberg (ginsberg)

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  On Behalf Of tony...@tony.li
Sent: Tuesday, August 18, 2020 7:44 AM
To: Peter Psenak (ppsenak) 
Cc: lsr@ietf.org; lsr-...@ietf.org; Christian Hopps ; Acee 
Lindem (acee) ; 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 DelayRFC8570


And it also says:


33  Unidirectional Link Delay
RFC8570<https://tools.ietf.org/html/rfc8570>


This does not help.



So, IMHO what we have now is correct and sufficient, but I have no issue adding 
the text you proposed below.


What you have now is ambiguous. We have a responsibility, as writers of 
specifications, to be precise and clear.  We are not there yet.



BTW, before I posted 09 version of flex-algo draft, I asked if you were fine 
with just referencing ietf-isis-te-app in 5.1. I thought you were, as you did 
not indicate otherwise.


My bad, I should have pressed the issue.



Anyway, I consider this as a pure editorial issue and hopefully not something 
that would cause you to object the WG LC of the flex-algo draft.


I’m sorry, I think that this is trivially resolved, but important clarification.

You also have an author’s email that is bouncing, so at least one more spin is 
required.

Sorry,
Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2020-08-18 Thread Peter Psenak


Hi Tony,

On 18/08/2020 16:44, tony...@tony.li wrote:


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.


I'm not sure what do you mean by 33. "Min/Max Unidirectional Link Delay" 
is Type 34.


thanks,
Peter






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 DelayRFC8570  



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
https://www.ietf.org/mailman/listinfo/lsr

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

2020-08-18 Thread tony . li


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


And it also says:

33  Unidirectional Link DelayRFC8570 



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
https://www.ietf.org/mailman/listinfo/lsr

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

2020-08-18 Thread Peter Psenak


Hi Chris,

I am not aware of any undisclosed IPR.

thanks,
Peter


On 18/08/2020 01:30, Christian Hoppsprotocol= application/pgp-signature 
wrote:

This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

   https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

   [From 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-flex-algo]

   https://datatracker.ietf.org/ipr/3910/
   https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2020-08-18 Thread Peter Psenak


Hi Tony,

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



section 7.3. of ietf-isis-te-app says:

Type   Description  Encoding
Reference
-
34  Min/Max Unidirectional Link DelayRFC8570


So, IMHO what we have now is correct and sufficient, but I have no issue 
adding the text you proposed below.


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.


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.


thanks,
Peter









On 18/08/2020 01:47, tony...@tony.li wrote:




This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/




Hi,

I’d like to raise an objection.

Recently, I requested (and I thought that Peter agreed to) a clarification of 
the Min Unidirectional Link Delay.

As of version -08, the draft references RFC 7810 for the Metric-type in Section 
5.1.

That RFC defines both a “Unidirectional Link Delay” (section 4.1) and “Min/Max 
Unidirectional Link Delay” (section 4.2).

I requested that the reference be extended to specify the section.

Instead, as of -09, the reference has been changed to refer to 
ietf-isis-te-app.  This is somewhat helpful becuase it makes it clear that this 
should be found
in the Application Specific Link Attributes Sub-TLV, but it still does not 
resolve the ambiguity of which sub-sub-TLV should be used.

I would again request that this be clarified.  Proposed text:

1: Min Unidirectional Link Delay as defined in [RFC 7810], section 4.2, 
encoded in the Application Specific Link Attributes Sub-TLV 
[I-D.ietf-isis-te-app].


Thank you.

Regards,
Tony





___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2020-08-17 Thread Shraddha Hegde

I am not aware of any undisclosed IPR.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Christian Hopps  
Sent: Tuesday, August 18, 2020 5:00 AM
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-...@ietf.org; Acee Lindem (acee) 
; draft-ietf-lsr-flex-algo@ietf.org
Subject: WG Last Call for draft-ietf-lsr-flex-algo

This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2020-08-17 Thread Ketan Talaulikar (ketant)

As a co-author, I am not aware of IPR beyond what has been already disclosed on 
this document.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 18 August 2020 05:00
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-...@ietf.org; Acee Lindem (acee) 
; draft-ietf-lsr-flex-algo@ietf.org
Subject: WG Last Call for draft-ietf-lsr-flex-algo

This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2020-08-17 Thread tony . li



> This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
> draft-ietf-lsr-flex-algo
> 
>  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/



Hi,

I’d like to raise an objection.

Recently, I requested (and I thought that Peter agreed to) a clarification of 
the Min Unidirectional Link Delay.

As of version -08, the draft references RFC 7810 for the Metric-type in Section 
5.1.  

That RFC defines both a “Unidirectional Link Delay” (section 4.1) and “Min/Max 
Unidirectional Link Delay” (section 4.2).

I requested that the reference be extended to specify the section.

Instead, as of -09, the reference has been changed to refer to 
ietf-isis-te-app.  This is somewhat helpful becuase it makes it clear that this 
should be found
in the Application Specific Link Attributes Sub-TLV, but it still does not 
resolve the ambiguity of which sub-sub-TLV should be used.

I would again request that this be clarified.  Proposed text:

1: Min Unidirectional Link Delay as defined in [RFC 7810], section 4.2, 
encoded in the Application Specific Link Attributes Sub-TLV 
[I-D.ietf-isis-te-app].


Thank you.

Regards,
Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2020-08-17 Thread Christian Hopps

This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

47 matches

Mail list logo