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

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Thu, 4 Jul 2013 15:21:04 +0000

Loa

Thank you very much for your detailed review.

Please see below for some responses to your comments.

Best regards

Matthew

On 20/06/2013 17:21, "Loa Andersson" <[email-masked]> wrote:

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

Agreed

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

Agreed. I will change it to 'Dynamic Placement of Multi-Segment
Pseudowires'.

>
>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?

I will rearrange the sections according to the guide. I think the existing
arrangement is a result of this draft being around long before the current
version of the style guide.

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

Agreed, I'll move it.

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

OK

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

Ok

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

It is true that the MS-PW Architecture (RFC5659) only defines MS-Pws as
P2P. There has been some work to define requirements and a framework for
P2MP Pws, that includes MS-PW, but I think we always intended to extend
the P2P drafts/rfcs for this, rather than to define P2MP in the base RFCs.
I.e. There is no proper consideration of P2MP in the dynamic MS-PW draft.
Therefore, I agree with adding your proposed statement.
>
>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.
>

I agree. I think we can probably remove this term. In fact, it is the
direction of the label mapping flow for a given 'forward' or 'reverse'
direction of the PW. It is not a label request, as such (since this is
LDP-DU).

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

I think it should be 'MS-PW reference Model', as per RFC5659.

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

Agreed.

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

There are examples where operators use MS-Pws and the segments of a given
PW can be said to span the same PSN. So I do not think that separate PSNs
should be mandated and there is nothing in the technology to restrict its
use to interconnection of separate PSNs.  However, RFC5659 does talk about
PSN 1 and PSN 2 in the reference model.

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

OK

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

Agreed.

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

OK

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

I think we were trying to say that FEC129 MAY be used to identify
attachment circuits of a single segment PW. It's not the attachment
circuits that are optional, but rather the way you identify them.

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

Ok

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

These are specified in RFC5003, so I propose adding a sentence to this
effect. In addition, I think the rest of the figures in the draft need
titles.

>
>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!

OK, but is it acceptable to point to RFC5003, otherwise we risk redefining
them here?

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

I think the following might be clearer:

"AII
   Type 2 based PW addressing is suitable for point-to-point
   provisioning models where auto-discovery of the address
   at the Target T-PE is not required. That is, it is known a-priori by
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.

Yes, I agree. I think it would read better as follows:

"For the purpose of MS-PWs, the AII MUST be globally unique across all
   PSNs that the MS-PW spanned by the MS-PW."

>
>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?

Well, this is actually trying to say that each S-PE has a special address
which identifies it from a pseudowire perspective. That is, it is an
identifier for the node along the path of the MS-PW.

>Is AI address = AII address?

Not quite. The AI is composed of the AGI and the AII (as defined in
RFC6074). The usage does seem incorrect here, and I think it would better
read:
"For this purpose, at least one address of a format similar to
   AII type 2 [RFC5003 ] composed of the Global ID, and Prefix part,
   only, MUST be assigned to each S-PE.

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

OK

>
>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??

Yes, it would typically be an address representing the far end of the tLDP
session to the next hop. This would apply to all next-hop Pes, whether
they are S-Pes or T-Pes. So, it should probably read:

Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling Hop
= {IP address of next hop S-PE or T-PE}

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

Agreed.

>
>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?

Yes, but in any case I think the paragraph is not quire correct. In
RFC6074, BGP is used for auto discovery, and LDP is used for signalling.
So I think this  should read
"
Contrary to layer 2 VPN signaling methods that use BGP [RFC6074] for auto
discovery, in
   the case of the dynamically placed MS-PW, the source T-PE knows a-
   priori (by provisioning) the AC ID on the terminating T-PE that
signaling should use."

>
>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?

This follows the convention used in RFC4670. I agree with you that it
would be clearer to spell it out, though.

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

Yes, I agree. I'll try to rephrase this in the next revision to indicate
that BW reservation is only one part of achieving QoS objectives.

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

OK

>
>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:"

OK

>
>Setion 10.
>==========
>First paragraph:
>
>Comment - 31:
>-------------
>The first paragraph should be promoted to section "10.1 Corrections"

OK

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

Ok

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

OK. This is historical. I'll fix in the next revision.

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

OK

>
>First paragraph, first sentence:
>
>Current text:
>"...IANA already maintains..."
>
>Comment - 35:
>-------------
>"Already" is unneccessary.

OK

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

OK

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

OK

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

OK

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

OK

>
>(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):"

OK

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

OK. 

>
>
>/Loa
>-- 
>
>
>Loa Andersson                        email: [email-masked]
>Senior MPLS Expert                          [email-masked]
>Huawei Technologies (consultant)     phone: +46 739 81 21 64
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pwe3

---

From: Loa Andersson <[email-masked]>
Date: Fri, 05 Jul 2013 10:41:32 +0200

Matthew,

I'm quite happy with your responses to my comments. Please use
references to existing definitions. e.g. to RFC 5003 for Global ID,
whenever possible.

I'll wait for the updated version before go ahead and request
publication.

BTW - we still have less than half of the expected responses to the
IPR poll. Would be good if the authors could remind each other that
it is necessary to respond.

/Loa

--