The MPLS WG Archive

["Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>]

Hi Yoshihiro
    Plz see my comments inline.


> Santosh,
>
>  > 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.
>
> Okay.  In such an assumption, an opaque FEC can be used, however...,
>
>  > 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.
>
> 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.
>
>  > 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
>
>
>  >                 LER1 ------> LSR2-------->LSR3------>LSR4
>
> 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?
>
> 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?
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
>
> Yoshihiro Ohba
>
>
>  > Santosh Gupta
>
>
>