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

[Ping Pan <[e-mail]>]

Cool! Will make the fix accordingly.

Best regards,

Ping

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

>  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" <[e-mail]> wrote:
>
> 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:  <[e-mail]>
> 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: [e-mail]
>
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft <
> https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
>  directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> ------------------------------
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> 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: [phone]
> *http://www.cisco.com*
>
>
>
>