Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02

From: Vishwas Manral <[email-masked]>
Date: Sun, 23 Jan 2005 02:36:00 -0800

Hi Mani,

Thanks for the suggestions. I will incorporate them. However corruption
of LS-Type could occur to a valid value, an error would still occur and
will stay till a new version of the LSA is received or if the LSA is
refreshed. 

One way to get over it is to have periodic checksum verification (I
think some implementations do this, but I am unable to find it in any
document).

Sujay,

From 2328
"The checksum of an LSA is verified in two cases:  a) when it
 is received in a Link State Update Packet and b) at times
 during the aging of the link state database"

I agree an implementation should take care that processing loops during
SPF calculation should not occur. However I think that is implementation
specific about how it should be implemented.

Do let me know if I am wrong?

Thanks,
Vishwas
-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of
Manikantan Srinivasan
Sent: Sunday, January 23, 2005 10:29 AM
To: [email-masked]
Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02

Dear Vishwas

Good day to you. Thanks for your clarification. 

# -----Original Message-----
# From: Mailing List [mailto:[email-masked]] On 
# Behalf Of Vishwas Manral
# Sent: Saturday, January 22, 2005 4:18 PM
# To: [email-masked]
# Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02
# 
# Hi Mani,
# 
# You have a good point there. One of the reasons to define the 
# behavior is to allow new types to be propagated. 
# 
# However the main motivation is that the RFC does not specify 
# the exact way of treating unknown link types which in some 
# cases can result in routing loops.
# 

I welcome and accept your suggestion to update the standard - to specify
the
exact way of treating unknown (also can be called as Invalid) link
types.
This will make the standard consistent as well, for example in the LS
Update
processing, the standard says ignore the LSA which has unknown LS
type.(Ref
Sec 13 Bullet 2 page 143 - RFC 2328)

A small typo in the current draft - Section 3 "Section A.4.3 [OSPFv3]
described the various" needs to be changed as "Section A.4.3 [OSPFv3]
describes the various". 

When I read your draft again, I could not visualize a scenario that
results
in the formation of loops, when a router ignores a received Router LSA
with
unknown/invalid LSA. Can you add an example as part of your slides
please?
It will be helpful, if it can be added to the draft too.

Suppose we have a situation as mentioned by Sujay, "the LinkStateDatabse
copy of the router LSA is corrupted during SPF(or run-time !)" I think,
the
standard's suggestion to ignore the wrong Link type information will
result
in a "Microloop"

Let us consider the following sample network.

                         +--+    1    +--+
                         |A |---------|B |
                         +--+         +--+
                          |             |
                         5|             |1
                          |             |
                         +--+   10    +--+
                         |E |---------|C |
                         +--+         +--+

A can reach E directly with metric 5. B can reach E via A with metric 6

Suppose the link type describing A-E link gets corrupted, and is ignored
during SPF calculation at A, A will determine the path to reach E is via
B
and C with a metric of 12. (Since the LSA gets corrupted, this corrupted
LSA
is visible only at A.) A sends packets destined for E to B and B sends
it to
A, resulting in a loop. This loop will exist until the next refresh of
Router LSA, where Router A has a chance to update its router LSA with
correct information.

If you feel, the above discussion is valid and is an (a security ?)
issue,
you can add it to section 5 of your draft. Feel free to ignore if this
is
invalid.

Best regards
Mani
P.S. Invalid is applicable when the link type gets corrupted.
<snip>

---

From: sujay <[email-masked]>
Date: Mon, 24 Jan 2005 11:30:05 +0530

Hi Vishwas,

Thank you very for your response.

The point I was driving to is this;

Without following the new draft 'any' Implementation would drop the
router lsa.
In case of both corrupted lsa else invalid lsa type.
 
After following the draft, it could lead to processing loops; 
Should or should not the implementation be made aware of this issue ?

Regds,
Sujay

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of
Vishwas Manral
Sent: Sunday, January 23, 2005 4:06 PM
To: [email-masked]
Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02

Hi Mani,

Sujay,

From 2328
"The checksum of an LSA is verified in two cases:  a) when it  is
received in a Link State Update Packet and b) at times  during the aging
of the link state database"

Thanks,
Vishwas
-----Original Message-----

Dear Vishwas

I welcome and accept your suggestion to update the standard - to specify
the exact way of treating unknown (also can be called as Invalid) link
types. This will make the standard consistent as well, for example in
the LS Update processing, the standard says ignore the LSA which has
unknown LS type.(Ref Sec 13 Bullet 2 page 143 - RFC 2328)

When I read your draft again, I could not visualize a scenario that
results in the formation of loops, when a router ignores a received
Router LSA with unknown/invalid LSA. Can you add an example as part of
your slides please? It will be helpful, if it can be added to the draft
too.

Suppose we have a situation as mentioned by Sujay, "the LinkStateDatabse
copy of the router LSA is corrupted during SPF(or run-time !)" I think,
the standard's suggestion to ignore the wrong Link type information will
result in a "Microloop"

                         +--+    1    +--+
                         |A |---------|B |
                         +--+         +--+
                          |             |
                         5|             |1
                          |             |
                         +--+   10    +--+
                         |E |---------|C |
                         +--+         +--+

Suppose the link type describing A-E link gets corrupted, and is ignored
during SPF calculation at A, A will determine the path to reach E is via
B and C with a metric of 12. (Since the LSA gets corrupted, this
corrupted LSA is visible only at A.) A sends packets destined for E to B
and B sends it to A, resulting in a loop. This loop will exist until the
next refresh of Router LSA, where Router A has a chance to update its
router LSA with correct information.

If you feel, the above discussion is valid and is an (a security ?)
issue, you can add it to section 5 of your draft. Feel free to ignore if
this is invalid.

Best regards
Mani
P.S. Invalid is applicable when the link type gets corrupted. <snip>