Subject: [Pals] WGC comments on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-04.txt

From: Stewart Bryant <[email-masked]>
Date: Fri, 30 Oct 2015 21:52:49 +0000

Authors

This is mainly editorial, but there are a few items such as the
comparison text that will need to be clarified before this
goes for further review. Experience shows that if they are not
fixed now they will surface again further down the line.

Thanks

Stewart

==================

  LDP Extensions for Pseudowire Binding to LSP Tunnels
             draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-04.txt

Abstract

    Many transport services require that user traffic, in the forms of
SB> s/forms/form/
    Pseudowires (PW), to be delivered on a single co-routed bidirectional
SB> s/to be/be/
    LSP or two LSPs that share the same routes.  In addition, the user
    traffic may traverse through multiple transport networks.

    This document defines an optional extension to LDP that enables the
    binding between PWs and the underlying LSPs.

========

3.  Theory of Operation

    During PW setup, the PEs may select desired forwarding tunnels/LSPs,
SB> s/may select/may choose to select/
    and inform the remote T-PE/S-PEs about the desired reverse tunnels/
    LSPs.

============

    As defined in (Section 7.2.1, [RFC6073]), each PE may be generally
    categorized into active and passive roles:

d/generally/

Otherwise you need to qualify the term "generally"

==========
  4.  PSN Binding Operation for SS-PW

    On receive, if the S-bit is set, other than following the processing

SB> s/other/as well as/

     procedure defined in Section 5.3.3 of [RFC4447], the receiving PE
    (i.e.  PE2) needs to determine whether to accept the indicated
    tunnel/LSP in PSN Tunnel Sub-TLV.

    If the receiving PE (PE2) is also an active PE, and may have
    initiated the PSN binding requests to the other PE (PE1), if the
    received PSN tunnel/LSP is the same as it has been sent in the Label
    Mapping message by PE2, then the signaling has converged on a
    mutually agreed Tunnel/LSP.  The binding operation is completed.

    Otherwise, the receiving PE (PE2) MUST compare its own Node ID
    against the received Source Node ID.  If it is numerically lower, the

SB> You need to describe (hopefully by reference) the conversion of the
SB> address to an unsigned integer, otherwise the text above is ambiguous.
SB> I am sure that I have some text that I wrote with Dan Frost on this
SB> but I cannot remember which RFC it was in.

    PE (PE2) will reply a Label Mapping message to complete the PW setup
SB> s/will reply/will reply with/
    and confirm the binding request.  The PSN Tunnel Binding TLV in the
    message MUST contain the same Source and Destination IDs/Numbers as

Chen, et al.              Expires March 4, 2016                 [Page 9]

Internet-Draft     Explicit PW to LSP Tunnels Binding     September 2015

    in the received binding request, in the appropriate order.  On the
    other hand, if the receiving PE (PE2) has a Node ID that is
    numerically higher than the Source Node ID carried in the PSN Tunnel
    Binding TLV, it MUST reply a Label Release message with status code

s/reply/reply with/

    set to "Reject to use the suggested tunnel/LSPs" and the received PSN
    Tunnel Binding TLV, and the PW will not be established.

SB> The text of the reject message is not good English.
SB> I suggest : "Reject - unable to use the suggested tunnel/LSPs"

    To support co-routed binding, the receiving PE can select the
    appropriated PSN tunnel/LSP for the reverse direction of the PW, so
    long as the forwarding and reverse PSNs share the same route.

SB> What do you mean by route? I think that you need to be more precise.

     Initially, a PE (PE1) sends a Label Mapping message to the remote PE
    (PE2) with the PSN Tunnel Binding TLV, with C-bit set, S-bit cleared,
    and the appropriate Source and Destination IDs/Numbers.  In case of
    unidirectional LSPs, the PSN Tunnel Binding TLV may only contain the
    Source IDs/Numbers, the Destination IDs/Numbers are set to zero and
    left for PE2 to fill when responding the Label Mapping message.

SB> s/fill/fill in/ or perhaps /complete/

  On receive, since PE2 is also an active PE, and may have initiated
    the PSN binding requests to the other PE (PE1), if the received PSN
    tunnel/LSP has the same route as the one that has been sent in the
    Label Mapping message to PE1, then the signaling has converged.  The
    binding operation is completed.

    Otherwise, it needs to compare its own Node ID against the received
SB> who is "it"?

    Source Node ID.  If it is numerically lower,

SB> Again the definition of "numerically lower" needs to be provided.

    PE2 needs to find/
    establish a tunnel/LSP that meets the co-routed constraint, and reply

SB> s/reply/reply with/

    a Label Mapping message with a PSN Binding TLV that contains the
    Source and Destination IDs/Numbers in the appropriate order.
SB> What does "appropriate order" mean?

    On the
    other hand, if the receiving PE (PE2) has a Node ID that is
    numerically higher than the Source Node ID carried in the PSN Tunnel
    Binding TLV, it MUST reply a Label Release message with status code

SB> s/reply/reply with/

    set to "Reject to use the suggested tunnel/LSPs" and the received PSN
    Tunnel Binding TLV.

    In both strict and co-routed bindings, if T-bit is set, the LSP
    Number field MUST be set to zero.  Otherwise, the field MUST contain
    the actual LSP number for the related PSN LSP.

    After a PW established, the operators may choose to move the PWs from
    the current tunnel/LSPs to other tunnel/LSPs.  Or, the underlying PSN
    tunnel is broken due to network failure.  In this scenario, a new
    Label Mapping message MUST be sent to update the changes.  Note that
    when T-bit is set, the working LSP broken will not trigger to update
    the changes if there are protection LSPs.

SB> I think that should be written as:

    After a PW is established, the operators may choose to move the PWs from
    the current tunnel/LSPs to other tunnel/LSPs. Also  the underlying PSN
    tunnel may  break due to a network failure.  When either of  these scenarios occur, a new
    Label Mapping message MUST be sent to notify the remote PW of the changes.  Note that
    when the T-bit is set, the working LSP broken will not provide this update
    if there are protection LSPs in place.

    The message may carry a new PSN Tunnel Binding TLV, which contains
    the new Source and Destination Numbers/IDs.  The procedure for handling of the new

Chen, et al.              Expires March 4, 2016                [Page 10]

Internet-Draft     Explicit PW to LSP Tunnels Binding     September 2015

    message is identical to the procedure already described in this
    section.

SB> NOTE I changed the previous sentence - but for got to keep the original text.

    However, if the new Label Binding message does not contain the PSN
    Tunnel Binding TLV, it declares the removal of any co-routed/strict
    constraints.  The PEs may not map the PW to the underlying PSN on
    purpose, the current independent PW to PSN binding will be used.

SB> I do not understand the text from "However" to "used"

    Further, as an implementation option, the PEs should not remove the

SB> I think that should be "PEs may choose not to"

    traffic from an operational PW, until the completion of the
    underlying PSN tunnel/LSP changes.

================

    If the Label Mapping message is for forward direction, and S-PE1
    accepts the requested tunnel/LSPs from T-PE1, S-PE1 MUST save the
    tunnel/LSP information for reverse-direction processing later on.  If
    the PSN binding request is not acceptable, S-PE1 MUST reply a Label
s/reply/reply with/

    Release Message to the upstream PE (T-PE1) with Status Code set to
    "Reject to use the suggested tunnel/LSPs".

SB> Please see earlier comment

  Chen, et al.              Expires March 4, 2016                [Page 11]

Internet-Draft     Explicit PW to LSP Tunnels Binding     September 2015

    Otherwise, S-PE1 relays the Label Mapping message to the next S-PE
    (that is, S-PE2), with the PSN Tunnel sub-TLV carrying the
    information of the new PSN tunnel/LSPs selected by S-PE1.  S-PE2 and
    subsequent S-PEs will repeat the same operation until the Label
    Mapping message reaches to the remote T-PE (that is, T-PE2).

    If T-PE2 agrees with the requested tunnel/LSPs, it will reply a Label

SB> what does "agrees with" mean?

     Mapping message to initiate to the binding process on the reverse
    direction.  The Label Mapping message contains the received PSN
    Tunnel Binding TLV for confirmation purposes.

    When its upstream S-PE (S-PE2) receives the Label Mapping message,
    the S-PE relays the Label Mapping message to its upstream adjacent
    S-PE (S-PE1), with the previously saved PSN tunnel/LSP information in
    the PSN Tunnel sub-TLV.  The same procedure will be applied on
    subsequent S-PEs, until the message reaches to T-PE1 to complete the
    PSN binding setup.

    During the binding process, if any PE does not agree to the requested
    tunnel/LSPs, it can send a Label Release Message to its upstream
    adjacent PE with Status Code set to "Reject to use the suggested
    tunnel/LSPs".

    For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit,
    reset the S-bit and indicates the suggested tunnel/LSP in PSN Tunnel
    sub-TLV to the next-hop S-PE (S-PE1).

    During the MS-PW setup, the PEs have the option to ignore the
SB> s/to/of/
    suggested tunnel/LSP, and select another tunnel/LSP for the segment

SB> s/and/and to/
    PW between itself and its upstream PE on reverse direction only if
SB> s/on/in/
SB> below s/forwarding/forward/

    the tunnel/LSP is co-routed with the forwarding one.  Otherwise, the
    procedure is the same as the strict binding.

    The tunnel/LSPs may change after a MS-PW being established.  When a
    tunnel/LSP has changed, the PE that detects the change SHOULD select
    an alternative tunnel/LSP for temporary use while negotiating with
    other PEs following the procedure described in this section.

6.  Security Considerations

    The ability to control which LSP to carry traffic from a PW can be a

SB> s/which LSP/which LSP is used/

<end>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 31 Oct 2015 10:07:42 +0900

All,

Just in case you’re confused because you didn’t yet see a WG LC for this
draft, Stewart jumped the gun a little bit with his review (but that’s
OK!). The draft will be going into WG LC following the IETF meeting.

Cheers,
Andy