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

From: [email-masked]
Date: Thu, 20 Oct 2011 21:29:14 +0800

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 <[email-masked]> 
2011-10-20 15:22

收件人
[email-masked]
抄送
"[email-masked]" <[email-masked]>
主题
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 <
[email-masked]> 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: [email-masked]
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [mpls] Request comments on
       draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00
Message-ID:
       <
[email-masked]>
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

---

From: [email-masked]
Date: Fri, 21 Oct 2011 09:04:35 +0800

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.

That is the history why a new Connection object is introduced here for the 
co-routed bidirectional LSP.

Be glad to share my opinion on this subject.

Best regards

Fei

2011-10-20 23:40

收件人
[email-masked]
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
主题
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 <[email-masked]>

Hi Jaihari 

Best regards 

Fei 

收件人
[email-masked] 
抄送

I have a question. 

Please comment.. 

Thanks & Regards, 
Jai Hari M.K.
IP Infusion 

Hi all

Best,

Fei

---

From: Jaihari Kalijanakiraman <[email-masked]>
Date: Thu, 20 Oct 2011 21:10:17 +0530

Hi Zhang,

Sorry I misunderstood.

I have a question here..

When I read the draft, initially thought that this connection object will be
used to establish that binding or association...

*Thanks & Regards,*
*Jai Hari M.K.*
*IP Infusion*

> co-routed bidirectional LSP, sorry I do not describe it clearly in the mail.
>
> As to the associated bidirectional LSP, there are two independent signaling
> procedures for the forward and backward directional LSPs, and the A1 and Z9
>  *Jaihari Kalijanakiraman <[email-masked]>*
>
> 2011-10-20 15:22
>   收件人
> [email-masked]
> 抄送
> On Thu, Oct 20, 2011 at 12:50 PM, Jaihari Kalijanakiraman <*
> [email-masked]* <[email-masked]>> wrote:
> Hi Zhang,
>
> I have a question.
>
> *
> 5.2.2.  MPLS-TP Associated Bidirectional LSP Identifiers*
>
> *Thanks & Regards,*
> *Jai Hari M.K.
> IP Infusion*
> From: [email-masked]* <[email-masked]>
> To: "[email-masked]* <[email-masked]>" <[email-masked]* <[email-masked]>>,
> "[email-masked]* <[email-masked]>" <[email-masked]* <[email-masked]>>
>        <*
> [email-masked]*<[email-masked]>
> >
> 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>
> .
>
> described in *http://tools.ietf.org/html/rfc6370*<http://tools.ietf.org/html/rfc6370>,
> at each end point, a
> Furthermore, *http://tools.ietf.org/html/rfc6373*<http://tools.ietf.org/html/rfc6373>addressed this issue in
> section 4.4.8.
>
> subsequent version of the draft*
> **http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06*<http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06>
> .
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 25 Oct 2011 16:41:25 -0400

Fei,

On 10/20/2011 9:04 PM, [email-masked] wrote:
> 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
> independent signaling procedures for the forward and backward
> directional LSPs"..
> 
> 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...
> 
> /Thanks & Regards,/
> /Jai Hari M.K./
> /IP Infusion/
> 2011/10/20 <[email-masked] <mailto:[email-masked]>>
> 
> Hi Jaihari
> 
> *Jaihari Kalijanakiraman <[email-masked]*
> <mailto:[email-masked]>*>*
> 
> 2011-10-20 15:22
> 
> 	
> 收件人
> 	[email-masked] <mailto:[email-masked]>
> 抄送
> 	"[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> 主题
> On Thu, Oct 20, 2011 at 12:50 PM, Jaihari Kalijanakiraman
> <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Zhang,
> 
> I have a question.
> 
> /
> Thanks & Regards,/ /
> IP Infusion/
> From: [email-masked] <mailto:[email-masked]>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> <[email-masked]
> <mailto:[email-masked]>>
> 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_.
> 
> described in _http://tools.ietf.org/html/rfc6370_, at each end point, a
> Furthermore, _http://tools.ietf.org/html/rfc6373_ addressed this issue in
> section 4.4.8.
> 
> subsequent version of the draft_
> __http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06_.
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: [email-masked]
Date: Sat, 29 Oct 2011 11:03:53 +0800

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 <[email-masked]> 
2011-10-26 04:41

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

Fei,

Lou
> *Jaihari Kalijanakiraman <[email-masked]>*
mailto:[email-masked]