Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-rfc5306bis-06: (with COMMENT)

[Les Ginsberg (ginsberg)]

Roman -

Thanx for the review.
I have uploaded V7 of the draft to address your comments.

Responses inline.

> -Original Message-
> From: Roman Danyliw via Datatracker 
> Sent: Wednesday, September 18, 2019 7:45 AM
> To: The IESG 
> Cc: draft-ietf-lsr-isis-rfc5306...@ietf.org; Uma Chunduri
> ; aretana.i...@gmail.com; lsr-cha...@ietf.org;
> uma.chund...@huawei.com; lsr@ietf.org
> Subject: Roman Danyliw's No Objection on draft-ietf-lsr-isis-rfc5306bis-06:
> (with COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-lsr-isis-rfc5306bis-06: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/
> 
> 
> 
> --
> COMMENT:
> --
> 
> (1) Section 3.1.  The two “NOTE” statements in this section seem to conflict:
> -- NOTE: These timers are NOT applicable to a router which is preparing to do
> a
> planned restart.
> 
> -- NOTE: The timer T3 is only used by a restarting router.

[Les:] I have added text indicating that T1/T2 can be used both by a restarting 
router and starting router (details were already provided in the respective 
sections later in the document) but that T3 is only used by a restarting router.
The second NOTE has been deleted.

> 
> (2) Per the definition of the “Remaining Time” field, when is it the 
> “remaining
> holding time” vs. “recommended holding time"

[Les:] I have removed the term "recommended" which is not otherwise used in the 
document.

> 
> (3) Editorial Nits:
> -- Multiple places.  s/signalling/signaling/g

[Les:] It depends whether you are British or not. 
As the original lead author of RFC 5306 was British I have conformed to the 
British spelling.
If you think that is not right, I suggest we let the RFC Editor decide.

Les

> 

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

[Lsr] I-D Action: draft-ietf-lsr-isis-rfc5306bis-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Restart Signaling for IS-IS
Authors : Les Ginsberg
  Paul Wells
Filename: draft-ietf-lsr-isis-rfc5306bis-07.txt
Pages   : 25
Date: 2019-09-18

Abstract:
   This document describes a mechanism for a restarting router to signal
   to its neighbors that it is restarting, allowing them to reestablish
   their adjacencies without cycling through the down state, while still
   correctly initiating database synchronization.

   This document additionally describes a mechanism for a router to
   signal its neighbors that it is preparing to initiate a restart while
   maintaining forwarding plane state.  This allows the neighbors to
   maintain their adjacencies until the router has restarted, but also
   allows the neighbors to bring the adjacencies down in the event of
   other topology changes.

   This document additionally describes a mechanism for a restarting
   router to determine when it has achieved Link State Protocol Data
   Unit (LSP) database synchronization with its neighbors and a
   mechanism to optimize LSP database synchronization, while minimizing
   transient routing disruption when a router starts.

   This document obsoletes RFC 5306.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc5306bis-07
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-rfc5306bis-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-rfc5306bis-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-04.txt

[Acee Lindem (acee)]

Amanda et al,
The IGP Flex Algorithm early allocations were made prior to the addition of 
Prefix Metric as defined in sections 16.3.2. 16.4.2. and 16.4.3 repectively for 
IS-IS, OSPFv2, and OSPFv3. Can these code points for prefix metric be added to 
the early allocations?
Thanks,
Acee

On 9/18/19, 6:16 AM, "Lsr on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : IGP Flexible Algorithm
Authors : Peter Psenak
  Shraddha Hegde
  Clarence Filsfils
  Ketan Talaulikar
  Arkadiy Gulko
Filename: draft-ietf-lsr-flex-algo-04.txt
Pages   : 31
Date: 2019-09-18

Abstract:
   IGP protocols traditionally compute best paths over the network based
   on the IGP metric assigned to the links.  Many network deployments
   use RSVP-TE based or Segment Routing based Traffic Engineering to
   enforce traffic over a path that is computed using different metrics
   or constraints than the shortest IGP path.  This document proposes a
   solution that allows IGPs themselves to compute constraint based
   paths over the network.  This document also specifies a way of using
   Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
   along the constraint-based paths.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-04
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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

Re: [Lsr] [Gen-art] Genart last call review of draft-ietf-lsr-isis-rfc5306bis-04

[Alissa Cooper]

Russ, thanks for your review. Les, thanks for addressing the review comments. I 
entered a No Objection ballot.

Alissa


> On Aug 16, 2019, at 5:05 PM, Russ Housley  wrote:
> 
>>> Nits:
>>> 
>>> Section 3.2.3: The lettered paragraphs at the top of the section
>>> begin with lower case letters, but the lettered paragraphs at the
>>> top of the section begin with upper case letters.  Please be
>>> consistent.
>>> 
>> [Les:] Done
> 
> Cool.
> 
>>> Section 3.2.3: s/time after which the adjacency will now expire/
>>>   /time after which the adjacency will expire/
>>> 
>> [Les:] I left this unchanged.  The text is identical to text in Section 
>> 3.2.1 regarding the RA bit. The point of using "now expire" is to emphasize 
>> that the expiration time has been adjusted as a result of the RR/PR request.
>> Hope this is OK with you.
> 
> Sure.  That makes sense.
> 
>>> Section 3.2.3 says:
>>> 
>>>  ... It
>>>  is therefore useful to signal a planned restart (if the forwarding
>>>  plane on the restarting router is maintained) so that ...
>>> 
>>> I suggest:
>>> 
>>>  ... If
>>>  the forwarding plane on the restarting router is maintained, it
>>>  is useful to signal a planned restart so that ...
>> 
>> [Les:] I rewrote this paragraph. The term "restart" has been defined in 
>> Section 2 to be associated with a control plane restart which involves 
>> maintenance of the forwarding plane - so some of the text was redundant. 
>> I hope the revised text is both more readable and more precise.
> 
> I just fetched the -05 version.  The revised paragraph looks good to me.
> 
> Russ
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [Lsr] RtgDir review: draft-ietf-ospf-te-link-attr-reuse-08

[Peter Psenak]

Hi Daniele,

please see inline:

On 18/09/2019 11:01, Daniele Ceccarelli wrote:

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-08.txt
Reviewer: Daniele Ceccarelli
Review Date: 2019-09-13
IETF LC End Date: date-if-known
Intended Status: Standard Track

*Summary:*
I have significant concerns about this document and recommend that the 
Routing ADs discuss these issues further with the authors.


*Comments:*

*The drafts needs some improvement to be clear and easy to read. It is 
outside the scope of the RTG-Directorate review to consider consensus on 
it, but the it is not possible to ignore comments received from a WG 
member of its usefulness. Implementations on ISIS segment routing and 
OSPF segment routing (publicly available) prove that applications like 
Flexible Algorithm, TI-LFA and R-LFA can be implemented using TE 
parameters compliant with RFC3630 and RFC5305 without the need for these 
extensions.***


this has been discussed several times in the WG prior to WG acceptance 
and also during its lifetime as the WG document. If there was no 
sufficient support and a real problem to solve, the document would not 
have made it to its current state.





*That said the rest of the review will be limited only to the quality of 
the document.*


*Major Issues:*

  * No major issue in addition to the one described in the comments.

*Minor Issues:*

  * Abstract: it would be nice to have an overview of what is the
purpose of distributing the attributes (in addition to MPLS-TE and
GMPLS). The document starts with a very generic scope but then
focuses on segment routing. It could be stated at the beginning.


the abstract says that link attributes can be used for other then MPLS 
TE and GMPLS and that this document defines how that can be done. Not 
sure what exactly do you want to add. Please let me know.


Not sure where you got the impression that the document focuses on SR, 
but that was not the intent.




  * Section 2: what does this sentence mean?: “Additionally, there will
be additional standardization effort.Additionally, there will be
additional standardization effort.  However, this could also be
viewed as an advantage as the non-TE use cases for the TE link
attributes are documented and validated by the LSR working group”



It means that when the new link attribute is defined and it can be 
advertised as app specific one, the code point from OSPFv2 Extended Link 
TLV sub-TLVs and OSPFv3 Extended LSA Sub-TLV registries would have to be 
allocated so that it can be advertised in ASLA sub-TLV.




  * It is not clear the usage of RFC2119 language (RECOMMENDED) in
section 2.1, is section 2.1 defining a new procedure? My
understanding is that section 2 is the actual solution while section
3 is the newly defined one. Am I wrong? If so it should be made a
bit more clear and I would expect to see RFC2119 language only in
section 3.


I'll change the wording and get rid of RECOMMENDED.



  * Section 3: “This situation SHOULD be logged as an error” how? Should
a notification be sent? Logging an error is not part of the protocol
definition but rather an implementation issue.


not sure I see the problem. We use this language about logging an error 
message in many places.




  * Section 4: the title is misleading. It is defining how to encode the
list of attributed defined at the end of section 3 (some of them are
reused, some others are TBD), why the title of the section is Reused
TE link attributes?


no attributes are defined at the end of section 3, these are all 
existing attributes. Section 4 defines the code points from the OSPFv2
Extended Link TLV Sub-TLV Registry and OSPFv3 Extended LSA Sub-TLV 
Registry for these. I will clean the TBDs as these now have early IANA 
allocations.




  * Sections 5-6-7: Section 3 describes the procedure and TLV format,
section 4 the encoding of the attributes…what is defined in section
5-6-7. If I search for e.g. Maximum link bandwidth (the title of
section 5), the first occurrence is the title of section 5. Maybe
gouping sections 5-6-7 into a single one with an intro of what is
defined could improve the reading. 


Attribute in sections 5,6,7 are attributes that MUST NOT be advertised 
in 

[Lsr] Genart last call review of draft-ietf-isis-yang-isis-cfg-37

[Stewart Bryant via Datatracker]

Reviewer: Stewart Bryant
Review result: 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-isis-yang-isis-cfg-??
Reviewer: Stewart Bryant
Review Date: 2019-09-18
IETF LC End Date: 2019-09-23
IESG Telechat date: Not scheduled for a telechat

Summary: A true magnum opus. Well written and from a GENART point of view ready
to be published. I have not checked the YANG syntax, and have only checked that
the configuration symantics look plausible. I assume that specalist YANG and
Routing reviewers will look at that detail.

Major issues: None

Minor issues: None

Nits/editorial comments:
   This document defines a YANG data model that can be used to configure
   and manage IS-IS protocol on network elements.

SB> s/manage/manage the/

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

[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-rfc5306bis-06: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-lsr-isis-rfc5306bis-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/



--
COMMENT:
--

(1) Section 3.1.  The two “NOTE” statements in this section seem to conflict:
-- NOTE: These timers are NOT applicable to a router which is preparing to do a
planned restart.

-- NOTE: The timer T3 is only used by a restarting router.

(2) Per the definition of the “Remaining Time” field, when is it the “remaining
holding time” vs. “recommended holding time"

(3) Editorial Nits:
-- Multiple places.  s/signalling/signaling/g


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

Re: [Lsr] Barry Leiba's No Objection on draft-ietf-lsr-isis-rfc5306bis-05: (with COMMENT)

[Barry Leiba]

Hi, Les.  Thanks for the response, and for considering my comments.
All is good.

Barry

On Tue, Sep 17, 2019 at 11:07 PM Les Ginsberg (ginsberg)
 wrote:
>
> Barry -
>
> Thanx for the thoughtful review.
>
> I have uploaded V6 of the document to address some (but not all) of your 
> points.
>
> More inline.
>
> > -Original Message-
> > From: Barry Leiba via Datatracker 
> > Sent: Friday, September 13, 2019 10:06 AM
> > To: The IESG 
> > Cc: draft-ietf-lsr-isis-rfc5306...@ietf.org; Uma Chunduri
> > ; aretana.i...@gmail.com; lsr-cha...@ietf.org;
> > uma.chund...@huawei.com; lsr@ietf.org
> > Subject: Barry Leiba's No Objection on draft-ietf-lsr-isis-rfc5306bis-05: 
> > (with
> > COMMENT)
> >
> > Barry Leiba has entered the following ballot position for
> > draft-ietf-lsr-isis-rfc5306bis-05: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > Thanks for this well written document, which I’ve found easy to read and
> > mostly
> > clear.  I have some editorial comments below, a few related to clarity.  I
> > realize that some of these apply to text that was in RFC 5306, and I ask 
> > you to
> > please consider them, but I understand if you want to minimize changes
> > from
> > 5306.
> >
> > — Abstract —
> >
> > This is entirely an editorial style comment, and no response is needed; just
> > do
> > what you think best, and if that is to leave it as it is, then that’s fine. 
> >  I
> > find the “This document…  This document additionally…  This document
> > additionally…” to be awkward, and suggest this instead:
> >
>
> [Les:] I appreciate your point - but decided to leave this section as is.
>
> > NEW
> >This document obsoletes RFC 5306 and describes a set of mechanisms
> >that can improve neighbor reconfiguration when a router restarts.
> >Using these mechanisms:
> >
> >1. A restarting router can signal to its neighbors that it is
> >restarting, allowing them to reestablish their adjacencies without
> >cycling through the down state, while still correctly initiating
> >database synchronization.
> >
> >2. A router can signal its neighbors that it is preparing to initiate
> >a restart while maintaining forwarding plane state.  This allows the
> >neighbors to maintain their adjacencies until the router has
> >restarted, but also allows the neighbors to bring the adjacencies down
> >in the event of other topology changes.
> >
> >3. A restarting router can determine when it has achieved Link State
> >Protocol Data Unit (LSP) database synchronization with its neighbors
> >and can optimize LSP database synchronization, while minimizing
> >transient routing disruption when a router starts.
> > END
> >
> > — Section 1 —
> >
> >This document describes a mechanism for a restarting router to signal
> >that it is restarting to its neighbors, and allow them to reestablish
> >their adjacencies without cycling through the down state, while still
> >correctly initiating database synchronization.
> >
> > As this is written, (1) “to its neighbors” is misplaced (it is not 
> > “restarting
> > to its neighbors”) and (2) it sounds like the restarting router is allowing
> > them to do the reestablishment, but it’s the signal that is.  I suggest 
> > this:
> >
> > NEW
> >This document describes a mechanism for a restarting router to signal
> >to its neighbors that it is restarting.  The signal allows them to
> >reestablish their adjacencies without cycling through the down state,
> >while still correctly initiating database synchronization.
> > END
> >
>
> [Les:] This has been revised - though a bit differently than your proposed 
> text.
>
> > — Section 3.1 —
> >
> >An instance of the timer T2 is maintained for each LSP database
> >(LSPDB) present in the system, i.e., for a Level 1/2 system, there
> >will be an instance of the timer T2 for Level 1 and an instance for
> >Level 2.
> >
> > Do you really mean “i.e.” here?  Is this the only possible situation, or is 
> > it
> > an example (for which you would want “e.g.”)?  I think it’s the latter, in
> > which case I would avoid the Latin, use English, and start a new sentence:
> >
> > NEW
> >An instance of the timer T2 is maintained for each LSP database
> >(LSPDB) present in the system.  For example, for a Level 1/2 system,
> >

[Lsr] I-D Action: draft-ietf-lsr-flex-algo-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : IGP Flexible Algorithm
Authors : Peter Psenak
  Shraddha Hegde
  Clarence Filsfils
  Ketan Talaulikar
  Arkadiy Gulko
Filename: draft-ietf-lsr-flex-algo-04.txt
Pages   : 31
Date: 2019-09-18

Abstract:
   IGP protocols traditionally compute best paths over the network based
   on the IGP metric assigned to the links.  Many network deployments
   use RSVP-TE based or Segment Routing based Traffic Engineering to
   enforce traffic over a path that is computed using different metrics
   or constraints than the shortest IGP path.  This document proposes a
   solution that allows IGPs themselves to compute constraint based
   paths over the network.  This document also specifies a way of using
   Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
   along the constraint-based paths.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-04
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[Lsr] RtgDir review: draft-ietf-ospf-te-link-attr-reuse-08

[Daniele Ceccarelli]

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-08.txt
Reviewer: Daniele Ceccarelli
Review Date: 2019-09-13
IETF LC End Date: date-if-known
Intended Status: Standard Track

Summary:
I have significant concerns about this document and recommend that the Routing 
ADs discuss these issues further with the authors.

Comments:

The drafts needs some improvement to be clear and easy to read. It is outside 
the scope of the RTG-Directorate review to consider consensus on it, but the it 
is not possible to ignore comments received from a WG member of its usefulness. 
Implementations on ISIS segment routing and OSPF segment routing (publicly 
available) prove that applications like Flexible Algorithm, TI-LFA and R-LFA 
can be implemented using TE parameters compliant with RFC3630 and RFC5305 
without the need for these extensions.

That said the rest of the review will be limited only to the quality of the 
document.

Major Issues:

*   No major issue in addition to the one described in the comments.

Minor Issues:

*   Abstract: it would be nice to have an overview of what is the purpose 
of distributing the attributes (in addition to MPLS-TE and GMPLS). The document 
starts with a very generic scope but then focuses on segment routing. It could 
be stated at the beginning.
*   Section 2: what does this sentence mean?: “Additionally, there will be 
additional standardization effort. Additionally, there will be additional 
standardization effort.  However, this could also be viewed as an advantage as 
the non-TE use cases for the TE link attributes are documented and validated by 
the LSR working group”
*   It is not clear the usage of RFC2119 language (RECOMMENDED) in section 
2.1, is section 2.1 defining a new procedure? My understanding is that section 
2 is the actual solution while section 3 is the newly defined one. Am I wrong? 
If so it should be made a bit more clear and I would expect to see RFC2119 
language only in section 3.
*   Section 3: “This situation SHOULD be logged as an error” how? Should a 
notification be sent? Logging an error is not part of the protocol definition 
but rather an implementation issue.
*   Section 4: the title is misleading. It is defining how to encode the 
list of attributed defined at the end of section 3 (some of them are reused, 
some others are TBD), why the title of the section is Reused TE link attributes?
*   Sections 5-6-7: Section 3 describes the procedure and TLV format, 
section 4 the encoding of the attributes…what is defined in section 5-6-7. If I 
search for e.g. Maximum link bandwidth (the title of section 5), the first 
occurrence is the title of section 5. Maybe gouping sections 5-6-7 into a 
single one with an intro of what is defined could improve the reading. 

Nits:

*   MPLS TE is sometimes in capital letters and sometimes not.
*   SRTE expand on first use.

 

BR

Daniele  

 



smime.p7s
Description: S/MIME cryptographic signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Martin Vigoureux's No Objection on draft-ietf-lsr-isis-rfc5306bis-05: (with COMMENT)

[Les Ginsberg (ginsberg)]

Martin -

Thanx for reviewing.
Inline.

> -Original Message-
> From: Martin Vigoureux via Datatracker 
> Sent: Tuesday, September 17, 2019 1:18 AM
> To: The IESG 
> Cc: draft-ietf-lsr-isis-rfc5306...@ietf.org; Uma Chunduri
> ; aretana.i...@gmail.com; lsr-cha...@ietf.org;
> uma.chund...@huawei.com; lsr@ietf.org
> Subject: Martin Vigoureux's No Objection on draft-ietf-lsr-isis-rfc5306bis-05:
> (with COMMENT)
> 
> Martin Vigoureux has entered the following ballot position for
> draft-ietf-lsr-isis-rfc5306bis-05: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Hello,
> 
> thank you for this document.
> What is the expected behaviour, if any needing to be described, when the
> neighbor of a router planning to restart decides to also plan a restart?
> 

[Les:] A restarting router depends upon the adjacency state preserved by its 
neighbors in order to gracefully restore state post-restart. Anything which 
compromises that will compromise the "gracefulness" of the restart.
If two routers who are neighbors restart at the "same time" then the state of 
the adjacency(s) between those two routers will not be preserved and this will 
cause some flapping.

GR is intended to be a planned activity - therefore the operator should be able 
to insure that only one router at a time is undergoing GR.

   Les


> Thank you
> 

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

Re: [Lsr] Barry Leiba's No Objection on draft-ietf-lsr-isis-rfc5306bis-05: (with COMMENT)

[Les Ginsberg (ginsberg)]

Barry -

Thanx for the thoughtful review.

I have uploaded V6 of the document to address some (but not all) of your points.

More inline.

> -Original Message-
> From: Barry Leiba via Datatracker 
> Sent: Friday, September 13, 2019 10:06 AM
> To: The IESG 
> Cc: draft-ietf-lsr-isis-rfc5306...@ietf.org; Uma Chunduri
> ; aretana.i...@gmail.com; lsr-cha...@ietf.org;
> uma.chund...@huawei.com; lsr@ietf.org
> Subject: Barry Leiba's No Objection on draft-ietf-lsr-isis-rfc5306bis-05: 
> (with
> COMMENT)
> 
> Barry Leiba has entered the following ballot position for
> draft-ietf-lsr-isis-rfc5306bis-05: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for this well written document, which I’ve found easy to read and
> mostly
> clear.  I have some editorial comments below, a few related to clarity.  I
> realize that some of these apply to text that was in RFC 5306, and I ask you 
> to
> please consider them, but I understand if you want to minimize changes
> from
> 5306.
> 
> — Abstract —
> 
> This is entirely an editorial style comment, and no response is needed; just
> do
> what you think best, and if that is to leave it as it is, then that’s fine.  I
> find the “This document…  This document additionally…  This document
> additionally…” to be awkward, and suggest this instead:
> 

[Les:] I appreciate your point - but decided to leave this section as is.

> NEW
>This document obsoletes RFC 5306 and describes a set of mechanisms
>that can improve neighbor reconfiguration when a router restarts.
>Using these mechanisms:
> 
>1. A restarting router can signal to its neighbors that it is
>restarting, allowing them to reestablish their adjacencies without
>cycling through the down state, while still correctly initiating
>database synchronization.
> 
>2. A router can signal its neighbors that it is preparing to initiate
>a restart while maintaining forwarding plane state.  This allows the
>neighbors to maintain their adjacencies until the router has
>restarted, but also allows the neighbors to bring the adjacencies down
>in the event of other topology changes.
> 
>3. A restarting router can determine when it has achieved Link State
>Protocol Data Unit (LSP) database synchronization with its neighbors
>and can optimize LSP database synchronization, while minimizing
>transient routing disruption when a router starts.
> END
> 
> — Section 1 —
> 
>This document describes a mechanism for a restarting router to signal
>that it is restarting to its neighbors, and allow them to reestablish
>their adjacencies without cycling through the down state, while still
>correctly initiating database synchronization.
> 
> As this is written, (1) “to its neighbors” is misplaced (it is not “restarting
> to its neighbors”) and (2) it sounds like the restarting router is allowing
> them to do the reestablishment, but it’s the signal that is.  I suggest this:
> 
> NEW
>This document describes a mechanism for a restarting router to signal
>to its neighbors that it is restarting.  The signal allows them to
>reestablish their adjacencies without cycling through the down state,
>while still correctly initiating database synchronization.
> END
> 

[Les:] This has been revised - though a bit differently than your proposed text.

> — Section 3.1 —
> 
>An instance of the timer T2 is maintained for each LSP database
>(LSPDB) present in the system, i.e., for a Level 1/2 system, there
>will be an instance of the timer T2 for Level 1 and an instance for
>Level 2.
> 
> Do you really mean “i.e.” here?  Is this the only possible situation, or is it
> an example (for which you would want “e.g.”)?  I think it’s the latter, in
> which case I would avoid the Latin, use English, and start a new sentence:
> 
> NEW
>An instance of the timer T2 is maintained for each LSP database
>(LSPDB) present in the system.  For example, for a Level 1/2 system,
>there will be one instance of the timer T2 for Level 1 and another
>instance for Level 2.
> END

[Les:] Done. 

> 
>This is initialized to 65535
>seconds, but is set to the minimum of the remaining times of received
>IIHs containing a restart TLV with the Restart Acknowledgement (RA)
>set and an indication that the neighbor has an adjacency in the "UP"
>state to