Skip to main content

Early Review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
review-ietf-pals-mpls-tp-pw-over-bidir-lsp-06-rtgdir-early-ceccarelli-2016-04-26-00

Request Review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp
Requested revision No specific revision (document currently at 09)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-04-26
Requested 2016-04-11
Authors Mach Chen , Wei Cao , Attila Takacs , Ping Pan
I-D last updated 2016-04-26
Completed reviews Genart Telechat review of -08 by Roni Even (diff)
Secdir Last Call review of -08 by Christian Huitema (diff)
Opsdir Last Call review of -06 by Sarah Banks (diff)
Rtgdir Early review of -06 by Daniele Ceccarelli (diff)
Assignment Reviewer Daniele Ceccarelli
State Completed
Request Early review on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp by Routing Area Directorate Assigned
Reviewed revision 06 (document currently at 09)
Result Has nits
Completed 2016-04-26
review-ietf-pals-mpls-tp-pw-over-bidir-lsp-06-rtgdir-early-ceccarelli-2016-04-26-00

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.

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