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

From: Vishwas Manral <[email-masked]>
Date: Sat, 22 Jan 2005 02:47:51 -0800

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.

Acee,
I will prepare the slides and pass them onto you.

Vivek,

Thanks for reviewing the draft.
> Draft doesnt say anything about the case "All links have unknown link
> type"  in the Router Lsa. Such an information should be left for
opaque
> LSAs.
I may be off target but we are not defining extensions; we are
clarifying the behavior in case unknown link type in Router LSA is found
during SPF calculation.

> Further -
> Unknown : 1) Extension to link type
>           OR 
>          2) Junk value. 
> Now case (2) should not be allowed to sneak through to allow for case
(1).
> Better if the range of UNKNOWN is defined.
I do not see a reason that is required at all. Any unknown type is
ignored, if there is an errored type("Junk value") all the routers will
ignore the link so it does not create any issues.

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

Hello Acee, Vishwas

I understand the ability to add new link types to the router LSA is to
enable new implementations/applications to propagate new link types and
their associated additional link information. This information will be
used
(currently) by few implementation and others need to ignore. Hence the
clarification / addition to the standard.

Do we need to add new link types to the router LSA?

Can't we use the Opaque LSAs to pass the additional/new information? 

Best regards
mani

# -----Original Message-----
# From: Mailing List [mailto:[email-masked]] On 
# Behalf Of Acee Lindem
# Sent: Friday, January 21, 2005 7:50 PM
# To: [email-masked]
# Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02
# 
# Vishwas Manral wrote:
# 
# >Thanks a lot Acee.
# >
# >As this is more like a bug fix, would the category be 
# Standard Track or 
# >Informational?
# >  
# >
# I guess standards track would be better and than I'd include 
# the change in the OSPFv3 update.
# Since we are going from undefined to defined behavior we have 
# to be careful as to how the draft is ultimately worded.
# 
# Could you prepare a couple slides for the Minneapolis IETF? 
# If you are not going to be there, I could certainly present it.
# 
# >Thanks again,
# >Vishwas
# >-----Original Message-----
# >From: Mailing List [mailto:[email-masked]] On 
# Behalf Of Acee 
# >Lindem
# >Sent: Thursday, January 20, 2005 7:53 AM
# >To: [email-masked]
# >Subject: Re: draft-manral-ospf-router-lsa-unknown-type-02
# >
# >Vishwas Manral wrote:
# >
# >  
# >
# >>Hi folks,
# >>
# >> 
# >>
# >>I would want to progress the following draft to completion: -
# >>
# >>
# >>    
# >>
# >http://www.ietf.org/internet-drafts/draft-manral-ospf-router-
# lsa-unknow
# >n
# >-type-02.txt
# >  
# >
# >> 
# >>
# >>Would we want to leave it as it is, make it an individual 
# submission 
# >>to IESG, or first make a WG draft and submit then it to IESG?
# >>
# >>    
# >>
# >Any opinions on this draft?
# >
# >Speaking as a WG member I'd support it. We'll schedule 5-10 
# minutes in 
# >Minneapolis to discuss.
# >
# >Thanks,
# >Acee
# >  
# >
# >>Thanks,
# >>Vishwas
# >>
# >>    
# >>
# >
# >  
# >
#

---

From: sujay <[email-masked]>
Date: Sat, 22 Jan 2005 17:03:53 +0530

Vishwas;

As per your draft;

Let us assume;

In case if the LinkStateDatabse copy of the router LSA is corrupted
during SPF(or run-time !);

And the SPF encounters an unknown link lsa type , it proceeds with the
next link.Probably as the lsa is corrupted this could lead to recursive
processing in the SPF.

Hence maybe the draft should mention specifically to stop processing
furher  if the link count(in the header) is exhausted !

Regds,
Sujay

-----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,

Acee,

Vivek,

opaque

(1).

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

Hello Acee, Vishwas

Best regards
mani

# If you are not going to be there, I could certainly present it. # 
# >>I would want to progress the following draft to completion: - # >> #
# >>    
# >>
# >>to IESG, or first make a WG draft and submit then it to IESG? # >>

---

From: Manikantan Srinivasan <[email-masked]>
Date: Sun, 23 Jan 2005 10:28:57 +0530

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>