The MPLS WG Archive

[Lou Berger <lberger@movaz.com>]

Adrian,
         See below.

At 04:43 PM 10/24/00, Adrian Farrel wrote:
>[...]
> >
> >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?

Done.


> >>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?

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.

> >>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.

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.

> >>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.

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.


> >>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?

yes.

>This would be good, but it might be helpful to describe the
>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