Re: [Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

[Les Ginsberg (ginsberg)]

Bruno -

Thanx for your (as always) meticulous review.
Responses inline.
Once we have reached agreement I will send out an updated version.

> -Original Message-
> From: Bruno Decraene via Datatracker 
> Sent: Friday, May 29, 2020 10:18 AM
> To: rtg-...@ietf.org
> Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org
> Subject: Rtgdir last call review of draft-ietf-isis-te-app-13
> 
> Reviewer: Bruno Decraene
> Review result: Has Issues
> 
>  Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft. The
> Routing Directorate seeks to review all routing or routing-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs.
> For more information about the Routing Directorate, please see
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs, it
> would
> be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion or
> by
> updating the draft.
> 
> Document: draft-ietf-isis-te-app-13
> Reviewer: Bruno Decraene
> Review Date: 2020-05-29
> IETF LC End Date: 2020-05-29
> Intended Status: Standards Track
> 
> Summary:
> I have some minor concerns about this document that I think should be
> resolved before publication.
> 
> Comments:
>   Draft is clear.
> 
> Minor Issues:
> 
> §4.1
> *2 (for SABM & UDABM fields)
> OLD: The length SHOULD be the minimum required to send all bits which are
> set.
> I'd propose
> NEW: The length SHOULD be the minimum required to send all the
> meaningful bits
> which are set.
> 
> Motivation; the 'bits which are sent' are the bits in the SABM field. (they do
> include non-meaningful and padding bits)
> 

[Les:] The definition of what is "meaningful" and what is "padding"  to me is 
ambiguous.
Meaningful could be only those bits which are currently defined in the registry 
(speaking of SABM here). But if there are 10 bits defined in the registry and I 
only intend to set Bit 5, I do not need to send all 10 bits - I only need to 
send one octet - because we state:

"Bits that are NOT transmitted MUST be treated as if they
   are set to 0 on receipt.  "

Also, an implementation written when there were only 4 bits defined in the 
registry might think that "meaningful" is different than an implementation 
written when more than 8 bits were defined in the registry. Yet they can still 
interoperate.

I believe the current language is best.

> 
> 
> OLD: Undefined bits MUST be transmitted as 0
> NEW: Undefined transmitted bits MUST be cleared (0)
> 
> Motivation: currently the number of undefined bits is 8*8-3. They SHOULD
> not be
> transmitted (beyond the first ones fitting in the first N required octet). The
> sentence "Undefined bits MUST be transmitted as 0" could be read as all
> defined
> bits MUST be transmitted (as 0).
> ---
[Les:] I do not see how that could be a valid interpretation given that we 
state:

" The length SHOULD  be the minimum required to send all bits which are set."

And (repeating)

"Bits that are NOT transmitted MUST be treated as if they
   are set to 0 on receipt.  "

And again, you assume that "defined bits" is the same for all implementations - 
which isn't guaranteed as I discussed above.


> User Defined Application Identifier Bits have no name. I'd propose to call
> them
> UDABM[0], UDABM[1]... This may avoid that different implementation use
> different names and, more problematic, that some implementations starting
> with
> 1 (the first, the second) while while some other implementations starts as 0,
> creating interop issues (SABM[1] on node A is SABM[0] on node B)
> ---

[Les:] What implementations may name bits they assign from the User space is 
out of scope of this document.
If I were implementing a non-standard User App I likely would give it a 
meaningful name both in my code and in any documentation I produce.

As far as interoperability, if you want multiple vendors to interoperate then 
you need a standard application. User defined applications do not provide any 
guarantee of interoperability.

We do state that 

"It is recommended that [user defined] bits are used starting with Bit 0..."

but as User Defined Applications are outside the scope of the document they 
might choose to do otherwise.


> §4.2
> 
> "In cases where conflicting values for the same application/attribute/link are
> advertised all the conflicting values MUST be ignored." I'd propose to add
> "for
> this application" (IOW, those values are still applicable for all other
> applications)
> ---

[Les:] How about adding "for the specified application" ?



> §6.2
> I'd argue that the first part of section 3.2 is a specification of the 
> behavior
> and hence should be moved to section 4.1, rather than placed in the section
> "deploy

[Lsr] lsr - New Meeting Session Request for IETF 108

[IETF Meeting Session Request Tool]

A new meeting session request has just been submitted by Christian Hopps, a 
Chair of the lsr working group.


-
Working Group Name: Link State Routing
Area Name: Routing Area
Session Requester: Christian Hopps


Number of Sessions: 1
Length of Session(s):  100 Minutes
Number of Attendees: 100
Conflicts to Avoid: 
 Chair Conflict: ipsecme idr rtgwg lsvr
 Technology Overlap: rift spring
 Key Participant Conflict: bfd bess





People who must be present:
  Acee Lindem
  Christian Hopps
  Alvaro Retana

Resources Requested:

Special Requests:
  
-


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

[Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

[Bruno Decraene via Datatracker]

Reviewer: Bruno Decraene
Review result: Has Issues

 Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-isis-te-app-13
Reviewer: Bruno Decraene
Review Date: 2020-05-29
IETF LC End Date: 2020-05-29
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be
resolved before publication.

Comments:
  Draft is clear.

Minor Issues:

§4.1
*2 (for SABM & UDABM fields)
OLD: The length SHOULD be the minimum required to send all bits which are set.
I'd propose
NEW: The length SHOULD be the minimum required to send all the meaningful bits
which are set.

Motivation; the 'bits which are sent' are the bits in the SABM field. (they do
include non-meaningful and padding bits)



OLD: Undefined bits MUST be transmitted as 0
NEW: Undefined transmitted bits MUST be cleared (0)

Motivation: currently the number of undefined bits is 8*8-3. They SHOULD not be
transmitted (beyond the first ones fitting in the first N required octet). The
sentence "Undefined bits MUST be transmitted as 0" could be read as all defined
bits MUST be transmitted (as 0).
---
User Defined Application Identifier Bits have no name. I'd propose to call them
UDABM[0], UDABM[1]... This may avoid that different implementation use
different names and, more problematic, that some implementations starting with
1 (the first, the second) while while some other implementations starts as 0,
creating interop issues (SABM[1] on node A is SABM[0] on node B)
---
§4.2

"In cases where conflicting values for the same application/attribute/link are
advertised all the conflicting values MUST be ignored." I'd propose to add "for
this application" (IOW, those values are still applicable for all other
applications)
---
§6.2
I'd argue that the first part of section 3.2 is a specification of the behavior
and hence should be moved to section 4.1, rather than placed in the section
"deployment consideration" which eventually will not be read by someone
implementing the specification. Especially since the text in section 4.1
implies a different behavior: "Bits that are NOT transmitted MUST be treated as
if they are set to 0 on receipt."
---
§5
"In the case of SRTE, advertisement of application specific link attributes
does NOT indicate enablement of SRTE." What does "enablement of SRTE" means? Do
you have a pointer to a document/text?

I'm not sure I would keep that paragraph on SR-TE enablement.
---
§6.1
"Under the conditions defined above, implementations which support the
   extensions defined in this document have the choice of using legacy
   advertisements or application specific advertisements in support of
   SRTE and/or LFA.  This will require implementations to provide
   controls specifying which type of advertisements are to be sent/
   processed on receive for these applications."

I think that "have the choice" is not prescriptive enough given the deployment
issues described in section 6.3 I'd rather say that implementations MUST
support the use of both advertisements (legacy and application specific
advertisement) and MUST provide controls specifying which type of
advertisements are to be processed on receive for these applications.


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

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

[Daniele Ceccarelli via Datatracker]

Reviewer: Daniele Ceccarelli
Review result: Has Nits

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-ospf-te-link-attr-reuse-12
Reviewer: Daniele Ceccarelli
Review Date: 2020-05-29
IETF LC End Date: date-if-known
Intended Status: Standard Track

Summary:

The readibility of the draft has been significantly improved since my last
review (v07), mostly the abstract and the introduction, which now cleary state
what is the scope of the draft. I also appreciated the introduction of section
3 where a description of the existing solution is described.

Minor issues:
- Section 4.1 - Advantages with respect to RSVP-TE are described while the text
speaks about advantages with respect to RSVP-TE and GMPLS, probably it could be
changed into: advantages with respect to RSVP-TE when used in packet networks
and in GMPLS, something like this. - Section 5 - Why for the UDABM it doens't
say the value MUST be 0,4,8 but rather says "the legal values are" ? Is 8
octets future-proof enough? or conversely, if only 3 values are defined why do
we need 8 octects as option? - Section 8 - I really find it hard to understand
this small section.

Typos:
-  Unidirectional Link Dela [RFC7471]



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

Re: [Lsr] Genart last call review of draft-ietf-isis-te-app-13

[Les Ginsberg (ginsberg)]

Jouni -

Thanx for the review.

I have addressed the editorial issues you raised - though I will wait for 
additional comments from other reviewers before publishing a new version.

   Les


> -Original Message-
> From: Jouni Korhonen via Datatracker 
> Sent: Friday, May 29, 2020 6:11 AM
> To: gen-...@ietf.org
> Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org
> Subject: Genart last call review of draft-ietf-isis-te-app-13
> 
> Reviewer: Jouni Korhonen
> Review result: Ready with Nits
> 
> 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-isis-te-app-??
> Reviewer: Jouni Korhonen
> Review Date: 2020-05-29
> IETF LC End Date: 2020-05-29
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Not really my area of expertise, however, I did not spot any issues during the
> review. The document is ready for publication.
> 
> Major issues:
> 
> None.
> 
> Minor issues:
> 
> None.
> 
> Nits/editorial comments:
> 
> * There are spacing issues mostly with parenthesis in the text that the RFC
> editor likely takes care of. * On line 165 SR is used without expanding it. 
> The
> expansion is obvious but the RFC has both "Segment Routing" and "Shared
> Risk"
> used with SRxx.. * At least Section 5 has "is NOT" and "does NOT" emphasis
> used. I would use just "is not" and "does not", since those with "NOT" are
> not
> in listed in normal "Requirements Language".
> 

___
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

[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] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huzhibo]

I support this adaption.It propose an algorithm for node to compute a flooding 
topology.It is useful for reduce flooding.

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com

发件人：Acee Lindem (acee) 
收件人：lsr 
时 间：2020-05-16 03:40:29
主 题：[Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/

Thanks,
Acee
___
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

[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

[Lsr] Genart last call review of draft-ietf-isis-te-app-13

[Jouni Korhonen via Datatracker]

Reviewer: Jouni Korhonen
Review result: Ready with Nits

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-isis-te-app-??
Reviewer: Jouni Korhonen
Review Date: 2020-05-29
IETF LC End Date: 2020-05-29
IESG Telechat date: Not scheduled for a telechat

Summary:

Not really my area of expertise, however, I did not spot any issues during the
review. The document is ready for publication.

Major issues:

None.

Minor issues:

None.

Nits/editorial comments:

* There are spacing issues mostly with parenthesis in the text that the RFC
editor likely takes care of. * On line 165 SR is used without expanding it. The
expansion is obvious but the RFC has both "Segment Routing" and "Shared Risk"
used with SRxx.. * At least Section 5 has "is NOT" and "does NOT" emphasis
used. I would use just "is not" and "does not", since those with "NOT" are not
in listed in normal "Requirements Language".


___
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

[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