Subject: RE: Doubt in New FEC procedure, FEC.1

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

A and B in the previous posting are only necessary conditions,
and are not sufficient conditions.

> -----Original Message-----
> From: HariKishan [mailto:[email-masked]]
> Sent: Wednesday, September 12, 2001 5:13 PM
> To: [email-masked]
> Subject: RE: Doubt in New FEC procedure, FEC.1
>
>
> 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
>
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf
> > Of Eric Gray
> > Sent: Tuesday, September 11, 2001 7:28 AM
> > 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:
> >
> >    "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
> >
> >
> > You wrote:
> >
> > > 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
> >
>
>
>
>