From joakim.tjernlund@transmode.se Tue Nov 17 04:21:03 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99ADF3A6A95 for ; Tue, 17 Nov 2009 04:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORVDnqm13-0G for ; Tue, 17 Nov 2009 04:21:02 -0800 (PST) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id B4F633A6A75 for ; Tue, 17 Nov 2009 04:21:01 -0800 (PST) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 6412C65000A for ; Tue, 17 Nov 2009 13:20:58 +0100 (CET) X-KeepSent: 11324EFB:CF270A94-C1257671:004298AC; type=4; name=$KeepSent To: ospf@ietf.org X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Joakim Tjernlund Date: Tue, 17 Nov 2009 13:19:47 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF964|October 21, 2009) at 2009-11-17 13:20:58 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 12:21:03 -0000 I OSPF RFC 2328, chap 10.5 one can read: o If the neighbor is both declaring itself to be Designated Router (Hello Packet's Designated Router field = Neighbor IP address) and the Backup Designated Router field in the packet is equal to 0.0.0.0 and the receiving interface is in state Waiting, the receiving interface's state machine is scheduled with the event BackupSeen. Otherwise, if the neighbor is declaring itself to be Designated Router and it had not previously, or the neighbor is not declaring itself Designated Router where it had previously, the receiving interface's state machine is scheduled with the event NeighborChange. o If the neighbor is declaring itself to be Backup Designated Router (Hello Packet's Backup Designated Router field = Neighbor IP address) and the receiving interface is in state Waiting, the receiving interface's state machine is scheduled with the event BackupSeen. Otherwise, if the neighbor is declaring itself to be Backup Designated Router and it had not previously, or the neighbor is not declaring itself Backup Designated Router where it had previously, the receiving interface's state machine is scheduled with the event NeighborChange. I wonder about the Otherwise, .. part in these two bullets: Should this be read as iff the first part before the "Otherwise, .." is false only the the otherwise part should be performed? in other words, can each bullet generate a BackupSeen AND NeighborChange or only one of them? Does the order matter, i.e is it valid to schedule two BackupSeen then two NeighborChange? Or should/must it be in order? Jocke From acee.lindem@ericsson.com Tue Nov 17 05:40:41 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73AA3A6AB7 for ; Tue, 17 Nov 2009 05:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEy0zz+dzfYw for ; Tue, 17 Nov 2009 05:40:40 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id CEC843A695A for ; Tue, 17 Nov 2009 05:40:40 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nAHBspZH014081; Tue, 17 Nov 2009 07:40:24 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 17 Nov 2009 08:36:12 -0500 From: Acee Lindem To: Joakim Tjernlund , "ospf@ietf.org" Date: Tue, 17 Nov 2009 08:36:10 -0500 Thread-Topic: [OSPF] Neighbour processing Thread-Index: AcpngHplEBJZFrzJTIaah8UMFbEr4wACjEhQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 13:40:41 -0000 Hi Joakim, If the inteface state is Waiting, then the BackupSeen event is scheduled. F= or more advanced interface states, the NeighborChange event is scheduled. Y= ou would never schedule both of them. =20 Hope this Helps, Acee=20 |-----Original Message----- |From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 |Behalf Of Joakim Tjernlund |Sent: Tuesday, November 17, 2009 7:20 AM |To: ospf@ietf.org |Subject: [OSPF] Neighbour processing | | |I OSPF RFC 2328, chap 10.5 one can read: | o If the neighbor is both declaring itself to be Designated | Router (Hello Packet's Designated Router field =3D=20 |Neighbor IP | address) and the Backup Designated Router field in the | packet is equal to 0.0.0.0 and the receiving=20 |interface is in | state Waiting, the receiving interface's state machine is | scheduled with the event BackupSeen. Otherwise, if the | neighbor is declaring itself to be Designated Router and it | had not previously, or the neighbor is not declaring itself | Designated Router where it had previously, the receiving | interface's state machine is scheduled with the event | NeighborChange. | | o If the neighbor is declaring itself to be Backup Designated | Router (Hello Packet's Backup Designated Router field =3D | Neighbor IP address) and the receiving interface=20 |is in state | Waiting, the receiving interface's state machine is | scheduled with the event BackupSeen. Otherwise, if the | neighbor is declaring itself to be Backup Designated Router | and it had not previously, or the neighbor is not declaring | itself Backup Designated Router where it had=20 |previously, the | receiving interface's state machine is scheduled with the | event NeighborChange. | |I wonder about the Otherwise, .. part in these two bullets:=20 |Should this be read as iff the first part before the=20 |"Otherwise, .." is false only the the otherwise part should be=20 |performed? in other words, can each bullet generate a=20 |BackupSeen AND NeighborChange or only one of them? | |Does the order matter, i.e is it valid to schedule two=20 |BackupSeen then two NeighborChange? |Or should/must it be in order? | | Jocke | |_______________________________________________ |OSPF mailing list |OSPF@ietf.org |https://www.ietf.org/mailman/listinfo/ospf |= From joakim.tjernlund@transmode.se Tue Nov 17 07:26:22 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F37A3A6BD1 for ; Tue, 17 Nov 2009 07:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sf2NQoAvXOPT for ; Tue, 17 Nov 2009 07:26:21 -0800 (PST) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 1BCBE3A6BCE for ; Tue, 17 Nov 2009 07:26:20 -0800 (PST) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id E201B650013; Tue, 17 Nov 2009 16:26:17 +0100 (CET) In-Reply-To: References: X-KeepSent: 79864934:3612623C-C1257671:00513DD6; type=4; name=$KeepSent To: Acee Lindem X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Joakim Tjernlund Date: Tue, 17 Nov 2009 16:23:56 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF964|October 21, 2009) at 2009-11-17 16:26:17 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "ospf@ietf.org" Subject: Re: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:26:22 -0000 Acee Lindem wrote on 17/11/2009 14:36:10: > > Hi Joakim, > If the inteface state is Waiting, then the BackupSeen event is scheduled. For > more advanced interface states, the NeighborChange event is scheduled. You > would never schedule both of them. > Hope this Helps, Yes it does, thanks. Clarification though: "never schedule both of them" is that per bullet? If the first bullet schedules either a BackupSeen or NeighborChange should the next bullet be skipped? New question same chaper(10.5) there is: When receiving an Hello Packet from a neighbor on a broadcast, Point-to-MultiPoint or NBMA network, set the neighbor structure's Neighbor ID equal to the Router ID found in the packet's OSPF header. For these network types, the neighbor structure's Router Priority field, Neighbor's Designated Router field, and Neighbor's Backup Designated Router field are also set equal to the corresponding fields found in the received Hello Packet; changes in these fields should be noted for possible use in the steps below. When receiving an Hello on a point-to-point network (but not on a virtual link) set the neighbor structure's Neighbor IP address to the packet's IP source address. I don't understand how virtual link fits. Should a Vlink be considered to be in the same group as "broadcast, Point-to-MultiPoint or NBMA network" or is it its own group? If so what should be for vlinks? Jocke > Acee > > |-----Original Message----- > |From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > |Behalf Of Joakim Tjernlund > |Sent: Tuesday, November 17, 2009 7:20 AM > |To: ospf@ietf.org > |Subject: [OSPF] Neighbour processing > | > | > |I OSPF RFC 2328, chap 10.5 one can read: > | o If the neighbor is both declaring itself to be Designated > | Router (Hello Packet's Designated Router field = > |Neighbor IP > | address) and the Backup Designated Router field in the > | packet is equal to 0.0.0.0 and the receiving > |interface is in > | state Waiting, the receiving interface's state machine is > | scheduled with the event BackupSeen. Otherwise, if the > | neighbor is declaring itself to be Designated Router and it > | had not previously, or the neighbor is not declaring itself > | Designated Router where it had previously, the receiving > | interface's state machine is scheduled with the event > | NeighborChange. > | > | o If the neighbor is declaring itself to be Backup Designated > | Router (Hello Packet's Backup Designated Router field = > | Neighbor IP address) and the receiving interface > |is in state > | Waiting, the receiving interface's state machine is > | scheduled with the event BackupSeen. Otherwise, if the > | neighbor is declaring itself to be Backup Designated Router > | and it had not previously, or the neighbor is not declaring > | itself Backup Designated Router where it had > |previously, the > | receiving interface's state machine is scheduled with the > | event NeighborChange. > | > |I wonder about the Otherwise, .. part in these two bullets: > |Should this be read as iff the first part before the > |"Otherwise, .." is false only the the otherwise part should be > |performed? in other words, can each bullet generate a > |BackupSeen AND NeighborChange or only one of them? > | > |Does the order matter, i.e is it valid to schedule two > |BackupSeen then two NeighborChange? > |Or should/must it be in order? > | > | Jocke > | > |_______________________________________________ > |OSPF mailing list > |OSPF@ietf.org > |https://www.ietf.org/mailman/listinfo/ospf > | > From acee.lindem@ericsson.com Tue Nov 17 07:40:15 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D763A6805 for ; Tue, 17 Nov 2009 07:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPM9ZRPcAXHI for ; Tue, 17 Nov 2009 07:40:14 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 452523A6857 for ; Tue, 17 Nov 2009 07:40:14 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nAHFeCUd007761; Tue, 17 Nov 2009 09:40:12 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 17 Nov 2009 10:40:11 -0500 From: Acee Lindem To: Joakim Tjernlund Date: Tue, 17 Nov 2009 10:40:10 -0500 Thread-Topic: [OSPF] Neighbour processing Thread-Index: AcpnmlH+MMM2kCS0TVWDl2zFjWL6+gAAP+3A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:40:15 -0000 Hi Joakim, =20 |-----Original Message----- |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]=20 |Sent: Tuesday, November 17, 2009 10:24 AM |To: Acee Lindem |Cc: ospf@ietf.org |Subject: RE: [OSPF] Neighbour processing | |Acee Lindem wrote on 17/11/2009 14:36:10: |> |> Hi Joakim, |> If the inteface state is Waiting, then the BackupSeen event is=20 |> scheduled. For more advanced interface states, the NeighborChange=20 |> event is scheduled. You would never schedule both of them. |> Hope this Helps, | |Yes it does, thanks. |Clarification though: "never schedule both of them" is that per bullet? |If the first bullet schedules either a BackupSeen or=20 |NeighborChange should the next bullet be skipped? Yes. Only one bullet is applicable and the conditions predicating each bull= et should be mutually exclusive.=20 | |New question same chaper(10.5) there is: | When receiving an Hello Packet from a neighbor on a broadcast, | Point-to-MultiPoint or NBMA network, set the neighbor | structure's Neighbor ID equal to the Router ID found in the | packet's OSPF header. For these network types, the neighbor | structure's Router Priority field, Neighbor's Designated Router | field, and Neighbor's Backup Designated Router field are also | set equal to the corresponding fields found in the received | Hello Packet; changes in these fields should be noted for | possible use in the steps below. When receiving an Hello on a | point-to-point network (but not on a virtual link) set the | neighbor structure's Neighbor IP address to the packet's IP | source address. | |I don't understand how virtual link fits. Should a Vlink be=20 |considered to be in the same group as "broadcast,=20 |Point-to-MultiPoint or NBMA network" or is it its own group?=20 |If so what should be for vlinks? A virtual link will have the same interface states as a point-to-point inte= rface except the Loopback state isn't applicable. Also, the InterfaceUp eve= nt only occurs when the virtual link endpoint is reachable across the trans= it area. =20 Thanks, Acee=20 | | Jocke | |> Acee |> |> |-----Original Message----- |> |From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org]=20 |On Behalf=20 |> |Of Joakim Tjernlund |> |Sent: Tuesday, November 17, 2009 7:20 AM |> |To: ospf@ietf.org |> |Subject: [OSPF] Neighbour processing |> | |> | |> |I OSPF RFC 2328, chap 10.5 one can read: |> | o If the neighbor is both declaring itself to be=20 |Designated |> | Router (Hello Packet's Designated Router field=20 |=3D Neighbor=20 |> |IP |> | address) and the Backup Designated Router field in the |> | packet is equal to 0.0.0.0 and the receiving=20 |interface is=20 |> |in |> | state Waiting, the receiving interface's state=20 |machine is |> | scheduled with the event BackupSeen. Otherwise, if the |> | neighbor is declaring itself to be Designated=20 |Router and it |> | had not previously, or the neighbor is not=20 |declaring itself |> | Designated Router where it had previously, the receiving |> | interface's state machine is scheduled with the event |> | NeighborChange. |> | |> | o If the neighbor is declaring itself to be=20 |Backup Designated |> | Router (Hello Packet's Backup Designated Router field =3D |> | Neighbor IP address) and the receiving interface is in=20 |> |state |> | Waiting, the receiving interface's state machine is |> | scheduled with the event BackupSeen. Otherwise, if the |> | neighbor is declaring itself to be Backup=20 |Designated Router |> | and it had not previously, or the neighbor is=20 |not declaring |> | itself Backup Designated Router where it had=20 |previously,=20 |> |the |> | receiving interface's state machine is=20 |scheduled with the |> | event NeighborChange. |> | |> |I wonder about the Otherwise, .. part in these two bullets: |> |Should this be read as iff the first part before the=20 |"Otherwise, .."=20 |> |is false only the the otherwise part should be performed? in other=20 |> |words, can each bullet generate a BackupSeen AND NeighborChange or=20 |> |only one of them? |> | |> |Does the order matter, i.e is it valid to schedule two BackupSeen=20 |> |then two NeighborChange? |> |Or should/must it be in order? |> | |> | Jocke |> | |> |_______________________________________________ |> |OSPF mailing list |> |OSPF@ietf.org |> |https://www.ietf.org/mailman/listinfo/ospf |> | |> | |= From joakim.tjernlund@transmode.se Tue Nov 17 07:51:25 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B1928C153 for ; Tue, 17 Nov 2009 07:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyXlB5-ZZNEK for ; Tue, 17 Nov 2009 07:51:24 -0800 (PST) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 13D9B3A6AB5 for ; Tue, 17 Nov 2009 07:51:23 -0800 (PST) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 341B0650013; Tue, 17 Nov 2009 16:51:21 +0100 (CET) In-Reply-To: References: X-KeepSent: F8155C7B:1E2C8C16-C1257671:00566C88; type=4; name=$KeepSent To: Acee Lindem X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Joakim Tjernlund Date: Tue, 17 Nov 2009 16:50:29 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF964|October 21, 2009) at 2009-11-17 16:51:21 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "ospf@ietf.org" Subject: Re: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:51:25 -0000 Acee Lindem wrote on 17/11/2009 16:40:10: > > |-----Original Message----- > |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] > |Sent: Tuesday, November 17, 2009 10:24 AM > |To: Acee Lindem > |Cc: ospf@ietf.org > |Subject: RE: [OSPF] Neighbour processing > | > |Acee Lindem wrote on 17/11/2009 14:36:10: > |> > |> Hi Joakim, > |> If the inteface state is Waiting, then the BackupSeen event is > |> scheduled. For more advanced interface states, the NeighborChange > |> event is scheduled. You would never schedule both of them. > |> Hope this Helps, > | > |Yes it does, thanks. > |Clarification though: "never schedule both of them" is that per bullet? > |If the first bullet schedules either a BackupSeen or > |NeighborChange should the next bullet be skipped? > > Yes. Only one bullet is applicable and the conditions predicating each bullet > should be mutually exclusive. Thanks, this makes sense. > > | > |New question same chaper(10.5) there is: > | When receiving an Hello Packet from a neighbor on a broadcast, > | Point-to-MultiPoint or NBMA network, set the neighbor > | structure's Neighbor ID equal to the Router ID found in the > | packet's OSPF header. For these network types, the neighbor > | structure's Router Priority field, Neighbor's Designated Router > | field, and Neighbor's Backup Designated Router field are also > | set equal to the corresponding fields found in the received > | Hello Packet; changes in these fields should be noted for > | possible use in the steps below. When receiving an Hello on a > | point-to-point network (but not on a virtual link) set the > | neighbor structure's Neighbor IP address to the packet's IP > | source address. > | > |I don't understand how virtual link fits. Should a Vlink be > |considered to be in the same group as "broadcast, > |Point-to-MultiPoint or NBMA network" or is it its own group? > |If so what should be for vlinks? > > A virtual link will have the same interface states as a point-to-point > interface except the Loopback state isn't applicable. Also, the InterfaceUp > event only occurs when the virtual link endpoint is reachable across the transit area. This seems to indicate that I should treat a Vlink the same as a p2p link above, however the paragraph explicitly say I should not so now I am confused :) Exactly what should be done to a Vlink in the above context? From acee.lindem@ericsson.com Tue Nov 17 14:54:14 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45AFD3A6A11 for ; Tue, 17 Nov 2009 14:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfuwqATrClvF for ; Tue, 17 Nov 2009 14:54:13 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 65F913A67F4 for ; Tue, 17 Nov 2009 14:54:13 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nAHMqtjd027736; Tue, 17 Nov 2009 16:54:10 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 17 Nov 2009 17:52:43 -0500 From: Acee Lindem To: Joakim Tjernlund Date: Tue, 17 Nov 2009 17:52:42 -0500 Thread-Topic: [OSPF] Neighbour processing Thread-Index: AcpnngFK9pflQiCoSHG9WD168gr7HQAOiu4A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:54:14 -0000 Hi Joakim, See inline. =20 |-----Original Message----- |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]=20 |Sent: Tuesday, November 17, 2009 10:50 AM |To: Acee Lindem |Cc: ospf@ietf.org |Subject: RE: [OSPF] Neighbour processing | |Acee Lindem wrote on 17/11/2009 16:40:10: |> |> |-----Original Message----- |> |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] |> |Sent: Tuesday, November 17, 2009 10:24 AM |> |To: Acee Lindem |> |Cc: ospf@ietf.org |> |Subject: RE: [OSPF] Neighbour processing |> | |> |Acee Lindem wrote on 17/11/2009 14:36:10: |> |> |> |> Hi Joakim, |> |> If the inteface state is Waiting, then the BackupSeen event is=20 |> |> scheduled. For more advanced interface states, the NeighborChange=20 |> |> event is scheduled. You would never schedule both of them. |> |> Hope this Helps, |> | |> |Yes it does, thanks. |> |Clarification though: "never schedule both of them" is that=20 |per bullet? |> |If the first bullet schedules either a BackupSeen or NeighborChange=20 |> |should the next bullet be skipped? |> |> Yes. Only one bullet is applicable and the conditions=20 |predicating each=20 |> bullet should be mutually exclusive. | |Thanks, this makes sense. | |> |> | |> |New question same chaper(10.5) there is: |> | When receiving an Hello Packet from a neighbor on a=20 |broadcast, |> | Point-to-MultiPoint or NBMA network, set the neighbor |> | structure's Neighbor ID equal to the Router ID found in the |> | packet's OSPF header. For these network types, the neighbor |> | structure's Router Priority field, Neighbor's=20 |Designated Router |> | field, and Neighbor's Backup Designated Router=20 |field are also |> | set equal to the corresponding fields found in the received |> | Hello Packet; changes in these fields should be noted for |> | possible use in the steps below. When receiving an=20 |Hello on a |> | point-to-point network (but not on a virtual link) set the |> | neighbor structure's Neighbor IP address to the packet's IP |> | source address. |> | |> |I don't understand how virtual link fits. Should a Vlink be=20 |> |considered to be in the same group as "broadcast,=20 |Point-to-MultiPoint=20 |> |or NBMA network" or is it its own group? |> |If so what should be for vlinks? |> |> A virtual link will have the same interface states as a=20 |point-to-point=20 |> interface except the Loopback state isn't applicable. Also, the=20 |> InterfaceUp event only occurs when the virtual link endpoint=20 |is reachable across the transit area. | |This seems to indicate that I should treat a Vlink the same as=20 |a p2p link above, however the paragraph explicitly say I=20 |should not so now I am confused :) Exactly what should be done=20 |to a Vlink in the above context? This statement only refers to the setting of the Neighbor IP address in the= RFC's reference Neighbor data structure. For virtual links, this address s= hould be as described in the second full bullet on page 159 (Section 15) in= RFC 2328.=20 Hope this helps, Acee =20 | |= From joakim.tjernlund@transmode.se Wed Nov 18 02:58:10 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C64A3A69CE for ; Wed, 18 Nov 2009 02:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usX2-CUXCnjp for ; Wed, 18 Nov 2009 02:58:09 -0800 (PST) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 3901C3A6926 for ; Wed, 18 Nov 2009 02:58:09 -0800 (PST) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id B28C8650001; Wed, 18 Nov 2009 11:58:05 +0100 (CET) In-Reply-To: References: X-KeepSent: BE307B61:E51FF413-C1257672:003AEE65; type=4; name=$KeepSent To: Acee Lindem X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Joakim Tjernlund Date: Wed, 18 Nov 2009 11:54:16 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF964|October 21, 2009) at 2009-11-18 11:58:05 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "ospf@ietf.org" Subject: Re: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 10:58:10 -0000 Acee Lindem wrote on 17/11/2009 23:52:42: > > Hi Joakim, > See inline. > > |-----Original Message----- > |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] > |Sent: Tuesday, November 17, 2009 10:50 AM > |To: Acee Lindem > |Cc: ospf@ietf.org > |Subject: RE: [OSPF] Neighbour processing > | > |Acee Lindem wrote on 17/11/2009 16:40:10: > |> > |> |-----Original Message----- > |> |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] > |> |Sent: Tuesday, November 17, 2009 10:24 AM > |> |To: Acee Lindem > |> |Cc: ospf@ietf.org > |> |Subject: RE: [OSPF] Neighbour processing > |> | > |> |Acee Lindem wrote on 17/11/2009 14:36:10: > |> |> > |> |> Hi Joakim, > |> |> If the inteface state is Waiting, then the BackupSeen event is > |> |> scheduled. For more advanced interface states, the NeighborChange > |> |> event is scheduled. You would never schedule both of them. > |> |> Hope this Helps, > |> | > |> |Yes it does, thanks. > |> |Clarification though: "never schedule both of them" is that > |per bullet? > |> |If the first bullet schedules either a BackupSeen or NeighborChange > |> |should the next bullet be skipped? > |> > |> Yes. Only one bullet is applicable and the conditions > |predicating each > |> bullet should be mutually exclusive. > | > |Thanks, this makes sense. > | > |> > |> | > |> |New question same chaper(10.5) there is: > |> | When receiving an Hello Packet from a neighbor on a > |broadcast, > |> | Point-to-MultiPoint or NBMA network, set the neighbor > |> | structure's Neighbor ID equal to the Router ID found in the > |> | packet's OSPF header. For these network types, the neighbor > |> | structure's Router Priority field, Neighbor's > |Designated Router > |> | field, and Neighbor's Backup Designated Router > |field are also > |> | set equal to the corresponding fields found in the received > |> | Hello Packet; changes in these fields should be noted for > |> | possible use in the steps below. When receiving an > |Hello on a > |> | point-to-point network (but not on a virtual link) set the > |> | neighbor structure's Neighbor IP address to the packet's IP > |> | source address. > |> | > |> |I don't understand how virtual link fits. Should a Vlink be > |> |considered to be in the same group as "broadcast, > |Point-to-MultiPoint > |> |or NBMA network" or is it its own group? > |> |If so what should be for vlinks? > |> > |> A virtual link will have the same interface states as a > |point-to-point > |> interface except the Loopback state isn't applicable. Also, the > |> InterfaceUp event only occurs when the virtual link endpoint > |is reachable across the transit area. > | > |This seems to indicate that I should treat a Vlink the same as > |a p2p link above, however the paragraph explicitly say I > |should not so now I am confused :) Exactly what should be done > |to a Vlink in the above context? > > This statement only refers to the setting of the Neighbor IP address in the > RFC's reference Neighbor data structure. For virtual links, this address Yes and that was what I wondered about. The stmt does not cover Vlinks I think so what should one do with Neighbour data when the link in question is a Vlink? Why should one only set the Neighbor IP address for a PtoP link? What should Neighbor IP address be for the other link types? > should be as described in the second full bullet on page 159 (Section 15) in RFC 2328. From acee.lindem@ericsson.com Wed Nov 18 09:36:00 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A073A697C for ; Wed, 18 Nov 2009 09:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ma7VeVj6p+w for ; Wed, 18 Nov 2009 09:35:59 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id A46CF3A6993 for ; Wed, 18 Nov 2009 09:35:59 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nAIFOabN004512; Wed, 18 Nov 2009 11:35:51 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 18 Nov 2009 12:35:42 -0500 From: Acee Lindem To: Joakim Tjernlund Date: Wed, 18 Nov 2009 12:35:40 -0500 Thread-Topic: [OSPF] Neighbour processing Thread-Index: AcpoPjcUphzjaFYqQhmwi7xe8tnE3AANgAAQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 17:36:00 -0000 Joakim - see inline.=20 |-----Original Message----- |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]=20 |Sent: Wednesday, November 18, 2009 5:54 AM |To: Acee Lindem |Cc: ospf@ietf.org |Subject: RE: [OSPF] Neighbour processing | |Acee Lindem wrote on 17/11/2009 23:52:42: |> |> Hi Joakim, |> See inline. |> |> |-----Original Message----- |> |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] |> |Sent: Tuesday, November 17, 2009 10:50 AM |> |To: Acee Lindem |> |Cc: ospf@ietf.org |> |Subject: RE: [OSPF] Neighbour processing |> | |> |Acee Lindem wrote on 17/11/2009 16:40:10: |> |> |> |> |-----Original Message----- |> |> |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] |> |> |Sent: Tuesday, November 17, 2009 10:24 AM |> |> |To: Acee Lindem |> |> |Cc: ospf@ietf.org |> |> |Subject: RE: [OSPF] Neighbour processing |> |> | |> |> |Acee Lindem wrote on=20 |17/11/2009 14:36:10: |> |> |> |> |> |> Hi Joakim, |> |> |> If the inteface state is Waiting, then the BackupSeen event is=20 |> |> |> scheduled. For more advanced interface states, the=20 |> |> |> NeighborChange event is scheduled. You would never=20 |schedule both of them. |> |> |> Hope this Helps, |> |> | |> |> |Yes it does, thanks. |> |> |Clarification though: "never schedule both of them" is that |> |per bullet? |> |> |If the first bullet schedules either a BackupSeen or=20 |> |> |NeighborChange should the next bullet be skipped? |> |> |> |> Yes. Only one bullet is applicable and the conditions |> |predicating each |> |> bullet should be mutually exclusive. |> | |> |Thanks, this makes sense. |> | |> |> |> |> | |> |> |New question same chaper(10.5) there is: |> |> | When receiving an Hello Packet from a neighbor on a |> |broadcast, |> |> | Point-to-MultiPoint or NBMA network, set the neighbor |> |> | structure's Neighbor ID equal to the Router ID=20 |found in the |> |> | packet's OSPF header. For these network types,=20 |the neighbor |> |> | structure's Router Priority field, Neighbor's |> |Designated Router |> |> | field, and Neighbor's Backup Designated Router |> |field are also |> |> | set equal to the corresponding fields found in=20 |the received |> |> | Hello Packet; changes in these fields should be noted for |> |> | possible use in the steps below. When receiving an |> |Hello on a |> |> | point-to-point network (but not on a virtual=20 |link) set the |> |> | neighbor structure's Neighbor IP address to the=20 |packet's IP |> |> | source address. |> |> | |> |> |I don't understand how virtual link fits. Should a Vlink be=20 |> |> |considered to be in the same group as "broadcast, |> |Point-to-MultiPoint |> |> |or NBMA network" or is it its own group? |> |> |If so what should be for vlinks? |> |> |> |> A virtual link will have the same interface states as a |> |point-to-point |> |> interface except the Loopback state isn't applicable. Also, the=20 |> |> InterfaceUp event only occurs when the virtual link endpoint |> |is reachable across the transit area. |> | |> |This seems to indicate that I should treat a Vlink the same=20 |as a p2p=20 |> |link above, however the paragraph explicitly say I should=20 |not so now=20 |> |I am confused :) Exactly what should be done to a Vlink in=20 |the above=20 |> |context? |> |> This statement only refers to the setting of the Neighbor IP address=20 |> in the RFC's reference Neighbor data structure. For virtual links,=20 |> this address | |Yes and that was what I wondered about. The stmt does not=20 |cover Vlinks I think so what should one do with Neighbour data=20 |when the link in question is a Vlink? For virtual links, this clearly described in section 15 of RFC 2328: o Just as the virtual link's cost and viability are determined by the routing table build process (through construction of the routing table entry for the other endpoint), so are the IP interface address for the virtual interface and the virtual neighbor's IP address. These are used when sending OSPF protocol packets over the virtual link. Note that when one (or both) of the virtual link endpoints connect to the Transit area via an unnumbered point-to-point link, it may be impossible to calculate either the virtual interface's IP address and/or the virtual neighbor's IP address, thereby causing the virtual link to fail.=20 | |Why should one only set the Neighbor IP address for a PtoP link? |What should Neighbor IP address be for the other link types? In the paragraph preceding the one in question, it clearly states that the = source for broadcast, P2MP, and NBMA networks is identified by the IP sourc= e address. It doesn't state explicitly that you should save it in the RFC's= reference neighbor data structure but this is implied.=20 At this point, an attempt is made to match the source of the Hello Packet to one of the receiving interface's neighbors. If the receiving interface connects to a broadcast, Point-to- MultiPoint or NBMA network the source is identified by the IP source address found in the Hello's IP header. If the receiving interface connects to a point-to-point link or a virtual link, the source is identified by the Router ID found in the Hello's OSPF packet header. The interface's current list of neighbors is contained in the interface's data structure. If a matching neighbor structure cannot be found, (i.e., this is the first time the neighbor has been detected), one is created. The initial state of a newly created neighbor is set to Down. Hope this Helps,=20 Acee=20 | |> should be as described in the second full bullet on page 159=20 |(Section 15) in RFC 2328. | | |= From joakim.tjernlund@transmode.se Wed Nov 18 10:48:55 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086193A6841 for ; Wed, 18 Nov 2009 10:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW+nfJg0YQrL for ; Wed, 18 Nov 2009 10:48:54 -0800 (PST) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id A370E3A6855 for ; Wed, 18 Nov 2009 10:48:53 -0800 (PST) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 36635650004; Wed, 18 Nov 2009 19:48:49 +0100 (CET) In-Reply-To: References: X-KeepSent: CCF18798:2EA2D854-C1257672:0065E517; type=4; name=$KeepSent To: Acee Lindem X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Joakim Tjernlund Date: Wed, 18 Nov 2009 19:46:09 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF964|October 21, 2009) at 2009-11-18 19:48:49 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "ospf@ietf.org" Subject: Re: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:48:55 -0000 Acee Lindem wrote on 18/11/2009 18:35:40: > > Joakim - see inline. > > |-----Original Message----- > |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] > |Sent: Wednesday, November 18, 2009 5:54 AM > |To: Acee Lindem > |Cc: ospf@ietf.org > |Subject: RE: [OSPF] Neighbour processing > | > |Acee Lindem wrote on 17/11/2009 23:52:42: > |> > |> Hi Joakim, > |> See inline. > |> > |> |-----Original Message----- > |> |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] > |> |Sent: Tuesday, November 17, 2009 10:50 AM > |> |To: Acee Lindem > |> |Cc: ospf@ietf.org > |> |Subject: RE: [OSPF] Neighbour processing > |> | > |> |Acee Lindem wrote on 17/11/2009 16:40:10: > |> |> > |> |> |-----Original Message----- > |> |> |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] > |> |> |Sent: Tuesday, November 17, 2009 10:24 AM > |> |> |To: Acee Lindem > |> |> |Cc: ospf@ietf.org > |> |> |Subject: RE: [OSPF] Neighbour processing > |> |> | > |> |> |Acee Lindem wrote on > |17/11/2009 14:36:10: > |> |> |> > |> |> |> Hi Joakim, > |> |> |> If the inteface state is Waiting, then the BackupSeen event is > |> |> |> scheduled. For more advanced interface states, the > |> |> |> NeighborChange event is scheduled. You would never > |schedule both of them. > |> |> |> Hope this Helps, > |> |> | > |> |> |Yes it does, thanks. > |> |> |Clarification though: "never schedule both of them" is that > |> |per bullet? > |> |> |If the first bullet schedules either a BackupSeen or > |> |> |NeighborChange should the next bullet be skipped? > |> |> > |> |> Yes. Only one bullet is applicable and the conditions > |> |predicating each > |> |> bullet should be mutually exclusive. > |> | > |> |Thanks, this makes sense. > |> | > |> |> > |> |> | > |> |> |New question same chaper(10.5) there is: > |> |> | When receiving an Hello Packet from a neighbor on a > |> |broadcast, > |> |> | Point-to-MultiPoint or NBMA network, set the neighbor > |> |> | structure's Neighbor ID equal to the Router ID > |found in the > |> |> | packet's OSPF header. For these network types, > |the neighbor > |> |> | structure's Router Priority field, Neighbor's > |> |Designated Router > |> |> | field, and Neighbor's Backup Designated Router > |> |field are also > |> |> | set equal to the corresponding fields found in > |the received > |> |> | Hello Packet; changes in these fields should be noted for > |> |> | possible use in the steps below. When receiving an > |> |Hello on a > |> |> | point-to-point network (but not on a virtual > |link) set the > |> |> | neighbor structure's Neighbor IP address to the > |packet's IP > |> |> | source address. > |> |> | > |> |> |I don't understand how virtual link fits. Should a Vlink be > |> |> |considered to be in the same group as "broadcast, > |> |Point-to-MultiPoint > |> |> |or NBMA network" or is it its own group? > |> |> |If so what should be for vlinks? > |> |> > |> |> A virtual link will have the same interface states as a > |> |point-to-point > |> |> interface except the Loopback state isn't applicable. Also, the > |> |> InterfaceUp event only occurs when the virtual link endpoint > |> |is reachable across the transit area. > |> | > |> |This seems to indicate that I should treat a Vlink the same > |as a p2p > |> |link above, however the paragraph explicitly say I should > |not so now > |> |I am confused :) Exactly what should be done to a Vlink in > |the above > |> |context? > |> > |> This statement only refers to the setting of the Neighbor IP address > |> in the RFC's reference Neighbor data structure. For virtual links, > |> this address > | > |Yes and that was what I wondered about. The stmt does not > |cover Vlinks I think so what should one do with Neighbour data > |when the link in question is a Vlink? > > For virtual links, this clearly described in section 15 of RFC 2328: > > o Just as the virtual link's cost and viability are determined by > the routing table build process (through construction of the > routing table entry for the other endpoint), so are the IP > interface address for the virtual interface and the virtual > neighbor's IP address. These are used when sending OSPF > protocol packets over the virtual link. Note that when one (or > both) of the virtual link endpoints connect to the Transit area > via an unnumbered point-to-point link, it may be impossible to > calculate either the virtual interface's IP address and/or the > virtual neighbor's IP address, thereby causing the virtual link > to fail. > > > | > |Why should one only set the Neighbor IP address for a PtoP link? > |What should Neighbor IP address be for the other link types? > > > In the paragraph preceding the one in question, it clearly states that the > source for broadcast, P2MP, and NBMA networks is identified by the IP source > address. It doesn't state explicitly that you should save it in the RFC's > reference neighbor data structure but this is implied. > > At this point, an attempt is made to match the source of the > Hello Packet to one of the receiving interface's neighbors. If > the receiving interface connects to a broadcast, Point-to- > MultiPoint or NBMA network the source is identified by the IP > source address found in the Hello's IP header. If the receiving > interface connects to a point-to-point link or a virtual link, > the source is identified by the Router ID found in the Hello's > OSPF packet header. The interface's current list of neighbors > is contained in the interface's data structure. If a matching > neighbor structure cannot be found, (i.e., this is the first > time the neighbor has been detected), one is created. The > initial state of a newly created neighbor is set to Down. > > Hope this Helps, > Acee OK, this helps a lot. There is just one thing I don't get: Why can you not use the packet IP src address for Vlinks? It must have one, right? When would this src address differ from the address calculated at route time? Suppose one uses packet IP src address anyway, what would the down side be? Jocke From acee.lindem@ericsson.com Wed Nov 18 11:45:20 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01563A6851 for ; Wed, 18 Nov 2009 11:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQDHDqv7JJfY for ; Wed, 18 Nov 2009 11:45:19 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 6EF4B3A67E1 for ; Wed, 18 Nov 2009 11:45:19 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nAIJjG6o012133; Wed, 18 Nov 2009 13:45:16 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 18 Nov 2009 14:45:15 -0500 From: Acee Lindem To: Joakim Tjernlund Date: Wed, 18 Nov 2009 14:45:13 -0500 Thread-Topic: [OSPF] Neighbour processing Thread-Index: Acpof/a569Ad2i1yRQ6Rq8tBSTYo1wABpjuw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 19:45:20 -0000 See inline.=20 |-----Original Message----- |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]=20 |Sent: Wednesday, November 18, 2009 1:46 PM |To: Acee Lindem |Cc: ospf@ietf.org |Subject: RE: [OSPF] Neighbour processing | |Acee Lindem wrote on 18/11/2009 18:35:40: |> |> Joakim - see inline. |> |> |-----Original Message----- |> |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] |> |Sent: Wednesday, November 18, 2009 5:54 AM |> |To: Acee Lindem |> |Cc: ospf@ietf.org |> |Subject: RE: [OSPF] Neighbour processing |> | |> |Acee Lindem wrote on 17/11/2009 23:52:42: |> |> |> |> Hi Joakim, |> |> See inline. |> |> |> |> |-----Original Message----- |> |> |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] |> |> |Sent: Tuesday, November 17, 2009 10:50 AM |> |> |To: Acee Lindem |> |> |Cc: ospf@ietf.org |> |> |Subject: RE: [OSPF] Neighbour processing |> |> | |> |> |Acee Lindem wrote on=20 |17/11/2009 16:40:10: |> |> |> |> |> |> |-----Original Message----- |> |> |> |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] |> |> |> |Sent: Tuesday, November 17, 2009 10:24 AM |> |> |> |To: Acee Lindem |> |> |> |Cc: ospf@ietf.org |> |> |> |Subject: RE: [OSPF] Neighbour processing |> |> |> | |> |> |> |Acee Lindem wrote on |> |17/11/2009 14:36:10: |> |> |> |> |> |> |> |> Hi Joakim, |> |> |> |> If the inteface state is Waiting, then the BackupSeen event=20 |> |> |> |> is scheduled. For more advanced interface states, the=20 |> |> |> |> NeighborChange event is scheduled. You would never |> |schedule both of them. |> |> |> |> Hope this Helps, |> |> |> | |> |> |> |Yes it does, thanks. |> |> |> |Clarification though: "never schedule both of them" is that |> |> |per bullet? |> |> |> |If the first bullet schedules either a BackupSeen or=20 |> |> |> |NeighborChange should the next bullet be skipped? |> |> |> |> |> |> Yes. Only one bullet is applicable and the conditions |> |> |predicating each |> |> |> bullet should be mutually exclusive. |> |> | |> |> |Thanks, this makes sense. |> |> | |> |> |> |> |> |> | |> |> |> |New question same chaper(10.5) there is: |> |> |> | When receiving an Hello Packet from a neighbor on a |> |> |broadcast, |> |> |> | Point-to-MultiPoint or NBMA network, set the neighbor |> |> |> | structure's Neighbor ID equal to the Router ID |> |found in the |> |> |> | packet's OSPF header. For these network types, |> |the neighbor |> |> |> | structure's Router Priority field, Neighbor's |> |> |Designated Router |> |> |> | field, and Neighbor's Backup Designated Router |> |> |field are also |> |> |> | set equal to the corresponding fields found in |> |the received |> |> |> | Hello Packet; changes in these fields should=20 |be noted for |> |> |> | possible use in the steps below. When receiving an |> |> |Hello on a |> |> |> | point-to-point network (but not on a virtual |> |link) set the |> |> |> | neighbor structure's Neighbor IP address to the |> |packet's IP |> |> |> | source address. |> |> |> | |> |> |> |I don't understand how virtual link fits. Should a Vlink be=20 |> |> |> |considered to be in the same group as "broadcast, |> |> |Point-to-MultiPoint |> |> |> |or NBMA network" or is it its own group? |> |> |> |If so what should be for vlinks? |> |> |> |> |> |> A virtual link will have the same interface states as a |> |> |point-to-point |> |> |> interface except the Loopback state isn't applicable.=20 |Also, the=20 |> |> |> InterfaceUp event only occurs when the virtual link endpoint |> |> |is reachable across the transit area. |> |> | |> |> |This seems to indicate that I should treat a Vlink the same |> |as a p2p |> |> |link above, however the paragraph explicitly say I should |> |not so now |> |> |I am confused :) Exactly what should be done to a Vlink in |> |the above |> |> |context? |> |> |> |> This statement only refers to the setting of the Neighbor IP=20 |> |> address in the RFC's reference Neighbor data structure.=20 |For virtual=20 |> |> links, this address |> | |> |Yes and that was what I wondered about. The stmt does not cover=20 |> |Vlinks I think so what should one do with Neighbour data when the=20 |> |link in question is a Vlink? |> |> For virtual links, this clearly described in section 15 of RFC 2328: |> |> o Just as the virtual link's cost and viability are=20 |determined by |> the routing table build process (through construction of the |> routing table entry for the other endpoint), so are the IP |> interface address for the virtual interface and the virtual |> neighbor's IP address. These are used when sending OSPF |> protocol packets over the virtual link. Note that=20 |when one (or |> both) of the virtual link endpoints connect to the=20 |Transit area |> via an unnumbered point-to-point link, it may be=20 |impossible to |> calculate either the virtual interface's IP address=20 |and/or the |> virtual neighbor's IP address, thereby causing the=20 |virtual link |> to fail. |> |> |> | |> |Why should one only set the Neighbor IP address for a PtoP link? |> |What should Neighbor IP address be for the other link types? |> |> |> In the paragraph preceding the one in question, it clearly=20 |states that=20 |> the source for broadcast, P2MP, and NBMA networks is=20 |identified by the=20 |> IP source address. It doesn't state explicitly that you=20 |should save it=20 |> in the RFC's reference neighbor data structure but this is implied. |> |> At this point, an attempt is made to match the source of the |> Hello Packet to one of the receiving interface's=20 |neighbors. If |> the receiving interface connects to a broadcast, Point-to- |> MultiPoint or NBMA network the source is identified by the IP |> source address found in the Hello's IP header. If=20 |the receiving |> interface connects to a point-to-point link or a=20 |virtual link, |> the source is identified by the Router ID found in=20 |the Hello's |> OSPF packet header. The interface's current list of=20 |neighbors |> is contained in the interface's data structure. If=20 |a matching |> neighbor structure cannot be found, (i.e., this is the first |> time the neighbor has been detected), one is created. The |> initial state of a newly created neighbor is set to Down. |> |> Hope this Helps, |> Acee | |OK, this helps a lot. There is just one thing I don't get: |Why can you not use the packet IP src address for Vlinks? |It must have one, right? I'm sure some implementations do just that :^) However, the intent of the p= rotocol is that the control packets take the same path as OSPF computes acr= oss the transit area.=20 |When would this src address differ from the address calculated=20 |at route time? When the routing across the transit area is asymetric.=20 |Suppose one uses packet IP src address anyway, what would the=20 |down side be? If the routing asymetric, there could possibly be inconsistencies between t= he data plane and control plane.=20 Hope this helps, Acee | | Jocke | |= From joakim.tjernlund@transmode.se Thu Nov 19 00:16:01 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2C63A68AF for ; Thu, 19 Nov 2009 00:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxzrHCneBQX3 for ; Thu, 19 Nov 2009 00:16:00 -0800 (PST) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 770B328C123 for ; Thu, 19 Nov 2009 00:15:59 -0800 (PST) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id EC6B9650001; Thu, 19 Nov 2009 09:15:54 +0100 (CET) In-Reply-To: References: X-KeepSent: 211AAE65:348FBD10-C1257673:002CA011; type=4; name=$KeepSent To: Acee Lindem X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Joakim Tjernlund Date: Thu, 19 Nov 2009 09:15:00 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5 HF964|October 21, 2009) at 2009-11-19 09:15:55 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "ospf@ietf.org" Subject: Re: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 08:16:01 -0000 Acee Lindem wrote on 18/11/2009 20:45:13: > See inline. > > |OK, this helps a lot. There is just one thing I don't get: > |Why can you not use the packet IP src address for Vlinks? > |It must have one, right? > > I'm sure some implementations do just that :^) However, the intent of the > protocol is that the control packets take the same path as OSPF computes > across the transit area. > > > |When would this src address differ from the address calculated > |at route time? > > When the routing across the transit area is asymetric. > > > |Suppose one uses packet IP src address anyway, what would the > |down side be? > > If the routing asymetric, there could possibly be inconsistencies between the > data plane and control plane. Is there any case where using IP src is better? I am thinking about this stmt in section 15: Note that when one (or both) of the virtual link endpoints connect to the Transit area via an unnumbered point-to-point link, it may be impossible to calculate either the virtual interface's IP address and/or the virtual neighbor's IP address, thereby causing the virtual link to fail. Would using IP src help when one fails to calculate neighbor's IP address? Jocke From acee.lindem@ericsson.com Thu Nov 19 06:02:16 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451793A6930 for ; Thu, 19 Nov 2009 06:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ-JjiqKsTMf for ; Thu, 19 Nov 2009 06:02:15 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id ABBD73A6935 for ; Thu, 19 Nov 2009 06:02:11 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nAJE26wO015996; Thu, 19 Nov 2009 08:02:06 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 19 Nov 2009 09:02:06 -0500 From: Acee Lindem To: Joakim Tjernlund Date: Thu, 19 Nov 2009 09:02:04 -0500 Thread-Topic: [OSPF] Neighbour processing Thread-Index: Acpo8Iu4HZqYL4RhQpadkf/A188BMwAMBkSQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Neighbour processing X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 14:02:16 -0000 =20 |-----Original Message----- |From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]=20 |Sent: Thursday, November 19, 2009 3:15 AM |To: Acee Lindem |Cc: ospf@ietf.org |Subject: RE: [OSPF] Neighbour processing | |Acee Lindem wrote on 18/11/2009 20:45:13: |> See inline. |> |> |OK, this helps a lot. There is just one thing I don't get: |> |Why can you not use the packet IP src address for Vlinks? |> |It must have one, right? |> |> I'm sure some implementations do just that :^) However, the=20 |intent of=20 |> the protocol is that the control packets take the same path as OSPF=20 |> computes across the transit area. |> |> |> |When would this src address differ from the address calculated at=20 |> |route time? |> |> When the routing across the transit area is asymetric. |> |> |> |Suppose one uses packet IP src address anyway, what would the down=20 |> |side be? |> |> If the routing asymetric, there could possibly be inconsistencies=20 |> between the data plane and control plane. | |Is there any case where using IP src is better? I am thinking=20 |about this stmt in section 15: | Note that when one (or | both) of the virtual link endpoints connect to the Transit area | via an unnumbered point-to-point link, it may be impossible to | calculate either the virtual interface's IP address and/or the | virtual neighbor's IP address, thereby causing the virtual link | to fail. | |Would using IP src help when one fails to calculate neighbor's=20 |IP address? I don't see a requirement for this. OSPFv2 has been deployed in the largest= networks since the mid-90s and this restriction hasn't been a concern.=20 Thanks, Acee | | Jocke | |=