Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[LEI LIU]

Support as a co-author.

Thanks,
Best regards,
Lei

On Tue, Aug 18, 2020 at 7:17 AM Acee Lindem (acee)  wrote:

>
>
> Based on the discussions in the last meeting and on the mailing list
> regarding draft-chen-isis-ttz-11, the chairs feel that there are enough
> differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to
> consider advancing it independently on the experimental track.
>
>
>
> These differences include abstraction at arbitrary boundaries and IS-IS
> extensions for smooth transition to/from zone abstraction.
>
>
>
> We are now starting an LSR WG adoption call for
> draft-chen-isis-ttz-11.txt. Please indicate your support or objection to
> adoption prior to Tuesday, September 2nd, 2020.
>
>
>
> Thanks,
>
> Acee and Chris
>
>
> ___
> 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] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

[LEI LIU]

I’m not aware of any IPR associated with this draft.



Thanks,

Best regards,


Lei



On Tue, Aug 18, 2020 at 7:24 AM Acee Lindem (acee)  wrote:

> Authors,
>
>
>
> The IETF IPRs declarations submitted for draft-chen-isis-ttz are specified
> here:
>
>
>
> https://datatracker.ietf.org/ipr/4029/
>
>
>
>
>
> Are you aware of any other IPR that applies to draft-chen-isis-ttz?
>
>
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
>
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as a document author or contributor please respond
>
> to this email regardless of whether or not you are aware of any
>
> relevant IPR. *The response needs to be sent to the LSR WG mailing
>
> list.* The document will not advance to the next stage until a
>
> response has been received from each author and contributor.
>
>
>
> If you are on the LSR WG email list but are not listed as an author or
>
> contributor, then please explicitly respond only if you are aware of
>
> any IPR that has not yet been disclosed in conformance with IETF rules.
>
>
>
> Thanks,
>
> Acee
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Aijun Wang]

Hi, all:

 

Support its adoption.

>From the current contents of these two drafts, as Acee said, there are enough 
>differences between them. The area-proxy draft defining mainly the extension 
>of the TLVs that should be carried by the Proxy LSP, the TTZ draft emphasizes 
>mainly the smooth transition procedures and the related protocol extension.  

 

Using the protocol to solve the transition problem can certainly ease the 
deployment/operation overhead.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

 

 

From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 PM
To: lsr@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

 

 

Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.

 

These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.

 

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.

 

Thanks,

Acee and Chris 

 

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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Haoyu Song]

I Support the adoption for experimental track.

Haoyu

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.

These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.

Thanks,
Acee and Chris

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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Kiran Makhijani]

I support the adoption.
-Kiran

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.

These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.

Thanks,
Acee and Chris

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

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

[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

[Peter Psenak]

Olivier,

On 20/08/2020 16:25, olivier.dug...@orange.com wrote:

Peter,

Le 20/08/2020 à 14:12, Peter Psenak a écrit :

Hi Olivier,

On 20/08/2020 13:58, 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.


what is the problem with using the reference to isis-te-app,
ospf-te-link-attr-reuse in 5.1 and 5.2?




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 ? 


sure

if yes, how can we link metrics advertise in ALSA A from metrics 
advertise in ALSA B ? The draft mention only one bit for Flex-Algo.


there is only single ASLA flex-algo delay metric advertisement per link, 
similar to only single RSVP-TE delay metric per link.



Advertisement is done per application type, flex-algo being one of them, 
not per each instance of the application (e.g. flex-algo number).





Regards,

Olivier

PS. I note a duplicate paragraph in section 12: "When computing the path 
for a given Flex-Algorithm, the metric-type that is part of the 
Flex-Algorithm definition (Section 5) MUST be used."


I don't see it. I see one talking about metric, the other one about the 
calculation type.


thanks,
Peter





thanks,
Peter



Regards

Olivier

PS. We have a pre-alpha implementation of flex algo using the legacy 
metrics and I know that recent IOS-XR provided similar implementation 
of flex algo based on legacy metrics.




regards,
Peter



Regards

Olivier

Le 18/08/2020 à 19:02, tony...@tony.li 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 > 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 

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

[olivier.dugeon]

Peter,

Le 20/08/2020 à 14:12, Peter Psenak a écrit :
> Hi Olivier,
>
> On 20/08/2020 13:58, olivier.dug...@orange.com wrote:
>> Hi Peter,
>>
>> Thank for the new version.
>>
>> Le 19/08/2020 à 14:00, Peter Psenak a écrit :
>>> Olivier, 
>> [ ... ]
 So, to speed up the deployment, I would prefer a reference to a delay 
 value that could be advertise by means of RFC7471, RFC8570 and/or TE-App 
 draft. It is then up to the operator to ensure the coherency of what it is 
 announced in its network by the different routers.
>>>
>>> I know you don't like the app specific link advertisement, but I'm afraid 
>>> what you ask for is absolutely wrong.
>>>
>>> We defined the ASLA encoding to address a real problems for advertising the 
>>> link attributes. We allow the link attributes to be advertised in both 
>>> legacy and ASLA advertisement for legacy application (RSVP-TE, SRTE) to 
>>> address the backward compatibility. Flex-algo is a new application, there 
>>> is absolutely no need to use the legacy advertisement. Doing so would just 
>>> extend the problem to the flex-algo application.
>>
>> Regarding the new version you provided, new section 5.1 (for IS-IS) and 
>> section 5.2 (for OSPF) mention respectively RFC 8570 and RFC 7471 for the 
>> definition of Min delay and TE metric which is fine for me. But, they also 
>> made reference to draft isis-te-app, respectively ospf-te-link-attr-reuse to 
>> encode these value. 
>
> that's what people were asking for. And it is right because we are mandating 
> the usage of ALSA encoding for any flex-algo related link attributes.
>
>> Here, it is confusing. 
>
> I don't see how much more clear we can make it.
>
>> Indeed, RFC 8570 and RFC 7471 also define the way to encode TE metric and 
>> Min delay.
>
> you have to distinguish between two things:
>
> a)  where Min delay and TE metric were defined - RFC 8570 and RFC 7471
> b)  how we encode it for flex-algo - isis-te-app,
> ospf-te-link-attr-reuse
>
>>
>> What I'm suggesting, is a clear reference to the RFC for TE metric and Min 
>> delay definition as well as the encoding (especially for the delay) while 
>> leaving open the door to how the router acquire these values: legacy a.k.a. 
>> RFC 8570 & 7471 or new draft a.k.a draft-isis-te-app & 
>> draft-ospf-link-attr-reuse.
>
> no. This will not be done. We only allow ASLA advertisement for these metrics 
> and other link attributes that are used for flex-algo. It is done for a 
> reason and I have already explained that.
>
OK. Reading section 11 which clarify how metrics are convey, let me suggest to 
make a reference to section 11 in section 5.1 and 5.2 instead of reference to 
drafts.
>>
>> In fact, in section 17.1.2, you mention only reference to RFC 8570 & RFC7471 
>> for the IANA definition which is fine for me. 
>
> because in registry, we are defining a metric type, not how we are going to 
> advertise it for the link.
>
>
OK.
>
>> I would suggest the same wording for section 5.1. and 5.2 leaving operator 
>> free about how it collect the values from the neighbour routers: legacy or 
>> new method.
>
> please stop trying to make use of legacy RSVP-TE link advertisements for 
> flex-algo - it will not be allowed.

This raise to me a simple question: Is it possible to use 2 different Flex Algo 
with delay metric, one for App A and another one for App B ? if yes, how can we 
link metrics advertise in ALSA A from metrics advertise in ALSA B ? The draft 
mention only one bit for Flex-Algo.

Regards,

Olivier

PS. I note a duplicate paragraph in section 12: "When computing the path for a 
given Flex-Algorithm, the metric-type that is part of the Flex-Algorithm 
definition (Section 5) MUST be used."

>
> thanks,
> Peter
>
>>
>> Regards
>>
>> Olivier
>>
>> PS. We have a pre-alpha implementation of flex algo using the legacy metrics 
>> and I know that recent IOS-XR provided similar implementation of flex algo 
>> based on legacy metrics.
>>
>>>
>>> regards,
>>> Peter
>>>

 Regards

 Olivier

 Le 18/08/2020 à 19:02, tony...@tony.li 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 > > 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 

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

[Peter Psenak]

Hi Olivier,

On 20/08/2020 13:58, 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.




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.




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.


thanks,
Peter



Regards

Olivier

PS. We have a pre-alpha implementation of flex algo using the legacy 
metrics and I know that recent IOS-XR provided similar implementation of 
flex algo based on legacy metrics.




regards,
Peter



Regards

Olivier

Le 18/08/2020 à 19:02, tony...@tony.li 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 > 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) 
> 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 

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

[olivier.dugeon]

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. 
Here, it is confusing. Indeed, RFC 8570 and RFC 7471 also define the way to 
encode TE metric and Min delay.

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.

In fact, in section 17.1.2, you mention only reference to RFC 8570 & RFC7471 
for the IANA definition which is fine for me. 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.

Regards

Olivier

PS. We have a pre-alpha implementation of flex algo using the legacy metrics 
and I know that recent IOS-XR provided similar implementation of flex algo 
based on legacy metrics.

>
> regards,
> Peter
>
>>
>> Regards
>>
>> Olivier
>>
>> Le 18/08/2020 à 19:02, tony...@tony.li 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 >>> > 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 
     *Sent:* Tuesday, August 18, 2020 7:44 AM
     *To:* Peter Psenak (ppsenak) >>>     >
     *Cc:* lsr@ietf.org ; lsr-...@ietf.org
     ; Christian Hopps >>>     >; Acee Lindem (acee) >>>     >; 

Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

[Veerendranatha Reddy V]

Thanks Peter for the clarification.

Thanks & Regards,
Veerendranath

-Original Message-
From: Peter Psenak  
Sent: Wednesday, August 19, 2020 5:32 PM
To: Veerendranatha Reddy V ; lsr@ietf.org
Subject: Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Hi Veerendranatha,

On 19/08/2020 11:48, Veerendranatha Reddy V wrote:
> Hi Peter,
> Thanks for the reply.
> As per the discussion, my understanding is Range TLV  defined mainly be used 
> for SRMS entries (to get entries from LDP , for LDP Interoperability).
> The use case mentioned  is different from SRMS (redistribution across IGP 
> protocols) , Range TLV is not applicable to use in that use case?

no. At this point, Range TLV is defined only for SRMS mapping advertisement.

thanks,
Peter

> 
> Thanks & Regards,
> Veerendranath
> 
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Wednesday, August 19, 2020 3:04 PM
> To: Veerendranatha Reddy V ; 
> lsr@ietf.org
> Subject: Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
> External/NSSA prefixes defined in RFC 8665
> 
> Veerendranatha,
> 
> On 19/08/2020 11:19, Veerendranatha Reddy V wrote:
>> Hi Peter,
>> Thanks for the reply.
>> For OSPFv2 Extended Prefix TLV  (defined in RFC 7684) has route type and it 
>> supports NSSA External Prefixes to carry SID information.
>> In the same way, if Range TLV has Route-Type , we can extend to support for 
>> NSSA ASBR to send Range TLVs for redistributed prefixes.
> 
> no. NSSA route type is used for redistribution of prefixes to NSSA areas. 
> There is no such thing as redistribution of SRMS entries. So using NSSA type 
> with SRMS advertisement is not valid.
> 
> Peter
> 
> 
> 
> 
>>
>> Thanks & Regards,
>> Veerendranath
>>
>> -Original Message-
>> From: Peter Psenak 
>> Sent: Wednesday, August 19, 2020 1:39 PM
>> To: Veerendranatha Reddy V ;
>> lsr@ietf.org
>> Subject: Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
>> External/NSSA prefixes defined in RFC 8665
>>
>> Veerendranath,
>>
>> On 19/08/2020 10:03, Veerendranatha Reddy V wrote:
>>> Hi Peter,
>>> It is not related to SRMS.
>>> If there exist ISIS/OSPF or two instances of OSPF in same device, and all 
>>> are supporting ST, then I can redistribute SR Prefix information to OSPF 
>>> from other OSPF instance or from ISIS.
>>
>> yes, you can.
>>
>>> In this case, I may use range TLV to reduce the number of Prefix TLVs, by 
>>> using  Range TLV, if prefixes and SID are able to convert to Range TLV.
>>
>> you would have to generate one somewhere (on ABR?), but it would not be of 
>> NSSA type.
>>
>> Peter
>>
>>
>>>
>>> Thanks & Regards,
>>> Veerendranath
>>>
>>>
>>> -Original Message-
>>> From: Peter Psenak 
>>> Sent: Wednesday, August 19, 2020 1:23 PM
>>> To: Veerendranatha Reddy V ;
>>> lsr@ietf.org
>>> Subject: Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage 
>>> for External/NSSA prefixes defined in RFC 8665
>>>
>>> Hi Veerendranatha,
>>>
>>> On 19/08/2020 06:23, Veerendranatha Reddy V wrote:
 Hi Peter,
 While redistributing prefix Sid for the prefixes from other protocols (Ex: 
 from ISIS or other OSPF instances), we can consider as range TLV for the 
 prefixes which are advertised in the range TLV in that protocol.
>>>
>>> I don't follow. Are you talking about redistribution of SRMS advertisement 
>>> between protocols? Such thing has not been defined.
>>>
>>> thanks,
>>> Peter
>>>
>>>
 If it is NSSA, then we need to advertise these redistributed prefixes as 
 area scope, so Range TLV also need to be part of area scope Opaque LSA.

 Thanks & Regards,
 Veerendranath

 -Original Message-
 From: Peter Psenak 
 Sent: Tuesday, August 18, 2020 11:06 PM
 To: Veerendranatha Reddy V ;
 lsr@ietf.org
 Subject: Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage 
 for External/NSSA prefixes defined in RFC 8665

 Veerendranath,

 On 18/08/2020 16:40, Veerendranatha Reddy V wrote:
> Hi Authors, All,
>
> OSPF Extended Prefix Range TLV defined in RFC 8665 has IA flag to 
> distinguish between Intra and Inter Area scope prefixes.
>
> Whether any restrictions to not to use Prefix Range TLV for 
> external/NSSA prefixes ?

 I don't see how you can use OSPF Extended Prefix Range TLV for NSSA, the 
 usage of OSPF Extended Prefix Range TLV has only been defined in the 
 context of RFC 8665.

 thanks,
 Peter


>
> For External Prefixes, we can able to use  Prefix Range TLV  by 
> using LSA type (based on AS scope Opaque Type , so the TLV is for 
> External
> Prefixes)
>
> But If we need to use the Prefix Range TLV for NSSA prefixes
> (Type-7) , which are in area scope, there is no flag/route-type 
> field in this TLV to distinguish between Intra or NSSA prefixes( 
> as IA flag will not be set anyway).