The MPLS WG Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi Adrian,

Thanks a lot for your comments - see in line,

At 10:11 AM 1/14/2004 +0000, Adrian Farrel wrote:
>  
> Thanks Loa,
>  
> Observation:
>  
> The use of the node-id flag is not clearly
> explained as a requirement to achieve the function that the draft states
> it aims to achieve. In section 4, you have...
>  
>   - case 1: the backup tunnel
> destination is the MP's node-id. Then a PLR 
>   can find the MP and suitable backup tunnel by simply comparing the
>   backup tunnel's destination address with the node-id included in
> the 
>   RRO of the primary tunnel.  
>   - case 2: the backup tunnel terminates at an address different
> than the 
>   MP's node-id. Then a node-id subobject MUST also be included in
> the RRO 
>   object of the backup tunnel. A PLR can find the MP and suitable
> backup 
>   tunnel by simply comparing the node-ids present in the RRO objects
> of 
>   both the primary and backup tunnels. 
>  
> The requirement for these cases is that the
> node-id is inserted in the RRO so that the tail-ends of the available
> backup tunnels can be compared against the RRO to determine an MP and a
> suitable backup tunnel. This function does not require that the node-ids
> be distinguishable from interface-ids within the RRO (although that
> distinction might marginally speed up the comparison).
>  
> Thus the applicability of the node-id flag
> does not extend to the problem stated.
>  
> This does not detract from
> - the need to include node-ids in the
> RRO
> - the wider benefit of being able to
> distinguish node-ids from interface-ids.
>  

Sure, I'll clarify, thanks.


>  
> Major point:
>  
> I do not believe it is helpful to copy text
> from RFC 3209 into section 3. Further, I consider it unhelpful to copy in
> text that is not correctly cited. Note that RFC 3209 defines only 2 RRO
> flags (Local protection available, and Local protection in use). The
> other three flags are defined in drafts not RFCs.
> I would suggest that you simply define your
> new flag value. if you want to justify the value, simply say that other
> documents define other flag settings.

Agree, will fix that.

>  
> Minor points:
>  
> Abstract must not contain
> citations.
> Intellectual property section is not the
> standard wording.
> Copyright section is missing.
> Security section should reference RFC 3209,
> not RFC 2205.
> References need to be split into Normative
> and Informational.

Good points, will fix that also.

>  
>  
>  
> Nits:
>  
> Date stamps are inconsistent.
> References are way out of date.
> Page 5 para 1
> "trafficengineering"
>  

will fix that also.

Thanks for the comments, I'll repost a rev -02 shortly incorporating your
comments and fixes.

Thanks.

JP.

>  
>  
> Thanks,
> Adrian
> ----- Original Message ----- 
> From: "Loa Andersson"
> <NtscpUsrLoa@netscape.net>
> To: "MPLS wg"
> <mpls@UU.NET>
> Cc: "Alex Zinin"
> <zinin@psg.com>; "George
> Swallow"
> <swallow@cisco.com>
> Sent: Thursday, January 08, 2004 4:21
> PM
> Subject: WG last call on
> draft-ietf-mpls-nodeid-subobject-01.txt
>
> > WG-group,
> > 
> > this is to initiate a two week wg last call on
> > 
> > <draft-ietf-mpls-nodeid-subobject-01.txt>
> > 
> > Please send comments to the mailing list.
> > 
> > The wg last call ends on January 25th 12PM EST.
> > 
> > /Loa
> > 
> > 
> > -- 
> > 
> > Loa Andersson
> > 
> > mobile +46 739 81 21 64
> > 
> > 
> > 
> >