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 <lberger <at> labn.net>
2012-08-04 05:35
|
|
收件人
|
zhang.fei3 <at> zte.com.cn
|
|
抄送
|
ccamp <at> ietf.org, venkat.mahalingams <at> gmail.com,
xuyunbin <at> mail.ritt.com.cn, bao.xiao1 <at> zte.com.cn
|
|
主题
|
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, zhang.fei3 <at> zte.com.cn 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
RSS Feed