The MPLS WG Archive

[Eric Gray <ewgray2k@netscape.net>]

Leonardo,

    Let me see if I understand you.  You're asking me to review your code?

    :-)  (-:   :-)  (-:   :-)

    Try breaking this into steps and ask about the steps that aren't 
clear. So
far, you've copied a section out of the appendix (twice) and said that you
don't understand it.  Please be specific as to what it is you don't 
understand. 
Trying to make sense out of your code fragment - which is clearly not 100%
exactly congruent with the procedural steps and is out of context as well -
just gives me a huge headache.

    The reason why the procedure is not meant to be pseudo code is that
it describes what it is that the implementation is supposed to do. There is
no strict ordering or contextual mapping of the things your implementation
has to do to the way in which your implementation does them.  If you take
a broad look at how many ways there are to do the rest of the things that
any label switching implementation might do, you will quickly realize how
pointless it would be to try to cover all the ways in which this particular
set of "steps" might be done.

    As for PMpA.14 - it asks if there _is_ a hop count. For that purpose,
it is irrelevant whether it is the incremented or unincremented value. 
In any
case, I believe you understand the gist of that section.

--
Eric

Leonardo Balliache wrote:

> 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