Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-06-10 Thread Linda Dunbar 
Peter, 

Thank you for the explanation.  

Linda

-Original Message-
From: Peter Psenak  
Sent: Wednesday, June 10, 2020 3:40 AM
To: Linda Dunbar ; Acee Lindem (acee) 
; gen-...@ietf.org
Cc: last-c...@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] Genart last call review of 
draft-ietf-ospf-te-link-attr-reuse-12

Linda,

On 09/06/2020 22:20, Linda Dunbar wrote:
> Peter,
> 
> Thank you for the explanation.
> 
> So you are saying that a node might not support RSVP or RSVP-TE, but can 
> advertise the TE related attributes for SR purpose. When  the head node 
> receiving the advertisement also support RSVP-TE, it might use the 
> information to establish the RSVP path, which will be rejected by the node 
> that don't support RSVP but advertise the TE related information?  is it 
> correct?

yes.

> 
> It would be useful if you can add a statement to explain the scenario that a 
> node only has a subset of links supporting RSVP-TE but also capable of 
> advertising TE related attributes for links that are not enabled for RSVP-TE.

There is a text in the draft:

 An example where this ambiguity causes a problem is a network in
 which RSVP-TE is enabled only on a subset of its links.  A link
 attribute is advertised for the purpose of another application (e.g.
 SRTE) for a link that is not enabled for RSV-TE.  As soon as the
 router that is an RSVP-TE head-end sees the link attribute being
 advertised for that link, it assumes RSVP-TE is enabled on that
 link, even though it is not.  If such RSVP-TE head-end router tries
 to setup an RSVP-TE path via that link it will result in the path
 setup failure.

thanks,
Peter

> 
> Linda Dunbar
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Tuesday, June 9, 2020 10:18 AM
> To: Linda Dunbar ; Acee Lindem (acee) 
> ; gen-...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org; 
> draft-ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: Genart last call review of 
> draft-ietf-ospf-te-link-attr-reuse-12
> 
> Linda,
> 
> On 09/06/2020 16:18, Linda Dunbar wrote:
>> Acee and Peter,
>>
>> Thank you very much for the explanation.
>>
>> My fundamental question is: What problem will be encountered when a node use 
>> the TE information on links that RSVP-TE are not enabled?
> 
> The problem is on a node where RSVP is enabled, when it receives the link 
> attribute for a remote link where RSVP is not enabled.
> 
>  An example where this ambiguity causes a problem is a network in
>  which RSVP-TE is enabled only on a subset of its links.  A link
>  attribute is advertised for the purpose of another application (e.g.
>  SRTE) for a link that is not enabled for RSV-TE.  As soon as the
>  router that is an RSVP-TE head-end sees the link attribute being
>  advertised for that link, it assumes RSVP-TE is enabled on that link,
>  even though it is not.  If such RSVP-TE head-end router tries to
>  setup an RSVP-TE path via that link it will result in the path setup
>  failure.
> 
>>
>> I would think that the reason that RSVP-TE is enabled per interface is 
>> because not every interface is capable of generating the TE information, or 
>> the Node doesn't want to share the detailed TE information to remote nodes 
>> (for security reasons?).
> 
> the simplest reason is that RSVP is not used on the router at all.
> 
>>
>>If SR is enabled on a node, which is capable of detecting the TE 
>> information on the links to be advertised to remote nodes, what problems do 
>> we have when the OSPF-TE application on remote nodes utilizes the Link TE 
>> information?
> 
> please see above.
> 
> thanks,
> Peter
>>
>>
>> Thank you.
>>
>> Linda
>>
>> -Original Message-
>> From: Acee Lindem (acee) 
>> Sent: Tuesday, June 9, 2020 6:25 AM
>> To: Peter Psenak (ppsenak) ; Linda Dunbar 
>> ; gen-...@ietf.org
>> Cc: last-c...@ietf.org; lsr@ietf.org; 
>> draft-ietf-ospf-te-link-attr-reuse@ietf.org
>> Subject: Re: Genart last call review of
>> draft-ietf-ospf-te-link-attr-reuse-12
>>
>> Hi Linda,
>> One more point...
>>
>> On 6/9/20, 4:52 AM, "Peter Psenak"  wrote:
>>
>>   Linda,
>>
>>   On 09/06/2020 02:37, Linda Dunbar wrote:
>>   > Peter,
>>   >
>>   > Thank you very much for adding the extra text to explain.
>>   >
>>   > But SR is supposed to be transparent to all intermediate nodes. Does 
>> your draft require a node to be specifically configured for each link to 
>> sup

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-06-10 Thread Peter Psenak 

Linda,

On 09/06/2020 22:20, Linda Dunbar wrote:

Peter,

Thank you for the explanation.

So you are saying that a node might not support RSVP or RSVP-TE, but can 
advertise the TE related attributes for SR purpose. When  the head node 
receiving the advertisement also support RSVP-TE, it might use the information 
to establish the RSVP path, which will be rejected by the node that don't 
support RSVP but advertise the TE related information?  is it correct?


yes.



It would be useful if you can add a statement to explain the scenario that a 
node only has a subset of links supporting RSVP-TE but also capable of 
advertising TE related attributes for links that are not enabled for RSVP-TE.


There is a text in the draft:

An example where this ambiguity causes a problem is a network in
which RSVP-TE is enabled only on a subset of its links.  A link
attribute is advertised for the purpose of another application (e.g.
SRTE) for a link that is not enabled for RSV-TE.  As soon as the
router that is an RSVP-TE head-end sees the link attribute being
advertised for that link, it assumes RSVP-TE is enabled on that
link, even though it is not.  If such RSVP-TE head-end router tries
to setup an RSVP-TE path via that link it will result in the path
setup failure.

thanks,
Peter



Linda Dunbar

-Original Message-
From: Peter Psenak 
Sent: Tuesday, June 9, 2020 10:18 AM
To: Linda Dunbar ; Acee Lindem (acee) 
; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Linda,

On 09/06/2020 16:18, Linda Dunbar wrote:

Acee and Peter,

Thank you very much for the explanation.

My fundamental question is: What problem will be encountered when a node use 
the TE information on links that RSVP-TE are not enabled?


The problem is on a node where RSVP is enabled, when it receives the link 
attribute for a remote link where RSVP is not enabled.

 An example where this ambiguity causes a problem is a network in
 which RSVP-TE is enabled only on a subset of its links.  A link
 attribute is advertised for the purpose of another application (e.g.
 SRTE) for a link that is not enabled for RSV-TE.  As soon as the
 router that is an RSVP-TE head-end sees the link attribute being
 advertised for that link, it assumes RSVP-TE is enabled on that link,
 even though it is not.  If such RSVP-TE head-end router tries to
 setup an RSVP-TE path via that link it will result in the path setup
 failure.



I would think that the reason that RSVP-TE is enabled per interface is because 
not every interface is capable of generating the TE information, or the Node 
doesn't want to share the detailed TE information to remote nodes (for security 
reasons?).


the simplest reason is that RSVP is not used on the router at all.



   If SR is enabled on a node, which is capable of detecting the TE information 
on the links to be advertised to remote nodes, what problems do we have when 
the OSPF-TE application on remote nodes utilizes the Link TE information?


please see above.

thanks,
Peter



Thank you.

Linda

-Original Message-
From: Acee Lindem (acee) 
Sent: Tuesday, June 9, 2020 6:25 AM
To: Peter Psenak (ppsenak) ; Linda Dunbar
; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org;
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of
draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda,
One more point...

On 6/9/20, 4:52 AM, "Peter Psenak"  wrote:

  Linda,

  On 09/06/2020 02:37, Linda Dunbar wrote:
  > Peter,
  >
  > Thank you very much for adding the extra text to explain.
  >
  > But SR is supposed to be transparent to all intermediate nodes. Does 
your draft require a node to be specifically configured for each link to support 
or not support SR or RSVP-TE?

  the draft does not pose any new requirements in terms of how
  applications are enabled.

  Please note that RSVP-TE is typically enabled per interface, SRTE is
  typically enabled on a per node basis.

For SR, these attributes are attributes are advertised in OSPF so that any OSPF 
router or controller in the OSPF domain can make use of them to compute the SR 
path.

Thanks,
Acee


  >
  > In addition, there is no new attributes described in the document. So 
if a node is advertising TE related attributes for a specific link, such as 
bandwidth, delay,  what kind problems this node will encounter if a remote node 
utilize those TE specific attributes?

  the problem is when the link attributes advertise for the purpose of
  application other than RSVP-TE is mistakenly used by RSVP-TE.

  thanks,
  Peter



  >
  > Linda Dunbar
  >
  > -Original Message-
  > From: Peter Psenak 
  > Sent: Monday, June 1, 2020 11:01 AM
  > To: Linda Dunbar

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-06-09 Thread Linda Dunbar 
Peter, 

Thank you for the explanation. 

So you are saying that a node might not support RSVP or RSVP-TE, but can 
advertise the TE related attributes for SR purpose. When  the head node 
receiving the advertisement also support RSVP-TE, it might use the information 
to establish the RSVP path, which will be rejected by the node that don't 
support RSVP but advertise the TE related information?  is it correct? 

It would be useful if you can add a statement to explain the scenario that a 
node only has a subset of links supporting RSVP-TE but also capable of 
advertising TE related attributes for links that are not enabled for RSVP-TE. 

Linda Dunbar

-Original Message-
From: Peter Psenak  
Sent: Tuesday, June 9, 2020 10:18 AM
To: Linda Dunbar ; Acee Lindem (acee) 
; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Linda,

On 09/06/2020 16:18, Linda Dunbar wrote:
> Acee and Peter,
> 
> Thank you very much for the explanation.
> 
> My fundamental question is: What problem will be encountered when a node use 
> the TE information on links that RSVP-TE are not enabled?

The problem is on a node where RSVP is enabled, when it receives the link 
attribute for a remote link where RSVP is not enabled.

An example where this ambiguity causes a problem is a network in
which RSVP-TE is enabled only on a subset of its links.  A link
attribute is advertised for the purpose of another application (e.g.
SRTE) for a link that is not enabled for RSV-TE.  As soon as the
router that is an RSVP-TE head-end sees the link attribute being
advertised for that link, it assumes RSVP-TE is enabled on that link,
even though it is not.  If such RSVP-TE head-end router tries to
setup an RSVP-TE path via that link it will result in the path setup
failure.

> 
> I would think that the reason that RSVP-TE is enabled per interface is 
> because not every interface is capable of generating the TE information, or 
> the Node doesn't want to share the detailed TE information to remote nodes 
> (for security reasons?).

the simplest reason is that RSVP is not used on the router at all.

> 
>   If SR is enabled on a node, which is capable of detecting the TE 
> information on the links to be advertised to remote nodes, what problems do 
> we have when the OSPF-TE application on remote nodes utilizes the Link TE 
> information?

please see above.

thanks,
Peter
> 
> 
> Thank you.
> 
> Linda
> 
> -Original Message-
> From: Acee Lindem (acee) 
> Sent: Tuesday, June 9, 2020 6:25 AM
> To: Peter Psenak (ppsenak) ; Linda Dunbar 
> ; gen-...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org; 
> draft-ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: Genart last call review of 
> draft-ietf-ospf-te-link-attr-reuse-12
> 
> Hi Linda,
> One more point...
> 
> On 6/9/20, 4:52 AM, "Peter Psenak"  wrote:
> 
>  Linda,
> 
>  On 09/06/2020 02:37, Linda Dunbar wrote:
>  > Peter,
>  >
>  > Thank you very much for adding the extra text to explain.
>  >
>  > But SR is supposed to be transparent to all intermediate nodes. Does 
> your draft require a node to be specifically configured for each link to 
> support or not support SR or RSVP-TE?
> 
>  the draft does not pose any new requirements in terms of how
>  applications are enabled.
> 
>  Please note that RSVP-TE is typically enabled per interface, SRTE is
>  typically enabled on a per node basis.
> 
> For SR, these attributes are attributes are advertised in OSPF so that any 
> OSPF router or controller in the OSPF domain can make use of them to compute 
> the SR path.
> 
> Thanks,
> Acee
> 
> 
>  >
>  > In addition, there is no new attributes described in the document. So 
> if a node is advertising TE related attributes for a specific link, such as 
> bandwidth, delay,  what kind problems this node will encounter if a remote 
> node utilize those TE specific attributes?
> 
>  the problem is when the link attributes advertise for the purpose of
>  application other than RSVP-TE is mistakenly used by RSVP-TE.
> 
>  thanks,
>  Peter
> 
> 
> 
>  >
>  > Linda Dunbar
>  >
>  > -Original Message-
>  > From: Peter Psenak 
>  > Sent: Monday, June 1, 2020 11:01 AM
>  > To: Linda Dunbar ; gen-...@ietf.org
>  > Cc: last-c...@ietf.org; lsr@ietf.org; 
> draft-ietf-ospf-te-link-attr-reuse@ietf.org
>  > Subject: Re: Genart last call review of 
> draft-ietf-ospf-te-link-attr-reuse-12
>  >
>  > Hi Linda,
>  >
>  >
>  > On 01/06/2020 17:30, Linda Dunbar wrote:
>  >> Peter,
>  >> You said:
>  >> /“//the problem with existing advertisement is that RSVP-TE will use
>  >> it, even if it was not intended to be used by RSVP-TE.//”/ What is the
>  >> problem if RSVP-TE use the advertisement?

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-06-09 Thread Peter Psenak 

Linda,

On 09/06/2020 16:18, Linda Dunbar wrote:

Acee and Peter,

Thank you very much for the explanation.

My fundamental question is: What problem will be encountered when a node use 
the TE information on links that RSVP-TE are not enabled?


The problem is on a node where RSVP is enabled, when it receives the 
link attribute for a remote link where RSVP is not enabled.


   An example where this ambiguity causes a problem is a network in
   which RSVP-TE is enabled only on a subset of its links.  A link
   attribute is advertised for the purpose of another application (e.g.
   SRTE) for a link that is not enabled for RSV-TE.  As soon as the
   router that is an RSVP-TE head-end sees the link attribute being
   advertised for that link, it assumes RSVP-TE is enabled on that link,
   even though it is not.  If such RSVP-TE head-end router tries to
   setup an RSVP-TE path via that link it will result in the path setup
   failure.



I would think that the reason that RSVP-TE is enabled per interface is because 
not every interface is capable of generating the TE information, or the Node 
doesn't want to share the detailed TE information to remote nodes (for security 
reasons?).


the simplest reason is that RSVP is not used on the router at all.



  If SR is enabled on a node, which is capable of detecting the TE information 
on the links to be advertised to remote nodes, what problems do we have when 
the OSPF-TE application on remote nodes utilizes the Link TE information?


please see above.

thanks,
Peter



Thank you.

Linda

-Original Message-
From: Acee Lindem (acee) 
Sent: Tuesday, June 9, 2020 6:25 AM
To: Peter Psenak (ppsenak) ; Linda Dunbar 
; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda,
One more point...

On 6/9/20, 4:52 AM, "Peter Psenak"  wrote:

 Linda,

 On 09/06/2020 02:37, Linda Dunbar wrote:
 > Peter,
 >
 > Thank you very much for adding the extra text to explain.
 >
 > But SR is supposed to be transparent to all intermediate nodes. Does 
your draft require a node to be specifically configured for each link to support 
or not support SR or RSVP-TE?

 the draft does not pose any new requirements in terms of how
 applications are enabled.

 Please note that RSVP-TE is typically enabled per interface, SRTE is
 typically enabled on a per node basis.

For SR, these attributes are attributes are advertised in OSPF so that any OSPF 
router or controller in the OSPF domain can make use of them to compute the SR 
path.

Thanks,
Acee


 >
 > In addition, there is no new attributes described in the document. So if 
a node is advertising TE related attributes for a specific link, such as 
bandwidth, delay,  what kind problems this node will encounter if a remote node 
utilize those TE specific attributes?

 the problem is when the link attributes advertise for the purpose of
 application other than RSVP-TE is mistakenly used by RSVP-TE.

 thanks,
 Peter



 >
 > Linda Dunbar
 >
 > -Original Message-
 > From: Peter Psenak 
 > Sent: Monday, June 1, 2020 11:01 AM
 > To: Linda Dunbar ; gen-...@ietf.org
 > Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
 > Subject: Re: Genart last call review of 
draft-ietf-ospf-te-link-attr-reuse-12
 >
 > Hi Linda,
 >
 >
 > On 01/06/2020 17:30, Linda Dunbar wrote:
 >> Peter,
 >> You said:
 >> /“//the problem with existing advertisement is that RSVP-TE will use
 >> it, even if it was not intended to be used by RSVP-TE.//”/ What is the
 >> problem if RSVP-TE use the advertisement? What specific attributes
 >> that RSVP-TE shouldn’t use?
 >
 > Following text has been added to the draft based on comments from Scott.
 >
 > "An example where this ambiguity causes problem is a network which has 
RSVP-TE enabled on one subset of links, and SRTE enabled on a different subset. A link 
attribute is advertised for the purpose of some other application (e.g. SRTE) for a link 
that is not enabled for RSV-TE. As soon as the router that is an RSVP-TE head-end sees the 
link attribute being advertised for such link, it assumes RSVP-TE is enabled on that link, 
even though in reality, RSVP-TE is not enabled on it. If such RSVP-TE head-end router tries 
to setup an RSVP-TE path via link where RSVP-TE is not enabled it will result in the path 
setup failure."
 >
 > Hope it makes it clear and addresses your question.
 >
 > thanks,
 > Peter
 >
 >
 >
 >
 >
 >> Linda Dunbar
 >> -Original Message-
 >> From: Peter Psenak 
 >> Sent: Friday, May 29, 2020 10:00 AM
 >> To: Linda Dunbar ; gen-...@ietf.org
 >> Cc: last-c...@ietf.org; lsr@ietf.org;
 >>

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-06-09 Thread Linda Dunbar 
Acee and Peter, 

Thank you very much for the explanation. 

My fundamental question is: What problem will be encountered when a node use 
the TE information on links that RSVP-TE are not enabled? 

I would think that the reason that RSVP-TE is enabled per interface is because 
not every interface is capable of generating the TE information, or the Node 
doesn't want to share the detailed TE information to remote nodes (for security 
reasons?). 

 If SR is enabled on a node, which is capable of detecting the TE information 
on the links to be advertised to remote nodes, what problems do we have when 
the OSPF-TE application on remote nodes utilizes the Link TE information? 


Thank you. 

Linda

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, June 9, 2020 6:25 AM
To: Peter Psenak (ppsenak) ; Linda Dunbar 
; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda,
One more point... 

On 6/9/20, 4:52 AM, "Peter Psenak"  wrote:

Linda,

On 09/06/2020 02:37, Linda Dunbar wrote:
> Peter,
> 
> Thank you very much for adding the extra text to explain.
> 
> But SR is supposed to be transparent to all intermediate nodes. Does your 
draft require a node to be specifically configured for each link to support or 
not support SR or RSVP-TE?

the draft does not pose any new requirements in terms of how 
applications are enabled.

Please note that RSVP-TE is typically enabled per interface, SRTE is 
typically enabled on a per node basis.

For SR, these attributes are attributes are advertised in OSPF so that any OSPF 
router or controller in the OSPF domain can make use of them to compute the SR 
path. 

Thanks,
Acee


> 
> In addition, there is no new attributes described in the document. So if 
a node is advertising TE related attributes for a specific link, such as 
bandwidth, delay,  what kind problems this node will encounter if a remote node 
utilize those TE specific attributes?

the problem is when the link attributes advertise for the purpose of 
application other than RSVP-TE is mistakenly used by RSVP-TE.

thanks,
Peter



> 
> Linda Dunbar
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Monday, June 1, 2020 11:01 AM
> To: Linda Dunbar ; gen-...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: Genart last call review of 
draft-ietf-ospf-te-link-attr-reuse-12
> 
> Hi Linda,
> 
> 
> On 01/06/2020 17:30, Linda Dunbar wrote:
>> Peter,
>> You said:
>> /“//the problem with existing advertisement is that RSVP-TE will use
>> it, even if it was not intended to be used by RSVP-TE.//”/ What is the
>> problem if RSVP-TE use the advertisement? What specific attributes
>> that RSVP-TE shouldn’t use?
> 
> Following text has been added to the draft based on comments from Scott.
> 
> "An example where this ambiguity causes problem is a network which has 
RSVP-TE enabled on one subset of links, and SRTE enabled on a different subset. 
A link attribute is advertised for the purpose of some other application (e.g. 
SRTE) for a link that is not enabled for RSV-TE. As soon as the router that is 
an RSVP-TE head-end sees the link attribute being advertised for such link, it 
assumes RSVP-TE is enabled on that link, even though in reality, RSVP-TE is not 
enabled on it. If such RSVP-TE head-end router tries to setup an RSVP-TE path 
via link where RSVP-TE is not enabled it will result in the path setup failure."
> 
> Hope it makes it clear and addresses your question.
> 
> thanks,
> Peter
> 
> 
> 
> 
> 
>> Linda Dunbar
>> -Original Message-
>> From: Peter Psenak 
>> Sent: Friday, May 29, 2020 10:00 AM
>> To: Linda Dunbar ; gen-...@ietf.org
>> Cc: last-c...@ietf.org; lsr@ietf.org;
>> draft-ietf-ospf-te-link-attr-reuse@ietf.org
>> Subject: Re: Genart last call review of
>> draft-ietf-ospf-te-link-attr-reuse-12
>> Linda,
>> On 29/05/2020 16:52, Linda Dunbar wrote:
>>> Peter,
>>> You said:
>>> /we are not defining any new attributes./ /We are allowing an
>>> existing link attributes to be used by other applications, including,
>>> but not limited to SRTE./ What prevent a node (or an application on
>>> the node) receiving the LSA from using the attributes carried by the 
LSA?
>> the problem with existing advertisement is that RSVP-TE will use it,
>> even if it was not intended to be used by RSVP-TE.
>> We are providing a way to explicitly advertised apps that are allowed
>> to use the advertised attributes.
>>> If no new attributes are
>>> to be added, then why need a new ASLA sub-TLV?
>> to be able

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-06-09 Thread Acee Lindem (acee) 
Hi Linda,
One more point... 

On 6/9/20, 4:52 AM, "Peter Psenak"  wrote:

Linda,

On 09/06/2020 02:37, Linda Dunbar wrote:
> Peter,
> 
> Thank you very much for adding the extra text to explain.
> 
> But SR is supposed to be transparent to all intermediate nodes. Does your 
draft require a node to be specifically configured for each link to support or 
not support SR or RSVP-TE?

the draft does not pose any new requirements in terms of how 
applications are enabled.

Please note that RSVP-TE is typically enabled per interface, SRTE is 
typically enabled on a per node basis.

For SR, these attributes are attributes are advertised in OSPF so that any OSPF 
router or controller in the OSPF domain can make use of them to compute the SR 
path. 

Thanks,
Acee


> 
> In addition, there is no new attributes described in the document. So if 
a node is advertising TE related attributes for a specific link, such as 
bandwidth, delay,  what kind problems this node will encounter if a remote node 
utilize those TE specific attributes?

the problem is when the link attributes advertise for the purpose of 
application other than RSVP-TE is mistakenly used by RSVP-TE.

thanks,
Peter



> 
> Linda Dunbar
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Monday, June 1, 2020 11:01 AM
> To: Linda Dunbar ; gen-...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: Genart last call review of 
draft-ietf-ospf-te-link-attr-reuse-12
> 
> Hi Linda,
> 
> 
> On 01/06/2020 17:30, Linda Dunbar wrote:
>> Peter,
>> You said:
>> /“//the problem with existing advertisement is that RSVP-TE will use
>> it, even if it was not intended to be used by RSVP-TE.//”/ What is the
>> problem if RSVP-TE use the advertisement? What specific attributes
>> that RSVP-TE shouldn’t use?
> 
> Following text has been added to the draft based on comments from Scott.
> 
> "An example where this ambiguity causes problem is a network which has 
RSVP-TE enabled on one subset of links, and SRTE enabled on a different subset. 
A link attribute is advertised for the purpose of some other application (e.g. 
SRTE) for a link that is not enabled for RSV-TE. As soon as the router that is 
an RSVP-TE head-end sees the link attribute being advertised for such link, it 
assumes RSVP-TE is enabled on that link, even though in reality, RSVP-TE is not 
enabled on it. If such RSVP-TE head-end router tries to setup an RSVP-TE path 
via link where RSVP-TE is not enabled it will result in the path setup failure."
> 
> Hope it makes it clear and addresses your question.
> 
> thanks,
> Peter
> 
> 
> 
> 
> 
>> Linda Dunbar
>> -Original Message-
>> From: Peter Psenak 
>> Sent: Friday, May 29, 2020 10:00 AM
>> To: Linda Dunbar ; gen-...@ietf.org
>> Cc: last-c...@ietf.org; lsr@ietf.org;
>> draft-ietf-ospf-te-link-attr-reuse@ietf.org
>> Subject: Re: Genart last call review of
>> draft-ietf-ospf-te-link-attr-reuse-12
>> Linda,
>> On 29/05/2020 16:52, Linda Dunbar wrote:
>>> Peter,
>>> You said:
>>> /we are not defining any new attributes./ /We are allowing an
>>> existing link attributes to be used by other applications, including,
>>> but not limited to SRTE./ What prevent a node (or an application on
>>> the node) receiving the LSA from using the attributes carried by the 
LSA?
>> the problem with existing advertisement is that RSVP-TE will use it,
>> even if it was not intended to be used by RSVP-TE.
>> We are providing a way to explicitly advertised apps that are allowed
>> to use the advertised attributes.
>>> If no new attributes are
>>> to be added, then why need a new ASLA sub-TLV?
>> to be able to use the existing attributes for new apps, other than 
RSVP-TE.
>> thanks,
>> Peter
>>> Linda
>>> -Original Message-
>>> From: Peter Psenak mailto:ppse...@cisco.com>>
>>> Sent: Friday, May 29, 2020 5:51 AM
>>> To: Linda Dunbar >> >;
>> gen-...@ietf.org 
>>> Cc: last-c...@ietf.org ; lsr@ietf.org
>> ;
>>> draft-ietf-ospf-te-link-attr-reuse@ietf.org
>> 
>>> Subject: Re: Genart last call review of
>>> draft-ietf-ospf-te-link-attr-reuse-12
>>> Hi Linda,
>>> On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:
 Reviewer: Linda Dunbar
 Review result: Not Ready

 I am the assigned Gen-ART reviewer for this draft. The General Area
 Review Team (Gen-ART) reviews all IETF documents being processed by
 the IESG for the IETF Chair.

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-06-09 Thread Peter Psenak 

Linda,

On 09/06/2020 02:37, Linda Dunbar wrote:

Peter,

Thank you very much for adding the extra text to explain.

But SR is supposed to be transparent to all intermediate nodes. Does your draft 
require a node to be specifically configured for each link to support or not 
support SR or RSVP-TE?


the draft does not pose any new requirements in terms of how 
applications are enabled.


Please note that RSVP-TE is typically enabled per interface, SRTE is 
typically enabled on a per node basis.




In addition, there is no new attributes described in the document. So if a node 
is advertising TE related attributes for a specific link, such as bandwidth, 
delay,  what kind problems this node will encounter if a remote node utilize 
those TE specific attributes?


the problem is when the link attributes advertise for the purpose of 
application other than RSVP-TE is mistakenly used by RSVP-TE.


thanks,
Peter





Linda Dunbar

-Original Message-
From: Peter Psenak 
Sent: Monday, June 1, 2020 11:01 AM
To: Linda Dunbar ; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda,


On 01/06/2020 17:30, Linda Dunbar wrote:

Peter,
You said:
/“//the problem with existing advertisement is that RSVP-TE will use
it, even if it was not intended to be used by RSVP-TE.//”/ What is the
problem if RSVP-TE use the advertisement? What specific attributes
that RSVP-TE shouldn’t use?


Following text has been added to the draft based on comments from Scott.

"An example where this ambiguity causes problem is a network which has RSVP-TE 
enabled on one subset of links, and SRTE enabled on a different subset. A link attribute 
is advertised for the purpose of some other application (e.g. SRTE) for a link that is 
not enabled for RSV-TE. As soon as the router that is an RSVP-TE head-end sees the link 
attribute being advertised for such link, it assumes RSVP-TE is enabled on that link, 
even though in reality, RSVP-TE is not enabled on it. If such RSVP-TE head-end router 
tries to setup an RSVP-TE path via link where RSVP-TE is not enabled it will result in 
the path setup failure."

Hope it makes it clear and addresses your question.

thanks,
Peter






Linda Dunbar
-Original Message-
From: Peter Psenak 
Sent: Friday, May 29, 2020 10:00 AM
To: Linda Dunbar ; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org;
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of
draft-ietf-ospf-te-link-attr-reuse-12
Linda,
On 29/05/2020 16:52, Linda Dunbar wrote:

Peter,
You said:
/we are not defining any new attributes./ /We are allowing an
existing link attributes to be used by other applications, including,
but not limited to SRTE./ What prevent a node (or an application on
the node) receiving the LSA from using the attributes carried by the LSA?

the problem with existing advertisement is that RSVP-TE will use it,
even if it was not intended to be used by RSVP-TE.
We are providing a way to explicitly advertised apps that are allowed
to use the advertised attributes.

If no new attributes are
to be added, then why need a new ASLA sub-TLV?

to be able to use the existing attributes for new apps, other than RSVP-TE.
thanks,
Peter

Linda
-Original Message-
From: Peter Psenak mailto:ppse...@cisco.com>>
Sent: Friday, May 29, 2020 5:51 AM
To: Linda Dunbar mailto:linda.dun...@futurewei.com>>;

gen-...@ietf.org 

Cc: last-c...@ietf.org ; lsr@ietf.org

;

draft-ietf-ospf-te-link-attr-reuse@ietf.org



Subject: Re: Genart last call review of
draft-ietf-ospf-te-link-attr-reuse-12
Hi Linda,
On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:

Reviewer: Linda Dunbar
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.  Please treat these comments just like
any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-te-link-attr-reuse-??
Reviewer: Linda Dunbar
Review Date: 2020-05-28
IETF LC End Date: 2020-05-29
IESG Telechat date: Not scheduled for a telechat

Summary: this document introduces a new link attribute advertisement
in OSPFv2 and OSPFv3 to address general link properties needed for
new applications, such as Segment Routing.

Major issues:
The document has good description on the TLV structure of the
Application

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-06-08 Thread Linda Dunbar 
Peter, 

Thank you very much for adding the extra text to explain. 

But SR is supposed to be transparent to all intermediate nodes. Does your draft 
require a node to be specifically configured for each link to support or not 
support SR or RSVP-TE?

In addition, there is no new attributes described in the document. So if a node 
is advertising TE related attributes for a specific link, such as bandwidth, 
delay,  what kind problems this node will encounter if a remote node utilize 
those TE specific attributes? 

Linda Dunbar

-Original Message-
From: Peter Psenak  
Sent: Monday, June 1, 2020 11:01 AM
To: Linda Dunbar ; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda,


On 01/06/2020 17:30, Linda Dunbar wrote:
> Peter,
> You said:
> /“//the problem with existing advertisement is that RSVP-TE will use 
> it, even if it was not intended to be used by RSVP-TE.//”/ What is the 
> problem if RSVP-TE use the advertisement? What specific attributes 
> that RSVP-TE shouldn’t use?

Following text has been added to the draft based on comments from Scott.

"An example where this ambiguity causes problem is a network which has RSVP-TE 
enabled on one subset of links, and SRTE enabled on a different subset. A link 
attribute is advertised for the purpose of some other application (e.g. SRTE) 
for a link that is not enabled for RSV-TE. As soon as the router that is an 
RSVP-TE head-end sees the link attribute being advertised for such link, it 
assumes RSVP-TE is enabled on that link, even though in reality, RSVP-TE is not 
enabled on it. If such RSVP-TE head-end router tries to setup an RSVP-TE path 
via link where RSVP-TE is not enabled it will result in the path setup failure."

Hope it makes it clear and addresses your question.

thanks,
Peter





> Linda Dunbar
> -Original Message-
> From: Peter Psenak 
> Sent: Friday, May 29, 2020 10:00 AM
> To: Linda Dunbar ; gen-...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org; 
> draft-ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: Genart last call review of
> draft-ietf-ospf-te-link-attr-reuse-12
> Linda,
> On 29/05/2020 16:52, Linda Dunbar wrote:
>> Peter,
>> You said:
>> /we are not defining any new attributes./ /We are allowing an 
>> existing link attributes to be used by other applications, including, 
>> but not limited to SRTE./ What prevent a node (or an application on 
>> the node) receiving the LSA from using the attributes carried by the LSA?
> the problem with existing advertisement is that RSVP-TE will use it, 
> even if it was not intended to be used by RSVP-TE.
> We are providing a way to explicitly advertised apps that are allowed 
> to use the advertised attributes.
>> If no new attributes are
>> to be added, then why need a new ASLA sub-TLV?
> to be able to use the existing attributes for new apps, other than RSVP-TE.
> thanks,
> Peter
>> Linda
>> -Original Message-
>> From: Peter Psenak mailto:ppse...@cisco.com>>
>> Sent: Friday, May 29, 2020 5:51 AM
>> To: Linda Dunbar > >;
> gen-...@ietf.org 
>> Cc: last-c...@ietf.org ; lsr@ietf.org
> ;
>> draft-ietf-ospf-te-link-attr-reuse@ietf.org
> 
>> Subject: Re: Genart last call review of
>> draft-ietf-ospf-te-link-attr-reuse-12
>> Hi Linda,
>> On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:
>>> Reviewer: Linda Dunbar
>>> Review result: Not Ready
>>> 
>>> I am the assigned Gen-ART reviewer for this draft. The General Area 
>>> Review Team (Gen-ART) reviews all IETF documents being processed by 
>>> the IESG for the IETF Chair.  Please treat these comments just like 
>>> any other last call comments.
>>> 
>>> For more information, please see the FAQ at
>>> 
>>> .
>>> 
>>> Document: draft-ietf-ospf-te-link-attr-reuse-??
>>> Reviewer: Linda Dunbar
>>> Review Date: 2020-05-28
>>> IETF LC End Date: 2020-05-29
>>> IESG Telechat date: Not scheduled for a telechat
>>> 
>>> Summary: this document introduces a new link attribute advertisement 
>>> in OSPFv2 and OSPFv3 to address general link properties needed for 
>>> new applications, such as Segment Routing.
>>> 
>>> Major issues:
>>> The document has good description on the TLV structure of the 
>>> Application specific Advertisements, but fails to describe what are 
>>> the NEW Link attributes needed by Segment Routing. Page 7 (section 
>>> 5) has a really good description on all the link properties added

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-06-01 Thread Peter Psenak 

Hi Linda,


On 01/06/2020 17:30, Linda Dunbar wrote:

Peter,
You said:
/“//the problem with existing advertisement is that RSVP-TE will use it, 
even if it was not intended to be used by RSVP-TE.//”/
What is the problem if RSVP-TE use the advertisement? What specific 
attributes that RSVP-TE shouldn’t use?


Following text has been added to the draft based on comments from Scott.

"An example where this ambiguity causes problem is a network which has 
RSVP-TE enabled on one subset of links, and SRTE enabled on a different 
subset. A link attribute is advertised for the purpose of some other 
application (e.g. SRTE) for a link that is not enabled for RSV-TE. As 
soon as the router that is an RSVP-TE head-end sees the link attribute 
being advertised for such link, it assumes RSVP-TE is enabled on that 
link, even though in reality, RSVP-TE is not enabled on it. If such 
RSVP-TE head-end router tries to setup an RSVP-TE path via link where 
RSVP-TE is not enabled it will result in the path setup failure."


Hope it makes it clear and addresses your question.

thanks,
Peter






Linda Dunbar
-Original Message-
From: Peter Psenak 
Sent: Friday, May 29, 2020 10:00 AM
To: Linda Dunbar ; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of 
draft-ietf-ospf-te-link-attr-reuse-12

Linda,
On 29/05/2020 16:52, Linda Dunbar wrote:

Peter,
You said:
/we are not defining any new attributes./ /We are allowing an existing 
link attributes to be used by other applications, including, but not 
limited to SRTE./ What prevent a node (or an application on the node) 
receiving the LSA from using the attributes carried by the LSA?
the problem with existing advertisement is that RSVP-TE will use it, 
even if it was not intended to be used by RSVP-TE.
We are providing a way to explicitly advertised apps that are allowed to 
use the advertised attributes.

If no new attributes are
to be added, then why need a new ASLA sub-TLV?

to be able to use the existing attributes for new apps, other than RSVP-TE.
thanks,
Peter

Linda
-Original Message-
From: Peter Psenak mailto:ppse...@cisco.com>>
Sent: Friday, May 29, 2020 5:51 AM
To: Linda Dunbar mailto:linda.dun...@futurewei.com>>; 

gen-...@ietf.org 
Cc: last-c...@ietf.org ; lsr@ietf.org 

;
draft-ietf-ospf-te-link-attr-reuse@ietf.org 



Subject: Re: Genart last call review of
draft-ietf-ospf-te-link-attr-reuse-12
Hi Linda,
On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:

Reviewer: Linda Dunbar
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by 
the IESG for the IETF Chair.  Please treat these comments just like 
any other last call comments.


For more information, please see the FAQ at

.

Document: draft-ietf-ospf-te-link-attr-reuse-??
Reviewer: Linda Dunbar
Review Date: 2020-05-28
IETF LC End Date: 2020-05-29
IESG Telechat date: Not scheduled for a telechat

Summary: this document introduces a new link attribute advertisement 
in OSPFv2 and OSPFv3 to address general link properties needed for 
new applications, such as Segment Routing.


Major issues:
The document has good description on the TLV structure of the 
Application specific Advertisements, but fails to describe what are 
the NEW Link attributes needed by Segment Routing. Page 7 (section 5) 
has a really good description on all the link properties added to 
OSFP (RFC4203, RFC 7308, RFC7471, RFC3630) to achieve TE. I can see 
Segment Routing would need each node to advertise its own SID and the 
SIDs of adjacent nodes. Can't they be encoded (or extended) in OSPF's NODE ID?

we are not defining any new attributes.
We are allowing an existing link attributes to be used by other 
applications, including, but not limited to SRTE.

thanks,
Peter


Minor issues:

Nits/editorial comments:

Best regards,

Linda Dunbar






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

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-06-01 Thread Linda Dunbar 
Peter,

You said:

  “the problem with existing advertisement is that RSVP-TE will use it, 
even if it was not intended to be used by RSVP-TE.”

What is the problem if RSVP-TE use the advertisement? What specific attributes 
that RSVP-TE shouldn’t use?


Linda Dunbar


-Original Message-
From: Peter Psenak 
Sent: Friday, May 29, 2020 10:00 AM
To: Linda Dunbar ; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Linda,

On 29/05/2020 16:52, Linda Dunbar wrote:
> Peter,
> You said:
> /we are not defining any new attributes./ /We are allowing an existing
> link attributes to be used by other applications, including, but not
> limited to SRTE./ What prevent a node (or an application on the node)
> receiving the LSA from using the attributes carried by the LSA?

the problem with existing advertisement is that RSVP-TE will use it, even if it 
was not intended to be used by RSVP-TE.

We are providing a way to explicitly advertised apps that are allowed to use 
the advertised attributes.

> If no new attributes are
> to be added, then why need a new ASLA sub-TLV?

to be able to use the existing attributes for new apps, other than RSVP-TE.


thanks,
Peter

> Linda
> -Original Message-
> From: Peter Psenak mailto:ppse...@cisco.com>>
> Sent: Friday, May 29, 2020 5:51 AM
> To: Linda Dunbar 
> mailto:linda.dun...@futurewei.com>>; 
> gen-...@ietf.org
> Cc: last-c...@ietf.org; 
> lsr@ietf.org;
> draft-ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: Genart last call review of
> draft-ietf-ospf-te-link-attr-reuse-12
> Hi Linda,
> On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:
>> Reviewer: Linda Dunbar
>> Review result: Not Ready
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed by
>> the IESG for the IETF Chair.  Please treat these comments just like
>> any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> .
>>
>> Document: draft-ietf-ospf-te-link-attr-reuse-??
>> Reviewer: Linda Dunbar
>> Review Date: 2020-05-28
>> IETF LC End Date: 2020-05-29
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary: this document introduces a new link attribute advertisement
>> in OSPFv2 and OSPFv3 to address general link properties needed for
>> new applications, such as Segment Routing.
>>
>> Major issues:
>> The document has good description on the TLV structure of the
>> Application specific Advertisements, but fails to describe what are
>> the NEW Link attributes needed by Segment Routing. Page 7 (section 5)
>> has a really good description on all the link properties added to
>> OSFP (RFC4203, RFC 7308, RFC7471, RFC3630) to achieve TE. I can see
>> Segment Routing would need each node to advertise its own SID and the
>> SIDs of adjacent nodes. Can't they be encoded (or extended) in OSPF's NODE 
>> ID?
> we are not defining any new attributes.
> We are allowing an existing link attributes to be used by other
> applications, including, but not limited to SRTE.
> thanks,
> Peter
>>
>> Minor issues:
>>
>> Nits/editorial comments:
>>
>> Best regards,
>>
>> Linda Dunbar
>>
>>
>>
>>


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

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-05-29 Thread Peter Psenak 

Linda,

On 29/05/2020 16:52, Linda Dunbar wrote:

Peter,
You said:
/we are not defining any new attributes./
/We are allowing an existing link attributes to be used by other 
applications, including, but not limited to SRTE./
What prevent a node (or an application on the node) receiving the LSA 
from using the attributes carried by the LSA?  


the problem with existing advertisement is that RSVP-TE will use it, 
even if it was not intended to be used by RSVP-TE.


We are providing a way to explicitly advertised apps that are allowed to 
use the advertised attributes.


If no new attributes are 
to be added, then why need a new ASLA sub-TLV?


to be able to use the existing attributes for new apps, other than RSVP-TE.


thanks,
Peter


Linda
-Original Message-
From: Peter Psenak 
Sent: Friday, May 29, 2020 5:51 AM
To: Linda Dunbar ; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of 
draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda,
On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:

Reviewer: Linda Dunbar
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by 
the IESG for the IETF Chair.  Please treat these comments just like 
any other last call comments.


For more information, please see the FAQ at

.

Document: draft-ietf-ospf-te-link-attr-reuse-??
Reviewer: Linda Dunbar
Review Date: 2020-05-28
IETF LC End Date: 2020-05-29
IESG Telechat date: Not scheduled for a telechat

Summary: this document introduces a new link attribute advertisement 
in OSPFv2 and OSPFv3 to address general link properties needed for new 
applications, such as Segment Routing.


Major issues:
The document has good description on the TLV structure of the 
Application specific Advertisements, but fails to describe what are 
the NEW Link attributes needed by Segment Routing. Page 7 (section 5) 
has a really good description on all the link properties added to OSFP 
(RFC4203, RFC 7308, RFC7471, RFC3630) to achieve TE. I can see Segment 
Routing would need each node to advertise its own SID and the SIDs of 
adjacent nodes. Can't they be encoded (or extended) in OSPF's NODE ID?

we are not defining any new attributes.
We are allowing an existing link attributes to be used by other 
applications, including, but not limited to SRTE.

thanks,
Peter


Minor issues:

Nits/editorial comments:

Best regards,

Linda Dunbar






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

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-05-29 Thread Linda Dunbar 
Peter,

You said:

  we are not defining any new attributes.

  We are allowing an existing link attributes to be used by other 
applications, including, but not limited to SRTE.

What prevent a node (or an application on the node) receiving the LSA from 
using the attributes carried by the LSA?  If no new attributes are to be added, 
then why need a new ASLA sub-TLV?


Linda

-Original Message-
From: Peter Psenak 
Sent: Friday, May 29, 2020 5:51 AM
To: Linda Dunbar ; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda,

On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:
> Reviewer: Linda Dunbar
> Review result: Not Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please treat these comments just like
> any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-ospf-te-link-attr-reuse-??
> Reviewer: Linda Dunbar
> Review Date: 2020-05-28
> IETF LC End Date: 2020-05-29
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: this document introduces a new link attribute advertisement
> in OSPFv2 and OSPFv3 to address general link properties needed for new
> applications, such as Segment Routing.
>
> Major issues:
> The document has good description on the TLV structure of the
> Application specific Advertisements, but fails to describe what are
> the NEW Link attributes needed by Segment Routing. Page 7 (section 5)
> has a really good description on all the link properties added to OSFP
> (RFC4203, RFC 7308, RFC7471, RFC3630) to achieve TE. I can see Segment
> Routing would need each node to advertise its own SID and the SIDs of
> adjacent nodes. Can't they be encoded (or extended) in OSPF's NODE ID?

we are not defining any new attributes.

We are allowing an existing link attributes to be used by other applications, 
including, but not limited to SRTE.

thanks,
Peter

>
> Minor issues:
>
> Nits/editorial comments:
>
> Best regards,
>
> Linda Dunbar
>
>
>
>


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

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-05-29 Thread Peter Psenak 

Hi Linda,

On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:

Reviewer: Linda Dunbar
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-te-link-attr-reuse-??
Reviewer: Linda Dunbar
Review Date: 2020-05-28
IETF LC End Date: 2020-05-29
IESG Telechat date: Not scheduled for a telechat

Summary: this document introduces a new link attribute advertisement in OSPFv2
and OSPFv3 to address general link properties needed for new applications, such
as Segment Routing.

Major issues:
The document has good description on the TLV structure of the Application
specific Advertisements, but fails to describe what are the NEW Link attributes
needed by Segment Routing. Page 7 (section 5) has a really good description on
all the link properties added to OSFP (RFC4203, RFC 7308, RFC7471, RFC3630) to
achieve TE. I can see Segment Routing would need each node to advertise its own
SID and the SIDs of adjacent nodes. Can't they be encoded (or extended) in
OSPF's NODE ID?


we are not defining any new attributes.

We are allowing an existing link attributes to be used by other 
applications, including, but not limited to SRTE.


thanks,
Peter



Minor issues:

Nits/editorial comments:

Best regards,

Linda Dunbar






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