Subject: Re: CR-LDP

From: [email-masked]
Date: Tue, 28 Mar 2000 15:33:15 +0800

LSP-IDs become part of the "traffic engineering state" of the network.  So
it is legitimate to define a CR-LSP, whose ingress is LER2,  stacking or
splicing with an existing CR-LSP whose ingress is LER1,  the latter being
specified by its LSP-ID.   The entity which does traffic engineering can be
thought of as "higher" than the LSR, and it knows these LSP-IDs.  At that
level, there is global (or, supra-local) knowledge.

However, from the point of view of LSRs, local knowledge is sufficient.
LSRs need to know only the LSP-IDs they participate in.

In your example,  LER2 and LSR5 do not need to know the spliced/stacked
CR-LSP's LSP-ID because all they do with it is, just pass it downward.
That remains true as we go down the request path till we hit LSR3, for
which it is intended.   So there is no need for non-participating LSRs to
be aware of the LSP-ID.

-- Ajith

--

"Santosh Gupta" <[email-masked]> on 03/28/2000 12:45:39
PM

Please respond to "Santosh Gupta" <[email-masked]>

To:   [email-masked], [email-masked]
cc:   "Ashish Monga" <[email-masked]> (bcc: Ajith
      Narayanan/Singapore/IBM)
Subject:  Re: CR-LDP

Hi Sumit
    The concerned section of CR-LDP draft is as below.
4.7.4. ER-Hop 4: LSPID

The LSPID is used to identify the tunnel ingress point as the next
hop in the ER. This ER-Hop allows for stacking new CR-LSPs within an
already established CR-LSP. It also allows for splicing the CR-LSP
being established with an existing CR-LSP.
If an LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may
splice the CR-LSP of the incoming Label Request to the CR-LSP that
currently exists with this LSPID. This is useful, for example, at
the point at which a Label Request used for local repair arrives at
the next ER-Hop after the loosely specified CR-LSP segment. Use of
the LSPID Hop in this scenario eliminates the need for ER-Hops to
keep the entire remaining ER-TLV at each LSR that is at either
(upstream or downstream) end of a loosely specified CR-LSP segment
as part of its state information. This is due to the fact that the
upstream LSR needs only to keep the next ER-Hop and the LSPID and
the downstream LSR needs only to keep the LSPID in order for each
end to be able to recognize that the same LSP is being identified.

In this it clearly states that it is not only the Ingress LER and the LSRs
in the path of this LSP but other LERs also need to know the LSP-ID of
different LSPs. The scenario is something like

                LER1 ------> LSR2-------->LSR3------>LSR4

                LER2-------->LSR5

there is an LSP setup as shown from LER1 thru LSR2,LSR3, LSR4. Now LER5
receives a ER-TLV which says it has to make an  LSP for which the next hop
is LSR3 and the already existing LSP with the LSP-ID is to be used. Now the
question is how does LSR5 or LER2 come to know about this particular LSP-ID
which actually originated at LER1?

santosh

[email-masked]

----- Original Message -----
From: Sumit Garg
To: 'ashish'
Sent: Tuesday, March 28, 2000 3:49 A
Subject: RE: CR-LDP

Hi,

LSD-ID is a TLV defined by the CR-LDP draft. It is a combination of the
LSR-ID and a 2 octect number assigned by the ingress/ initiating LSR. This
would typically be an administor assigned/ monitored quantity and thereof
known a priori for LSP splicing/ tunneling.

The LSPID is propagated to downstream LSRs in the LSP setup request.

Regards
Sumit

  -----Original Message-----
  From: ashish [mailto:[email-masked]]
  Sent: Monday, March 27, 2000 03:58 AM
  To: [email-masked]
  Subject: CR-LDP

  In CR-LDP draft-03, one of the ER-HOP TLV types contain LSPID field that
is used for tunneling thru some existing LSP having that LSPID field.
  This means that that LSPID should be known in advance .
  How is that done.
  Does information regarding each LSP being created each having unique
LSPID is propagated to all LSR's.
  Please clarify.

---

From: "Santosh Gupta" <[email-masked]>
Date: Tue, 28 Mar 2000 14:37:15 +0530

Hi Ajit
    The label stacking scenario that you mentioned is possible in MPLS, but if  we implement it on ATM then how can it be done as the  ATM cell has a fixed header size (5 bytes) and there is just 12+16 bits allocated for label (VPI/VCI ). Any suggestions.
santosh
  ----- Original Message ----- 
  From: [email-masked] 
  To: Santosh Gupta 
  Cc: [email-masked] ; Ashish Monga ; [email-masked] 
  Sent: Tuesday, March 28, 2000 1:03 PM
  Subject: Re: CR-LDP

  -- Ajith

  --

  Hi Sumit

                  LER2-------->LSR5

  santosh

  [email-masked]

  ----- Original Message -----
  From: Sumit Garg
  To: 'ashish'
  Sent: Tuesday, March 28, 2000 3:49 A
  Subject: RE: CR-LDP

  Hi,

  Regards
  Sumit

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 28 Mar 2000 22:33:15 +0900

Ajithn,

 > which it is intended.   So there is no need for non-participating LSRs to

There is an issue here on how an LSR that is not aware of the LSP-ID
can determine who is the "downward" LSR for the LSP-ID.

I think it depends on the FEC type used for the CR-LSP, that is, 
an opaque FEC should not be used in this case.  If we use a prefix FEC or 
host address FEC, the "downward" LSR can be determined based
on the FEC information.

Yoshihiro Ohba

---

From: "Santosh Gupta" <[email-masked]>
Date: Wed, 29 Mar 2000 11:14:19 +0530

Hi Yoshihiro
    Please see the embedded comments.

> host address FEC, the "downward" LSR can be determined based

Who is supposed to be the "Downstream" peer is decided by the global (or,
supra-local) entity which has the knowledge of all the LSPs and the topology
of the network.
An Opaque FEC has to be used for CR-LSP(sec 4.10 in
draft-ietf-mpls-cr-ldp-03) since this feature is there only in CR-LDP and to
setup a CR-LSP it is compulsory.
One more issue that crops up at this point is that how is this type of LSP
to be setup. The initial scenario that we discussed was

                LER2-------->LSR5

Now suppose the scenario were like

                LER1 ------> LSR2-------->LSR3------>LSR4------>LSR6

                LER2-------->LSR5------->LSR7

and LSR7 was supposed to connect to LSR4. How is the new LSP to be setup?
The  global (or, supra-local) entity will inform only LER2 which will be
sending message to LSR5 which would in turn send the request to LSR7. Is
there any standard draft on how this is to be handled?

Santosh Gupta

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 30 Mar 2000 00:00:44 +0900

Santosh,

 > supra-local) entity which has the knowledge of all the LSPs and the topology

Okay.  In such an assumption, an opaque FEC can be used, however..., 

 > setup a CR-LSP it is compulsory.

section 4.10 of the CR-LDP draft does not preclude the use of other
FECs elements (Type=0x01, 0x02, 0x03) in CR-LDP messages.

 >                 LER1 ------> LSR2-------->LSR3------>LSR4

LER2--------> LSR5

 >                 LER1 ------> LSR2-------->LSR3------>LSR4------>LSR6

LER2--------> LSR5------->LSR7

 > there any standard draft on how this is to be handled?

I don't think there is any standard draft proposing to distribute
LSPID information to/from the global entity.  But is there a 
situation where the supposed scenario is useful?

Yoshihiro Ohba

---

From: "Subodh Mathur" <[email-masked]>
Date: Wed, 29 Mar 2000 15:01:33 -0500

By using loose hop problem mentioned below can be solved.
Suppose second LSP is to terminate at LER10 which is topologically adjacent
to LSR6.

        LER2----->LSR5----->LSR7----->LSR4----->LSR6----->LER10

So if LER2 construct a ER TLV with  ER-Hops <LSR5, LSR7, LER10> where LER10
is a loose ER-Hop. LSR7 will determine using some routing algo. that LSR4 is
the next hop. So it will modify the ER TLV as <LSR4, LER10>.  Now LSR4 can
use its knowledge of existing LSP ID for tunneling and ER TLV will be
<LSPID, LER10>.
Subodh

---

From: "Santosh Gupta" <[email-masked]>
Date: Thu, 30 Mar 2000 11:15:15 +0530

Hi Yoshihiro
    Plz see my comments inline.

> situation where the supposed scenario is useful?
This could be useful in the case when lots of traffic is meant for the same
destination. If we make the traffic go thru the same LSP that would reduce
load on the switch as it will have less no. of LSPs in the state
information. This case is the same as "Merging" of LSPs.

Santosh