Subject: RE: draft-ietf-mpls-generalized-signaling-00.txt

From: Adrian Farrel <[email-masked]>
Date: Tue, 24 Oct 2000 21:43:58 +0100

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:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.dataconnection.com/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

---

From: Lou Berger <[email-masked]>
Date: Wed, 25 Oct 2000 08:15:27 -0400

Adrian,
         See below.

At 04:43 PM 10/24/00, Adrian Farrel wrote:
>[...]

Done.

>No chance of re-opening this debate?

I actually don't think there's much to debate here.  Here's my view: Your 
suggested approach would require the use of ResvConf.  There are a some 
issues with this.  (1) ResvConf is currently optional, and (2) more 
importantly ResvConf is not refreshed.  The latter means that the reliable 
message delivery of refresh-reduct is also required to support 
bidirectional LSPs, such support isn't currently required.  (BTW I may be 
mistaken, but I don't think there's a ResvConf equivalent in CR-LDP, so it 
too would need to be defined.)  If all of this isn't enough, the other 
factor to consider is that LSP setup would require three passes of control 
messages versus the two passes currently supported by both signaling 
protocols.  Given all of this, I think it's clear that use of /reliance on 
ResvConf isn't the way to go.

>have to receive a Path message containing RSVP_HOP from the

If I understand you correctly, you're point is that the neighbor address 
might not be known when sending the 1st path messages and if both sides 
send initial path messages at approximately the same time, they might not 
know the neighbor's address.  Did I get it right?  If so, there are lots of 
other places in the system where such information should be 
available.  Assuming it's not, both nodes suggesting a random label when 
the neighbor's address should be good enough for this initial 
condition.  I'll add a comment in the draft to that effect.

>explicit than the BNF) precisely because of the discussions about

Okay I think the BNF is explicit but I've added the following text anyway:
    If a message contains multiple NOTIFY_REQUEST objects, only the first
    object is meaningful.  Subsequent NOTIFY_REQUEST objects MAY be ignored
    and SHOULD NOT be propagated.

>to change the value of the Notify Address as the Path/Resv

yes.

>process.  (Text available on demand :-)

The text says:
    The outgoing Notify Node Address MAY be updated based on local policy.

I think this is enough since this is a local implementation issue.

Thanks again for the comments,
Lou