Subject: Doubt in New FEC procedure, FEC.1

From: "Venu G.S" <[email-masked]>
Date: Mon, 10 Sep 2001 13:58:54 +0530

I searched in the mail archive and could't locate any related information.
So, please clarify:

   In FEC.1:
   If DU independent control, the parameter "Unknown hop count"
   is passed in the function Prepare_Label_Mapping_Attributes even if the
   mapping from FEC next hop is already present. If the mapping is
   previously received from the fec next hop, should't this parameter
   be "StoredHopCount"?

- Thanks
Venu.G.S

---

From: Eric Gray <[email-masked]>
Date: Mon, 10 Sep 2001 10:09:52 -0400

I'm going to make a tiny leap of faith and guess that this is in reference to
RFC 3036.

 In that case, there is an ordering constraint on the way in which Label
Mappings and new FEC information must arrive.  The new FEC must be
recognized before a Label Mapping for this FEC may be accepted from
a peer LSR.

Since this is the case, when doing DUI (Downstream Unsolicited,
Independent), recognizing a new FEC results in sending Label Mappings
to potential upstream peers before receiving a label mapping from down-
stream peers (definition of Independent).  In reality, it is possible for an
implementation  to receive a corresponding Label Mapping from the next
hop for the FEC before it has actually sent Label Mappings to upstream
peers - and possible that such an implementation may collapse the two
messages to any one peer into a single one.  But that is a detail issue for
implementation, not specification.

--
Eric Gray

---

From: Abhijit Gadgil <[email-masked]>
Date: Tue, 11 Sep 2001 09:48:06 +0530 (IST)

Eric,

I have some doubt here.

EG> In that case, there is an ordering constraint on the way in which Label
EG>Mappings and new FEC information must arrive.  The new FEC must be
EG>recognized before a Label Mapping for this FEC may be accepted from
EG>a peer LSR.

How can this be guaranteed? Since the two entities involved in the
corrosponding events are independent if not uncorrelated.

-abhijit

---

From: Eric Gray <[email-masked]>
Date: Tue, 11 Sep 2001 10:27:42 -0400

Abhijit,

    The key words and tricky phrase here was 'may be accepted'.  I meant that
an LSR cannot accept a label mapping for a FEC for which it does not have a
route table entry.  In that case, the FEC would have to be known before label
mappings may be accepted for it.  On re-reading the specification, however,
the exact wording is:

   "An LSR receiving a Label Mapping message from a downstream LSR for a
   Prefix or Host Address FEC Element should not use the label for
   forwarding unless its routing table contains an entry that exactly
   matches the FEC Element."

And I had incorrectly read into this that the LSR would release the label.
This would not be the case if the LSR is using liberal retention - as is
likely to be the case if it is also using DU distribution.  This may be
verified by following the 'Receive Label Mapping' procedures in Appendix.
In the case Venu raised, the steps would be LMp.1, LMp.3, LMp.9, LMp.11,
LMp.12, LMp.13 and either LMp.32 (where the label would be released in
the conservative retention mode) or LMp.33 (where it would not be in the
liberal retention mode).

In this case, Venu would have a valid point - except that (in an arcane
sort of way) the procedures for handling a new FEC takes into account the
retention mode (see FEC.1.DU.2 and 3) and - if liberal retention is used
AND if a Label Mapping has previously been received and retained for the
next hop associated with this FEC - then the hop count for the previously
retained label mapping would be incremented and used in upstream Label
Mapping.  This can be seen from the "Prepare_Label_Mapping_Attributes"
procedure which - in this case - would include steps PMpA.1, PMpA.2, PMpA.4,
PMpA.5, PMpA.7, PMpA.9, etc.  Step PMpA.7 is where the value of the hop
count in the corresponding received Label Mapping attributes is incremented
and set in the send attributes for Label Mappings to be sent upstream.

--
Eric Gray

---

From: "Venu G.S" <[email-masked]>
Date: Wed, 12 Sep 2001 10:25:10 +0530

Eric,

    FEC.1.DUI.3 passes the value InitAttributes corresponding to the
parameter
    RAttributes in the function Prepare_Label_Mapping_Attributes.
    As given in Notes 1 of New FEC procedure, InitAttributes will not
include a known
    hop count or a path vector. So, RAttributes is not the attribute
    received from the fec next hop. So, effectively the hop count is set
    to unknown hop count even if Propagating is set to IsPropagating (which
    is possible only in the liberal retention mode) and this does not
    look correct.

- Thanks
Venu.G.S

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Tuesday, September 11, 2001 7:58 PM
To: Abhijit Gadgil
Cc: Venu G.S; [email-masked]
Subject: Re: Doubt in New FEC procedure, FEC.1

Abhijit,

    The key words and tricky phrase here was 'may be accepted'.  I meant
that
an LSR cannot accept a label mapping for a FEC for which it does not have a
route table entry.  In that case, the FEC would have to be known before
label
mappings may be accepted for it.  On re-reading the specification, however,
the exact wording is:

--
Eric Gray

---

From: Eric Gray <[email-masked]>
Date: Wed, 12 Sep 2001 11:40:03 -0400

Venu,

    I find myself in the ironic position of trying to defend a specification's
'weaknesses' that I have pointed out previously.  The irony is that I find
myself 'passing on' the same arguments that were given to me then.  I
am not representing that I agree or disagree with these arguments, but I
did find them at least somewhat mollifying at the time.

    Perhaps, after this attempt, if you are not satisfied with my restatment
of these arguments - then you should probably take this discussion up
with the RFC's authors.

    As much as procedures in the Appendix look like function calls, they
are not intended to be as precise as that.  There is - for instance - no
intention that every implementation should implement precisely these
procedures, arguments, steps and/or data structures.  The procedures
in the Appendix are not like a MIB specification that is intended to just
compile and run correctly.

    An example of how to interpret the Appendix might be to look at the
argument "InitAttributes" as a place holder in the procedure call to the
procedure "Prepare_Label_Mapping_Attributes" that is needed because
- in new FEC processing - there is no "RAttributes" to pass.  In this
case - assuming that an implementation was trying to follow the steps
in the Appendix as closely as possible - an implementor would most
likely implement a variation of "Prepare_Label_Mapping_Attributes"
that did not require this argument and used the values from RAttributes
stored previously.

    If you look at the section of the Appendix that defines RAttributes in
"Prepare_Label_Mapping_Attributes", you will see that it defines it as:

    "The attributes this LSR associates with the LSP for FEC."

Analyzing this statement in the abstract, this would mean - in this
specific case - the RAttributes recorded earlier in association with a
Label Mapping received from the next hop for this FEC.

--
Eric Gray

---

From: "HariKishan" <[email-masked]>
Date: Wed, 12 Sep 2001 17:00:37 -0700

A.1.6 talks about FECs which are learned via routing table.
If a FEC label binding was received before the FEC was
learned ( probably Route table has no matching entry for the FEC,
or is not covered by FEC learning policy which is implementation
dependent), the procedure 'Receive Label Mapping' in Appendix
would follow

LMp.1, LMp.3, LMp.9, LMp.11, stop here...

LMp.11. Determine the Next hop for FEC..

Now, the LSR should not be able to decide the next hop,
because the FEC it self is not yet learned, hence
release the binding .....

Passing Unknown hop count as last argument value for procedure
'Prepare_Label_Mapping_attribute' is used to force the SAttributes,
include a path vector of length 1 (own LSR ID)
when both the following conditions hold !!!

A) The LSR is configured for Loop Detection

B) The attributes received from a downstream peer
   have no path vector but have a non-zero hop-count.(known hopcount)

--
Kishan

> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Eric Gray
> Sent: Tuesday, September 11, 2001 7:28 AM
> To: Abhijit Gadgil

---

From: Eric Gray <[email-masked]>
Date: Thu, 13 Sep 2001 11:00:55 -0400

Kishan,

    So, is there a question you are trying to ask?

    You made the same mistake I had made earlier, but you must not
have read the text you included below (from my earlier reply to Abhijit)
where I said:

"In the case Venu raised, the steps would be LMp.1, LMp.3, LMp.9,
LMp.11, LMp.12, LMp.13 and either LMp.32 (where the label would be
released in the conservative retention mode) or LMp.33 (where it would
not be in the liberal retention mode)."

Otherwise, you would have realized that there is no step that says "if
unable to determine next hop in LMp.11, release the label mapping."
In liberal retention mode, it is not necessary to make this determination
in order to retain the label.  I admit that, at first, it didn't make sense to
me either - but there you have it.  :-)

--
Eric Gray