Re: [CCAMP] Request for comments: the next step about the draft draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03

[[e-mail]]

Lou 

Sorry for the misunderstanding, the proposal is listed below. 

we define the new Association Type "LSP identifiers" and it's semantics in 
the draft draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03. Furthermore, 
this draft will only focus on the corouted bidirectional LSP, and this 
type of the Association object can be carried in the Resv message to let 
A1 node know the Global ID and tunnel number of Z9 node.

As to the associated bidrectional LSP, Z9 and A1 node needs to each 
other's global ID in certain scenarios (CV configuration if the LSP across 
different domains). we will add one section in the draft 
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 
to describe the scenarios and cite the extension defined in the draft 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03. In other words, if CV 
configuration is required and the LSP is across different domains, two 
Association object will be carried at least, one is the Association Type 
"associatied bidirectional lsp" to represent the association and the other 
is the Association Type "LSP identifiers" used for CV configuration.

In this way, the subjects of these two drafts are unambiguous, one is 
corouted and the other is associated. IMHO, the vendor will implement 
corouted or associated bidrectional LSPs, but may not implement both of 
them. Consider the reason listed above, I would like to keep the two 
drafts relatively independent and relunctant to put all these content into 
one draft 
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03.

Any comments are welcome

Thanks

Fei



Lou Berger <[e-mail]> 
2012-08-04 05:35

收件人
[e-mail]
抄送
[e-mail], [e-mail], [e-mail], 
[e-mail]
主题
Re: Request for comments: the next step about the draft 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03







Fei,
                 My request was a bit more specific.  The request was/is 
for the authors
to propose, on the list, text that would merge support for the function
discussed in the draft (and agreed to on the list) into
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp.  The WG could then
react to this proposal and agree/disagree to the proposed merge.

Lou

On 8/3/2012 4:37 AM, [e-mail] wrote:
>
> Hi Lou
> 
> Thanks you for your suggestion in the merging the solution into the
> existing WG documents to push this work forward. :)
> 
> IMHO, there are three potential WG documents, like
> 
> (1) draft-ietf-ccamp-assoc-ext-03.txt
> <http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-03.txt>
> 
> This draft is now in IESG processing, which defines the extensions of
> the Association object, and is irrelevant with the specific association
> types.
> 
> (2) draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08
> <http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08>
> 
> The proposed text can be added in section 3.2, a new TLV or the
> Association object with the defined new association type, which carring
> back the Z9_tunnel_num in the Resv message, needs to be defined there.
> This draft is WG last call, and I have sent out the corresponding
> comments, hope to hear the authors' opinion.
> 
> (3) draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp
> <
http://tools.ietf.org/wg/ccamp/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp/
>
> 
> 
> If the proposed texts are added in this draft, the subject needs to be
> enlarged to cover both the associated and corouted bidirectional LSPs.
> 
> Maybe the first step is to determine which draft is the better choice
> for merging, then we will submit the proposed texts.
> 
> Any WG's feedbacks are welcome
> 
> Best regards
> 
> Fei