Re: [mpls] [CCAMP] Request comments on draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00
Lou Berger <lberger@labn.net> Tue, 25 October 2011 20:41 UTC
Return-Path: <lberger@labn.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC99221F8726 for <mpls@ietfa.amsl.com>; Tue, 25 Oct 2011 13:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.727
X-Spam-Level:
X-Spam-Status: No, score=-98.727 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 x8N9K+FgrtPq for <mpls@ietfa.amsl.com>; Tue, 25 Oct 2011 13:41:26 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id B5E2E21F8677 for <mpls@ietf.org>; Tue, 25 Oct 2011 13:41:25 -0700 (PDT)
Received: (qmail 1126 invoked by uid 0); 25 Oct 2011 20:41:25 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 25 Oct 2011 20:41:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=M1Zn7jISRZrMW+UQm5BsxbSw8ohs//0cGg7Awab4HcM=; b=lyECNwKrhsYMcDYAV5hj3zKP1iHlecgQgPw2mmapAfNsaItP8a7koWqXB6wn3j2p1A574Glq2gUzTctjnaLwgdPe6dW0DeQsyCKbd1a5pvs0V7WGTEJKAU8loLjz8tWf;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1RInoK-0002sq-O1; Tue, 25 Oct 2011 14:41:25 -0600
Message-ID: <4EA71EF5.5060908@labn.net>
Date: Tue, 25 Oct 2011 16:41:25 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: zhang.fei3@zte.com.cn
References: <OF671D8908.85D8155E-ON48257930.0000A497-48257930.0005E940@zte.com.cn>
In-Reply-To: <OF671D8908.85D8155E-ON48257930.0000A497-48257930.0005E940@zte.com.cn>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "mpls@ietf.org" <mpls@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, Jaihari Kalijanakiraman <jaiharik@ipinfusion.com>
Subject: Re: [mpls] [CCAMP] Request comments on draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 20:41:26 -0000
Fei, On 10/20/2011 9:04 PM, zhang.fei3@zte.com.cn wrote: > > Hi Jaihari > > As to the associated bidirectional LSP, the binding is based on the > Extended Association object, which is defined in the draft > http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-00. > > A new Association Type is introduced in another draft*, > *http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02. > > Based on the association type "associated bidirectional LSP", two > reverse unidirectional LSPs can form the assoicated bidirectional LSP. > > However, according to the usage of this object, see the description of > the section 2.3.1 in the draft > http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-00, "no > associations are made across Path and Resv state". > > That indicates that the Association object or Extended Association > object can not be used to carry back the local assigned tunnel number in > the context of corouted bidirectional LSP. sure, it *could*, but agree that this isn't the way to go. (Although such usage might be better than allocating a new top-level object for this purpose!) > > That is the history why a new Connection object is introduced here for > the co-routed bidirectional LSP. If all this draft is really about is providing the RFC6370 Z9 (egress) Tunnel_Num, why not just define a new LSP Attributes TLV and carry it there (in Resv messages of co-routed bidirectional LSPs)? New top-level RSVP objects are a *bid* deal as the number space is so small. Lou > > Be glad to share my opinion on this subject. > > Best regards > > Fei > > > > *Jaihari Kalijanakiraman <jaiharik@ipinfusion.com>* > > 2011-10-20 23:40 > > > 收件人 > zhang.fei3@zte.com.cn > 抄送 > "ccamp@ietf.org" <ccamp@ietf.org>, "mpls@ietf.org" <mpls@ietf.org> > 主题 > Re: [mpls] Request comments on > draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 > > > > > > > > > Hi Zhang, > > Thanks for the clarification. > > Sorry I misunderstood. > > I have a question here.. > > You mentioned "As to the associated bidirectional LSP, there are two > independent signaling procedures for the forward and backward > directional LSPs".. > > So for associated bidirectional LSPs the two endpoints should have an > association or binding between the forward and reverse tunnels. > > So if the forward and reverse directional LSPs are independently > signaled, how the binding or association will be established between them.. > > When I read the draft, initially thought that this connection object > will be used to establish that binding or association... > > Is there a way to establish this binding already.. Please clarify.. > > Cant we use this object to establish that binding?? > > Thanks again, for your kind reply... > > > /Thanks & Regards,/ > /Jai Hari M.K./ > /IP Infusion/ > > 2011/10/20 <_zhang.fei3@zte.com.cn_ <mailto:zhang.fei3@zte.com.cn>> > > Hi Jaihari > > Thanks for your comments. :-) > > This draft is about how to carry the local assigned tunnel number of > co-routed bidirectional LSP, sorry I do not describe it clearly in the > mail. > > According to the description in section 5.2.1 of the RFC6370, the LSP > number keeps the same under the context of A1 and Z9's tunnel numbers: > > A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num > > So only the tunnel number assigned by the destination node is missing. > > As to the associated bidirectional LSP, there are two independent > signaling procedures for the forward and backward directional LSPs, and > the A1 and Z9 > know each other the assigned tunnel number and LSP number. > > Furthermore, the Global_ID is also needed if the LSP is across different > ASs, which may be added in next version. > > Your comments are welcome. > > Best regards > > Fei > > *Jaihari Kalijanakiraman <**_jaiharik@ipinfusion.com_* > <mailto:jaiharik@ipinfusion.com>*>* > > 2011-10-20 15:22 > > > 收件人 > _zhang.fei3@zte.com.cn_ <mailto:zhang.fei3@zte.com.cn> > 抄送 > "_mpls@ietf.org_ <mailto:mpls@ietf.org>" <_mpls@ietf.org_ > <mailto:mpls@ietf.org>> > 主题 > Re: [mpls] Request comments on > draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 > > > > > > > > > > > > > On Thu, Oct 20, 2011 at 12:50 PM, Jaihari Kalijanakiraman > <_jaiharik@ipinfusion.com_ <mailto:jaiharik@ipinfusion.com>> wrote: > Hi Zhang, > > I have a question. > > The connection object in the draft has only destination tunnel number. > > But as per TP Identifiers RFC 6370, > * > > > 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers* > > A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: > Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num} > > > So I think the connection object should also include the destination LSP > number also. > > Please comment.. > > / > Thanks & Regards,/ / > Jai Hari M.K. > IP Infusion/ > > > Date: Mon, 17 Oct 2011 19:08:51 +0800 > From: _zhang.fei3@zte.com.cn_ <mailto:zhang.fei3@zte.com.cn> > To: "_ccamp@ietf.org_ <mailto:ccamp@ietf.org>" <_ccamp@ietf.org_ > <mailto:ccamp@ietf.org>>, "_mpls@ietf.org_ <mailto:mpls@ietf.org>" > <_mpls@ietf.org_ <mailto:mpls@ietf.org>> > Subject: [mpls] Request comments on > draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 > Message-ID: > > <_OF3E7FD488.405BF0C5-ON4825792C.00351CBE-4825792C.003D3BA7@zte.com.cn_ > <mailto:OF3E7FD488.405BF0C5-ON4825792C.00351CBE-4825792C.003D3BA7@zte.com.cn>> > Content-Type: text/plain; charset="us-ascii" > > Hi all > > We've submitted a draft for the group's consideration, below is the link:_ > __http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00_. > > This draft is about the supporting of MPLS-TP Maintenance Identifiers. As > described in _http://tools.ietf.org/html/rfc6370_, at each end point, a > tunnel is uniquely identified by the end point's Node_ID and a locally > assigned tunnel number, which allow a compact form for the MEP_ID, and > extensions will be required to GMPLS to support these identifiers. > Furthermore, _http://tools.ietf.org/html/rfc6373_ addressed this issue in > section 4.4.8. > > Obviously, this issue can be solved by defining a new object, such as > Connection Object as described in this draft, or a new sub-TLV call MEP_ID > can be carried back to the ingress LSR in Resv message when the "CV" flag > of the OAM Function Flags Sub-TLV is set, which may be considered in the > subsequent version of the draft_ > __http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06_. > > We hope you'll find the time to look through the draft and comment on the > list, help judge which way is more suitable before the WG meeting in > Taipei, and hope that we'll be able to have a fruitful and lively > discussion there. > > > Best, > > Fei > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp
- [mpls] Request comments on draft-zhang-ccamp-mpls… zhang.fei3
- Re: [mpls] Request comments on draft-zhang-ccamp-… Jaihari Kalijanakiraman
- Re: [mpls] Request comments on draft-zhang-ccamp-… zhang.fei3
- Re: [mpls] Request comments on draft-zhang-ccamp-… Jaihari Kalijanakiraman
- Re: [mpls] Request comments on draft-zhang-ccamp-… zhang.fei3
- Re: [mpls] [CCAMP] Request comments on draft-zhan… Lou Berger
- Re: [mpls] [CCAMP] Request comments on draft-zhan… zhang.fei3