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

From: Mach Chen <[email-masked]>
Date: Fri, 13 May 2016 07:24:58 +0000

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 25 May 2016 08:08:29 +0000

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

BR
Daniele

> -----Original Message-----
> From: Mach Chen [mailto:[email-masked]]
> Sent: venerdì 13 maggio 2016 09:25
> To: Daniele Ceccarelli <[email-masked]>; <[email-masked]>
> ([email-masked]) <[email-masked]>
> Cc: [email-masked]; draft-ietf-pals-mpls-tp-pw-over-bidir-
> [email-masked]; [email-masked]
> Subject: RE: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
> 
> Hi Daniele,
> 
> 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
> > 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
> > 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.
> > • 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.
> 
> > • 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.
> 
> 
> > •  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?
> 
> > “Pseudowire (PW) Emulation Edge-to-Edge (PWE3)”. I suggest removing
> > (PW), it’s already included into PWE3.
> 
> OK.
> > 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.
> 
> > (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.
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 25 May 2016 09:01:48 +0000

Hi Daniele,

> From: Daniele Ceccarelli [mailto:[email-masked]]
> Sent: Wednesday, May 25, 2016 4:08 PM
> To: Mach Chen; <[email-masked]> ([email-masked])
> Cc: [email-masked]; [email-masked];
> [email-masked]

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
> > Subject: RE: RtgDir review:
> > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
> >
> > Hi Daniele,
> >
> > > 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.
> > > also the operation section are pretty straighforward. What needs to
> > > be improved is the introduction part, which should be reviewed by a
> > 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:
> > 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
> > 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.
> >
> > No, this sentence just brings the requirements of explicit PW to PSN
> > tunnel binding, whatever it is automatic signaling or manual configuration.
> >
> > > • 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.
> >
> >
> > 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: Strict binding vs Co-routed binding: from the
> > > description it seems that the first one is strict and the second one is
> “loose”
> > 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.
> >
> > > 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
> > 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?
> >
> > > rephrasing: “Bidirectional LSPs share fate and simplify the routing
> > > of a protection path also consisting of bidirectional   LSPs because
> > > (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.
> >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 25 May 2016 09:20:46 +0000

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

> Sent: mercoledì 25 maggio 2016 11:02
> > Cc: [email-masked];
> > [email-masked];
> > [email-masked]
> 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.
> 
> > > 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
> > > > Subject: RtgDir review:
> > > > • 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.
> > >
> > > > 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:
> > >
> > > 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?
> > >
> > > 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?
> > >
> > > > •  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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > > “Pseudowire (PW) Emulation Edge-to-Edge (PWE3)”. I suggest
> > > > removing (PW), it’s already included into PWE3.
> > >
> > > OK.
> > > > 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.
> > >

---

From: Mach Chen <[email-masked]>
Date: Wed, 25 May 2016 09:46:59 +0000

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 

> Sent: Wednesday, May 25, 2016 5:21 PM
> 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").
> 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.
> 
> > 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.
> >
> > > > > 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,
> > > > > 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.
> > > > 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:
> > > > between PWs and the underlying TE tunnels. The extension applies
> > > > to both SS-PW and
> > > MS-PW."
> > > >
> > > > 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.
> > > >
> > > > 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.
> > > >
> > > > > • 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.
> > > >
> > > >
> > > > 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.
> > > >
> > > > > defined in Section 2.1 of [RFC3209],  which is uniquely
> > > > > identified by the SESSION object together with  SENDER_TEMPLATE
> > > > > (or
> > > > > address.” Why is the draft considering only signaled LSPs?
> > > > > Doesn’t it apply also to centrally
> > > > 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?
> > > >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 25 May 2016 10:03:04 +0000

That's perfect!

BR
Daniele

> Sent: mercoledì 25 maggio 2016 11:47
> 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
> 
> > 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.
> >
> > > 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
> > > > > 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
> > > > > > Cc: [email-masked]';
> > > > > > 'draft-ietf-pals-mpls-tp-pw-over-bidir-
> > > [email-masked]'
> > > > > > Subject: RtgDir review:
> > > > > > this draft. The Routing Directorate seeks to review all
> > > > > > routing or routing-related drafts as they pass through IETF
> > > > > > last call and IESG review,
> > > > > > 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.
> > > > > > • 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.
> > > > >
> > > > > > • 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."
> > > > >
> > > > > > common and important in many deployment scenarios”. I guess
> > > > > > you mean an automatic binding done via a signaling protocol?
> > > > >
> > > > > > generic with a network between the PEs? With directly
> > > > > > connected PEs it doesn’t seem a realistic and generic enough
> example.
> > > > >
> > > > >
> > > > > > •  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.
> > > > >
> > > > > 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.
> > > > >
> > > > > 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.
> > > > >
> > > > > > 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?
> > > > > > (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.
> > > > >

---

From: Mach Chen <[email-masked]>
Date: Thu, 26 May 2016 06:21:03 +0000

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

> Sent: Wednesday, May 25, 2016 6:03 PM
> > 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
> >
> > > 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.
> > >
> > > > > [mailto:[email-masked]]
> > > > > > > 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
> > > > > > > along with any other IETF Last Call comments that you
> > > > > > > receive, and strive to resolve them through discussion or by
> > > > > > > updating the
> > draft.
> > > > > > > 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:
> > > > > > > straighforward. What needs to be improved is the
> > > > > > > introduction part, which should be reviewed by a native English
> speaker.
> > > > > > "Many transport services require that user traffic, in the
> > > > > > form of Pseudowires (PW), be delivered on a single co-routed
> > > > > > 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.
> > > > > > make Abstract and Introduction have the consistent usage.
> > > > > > Please see above the new text for Abstract.
> > > > > >
> > > > > > No, this sentence just brings the requirements of explicit PW
> > > > > > to PSN tunnel binding, whatever it is automatic signaling or
> > > > > > manual
> > > configuration.
> > > > > >
> > > > > > > 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.
> > > > > > 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"
> > > > > > 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.
> > > > > >
> > > > > > > routing of a protection path also consisting of
> > > > > > > bidirectional LSPs because working and protection paths have to be
> disjoint.”
> > > > > >
> > > > > > OK.
> > > > > >