Re: [Gen-art] Genart last call review of draft-ietf-mpls-egress-protection-framework-05

[Yimin Shen]

Hi Peter,

Thanks very much for your detailed review for this draft! We will fix these 
issues in the next version.

Thanks,

-- Yimin Shen

On 6/21/19, 12:50 AM, "Peter Yee via Datatracker"  wrote:

Reviewer: Peter Yee
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


<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_gen_wiki_GenArtfaq=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug=61TkOv7C_RPT7dnqd0XVzhHp5Z3upqOSAqO5uQS1Pd8=L5X3khIidqv94LrBgsAHkZ66kkCliEdYqP0bbir_w-w=
 >.

Document: draft-ietf-mpls-egress-protection-framework-05
Reviewer: Peter Yee
Review Date: 2019-06-20
IETF LC End Date: 2019-06-17
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with Nits.  I didn't really find any substantial issues with 
the
document, although I admit this one is quite out of my area of expertise.  
I'm
reduced to making sure it sounds logical (it does) and trying to reduce the
(future) burden on the RFC Editor.

Major issues:

Minor issues:

Nits/editorial comments:

General:

For each occurrence of "e.g." and "i.e.", make sure that it is followed by a
comma and a single space.  There are some occurrences of double spaces and
pretty much no commas.

Change "aka." to "aka" or to "a.k.a."

Specific:

Page 1, Abstract, 3rd sentence: change "context based" to "context-based".

Page 3, section 1, 2nd paragraph, 1st sentence: change "repair based" to
"repair-based".  Insert "and" before "[RFC7812]" or put the sequence of
references inside of parentheses.

Page 3, section 1, 2nd paragraph, 2nd sentence: delete the comma and "i.e."
after "PLR".  Put "point of local repair" in brackets.  Delete the comma and
"i.e." after "MP" and place "merge point" inside brackets.

Page 7, section 4, 1st bullet item: append a comma after the first 
occurrence
of "MP2P".

Page 7, section 4, 4th bullet item, 2nd sentence: insert "on a" before
"per-service-destination".

Page 9, 1st bullet item: change "Or" to "or".

Page 10, 1st partial paragraph, last sentence: change "It" to "it".

Page 10, section 5.4, 2nd paragraph, 3rd sentence: delete extraneous space
between "{E, P1}" and the following comma.

Page 11, section 5.7 title: change "context based" to "context-based".

Page 14, item 3, 4th sentence: change "any-cast" to "anycast".

Page 14, item 3, last sentence: I can't parse the end of that sentence.  Do 
you
want one or the other of "to" and "in", or is there a word or words missing 
in
there?

Page 15, 1st paragraph, 1st sentence: append "of" after "AS'".  And I'll 
just
say that that's a very labored construction to avoid using "ASs" or "AS's" 
in
the sentence.  It took be a while to parse what was meant.

Page 16, 1st full paragraph, 1st sentence: insert "the" before "PLR".

Page 18, 1st paragraph, last sentence: change the first occurrence of "in" 
to
"if".

Page 19, 1st partial paragraph, 1st full sentence: change "Figure-3" to 
"Figure
3" to match the figure's actual labeling.

Page 21, section 8, 1st sentence: append a comma after "far".

Page 25, section 11, 2nd paragraph, 2nd sentence: insert "of" before 
"trust".




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

Re: [Gen-art] Review of draft-ietf-pals-endpoint-fast-protection-04

[Yimin Shen]

Hi Dale,

Thanks very much for such a detailed review and comments! We will look into 
each point, and revise and clarify as you suggested.

Thanks,

-- Yimin


Andy

On Tue, Dec 6, 2016 at 11:27 AM, IETF Secretariat 
> wrote:
Reviewer: Dale Worley
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-pals-endpoint-fast-protection-04
Reviewer: Dale R. Worley
Review Date: 2016-12-06
IETF LC End Date: 2016-12-06
IESG Telechat date: (not set)

Before reviewing this document, I knew nothing about pseudowire
routing, so my review does not fully assess the technical aspects of
the document.  I suspect that almost all of these items are editorial.
I hope that they are simply places where the description can be made
clearer to the naive reader by making it more exact.  Some of them may
be places where I don't fully understand the technology.  It's
possible that some of them are technical issues.

Summary:

This draft is basically ready for publication, but has nits that
should be fixed before publication.

These items seem to have technical content:

In section 4.2 and 4.3, it is not clear to me whether all of the PWs
being carried by a particular tunnel must have the same protector.
Section 4.2 says that it is so, but section 4.3 suggests that the PWs
can be divided into subsets which have different protectors, without
mentioning any correspondence between the subsets and the
tunnel-groups of PWs.

What is the mechanics of context identifiers in the context of
protecting egress ACs?  It seems like this should all be analogous to
the described cases (protecting PEs), but as this is a specification,
how the analogy works should be made explicit.

In section 6.4, does there need to be a specification for the
"Reserved" fields of the Protection FEC Element TLV?  Usually, there
is a specification "must be sent with zeros/must be ignored on
receipt".  (Or is there a global understanding of this in LDP?)

In section 6.4, there is a definition of "PW Information".  Are there
previous definitions of "PW information" in PW/LDP/MPLS usage?  It
looks a lot like what's defined in RFC 4447 sections 5.2 and 5.3.  If
they are semantically the same, the same format should be used and
simply referred to here.  If the format is different because they
aren't semantically the same ... perhaps there should be a note
explaining how/why.

Nits/editorial comments:

There are quite a number of places where "a" or "the" seems to be
omitted before nouns.  I'll let the RFC Editor identify/correct those.

There is a general issue regarding what aspects of local repair are
configured by some external means (e.g., the protectors that PLRs use,
the context identifiers) and what aspects are established
automagically by the defined mechanisms (the bypass tunnels).  The
document would have been clearer to me if these were separated
explicitly, but I suspect that it is common usage in routing
specifications for the reader to sort it out.

Abstract

IMO it would help if the Abstract mentioned that only IP/MPLS
transport tunnels are protected.  I say this because the only part of
this technology that I'd previously heard of was MPLS; such a
specification in the abstract would tell a large body of potential
readers that the document is *not* relevant to their situation.

1.  Introduction

   The mechanism is applicable to LDP signaled PWs.  It is relevant to
   networks with redundant PWs and multi-homed CEs.  It is designed on
   the basis of MPLS upstream label assignment and context-specific
   label switching [RFC5331].

It might be more informative to say "Fast failure protection for
pseudowire endpoints" rather than "The mechanism".

Which of the factors listed are prerequisites for the use of this
mechanism and which are factors which this mechanism additionally
supports?

Whichever of these are prerequisites for the solution should be
mentioned as such in the Abstract, including particularly that the PW
must be carried by IP/MPLS transport tunnels (as described in section
4.1 paragraph 2).

   Fast protection refers to its ability to
   restore traffic in the order of tens of milliseconds.  Compared
with
   global repair and control plane repair, this mechanism can provide
   faster service restoration.

What is the time scale of "global repair and control plane repair"?
Given that you give the time scale of "fast protection", it would be
informative to have comparable values for other repair techniques.

   However, it is intended to complement
   those mechanisms, rather than replacing them.

It might be useful to explain why