The MPLS WG Archive

[ajithn@sg.ibm.com]

Ohba,

>Ajithn,
>
> > 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.
>
>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
>

That sounds drastic, and I dont see a need to modify the FEC. The ER list
is powerful enough to handle these kinds of cases. For the problem as
stated (in Santosh's example), the (a?) correct way to formulate the ER
list is <LSR-5, LSR-3, LSP-ID1, ...> where LSP-ID1 identifies the CR-LSP
depicted as originating at LER1 and transiting through LSR-3.  If that is
the ER list, there remains no issue for LSR-3 in determining the downward
LSR for LSP-ID1; LSR-3 already knows LSP-ID1.

The case where LSP-ID1 is unknown to LSR-3 would be an error, and it should
then reject the request.

--Ajith

|   Ajith Narayanan <ajithn@sg.ibm.com>