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

[Mach Chen <[e-mail]>]

Thanks Daniele!

We have uploaded the version-07 to address the RtgDir review comments. 

Htmlized:       https://tools.ietf.org/html/draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-07
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-07

Best regards,
Mach

> -----Original Message-----
> From: Daniele Ceccarelli [mailto:[e-mail]]
> Sent: Wednesday, May 25, 2016 6:03 PM
> To: Mach Chen; <[e-mail]> ([e-mail])
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
> 
> That's perfect!
> 
> BR
> Daniele
> 
> > -----Original Message-----
> > From: Mach Chen [mailto:[e-mail]]
> > Sent: mercoledì 25 maggio 2016 11:47
> > To: Daniele Ceccarelli <[e-mail]>;
> > <[e-mail]>
> > ([e-mail]) <[e-mail]>
> > Cc: [e-mail]; draft-ietf-pals-mpls-tp-pw-over-bidir-
> > [e-mail]; [e-mail]
> > Subject: RE: RtgDir review:
> > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
> >
> > Hi Daniele,
> >
> > Yes, your understanding is right. How about add the following text:
> >
> > The U-bit and F-bit are defined Section 3.3 RFC5036. Since the PSN
> > Tunnel Binding TLV is an optional TLV, the U-bit MUST be set to 1 so
> > that a receiver MUST silently ignore this TLV if unknown to it, and
> > continue processing the rest of the message.
> > A receiver of this TLV is not allowed to forward the TLV further when
> > it does not know the TLV. So, the F-bit MUST be set to 0.
> >
> > Thanks,
> > Mach
> >
> > > -----Original Message-----
> > > From: Daniele Ceccarelli [mailto:[e-mail]]
> > > Sent: Wednesday, May 25, 2016 5:21 PM
> > > To: Mach Chen; <[e-mail]> ([e-mail])
> > > Cc: [e-mail];
> > > [e-mail];
> > > [e-mail]
> > > Subject: RE: RtgDir review:
> > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
> > >
> > > Hi Mach,
> > >
> > > Ok, let me try to summarize.
> > >
> > > The draft defines a new TLV for the LDP Mapping Message (RFC 5036
> > > section
> > > 3.5.7) which I guess would end up in the "optional parameters" field
> > > (the text
> > > says: "contains 0 or more parameters, each encoded as a TLV").
> > > Then section 3.3 mandates how to build those TLVs (U, F and so on).
> > >
> > > If my understanding correct? If yes I suggest to state it in the
> > > text and possibly add why the U bit is always 1 in your case and the
> > > F bit is
> > always 0.
> > >
> > > Thanks for the explanation
> > > Daniele
> > >
> > > > -----Original Message-----
> > > > From: Mach Chen [mailto:[e-mail]]
> > > > Sent: mercoledì 25 maggio 2016 11:02
> > > > To: Daniele Ceccarelli <[e-mail]>;
> > > > <[e-mail]>
> > > > ([e-mail]) <[e-mail]>
> > > > Cc: [e-mail]; draft-ietf-pals-mpls-tp-pw-over-bidir-
> > > > [e-mail]; [e-mail]
> > > > Subject: RE: RtgDir review:
> > > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
> > > >
> > > > Hi Daniele,
> > > >
> > > > > -----Original Message-----
> > > > > From: Daniele Ceccarelli
> > > > > [mailto:[e-mail]]
> > > > > Sent: Wednesday, May 25, 2016 4:08 PM
> > > > > To: Mach Chen; <[e-mail]> ([e-mail])
> > > > > Cc: [e-mail];
> > > > > [e-mail];
> > > > > [e-mail]
> > > > > Subject: RE: RtgDir review:
> > > > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
> > > > >
> > > > > Hi Mach,
> > > > >
> > > > > Thanks for the update.
> > > > > There is just one outstanding point:
> > > > >
> > > > > > • Section 2.1: “LDP Label Mapping message” missing reference.
> > > > > > And why the Type field starts with 1 and 0?
> > > > > Thanks for adding the reference but I still don't get why the
> > > > > Type field starts with 1 and 0.
> > > >
> > > > The first two bits are U-bit and F-bit, which are defined in
> > > > Section
> > > > 3.3 of RFC5036. How about adding the follow text:
> > > >
> > > > For this TLV, the Unknown TLV bit (U-bit) (Section 3.3 of RFC5036)
> > > > is set to 1, and the Forwarding unknown bit (F-bit) (Section 3.3
> > > > of
> > > > RFC5036) is
> > > set to 0.
> > > >
> > > > > One more comment that I lost during the first iteration: why do
> > > > > you define the "flag" field in figure 3 and then below have a
> > > > > further figure showing C, S, T and the must be zero field? I'd
> > > > > directly put the C,S,T and must be zero fields in place of the
> > > > > Flag field in figure 3. It
> > > > helps with readability IMHO.
> > > >
> > > > OK, will put them back to the TLV and remove the flags figure.
> > > >
> > > >
> > > > Hope above address your comments!
> > > >
> > > > Thanks,
> > > > Mach
> > > > >
> > > > >
> > > > > BR
> > > > > Daniele
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Mach Chen [mailto:[e-mail]]
> > > > > > Sent: venerdì 13 maggio 2016 09:25
> > > > > > To: Daniele Ceccarelli <[e-mail]>;
> > > > > > <[e-mail]>
> > > > > > ([e-mail]) <[e-mail]>
> > > > > > Cc: [e-mail]; draft-ietf-pals-mpls-tp-pw-over-bidir-
> > > > > > [e-mail]; [e-mail]
> > > > > > Subject: RE: RtgDir review:
> > > > > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
> > > > > >
> > > > > > Hi Daniele,
> > > > > >
> > > > > > Thanks for the detailed review and valuable comments!
> > > > > >
> > > > > > Please see my responses inline...
> > > > > >
> > > > > > I also attached a diff that shows the updates that try to
> > > > > > address your comments. If you are OK with the updates, I will
> > > > > > submit
> > it then.
> > > > > >
> > > > > > Thanks,
> > > > > > Mach
> > > > > >
> > > > > > > From: Daniele Ceccarelli
> > > > > > > Sent: lunedì 25 aprile 2016 19:04
> > > > > > > To: <[e-mail]> ([e-mail])
> > > > > > > Cc: '[e-mail]';
> > > > > > > 'draft-ietf-pals-mpls-tp-pw-over-bidir-
> > > > [e-mail]'
> > > > > > > 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.
> > > > > > > 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.
> > > > > >
> > > > > > Thanks for your suggestion, I assume the RFC editor will do
> > > > > > another review once the document progressed to that stage.
> > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > How about this:
> > > > > >
> > > > > > "Many transport services require that user traffic, in the
> > > > > > form of Pseudowires (PW), be delivered on a single co-routed
> > > > > > bidirectional tunnel or two tunnels that share the same routes.
> > > > > > This document defines an optional extension to LDP that
> > > > > > enables the binding between PWs and the underlying TE tunnels.
> > > > > > The extension applies to both 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?
> > > > > >
> > > > > > Yes, it's better to use tunnel, I have updated the abstract to
> > > > > > make Abstract and Introduction have the consistent usage.
> > > > > > Please see above the new text for Abstract.
> > > > > >
> > > > > > > • 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?
> > > > > >
> > > > > > No, this sentence just brings the requirements of explicit PW
> > > > > > to PSN tunnel binding, whatever it is automatic signaling or
> > > > > > manual
> > > configuration.
> > > > > >
> > > > > > > • What do you mean with “may traverse through different routes”?
> > > > > > > I suggest leaving “may traverse multiple networks or domains.
> > > > > >
> > > > > > Here the "routes" means "paths".
> > > > > >
> > > > > > How about: "...may traverse through different paths or networks"?
> > > > > >
> > > > > > > • 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”.
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > > •  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.
> > > > > >
> > > > > > Indeed, that's the intention. This work was triggered by the
> > > > > > discussion of MPLS-TP. But with the progress of this draft and
> > > > > > discussion within the WG, there is a consensus that this
> > > > > > technique is a general solution that can actually apply to
> > > > > > both TP and
> > non-TP cases.
> > > > > >
> > > > > > > • 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?
> > > > > >
> > > > > > Between PEs of an PW.
> > > > > >
> > > > > > > • 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?
> > > > > >
> > > > > > Yes, both can apply to co-routed LSPs. But for "strict" mode,
> > > > > > if the egress PE must bind to the specified tunnel by the
> > > > > > ingress PE, otherwise, the binding will not success. The "co-routed"
> > > > > > mode gives the egress PE the use alternative tunnel.
> > > > > >
> > > > > > > • 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).
> > > > > >
> > > > > > The main purpose here is to give a reference to the term of "LSP"
> > > > > > and "tunnel", hence to eliminate the confusion of when use
> > > > > > these in the following sections. As for the NMS and SDN based
> > > > > > TE LSP/Tunnel, technically, it can apply to as well only if
> > > > > > the TE LSP/Tunnel has the LSP number, node ID etc. information.
> > > > > >
> > > > > > > • Section 2.1: “LDP Label Mapping message” missing reference.
> > > > > > > And why the Type field starts with 1 and 0?
> > > > > >
> > > > > > Good catch, will add a reference here.
> > > > > >
> > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > OK.
> > > > > > > • Intro: s/ a bidirectional circuits/ a bidirectional
> > > > > > > circuit
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > • 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.”
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > > • Intro: s/ there are a large number/ there is a large
> > > > > > > number
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > • Intro:s/to be
> > > > > > > carried/are carried
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > • Intro:s/there are a number/there is a number
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > • Intro: s/
> > > > > > > traffic belongs/traffic belonging
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > • 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.
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > > • Intro: s/ The similar problems/A similar problem
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > >• Intro: s/ won't/does not
> > > > > >
> > > > > > OK.
> > > > > > >•Intro: s/ In this document, it introduces/This document
> > > > > > >introduces BR Daniele
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > >