Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type

Richard Ogier <ogier@earthlink.net> Tue, 12 April 2011 20:06 UTC

Return-Path: <ogier@earthlink.net>
X-Original-To: ospf@ietfc.amsl.com
Delivered-To: ospf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EFB85E08D5 for <ospf@ietfc.amsl.com>; Tue, 12 Apr 2011 13:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btZpXLKCGZRg for <ospf@ietfc.amsl.com>; Tue, 12 Apr 2011 13:06:55 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfc.amsl.com (Postfix) with ESMTP id E3D50E08A2 for <ospf@ietf.org>; Tue, 12 Apr 2011 13:06:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rVap+1WnySey7tsiD/0ICZBYGypvwwM3GOBkzvnpB2nvNOVknjyfZsfuafDDbKup; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [66.81.251.245] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <ogier@earthlink.net>) id 1Q9jrP-0001cL-JV; Tue, 12 Apr 2011 16:06:54 -0400
Message-ID: <4DA4B1EB.1030105@earthlink.net>
Date: Tue, 12 Apr 2011 13:11:23 -0700
From: Richard Ogier <ogier@earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
References: <FC090A1B-0A33-4CC8-B7B8-34076F16EE4D@ericsson.com> <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> <4D5474C5.1050107@juniper.net> <4D9F590A.5050008@earthlink.net> <13205C286662DE4387D9AF3AC30EF456D340CA09EE@EMBX01-WF.jnpr.net>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D340CA09EE@EMBX01-WF.jnpr.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478dd836ef1d960a2d9296bda4293fea1c9e3dc63163ab1e6cc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 66.81.251.245
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 20:06:56 -0000

Jeffrey,

I agree with your comments and was not opposing acceptance of the hybrid 
draft. In fact, I said:

>The hybrid-bcast-p2mp draft is nice because it requires only minimal
>modifications to OSPF, keeping the DR and BDR and the same 
>adjacencies.
>

My main point was to show how OSPF-MDR (RFC 5614) provides a similar 
solution when applied to single-hop networks, since the application of 
RFC 5820 to such networks had already been discussed.  In particular, 
RFC 5614 looks a lot like OSPF when applied to single-hop networks (with 
DR, BDR and associated adjacencies) whereas RFC 5820 looks quite different.

Richard


Jeffrey (Zhaohui) Zhang wrote:

>Richard,
>
>Thanks for your comments and detailed comparison.
>
>  
>
>>-----Original Message-----
>>From: Richard Ogier [mailto:ogier@earthlink.net] 
>>Sent: Friday, April 08, 2011 2:51 PM
>>To: ospf@ietf.org
>>Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
>>
>>I decided to read the posts regarding this draft (hybrid-bcast-p2mp),
>>since it is related to OSPF-MANET, and have a few comments.
>>    
>>
>
>We actually try to completely disassociated it from OSPF-MANET, and the premise is really about "true broadcast single-hop network with per-neighbor metrics".
>
>  
>
>>It was mentioned that RFC 5820 (OSPF-MANET with smart peering) solves
>>the problem of this draft, assuming that smart peering and 
>>unsynchronized
>>adjacencies are used. (E.g., Sheth's post on 2/10/2011.)
>>    
>>
>
>Sheth's comment is not really about that RFC 5820 solves the problem. Rather, a comment was made by someone else about RFC 5820's applicability here and Sheth was trying to point out what exactly need to be done if one were to use MANET to get the same result.
>
>  
>
>>I also want to point out that RFC 5614 (OSPF-MANET-MDR or OSPF-MDR),
>>which uses CDS flooding via MDRs (MANET Designated Routers), not only
>>solves the problem of this draft, but provides almost the 
>>same solution
>>as this draft when OSPF-MDR (with full-topology LSAs and biconnected
>>adjacencies) is applied to single-hop broadcast networks.
>>    
>>
>
>The final result does look similar.
>
>  
>
>>The hybrid-bcast-p2mp draft is nice because it requires only minimal
>>modifications to OSPF, keeping the DR and BDR and the same 
>>adjacencies.
>>    
>>
>
>Right - that's why we have been trying to completely disassociating it from various MANET methods.
>
>One could look at it and the alternatives the following way:
>
>- Hybrid method is a smiple and straightforward "step-up" from the well-known/understood/implemented/deployed broadcast interface
>- MANET method is a "step-down" from the MANET interface which has relatively fewer implementations/deployments, and which is understood by fewer people, and which does require some MANET-related code.
>
>Therefore, we believe the hybrid way is worth the WG effort to standardize it.
>
>We hope you were not really opposing its acceptance as a WG item, but it is not quite clear so if you could clarify that'd be great.
>
>Thanks.
>Jeffrey
>
>  
>
>>The reason that OSPF-MDR applied to single-hop broadcast networks
>>provides almost the same solution as this draft is because it
>>generalizes the concept of DRs and BDRs to MANETs, and requires
>>only 2 adjacencies for a non-DR/BDR (or non-MDR/BMDR) in a
>>single-hop broadcast network.  More on this (near) equivalence below.
>>
>>In contrast, the solution of draft-retana-ospf-manet, which applies
>>RFC 5820 with smart peering to single-hop broadcast networks, is quite
>>different, resulting in a more random selection of adjacencies,
>>which are not common to any single node such as a DR.
>>Thus, unlike the other two solutions, draft-retana-ospf-manet is
>>conceptually quite different from OSPF broadcast, since it does not
>>use the concept of the DR and BDR.
>>
>>One of the goals in the design of OSPF-MDR was to minimize changes
>>to OSPF.  Thus, instead of throwing out the DR and BDR, they were
>>generalized to multi-hop networks, and were kept essentially the
>>same in the special case of a single-hop network, for the purpose
>>of flooding and forming adjacencies.  More information on OSPF-MDR
>>can be found at www.manet-routing.org.
>>
>>Now more on the (near) equivalence between hybrid-bcast-p2mp and
>>OSPF-MDR when applied to a single-hop broadcast network.
>>In this case, the MDR selection algorithm is very similar to the
>>DR election algorithm of OSPF, and both select a single DR/MDR.
>>(There are a few minor differences that are not important to
>>this discussion.)  Also, if AdjConnectivity = 2, each node forms
>>an adjacency with the MDR and BMDR.
>>
>>The origination of router LSAs is also nearly equivalent.
>>The rules in Section 3.6 of hybrid-bcast-p2mp, which specifies
>>which Type 1 links a non-DR includes in its router LSA,
>>are similar to the corresponding rules in RFC 5614 when
>>LSAFullness = 4 (full-topology LSAs).  In that case, a router
>>includes all bidirectional (2-Way or higher) neighbors that are
>>"routable", where a neighbor is routable if SPF has calculated
>>a route to the neighbor.  Note that SPF will calculate such a route
>>to the neighbor as long as both the router itself and the neighbor
>>are fully adjacent to the MDR.
>>
>>This is slightly different from Section 3.6 of 
>>hybrid-bcast-p2mp, which
>>only requires that the router itself be fully adjacent to the DR (thus
>>relying on the requirement of SPF that the neighbor must include a
>>link back to the router in its LSA).  But both solutions achieve the
>>same goal, in a similar way, using a single DR/MDR that becomes
>>adjacent with all neighbors.
>>
>>Richard
>>
>>    
>>
>
>  
>