Subject: [PWE3] Fwd: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt

From: Ping Pan <[email-masked]>
Date: Wed, 14 Mar 2012 14:26:41 -0700

Hi,

Here is a draft that we have discussed in the past two IETF's and made a
number of updates.

As we have shown in the new revision, the problem we need to solve is very
simple: we have multiple big bi-directional LSP's (say, GMPLS LSP's)
between two edge nodes. The operators need to aggregate a large number of
Ethernet connections over them. Each Ethernet connection is represented by
two PW's: one on forwarding direction; another, reverse direction. For
consistent services, we need to map PW-pairs onto the *same* bi-directional
LSP.

We are proposing of introducing an optional LDP extension to achieve this.

Please take a look, provide the feedback and like to ask to be accepted as
a WG document during IETF.

(BTW, the name is perhaps misleading. This has nothing to do with MPLS-TP.)

Regards,

Ping

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sun, Mar 11, 2012 at 11:26 PM
Subject: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

       Title           : LDP extensions for Pseudowire Binding to LSP
Tunnels
       Author(s)       : Mach(Guoyi) Chen
                         Wei Cao
                         Attila Takacs
                         Ping Pan
       Filename        : draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt
       Pages           : 15
       Date            : 2012-03-11

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

  This document specifies an optional extension in LDP that enable the
  binding between PWs and the underlying LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Kamran Raza <[email-masked]>
Date: Wed, 14 Mar 2012 18:41:02 -0500

Hi,

I have following high level comments:

1. Need reformat of Binding TLV and its sub TLV
2. Suggest re-work procedures to withdraw such an advertised binding
3. Consider LDP Capabilities [RFC5561] to bind this new signaling with an
LDP capability 
4. Add section on ³PW Typed Wildcard FEC² intersections with this extension.

Now, the detailed comments as follow:

1.  Section 2.1: PSN Tunnel Binding TLV

A) This TLV is sent without any LDP capability negotiation. Should you not
bind this optional info with some LDP capabilities [ LDP Capabilities
[RFC5561] ].

B) Fig 3:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|1| PSN Tunnel Binding (TBA)  |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Flag             |            Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                       PSN Tunnel Sub-TLV                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  - U/F are both defined as 1/1. Did you mean to define them as 1/0 ?
  - Length is defined as 2 octets. Assuming ³PSN Tunnel Sub TLV² is an
optional field of this TLV, then length is (2 + sizeof(PSN Tunnel Sub-TLV).
  - Flags are defined as
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     MUST be Zero        |C|S|T|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  For consistency with other defintions, we should define them as

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|S|T|     MUST be Zero        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2) Section 2.1.1: PSN Tunnel Sub-TLV

 a) The format of both IPv4 and IPv6 sub TLV is same (with variable
lengths). I think there is no need to define two separate sub-TLVs and
define a single sub-TLV with Address Family encoded into it and the fields
encoded/interpreted accordingly.

 b) Since this is a sub-TLV, we do not need U/F bits.

 c) Generally for sub-TLVs, an octect suffices for sub-LTV type, and same is
true for sub-TLV length.

 d) If you are using an ³optional² field in the middle of a sub-TLV, we will
need some sort of flag to indicate if this field is present. I¹d rather
suggest removing the ³optional² part and make it mandatory but use some
reserved value (e.g. 0) to indicate not-populated.

 I suggest the following new format

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IP PSN Tun.   | Length        |        Address Family         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Source Global ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Node ID  (variable length)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Source Tunnel Number     | Source LSP Number             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination Global ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination Node ID  (variable length)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Destination Tunnel Number   | Destination LSP Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 where Address Family is IANA defined address family. It¹s value must be
either 1 (IPv4) or 2 (IPv6). ³Source Node ID² and ³Destination Node ID²
field are IP addresses encoded according to Address Family.

3) Section 3: Theory of Operation
 
For withdrawl of Tunnel bindings, there are couple of options:
1. Send another Label Mapping without Tunnel binding TLV (specified in this
doc) 
2. Use Label Withdraw
3. Use LDP Notification

Ref to #1, the receipt of a new Label mapping msg with no change in PW label
(but due to piggyback info change) sounds bit awkward, and hence I¹d suggest
to use new LDP Notification alongwith this TLV to withdraw previous
advertised bindings.
#2 can be used only when original PW FEC binding is also being withdrawn. If
an LSR just needs to withdraw the PSN Tunel Binding, it sends this TLV in a
Notification msg. This also means that we need to either add some kind of
³A² flag bit in the ³PSN Tunnel Binding² TLV to indicate advertise or
withdraw

4) Section 4: PSN Binding Operation for SS-PW

³.. it MUST reply a Label Release message with status code
   set to "Reject to use the suggested tunnel/LSPs" and the received PSN
   Tunnel Binding TLV.²

Couple of issues here:

1. If the intent is just to reject the ³PSN Tunnel Binding² but keep PW
label, then Label Release is a wrong msg to sent back.
2. Label Release messages do not contain an status TLV. I suggest send a
separate Notification msg just to inform reject of Tunnel binding.

5) Section 7.1.1 IANA Consideration: PSN Tunnel Sub-TLVs

Where does this new requested Sub-TLV name space resides ? I suggest it
should be created under ³PW Namespaces (pew3-parameters)².

Rgds.
-- Kamran

On 12-03-14 4:26 PM, "Ping Pan" <[email-masked]> wrote:

> simple: we have multiple big bi-directional LSP's (say, GMPLS LSP's) between
> two edge nodes. The operators need to aggregate a large number of Ethernet
> connections over them. Each Ethernet connection is represented by two PW's:
> one on forwarding direction; another, reverse direction. For consistent
> services, we need to map PW-pairs onto the *same* bi-directional LSP.
> 
> Please take a look, provide the feedback and like to ask to be accepted as a
> WG document during IETF.
> 
>         Title           : LDP extensions for Pseudowire Binding to LSP Tunnels
> Internet-Draft 
> <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
> directories: http://www.ietf.org/shadow.html
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

-- 
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.com

---

From: Ping Pan <[email-masked]>
Date: Wed, 14 Mar 2012 16:36:33 -0700

Cool! Will make the fix accordingly.

Best regards,

Ping

On Wed, Mar 14, 2012 at 4:41 PM, Kamran Raza <[email-masked]> wrote:

>    3. Consider LDP Capabilities [RFC5561] to bind this new signaling with
>    an LDP capability
>    4. Add section on “PW Typed Wildcard FEC” intersections with this
>    extension.
>
>
>   - Length is defined as 2 octets. Assuming “PSN Tunnel Sub TLV” is an
>  c) Generally for sub-TLVs, an octect suffices for sub-LTV type, and same
> is true for sub-TLV length.
>
>  d) If you are using an “optional” field in the middle of a sub-TLV, we
> will need some sort of flag to indicate if this field is present. I’d
> rather suggest removing the “optional” part and make it mandatory but use
> some reserved value (e.g. 0) to indicate not-populated.
>
>  where Address Family is IANA defined address family. It’s value must be
> either 1 (IPv4) or 2 (IPv6). “Source Node ID” and “Destination Node ID”
>    1. Send another Label Mapping without Tunnel binding TLV (specified in
>    this doc)
>    2. Use Label Withdraw
>    3. Use LDP Notification
>
>
> Ref to #1, the receipt of a new Label mapping msg with no change in PW
> label (but due to piggyback info change) sounds bit awkward, and hence I’d
> suggest to use new LDP Notification alongwith this TLV to withdraw previous
> advertised bindings.
> #2 can be used only when original PW FEC binding is also being withdrawn.
> If an LSR just needs to withdraw the PSN Tunel Binding, it sends this TLV
> in a Notification msg. This also means that we need to either add some kind
> of “A” flag bit in the “PSN Tunnel Binding” TLV to indicate advertise or
> withdraw
>
> “.. it MUST reply a Label Release message with status code
>    Tunnel Binding TLV.”
>    1. If the intent is just to reject the “PSN Tunnel Binding” but keep
>    PW label, then Label Release is a wrong msg to sent back.
>    2. Label Release messages do not contain an status TLV. I suggest send
>    a separate Notification msg just to inform reject of Tunnel binding.
>
>
> should be created under “PW Namespaces (pew3-parameters)”.
>
> Rgds.
> -- Kamran
>
> Internet-Draft <
> https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
> ------------------------------
> *http://www.cisco.com*