Re: [CCAMP] I-D Action: draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04.txt

[[e-mail]]

Hi, Lou

Thanks for your detailed review and suggestions, see response in line 
tagged with <Fei>.

A new draft will be submitted recently.

Thanks and best regards

Fei



Lou Berger <[e-mail]> 
2012-10-09 02:11

收件人
[e-mail], "Rakesh Gandhi (rgandhi)" <[e-mail]>, 
[e-mail], [e-mail], 
[e-mail], "BRUNGARD, DEBORAH A (ATTLABS)" <[e-mail]>
抄送

主题
Re: [CCAMP] I-D Action: 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04.txt






Fei, Authors,
                 I think you have the document scoped to match the 
discussion.  I'm
personally still having a hard time with parsing the document.  I think
I know what you mean to say, it's just that the document isn't always so
clear.  I think some editing might help.

Hhere are some suggestions:
1) Change the title to something like:
RSVP-TE Identification of MPLS-TP Co-Routed Bidirectional LSPs

<Fei> Great, it reflects the motivation of the draft more precisely.

2) Simplify the Abstract, perhaps just focus on the purpose of the
extension vs the details of the extension.
<Fei> OK.

3) Ensure the Intro covers the key points clearly.  I see the minimal
set of key points as:
   - TP identifiers are defined in RFC6370

<Fei> Sure

   - Identifiers are need by both end points of a bidirectional LSP
     for OAM

<Fei> Exactly

   - RFC6370 defines mapping of TP identifiers to RSVP-TE for
     associated bidirectional LSPs (but other aspects aren't which
     are covered by [associated-lsp]), but not co-routed LSPs.

<Fei> To be strict, RFC6370 defines mapping of TP identifiers to RSVP-TE
for co-routed LSPs in paragraph 5.3, but not complete .

   - The high level approach taken by the draft to address the
     missing function.

<Fei> OK.

4) The Operation section seems to be covering procedures, so why not
just combine with section 4.2, or add an informational description of
the extension as part of section 4 (before section 4.1).

<Fei> We will change the title of paragraph 4 to be MPLS-TP Co-routed
Bidirectional LSPs Identification, then merge paragraph 3.


5) The Procedures section needs to explicitly define what an
implementation needs to do to (a) support the desired function and (b)
conform with the document.  Think about covering what the
ingress/transit/egress needs to do and how it needs to do it.

<Fei> Will add section "Compatibility" to cover the behavior of 
ingress/transit/egress nodes' processing.


Lou

PS please feel free to respond on-list (including the above) if you'd 
like.

On 8/28/2012 12:33 PM, [e-mail] wrote:
> 
> Lou
> 
> We have received comments offline/online and addressed them into the
> draft v-03 from the polling version 02, then updated the draft to v-04
> according to the comments received since IETF84 meeting and pushed the
> proposal into the mailinglist also to hear more opinions.
> 
> The authors think we have addressed all the comments and this draft is
> ready for WG consideration now.
> 
> Any suggestion?
> 
> Best regards :)
> 
> Fei
> 
> 
> *Lou Berger <[e-mail]>*
> 
> 2012-08-21 01:38
> 
> 
> 收件人
>                [e-mail]
> 抄送
>                [e-mail]
> 主题
>                Re: [CCAMP] I-D Action:
> draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04.txt
> 
> 
> 
> 
> 
> 
> 
> 
> Fei,
>                 To respond to your procedure point:
> 
> On 8/17/2012 3:27 AM, [e-mail] wrote:
>> I am not sure whether this draft should follow the the procedures
>> defined for WG documents or not.
> 
> Individual drafts are completely under the control of the authors.  Of
> course, they may choose to listen to feedback of WG participants in hope
> of getting their draft accepted as a WG draft....
> 
> Lou
> 
>