Subject: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt

From: "Manral, Vishwas" <[email-masked]>
Date: Fri, 11 Oct 2002 09:19:39 -0400

Hi Padma,

I am not sure why you require the new TLV. The restarting router sends the
Grace LSA, and the LSA already contains the Router-id. Why would we require
to send a TLV in the LSA for the same?

Thanks,
Vishwas

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 11 Oct 2002 08:34:31 -0700

Vishwas

Consistency.

If you dig up the archives, you will see that I
wanted to get rid of that TLV (type 3) for OSPFv2.
We need to make a decision about both v2 and v3
version of this TLV either get rid of it or translate
it for consistency.

While, it is still mandatory for v2, I feel we need to be
consistent.

Padma

---

From: Acee Lindem <[email-masked]>
Date: Fri, 11 Oct 2002 11:42:24 -0400

Hi Padma,

I think you can get rid of it. If I remember correctly,
the grace LSA TLV is solely for the identification
of neighboring routers on broadcast and NBMA network. In OSPFv3,
neighbors are always identified by router ID (RFC 2740, Section
2.2).

--
Acee

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 11 Oct 2002 09:16:00 -0700

Acee

> of neighboring routers on broadcast and NBMA network. In OSPFv3,

We can derive this information without TLV 3.
Helpers are only for previously full neighbors - which also means
that we know the id/address for each neighbor.
(rfc 2328 - section 10)

Padma

---

From: Acee Lindem <[email-masked]>
Date: Fri, 11 Oct 2002 12:46:44 -0400

> that we know the id/address for each neighbor.

Padma,

In OSPFv2, OSPF runs on a subnet. So if you have multiple subnets
on the same link (e.g., giga-ethernet), you need the local IP address
to unambiguously identify the neighbor (or you need to preserve it from
the IPv4 packet header). Some implementations don't support running
OSPF on a secondary address but RFC 2328 allows this and many
implementations support it (ours for example).

In OSPFv3, OSPF is per-link and neighbors are unambiguously identified
by router ID (RFC 2740, section 2.1). Hence, I don't think an IPv6 Interface
Address TLV is required.

Thanks,

Acee

---

From: Yasuhiro Ohara <[email-masked]>
Date: Sat, 12 Oct 2002 02:36:49 +0900

acee> In OSPFv3, OSPF is per-link and neighbors are unambiguously identified
acee> by router ID (RFC 2740, section 2.1). Hence, I don't think an
acee> IPv6 Interface Address TLV is required.

I may be very sassy for saying this without studying about the
grace-LSA, but it may not be true.

In the network configuration below, only router-ID to identify
Neighbor may be ambiguous. Because Ra have distinct "neighbor" data
structures of Rb for each link L1, L2.

    L1
  +---+
 Ra   Rb
  +---+
    L2

It depends on what "the neighbor" is. It means "the data structure to
hold adjacency status" sometimes, "The router itself" other times.
If we want to identify the former "neighbor", we'll need either
side of "Interface-ID" additionally.

I imagine that grace-LSA tries to achieve "gracefully restart
*adjacencies*", so I wondered "Is the interface-ID really unnecessary
to identify neighbor(adjacencies) ?".

Sorry if I'm missing the point of this discussion.

regards,
yasu

---

From: Acee Lindem <[email-masked]>
Date: Fri, 11 Oct 2002 14:03:37 -0400

> to identify neighbor(adjacencies) ?".

Hello Yasu,

I don't think it is necessary in this case since the the grace LSA
is scoped to either L1 or L2. Hence, if Ra is an OSPFv3 router performing
graceful restart, it will originate a separate link scoped opaque LSA for
L1 and L2.

Thanks,

--
Acee

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 11 Oct 2002 11:16:27 -0700

> the IPv4 packet header). Some implementations don't support running

IMHO, if you do not preserve it from the IPV4 source addr then you have
a slightly broken implementation ;-) (we do preservation - hence my grunt!)

BTW, the draft stipulates that one grace lsa is enough to notify the
neighboring helper even if it has multiple links to the restarting router.

Thanks

Padma

---

From: Acee Lindem <[email-masked]>
Date: Fri, 11 Oct 2002 14:34:46 -0400

> a slightly broken implementation ;-) (we do preservation - hence my grunt!)

I agree. In the case of a type 9 LSA, you really need to associated
it with the interface on which it was received in your Link State
database.

> neighboring helper even if it has multiple links to the restarting router.

I can't find this in the hitless draft right now - can you give
me pointer?

Thanks,
Acee

--
Acee

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 11 Oct 2002 11:54:15 -0700

> I can't find this in the hitless draft right now - can you give

Just realized that this has been modified in later draft
in  draft-ietf-ospf-hitless-restart-00.txt

    3.1.  Entering helper mode

 <snip>
        Note that Router Y only needs to receive a single grace-LSA from
        X, even if X and Y attach to multiple common segments.  The data
        in the first valid grace-LSA received is used to indicate the
        beginning and the end of the grace period -- all subsequent
        grace-LSAs received from X are ignored. This first grace-LSA is
        referred to below as simply "the grace-LSA from X".

        A single router is allowed to simultaneously serve as a helper
        for multiple restarting neighbors.

later it is said in 02-txt

        Note that Router Y may be helping X on some network segments,
        and not on others. However, that circumstance will probably lead
        to the premature termination of X's hitless restart, as Y will
        not continue to advertise adjacencies on the segments where it
        is not helping (see Section 2.2).
        A single router is allowed to simultaneously serve as a helper
        for multiple restarting neighbors.

Isn't that going to always lead to premature termination and hence defeat the
purpose ?
What is the idea behind of doing it per segment ?
A restarting router will affect all its links in the same way so why
differentiate it ?

Padma

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Fri, 11 Oct 2002 12:29:48 -0700

>graceful restart, it will originate a separate link scoped opaque LSA for

I think so too.  Since scope is link local and neighbor is identified.
We are ok with it.
--
Kunihiro Ishiguro

---

From: Acee Lindem <[email-masked]>
Date: Fri, 11 Oct 2002 15:40:12 -0400

<some pruning down to current discussion>

> A restarting router will affect all its links in the same way so why

I think don't think it makes sense that a full neighbor would help on

some network segments and not others. I agree this would leas to premature
termination.

I do think it simplifies things if a restarting router originates the grace LSAs
on all it's interfaces (or at least all with full neighbor
adjacencies if it a planned restart).

Thanks,
--
Acee

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 11 Oct 2002 12:50:21 -0700

> some network segments and not others. I agree this would leas to premature
Ok. we are on the same wavelength.

> adjacencies if it a planned restart).

I also agree with you .. that's what I do - the restarting router sends
grace lsa over all interfaces. But from a Helping router perspective
we should do as in 00-txt. It simplifies the helper code.
It also prevents corner cases where we might not help all adjacencies
(when we should).

Padma

---

From: Yasuhiro Ohara <[email-masked]>
Date: Sat, 12 Oct 2002 05:06:26 +0900

acee> I don't think it is necessary in this case since the the grace LSA
acee> is scoped to either L1 or L2. Hence, if Ra is an OSPFv3 router performing
acee> graceful restart, it will originate a separate link scoped opaque LSA for
acee> L1 and L2.

Thank you for your kind correction. I was wrong.
Sorry for my interruption.

regards,
yasu

---

From: Acee Lindem <[email-masked]>
Date: Fri, 11 Oct 2002 16:18:11 -0400

> Sorry for my interruption.

No need for apologies on this list - OSPF is complex enough that
discusion and questions help us all understand better.

--
Acee

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 17 Oct 2002 22:18:40 -0700

Acee

<snip>
> It also prevents corner cases where we might not help all adjacencies

I haven't heard anyone object to why the 00-txt.

If we are all clear on this,  I propose to modify the draft to have the
original text  as in -00-txt.

Padma

---

From: Acee Lindem <[email-masked]>
Date: Fri, 18 Oct 2002 01:37:57 -0400

Hi Padma,

> I haven't heard anyone object to why the 00-txt.

I will - I specifically agree with:

         Note that Router Y only needs to receive a single grace-LSA from
         X, even if X and Y attach to multiple common segments.

I don't like using an LSA with link local scope to enter/terminate
helper mode for neighbors on different interfaces. It is better if the
link local grace LSA only applies to that link.

> original text  as in -00-txt.

The draft implies one could define local policy to determine when it will or
will not act as a helper. This is where the situation arises where you can help
on some segments and not others. I don't necessarily think this is a good idea
since I don't see the requirement and, as the test in -00.txt states, it could
lead to premature termination of graceful restart. However, the scope and extent
of local policy is not explicitly specified.

--
Acee

---

From: Rajesh Varadarajan <[email-masked]>
Date: Mon, 21 Oct 2002 13:40:57 -0700

Acee, Padma,

Comments inline....

> >>>adjacencies if it a planned restart).

The above statement seems to imply (my reading) that a restarting router
can only send Grace LSA's out of some (not all) of its interfaces. The
spec however requires the router to send the grace-lsa out of all
interfaces on which it has full neigbhors. Failure to do so would always
result in its helper mode being terminated by others.

A -- B --- C --- D --+
|                    |
+--------------------+

If
1. A sent the grace LSA only to B.
2. B would help A and not change it router LSA after A's dead timer
fires.
3. However D would change its router LSA after A's dead timer fires and
flood back to B thru C.
4. When B receives the changed LSA from D, its going to terminate
helping A.

Therefore, in any network with any redundant connectivity, sending a
grace LSA on every interface is required for hitless restart to work.

The 00-txt (no longer in 02-txt) seems to be a corner-case optimization
which solves the case when the same routers are adjacent on multiple
interfaces, no other routers exist in those interfaces and one is
restarted.

> link local grace LSA only applies to that link.

Given the behavior above, I think the each neighbor should be considered
independently on a segment by segment basis.

thanks,
rajesh

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Mon, 21 Oct 2002 14:48:13 -0700

Rajesh

<snip>

>>>>>on all it's interfaces (or at least all with full neighbor

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^

>can only send Grace LSA's out of some (not all) of its interfaces. The
It doesn't imply that - clearly we send to all our neighbors.

Padma

<snip>

>>I will - I specifically agree with
>>
>>
>>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 22 Oct 2002 10:51:47 -0400

All,

I think we have a "rough concensus" that the restarting router
should NOT try to optimize flooding of grace LSAs. I've
only had one vote for this and I believe the vote was more
for flooding optimizations in general than this particular
scenario.

Padma,

I don't think it simplifies the helper code (or specification)
to apply the grace LSA to all neighbor instances of restarting
router. Here are my reasons:

   1. Conceptually, I don't think it is right to apply the link
      local grace LSA to neighbors that are not on the link.

   2. There are simply more corner cases -

       - When you receive a second grace LSA from the restarting
         router, do you update the reason and grace period for
         all neighbor instances or only ones on that segment?

       - When do exit helper mode? Is it when the first grace
         LSA is withdrawn or all the grace LSAs? I certainly don't
         think there should be disconnect between entering and
         exiting helper mode.

I do agree that it is somewhat more robust for the case where
you are adjacent with the same router on more than one link.
However, I don't see this as a real big gain. Has anyone
else implemented this draft?

Thanks,
Acee

--
Acee

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 22 Oct 2002 09:18:22 -0700

Acee,

>       local grace LSA to neighbors that are not on the link.

Let's be more precise - we are talking about adjacencies of the restarting
router.  A grace lsa from router X is received by router Y who has n
adjacencies to router X.  One grace lsa should apply to the n adjacencies.

I beg to differ. Conceptually, the grace lsa is used to signal that
a *router* is restarting to its neighbors. The only reason, why we use
a link-local lsa is that we have *no* other way to just prevent the lsa
from being flooded further by these neighbors.

I need to stress again that event being processed is a *router* restart
*not* a link restart.

Why the need to process that the router X is restarting n times ?
By analogy, if one gets 10 copies this email should one answer
it 10 times ? ;-)

>          all neighbor instances or only ones on that segment?

The second and consequent ones grace lsas are acknowledged but I do not
update the grace period/reason for the simple reason that the restarting
router (planned or unplanned) do not change those parameters on the fly.

>          think there should be disconnect between entering and

The first maxaged grace lsa will cause the helper to exit.

> else implemented this draft?

The big gain ?

I think that we expose ourselves to more timing dependencies corner cases
by considering a grace lsa per link processing on the helper side.

This unnecessary added complexity (per interface) will simply not scale.

Thanks

Padma

---

From: Acee Lindem <[email-masked]>
Date: Tue, 22 Oct 2002 14:43:15 -0400

Padma,

Let's see what others have to say. I can certainly write
write/test running code faster than these protracted E-mail
discussions but I'd like to see some real support prior to
changing the existing specification.

Also I don't agree with some of your arguments - especially
the one relating to scaling - comments inline.

> By analogy, if one gets 10 copies this email should one answer

Poor analogy. These are, in fact, different LSAs which will even
have different contents on some links.

> router (planned or unplanned) do not change those parameters on the fly.

I think if we do go this way, we should use the latest information.
Did you consider the case there is a stale link local LSA?

> by considering a grace lsa per link processing on the helper side.

Can you be more precise?

> This unnecessary added complexity (per interface) will simply not scale.

Don't buy this argument. If anything, processing helper adjacencies
incrementally as the existing draft recommends is more scalable.
Additionally, the helper only has to search through the neighbor adjacencies
on the link versus the potentially thousands associated with
the routing domain.

--
Acee