Re: [PWE3] Fwd: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt
Ping Pan <ping@pingpan.org> Wed, 14 March 2012 23:37 UTC
Return-Path: <ping@pingpan.org>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A36D11E808A for <pwe3@ietfa.amsl.com>; Wed, 14 Mar 2012 16:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.646
X-Spam-Level:
X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVWEy7zkEtJK for <pwe3@ietfa.amsl.com>; Wed, 14 Mar 2012 16:37:14 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with SMTP id 2D6D611E8075 for <pwe3@ietf.org>; Wed, 14 Mar 2012 16:37:14 -0700 (PDT)
Received: from mail-iy0-f178.google.com ([209.85.210.178]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT2ErqQLIhcbFC5te+hU00D5J8wzjPA/K@postini.com; Wed, 14 Mar 2012 16:37:14 PDT
Received: by mail-iy0-f178.google.com with SMTP id l21so3699681iak.23 for <pwe3@ietf.org>; Wed, 14 Mar 2012 16:37:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=aW0UbqbOhoFQHQFerMId0Y+4s2XbbuK6PRn7TpNc4PI=; b=ZG22enV9s9qnstz/9R4lt1j8pf+gkWemrWeLqRbLh4BVyqgAK1gx2JO9VrX5M1aGsi sIlvtqiSO/nCXhf3JK0CdTfDF1KLLdJ8bXH8HYZcJweH1+knt0Fzt6jCgMsY6fIVP4CR eBhAEyzsiDeqkZDoEkMVfH+MAt2M7wA+7Ykb/TRXG5gNIzJGq0S+7DJJd8Cg0FiK3y2j SsYFeDa9txeVLs3BVOLCtw1k75dteXBtURfPlhJy2TSvboV59Jclc+LtBCxEQAEPgbGs ro5aB13xkbhnhn5Qp0sD5zMhAAIJb9y06/gPrT3GWmfR1i5zCfu0KT2D/pMND25Yck4J ob2A==
Received: by 10.50.188.138 with SMTP id ga10mr7256153igc.51.1331768233235; Wed, 14 Mar 2012 16:37:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.134.72 with HTTP; Wed, 14 Mar 2012 16:36:33 -0700 (PDT)
In-Reply-To: <CB8696BF.27295%skraza@cisco.com>
References: <CAHEV9L0EXUC-suQEi7zFojCMtENR9bMX+esrU95nnxWyy-13Ew@mail.gmail.com> <CB8696BF.27295%skraza@cisco.com>
From: Ping Pan <ping@pingpan.org>
Date: Wed, 14 Mar 2012 16:36:33 -0700
Message-ID: <CAHEV9L2VA5jcS7738ss3PyX4B=U60S3zWjqoycRzr=ucfhmuzw@mail.gmail.com>
To: Kamran Raza <skraza@cisco.com>
Content-Type: multipart/alternative; boundary="14dae93407f977164c04bb3c74d2"
X-Gm-Message-State: ALoCoQlee5Q/SgFTvF+BActSQWQINV6gMrL7G+HhL51iz3cvR4qpkutGu7AFev+90sRzrWRpJhZy
Cc: pwe3@ietf.org
Subject: Re: [PWE3] Fwd: I-D Action: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2012 23:37:16 -0000
Cool! Will make the fix accordingly. Best regards, Ping On Wed, Mar 14, 2012 at 4:41 PM, Kamran Raza <skraza@cisco.com> 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" <ping@pingpan.org> 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: <internet-drafts@ietf.org> > 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: i-d-announce@ietf.org > > > > 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 > I-D-Announce@ietf.org > 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 > pwe3@ietf.org > 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* > > > >