The MPLS WG Archive

[Abhijit <gabhijit@ee.iitb.ernet.in>]

LDP specification does in fact allows it. Infact the message processing
procedures are quite elaborate about it. But the section 5.2.1 of
architecture draft says... 

5.2.1. Schemes for LSRs that Support Label Merging

   If Ru and Rd are label distribution peers, and both support label
   merging, one of the following schemes must be used:
                                         ^^^^
and the case which i was discussing was not included in the list of
schemes. thats why there was confusion... 
 
-abhijit

On Fri, 23 Feb 2001, Eric Gray wrote:

>Bhushana,
>
>    You're all placing too much "authority" in an architecture
>document.  Architecture typically defines a framework for
>design and specification.
>
>    In this case, the LDP specification specifically allows
>Label Request messages to be used by an upstream peer
>when the downstream peer is using downstream unsolicited
>label distribution.
>
>    As a minimum, this is required when the upstream LSR is
>an ATM LSR and is not able to perform VC-merge.  But
>there is nothing that restricts this support to ATM LSRs.
>
>    Instead of asking if the architecture allows it, look to see
>if the protocol specification allows it.
>
>
>You wrote:
>
>> > Consider e.g.
>> >
>> > Ru1
>> >   \
>> >     \
>> >      Rd1 - - Rd2 - - Rd3 - - D
>> >     /
>> >   /
>> > Ru2
>> >
>> > Let Rd1 be merge capable..
>> >
>> > Why can Rd1 not send a request to Rd2 for some FEC F for packets destined
>> > for D and coming from Both Ru1 and Ru2.. The fact that Rd2 distributes the
>> > label bindings unsolicitedly won't require Rd1 to send the request. But in
>> > any case it shouldn't prevent Rd1 from asking for it. How will it matter
>> > if Rd2 distributes binding labels for FEC independent control or Ordered
>> > control? So in any case Rd1 need not know Control mode of Rd2.. Is it
>> > consisitent with architecture?
>> > -abhijit
>>
>> exactly! the problem started with the same thing - why should my request
>> procedure depend on my peer's control mode?? I don't need to bother
>> whether he has given the binding indepndently or not. If you look at the
>> architecture doc section 5.2.1 you could find this dependency. So I feel
>> we need to have one more tuple there where my request procedure can be
>> "Request when needed" when I am in conservative retention and the
>> downstream dist procedure is PushUConditional (or a possible restructuring
>> of the tuples so that my request procedure is independant of peer's
>> control mode).
>>
>> best regards
>> Bhushana
>>
>> > > >
>