Subject: [PWE3] Shepherd review of draft-ietf-pwe3-dynamic-ms-pw

From: Loa Andersson <[email-masked]>
Date: Thu, 20 Jun 2013 18:21:45 +0200

Shepherd review of draft-ietf-pwe3-dynamic-ms-pw-16
===================================================

Authors/Editors I've reviewed draft-ietf-pwe3-dynamic-ms-pw-16.txt.
In general I think the docment is useful, well-written and about
ready to be publish as an RFC on the standards track.

I reviewed version -16, but the now active document version -17
contains no other changes than version number and dates.

I've also set the word document I've been working on to the authors.

My comments are both technical and related to the style on how RFCs
should be should be written, i.e.
http://www.rfc-editor.org/rfc-style-guide/rfc-style.

Being this late in the wg process some of the are also a bit nitty
gritty, but if we want smooth ride through AD review, IESG review and
the the editing by the RFC Editor we'd better fix them now.

Comments per section:

Document header
===============
Comment - 1:
--------
Since this document updates RFC6073 this needs to be spelled out in
the header (more details in the commens on the IANA section (section 10)).

Titel:
=====

Current text:
Dynamic Placement of Multi Segment Pseudowires

Comment -2:
--------
There is a list kept by the RFC Editor of well-known RFC acrononyms
are expanded
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt for
MS-PW it says  Multi-Segment Pseudowire.

Section 1:
==========
Current text:
1.  Major Co-authors

Comment-3:
----------
There is nothing to say about the content of this section, but the
the structure of this document is not according to the RFC style
guide. Is that motivated, or should it just be updated to meet what
is said in http://www.rfc-editor.org/rfc-style-guide/rfc-style?

Comment-4:
----------
The RFC Style guide says:
"a) Introduction
     The introduction section should always be the first section
     following the Table of Contents (except in the case of MIBs).
     While we recommend "Introduction" as the title for this section,
     authors sometimes choose alternate titles such as "Overview" or
     "Background"."

Section 2:
==========
Current text:
2. Acknowledgements
Comment -5:
-----------
Again there is nothing to say about the content of the paragraph, but
again it breaks the structure required by the style guide.
"Acknowledgements" is normally placed just before the "Author’s
Address” section and after an "Contributors" section.

Section 3:
==========
Current text:
3. Introduction
Comment - 6:
------------
This section should be Section 1.

Section 3.1.
============
First sentence of the first paragraph says:
    "[RFC5023] describes the service provider requirements for
     extending the reach of pseudowires across multiple PSN  domains.
     This is achieved using a Multi-segment Pseudowire (MS-PW)."
Comment- 7:
-----------
PSN is a well know abbreviation, but since it in the RFC-Editors
list of abbreviations are expanded two different ways and we here
is (my opinion) within the scope of reasonable doubts of which is
intended it should be expanded.

Second sentence of the first paragraph says:
    "An MS-PW is defined as a set of two or more contiguous PW segments
    that behave and function as a single point-to-point PW ."
Comment - 8:
I can’t find any active wg docs or RFCs on P2MP PWs, there is at
least one individual contribution on protection of P2MP – and
there have been other discussions. The way this is written it seems
that MS-PW’s are not for P2MP, if dynamic placement of P2MP PWs are
thought to be possible you should add “Dynamic placement of P2MP PWs
are for further study and out of scope for this document”.

Section 3.3
===========

Bullet 3, 4 and 5 says:
"    - Forward Direction: ST-PE to TT-PE.
      - Reverse Direction: TT-PE to ST-PE
      - Forwarding Direction  : Direction of control plane,
        signaling flow"

Comment - 9:
----------
Probably not that important, but since you want to distinguish
between ”Forward Direction” and ”Forwarding Direction” you not
making it easy by choosing terms that close. I have no better
suggestion just now.

Comment - 10:
-----------
This indicates that there is no CP signal flow in the reverse
direction – What about talking about “Request direction” (for what
is now” Forwarding Direction” and which is the direction the LDP
flow is initiated and “Response direction” which is the direction
of the responses go?
On the other hand why bother – this is the only place “Forwarding
Direction" is used in the document.

Section 3.4
===========
Under the figure

Current text:
Figure 1: PW switching Reference Model

Comment - 11:
-------------
Proposed new text:
Figure 1: MS-PW switching Reference Model

First paragraph under the figure, first sentence.

Current text:

Figure 1 shows the architecture for a simple multi-segment case.

Comment - 12:
This confuses me a bit, I thought a reference model gave all the
info you need. And I think this reference model does; it would be
equally true if if there were three PSNs concatenated. Or if the
S-PE1 put the PW segments 3 and 4 in one PSN each. A reference model
gives you the architectural constructs, it does not describe
separate cases.
Propose to change the text to “Figure 1 shows the reference model
for MS-PWs”.

First paragraph under the figure, third sentence.

Current text:
These PEs reside in different PSNs.

Comment/Question - 13:
Is the ”different PSNs” really required couldn’t there be reasons
for a operator of a single PSN to use the MS-PW technology within
that PSN. Text seem to mandate “different PSNs”.

First paragraph under the figure, fourth sentence.

Current text:
    "A PSN tunnel extends from T-PE1 to S-PE1 across PSN1, and a
     second PSN tunnel extends from S-PE1 to T-PE2 across PSN2."

Comment - 14:
-------------
Propose new text:
A PSN tunnel extends from T-PE1 to S-PE1 across PSN1 (supporting
PW segment 1 and 2), and a second PSN tunnel extends from S-PE1
to T-PE2 (supporting PW segment 3 and 4) cross PSN2.

First paragraph under the figure, last sentence.

Current text:

"...in case of an MPLS PSN to another MPLS PSN PW switching the
operation is a standard MPLS label switch  operation."

Comment - 15:
-------------
I think this should be ”label swap operation” according to 3031.

Section 4.1
===========

Current text:
"The following OPTIONAL  TLVs are also defined:"

Comment - 16:
-------------
Yes 2119 defines OPTIONAL as part of the 2119 language, but I don’t
think it is motivated here, this it just categorizing the TLV as
optional, not specifying behaviour. Suggest using lower case -
optional.

Sectiom 5.
==========
First paragraph - first sentence.

Current text:
    "Single segment pseudowires on an MPLS PSN can use attachment
     circuit identifiers for a PW using FEC 129."

Comment - 17:
-------------
I'm not clear on what this sentence says.
- I can read it as that attachment circuits are optional if FEC129
   are used.
- I can also read it as attachment circuit are allowed if FEC129
   is used
- I think there are a couple of other interpretations, can you
   be clearer?
   Could we use MAY? If there are cases when the identifiers are
   not necessary, otherwise just delete ”can”.

First paragraph - second sentence:

"...there is a requirement for the identifiers for the
    attachment circuits to be globally unique,...

Comment - 18:
-------------
Is this clearer ”...it is required that the attachment circuit
identifiers (AC ID) are globally unique,...”  ???

As far I can see this is the first place where Attachment Circuit
Identifiers” are mention and since acronym is used later this is
the place to introduce&expand the acronym.

Section 5.1
===========
Figure

Comment - 19:
-------------

Exactly what is the Global ID.
Please explain what all the fields in the TLVs are immediately
below the figure.

Comment - 20
------------

In the figure and the sentence just after the figure:

The LDP protocol introduced (or at least picked up) a praxis that
the fields in TLV are explained just after the figures – can you
please do so here also.
BTW AII is not one of the well known acronyms, please expand!

First paragraph on page 7; the parenthesis at the end of the
paragraph.

Current text:
(knows the address in priori by provisioning)

Comment - 21:
-------------
Not sure this English :).
Can we use: (the PE know the address from provisioning).

Last paragraph.

Comment - 22:
Is ”PW domain” defined anywhere; add a reference.
.pw stands for professional web in other contexts.
I can’t find a definition of “Pseudowire Domain (PW Domain)”.
The term is used in 5659 but not defined.
Thinking about it might be that what is called PSNs in figure 1 is
really PW Domains.

Section 5.2
===========
Comment - 23:
-------------
I'm not sure what this paragraph really says. I think you intend to
say that on each S-PE each PW must be individual accessible in
order to configure it.
Can this be made clearer?
Is AI address = AII address?

Section 6.1.1
=============
Comment- 24
-----------
A general comment on AII, TAII and TAI, they are not among the well
known acronyms, please expand when first used.

Section 6.1.2
=============
Last part of the paragraph.

Comment - 25:
-------------
Exactly what is ”S-PE1” here – IP address??
Why is this specific to S-PE1, does it not apply to e.g. S-PE2??

Section 6.1.3
=============
Current text:
"...Border Gateway Protocol (BGP) [RFC4760]..."

Comment - 26:
I’m not an BGP expert but RFC4760 is Multoprotocol Extensions
for BGP. The BGP specification is RFC 4271. It is correct to
reference RFC4670, but the text should be clearer point out what
it is.
I can imagine a couple of ways to do this, but would prefer:
"...MAY choose to use Border Gateway Protocol (BGP) [RFC4721]
with the Multiprotocol Extensions as defined in [RFC4760] to
propagate PW address information throughout the PSN."

Start of the second paragraph.

Current text:
"Contrary to other l2vpn signaling methods that..."

Comment/Question - 27::

Do we consider PWE3 signaling to be an l2vpn method?

The figure:

Comment - 28:
Well, yes and maybe this is sufficient, but it is a t least a bit
hard to read, I’d prefer to have all 168 bits spelled out in the
figure. Any reason not to?

Section 6.2.1
=============
First sentence.

This section is not clear about the difference about BW and QoS,
it says ”BW signaling”, but claim to be able to meet QoS in general.

Paragraph before the figure.

Comment - 29:
I still don’t think the 2119-language is need to describe the TLV,
2119-language is for requirements to be met.
OPTIONAL should be optional.

Section 8
=========
Second paragraph, last sentence.

Current text:

"In this case, the following type MUST be used in place of type 0x01
  in the PW switching point TLV:"

Comment - 30:
-------------
Proposed text "In this case, the following sub-TLV type (0x06) MUST
be used in place of type 0x01 in the PW switching point TLV:"

Setion 10.
==========
First paragraph:

Comment - 31:
-------------
The first paragraph should be promoted to section "10.1 Corrections"

AND

Comment - 32:
-------------
As usual the devil is in the details. The IANA registry points to
RFC6073 for "L2 PW address of the PW Switching Point". RFC6073 says
that the length is 12 (bytes), so this is really an update of RFC6073.
This needs to be captured in the Abstract, Introduction and
document header.
And in this document it should also be clear in section 8.

(Current) Section 10.1
======================
First paragraph, first sentence.

Current text:

    This document uses several  new LDP TLV types

Comment - 33:
-------------
There is only one new LDP TLV Type defined by this document.

Current test:
IANA already maintains a registry of name "TLV TYPE NAME SPACE"
defined by RFC5036

Comment -34:
------------
The correct name of the registry is ”Type, Length, and Value (TLV)
Type Name Space”. Please update; bothe here and the title of
(current) section 10.1.

First paragraph, first sentence:

Current text:
"...IANA already maintains..."

Comment - 35:
-------------
"Already" is unneccessary.

First paragraph, last sentence.

Current text:
"The following values are suggested  for assignment:"

Comment - 36:
-------------
Well – no! We should say that IANA is requested to  assign on
permanent basis the value (0x096E) that has been assigned to this
document by early allocation.
Proposed text:
"The IANA is requested to assign on permanent basis  the value
(0x096E)  that has been assigned to this document by early
allocation (TEMPORARY - Expires 2008-11-21)."

Comment - 37:
-------------
Please change the first paragarph of the current section 10.1 to:

    This document defines one new LDP TLV types. IANA already maintains
    a registry for LDP TLV types called "Type, Length, and Value
    (TLV) Type Name Space" within the "Label Distribution Protocol
    (LDP) Parameters" as defined by RFC5036. The IANA is requested
    to assign on permanent basis the value (0x096E)  that has been
    assigned to this document by early allocation (TEMPORARY -
    Expires 2008-11-21).:

The picture of the of the IANA allocation should look like this:

Value 	Description 	Reference 	Notes/Registration Date
------+----------------+---------------+-----------------------
0x096E  Bandwidth TLV   This document

(current) Section 10.2
======================
Current text:
"...IANA already maintains...

Comment - 38:
-------------
"already" is unneccessary.

Comment - 39:

Based on the comments on section 101.1, section 10.2 should be
changed to:

   "This document defines three new LDP status codes. IANA
    maintains a registry of called "STATUS CODE NAME SPACE" in the
    "Label Distribution Protocol (LDP) Parameters" as defined by
    RFC5036. The IANA is requested to assign on permanent basis the
    values that has been assigned to this document by early allocation
    (TEMPORARY - Expires 2008-11-21).:"

The table describing the IANA allocation should look like this:

    Range/Value     E     Description                       Reference
    ------------- -----   ----------------------            ---------
     0x00000037     0     Bandwidth resources unavailable   This doc.
     0x00000038     0     Resources Unavailable             This doc.
     0x00000039     0     AII Unreachable                   This doc.

(Current) Section 10.3
======================
Comment - 40:
Folowing the comments on section 10.1 and 10.2 the last sentence in
the first paragraph of section 10.3 should be changed to:

"The IANA is requested to assign on permanent basis the value (6)
  that has been assigned to this document by early allocation
  (TEMPORARY - Expires 2008-11-21):"

Section 13. Author's Address
============================
Comment - 41:
-------------
Since this document has been in progress for at least
five years can you please check if the contact info needs
to be updated.

/Loa
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64