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

[Huaimo Chen]

Hi Robert,

Thank you very much for your suggestion.
We have updated the document (version 16 uploaded) according to your 
suggestion.

Best Regards,
Huaimo

From: Robert Sparks 
Sent: Friday, June 12, 2020 11:32 AM
To: Huaimo Chen ; gen-art@ietf.org 

Cc: last-c...@ietf.org ; 
draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org 
; p...@ietf.org 

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



On 6/11/20 9:12 AM, Robert Sparks wrote:

Thanks! Some initial replies inline (I haven't looked at the updated draft yet, 
but will do so soon):

I've looked at the diffs between -13 and -15 and my comments have been 
addressed except for one point.


Only one of them (i.e., elastic range and grace periods) is used for an 
LSP.


Isn't strong enough. I think you need normative language here.


I suggest

A TLV can configure a non-zero grace period or elastic bound, but it MUST 
NOT provide both.

On 6/10/20 7:35 PM, Huaimo Chen wrote:
Hi Robert,

Thank you very much for your time and valuable comments.

My answers/explanations are inline below with prefix [HC].

Your comments have been addressed in the updated document
 
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca22642eaef594f08eb0308d80ee5e221%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637275727802251333=O2EvYJTW9ns6OFBSqAHwZSAp5qPgGGWUC3oQCFzLBw8%3D=0>

Best Regards,
Huaimo

From: Robert Sparks via Datatracker <mailto:nore...@ietf.org>
Sent: Tuesday, June 9, 2020 5:41 PM
To: gen-art@ietf.org<mailto:gen-art@ietf.org> 
<mailto:gen-art@ietf.org>
Cc: last-c...@ietf.org<mailto:last-c...@ietf.org> 
<mailto:last-c...@ietf.org>; 
p...@ietf.org<mailto:p...@ietf.org> <mailto:p...@ietf.org>; 
draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org<mailto:draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org>
 
<mailto:draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org>
Subject: Genart last call review of 
draft-ietf-pce-stateful-pce-lsp-scheduling-13

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

<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaqdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C009e6885956a4c1957c908d80cbde38d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637273356999321440sdata=x1%2BeFVCwSKtx16TqY5ycJgjrXK%2Bb%2Be4ttO0SuBrPStY%3Dreserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca22642eaef594f08eb0308d80ee5e221%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637275727802261328=891whMYACGrZ%2BzKXEmhvwpimP6wkNjd%2BL70QOehV9WQ%3D=0>>.

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?

[HC]: We have made it clear in the document through revising the texts.
When a periodical LSP is configured, the paths for all the scheduled
intervals of the LSP is computed once.
If there is no path for some (e.g., one) of the intervals,
the constraints for the periodical LSP is not satisfied and
the LSP will not be set up at all.

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?

[HC]: We have added the texts explicitly stating that
the previous LSP will not be impacted if the path for new
requirements cannot be set.

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

[HC]: We have removed TCP.

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.

[HC]: We have added some texts to say that only 

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

[Huaimo Chen]

Hi Robert,

Thank you very much for your quick reply.
My answers/explanations are inline below.

Best Regards,
Huaimo

From: Robert Sparks 
Sent: Thursday, June 11, 2020 10:12 AM
To: Huaimo Chen ; gen-art@ietf.org 

Cc: last-c...@ietf.org ; p...@ietf.org ; 
draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org 

Subject: Re: Genart last call review of 
draft-ietf-pce-stateful-pce-lsp-scheduling-13


Thanks! Some initial replies inline (I haven't looked at the updated draft yet, 
but will do so soon):


On 6/10/20 7:35 PM, Huaimo Chen wrote:
Hi Robert,

Thank you very much for your time and valuable comments.

My answers/explanations are inline below with prefix [HC].

Your comments have been addressed in the updated document
 
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce9d8ff99250149ef36fc08d80e118a6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637274815796667149=xqsVrqpFBP%2F7FZ1uXpePWT6m3X%2Fhy44K8pO8WcPO85M%3D=0>

Best Regards,
Huaimo

From: Robert Sparks via Datatracker <mailto:nore...@ietf.org>
Sent: Tuesday, June 9, 2020 5:41 PM
To: gen-art@ietf.org<mailto:gen-art@ietf.org> 
<mailto:gen-art@ietf.org>
Cc: last-c...@ietf.org<mailto:last-c...@ietf.org> 
<mailto:last-c...@ietf.org>; 
p...@ietf.org<mailto:p...@ietf.org> <mailto:p...@ietf.org>; 
draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org<mailto:draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org>
 
<mailto:draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org>
Subject: Genart last call review of 
draft-ietf-pce-stateful-pce-lsp-scheduling-13

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

<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaqdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C009e6885956a4c1957c908d80cbde38d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637273356999321440sdata=x1%2BeFVCwSKtx16TqY5ycJgjrXK%2Bb%2Be4ttO0SuBrPStY%3Dreserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce9d8ff99250149ef36fc08d80e118a6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637274815796667149=lFujiKxBpSoEGjvjxsBszLONJT2RajnEQLUwcQuqNYM%3D=0>>.

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?

[HC]: We have made it clear in the document through revising the texts.
When a periodical LSP is configured, the paths for all the scheduled
intervals of the LSP is computed once.
If there is no path for some (e.g., one) of the intervals,
the constraints for the periodical LSP is not satisfied and
the LSP will not be set up at all.

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?

[HC]: We have added the texts explicitly stating that
the previous LSP will not be impacted if the path for new
requirements cannot be set.

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

[HC]: We have removed TCP.

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.

[HC]: We have added some texts to say that only one of them is used.

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.

[HC]: You are right. The relative time is in seconds.
We have explicitly stated this and had some discussions about
synchronizing clocks and potential problems wit

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

[Huaimo Chen]

Hi Robert,

Thank you very much for your time and valuable comments.

My answers/explanations are inline below with prefix [HC].

Your comments have been addressed in the updated document
 https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/

Best Regards,
Huaimo

From: Robert Sparks via Datatracker 
Sent: Tuesday, June 9, 2020 5:41 PM
To: gen-art@ietf.org 
Cc: last-c...@ietf.org ; p...@ietf.org ; 
draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org 

Subject: Genart last call review of 
draft-ietf-pce-stateful-pce-lsp-scheduling-13

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?

[HC]: We have made it clear in the document through revising the texts.
When a periodical LSP is configured, the paths for all the scheduled
intervals of the LSP is computed once.
If there is no path for some (e.g., one) of the intervals,
the constraints for the periodical LSP is not satisfied and
the LSP will not be set up at all.

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?

[HC]: We have added the texts explicitly stating that
the previous LSP will not be impacted if the path for new
requirements cannot be set.

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

[HC]: We have removed TCP.

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.

[HC]: We have added some texts to say that only one of them is used.

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.

[HC]: You are right. The relative time is in seconds.
We have explicitly stated this and had some discussions about
synchronizing clocks and potential problems with transmission delay.

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).

[HC]: When R=1, Start-Time=0 means right now.
Because of transmission and processing delay, this cannot be achieved.
For R=0, Start-Time=0 means the epoch (i.e., 1 January 1970 at 00:00 UTC).
So for both R=1 and R=0, a value of 0 must not be used in Start-Time.

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.

[HC]: It is the interval between the end-time of one repetition and
the start of the next repetition. We had added some texts to
state this explicitly.

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.

[HC]: We have changed SHOULD NOT to MUST NOT.

Nits:

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

[HC]: We have split and rephrased it.

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

[HC]: We have rephrased it.

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

[HC]: We have changed 

Re: [Gen-art] Genart telechat review of draft-ietf-teas-rsvp-egress-protection-14

[Huaimo Chen]

Hi Steward,

Thank you very much for your time and your valuable comments.
We have updated the document to address the nits according to your 
suggestions.

Best Regards,
Huaimo
-Original Message-
From: Stewart Bryant [mailto:stewart.bry...@gmail.com] 
Sent: Monday, March 05, 2018 2:32 PM
To: gen-art@ietf.org
Cc: draft-ietf-teas-rsvp-egress-protection@ietf.org; i...@ietf.org; 
t...@ietf.org
Subject: Genart telechat review of draft-ietf-teas-rsvp-egress-protection-14

Reviewer: Stewart Bryant
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 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-teas-rsvp-egress-protection-??
Reviewer: Stewart Bryant
Review Date: 2018-03-05
IETF LC End Date: 2018-02-27
IESG Telechat date: 2018-03-08

Summary: This is much improved since the earlier version I reviewed.

I do have a concern about the use of the term "egress" when I think that it 
should be "egress node" or some such other network object.

Major issues: None

Minor issues: None

Nits/editorial comments:

The authors often use the term egress on its own when I think they mean egress 
PE or egress node or egress LSR. If my English concern is correct, this should 
be addressed before this goes to the RFC Editor else  Auth48 will be a painful 
process for all concerned.

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

Re: [Gen-art] Genart last call review of draft-ietf-teas-rsvp-ingress-protection-13

[Huaimo Chen]

Hi Robert,

Thank you very much for your time and valuable comments.
Answers to them are inline below with prefix [HC].
Would you mind reviewing them to see if they address the issues?

Best Regards,
Huaimo
-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com] 
Sent: Wednesday, February 21, 2018 12:20 PM
To: gen-art@ietf.org
Cc: i...@ietf.org; t...@ietf.org; 
draft-ietf-teas-rsvp-ingress-protection@ietf.org
Subject: Genart last call review of draft-ietf-teas-rsvp-ingress-protection-13

Reviewer: Robert Sparks
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-teas-rsvp-ingress-protection-13
Reviewer: Robert Sparks
Review Date: 2018-02-21
IETF LC End Date: 2018-03-01
IESG Telechat date: 2018-03-08

 Summary: Not Ready for publication as an Experimental RFC

I found this document hard to read. I encourage a significant editorial pass 
that focuses on presenting the core ideas early, and simplifies the language 
used throughout the document.
[HC] We have presented the core ideas early and simplify the language used in
the document accordingly.


Major Issues:

1) The IANA considerations section is unclear. You ask IANA to put something in 
"Class Names, Class Numbers, and Class Types" at 
.
But there is no registry with that title on that page. (Nor is there a registry 
with a structure matching the row you are asking IANA to add.) Did you mean the 
registry at 
?
[HC] Yes. You are right. We have corrected it in the document. 


If so, the number you are suggesting is in a "Reserved for Private Use" range.
If that _was_ your target, the structure of your requested record does not 
match the structure of the existing registry. Please clarify.
[HC] We are considering a new C-Type under the existing Protection Class. 
The related text has be updated accordingly as below:
Upon approval of this document, IANA is requested to assign a new
Class Type or C-Type under Class Number 37 and Class Name PROTECTION
located at , as follows:

Value Description   Reference
- ---   -
  4Type 4 INGRESS_PROTECTION   This Document


The instructions to IANA for what to do when this document moves to the 
standards track are inappropriate. You can say that you anticipate that the 
future document that moves the idea to the standard track expects to create a 
new registry under rsvp-te-parameters, but this document cannot instruct IANA 
to do so.
[HC] We have revised the text according to your suggestion as below:
It is anticipated that the future document that moves the idea to the 
standard track expects IANA to create and maintain a new registry under
PROTECTION object class, Class Number 37, C-Type 4. Initial values for 
the registry are given below. The future assignments are to be made through 
IETF Review.


2) "After one approach is selected, the document SHOULD become proposed 
standard." is an innappropriate use of SHOULD, and doesn't correctly reflect 
the process that would be followed in any case. You could, instead, say "After 
one approach is selected, a document revising the ideas here to reflect that 
selection and any other items learned from the experiment is expected to be 
submitted for publication on the standards track."
[HC] We have updated the text accordingly as below:
After one approach is selected, the document will be revised 
to reflect that selection and any other items learned from 
the experiment. The revised document is expected to be submitted 
for publication on the standards track.


3) It is unclear until you get to section 5 (11 pages into the document) which 
elements provide and which elements consume the information in the proposed new 
object. The document is inconsistent about which messages the object can/should 
appear in. Moving the overview of behavior earlier in the document would help.
Simplifying the description of that behavior will help more. Making the other 
sections consistent with what that overview describes is necessary.
[HC] We have corrected the inconsistency and updated the document according to 
your suggestions.


Minor Issues:

a) It is not clear what the difference between source-detect and 
backup-source-detect really are (I agree with the comments in the rtgdir review 
on these sections). In section 2.1, where you say "reliably detect", do you 
really mean "verify"? The detection has already been 

Re: [Gen-art] Genart last call review of draft-ietf-teas-rsvp-egress-protection-09

[Huaimo Chen]

Hi Stewart,

Thank you very much for your comments.
Answers to your comments are inline below with prefix [HC].
Would you mind reviewing them to see if they address the issues?

Best Regards,
Huaimo
-Original Message-
From: Stewart Bryant [mailto:stewart.bry...@gmail.com] 
Sent: Monday, February 19, 2018 7:06 AM
To: gen-art@ietf.org
Cc: draft-ietf-teas-rsvp-egress-protection@ietf.org; i...@ietf.org; 
t...@ietf.org
Subject: Genart last call review of draft-ietf-teas-rsvp-egress-protection-09

Reviewer: Stewart Bryant
Review result: On the Right Track

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-teas-rsvp-egress-protection-09

Reviewer: Stewart Bryant
Review Date: 2018-02-19
IETF LC End Date: 2018-02-27
IESG Telechat date: 2018-03-08

Summary:

I think that there are a number of issues that need to be looked at in detail 
before this is ready. It could be that a number of these are assumed knowledge 
of the subject area, but that is not the case for all of them.

Section 6, the example, explains how this works and the motivation. It is very 
abbreviated and I am unclear about how the solution fits together. This needs 
clarification and then the rest of the text needs checking against that.

[HC] We will add more details about the example in section 6 and check the 
rest with it.


There are a lot of cases where terms and abbreviations are used before 
definition.

[HC] We will define the terms and abbreviations before they are used.


Major issues:

Section 6 needs a re-write for clarity. As written it looks like a number of 
slides were just transcribed int the text rather than taking care to write for 
clarity. The section makes a number of assumptions that really should be 
spelled out.

[HC] We will revise/re-write it with more details.


I think that it needs to be clear that you are protecting the egress nodes, but 
that as far as I can see you are vulnerable to egress link failure. Certainly 
the example in section 6 does a BFD test between R3 and L1 which only tests L1 
reachability. Related to which are you constraining BFD to run over the LSP? 
If it is running as regular IP I don't think that validates the LSP.

[HC] We will update the document to make it clear that we are protecting the 
egress node. 
If egress node failure is determined, then the procedure for protecting the
egress node is triggered. If link failure and egress node alive are determined,
then link protection procedure is triggered. How to determine these is out of
scope for this document.


In this text:

   This can be achieved by configuring
   a same local address on L1 and La, using the address as a destination
   of the LSP and BGP next hop for VPN traffic.

SB> Don't you have to do cost management to get the right behaviour?
SB> what if you really want to send to them individually, does this 
SB> confuse things?

[HC] Some cost management is needed. 
The cost to L1 need to be less than the cost to La
in order for the traffic to be sent to L1. In this context, L1 is a primary 
egress node of an LSP and La is the backup egress node which is used to
protect the primary egress node L1. Thus L1 and La (i.e., the primary egress
node and the backup egress node protecting the primary egress node) are 
different nodes and the VPN connected to L1 is not the same VPN to La 
(i.e., the same VPN is not connected to both L1 and La). 
In case that we want to the VPN traffic to be sent to both L1 and La, 
they (i.e., L1 and La) are for the same VPN, but different sites. 
If L1 and La are for the same VPN, 
we want to the VPN traffic is sent to L1 and La individually, and 
La is used as the backup egress to protect the primary egress L1, 
then the VPN traffic is sent to L1 and La individually, which send the
traffic to their sites respectively in normal operations
since L1 and La have different IP addresses (e.g., L1-VpnAddress 
and La-VpnAddress). When La is used as the backup egress to protect the 
primary egress L1, L1's address (e.g., L1-VpnAddress) may be used/
configured as a local address on La and as BGP next hop for the VPN traffic.
Thus, in normal operation, the VPN traffic is sent to both L1 and La for 
two VPN sites. For the traffic to L1, it will be sent to L1 normally
since the cost to L1-VpnAddress on L1 is less than the cost to 
L1-VpnAddress on La. 


Minor issues:

1.1.  Egress Local Protection

   Figure 1 shows an example of using backup LSPs to locally protect
   egresses of a primary P2MP LSP from ingress R1 to two egresses,

SB> What is an egress in this context?

[HC] In this context, an egress is a destination (or egress) of the 
P2MP LSP having R1 as its source/ingress, L1 and L2 as its 

Re: [Gen-art] Gen-Art Last Call review of draft-ietf-ospf-ttz-05

[Huaimo Chen]

Hi Orit,

Thanks much for your time for reviewing the document. 
We will fix the nits.

Best Regards,
Huaimo
-Original Message-
From: Orit Levin [mailto:or...@microsoft.com] 
Sent: Tuesday, January 03, 2017 7:12 PM
To: gen-art@ietf.org
Cc: i...@ietf.org; draft-ietf-ospf-ttz@tools.ietf.org
Subject: Gen-Art Last Call review of draft-ietf-ospf-ttz-05

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-ttz-05

Reviewer: Orit Levin

Review Date: 2017-01-03

IETF LC End Date: 2017-01-03

IESG Telechat date: (if known)



Summary:

This draft is well-written and well organized. It is basically ready for 
publication, but has a couple of nits that should be fixed before publication

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