The MPLS-OPS Archive

[Vishal M <vishal_study@yahoo.com>]

If an LSR receives a Hello (UDP pkts), it restarts
just the Hello HoldTimer (and not the Session
holdTimer). 
However if it receives a KA or any LDP message i.e.
Mapping/Withdraw/Release (TCP pkts), it restarts the
Session HoldTimer (and not Hello holdtimer).

My question was if an LSR is busy trying to propagate
Label Mapping (of 50k Fecs) to a number of peers, it
might time out on receiving Hello or KA messages (if
the timeouts are defaulted to RFC 3036). 

Has someone seen this kind of the issue...

regards,
Vishal.

--- Carlos Patriawan <carlos@xebeo.com> wrote:
> from rfc 3036, sec 2.5.6-> when LSR rcv any LDP PDU
> messages (can be any
> msg
> other than hello/Keepalive), LSR must restart  its
> session Holdtimer, so
> in below
> case session wouldn't be terminated because these
> LDP/TCP(eg:Label
> Mapping msg )
> are treated "like" an hello/KA.
> 
> Carlos
> 
> Vishal M wrote:
> 
> > Hi Carlos,
> >
> > I agree that LDP applications could bundle
> multiple
> > LDP mappings into a single big-TCP buffer to save
> on
> > BW.
> >
> > The issue I was trying to state was of
> > routing/topology change affecting multiple LDP
> > sessions. For the duration this (routing change
> > resulting in lots of LDP messages) is happening,
> the
> > default Hello/KA holdtimers value may be a bit
> low.
> >
> > Has anyone seen this kind of behavior?
> >
> > Regards,
> > Vishal.
> >
> > --- Carlos Patriawan <carlos@xebeo.com> wrote:
> > > Vishal M wrote:
> > >
> > > > Hi,
> > > >
> > > > According to RFC 3036, LDP Hello interval is 5
> > > sec, KA
> > > > is 15 sec, Hello Holdtime is 15 sec and KA
> > > Holdtime is
> > > > 40 sec.
> > > >
> > > > If a LSR is acting in DU mode and has to deal
> with
> > > > large number of FECs (say 100k), the holdTimes
> of
> > > 15
> > > > (hello) and 40 (KA) is quite small and may
> result
> > > in
> > > > timeouts when LDP (and/or IP) modules of the
> LSR
> > > are
> > > > busy transmitting/receiving these large number
> of
> > > TCP
> > > > messages (i.e. FEC mappings).
> > > >
> > > > Hence the operator may have to tune these
> > > holdtimers
> > > > to a higher number.
> > > >
> > > > Has anyone seen this kind of issue and would
> like
> > > to
> > > > share the experiences.
> > > >
> > > > What is a *realistic* (or practical) value for
> > > > Hello/KA holdtimers (say given a
> gigabitEthernet
> > > kind
> > > > of interface) in ISP world ?
> > > >
> > > > Could someone please comment on this.
> > > >
> > > > Thanks for your time,
> > > >
> > > > Regards,
> > > > Vishal.
> > > >
> > > >
> __________________________________________________
> > > > Do you Yahoo!?
> > > > Yahoo! Mail Plus - Powerful. Affordable. Sign
> up
> > > now.
> > > > http://mailplus.yahoo.com
> > > >
> > > > -------
> > > > The MPLS-OPS Mailing List
> > > > Subscribe/Unsubscribe:
> > > http://www.mplsrc.com/mplsops.shtml
> > > > Archive:
> > > http://www.mplsrc.com/mpls-ops_archive.shtml
> > >
> > > I'm not sure if that would be an issue. First of
> all
> > > you can bundles
> > > some or all FEC
> > > in one packet so it doesn't consume lot of BW.
> > > Second, those messages
> > > usually
> > > only occured once unless you've lot of
> > > topology/routing changes.
> > >
> > >
> > > Carlos
> > >
> > >
> > >
> > >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up
> now.
> > http://mailplus.yahoo.com
> 
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe: 
> http://www.mplsrc.com/mplsops.shtml
> Archive:
http://www.mplsrc.com/mpls-ops_archive.shtml


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml