Subject: Re: LSP control mode of peer...

From: "Amarnath Honnavalli Anantharamaiah" <[email-masked]>
Date: Thu, 22 Feb 2001 19:23:42 +0530

Hi vijay,

Given a combination of upstream LSR (Ru) and downstream LSR (Rd) -
Distribution procedure is Downstream's distribution procedure & Request
procedure is upstreams. Hence in the combination below,
<PushUnConditional, RequestWhenNeeded, RequestNoRetry,ReleaseOnChange,
*> Distribution procedure represents donwstream ' distribution procedure
and Request Procedure is Upstream.

Am I wrong ?

The above conclution is made from the mpls architechture draft (or RFC)
5.1.1 Downstream LSR: Distribution Procedure
5.1.2 Upstream LSR: Request Procedure

Regards
Amar

Vijayanand Chandrasekar wrote:

>  Amar,This information is needed for configuring the LSRs' on what
> schemes WE support. For example PushConditional means Unsolicited
> Ordered control is used by us when we distribute labels as a
> downstream.It is not what is used ny our downstream.Your question is
> why you are not allowed to use -  (PushUnCond)UnsolicitedIndependent
> with (RWN)Conservative .Unsolicited Independent and Conservative are
> not used in combination,You can look at the mail archives for this.The
> question should not be not whether ur downstream is ordered or
> independent? Vijay
>
>      -----Original Message-----
>      From: Amarnath Honnavalli Anantharamaiah
>      [mailto:[email-masked]]
>      Sent: Thursday, February 22, 2001 5:39 PM
>      To: Vijayanand Chandrasekar
>      Cc: Bob Thomas
>      Subject: Re: LSP control mode of peer...
>
>      Vijay,
>
>      [1] No, basically question was,  From the list of valid
>      schemes supported  for  merge capable LSR, we don't find
>      this combination.
>      <PushUnConditional, RequestWhenNeeded,
>      RequestNoRetry,ReleaseOnChange, *>
>       however we can find the following combination
>      <PushConditional, RequestWhenNeeded,
>      RequestNoRetry,ReleaseOnChange, *>
>
>      Now, how do we know if downstream is PushConditional or
>      PushUnconditional ???
>
>      [2] If this is not needed to know, Why is this combination
>      given in the list ?
>
>      Regards
>      Amar
>
>      Vijayanand Chandrasekar wrote:
>
>     > Vinay,I don't think you need to know whether your
>     > downstream is Ordered or Independent. You need to just
>     > know if it is Ondemand or Unsolicited. Regards,Vijay
>     >
>     >      -----Original Message-----
>     >      From: [email-masked]
>     >      [mailto:[email-masked]]On Behalf Of Vinay
>     >      Vernekar
>     >      Sent: Thursday, February 22, 2001 1:41 PM
>     >      To: [email-masked]'
>     >      Subject: LSP control mode of peer...
>     >      Hello,I have a query which came up when
>     >      implementing the LDP as in rfc3036 - "LDP
>     >      Specification", keeping in mind the MPLS
>     >      architecture as given be rfc3031.As discussed in
>     >      rfc3031 - 5.2.1. Schemes for LSRs that Support
>     >      Label Merging -If Ru and Rd are label
>     >      distribution peers, and both support
>     >      labelmerging one of the supported scheme is - 3.
>     >      <PushConditional, RequestWhenNeeded,
>     >      RequestNoRetry,ReleaseOnChange, *>This implies
>     >      that the label retention mode of the upstream
>     >      can be conservative given that the downstream is
>     >      operating in Unsolicited label distribution mode
>     >      and its LSP control mode is Ordered. But how can
>     >      the LSP control mode of the peer be determined?
>     >      This is not available in any of the LDP
>     >      messages/TLVs. Thanks &
>     >      RegardsVinay~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     >
>     >      Yesterday is history. Tomorrow is mystery.
>     >      Today is a gift. That’s why it’s called the
>     >      Present!!
>     >
>     >      ****************************************************************************
>     >
>     >      Vinay H. Vernekar
>     >      Sr. Software Engineer - Global R&D Solutions
>     >      Wipro Technologies
>     >      No.26, Hosur Main Road, Bommanahalli,
>     >      Bangalore-560 068, India.
>     >
>     >      ****************************************************************************
>     >

---

From: Abhijit <[email-masked]>
Date: Thu, 22 Feb 2001 22:56:18 +0530 (IST)

amar,

I think its not at all necessary to know the Downstream Label Distribution
Control Mode. If thats what u r asking.. An LSR acting as Ru will never
mind whether the bindings it receives is independent or ordered as long as
it receives them . (However its a job of Downstream LSR to suppply
bindings properly.) 

perhaps following diagram might help.

   Ru........ Rd1.........Rd2

consider things at Rd1
PushConditional/unConditional depends upon whether after receiving request
from Ru1(Assuming Ru is reqWhenNeeded and ingress) Rd1 should distribute
binding to Ru1 independently (pushUnconditional) or only if it has
received it from Rd2(pushConditional -- assuming all conditions in 5.1.1.
are met.) So its not at all needed by Ru1 to know the Control mode of
Rd1..

However if Rd1 chooses to use pushConditional with requestNever with
Downsteam on Demand mode (thr' misconfiguration probably) ( READ
specifically section 5.2.3 of rfc3031), then its in serious problems as
it will never request anything but is expecting a mapping from downstream.

Hope it is clear

-abhijit

---

From: "Vijayanand Chandrasekar" <[email-masked]>
Date: Fri, 23 Feb 2001 10:27:51 +0530

Hi Amar,
Here - downstream distribution procedure means the distribution procedure
followed by the LSR as a downstream. So PushUnCond.. means u are using
DownstreamUnsolicitedIndependent control as your downstream label
distribution procedure.

Abhijit has graphically illustrated the scenario in his mail.Hop you are now
clear.

Regards,
Vijay
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Amarnath
Honnavalli Anantharamaiah
  Sent: Thursday, February 22, 2001 7:24 PM
  To: Vijayanand Chandrasekar; [email-masked]
  Cc: Bob Thomas
  Subject: Re: LSP control mode of peer...

  Hi vijay,
  Given a combination of upstream LSR (Ru) and downstream LSR (Rd) -
Distribution procedure is Downstream's distribution procedure & Request
procedure is upstreams. Hence in the combination below,
  <PushUnConditional, RequestWhenNeeded, RequestNoRetry,ReleaseOnChange, *>
Distribution procedure represents donwstream ' distribution procedure and
Request Procedure is Upstream.

  Am I wrong ?

  Regards
  Amar

     Amar,This information is needed for configuring the LSRs' on what
schemes WE support. For example PushConditional means Unsolicited Ordered
control is used by us when we distribute labels as a downstream.It is not
what is used ny our downstream.Your question is why you are not allowed to
use -  (PushUnCond)UnsolicitedIndependent with (RWN)Conservative
.Unsolicited Independent and Conservative are not used in combination,You
can look at the mail archives for this.The question should not be not
whether ur downstream is ordered or independent? Vijay
      -----Original Message-----

      Vijay,
      [1] No, basically question was,  From the list of valid schemes
supported  for  merge capable LSR, we don't find this combination.
      <PushUnConditional, RequestWhenNeeded, RequestNoRetry,ReleaseOnChange,
*>
       however we can find the following combination
      <PushConditional, RequestWhenNeeded, RequestNoRetry,ReleaseOnChange,
*>

      [2] If this is not needed to know, Why is this combination given in
the list ?

      Regards
      Amar

        Vinay,I don't think you need to know whether your downstream is
Ordered or Independent. You need to just know if it is Ondemand or
Unsolicited. Regards,Vijay
          -----Original Message-----
          From: [email-masked] [mailto:[email-masked]]On Behalf Of
Vinay Vernekar
          Sent: Thursday, February 22, 2001 1:41 PM
          To: [email-masked]'
          Subject: LSP control mode of peer...
          Hello,I have a query which came up when implementing the LDP as in
rfc3036 - "LDP Specification", keeping in mind the MPLS architecture as
given be rfc3031.As discussed in rfc3031 - 5.2.1. Schemes for LSRs that
Support Label Merging -If Ru and Rd are label distribution peers, and both
support labelmerging one of the supported scheme is - 3. <PushConditional,
RequestWhenNeeded, RequestNoRetry,ReleaseOnChange, *>This implies that the
label retention mode of the upstream can be conservative given that the
downstream is operating in Unsolicited label distribution mode and its LSP
control mode is Ordered. But how can the LSP control mode of the peer be
determined? This is not available in any of the LDP messages/TLVs. Thanks &
RegardsVinay~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          Yesterday is history. Tomorrow is mystery.
          Today is a gift. That’s why it’s called the Present!!

*

*

---

From: "Vinay Vernekar" <[email-masked]>
Date: Fri, 23 Feb 2001 11:01:19 +0530

Hello Abhijeet,
I have a query on the explanation given by you, kindly find it mentioned
below -

----- Original Message -----
From: Abhijit <[email-masked]>
To: Amarnath Honnavalli Anantharamaiah <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 22, 2001 10:56 PM
Subject: Re: LSP control mode of peer...

amar,

consider things at Rd1
PushConditional/unConditional depends upon whether after receiving request
from Ru1(Assuming Ru is reqWhenNeeded and ingress) Rd1 should distribute
binding to Ru1 independently (pushUnconditional)
-- Since you are assuming Ru is ReqWhenNeeded, does this mean that a MPLS
scheme is possible with Ru being RequestWhenNeeded and Rd1 being
PushUnconditional?? If yes this scheme is not mentioned in 5.2.1 Schemes for
LSRs that Support Label Merging...
If no it implies that Ru can be in RequestWhenNeeded only when Rd1 is
PushConditional and inorder to determine if Rd1 is in PushConditonal its
control mode is to be known by Ru.
Hope I have made it clear.

or only if it has

Hope it is clear

-abhijit

On Thu, 22 Feb 2001, Amarnath Honnavalli Anantharamaiah wrote:

>>     >      Today is a gift. That's why it's called the
>>     >      Present!!
>>     >
>>     >

---

From: Abhijit <[email-masked]>
Date: Fri, 23 Feb 2001 13:05:09 +0530 (IST)

>Hope I have made it clear.

Yes I certainly have missed this point. But i don't understand what
precludes Upstream LSR for requesting a Label from Downstream when
downstream is distributing it unslolcited with independent control. 

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? 

And if Rd1 is also distributing bindings independently.. It will
distribute same binding to Ru1 and Ru2. Again why shd it stop Ru1 and Ru2
from requesting it anyways? Is this also consistent with architecture?
Again Ru1 and Ru2 need not know the control mode of Rd1 

am i missing something?

-abhijit

---

From: "Nagabhushana Ramaswamy Nadig" <[email-masked]>
Date: Fri, 23 Feb 2001 14:38:04 +0000 (Local time zone must be set--see zic manual page)

> consisitent with architecture? 

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

---

From: Eric Gray <[email-masked]>
Date: Fri, 23 Feb 2001 10:50:14 -0500

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.

---

From: Abhijit <[email-masked]>
Date: Fri, 23 Feb 2001 22:15:43 +0530 (IST)

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

---

From: Eric Gray <[email-masked]>
Date: Fri, 23 Feb 2001 12:39:53 -0500

Abhijit,

    Yes, but it doesn't say "ONLY one of the ..." :-)