Subject: [CCAMP] UPSTREAM_TSPEC usage in draft-ietf-ccamp-asymm-bw-bidir-lsps-bis//Please ignore the above mail for the wrong address

From: [email-masked]
Date: Thu, 11 Aug 2011 17:18:37 +0800

Hi Authors

As descirbed in this document, the UPSTREAM_TSPEC will not used in the 
PATH message.

So we defined another object call RESVER_TSPCE to deal with the asymmetric 
bandwidth in associated bidirectional LSP scenarios in the draft 
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-01
.

According to the on-line discussion in IETF80, we need to check if the 
UPSTREAM_TSPEC object can be used in both co-routed and associated 
applications.

Lou Berger: a technical question, upstream TSPEC instead of a new TSPEC. 
It would be good to have Attila’s input on compatibility with asymmetric 
BW rfc/bis. 
Attila Takacs: I'm not entirely sure that we can use the same fields this 
case.
Lou Berger: I think this is also question for existing implementations. As 
to whether or not they would get confused by having the upstream TSPEC, in 
a path message that does not contain the upstream label. The BNF 
definition requires the TSPEC present if the label is also present. So 
what would happen to an existing implementation receives path message, 
which contains the TSPEC but not the label.
Attila Takacs: for this use case we may need a different field. I will 
need to check and comment on the list.

Can we enlarge the scope of the UPSTREAM_TSPEC object using a different 
field, or just keep the definition unchanged?

Thanks

Fei

---

From: Lou Berger <[email-masked]>
Date: Thu, 11 Aug 2011 07:51:35 -0400

Fai,
	I'm not exactly sure what you are asking, but I think your question
relates to the possible use of UPSTREAM_TSPEC in the path message as
part of an associated bidirectional LSP.  Is this correct?

In my opinion, this comes down to how you address the compatibility
issue. I think it would be helpful if you could send the Compatibility
section that would be include in the draft if you were to use
UPSTREAM_TSPEC.

Lou

On 8/11/2011 5:18 AM, [email-masked] wrote:
> So we defined another object call RESVER_TSPCE to deal with the
> asymmetric bandwidth in associated bidirectional LSP scenarios in the
> draft
> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-01.
> 
> 
> *Lou Berger*: a technical question, upstream TSPEC instead of a new
> TSPEC. It would be good to have Attila’s input on compatibility with
> asymmetric BW rfc/bis. *
> Attila Takacs*: I'm not entirely sure that we can use the same fields
> this case.*
> Lou Berger*: I think this is also question for existing implementations.
> As to whether or not they would get confused by having the upstream
> TSPEC, in a path message that does not contain the upstream label. The
> BNF definition requires the TSPEC present if the label is also present.
> So what would happen to an existing implementation receives path
> message, which contains the TSPEC but not the label.*
> Attila Takacs*: for this use case we may need a different field. I will
> need to check and comment on the list*.*
> 
> 
>

---

From: [email-masked]
Date: Fri, 12 Aug 2011 17:18:24 +0800

Hi Lou

Thanks for your prompt response.

Please see in line <fei>

B.R.

Fei

Lou Berger <[email-masked]> 
2011-08-11 19:51

收件人
[email-masked]
抄送
[email-masked], [email-masked], 
[email-masked], [email-masked], 
[email-masked]
主题
Re: UPSTREAM_TSPEC usage in 
draft-ietf-ccamp-asymm-bw-bidir-lsps-bis//Please ignore the above mail for 
the wrong address

Fai,
                 I'm not exactly sure what you are asking, but I think 
your question
relates to the possible use of UPSTREAM_TSPEC in the path message as
part of an associated bidirectional LSP.  Is this correct?

<Fei>Yeah

<Fei>I do not catch the idea clearly. Do you mean which one of the 
possible solutions listed below or another one?

(1) If the REVERSE_LSP object is defined in associated draft (here refers 
to your comments about section 5 )and the UPSTREAM_TSPEC is used as a 
sub-object. Although the UPSTREAM_TSPEC object is restricted not in PATH 
message, we can enlarge the usage here to address the comatibility issue?

(2) If the REVERSE_LSP object is defined in associated draft (here refers 
to your comments about section 5 )and the SENDER_TSPEC is used as a 
sub-object. There will be no
   backward issue since there is no need to use the UPSTREAM_TSPEC object.

Lou