Re: [CCAMP] [mpls] Request comments on draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00

[[e-mail]]

Lou

Thanks for pointing out this issue, we will revise it and add the global 
node id information in next version

Best regards

Fei 



Lou Berger <[e-mail]> 
2011-10-26 04:41

收件人
[e-mail]
抄送
Jaihari Kalijanakiraman <[e-mail]>, "[e-mail]" 
<[e-mail]>, "[e-mail]" <[e-mail]>
主题
Re: [CCAMP] [mpls] Request comments on 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00






Fei,
 

On 10/20/2011 9:04 PM, [e-mail] 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 <[e-mail]>*
> 
> 2011-10-20 23:40
> 
> 
> 收件人
>                [e-mail]
> 抄送
>                "[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]>
> 主题
>                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 <[e-mail]_ <mailto:[e-mail]>>
> 
> 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 <**[e-mail]_*
> <mailto:[e-mail]>*>*
> 
> 2011-10-20 15:22
> 
> 
> 收件人
>                [e-mail]_ <mailto:[e-mail]>
> 抄送
>                "[e-mail]_ <mailto:[e-mail]>" <[e-mail]_
> <mailto:[e-mail]>>
> 主题
>                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
> <[e-mail]_ <mailto:[e-mail]>> 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: [e-mail]_ <mailto:[e-mail]>
> To: "[e-mail]_ <mailto:[e-mail]>" <[e-mail]_
> <mailto:[e-mail]>>, "[e-mail]_ <mailto:[e-mail]>"
> <[e-mail]_ <mailto:[e-mail]>>
> Subject: [mpls] Request comments on
>       draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00
> Message-ID:
> 
> <[e-mail]_
> <
mailto:[e-mail]
>>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp