Subject: Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 25 Apr 2016 17:09:16 +0000

Resending to the right exploder

From: Daniele Ceccarelli
Sent: lunedì 25 aprile 2016 19:04
To: <[email-masked]> ([email-masked])
Cc: [email-masked]'; [email-masked]'
Subject: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
Reviewer: Daniele Ceccarelli
Review Date: April 25 2016
IETF LC End Date: -
Intended Status: Standard Track
Summary:

  *   I have some minor concerns about this document that I think should be resolved before publication.
Comments:

  *   What the drafts is proposing as protocol modification is clear and also the operation section are pretty straighforward. What needs to be improved is the introduction part, which should be reviewed by a native English speaker. Also the IANA section should be made clearer.
Major Issues:

  *   No major issues found
Minor Issues:

  *   Abstract: “In addition, the user traffic may traverse through multiple transport networks.” Maybe is worth elaborating a bit this sentence saying that the extensions defined in this draft apply both to SS-PW and MS-PW.
  *   In the abstract it is said that a PW is linked to an LSP but then in the intro it is said that the PW binding is to a tunnel. Can you clarify this? I’d say that it should be linked to a tunnel, right?
  *   Intro:   “PW-to-PSN Tunnel binding has become increasingly common and important in many deployment scenarios”. I guess you mean an automatic binding done via a signaling protocol?
  *   What do you mean with “may traverse through different routes”? I suggest leaving “may traverse multiple networks or domains.
  *   Intro and Figure 1: could be example be made a bit more generic with a network between the PEs? With directly connected PEs it doesn’t seem a realistic and generic enough example.
  *   Intro: suggest removing “As mentioned above”.
  *    The name of the draft explicitly mentions MPLS-TP but in the rest of the draft there is no mention of it, just the much more general Packet Switching Network term is used.
  *   Section 2:   “This document defines a new optional TLV, PSN Tunnel Binding TLV, to communicate tunnel/LSPs selection and binding requests between PEs. “ The binding request is between PEs? Or between an PW and a Tunnel (or LSP?) between two PEs?
  *   Section 2: Strict binding vs Co-routed binding: from the description it seems that the first one is strict and the second one is “loose” (in the sense that the PE can accept the request or not). Don’t both apply to co-routed LSPs?
  *   Section 2: ”The terminology "LSP" is  identical to the "LSP tunnel" defined in Section 2.1 of [RFC3209],  which is uniquely identified by the SESSION object together with  SENDER_TEMPLATE (or FILTER_SPEC) object that consists of LSP ID and Tunnel endpoint address.” Why is the draft considering only signaled LSPs? Doesn’t it apply also to centrally provisioned ones? (e.g. NMS or SDN).
  *   Section 2.1: “LDP Label Mapping message” missing reference. And why the Type field starts with 1 and 0?
Nits:

  *   Abstract s/ traverse through multiple/ traverse multiple
  *   Introduction: “Pseudowire (PW) Emulation Edge-to-Edge (PWE3)”. I suggest removing (PW), it’s already included into PWE3.
  *   Intro: s/ a bidirectional circuits/ a bidirectional circuit
  *   Intro: suggest rephrasing: “Bidirectional LSPs share fate and simplify the routing of a protection path also consisting of bidirectional   LSPs because working and protection paths have to be disjoint.”
  *   Intro: s/ there are a large number/ there is a large number
  *   Intro:s/to be carried/are carried
  *   Intro:s/there are a number/there is a number
  *   Intro: s/ traffic belongs/traffic belonging
  *   Intro: (suggestion) s/(PE1-P3-PE2)/ (PE2-P3-PE1) since we are speaking about directionality it makes more sense to list the nodes of the path in the reverse direction.
  *   Intro: s/ The similar problems/A similar problem
  *   Intro: s/ won't/does not
  *   Intro: s/ In this document, it introduces/This document introduces
BR
Daniele

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 25 Apr 2016 14:39:47 -0400

Daniele,

On behalf of the PALS WG, thanks for your review!

Cheers,
Andy

On Mon, Apr 25, 2016 at 1:09 PM, Daniele Ceccarelli <
[email-masked]> wrote:

> *From:* Daniele Ceccarelli
> *Sent:* lunedì 25 aprile 2016 19:04
> *To:* <[email-masked]> ([email-masked])
> *Cc:* [email-masked]'; '
> [email-masked]'
> *Subject:* RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
>
>
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and sometimes
> on special request. The purpose of the review is to provide assistance to
> the Routing ADs. For more information about the Routing Directorate, please
> see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> *Summary:*
>    - I have some minor concerns about this document that I think should
>    be resolved before publication.
>
> *Comments:*
>
>    - What the drafts is proposing as protocol modification is clear and
>    also the operation section are pretty straighforward. What needs to be
>    improved is the introduction part, which should be reviewed by a native
>    English speaker. Also the IANA section should be made clearer.
>
> *Major Issues:*
>
>    - No major issues found
>
> *Minor Issues:*
>
>    - Abstract: “In addition, the user traffic may traverse through
>    multiple transport networks.” Maybe is worth elaborating a bit this
>    sentence saying that the extensions defined in this draft apply both to
>    SS-PW and MS-PW.
>    - In the abstract it is said that a PW is linked to an LSP but then in
>    the intro it is said that the PW binding is to a tunnel. Can you clarify
>    this? I’d say that it should be linked to a tunnel, right?
>    - Intro:   “PW-to-PSN Tunnel binding has become increasingly common
>    and important in many deployment scenarios”. I guess you mean an automatic
>    binding done via a signaling protocol?
>    - What do you mean with “may traverse through different routes”? I
>    suggest leaving “may traverse multiple networks or domains.
>    - Intro and Figure 1: could be example be made a bit more generic with
>    a network between the PEs? With directly connected PEs it doesn’t seem a
>    realistic and generic enough example.
>    - Intro: suggest removing “As mentioned above”.
>    -  The name of the draft explicitly mentions MPLS-TP but in the rest
>    of the draft there is no mention of it, just the much more general Packet
>    Switching Network term is used.
>    - Section 2:   “This document defines a new optional TLV, PSN Tunnel
>    Binding TLV, to communicate tunnel/LSPs selection and binding requests
>    between PEs. “ The binding request is between PEs? Or between an PW and a
>    Tunnel (or LSP?) between two PEs?
>    - Section 2: Strict binding vs Co-routed binding: from the description
>    it seems that the first one is strict and the second one is “loose” (in the
>    sense that the PE can accept the request or not). Don’t both apply to
>    co-routed LSPs?
>    - Section 2: ”The terminology "LSP" is  identical to the "LSP tunnel"
>    defined in Section 2.1 of [RFC3209],  which is uniquely identified by the
>    SESSION object together with  SENDER_TEMPLATE (or FILTER_SPEC) object that
>    consists of LSP ID and Tunnel endpoint address.” Why is the draft
>    considering only signaled LSPs? Doesn’t it apply also to centrally
>    provisioned ones? (e.g. NMS or SDN).
>    - Section 2.1: “LDP Label Mapping message” missing reference. And why
>    the Type field starts with 1 and 0?
>
> *Nits:*
>
>    - Abstract s/ traverse through multiple/ traverse multiple
>    - Introduction: “Pseudowire (PW) Emulation Edge-to-Edge (PWE3)”. I
>    suggest removing (PW), it’s already included into PWE3.
>    - Intro: s/ a bidirectional circuits/ a bidirectional circuit
>    - Intro: suggest rephrasing: “Bidirectional LSPs share fate and
>    simplify the routing of a protection path also consisting of
>    bidirectional   LSPs because working and protection paths have to be
>    disjoint.”
>    - Intro: s/ there are a large number/ there is a large number
>    - Intro:s/to be carried/are carried
>    - Intro:s/there are a number/there is a number
>    - Intro: s/ traffic belongs/traffic belonging
>    - Intro: (suggestion) s/(PE1-P3-PE2)/ (PE2-P3-PE1) since we are
>    speaking about directionality it makes more sense to list the nodes of the
>    path in the reverse direction.
>    - Intro: s/ The similar problems/A similar problem
>    - Intro: s/ won't/does not
>    - Intro: s/ In this document, it introduces/This document introduces
>
> BR
> Daniele
>
>
>
>
>
> _______________________________________________
> Pals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pals
>
>