The MPLS WG Archive

[Adrian Farrel <AF@dataconnection.com>]

Lou,

Thanks for the response.

Agreements deleted.

Sorry that I missed so many obvious points.

Regards,
Adrian

>>Error values etc.
>>Can I suggest adding a section at the end as a place holder 
>>for new error values.
>
>This is *really* stylistic, do you really care?

I don't care, but the (new) values are going to have to be 
defined somewhere.  Perhaps we push this out to the
protocol-specific docs that will be written later?


>>4.2 Bidirectional LSP Procedures
>>The choice you have made is consistent (that you may not
>>propagate a Path containing Upstream_Label until the local
>>switch has been programmed, so that the terminator may start
>>sending data as soon as it has processed the Path) but may
>>unnecessarily increase the latency of LSP set up (compare
>>with the arguments for Suggested_Label).
>>If ResvConf were to be requested and used, the individual
>>switch programming tasks could be processed in parallel with
>>the propagation of the Path message.  The terminator is not
>>allowed to start sending data until it receives the ResvConf.
>>This is a direct trade-off, but could quite easily reduce
>>setup time for individual LSPs.
>
>This is a reasonable representation of the choice that was made.

No chance of re-opening this debate?

>>4.3 Bidirectional LSP Contention Resolution
>>The suggested behavior for reducing contention depends on
>>adjacent LSRs knowing each other's node IDs.  Does this
>>rely on Hello messages, carnal knowledge or what?
>
>from the draft:
>    For the purposes of RSVP contention
>    resolution, the node ID is the IP address used in the RSVP_HOP
>    object.

Agreed.
However, the draft also says...

   To reduce the probability of contention, one may impose a
   policy that the node with the lower ID never suggests a 
   label in the downstream direction and always accepts a 
   Suggested Label from an upstream node with a higher ID.

To know whether to suggest a label, you need to know whether
you have the higher or lower ID.  To find that out, you
have to receive a Path message containing RSVP_HOP from the
other node.

Hence my question.

>>5.1.2 Notify Request Procedures
>>We should add a statement about multiple instances of this object.
>>The current discussion allows just a single instance.
>
>This is by design.  Others have made the same point, but it 
>wasn't clear that this functionality is really required.  
>Why do you believe this is needed?

I'm aproaching from the other end.
I'd like an explicit statement limiting us to one instance (more
explicit than the BNF) precisely because of the discussions about 
multiple targets.


>>5.2.2 Notify Procedures
>>This version of the text does not prohibit the Notify Node from
>>being other than the requester (i.e. initiator or terminator).
>
>Again, this is by design.

Do I take it, then, that we're also leaving it open for nodes
to change the value of the Notify Address as the Path/Resv
is propagated?

This would be good, but it might be helpful to describe the
process.  (Text available on demand :-)

>>5.2     "Notify Ack" is obsolete, read "Ack"
>
>I couldn't find this.  Can you provide more context.
>
>>5.3     for "receiving such a error" read "receiving such an error"
>
>I couldn't find this.  Can you provide more context.

Sorry.  both transcription errors from my review of the beta draft.

--
Adrian Farrel  mailto:af@dataconnection.com
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.dataconnection.com/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422