Subject: [CCAMP] poll on making draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

From: Lou Berger <[email-masked]>
Date: Fri, 01 Apr 2011 11:24:27 +0200

All,

This is to start a two week poll on making
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a ccamp working
group document. Please send mail to the list indicating "yes/support"
or "no/do not support".  If indicating no, please state your technical
reservations with the document.

The poll ends Friday April 15.

Much thanks,
Lou (and Deborah)

---

From: Dieter Beller <[email-masked]>
Date: Fri, 1 Apr 2011 11:36:13 +0200

support

Dieter

On 01.04.2011 11:24, Lou Berger wrote:

All,

Much thanks,
Lou (and Deborah)

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

--

DIETER
BELLER

ALCATEL-LUCENT

PROJECT

MANAGER ASON/GMPLS CONTROL PLANE

NETWORKS GROUP, OPTICS DIVISION

TERRESTRIAL OPTICS UNIT

Lorenzstrasse 10

70435 Stuttgart, Germany

T:

+49 711 821 43125

M: +49 175 7266874

[email-masked]

Alcatel-Lucent

Deutschland AG

Domicile of the Company: Stuttgart · Local Court
Stuttgart HRB 4026

Chairman of the Supervisory Board: Michael Oppenhoff

Board of Management: Alf Henryk Wulf (Chairman) ·
Hans-Jörg Daub ·

Dr. Rainer Fechner · Peter
Kury

This e-mail and its
attachments, if any, may contain confidential
information.

If you have received this e-mail in error, please
notify us and delete or destroy the

e-mail and its attachments, if any, immediately. If
you have received this e-mail in

error, you must not forward or make use of the
e-mail and its attachments, if any.

---

From: Dieter Beller <[email-masked]>
Date: Fri, 1 Apr 2011 11:44:56 +0200

oops - I responded accidentally to this
poll - please disregard!

Dieter

On 01.04.2011 11:36, Dieter Beller wrote:

support

Dieter

All,

Much thanks,
Lou (and Deborah)

--

DIETER

BELLER

ALCATEL-LUCENT

PROJECT

TERRESTRIAL OPTICS UNIT

Lorenzstrasse 10

70435 Stuttgart, Germany

T:

+49 711 821 43125

M: +49 175 7266874

Alcatel-Lucent Deutschland
AG

Chairman of the Supervisory Board: Michael
Oppenhoff

This e-mail and its

e-mail and its attachments, if any, immediately.
If you have received this e-mail in

--

DIETER
BELLER

ALCATEL-LUCENT

PROJECT

TERRESTRIAL OPTICS UNIT

Lorenzstrasse 10

70435 Stuttgart, Germany

T:

+49 711 821 43125

M: +49 175 7266874

Alcatel-Lucent

Deutschland AG

This e-mail and its

---

From: [email-masked]
Date: Fri, 1 Apr 2011 17:33:55 +0800

Yes/Support

Xihua Fu

Lou Berger <[email-masked]> 
发件人:  [email-masked]
2011-04-01 下午 05:24

收件人
[email-masked]
抄送

主题
[CCAMP] poll on making  draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a 
WG document

All,

Much thanks,
Lou (and Deborah)

---

From: [email-masked]
Date: Sat, 2 Apr 2011 02:49:03 +0800

yes/support

as a co-author

Fei

2011-04-01 17:24

收件人
[email-masked]
抄送

主题

All,

Much thanks,
Lou (and Deborah)

---

From: [email-masked]
Date: Fri, 1 Apr 2011 17:41:20 +0800

yes/support

收件人
[email-masked]
抄送

主题

All,

Much thanks,
Lou (and Deborah)

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: [email-masked]
Date: Fri, 1 Apr 2011 17:28:19 +0800

Yes/support

Qilei Wang

收件人
[email-masked]
抄送

主题

All,

Much thanks,
Lou (and Deborah)

---

From: [email-masked]
Date: Wed, 6 Apr 2011 09:01:11 +0800

YES/SUPPORT

收件人
[email-masked]
抄送

主题

All,

Much thanks,
Lou (and Deborah)

---

From: [email-masked]
Date: Thu, 7 Apr 2011 14:28:42 +0800

Yes/Support

收件人
[email-masked]
抄送

主题

All,

Much thanks,
Lou (and Deborah)

---

From: "xuyunbin" <[email-masked]>
Date: Thu, 7 Apr 2011 16:41:38 +0800

Yes/support.

Yunbin Xu.

2011-04-07 

xuyunbin 

发件人： Lou Berger 
发送时间： 2011-04-01  17:17:38 
收件人： ccamp 
抄送： 
主题： [CCAMP] poll onmaking draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document 
 
All,

---

From: "Daniel King" <[email-masked]>
Date: Thu, 7 Apr 2011 21:03:48 +0100

Yes, support. 

Br, Dan. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lou Berger
Sent: 01 April 2011 10:24
To: [email-masked]
Subject: [CCAMP] poll on making
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

All,

This is to start a two week poll on making
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a ccamp working group
document. Please send mail to the list indicating "yes/support"
or "no/do not support".  If indicating no, please state your technical
reservations with the document.

Much thanks,
Lou (and Deborah)

---

From: [email-masked]
Date: Mon, 11 Apr 2011 09:14:29 +0800

+1

Best Regards，
Xuehui

"Daniel King" <[email-masked]> 
发件人:  [email-masked]
2011-04-08 04:03

收件人
<[email-masked]>
抄送

主题
Re: [CCAMP] poll on     making 
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG   document

Yes, support. 

Br, Dan. 

-----Original Message-----

All,

Much thanks,
Lou (and Deborah)

---

From: Attila Takacs <[email-masked]>
Date: Tue, 12 Apr 2011 22:27:33 +0200

Hi authors,

You talk about two provisioning models: "single" and "double" sided modes. 

Double sided is clear, it uses independent signaling for the two LSPs. 

Single sided, if I understood correctly, somehow binds the two LSP signaling phases together. I have some doubts that this model is needed. It seems to complicate operation and it also begs the question why not use bidirectional LSPs instead. 

I think two independently signaled LSPs with the addition of the proposed Association object would do the job addressing the associated bidirectional LSP requirements, so that transit nodes are also aware of the binding.

Best regards,
Attila 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Friday, April 01, 2011 11:24 AM
To: [email-masked]
Subject: [CCAMP] poll on making draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

All,

This is to start a two week poll on making
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a ccamp working group document. Please send mail to the list indicating "yes/support"
or "no/do not support".  If indicating no, please state your technical reservations with the document.

Much thanks,
Lou (and Deborah)

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 13 Apr 2011 10:02:09 +0800

Hi all,

This draft just introduces a new Association Type, so do we really need one more separate draft for this simple thing?

In Prague meeting, we know that there was a consensus on [draft-ietf-ccamp-assoc-info-01.txt] to separate it into two drafts: 
(1)Usage of The RSVP Association Object
(2)RSVP Association Object Extensions

So, I think it is appropriate to address MPLS-TP bidirectional LSP association in the draft (2), because we know that one of the key drivers for Association Object Extensions in [draft-ietf-ccamp-assoc-info-01] is for MPLS-TP.

In this way, we can just keep two drafts for the association stuff (besides RFC4872 and RFC4873), one is "informational usage for GMPLS recovery", another one is for "Standards track extensions for non-GMPLS recovery usage and Extended association". Another benefit  of this approach is very easy for the readers to track and review the RFCs.

Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

---

From: [email-masked]
Date: Wed, 13 Apr 2011 10:01:58 +0800

Hi Attila

Be appreciated for your comments.

See in line

Best regards

Fei

Attila Takacs <[email-masked]> 
发件人:  [email-masked]
2011-04-13 04:27

收件人
"[email-masked]" <[email-masked]>
抄送

主题

Hi authors,

Single sided, if I understood correctly, somehow binds the two LSP 
signaling phases together. I have some doubts that this model is needed. 
It seems to complicate operation and it also begs the question why not use 
bidirectional LSPs instead. 

[Fei] Just my two cents. Compared to co-routed bidirectional LSPs, the 
operation is a little complicated; but contrast to double sided 
provisioning, the operation is more or less   easier (the binding does not 
depend on the refreshed signaling).

As to the question that why not use co-routed bidrectional LSPs. Two 
consideration are listed below:

1) The bandwidth can not be satisfied in the reverse direction if co-route 
is required
2) The LSPs from west to east (LSP1) and east to west (LSP2) are already 
existing, they can be bound together also. 

I think two independently signaled LSPs with the addition of the proposed 
Association object would do the job addressing the associated 
bidirectional LSP requirements, so that transit nodes are also aware of 
the binding.

Best regards,
Attila 

-----Original Message-----

All,

Much thanks,
Lou (and Deborah)

---

From: [email-masked]
Date: Wed, 13 Apr 2011 11:51:34 +0800

Hi Fatai

There are some misunderstanding about the consensus on splitting the 
document [draft-ietf-ccamp-assoc-info-01.txt] to be two parts:
(1)Usage of The RSVP Association Object
(2)RSVP Association Object Extensions

one is "informational usage for GMPLS recovery", another one is for 
"Standards track extensions for non-GMPLS recovery usage and Extended 
association"

So for the second parts, it is about the information model，currently two 
documents related to it.

one is draft-ietf-ccamp-rsvp-resource-sharing-01

the other is draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04

Furthermore, the recovery defined in RFC4872 and RFC4873 need to be 
reconsidered in MPLS-TP; of course the association type is no need to be 
redefined, but the extended association object should be used.

Do you want to one doucment to merge all of these content, even for the 
future extensions?

Just my two cents, that is a useless suggestion. 

Anyway, we need to hear the opinions from the WG.

Thanks 

Fei

Fatai Zhang <[email-masked]> 
发件人:  [email-masked]
2011-04-13 10:02

收件人
Lou Berger <[email-masked]>, [email-masked]
抄送

主题
Re: [CCAMP] poll on makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 
a WG document

Hi all,
 
This draft just introduces a new Association Type, so do we really need 
one more separate draft for this simple thing?
 
In Prague meeting, we know that there was a consensus on 
[draft-ietf-ccamp-assoc-info-01.txt] to separate it into two drafts: 
(1)Usage of The RSVP Association Object
(2)RSVP Association Object Extensions
 
So, I think it is appropriate to address MPLS-TP bidirectional LSP 
association in the draft (2), because we know that one of the key drivers 
for Association Object Extensions in [draft-ietf-ccamp-assoc-info-01] is 
for MPLS-TP.
 
In this way, we can just keep two drafts for the association stuff 
(besides RFC4872 and RFC4873), one is "informational usage for GMPLS 
recovery", another one is for "Standards track extensions for non-GMPLS 
recovery usage and Extended association". Another benefit  of this 
approach is very easy for the readers to track and review the RFCs.

Thanks
 
Fatai
 
----- Original Message ----- 
From: "Lou Berger" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 01, 2011 5:24 PM
Subject: [CCAMP] poll on 
makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

CCAMP mailing list
[email-masked]

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 13 Apr 2011 15:15:23 +0800

Hi all,

Do you think that it should keep so much overlapped information (or crossed information) in so many separate drafts for the homogeneous topic?

I am not against anything, however, I just think the WG should discuss how to organize the content about association stuff.

I think it is the right time to discuss this issue(ie., content organization), because these drafts are still WG documents or individual drafts.

I would like to see the feedback from the authors of these related drafts and WG chairs.

Thanks
 
Fatai

  ----- Original Message ----- 
  From: [email-masked] 
  To: Fatai Zhang 
  Cc: [email-masked] ; [email-masked] ; Lou Berger 
  Sent: Wednesday, April 13, 2011 11:51 AM
  Subject: Re: [CCAMP] poll on makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

  Hi Fatai 

  There are some misunderstanding about the consensus on splitting the document [draft-ietf-ccamp-assoc-info-01.txt] to be two parts: 
  (1)Usage of The RSVP Association Object 
  (2)RSVP Association Object Extensions 

  one is "informational usage for GMPLS recovery", another one is for "Standards track extensions for non-GMPLS recovery usage and Extended association" 

  So for the second parts, it is about the information model，currently two documents related to it. 

  Furthermore, the recovery defined in RFC4872 and RFC4873 need to be reconsidered in MPLS-TP; of course the association type is no need to be redefined, but the extended association object should be used. 

  Do you want to one doucment to merge all of these content, even for the future extensions? 

  Thanks 

  Fei 

        Fatai Zhang <[email-masked]> 
        发件人:  [email-masked] 
        2011-04-13 10:02 
       收件人 Lou Berger <[email-masked]>, [email-masked]  
              抄送  
              主题 Re: [CCAMP] poll on makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document 

  Hi all, 

    

    

  Thanks

  Fatai

  ----- Original Message ----- 
  From: "Lou Berger" <[email-masked]> 
  To: <[email-masked]> 
  Sent: Friday, April 01, 2011 5:24 PM 
  Subject: [CCAMP] poll on makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document 

  CCAMP mailing list
  [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Wed, 13 Apr 2011 08:43:05 -0400

Attila,
	So I appreciate your comment, and would like to have this discussion,
but I think I need some clarification from the perspective of the poll.
 I'm unsure if you're saying:
(a) support this document becoming a WG document and would like
    discuss the point raised below in the context of a WG document
or
(b) do NOT support this document becoming a WG document until the
    point you raise becomes a WG document

Can you clarify if you mean (a) or (b)?

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 13 Apr 2011 09:11:49 -0400

Fatai,
	You raise a reasonable question.

In general, the reason to have separate documents is really about how we
expect implementations/usage to occur *after* the documents become RFCs.
 In particular, we generally follow the practice that if the functions
will typically be implemented/required as a set, then the functions
should be published as a single document; and if the functions are
completely separable, then they should be published as separate RFCs.
This is important from a conformance statement perspective (a whole RFC
is supported, not sections X, Y and Z of and RFC).

Am important related consideration is avoiding interoperability issues
seen in the past with subset implementations. In particular, we try
avoid the case where two implementations that state conformance to the
same RFC cannot interoperate to provide the same function.

Of course these are just general principles.

So if we ask the question will the functions covered in (2) and the
draft being polled always be implemented as a set.  Given
draft-ietf-ccamp-rsvp-resource-sharing, I suspect the answer is no.

Given this perspective, do you still believe that merging the drafts is
a good idea?

Lou

On 4/12/2011 10:02 PM, Fatai Zhang wrote:
> association in the draft (2), because we know that one of the key
> drivers for Association Object Extensions in
> [draft-ietf-ccamp-assoc-info-01] is for MPLS-TP.
>  
> From: "Lou Berger" <[email-masked] <mailto:[email-masked]>>
> To: <[email-masked] <mailto:[email-masked]>>
>> [email-masked] <mailto:[email-masked]>

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 14 Apr 2011 10:24:23 +0800

Hi Lou,

OK, I am fine if the authors and chairs like the current content organization.

Thanks
 
Fatai

---

From: "Jing Ruiquan" <[email-masked]>
Date: Thu, 14 Apr 2011 14:58:13 +0800

Support as co-author

Jing Ruiquan

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, April 11, 2011 9:14 AM
To: [email-masked]; [email-masked]; Lou Berger
Subject: Re: [CCAMP] poll on making
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

+1 

Best Regards， 
Xuehui 

2011-04-08 04:03 

收件人
<[email-masked]> 

抄送

主题

Yes, support. 

Br, Dan. 

-----Original Message-----

All,

Much thanks,
Lou (and Deborah)

---

From: Giovanni Martinelli <[email-masked]>
Date: Thu, 14 Apr 2011 09:20:26 +0200

support

G

P.S. Neutral on ID organization but agree that point raised by Attila 
need some discussion.

---

From: Isacco Fontana <[email-masked]>
Date: Thu, 14 Apr 2011 09:24:09 +0200

Support

Isacco

> The poll ends Friday April 15.

----------------------------------------------------------------------------------------------------------

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 14 Apr 2011 10:27:36 +0200

Yes / support

R.

---

From: Jie Dong <[email-masked]>
Date: Thu, 14 Apr 2011 12:22:44 +0000

Hi authors,

One quick comment here.

In section 3.3 recovery considerations, it says
" LSP3... can share the same TE tunnel with LSP1 or not. ... This can be done by inserting the Extended ASSOCIATION object in LSP3's Path message with the same value as in LSP1's Path message."

This means LSP3 may use LSP1's IDs in the Extended ASSOCIATION object in its Path message, which may contain Tunnel_Num and LSP_ID different from its own and LSP2's.

However, in section 4, the specification of Association ID and Extended Association ID field says:
 o Association ID:
   The Association ID MUST be set to its own signaled LSP ID (default); if known, it MAY be set to the LSP ID of the associated reverse LSP.
 o Extended Association ID:
   ... the first 16-bits MUST be set to its own tunnel ID (default); if known, it May be set to the tunnel ID of the associated reverse tunnel.

Hence the two specifications conflict with each other.

Regards,
Jie

---

From: [email-masked]
Date: Thu, 14 Apr 2011 22:16:04 +0800

Hi Jie

Thank you for the comments. :)

According to the description in section 4

"The Association ID MUST be set to its own signaled LSP ID (default); if 
known, it MAY be set to the LSP ID of the associated reverse LSP."
"The first 16-bits MUST be set to its own tunnel ID (default); if known, 
it May be set to the tunnel ID of the associated reverse tunnel."
 
What about the revision like this: "if known, it MAY be set to the LSP ID 
of the associated reverse LSP or inherited from the corresponding recovery 
LSP."

I will address all the comments in the next version.

Best regards 

Fei

:)

Jie Dong <[email-masked]> 
发件人:  [email-masked]
2011-04-14 20:22

收件人
Lou Berger <[email-masked]>, "[email-masked]" <[email-masked]>
抄送

主题

Hi authors,

One quick comment here.

In section 3.3 recovery considerations, it says
" LSP3... can share the same TE tunnel with LSP1 or not. ... This can be 
done by inserting the Extended ASSOCIATION object in LSP3's Path message 
with the same value as in LSP1's Path message."

This means LSP3 may use LSP1's IDs in the Extended ASSOCIATION object in 
its Path message, which may contain Tunnel_Num and LSP_ID different from 
its own and LSP2's.

However, in section 4, the specification of Association ID and Extended 
Association ID field says:
 o Association ID:
   The Association ID MUST be set to its own signaled LSP ID (default); if 
known, it MAY be set to the LSP ID of the associated reverse LSP.
 o Extended Association ID:
   ... the first 16-bits MUST be set to its own tunnel ID (default); if 
known, it May be set to the tunnel ID of the associated reverse tunnel.

Regards,
Jie

---

From: Attila Takacs <[email-masked]>
Date: Thu, 14 Apr 2011 19:06:39 +0200

Hi Lou, all,
It would be nice to clarify the scope of the proposed extension. 
I would say (a) if that does not include commitment to work on the "single sided mode". To my current understanding that operation mode is not required for associated bidirectional LSPs. There is no discussion in the document about which operation mode is really needed, if I'm not mistaken similar comments were raised in Beijing, but this is not addressed in the document. Hence my confusion.
Thanks,
Attila

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, April 13, 2011 2:43 PM
To: Attila Takacs
Cc: [email-masked]
Subject: Re: [CCAMP] poll on making draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Attila,
	So I appreciate your comment, and would like to have this discussion, but I think I need some clarification from the perspective of the poll.
 I'm unsure if you're saying:
(a) support this document becoming a WG document and would like
    discuss the point raised below in the context of a WG document or
(b) do NOT support this document becoming a WG document until the
    point you raise becomes a WG document

Lou

---

From: [email-masked]
Date: Fri, 15 Apr 2011 08:34:56 +0800

Hi Attila, all

That is the critical problem we need to solve next step. :-)

Yeah, Lou have the similar comments in Beijing, but there are not enough 
discussion on the mailinglist. Since every provisioning mode is possible 
"in theory" ,and in order to be convenient for discussion, I list both of 
them in the document currently. 

If we consider the pracitical deployment, and have an agreement that only 
double sided provisioining model is useful after the discussion, the 
single sided provisioning model will be deleted.

Best regards

Fei

:) 

2011-04-15 01:06

收件人

Hi Lou, all,
It would be nice to clarify the scope of the proposed extension. 
I would say (a) if that does not include commitment to work on the "single 
sided mode". To my current understanding that operation mode is not 
required for associated bidirectional LSPs. There is no discussion in the 
document about which operation mode is really needed, if I'm not mistaken 
similar comments were raised in Beijing, but this is not addressed in the 
document. Hence my confusion.
Thanks,
Attila

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, April 13, 2011 2:43 PM
To: Attila Takacs
Cc: [email-masked]
Subject: Re: [CCAMP] poll on making 

Attila,
                 So I appreciate your comment, and would like to have this 
discussion, but I think I need some clarification from the perspective of 
the poll.
 I'm unsure if you're saying:
(a) support this document becoming a WG document and would like
    discuss the point raised below in the context of a WG document or
(b) do NOT support this document becoming a WG document until the
    point you raise becomes a WG document

Lou

> 
> I think two independently signaled LSPs with the addition of the 
proposed Association object would do the job addressing the associated 
bidirectional LSP requirements, so that transit nodes are also aware of 
the binding.

---

From: Jie Dong <[email-masked]>
Date: Fri, 15 Apr 2011 02:07:25 +0000

Hi Fei,

Thanks for your prompt reply.

Although the suggested statement could solve the problem of confliction, it still looks a little strange that the IDs in the extended ASSOCIATION object may have nothing to do with the two associated LSPs.

Regards,
Jie

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 14, 2011 10:16 PM
To: Jie Dong
Cc: [email-masked]; [email-masked]; Lou Berger
Subject: Re: [CCAMP] poll on making draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Hi Jie

"The Association ID MUST be set to its own signaled LSP ID (default); if known, it MAY be set to the LSP ID of the associated reverse LSP."
"The first 16-bits MUST be set to its own tunnel ID (default); if known, it May be set to the tunnel ID of the associated reverse tunnel."

What about the revision like this: "if known, it MAY be set to the LSP ID of the associated reverse LSP or inherited from the corresponding recovery LSP."

Best regards

Fei

:)

2011-04-14 20:22

收件人

抄送

主题

Re: [CCAMP] poll on        making        draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG        document

Hi authors,

One quick comment here.

Regards,
Jie

---

From: [email-masked]
Date: Fri, 15 Apr 2011 14:04:00 +0800

Hi Jie

In general，two unidirectional LSPs can be bound together based on the 
same global unique value under the same association type. Actually, TP' 
identifier is one kind of such global
unique value, which is defined in the Extended Association object. In 
other words, the association rule under the scenarios of recovery is still 
based on the same association type and association value. So " the IDs in 
the extended ASSOCIATION object may have nothing to do with the two 
associated LSPs" has no effect on the binding.

Of course, we can define a new object which carrys another kind of unique 
value which is irrelevant to the TP's identifier. That SHOULD works well, 
but I think the design rule is to reuse the existing object to do the same 
thing if it is possible.

Is the interpretation reasonable?

Thanks and best regards

Fei

2011-04-15 10:07

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, Lou Berger <[email-masked]>
主题
RE: [CCAMP] poll on making 
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Hi Fei,

Although the suggested statement could solve the problem of confliction, 
it still looks a little strange that the IDs in the extended ASSOCIATION 
object may have nothing to do with the two associated LSPs.
 
Regards,
Jie

Hi Jie 

  

Best regards 

Fei 

:) 

收件人

主题

Hi authors,

One quick comment here.

Regards,
Jie

---

From: Jie Dong <[email-masked]>
Date: Fri, 15 Apr 2011 09:00:57 +0000

Hi Fei,

Please consider the following scenario:

1.       LSP1 and LSP2 form associated bidirectional LSP, the extended ASSOCIATION object uses Tunnel-ID1 and LSP-ID1.

2.       TE make-before-break happens for recovery. LSP3 is established and LSP1 is tore down.  Then LSP3 and LSP2 form associated bidirectional LSP, and according to specification in this draft,  it will still use Tunnel-ID and LSP-ID of LSP1 in the extended ASSOCIATION object.

3.       Later a new LSP is established using Tunnel-ID1 and LSP-ID1, and it may also need to associate with another reverse LSP4. Thus it may use Tunnel-ID1 and LSP-ID1 in the extended ASSOCIATION object for this new associated LSP. In this case, there may be two different associated LSPs using the same extended ASSOCIATION object.

This means in some cases the extended ASSOCIATION object may not be global unique. Is this acceptable?

Regards,
Jie

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 15, 2011 2:04 PM
To: Jie Dong
Cc: [email-masked]; [email-masked]; Lou Berger
Subject: RE: [CCAMP] poll on making draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Hi Jie

In general，two unidirectional LSPs can be bound together based on the same global unique value under the same association type. Actually, TP' identifier is one kind of such global
unique value, which is defined in the Extended Association object. In other words, the association rule under the scenarios of recovery is still based on the same association type and association value. So " the IDs in the extended ASSOCIATION object may have nothing to do with the two associated LSPs" has no effect on the binding.

Of course, we can define a new object which carrys another kind of unique value which is irrelevant to the TP's identifier. That SHOULD works well, but I think the design rule is to reuse the existing object to do the same thing if it is possible.

Thanks and best regards

Fei

2011-04-15 10:07

收件人

抄送

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Lou Berger <[email-masked]>

主题

RE: [CCAMP] poll on making draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Hi Fei,

Regards,
Jie

Hi Jie

Best regards

Fei

:)

2011-04-14 20:22

收件人

抄送

主题

Hi authors,

One quick comment here.

Regards,
Jie

---

From: [email-masked]
Date: Fri, 15 Apr 2011 17:55:09 +0800

Hi Jie

You are right, I neglected that LSP1 ID can be reused.

What about the revision below?

1.       LSP1 and LSP2 form associated bidirectional LSP, the extended 
ASSOCIATION object uses Tunnel-ID1 and LSP-ID1.
2.       TE make-before-break happens for recovery. LSP3 is established 
and LSP1 is tore down.  Then LSP3 and LSP2 form associated bidirectional 
LSP, and according to specification in section 4 ""The Association ID MUST 
be set to its own signaled LSP ID (default); if known, it MAY be set to 
the LSP ID of the associated reverse LSP." it will use Tunnel-ID and 
LSP-ID of LSP2 in the extended ASSOCIATION object.  LSP3 is refreshed with 
the additional inserted  Extended Association Object.

3.       Later a new LSP is established using Tunnel-ID1 and LSP-ID1, and 
it may also need to associate with another reverse LSP4. Thus it may use 
Tunnel-ID1 and LSP-ID1 in the extended ASSOCIATION object for this new 
associated LSP. In this case, there are no two different associated LSPs 
using the same extended ASSOCIATION object. 

So the current description in recovery section will be revised.

Thank you again for your comments and scenarios.

Best regards

Fei

2011-04-15 17:00

收件人

Hi Fei,

1.       LSP1 and LSP2 form associated bidirectional LSP, the extended 
ASSOCIATION object uses Tunnel-ID1 and LSP-ID1.
2.       TE make-before-break happens for recovery. LSP3 is established 
and LSP1 is tore down.  Then LSP3 and LSP2 form associated bidirectional 
LSP, and according to specification in this draft,  it will still use 
Tunnel-ID and LSP-ID of LSP1 in the extended ASSOCIATION object. 
3.       Later a new LSP is established using Tunnel-ID1 and LSP-ID1, and 
it may also need to associate with another reverse LSP4. Thus it may use 
Tunnel-ID1 and LSP-ID1 in the extended ASSOCIATION object for this new 
associated LSP. In this case, there may be two different associated LSPs 
using the same extended ASSOCIATION object. 
 
This means in some cases the extended ASSOCIATION object may not be global 
unique. Is this acceptable?
 
Regards,
Jie
 
Subject: RE: [CCAMP] poll on making 

Hi Jie 

Thanks and best regards 

Fei 

收件人

Hi Fei, 

  
Regards, 
Jie 

Hi Jie 

 

Best regards 

Fei 

:) 

收件人

主题

Hi authors,

One quick comment here.

Regards,
Jie

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 Apr 2011 09:42:11 -0400

Attila,
	So we have two points here:
1) WG procedure related

So this mail is in response to a poll. As your answer is (a).  I (as
chair) know how to interpret you position, i.e., "Yes/Support".

2) Point related to the contents of the draft.

As this is a technical point, and independent of the poll.  I'll start a
new thread on this in a separate mail.

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 Apr 2011 09:50:25 -0400

[Subject: Was Re: [CCAMP] poll on making
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document]

> As this is a technical point, and independent of the poll.  I'll
> start a new thread on this in a separate mail.
>

As I (as WG member, not chair) understand it, you are questioning the
requirement for the "single sided mode".  I think this is a good
question.  As you pointed out, I believe I suggest that this question be
raised, by the authors, on the TP list.

RFC5645 seems to allow for independent provisioning of associated, but
it doesn't preclude the "single sided mode".  It also has requirements
11 and 12 which are certainly facilitated by "single sided mode".

I believe you also raise some valid issues with the current definition
of the processing rules. I'll defer my comments on this for now.

Lou

BTW This isn't the first time that "single sided mode" has been suggest.
I seem to remember discussing a proposal on this from Juha Heinanen at
the Adelaide IETF.  I also know of one vendor-specific implementation
that never made it to the field or the WG.

---

From: "So, Ning" <[email-masked]>
Date: Fri, 15 Apr 2011 14:45:52 +0000

Yes/support.

Best regards,
 
Ning So
Network Evolution Planning
Verizon, Inc.
(office) 972-729-7905
(Cell) 972-955-0914

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lou Berger
Sent: Friday, April 15, 2011 8:42 AM
To: Attila Takacs
Cc: [email-masked]
Subject: Re: [CCAMP] poll on
makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Attila,

Thanks,
Lou

On 4/14/2011 1:06 PM, Attila Takacs wrote:
> I would say (a) if that does not include commitment to work on the
"single sided mode". To my current understanding that operation mode is
not required for associated bidirectional LSPs. There is no discussion
in the document about which operation mode is really needed, if I'm not
mistaken similar comments were raised in Beijing, but this is not
addressed in the document. Hence my confusion.
> 	So I appreciate your comment, and would like to have this
discussion, but I think I need some clarification from the perspective
of the poll.
signaling phases together. I have some doubts that this model is needed.
It seems to complicate operation and it also begs the question why not
use bidirectional LSPs instead. 
>> or "no/do not support".  If indicating no, please state your
technical reservations with the document.

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 Apr 2011 17:07:40 -0400

All,
	This poll is concluded.  While there has been discussion on this draft
during the poll, the clear consensus of the WG is that this document
should be accepted as a WG document.  As a reminder, this means that
formal WG effort on the document will now commence.

Authors,

Please resubmit your draft *unmodified* (except for the name) as
draft-ccamp...

Please also continue to discuss any issue raised during the poll.
Changes should go in the -01 version of the WG version of the document.

Thank you,
Lou (and Deborah)

---

From: Attila Takacs <[email-masked]>
Date: Tue, 19 Apr 2011 11:38:04 +0200

Hi all, 
Please see inline [at].

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, April 15, 2011 3:50 PM
To: Attila Takacs
Cc: [email-masked]
Subject: Requirement for singled ended provisioning of associated bidirectional LSPs

> As this is a technical point, and independent of the poll.  I'll start 
> a new thread on this in a separate mail.
>

As I (as WG member, not chair) understand it, you are questioning the requirement for the "single sided mode".  I think this is a good question.  As you pointed out, I believe I suggest that this question be raised, by the authors, on the TP list.

[at] Fei, is/was there any conclusion on the TP list?

RFC5645 seems to allow for independent provisioning of associated, but it doesn't preclude the "single sided mode".  It also has requirements
11 and 12 which are certainly facilitated by "single sided mode".

[at] I think requirements 11 and 12 can be fulfilled by using an association id on both LSPs with "double-sided mode" at LSP establishment or at a later point for association. 

In the case LSPs should be associated later on, after establishment, a simple "single sided" solution might be used to allow single-touch association, this is mainly an optimization not a required feature I guess. In this case besides the association id one may also send the LSP id of the reverse direction to which the association should be established, which in turn would result in the resignalling of that LSP with the association id. Doing more elaborate "single-sided" signaling, e.g, including reverse bw and qos parameters seems to me to add unnecessary complexity. 

Best regards,
Attila

I believe you also raise some valid issues with the current definition of the processing rules. I'll defer my comments on this for now.

Lou

BTW This isn't the first time that "single sided mode" has been suggest.
I seem to remember discussing a proposal on this from Juha Heinanen at the Adelaide IETF.  I also know of one vendor-specific implementation that never made it to the field or the WG.

On 4/15/2011 9:42 AM, Lou Berger wrote:
> As this is a technical point, and independent of the poll.  I'll start 
> a new thread on this in a separate mail.
> 
> Thanks,
> Lou
>

---

From: [email-masked]
Date: Tue, 19 Apr 2011 19:12:30 +0800

Hi Attila, 

see inline [Fei]

Best regards

Fei

2011-04-19 17:38

收件人

主题
Re: [CCAMP] Requirement for singled ended provisioning of associated 
bidirectional LSPs

Hi all, 
Please see inline [at].

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, April 15, 2011 3:50 PM
To: Attila Takacs
Cc: [email-masked]
Subject: Requirement for singled ended provisioning of associated 
bidirectional LSPs

As I (as WG member, not chair) understand it, you are questioning the 
requirement for the "single sided mode".  I think this is a good question. 
 As you pointed out, I believe I suggest that this question be raised, by 
the authors, on the TP list.

[Fei]Although I put it on the TP list, there was no discussion on this 
topic. See the old link : 
http://www.ietf.org/mail-archive/web/mpls-tp/current/msg05277.html
     I forward the discussion to the MPLS list this time, hope we can get 
more feedback.

RFC5645 seems to allow for independent provisioning of associated, but it 
doesn't preclude the "single sided mode".  It also has requirements
11 and 12 which are certainly facilitated by "single sided mode".

[at] I think requirements 11 and 12 can be fulfilled by using an 
association id on both LSPs with "double-sided mode" at LSP establishment 
or at a later point for association. 

[Fei] Agree, but the complexity of "double-sided mode" is almost the same 
as compared to "single-sided mode" at LSP establishment.

     Assume that the time costs for path and resv message are the same 
vlaue "TC" 

      For "single-sided mode", the time costs are 3TCs(2TCs for LSP1 from 
west to east plus 1TC for LSP2 from east to west).
      As for "double-sided mode", the binding happens when the path 
refresh message are sent out based on the solution described in the 
document, so the time cost is generally the same :one path-resv circle 
plus one path message processing. 

In the case LSPs should be associated later on, after establishment, a 
simple "single sided" solution might be used to allow single-touch 
association, this is mainly an optimization not a required feature I 
guess. In this case besides the association id one may also send the LSP 
id of the reverse direction to which the association should be 
established, which in turn would result in the resignalling of that LSP 
with the association id. Doing more elaborate "single-sided" signaling, 
e.g, including reverse bw and qos parameters seems to me to add 
unnecessary complexity. 

[Fei] In this case, the association id is the LSP id of the reverse 
direction ("if known, it MAY be set to the LSP ID of the associated 
reverse LSP"), there is no need to carry reverse bw and qos parameters. 
They are only carried when the reverse LSP does not exist. I will clarify 
it in next version.

 It is more complex for double sided provisiong mode in this case that the 
LSPs are associated after establishment, and the cost is one path-resv 
refresh circle plus one path refresh message processing.

Best regards,
Attila

I believe you also raise some valid issues with the current definition of 
the processing rules. I'll defer my comments on this for now.

Lou

BTW This isn't the first time that "single sided mode" has been suggest.
I seem to remember discussing a proposal on this from Juha Heinanen at the 
Adelaide IETF.  I also know of one vendor-specific implementation that 
never made it to the field or the WG.

"single sided mode". To my current understanding that operation mode is 
not required for associated bidirectional LSPs. There is no discussion in 
the document about which operation mode is really needed, if I'm not 
mistaken similar comments were raised in Beijing, but this is not 
addressed in the document. Hence my confusion.