The MPLS WG Archive

[Leonardo Balliache <lbb@opalsoft.net>]

Eric,

Thanks a lot for your answer. But let me the right to insist:

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

I think I didn't explain well. Here I copy again the spec and my code. I 
understand that the spec is not a pseudo-code but it is so specific that 
I'm not sure (I'm trying yet to understand well the logic) if this 
observation is important:

The spec:

A.1.1. Receive Label Request

     ...........

       LRq.9   Perform LSR Label Distribution procedure:

             For Downstream Unsolicited Independent Control OR
             For Downstream On Demand Independent Control

                1. Has LSR previously received and retained a label map-
                   ping for FEC from Next Hop?.
                   Is so, set Propagating to IsPropagating.
                   If not, set Propagating to NotPropagating.

                2. Execute procedure Prepare_Label_Map-
                   ping_Attributes(MsgSource, FEC, RAttributes, SAt-
                   tributes, Propagating, StoredHopCount).

                3. Execute procedure Send_Label (MsgSource, FEC, SAt-
                   tributes).

                4. Is LSR egress for FEC? OR
                   Has LSR previously received and retained a label map-
                   ping for FEC from Next Hop?
                   If so, goto LRq.11.
                   If not, goto LRq.10.

             For Downstream Unsolicited Ordered Control OR
             For Downstream On Demand Ordered Control

                1. Is LSR egress for FEC? OR
                   Has LSR previously received and retained a label map-
                   ping for FEC from Next Hop?  (See Note 3.)
                   If not, goto LRq.10.

                2. Execute procedure Prepare_Label_Map-
                   ping_Attributes(MsgSource, FEC, RAttributes, SAt-
                   tributes, IsPropagating, StoredHopCount)

                3. Execute procedure Send_Label (MsgSource, FEC, SAt-
                   tributes).
                   Goto LRq.11.


The code:

// FEC.1 LSR label distribution procedure
if ( labeldiscipline() == 0 )  {         // unsolicited
    if ( labelcontrol() == 0 )  {         // independendent control
       for ( LDP2Src* itfc = firstsource(); itfc != NULL; itfc = 
nextsource() )  {   // iterate for each peer              peer = itfc->daddr();
          propagating_ = find_ldp2rec(LDP2_LabelMappingMSG, LDP2_RECEIVED, 
0, nhop, fec, -1);
          prepare_label_mapping_attributes(peer, fec, initatt, satt, 
propagating_, 0);
          send_label(peer, fec, satt);
      }
   }
   else  {                              // ordeder control
      for ( LDP2Src* itfc = firstsource(); itfc != NULL; itfc = 
nextsource() )  {  // iterate for each peer
          peer = itfc->daddr();
          if ( lsr_isegress(fec) ||
               find_ldp2rec(LDP2_LabelMappingMSG, LDP2_RECEIVED, 0, nhop, 
fec, -1) )  {
             recatt = getatt_ldp2rec(LDP2_LabelMappingMSG, LDP2_RECEIVED, 
nhop, fec, -1);
             recatt == 0 ? storedhcount = 0 : storedhcount = 
recatt->hopcount();
             // ### we have here propagating_ not being initialized above
             prepare_label_mapping_attributes(peer, fec, initatt, satt, 
propagating_, storedhcount);
             send_label(peer, fec, satt);
          }
      }
   }
}

As you see, propagating_ is set in the upper side and used in 
prepare_label_mapping_attributes but this function is used too in the lower 
side not being previously set as in the upper side.

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

RAttribute->Hop count is used also in 14 (see below). In here (14) is it 
the modified hop count too?

A.2.8. Prepare_Label_Mapping_Attributes

     .........

       PMpA.7  Increment RAttributes Hop Count and copy the resulting
               Hop Count to SAttributes.  See Note 2.  Goto PMpA.9.

       PMpA.8  Include Hop Count of unknown (0) in SAttributes.

       PMpA.9  Is Loop Detection configured on LSR?
               If not, goto PMpA.21.

       PMpA.10 Do RAttributes have a Path Vector?
               If so, goto PMpA.19.

       PMpA.11 Is LSR propagating a received Label Mapping?
               If not, goto PMpA.20.

       PMpA.12 Does LSR support merging?
               If not, goto PMpA.14.

       PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer?
               If not, goto PMpA.20.

       PMpA.14 Do RAttributes include a Hop Count?   <<<---- original hop 
count??
               If not, goto PMpA.21.

       PMpA.15 Is Hop Count in Rattributes unknown(0)?
               If so, goto PMpA.20.

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

Ok, very clear. I think I have to advance a little bit more with my code to 
understand this better.

>--
>Eric

Best regards,

Leonardo Balliache



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