Subject: RE: Query on CRLDP

From: Abhishek Gupta <[email-masked]>
Date: Wed, 17 Nov 1999 19:57:14 +0530

Hi all ,
I understand that both  modes can be supported  but what shall I do when I am supporting DU mode and I receive CR-LDP request.
Please correct me if I am wrong.
Thanks 
Abhi

-----Original Message-----
From:	Srinivasan Balaji [SMTP:[email-masked]]
Sent:	Wednesday, November 17, 1999 7:07 PM
To:	Shyam P.S.
Cc:	[email-masked]
Subject:	Re: Query on  CRLDP

Folks,
   Yes, multiple modes can be supported simultaneously by the LSR. CR-LDP
always uses the downstream on demand with ordered control
mode because of the various parameters that the source has to send
identifying & classifying the LSP.

Thanks
Balaji.

"Shyam P.S." wrote:

> I think both "Unsolicited" and "On Demand" modes can be supported
> simultaneously by an LSR.
> Can anybody throw more light on this ?
> - SHyam
>
> ----- Original Message -----
> From: Abhishek Gupta <[email-masked]>
> To: [email-masked]' <[email-masked]>
> Sent: Wednesday, November 17, 1999 4:00 PM
> Subject: Query on CRLDP
>
> >
> > ****** Message from InterScan E-Mail VirusWall NT ******
> >
> > ** No virus found in attached file noname
> >
> > Mail Scanned For Virus At ITLInfosys
> >
> > *****************     End of message     ***************
> >
> >
>
> ----------------------------------------------------------------------------
> ----
>
> Hi All,
> I have a doubt regarding CR-LDP implementation in Unsolicited Control Mode.
> My question is whether is possible to Support CR-LDP  and Unsolicited Mode
> at the same time and at the same LSR? Though my question might sounds weird
> but I need a solution to my problem.
>
> A---->B---->C
> Suppose A, B and C are three LSRs and they are in Unsolicited Control Mode.
> Now  from A there a is CR-LDP request to B how does B react to it .Since I
> know that  CR-LDP uses Downstream On Demand Ordered Control Mode .
> * Now can I send CR-LDP request from A ?
>
> Thanks in advance
> Waiting for your replies.
> Abhi

--
  -----------------------------------------------------------------
  Srinivasan Balaji
  Ficon Technology
  Voice : (732) 283-2770 xtn.303
  Fax   : (732) 283-2848
  mailto:[email-masked]
  Web   : http://www.ficon-tech.com
  -----------------------------------------------------------------

---

From: [email-masked]
Date: Wed, 17 Nov 1999 22:54:26 +0800

Abhishek,

An LSR which is using DU mode [on link 'x']
is not prohibited from sending
Label mapping messages for any
Upstream peer [on link 'x'] requesting it
for label mappings

cheers,
chetan

---

From: Srinivasan Balaji <[email-masked]>
Date: Wed, 17 Nov 1999 10:53:55 -0500

Abhi,
   DoD must always be supported (even if you have signalled support for
DU mode) specifically for CRLDP though LSRs might have negotiated to use
DU for non-CRLSPs.   I don't think this behaviour has been explicitly specified
but can be adopted for flexbility.

Thanks
Balaji.

---

From: Geetha Brown <[email-masked]>
Date: Wed, 17 Nov 1999 11:19:22 -0500

Abhishek,

During the session initialization,  the LSRs negotiate the session
parameters.  One of these session parameter
is Label Advertisement Discipline. If the received label advertisement
discipline is unacceptable to an LSR, 
the session gets rejected.  So, if your LSR is supporting DU mode and it
has set up a session with its
adjacent LSR after negotiating the distribution mode, it should not send
the down stream on demand based
CR-LDP request to your LSR.

Geetha

-- 
Geetha M Brown

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 18 Nov 1999 16:24:57 +0900

Balaji,

From: Srinivasan Balaji <[email-masked]>
Subject: Re: Query on  CRLDP
Date: Wed, 17 Nov 1999 10:53:55 -0500

> but can be adopted for flexbility.

I agree with Balaji's suggestion, since it makes CR-LSPs and 
hop-by-hop LSPs co-exist nicely.  And I also don't think this 
behaviour has been explicitly specified.

Yoshihiro Ohba

---

From: Eric Gray <[email-masked]>
Date: Fri, 19 Nov 1999 00:26:50 -0500

> behaviour has been explicitly specified.

In the section "Downstream Unsolicited Label Advertisement", it
states -

"  In general, the downstream LSR is responsible for advertising a label
   mapping when it wants an upstream LSR to use the label.  An upstream
   LSR may issue a mapping request if it so desires.

"  The combination of Downstream Unsolicited mode and conservative label
   retention can lead to a situation where an LSR releases the label for
   a FEC that it later needs.  For example, if LSR Rd advertises to LSR
   Ru the label for a FEC for which it is not Ru's next hop, Ru will
   release the label.  If Ru's next hop for the FEC later changes to Rd,
   it needs the previously released label.

"  To deal with this situation either Ru can explicitly request the
   label when it needs it, or Rd can periodically readvertise it to Ru.
   In many situations Ru will know when it needs the label from Rd.  For
   example, when its next hop for the FEC changes to Rd.  However, there
   could be situations when Ru does not.  For example, Rd may be
   attempting to establish an LSP with non-standard properties.  Forcing
   Ru to explicitly request the label in this situation would require it
   to maintain state about a potential LSP with non-standard properties.

"  In situations where Ru knows it needs the label, it is responsible
   for explicitly requesting the label by means of a Label Request
   message.  In situations where Ru may not know that it needs the
   label, Rd is responsible for periodically readvertising the label to
   Ru."

Arguably, this is only an implicit statement that the downstream LSR 
must support DoD (in terms of answering the Label Requests that the
upstream LSR makes), but this an obvious implication.  For an explicit 
and definitive statement, review the section "Receive Label Request"
in the appendix.  There, you will find that there are no circumstances
in which the downstream LSR is allowed to ignore the Label Request and
circumstances in which a Notification is returned are well defined and
limited.

In addition, the MPLS architecture (in section "Schemes for LSRs that 
do not Support Label Merging") lists three modes of operation that may
be used in a non-merging LSR.  All of them include DoD label allocation.

Note that the procedures in LDP for negotiating label allocation mode
are not robust enough to make a non-merging LSR suddenly become merge
capable - or for that matter, LSRs with restricted merging capability
suddenly unrestricted.  Hence, even if the negotiated mode is DU, it
is still necessary that the LSRs be capable of processing Label
Requests.

I'm a little unclear on what more needs to be said...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 19 Nov 1999 18:41:07 +0900

Eric,

I know there is an explicit and definitive statement 
in the section "Receive Label Request" in the appendix 
that the downstream LSR operating in DU mode will process 
the received Label Request.

But I don't think there is an explicit statement in the appendix 
that an LSR operating in DU mode is allowed to send a Label Request 
*when it recognizes a new FEC*.

Suppose that an ingress LSR supporting CR-LDP wants to newly 
initiate a CRLSP setup.

According to the rule described in section "A.1.6. Recognize New FEC" 
of the LDP spec, the ingress LSR will not send a Label Request 
if unfortunately its next hop LSR is operating in DU mode
(so the ingress LSR is forced to use DU mode for the next hop LSR).

That's the reason for agreeing with Balaji's suggestion.

Note that I know in the case of next hop change, it is explicitly
described in section "A.1.7. Detect Change in FEC Next Hop" of the LDP
spec that even if an LSR is operating in DU mode, the LSR will send a
Label Request if particular conditions are met.

Regards,
Yoshihiro Ohba

From: Eric Gray <[email-masked]>
Subject: Re: Query on  CRLDP
Date: Fri, 19 Nov 1999 00:26:50 -0500

---

From: Eric Gray <[email-masked]>
Date: Sun, 21 Nov 1999 17:52:34 -0500

> *when it recognizes a new FEC*.

Huh?

This is precisely what the specification is talking
about when it says that an LSR operating in DU mode
may be able to determine that it needs a new Mapping
from its downstream neighbor relative to a specific
FEC.  See the second and third paragraphs in the text
quoted previously (below) on the subject.  In this 
case, it is explicitly allowed to request a new label.

From the perspective of the downstream neighbor, it
is impossible for that neighbor to determine WHY an
upstream neighbor (again relative to some FEC) asks
for a new Label Mapping.  It is non-sensical to even
try.  Hence, the upstream neighbor CAN ALWAYS ask
for a new Label Mapping, and why it does so is purely
an implementation choice - entirely independent of
the negotiated label allocation mode.

Recall that the reason for negotiating an allocation
mode is to prevent two under-achieving LSRs from not
being able to function in tandem with each other.  In
every case, over-achieving LSRs are allowed.  Period.

> (so the ingress LSR is forced to use DU mode for the next hop LSR).

The procedures describe MINIMAL required behavior.  It is
not a good idea to include everything that anyone would 
like to be able to do as a minimal required behavior.

> Label Request if particular conditions are met.

See discussion above.  As stated there, _why_ an LSR asks 
for a new label is irrelevant to the responding LSR peer.
Hence allowing it in any case, allows it in every case.