The MPLS WG Archive

[Eric Gray <ewgray@GraIyMage.com>]

Leonardo,

    See below...

Leonardo Balliache wrote:

> [.. SNIP ..]
>
> My questions refer to the specification, and are:
>
> ** Q1.- Here Propagating is set in independent control but not in 
> ordered control; but it is used as parameter in ordered control below.
>
> [.. SNIP ..]


I am not sure what the question related to in all the steps included, but
the setting of control mode is a "local" phenom and the fact that the local
LSR is operating in independent control does not prevent it from getting
label requests from upstream LSRs, or label mappings from downstream
LSRs that _are_ operating in ordered control mode.

>
>
> ** Q2.- Here, in PMpA.7, Hop Count in RAttribute is incremented but it 
> is used then in PMpA.14. In this (14), Hop Count to be used is the 
> original Hop Count in RAttribute or the incremented value in PMpA.7?
>
> [ .. SNIP ..]


Hop count is incremented and then copied in PMpA.7. That means the value
left in RAttribute is the incremented value.  The wording is quite 
clear, given a
number of other ways it could have been put.

The value is next used in PMpA.18 (not 14) and it should be clear from 
context,
that we are trying to determine if the value we would send (which is 
stored in
SAttribute) is different than the value we have previously sent. 
Consequently, we
are comparing RAttribute->hopCount with prevHopCount, _because_ we know
from step PMpA.7 that the values RAttibute->hopCount=SAttribute->hopCount.

Bear in mind that it is not the intention that this appendix is supposed 
to be treated
as "pseudo-code". It may - in fact - include operations which are more 
or less
intentionally not exactly the same as might appear in a specific 
implementation.

>
> ** Q3.- I've got some problem interpreting the sentences "Install 
> label" as below:
>
>  [.. SNIP ..]
>
> As I understand MPLS we should have three tables: NHLFE, FTN and ILM.
>
> FTN contains fecs and points to NHLFE. Then, it should have the 
> information about the incoming interface to have the tuple <fec, 
> incoming_itfc).
>
> ILM contains labels and points to NHLFE too. Then it should have the 
> information about the incoming interface to have the tuple <label, 
> incoming_itfc).
>
> NHLFE should have the information about the outgoing label (if it is 
> required or the null (0) label to indicate that the last label must be 
> popped to expose the L3-header), the outgoing interface and the 
> operation to be done (push, swap, pop) to have the tuple <label, 
> outgoing_itfc, operation).
>
> Then, I'm not very sure how to interpret the sentences above ordering 
> to "install label". Could you be a little bit more explicit about this 
> information?


Understand that FTN, ILM, NHLFE, etc. are terms used in various MPLS
specifications to describe the internal logical operations as they must 
appear
externally. There are any number of ways that the actual implementation may
be done so that it looks - from outside the box - as if it is done this way.

I believe that "installing the label" is fairly clear, but to make it 
even clearer,
it means the following:

1)    if this LSR is an intermediate LSR with respect to the LSP for 
which this
    label is defined, do whatever it is in your implementation that 
corresponds
    to adding a new (or modifying an existing) ILM to point to an NHLFE that
    includes the corresponding downstream next hop, label, encaps, etc.
2)   if this LSR is an ingress LSR with respect to the LSP for which a 
label is
    being defined, do whatever it is in your implementation that corresponds
    to adding a new (or modifying an existing) FTN to point to an NHLFE that
    includes the corresponding downstream next hop, label, encaps, etc.
3)   if this LSR is an (effective) egress LSR with respect to the LSP 
for which a
    label is being defined, do whatever it is in your implementation 
that corresponds
    to either adding a new (or modifying an existing) ILM to point to an 
NHLFE
    that includes the corresponding downstream next hop, encaps, etc. - 
and no
    label - or an ILM that instructs the receiving hardware to strip the 
label and
    present the remaining packet for further processing (depending on 
whether
    the label stripped was the bottom of the label stack).

In essense, instead of saying "do whatever it is ...", the specification 
says "install
the label".  I believe this is reasonable license.

--
Eric

>
> Best regards,
>
> Leonardo Balliache
>
>
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
>
>
>
>


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls