RE: Request for WG adoption of for draft-bryant-rtgwg-param-sync

[Chris Bowers]

Dear RTGWG,

I am a co-author, and I support the draft.

I am not aware of any relevant IPR.

Chris


-Original Message-
From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] 
Sent: Friday, August 4, 2017 2:46 PM
To: RTGWG 
Cc: 'rtgwg-chairs' ; 
draft-bryant-rtgwg-param-s...@ietf.org
Subject: Request for WG adoption of for draft-bryant-rtgwg-param-sync

Dear RTGWG,

The authors have requested the RTGWG to adopt for draft-bryant-rtgwg-param-sync 
as the working group document. 

WG expressed support during the last RTGWG meeting and the authors have 
addressed all the comments received.
Please indicate support or no-support by August 18, 2017.

If you are listed as a document author or contributor please respond to this 
email stating of whether or not you are aware of any relevant IPR. The response 
needs to be sent to the RTGWG mailing list. The document will not advance to 
the next stage until a response has been received from each author and each 
individual that has contributed to the document.

Cheers,
Jeff 



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

RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

[stephane.litkowski]

Thanks Chris, I will post a new revision with those changes.


From: Chris Bowers [mailto:cbow...@juniper.net]
Sent: Tuesday, August 08, 2017 16:05
To: LITKOWSKI Stephane OBS/OINIS
Cc: RTGWG; draft-ietf-rtgwg-uloop-de...@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Stephane,

See responses inline with [CB].

Chris

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, August 8, 2017 8:25 AM
To: Chris Bowers >
Cc: RTGWG >; 
draft-ietf-rtgwg-uloop-de...@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Hi Chris,

Thanks for the review. I'm updating the document to reflect your proposals.
Couple of comments:

-  s/"otherwise the standard IP convergence MUST be used."/ "otherwise 
the standard IP convergence MUST used". It does not sound good to me but may be 
because of an English grammar issue on my side. Could you confirm the change ?

[CB]  You are correct.  That proposed change is a mistake on my part.



-  Regarding your main comment on section 1 and 2.1, I do not agree 
about your statement on RSVP-FRR. First there are multiple deployment styles of 
RSVP FRR:

o   LDP tunneling

o   RSVP with no strict ERO

o   RSVP with CSPF at head end (strict ERO)
Your statement is true only for the third case where an RSVP tunnel between S 
and D exists with its path computed by S => no uloop in that case for sure. But 
as soon as you rely on distributed convergence, you will fall into a loop even 
if you use RSVP-FRR. I will precise in the text that we are in an LDP scenario 
for example. Here is a text proposal:
"In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T, 
provisioned on C and terminating on B, is used to protect the traffic against 
C-B link failure (IGP shortcut is activated on C)."
"The issue described here is completely independent of the fast-reroute 
mechanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop 
by hop defined path."


[CB] "when the primary path is an hop by hop defined path"  is somewhat 
ambiguous.
How about "when the primary path uses hop-by-hop routing" ?


For the LFA case, yes, there are some cases where there is no loop, but it is 
topology dependent. I'm not sure that we need to give such precision as if the 
LFA is on the postconvergence path, this means that the postconvergence is 
loopfree, so there will be no local microloop in any case.

[CB]  OK.


-  Regarding your comment on section 4.4, here is my new text proposal 
to fit your comment:

"Upon an adjacency/link down event, this document introduces a change
   in step 5 () in order to delay the local 
convergence compared to the
   network wide convergence. The new step 5 is described below:"
   5. Upon SPF_DELAY timer expiration, the SPF is computed. If the 
condition of a single local link-down event has been met and if the new 
convergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an 
update of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER 
msecs. Otherwise, the RIB and FIB SHOULD be updated immediately.

If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, 
ULOOP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of 
the new convergence event."

[CB]  This text seems clearer.

Brgds,

Stephane


From: Chris Bowers [mailto:cbow...@juniper.net]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; 
draft-ietf-rtgwg-uloop-de...@ietf.org
Cc: rtgwg@ietf.org
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Authors,

I'm in the process of doing the Shepherd write-up for 
draft-ietf-rtgwg-uloop-delay-05.txt.

In reading the latest version of the document, I wrote down some feedback.
A diff can be found at:
https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f3fc5b2c89dc65f813b992921d685049a4a4bd

http://bit.ly/2vJqoq2

Most of the feedback is related to clarifying language and typos.  However there
are few comments that I think are more substantive so I am
reproducing them below since they should probably discussed on the list.

===
[CB]  I find the examples presented in section 1 and section 2.1 to
be confusing.  The conclusion drawn in the last paragraph of section
2.1 does not seem to follow from these examples.

Section 1 (figure 1) shows an example of micro-loops occuring when shortest
path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths from the PLR.

Section 2.1 (figure 2) also shows an example of micro-loops occuring when
shortest path forwarding is used and the metrics are such 

RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

[Chris Bowers]

Stephane,

See responses inline with [CB].

Chris

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Tuesday, August 8, 2017 8:25 AM
To: Chris Bowers 
Cc: RTGWG ; draft-ietf-rtgwg-uloop-de...@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Hi Chris,

Thanks for the review. I'm updating the document to reflect your proposals.
Couple of comments:

-  s/"otherwise the standard IP convergence MUST be used."/ "otherwise 
the standard IP convergence MUST used". It does not sound good to me but may be 
because of an English grammar issue on my side. Could you confirm the change ?

[CB]  You are correct.  That proposed change is a mistake on my part.



-  Regarding your main comment on section 1 and 2.1, I do not agree 
about your statement on RSVP-FRR. First there are multiple deployment styles of 
RSVP FRR:

o   LDP tunneling

o   RSVP with no strict ERO

o   RSVP with CSPF at head end (strict ERO)
Your statement is true only for the third case where an RSVP tunnel between S 
and D exists with its path computed by S => no uloop in that case for sure. But 
as soon as you rely on distributed convergence, you will fall into a loop even 
if you use RSVP-FRR. I will precise in the text that we are in an LDP scenario 
for example. Here is a text proposal:
"In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T, 
provisioned on C and terminating on B, is used to protect the traffic against 
C-B link failure (IGP shortcut is activated on C)."
"The issue described here is completely independent of the fast-reroute 
mechanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop 
by hop defined path."


[CB] "when the primary path is an hop by hop defined path"  is somewhat 
ambiguous.
How about "when the primary path uses hop-by-hop routing" ?


For the LFA case, yes, there are some cases where there is no loop, but it is 
topology dependent. I'm not sure that we need to give such precision as if the 
LFA is on the postconvergence path, this means that the postconvergence is 
loopfree, so there will be no local microloop in any case.

[CB]  OK.


-  Regarding your comment on section 4.4, here is my new text proposal 
to fit your comment:

"Upon an adjacency/link down event, this document introduces a change
   in step 5 () in order to delay the local 
convergence compared to the
   network wide convergence. The new step 5 is described below:"
   5. Upon SPF_DELAY timer expiration, the SPF is computed. If the 
condition of a single local link-down event has been met and if the new 
convergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an 
update of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER 
msecs. Otherwise, the RIB and FIB SHOULD be updated immediately.

If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, 
ULOOP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of 
the new convergence event."

[CB]  This text seems clearer.

Brgds,

Stephane


From: Chris Bowers [mailto:cbow...@juniper.net]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; 
draft-ietf-rtgwg-uloop-de...@ietf.org
Cc: rtgwg@ietf.org
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Authors,

I'm in the process of doing the Shepherd write-up for 
draft-ietf-rtgwg-uloop-delay-05.txt.

In reading the latest version of the document, I wrote down some feedback.
A diff can be found at:
https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f3fc5b2c89dc65f813b992921d685049a4a4bd

http://bit.ly/2vJqoq2

Most of the feedback is related to clarifying language and typos.  However there
are few comments that I think are more substantive so I am
reproducing them below since they should probably discussed on the list.

===
[CB]  I find the examples presented in section 1 and section 2.1 to
be confusing.  The conclusion drawn in the last paragraph of section
2.1 does not seem to follow from these examples.

Section 1 (figure 1) shows an example of micro-loops occuring when shortest
path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths from the PLR.

Section 2.1 (figure 2) also shows an example of micro-loops occuring when
shortest path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths from the PLR.  However, in this example,
a one-hop RSVP tunnel is provisioned to provide link protection for one of
the links.  However, even with this one-hop RSVP tunnel the example
demonstrates that micro-loops can occur.

The last paragraph asserts that:
"The issue described here is completely independent of the fast-
reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)."

There are two problems with this 

RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

[stephane.litkowski]

Hi Chris,

Thanks for the review. I'm updating the document to reflect your proposals.
Couple of comments:

-  s/"otherwise the standard IP convergence MUST be used."/ "otherwise 
the standard IP convergence MUST used". It does not sound good to me but may be 
because of an English grammar issue on my side. Could you confirm the change ?



-  Regarding your main comment on section 1 and 2.1, I do not agree 
about your statement on RSVP-FRR. First there are multiple deployment styles of 
RSVP FRR:

o   LDP tunneling

o   RSVP with no strict ERO

o   RSVP with CSPF at head end (strict ERO)
Your statement is true only for the third case where an RSVP tunnel between S 
and D exists with its path computed by S => no uloop in that case for sure. But 
as soon as you rely on distributed convergence, you will fall into a loop even 
if you use RSVP-FRR. I will precise in the text that we are in an LDP scenario 
for example. Here is a text proposal:
"In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T, 
provisioned on C and terminating on B, is used to protect the traffic against 
C-B link failure (IGP shortcut is activated on C)."
"The issue described here is completely independent of the fast-reroute 
mechanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop 
by hop defined path."

For the LFA case, yes, there are some cases where there is no loop, but it is 
topology dependent. I'm not sure that we need to give such precision as if the 
LFA is on the postconvergence path, this means that the postconvergence is 
loopfree, so there will be no local microloop in any case.




-  Regarding your comment on section 4.4, here is my new text proposal 
to fit your comment:

"Upon an adjacency/link down event, this document introduces a change
   in step 5 () in order to delay the local 
convergence compared to the
   network wide convergence. The new step 5 is described below:"
   5. Upon SPF_DELAY timer expiration, the SPF is computed. If the 
condition of a single local link-down event has been met and if the new 
convergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an 
update of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER 
msecs. Otherwise, the RIB and FIB SHOULD be updated immediately.

If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, 
ULOOP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of 
the new convergence event."

Brgds,

Stephane


From: Chris Bowers [mailto:cbow...@juniper.net]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-de...@ietf.org
Cc: rtgwg@ietf.org
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Authors,

I'm in the process of doing the Shepherd write-up for 
draft-ietf-rtgwg-uloop-delay-05.txt.

In reading the latest version of the document, I wrote down some feedback.
A diff can be found at:
https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f3fc5b2c89dc65f813b992921d685049a4a4bd

http://bit.ly/2vJqoq2

Most of the feedback is related to clarifying language and typos.  However there
are few comments that I think are more substantive so I am
reproducing them below since they should probably discussed on the list.

===
[CB]  I find the examples presented in section 1 and section 2.1 to
be confusing.  The conclusion drawn in the last paragraph of section
2.1 does not seem to follow from these examples.

Section 1 (figure 1) shows an example of micro-loops occuring when shortest
path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths from the PLR.

Section 2.1 (figure 2) also shows an example of micro-loops occuring when
shortest path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths from the PLR.  However, in this example,
a one-hop RSVP tunnel is provisioned to provide link protection for one of
the links.  However, even with this one-hop RSVP tunnel the example
demonstrates that micro-loops can occur.

The last paragraph asserts that:
"The issue described here is completely independent of the fast-
reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)."

There are two problems with this assertion.

Problem 1) I don't think that the assertion is correct for RSVP TE-FRR in 
general.

For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S to D.
Before the failure of the link C-B, this LSP would follow the path
S-E-C-B-A-D.  Immediately after the failure of link C-B, the LSP would
follow the path S-E-C-E-A-B-A-D using the bypass LSP at C.  Once S is
made aware of the failure.  S will resignal the LSP to take the path S-E-A-D.
At no time would looping occur.

I assume that it wasn't the initial intention to claim that RSVP TE-FRR suffers 
from
micro-looping, but the text currently reads that way.  The assertion of the last
paragraph should be qualified to