Subject: I-D ACTION:draft-ietf-ospf-cap-04.txt

From: [email-masked]
Date: Thu, 2 Dec 2004 07:36:45 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.

        Title           : Extensions to OSPF for Advertising Optional Router
                          Capabilities
        Author(s)       : A. Lindem, et al.
        Filename        : draft-ietf-ospf-cap-04.txt
        Pages           : 13
        Date            : 2004-12-1

It is useful for routers in an OSPF routing domain to know the
   capabilities of their neighbors and other routers in the OSPF routing
   domain.  This draft proposes extensions to OSPF for advertising
   optional router capabilities.  A new Router Information (RI) opaque
   LSA is proposed for this purpose.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-04.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-ospf-cap-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-ietf-ospf-cap-04.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Manikantan Srinivasan <[email-masked]>
Date: Fri, 3 Dec 2004 14:25:23 +0530

Hello

Good day to you.

I have the following doubt/question.

As per Sec 13.3 Bullet 3 (Page 150) RFC 2328,

        (3) If the new LSA was received on this interface, and it was
            received from either the Designated Router or the Backup
            Designated Router, chances are that all the neighbors have
            received the LSA already.  Therefore, examine the next
            interface.

I understand, when a DR other (Router 1) receives an LSA from a DR (Router
2), Router 1 will skip flooding back the received LSA back in the received
interface.

1) Is this a "SHOULD" condition, i.e DR Other SHOULD not flood the LSA back?
Or

2) can (DR Other) MAY flood the LSA over the received interface? If so what
should be the destination address?

3) I notice few (atleast 2) implementations (when the DUT is DR Other), the
LSA received from DR is flooded back on the received interface, as a unicast
packet addressed to BDR. Is this a valid condition/implementation? IS this
behavior a "SHOULD" condition?

Thanks in advance

With best regards
Mani

---

From: Acee Lindem <[email-masked]>
Date: Sun, 5 Dec 2004 22:37:43 -0500

>behavior a "SHOULD" condition?
Hi Mani,

I've re-read RFC 2328 and unfortunately the broadcast network flooding
is complex
and not all that clear. What I suspect is happening is that the DR-other
router is adding
the new LSA to its retransmission list and retransmitting when the timer
expires. Based on
RFC 2328, this is correct. However, section 13.5  is somewhat unclear on
whether or not the
BDR should send a delayed acknowledgement. I think that it should since
the BDR is NOT the
router that re-flooded the LSA out the receiving interface (as
determined in section 13, step 5b)  -
even though the BDR knows that the DR is reflooding it out the receiving
interface.
Consequently, the first thing I would check before suspecting two
separate DR-other
implementations is whether or not the BDR is sending the delayed
acknowledgement. If it is
not, then it is the implementation that is culpable.

Other opinions are welcome.

Thanks,
Acee

---

From: Manikantan Srinivasan <[email-masked]>
Date: Wed, 15 Dec 2004 12:13:36 +0530

Hello Acee

Thank you for your reply.

In my tests I notice the BDR generating an acknowledgement for the LS Update
sent from DR_Other Router with unicast source address of the BDR.

Since Acknowledgement is generated, can I conclude the DR other
implementation as acceptable.

Secondly will it be acceptable :) to conclude - When a DR_Other receives an
LS Update from DR or BDR, it MAY flood it back on the received interface to
DR/BDR as an unicast (addressed to DR/BDR) .

Thanks again

Best regards
mani

# -----Original Message-----
# From: Mailing List [mailto:[email-masked]] On
# Behalf Of Acee Lindem
# Sent: Monday, December 06, 2004 9:08 AM
# To: [email-masked]
# Subject: Re: Clarification related to Flooding an LSA by DR
# Other on its received interface
#
# Manikantan Srinivasan wrote:
#
# >Hello
# >
# >Good day to you.
# >
# >I have the following doubt/question.
# >
# >As per Sec 13.3 Bullet 3 (Page 150) RFC 2328,
# >
# >        (3) If the new LSA was received on this interface, and it was
# >            received from either the Designated Router or the Backup
# >            Designated Router, chances are that all the
# neighbors have
# >            received the LSA already.  Therefore, examine the next
# >            interface.
# >
# >I understand, when a DR other (Router 1) receives an LSA from a DR
# >(Router 2), Router 1 will skip flooding back the received
# LSA back in
# >the received interface.
# >
# >1) Is this a "SHOULD" condition, i.e DR Other SHOULD not
# flood the LSA back?
# >Or
# >
# >2) can (DR Other) MAY flood the LSA over the received
# interface? If so
# >what should be the destination address?
# >
# >3) I notice few (atleast 2) implementations (when the DUT is
# DR Other),
# >the LSA received from DR is flooded back on the received
# interface, as
# >a unicast packet addressed to BDR. Is this a valid
# >condition/implementation? IS this behavior a "SHOULD" condition?
# >
# >
# Hi Mani,
#
# I've re-read RFC 2328 and unfortunately the broadcast network
# flooding is complex and not all that clear. What I suspect is
# happening is that the DR-other router is adding the new LSA
# to its retransmission list and retransmitting when the timer
# expires. Based on RFC 2328, this is correct. However, section
# 13.5  is somewhat unclear on whether or not the BDR should
# send a delayed acknowledgement. I think that it should since
# the BDR is NOT the router that re-flooded the LSA out the
# receiving interface (as determined in section 13, step 5b)  -
# even though the BDR knows that the DR is reflooding it out
# the receiving interface.
# Consequently, the first thing I would check before suspecting
# two separate DR-other implementations is whether or not the
# BDR is sending the delayed acknowledgement. If it is not,
# then it is the implementation that is culpable.
#
# Other opinions are welcome.
#
# Thanks,
# Acee
#
# >Thanks in advance
# >
# >With best regards
# >Mani
# >
# >
# >

---

From: Acee Lindem <[email-masked]>
Date: Thu, 16 Dec 2004 21:31:09 -0500

Mani,
I don't think you've given enough information to conclude whether the
routers under test behave precisely as described in section 13 of RFC 2328.

     1) Where did the DR get the LSA it is flooding? Specifically, was it
          self-originated, received from another router on the broadcast 
network,
          or received on a different interface?
      2) If it was received from another router on the broadcast network,
          which one? Is it the same one that you are observing unicasting
          to the BDR?
     
Note that it would be better to preform this test without any other OSPF
links between the routers on the broadcast network.

Acee

---

From: Manikantan Srinivasan <[email-masked]>
Date: Mon, 20 Dec 2004 19:10:00 +0530

Hello Acee

Good day to you. Thanks for your reply. 

Apologize for the delay and sorry for my mails being less informative
regarding my test topology. I hope I have detailed them now :)

In an attempt to create a set of cases, that can test an OSPF implementation
conformance to OSPF RFCs, I have defined a test case for Section 13.3 Bullet
3 (Page 150) in RFC 2328

For Quick reference the section is placed below
-----------
-------------

I have a defined a test topology as shown below

############################################################################
###
# Test Setup          :
#
#
#
#                  TEE                                      DUT
#
#               __________                              __________
#
#              |  _____   |                            |          |
#
#              | |     |  |                            |          |
#
#        I2 -----| RT1 |-||I1                          |          |
#
#              | |_____| ||                            |          |
#
#              |         ||                            |          |
#
#              |         |-----------------------------|    RT2   |
#
#              | ....... ||           (I1,BB)          |          |
#
#              | :     : ||                            |          |
#
#              | : SR1 :-||                            |          |
#
#              | :.....:  |                            |          |
#
#              |__________|                            |__________|
#
#
#
#              (Router IDs)            SR1_ID  <  RT1_ID  <  (RT2_ID = 0
#
#              (Router Priorities) RT1_I1_PRY  >  SR1_I1_PRY  >  RT2_I1_PRY
#
#
#
############################################################################
###

As test steps,

1) The needful PDUs from RT1 are generated and full adjacency is established
with RT2
   (At this point I1 is the only interface enabled at RT1)

2) The needful PDUs from SR1 are generated and full adjacency is established
with RT2
   (Since RT1 and SR1 are nodes handled by my test software, I don't
explicitly enable adjacency between RT1 and SR1)

3) I2 is enabled at RT1, which enables RT1 to generate a new Router LSA. RT2
being a DROther should not propagate back the LSA on the received interface.

In my test setup, the RT2 (DUT) propagates back the received new LSA.

When I create a topology using 3 DUTs (not my test software) I notice the
DR_Other does not propagate the received LSA.

I have to spend some more time with my test steps.

I will keep you and the mailing list posted as soon as I figure out and fix
my bug :)

Thank you for your valuable time.

Best regards
Mani

# -----Original Message-----
# From: Mailing List [mailto:[email-masked]] On 
# Behalf Of Acee Lindem
# Sent: Friday, December 17, 2004 8:01 AM
# To: [email-masked]
# Subject: Re: Clarification related to Flooding an LSA by DR 
# Other on its received interface
# 
# Mani,
# I don't think you've given enough information to conclude 
# whether the routers under test behave precisely as described 
# in section 13 of RFC 2328.
# 
#      1) Where did the DR get the LSA it is flooding? 
# Specifically, was it
#           self-originated, received from another router on 
# the broadcast network,
#           or received on a different interface?
#       2) If it was received from another router on the 
# broadcast network,
#           which one? Is it the same one that you are 
# observing unicasting
#           to the BDR?
#      
# Note that it would be better to preform this test without any 
# other OSPF links between the routers on the broadcast network.
# 
# Acee
#   
# 
# 
# 
# Manikantan Srinivasan wrote:
# 
# >Hello Acee
# >
# >Thank you for your reply.
# >
# >In my tests I notice the BDR generating an acknowledgement 
# for the LS 
# >Update sent from DR_Other Router with unicast source address 
# of the BDR.
# >
# >Since Acknowledgement is generated, can I conclude the DR other 
# >implementation as acceptable.
# >
# >Secondly will it be acceptable :) to conclude - When a DR_Other 
# >receives an LS Update from DR or BDR, it MAY flood it back on the 
# >received interface to DR/BDR as an unicast (addressed to DR/BDR) .
# >
# >Thanks again
# >
# >Best regards
# >mani
# >
# >
# ># -----Original Message-----
# ># From: Mailing List [mailto:[email-masked]] On # 
# Behalf Of 
# >Acee Lindem # Sent: Monday, December 06, 2004 9:08 AM # To: 
# >[email-masked] # Subject: Re: Clarification related to 
# >Flooding an LSA by DR # Other on its received interface # # 
# Manikantan 
# >Srinivasan wrote:
# >#
# ># >Hello
# ># >
# ># >Good day to you.
# ># >
# ># >I have the following doubt/question.
# ># >
# ># >As per Sec 13.3 Bullet 3 (Page 150) RFC 2328, # >
# ># >        (3) If the new LSA was received on this 
# interface, and it was
# ># >            received from either the Designated Router or 
# the Backup
# ># >            Designated Router, chances are that all the
# ># neighbors have
# ># >            received the LSA already.  Therefore, examine the next
# ># >            interface.
# ># >
# ># >I understand, when a DR other (Router 1) receives an LSA 
# from a DR # 
# >>(Router 2), Router 1 will skip flooding back the received # 
# LSA back 
# >in # >the received interface.
# ># >
# ># >1) Is this a "SHOULD" condition, i.e DR Other SHOULD not 
# # flood the 
# >LSA back?
# ># >Or
# ># >
# ># >2) can (DR Other) MAY flood the LSA over the received # 
# interface? 
# >If so # >what should be the destination address?
# ># >
# ># >3) I notice few (atleast 2) implementations (when the DUT is # DR 
# >Other), # >the LSA received from DR is flooded back on the 
# received # 
# >interface, as # >a unicast packet addressed to BDR. Is this 
# a valid # 
# >>condition/implementation? IS this behavior a "SHOULD" condition?
# ># >
# ># >
# ># Hi Mani,
# >#
# ># I've re-read RFC 2328 and unfortunately the broadcast network # 
# >flooding is complex and not all that clear. What I suspect is # 
# >happening is that the DR-other router is adding the new LSA # to its 
# >retransmission list and retransmitting when the timer # 
# expires. Based 
# >on RFC 2328, this is correct. However, section # 13.5  is somewhat 
# >unclear on whether or not the BDR should # send a delayed 
# >acknowledgement. I think that it should since # the BDR is NOT the 
# >router that re-flooded the LSA out the # receiving interface (as 
# >determined in section 13, step 5b)  - # even though the BDR 
# knows that 
# >the DR is reflooding it out # the receiving interface.
# ># Consequently, the first thing I would check before 
# suspecting # two 
# >separate DR-other implementations is whether or not the # BDR is 
# >sending the delayed acknowledgement. If it is not, # then it is the 
# >implementation that is culpable.
# >#
# ># Other opinions are welcome.
# >#
# ># Thanks,
# ># Acee
# >#
# ># >Thanks in advance
# ># >
# ># >With best regards
# ># >Mani
# ># >
# ># >
# ># >
# >
# >  
# >