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

[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-art@ietf.org
Cc: last-c...@ietf.org; l...@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-art@ietf.org
Cc: last-c...@ietf.org; l...@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-art@ietf.org 

Cc: last-c...@ietf.org ; l...@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 s

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

[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-art@ietf.org
> Cc: last-c...@ietf.org; l...@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-art@ietf.org
>> Cc: last-c...@ietf.org; l...@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-art@ietf.org 
>>> Cc: last-c...@ietf.org ; l...@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 Chai

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

[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-art@ietf.org
Cc: last-c...@ietf.org; l...@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-art@ietf.org
> Cc: last-c...@ietf.org; l...@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-art@ietf.org
>> Cc: last-c...@ietf.org; l...@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 abl

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

[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-art@ietf.org
Cc: last-c...@ietf.org; l...@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-art@ietf.org
 > Cc: last-c...@ietf.org; l...@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-art@ietf.org
 >> Cc: last-c...@ietf.org; l...@ietf.org;
 >> draft-i

Re: [Gen-art] [Id-event] Genart last call review of draft-ietf-secevent-http-poll-09

[Dick Hardt]

There were concerns mandating TLS for any SET as it restricts the use of
SET to TLS transports. I would guess the language in the
draft-ietf-secevent-http-pull and draft-ietf-secevent-http-poll followed
that thinking.

I my personal opinion, mandating TLS for HTTP transports is reasonable
(which is what the specs in discussion use), and that should be changed in
both draft-ietf-secevent-http-pull and draft-ietf-secevent-http-poll

/Dick

On Mon, Jun 8, 2020 at 6:18 PM Mike Jones 
wrote:

> I agree that the spec should give clear guidance on whether TLS is
> required.  People should read Phil Hunt's comments (which I just forwarded
> to the list) and consider where we'd like to land in this regard.
>
> I agree that if we decide to mandate TLS, rather than simply
> integrity-protected SETS, we should modify the Section 3 text below:
>The SET delivery method described in this specification is based upon
>HTTP and HTTP over TLS [RFC2818] and/or standard HTTP authentication
>and authorization schemes, as per [RFC7235].
> to remove the "HTTP and".
>
> Likewise, we'd need to revise 4.3 to remove the non-TLS choice.  We can
> also revise the first sentence of 4.4.1 to make it clear that 6750 requires
> TLS, regardless of other decisions we make.
>
> Note that some of the language in question is also present in
> draft-ietf-secevent-http-push, so we should apply consistent changes there
> as well.
>
> I hope to hear back from the working group with your thoughts this week.
>
> -- Mike
>
> -Original Message-
> From: Yaron Sheffer 
> Sent: Friday, June 5, 2020 9:36 AM
> To: Mike Jones ; Robert Sparks <
> rjspa...@nostrum.com>; gen-art@ietf.org; Valery Smyslov 
> Cc: last-c...@ietf.org; draft-ietf-secevent-http-poll@ietf.org;
> id-ev...@ietf.org
> Subject: Re: [Id-event] Genart last call review of
> draft-ietf-secevent-http-poll-09
>
> Hi Mike,
>
> The document is very ambiguous regarding the use of TLS, and frankly I
> wish we noticed it earlier.
>
> - The first sentence of Sec. 3 has TLS as one of two options: "The SET
> delivery method described in this specification is based upon HTTP and HTTP
> over TLS [RFC2818] and/or standard HTTP authentication and authorization
> schemes, as per [RFC7235]. "
>
> - Similarly in Sec. 4.3, TLS is mentioned as one alternative, not a
> requirement: "In such cases, SET Transmitters and SET Recipients MUST
> protect the confidentiality of the SET contents by encrypting the SET as
> described in JWE [RFC7516], using a transport-layer security mechanism such
> as TLS, or both. "
>
> - Sec. 4.4.1 (first sentence) also treats TLS as conditional.
>
> My personal opinion is that nowadays we can simply mandate TLS, but I'm
> open to discuss it. Whatever the WG chooses, the document needs to be clear
> and consistent.
>
> Thanks,
> Yaron
>
> On 6/5/20, 19:22, "Mike Jones"  wrote:
>
> That TLS is used is specified in the first sentence of the
> introduction at
> https://tools.ietf.org/html/draft-ietf-secevent-http-poll-09#section-1.
> It's also in the first paragraph of
> https://tools.ietf.org/html/draft-ietf-secevent-http-poll-09#section-3.
>
> The new privacy considerations text was requested by Valery Smyslov in
> the SecDir review of push.  I also added it here.  I did think it was odd
> that it was requested when TLS is required, but it seemed harmless to add
> it.  If you like, I could clarify that this should never occur.
>
> -- Mike
>
> -Original Message-
> From: Yaron Sheffer 
> Sent: Friday, June 5, 2020 8:26 AM
> To: Mike Jones ; Robert Sparks <
> rjspa...@nostrum.com>; gen-art@ietf.org
> Cc: last-c...@ietf.org; draft-ietf-secevent-http-poll@ietf.org;
> id-ev...@ietf.org
> Subject: Re: [Id-event] Genart last call review of
> draft-ietf-secevent-http-poll-09
>
> Hi Mike,
>
> I'm looking at the latest PR, specifically at the Poll document. I can
> see that you changed the text around signing SETs, but I don't see any new
> (or existing) text that requires HTTPS as you noted in your response to
> Robert.
>
> I even see this new text "If SETs are transmitted over unencrypted
> channels" that confuses me even more. For the latter, maybe you meant
> something like: If SETs are transmitted over unencrypted channels while
> being processed in an otherwise protected system.
>
> Thanks,
> Yaron
>
> On 6/5/20, 03:49, "Mike Jones"  wrote:
>
> Thanks for the quick reply.  My responses are inline, prefixed by
> "Mike>".
>
> -Original Message-
> From: Robert Sparks 
> Sent: Thursday, June 4, 2020 2:51 PM
> To: Mike Jones ; gen-art@ietf.org
> Cc: last-c...@ietf.org; draft-ietf-secevent-http-poll@ietf.org;
> id-ev...@ietf.org
> Subject: Re: [Id-event] Genart last call review of
> draft-ietf-secevent-http-poll-09
>
>
> On 6/4/20 4:27 PM, Mike Jones wrote:

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

[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-art@ietf.org
Cc: last-c...@ietf.org; l...@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-art@ietf.org
> Cc: last-c...@ietf.org; l...@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-art@ietf.org
>  > Cc: last-c...@ietf.org; l...@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?

[Gen-art] Genart last call review of draft-ietf-pce-stateful-pce-lsp-scheduling-13

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Ready with Issues

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-pce-stateful-pce-lsp-scheduling-13
Reviewer: Robert Sparks
Review Date: 2020-06-09
IETF LC End Date: 2020-06-12
IESG Telechat date: Not scheduled for a telechat

Summary: Essentially ready for publication as a Proposed Standard RFC, but with
issues to consider before progressing

Minor Issues:

Section 4.2.2: It's not clear when the computation for a path satisfying the
constraint happens. Is this done once when the periodical LSP arrives, or at
each scheduled interval? If the former, what happens if there is no path
solution for only one of the multiple intervals?

Section 4.4, second paragraph, last sentence: If the path cannot be set, is the
previous LSP left in effect? Or does the failure result in no there being no
scheduled LSPs in effect?

Section 5.1 first paragraph: Why is TCP called out here?

You should be explicit about whether it's ok to have both grace periods and
elastic bounds at the same time. The TLV allows that to happen. I'm not sure
what it would mean, and I suspect it's unlikely that you would have two
implementers compute the consequences the same way.

Section 5.2.1, definition of the R bit: You should call out that relative time
is in seconds (I think?) when the R bit is 1, and you need a discussion
somewhere about the necessity of synchronized clocks and potential problems
with transmission delay when the R bit is 1.

Section 5.2.1, definition of Start-Time: Why must a value of 0 not be used? Is
this true for both R=1 and R=0? For R=1, a start time value of 1 vs a start
time value of 0 may, in practice, be indistinguishable (because of transmission
or processing delay).

In section 5.2.2 at the definition of Repeat-time-length: Please be explicit
about whether this is the interval between the start time of two repetitions or
the interval between the end-time of one repetition and the start of the next
repetition. I think you mean the former.

At section 5.2.1 you say this TLV SHOULD NOT be included unless both PCEP peers
have set the B bit. But in section 6.6, you say MUST NOT. Please choose one. I
think you want both places to say MUST NOT.

Nits:

Introduction, paragraph 3, second sentence: This is hard to read. I suggest
trying to break it into more than one sentence.

Introduction, paragraph 4, third sentence: This is hard to read. Please
simplify.

The document uses both "database" and "data base". Please pick one.

Top of page 7: "In case of former" does not parse. Please clarify.

Section 4.2.2, second paragraph, first sentence: Does not parse. I think it is
missing more than articles.

Section 4.3 at "In both modes": It's not clear what "modes" means here.

It would be worth calling out in section 5.1 that setting PD requires setting B
as specified in 5.2.2.

It would be helpful in 5.2.2 at the definition of Opt: to point forward to the
registry you are creating for its values. It would also be good to be explicit
about what to do if an element receives a TLV with a value here it does not
understand yet.

Section 9.1 ignores leap-years and leap-seconds. It's worth explicitly noting
that.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart telechat review of draft-ietf-ospf-te-link-attr-reuse-14

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Ready with Issues

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-ospf-te-link-attr-reuse-14
Reviewer: Linda Dunbar
Review Date: 2020-06-09
IETF LC End Date: 2020-05-29
IESG Telechat date: 2020-06-11

Summary:

This document proposes a new OSPF  Link attribute to indicate the intended
purpose of the advertised TE information. So that if the RSVP-TE is not enabled
on a link, the TE attributes of the Link being advertised can't be used by
remote receiving nodes for  RSVP-TE purpose.

It would be useful if the authors can add a statement to explain the scenario
when a node only has a subset of links supporting RSVP-TE but is capable of
advertising TE related attributes for the links that are not enabled for
RSVP-TE.  Just wondering what reasons that some links can collect TE attributes
but not enabled for RSVP-TE.

I have reviewed this draft multiple times, provided comments to -11, -12
version. The authors have addressed many of them in the -14 version.  Many
thanks.

Major issues:

Minor issues:

Nits/editorial comments:

Best Regards,

Linda Dunbar


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art