Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand

From: Erblichs <[email-masked]>
Date: Wed, 28 May 2003 12:11:22 -0700

"L-Soft list server at PEACH.EASE.LSOFT.COM (1.8e)" wrote:
>
> Your  message is  being returned  to you  unprocessed because  it looks  like a
> LISTSERV command, rather than material intended for distribution to the members
> of the OSPF list. Please note that LISTSERV commands must ALWAYS be sent to the
> LISTSERV address;  if it  was indeed  a command you  were attempting  to issue,
> please send it again to [email-masked] for execution. Otherwise,
> please accept  our apologies  and try  to rewrite the  message with  a slightly
> different wording - for instance, change the first word of the message, enclose
> it  in quotation  marks, insert  a  line of  dashes  at the  beginning of  your
> message, etc.
>
>   ------------------------------------------------------------------------
>
> Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand
>      Circuits to Proposed Standard
> Date: Wed, 28 May 2003 11:52:47 -0700
> From: Erblichs <[email-masked]>
> To: [email-masked], [email-masked]
> References: <[email-masked]>
>
> Ok,
>
>         If I wanted to look into the draft itself, then I have 4 suggestions
>         labed A, B, C, and D.
>
>         A) No order is implied..
>         2.  "When application traffic starts going over the link, the
>              link is brought up, and the routers may probe each other."
>
>         The wording could be improved to specify:
>
>         After the link is brought up, a probe SHOULD be sent if ..ProbeInterval
>         has expired, and after verifying a successful probe, then application
>         data can be sent.
>
>         B) Configurable Parameters
>
>         Did I see any usage of these parameters in the draft? Shouldn't
>         some wording be used for them in the draft before the
>         appendix?
>
>         C) ...ProbeInterval
>
>         I question whether a sucessful probe that is specified in this
>         draft will guarantee that even with link that is up that application
>         traffic will be properly recieved.
>
>         Why? A probe with a minimum packet/frame size may succeed in
>         a buffer allocation where application traffic may use a MTU
>         size packet. Thus, probes should be of MTU size.
>         (this type of verification is done in IS-IS)
>
>          Thus, I would add a suggested probe size of MTU size.
>
>         D) .. ProbeInterval
>
>         I question that an demand link uptime can be shorter
>         than ..ProbeInterval. In the event that ..ProbeInterval
>         is longer than successive application transmissions, then
>         some application traffic is sent without a prior probe.
>
>         Thus, for the paranoid of us, I would expect that a probe be sent
>         before and after application data. This would allow a higher
>         assurance level of successful transmission of the application
>         data.
>
>         Thus, my suggestion is to remove the ..ProbeInterval config
>         value and suggest bracketing application data with probes.
>
>         My only issue, is if the first probe succeeded and the 2nd failed,
>         then what do you do?
>
>         Minimally, I would expect a probe before each application transmit
>         and remove the ..ProbeInterval config value.
>
>         Mitchell Erblich
>         Sr Software Engineer
>         -----------------------
>
> > >
> > > The IESG wrote:
> > > >
> > > > The IESG has received a request from the Open Shortest Path
> > > > First IGP Working Group to consider Detecting Inactive Neighbors
> > > > over OSPF Demand Circuits <draft-ietf-ospf-dc-06.txt> as a
> > > > Proposed Standard.
> > > >
> > > > The IESG plans to make a decision in the next few weeks,
> > > and solicits
> > > > final comments on this action.  Please send any comments to the
> > > > [email-masked] or [email-masked] mailing lists by 2003-6-10.
> > > >
> > > > Files can be obtained
> > > > via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt
> > >

---

From: Abhay Roy <[email-masked]>
Date: Wed, 28 May 2003 13:23:34 -0700

Mitchell,

Please see some comments inline..

> >         has expired, and after verifying a successful probe, then application

We can change MAY to a SHOULD.

The latter part implies that the data should not be sent till the
probe succeeds.. I don't think there is any need to be that
extreme. The success of probes depends on possibly retransmitting
the Update packet multiple times. And I don't see much value
(except maybe in the case, when the neighbor is indeed dead) in
dropping the data for that much time.

> >         some wording be used for them in the draft before the

We got the same comment from the AD ;) We will fix it..

> >          Thus, I would add a suggested probe size of MTU size.

OSPF uses Interface MTU during DBD exchange to make sure that
MTU's match.. If there was an MTU problem, the adjacency will not
progress to FULL state.. The probe is just an OSPF update packet,
so it has no size restrictions..

> >         and remove the ..ProbeInterval config value.

To me, the probe is just a background task to verify the viability
of the DC link to a neighbor. I don't see how data plane waiting
for control plane verification is going to help..

Regards,
-Roy-

---

From: Acee Lindem <[email-masked]>
Date: Wed, 28 May 2003 17:26:34 -0400

I agree with Abhay on all points.  Especially that we do not want
to make this a mechanism to verify MTU agreement or verify the
data plane. It is solely a mechanism to detech dead OSPF neighbors
over demand circuits.

--
Acee

---

From: Erblichs <[email-masked]>
Date: Wed, 28 May 2003 13:06:59 -0700

Sorry group,

        I forgot..

        E) If ..ProbeInterval is kept, its max value MUST not exceed
           1 hr..

        I think this follows that if we haven't heard from our
        nbr in 1 hr "he" is considered dead.

        Mitchell Erblich
        -------------------

---

From: Abhay Roy <[email-masked]>
Date: Wed, 28 May 2003 15:53:22 -0700

Mitchell,

Why it MUST not exceed 1hr? Today it's infinity, so in theory any
interval (including absurdly high ones) should be allowed.

Regards,
-Roy-

---

From: Erblichs <[email-masked]>
Date: Wed, 28 May 2003 17:01:41 -0700

Abhay Roy and Acee Lindem,

        If the mechanism is to detect only dead neighbors,
        then why wouldn't their be just a periodic probing
        of the neighbor every 45 minutes or so, without
        respect to the application data traffic?

        In addition, if a probe is recieved and responded
        to within the 1 hr time frame, then a  probe in the
        reverse direction would not be necessary until
        the next time interval.

        If on the other hand it is important to know that
        the data was successfully transmitted over the DC
        (which infers a live nbr), then a verification of a
        successful probe, in my opinion should proceed the
        transmit of the application data.

        Lastly, my MTU size packet is not to verify that the
        link-MTUs match between the two nbrs. It is to verify
        that MTU size buffers are available for the incoming
        application traffic. It is assumed that a MTU probe
        length, will be of an insignificant amount of additional
        data and processing overhead.

        Mitchell Erblich
        Sr Software Engineer
        -------------------

---

From: Abhay Roy <[email-masked]>
Date: Wed, 28 May 2003 18:34:58 -0700

Mitchell,

In case of 'always up' DC links, it does turn out to be periodic
probing. But in case of 'on demand' DC links, (if there is no data
traffic) it's of no use to bring up the link just to send probes.
So it makes sense to piggy back this event on the link coming up
event, and keep doing it periodically till the time line remains
up (due to data traffic).

Regards,
-Roy-

---

From: Erblichs <[email-masked]>
Date: Fri, 30 May 2003 00:20:10 -0700

Lets cover two stones with one throw..

        Lets try part of this again..

        In the 1793 RFC which deals with demand circuits,
        there is a 2.3 - 2) section that mentions MaxAge
        seconds, aka 3600 seconds or 1 hr.

To ensure that these LSAs are eventually
      flushed from the routing domain, and that the size of the link
      state database doesn't grow without bound, routers are required to
      flush a DoNotAge LSA if BOTH of the following conditions are met:

(2) The originator of the LSA has been unreachable (according to
    the routing calculations specified by Section 16 of [1]) for
            at least MaxAge seconds.

        If probe exceeds 1 hr then LSAs are most likely
        dropped and LSAs need to be originated. Thus, tell
        me why you would want to allow LSAs to be forced
        to be re-originated in favor of a longer probe.

        I also think you may get a dead nbr, but that is
        a different discussion point..

        Mitchell Erblich
        Sr Software Engineer
        ---------------------

Mitchell,

Regards,
-Roy-

---

From: Abhay Roy <[email-masked]>
Date: Fri, 30 May 2003 01:35:41 -0700

Mitchell,

The important point to note here is that: If the originator is
'reachable', DoNotAge LSA's can stay forever.

Regards,
-Roy-

---

From: Vivek Dubey <[email-masked]>
Date: Fri, 30 May 2003 20:48:55 +0530

Roy,
Suppose the time "Nbr probing" starts, the Ospf at the
other end is undergoing "graceful restart"...(grace period
1800 sec).....
while probing fails at this end.....
should we consdier NBR dead or there is some "safeguard"
in RFC 1793 - graceful restart - and Nbr probing draft, for such scenario.

thanks,
vivek

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of Abhay
Roy
Sent: Friday, 30 May 2003 2:06 PM
To: [email-masked]
Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
Demand

Mitchell,

Regards,
-Roy-

>         a different discussion point..

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: Acee Lindem <[email-masked]>
Date: Fri, 30 May 2003 11:28:08 -0400

Another important point is that with the standard RFC 1793 behavior
an adjacency over a DC link will stay up indefinitely. So this
is an improvement no matter what the configured interval. Since
the probing is disabled by default it is somewhat contradictory
to put an upper limit on the probe interval (i.e., the default
probing interval is infinite ;^).

One could add a statement to the ospfIfDemandNbrProbeInterval
description saying. "An interval of less than 3600 minutes is
recommended to assure the stale DoNotAge LSAs are purged from the
link state database." However, I'm not sure that this adds all
that much value and would leave it to the discretion of the
authors.

Thanks,
Acee

--
Acee

---

From: Erblichs <[email-masked]>
Date: Fri, 30 May 2003 10:22:22 -0700

Abhay,

        Actually, I would say, if the originator is
        constantly "1 hr monotonomicly reachable",
        then DNA LSAs can stay forever in the LS
        tables.

Acee Lindem,

        Interesting I always thought that
        either active (sending) or a passive
        (recieving) probing was a requirement
        for an active DC OSPF speaker.

        I classify DC nbrs that don't meet this
        criteria for 1 hr, ....
        (Sorry, Intellectural property and is
        extraneous information) :-)

        Lets work with your 2nd paragraph.

        Lets assume that the nbr can not be probed for
        over 1 hr and does not initiate a probe for
        over 1 hr. And that all its interfaces are
        DC based.

        Is it still a valid OSPF active speaker if
        the only entries in its link state tables
        are its own? Remember everything else is
        flushed.

        Why would OSPF want to allow this level of
        depricated implimentation? Doesn't it
        just consume nbr slots forever?

        Why wouldn't you want to explicitly state
        about stale LSAs? How many non OSPF
        developers realize the consequences of
        1 hr plus probes.

        Mitchell Erblich
        Sr Software Engineer
        --------------------

---

From: Alex Zinin <[email-masked]>
Date: Fri, 30 May 2003 12:12:34 -0700

Mitchell-

<hat=co-author>

Let me try to address some of your questions/concerns.

Friday, May 30, 2003, 12:20:10 AM, Erblichs wrote:
...
>         to be re-originated in favor of a longer probe.

Please note that the neighbor probing process and the LSA origination
process are not coupled. Regardless of how often I decide to probe my
neighbors, I will keep refreshing my LSAs as usual, the only
difference is in the sequence number in the LSA that will be found
in n'th and n+1'st probes.

>         then DNA LSAs can stay forever in the LS

Correct, and this is how it is supposed to work.

>         for an active DC OSPF speaker.

Not really. 1793 is based on the notion of "assumption of
reachability", which is quite important. With hello suppression
enabled, after a full adjacency has been established, we assume that
the neighbor is reachable unless we receive an explicit indication
proving this assumption wrong. 1793 mentions one possible
indication--failure of the dialer to reach the guy. The document in
question introduces another--failure of the reliable flooding
mechanism to deliver an LSA.

>         extraneous information) :-)

It is definitely possible to have implementation-specific mechanisms
that decide when to bring a DC neighbor down. Note though that your
approach may result in loss of connectivity when a multi-point dialer
(one with more than one next-hop-to-phone-num mappings) doesn't even
try to dial some remote locations due to the lack of application
traffic in that direction...

>         over 1 hr. And that all its interfaces are

We should be clear whether you mean "a nbr is not probed for over 1hr
because of the ProbeInterval" or "a nbr does not reply to probes for
over 1hr". The latter is an indication of unreachability and should
be caught by ProbeRetxLimit. The former is completely normal.

>         are its own? Remember everything else is

If all links are DC, then all received LSAs will be DNA. Provided that
the adjacencies are not brought down, I don't see how all other LSAs
could be assumed to be flushed.

However, regardless of the above point, it is absolutely normal for a
DC-connected router to not hear from its neighbor for more than one
hour, because there may be no application traffic going in its
direction and no topology changes that should be communicated to it.
So, yes, it is still a valid OSPF speaker. Keep the presumption of
reachability in mind.

>         just consume nbr slots forever?

See above about proving wrong assumption of reachability.

>         developers realize the consequences of

It is not clear to me what you are proposing to state
about stale LSAs.

Regards

Alex

---

From: Abhay Roy <[email-masked]>
Date: Fri, 30 May 2003 12:47:19 -0700

Vivek,

Generally graceful restart techniques should finish well before
the probe retries (configurable) are finished. If it does not,
then yes, we will consider the neighbor dead. But it's not a big
problem, because the adjacency will come right back up.

I guess implementations could choose to factor in the grace period
to 'delay' probes.

Regards,
-Roy-

---

From: Erblichs <[email-masked]>
Date: Fri, 30 May 2003 14:25:39 -0700

Alex, Alex,

        Just 3 Inlines..

        And all of this is to suggest that a DC router in my opinion
        SHOULD send or recieve sucessful probes to/from each DC nbr
        within each monotomically hr.

        And that a successful probe will determine that a
        data-link is not closed and data will have a decent
        probably of being accepted. This does imply that
        the probe opens the connection, just that the
        connection is open at the time of the probe.

        Mitch or Mitchell
        ---------

> Correct, and this is how it is supposed to work.

        If it is NOT, 1 hr REACHABLE, then DC DNA LSAs are
        flushed via rfc1793 2.3 - 2, in 1 hr time frame.

        This is specified specifly for DC router DNA LSAs,
        but will also occur for non-DNA LSAs, due to the
        fact of "reachability failure"., but will not
        allow updates to refresh non-DNA LSAs on
        the DC router, because..

        "..., OSPF Hellos and the refresh of OSPF routing
   information are suppressed on demand circuits, allowing the
   underlying data-link connections to be closed when not carrying
   application traffic."

        thus, Do you really think a OSPF router that only has
        its own LSAs can be a valid OSPF router?

        Justify to me that this router is doing any good after
        the link has been down for 1hr or more?

        ===============
=======================

> could be assumed to be flushed.

        By stating that all links are DC, I am trying to imply that all
        the routers on those links are DC routers originating DNA LSAs.

        If data links at one router is down for 1 hr or more, then
        reachability is not met for that 1hr time frame and via rfc1793 the
        DNA LSAs are then flushed at the ONE router that had its links
        down!

        The other DC routers will only flush the one DC router that has
        not been reachable for that 1 hr timeframe.

> So, yes, it is still a valid OSPF speaker. Keep the presumption of

        So, I would expect DNA LSAs to be flushed according to
        rfc1793 2.3 - 2!

        The presumption of reachability is that we can establish
        an open link before we send app data and that the router
        will exist on the other side. The adj exists forever..

> It is not clear to me what you are proposing to state

        That stale LSAs are the result of a down link of 1
        hr or more after origination. See above for more.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 30 May 2003 15:18:50 -0700

Mitchell-

Let me try one more time.

Starting with inlines, a bit out of order though:

[...]
>         DNA LSAs are then flushed at the ONE router that had its links

This seems to be the source of the confusion.

The fact that the data link to a guy has not gone up for 1h or more
does NOT mean that the reachability condition has not been met.

The 1hr originator reachability condition is checked through SPF, and
1793 is very explicit about it. This means that as long as you have
NOT received an evidence of unreachability of your neighbor, the
adjacency will stay up, and you (as well as other routers) will
consider the guy reachable even if the data link has never gone up.

[...]

>    underlying data-link connections to be closed when not carrying

Refreshes never come on the DC links, and don't have to.
If you have non-DNA LSAs then you have non-DC links and
the refreshes will come on them, not on the DC links.

>         its own LSAs can be a valid OSPF router?

Yes, see my previous message

>         the link has been down for 1hr or more?

ditto

>         So, I would expect DNA LSAs to be flushed according to

Nope. I think you are confused with what "Reachability" means.
See my first comment above.

>         hr or more after origination. See above for more.

This is not true, as the originator is still reachable because
the adjacency is still up.

>         connection is open at the time of the probe.

I don't think we should put this in the spec. I also believe this will
cause problems with multi-point dialers (see last paragraph in Section
2 of the document.)

On the other hand, if you believe this is useful, you can definitely
add this to your implementation and still successfully interoperate.

Alex

---

From: Vivek Dubey <[email-masked]>
Date: Sat, 31 May 2003 12:43:02 +0530

Roy,
Adjacency will be restored up again but
won't the purpose of "graceful restart" somewhat
defeated then (NBR is needlessly considered dead -
though it is trying graceful restart).

Won't it be better, if it is explicitly mentioned:
1)Generally graceful restart techniques should finish well before
  the probe retries (configurable) are finished(as you said in reply).
OR
2)If the router has received grace LSA from other end
  point.... delay "Nbr probing" till "graceful restart"
  process completes.

thanks,
vivek

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of Abhay
Roy
Sent: Saturday, 31 May 2003 1:17 AM
To: [email-masked]
Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
Demand

Vivek,

Regards,
-Roy-