From acee@lindem.com Thu May 5 05:34:53 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD85E0724 for ; Thu, 5 May 2011 05:34:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CobFKW86tRxs for ; Thu, 5 May 2011 05:34:53 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by ietfa.amsl.com (Postfix) with ESMTP id F2857E0721 for ; Thu, 5 May 2011 05:34:52 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=r4yJ8ACLDmU9N8MfnU6qGSvboKzSN9UnPAeXToqJDNE= c=1 sm=0 a=PRfY_ZoAvNcA:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=vBnH86IIPThSVV33hWu2Vw==:17 a=OvO2lAc5ioLa4ohNjjUA:9 a=CjuIK1q_8ugA:10 a=Mjkxkh1Wj4pHkDij:21 a=E4K4F8zVVnHUxAAo:21 a=vBnH86IIPThSVV33hWu2Vw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.177.132.147 Received: from [75.177.132.147] ([75.177.132.147:52180] helo=[192.168.1.100]) by cdptpa-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 1A/01-09483-B6992CD4; Thu, 05 May 2011 12:34:52 +0000 From: Acee Lindem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 5 May 2011 08:34:50 -0400 Message-Id: <40FF7945-5254-4F70-86EB-A617FBA866E6@lindem.com> To: OSPF List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Vishwas Manral Subject: [OSPF] OSPFv3 Authentication Trailer (AT) Draft WG Last Call X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 05 May 2011 12:34:53 -0000 All,=20 We will make these editorial changes as part of the WG last call ending = on May 9. We will not issue an 05 version of the draft until the WG last = period has ended. Please review the document by May 9th, if you intend = to do so.=20 Clarification:=20 *************** *** 308,314 **** Trailer is very similar to how it is done in case of [RFC2328]. The only difference between the OSPFv2 authentication trailer and the OSPFv3 authentication trailer is that information in addition to the ! message digest is included. Consistent with OSPFv2 cryptographic authentication [RFC2328], both OSPFv3 header checksum calculation and verification are omitted when --- 308,317 ---- Trailer is very similar to how it is done in case of [RFC2328]. The only difference between the OSPFv2 authentication trailer and the OSPFv3 authentication trailer is that information in addition to the ! message digest is included. The additional information in the = OSPFv3 ! Authentication Trailer is included in the message digest = computation ! and, therefore, protected by OSPFv3 cryptographic authentication as ! described herein. Consistent with OSPFv2 cryptographic authentication [RFC2328], both OSPFv3 header checksum calculation and verification are omitted when *************** Correction:=20 *************** *** 623,631 **** 2. First Hash ! First, the OSPFv3 packet's Authentication Trailer (which is = very ! similar to the appendage described in RFC 2328, Section D.4.3, ! Page 233, items(6)(a) and (6)(d)) is filled with the value = Apad. Then, a First-Hash, also known as the inner hash, is computed as follows: --- 623,632 ---- 2. First Hash ! First, the OSPFv3 packet's Authentication Data field in the ! Authentication Trailer (which is very similar to the appendage ! described in RFC 2328, Section D.4.3, Page 233, items(6)(a) and ! (6)(d)) is filled with the value Apad. Then, a First-Hash, also known as the inner hash, is computed as follows: *************** *** 635,643 **** Implementation Notes: Note that the First-Hash above includes the Authentication ! Trailer containing the Apad value, as well as the OSPFv3 ! packet, as per RFC 2328, Section D.4.3 and, if present, the ! LLS block[RFC5613]. The definition of Apad (above) ensures it is always the same length as the hash output. This is consistent with RFC 2328. --- 636,643 ---- Implementation Notes: Note that the First-Hash above includes the Authentication ! Trailer, as well as the OSPFv3 packet, as per RFC 2328, ! Section D.4.3 and, if present, the LLS block[RFC5613]. The definition of Apad (above) ensures it is always the same length as the hash output. This is consistent with RFC 2328. *************** Thanks, Acee From manav.bhatia@alcatel-lucent.com Sun May 8 16:50:27 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF1FE0704 for ; Sun, 8 May 2011 16:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[AWL=1.223, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBQ3LH0seaDX for ; Sun, 8 May 2011 16:50:26 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id D12DBE0698 for ; Sun, 8 May 2011 16:50:25 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p48NoLwN014114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 8 May 2011 18:50:23 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p48NoKhY008756 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 9 May 2011 05:20:21 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 9 May 2011 05:20:20 +0530 From: "Bhatia, Manav (Manav)" To: OSPF WG List Date: Mon, 9 May 2011 05:20:18 +0530 Thread-Topic: draft-ietf-ospf-security-extension-manual-keying-00 Thread-Index: AcwE8sEfVTsSmoifTBWqPGAf47jByAI56SRg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFDBA65EA@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4B460FD5-4E9D-4ECF-8D7B-24137FBF9017@ericsson.com> <4DB83A96.80104@cisco.com> In-Reply-To: <4DB83A96.80104@cisco.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [OSPF] draft-ietf-ospf-security-extension-manual-keying-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 08 May 2011 23:50:27 -0000 Hi, The WG document has been uploaded. http://tools.ietf.org/html/draft-ietf-ospf-security-extension-manual-keying= -00=20 Would be great to hear feedback from the WG! Cheers,=20 Manav > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 > Behalf Of Abhay Roy > Sent: Wednesday, April 27, 2011 9.18 PM > To: Acee Lindem > Cc: OSPF WG List; Sam Hartman > Subject: Re: [OSPF] Security Extension for OSPFv2 when using=20 > Manual Key Management - draft-bhatia-karp-ospf-ip-layer-protection-03 >=20 > There has been multiple support and no opposition for this draft. We=20 > will make this a WG draft.. >=20 > Regards, > -Abhay >=20 > On 4/11/11 10:18 AM, Acee Lindem wrote: > > There was general agreement that this should be a WG=20 > document at the meeting in Prague. Please indicate your=20 > position on making this draft a WG document with intended=20 > status Proposed Standard. > > > > Thanks, > > Acee > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > =20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > = From Alan.Davey@metaswitch.com Mon May 9 02:51:41 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B22E06C0 for ; Mon, 9 May 2011 02:51:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-zIN2ng1dhJ for ; Mon, 9 May 2011 02:51:40 -0700 (PDT) Received: from enfiets2.dataconnection.com (enfiets2.dataconnection.com [192.91.191.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD8BE0651 for ; Mon, 9 May 2011 02:51:40 -0700 (PDT) Received: from ENFIMBOX2.ad.datcon.co.uk (172.18.74.17) by enfiets2.dataconnection.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 9 May 2011 10:52:35 +0100 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX2.ad.datcon.co.uk ([172.18.74.17]) with mapi; Mon, 9 May 2011 10:51:39 +0100 From: Alan Davey To: OSPF List Date: Mon, 9 May 2011 10:51:37 +0100 Thread-Topic: [OSPF] OSPFv3 Authentication Trailer (AT) Draft WG Last Call Thread-Index: AcwLINm8SJe/TIj+S6mOP4lxGV/4CwDDBq7A Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD7207AA16D4F20A@ENFIMBOX1.ad.datcon.co.uk> References: <40FF7945-5254-4F70-86EB-A617FBA866E6@lindem.com> In-Reply-To: <40FF7945-5254-4F70-86EB-A617FBA866E6@lindem.com> 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: Vishwas Manral Subject: Re: [OSPF] OSPFv3 Authentication Trailer (AT) Draft WG Last Call X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 09 May 2011 09:51:41 -0000 Folks One minor point on the draft; it is not clear to me if the Auth Data Len fi= eld is the inclusive length of the entire authentication trailer, or just t= he length of the Authentication Data. I think that the inclusive length of the authentication trailer is preferab= le. =20 Either way, the text in section 4.1 could be made specific by changing "mes= sage digest" to "authentication trailer" or "Authentication Data". Regards Alan Davey Network Technologies Division Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 www.metaswitch.com -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ace= e Lindem Sent: 05 May 2011 13:35 To: OSPF List Cc: Vishwas Manral Subject: [OSPF] OSPFv3 Authentication Trailer (AT) Draft WG Last Call All,=20 We will make these editorial changes as part of the WG last call ending on = May 9. We will not issue an 05 version of the draft until the WG last perio= d has ended. Please review the document by May 9th, if you intend to do so.= =20 Clarification:=20 *************** *** 308,314 **** Trailer is very similar to how it is done in case of [RFC2328]. The only difference between the OSPFv2 authentication trailer and the OSPFv3 authentication trailer is that information in addition to the ! message digest is included. Consistent with OSPFv2 cryptographic authentication [RFC2328], both OSPFv3 header checksum calculation and verification are omitted when --- 308,317 ---- Trailer is very similar to how it is done in case of [RFC2328]. The only difference between the OSPFv2 authentication trailer and the OSPFv3 authentication trailer is that information in addition to the ! message digest is included. The additional information in the OSPFv3 ! Authentication Trailer is included in the message digest computation ! and, therefore, protected by OSPFv3 cryptographic authentication as ! described herein. Consistent with OSPFv2 cryptographic authentication [RFC2328], both OSPFv3 header checksum calculation and verification are omitted when *************** Correction:=20 *************** *** 623,631 **** 2. First Hash ! First, the OSPFv3 packet's Authentication Trailer (which is very ! similar to the appendage described in RFC 2328, Section D.4.3, ! Page 233, items(6)(a) and (6)(d)) is filled with the value Apad. Then, a First-Hash, also known as the inner hash, is computed as follows: --- 623,632 ---- 2. First Hash ! First, the OSPFv3 packet's Authentication Data field in the ! Authentication Trailer (which is very similar to the appendage ! described in RFC 2328, Section D.4.3, Page 233, items(6)(a) and ! (6)(d)) is filled with the value Apad. Then, a First-Hash, also known as the inner hash, is computed as follows: *************** *** 635,643 **** Implementation Notes: Note that the First-Hash above includes the Authentication ! Trailer containing the Apad value, as well as the OSPFv3 ! packet, as per RFC 2328, Section D.4.3 and, if present, the ! LLS block[RFC5613]. The definition of Apad (above) ensures it is always the same length as the hash output. This is consistent with RFC 2328. --- 636,643 ---- Implementation Notes: Note that the First-Hash above includes the Authentication ! Trailer, as well as the OSPFv3 packet, as per RFC 2328, ! Section D.4.3 and, if present, the LLS block[RFC5613]. The definition of Apad (above) ensures it is always the same length as the hash output. This is consistent with RFC 2328. *************** Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From alvaro.retana@hp.com Mon May 9 12:13:07 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DD4E06FF for ; Mon, 9 May 2011 12:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEjcjLBp9G-L for ; Mon, 9 May 2011 12:13:06 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id A0B74E06C7 for ; Mon, 9 May 2011 12:13:06 -0700 (PDT) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id AED7638832; Mon, 9 May 2011 19:13:05 +0000 (UTC) Received: from G1W1916.americas.hpqcorp.net (16.236.60.246) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 May 2011 19:12:03 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.11]) by G1W1916.americas.hpqcorp.net ([16.236.60.246]) with mapi; Mon, 9 May 2011 19:12:03 +0000 From: "Retana, Alvaro" To: "ospf@ietf.org" Date: Mon, 9 May 2011 19:12:00 +0000 Thread-Topic: Adoption of "Single Hop MANET Interface" as WG Document Thread-Index: AcwOfPk7aD+0ETYQSG2Cv1SOGwALyA== Message-ID: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_24646CE17826CF4A8DF71F9856C7E65659240FE2F3GVW1338EXAame_" MIME-Version: 1.0 Subject: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 09 May 2011 19:13:08 -0000 --_000_24646CE17826CF4A8DF71F9856C7E65659240FE2F3GVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! Following up on the WG meeting in Prague... http://tools.ietf.org/html/draft-retana-ospf-manet-single-hop A brief poll at the meeting found no objection to this update to rfc 5820. This e-mail is the formal request for adoption as a WG document. Just like= rfc 5820, the intended status is Experimental. Thoughts/comments? Thanks! Alvaro. --_000_24646CE17826CF4A8DF71F9856C7E65659240FE2F3GVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

Following = up on the WG meeting in Prague…

 

http://tools.ietf.org/html/draft-ret= ana-ospf-manet-single-hop

 = ;

A brief poll at the meeting found no object= ion to this update to rfc 5820.

&nb= sp;

This e-mail is the formal request for ado= ption as a WG document.  Just like rfc 5820, the intended status is Ex= perimental.

 

Thoughts/comments?

&n= bsp;

Thanks!

 

Alvaro.

 

= --_000_24646CE17826CF4A8DF71F9856C7E65659240FE2F3GVW1338EXAame_-- From alvaro.retana@hp.com Mon May 9 12:55:36 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540F2E0855 for ; Mon, 9 May 2011 12:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMOj1qX5TTJJ for ; Mon, 9 May 2011 12:55:35 -0700 (PDT) Received: from g5t0008.atlanta.hp.com (g5t0008.atlanta.hp.com [15.192.0.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2761BE0717 for ; Mon, 9 May 2011 12:55:34 -0700 (PDT) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0008.atlanta.hp.com (Postfix) with ESMTPS id E78DE24401; Mon, 9 May 2011 19:55:33 +0000 (UTC) Received: from G1W0396.americas.hpqcorp.net (16.236.31.9) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 May 2011 19:54:35 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.11]) by G1W0396.americas.hpqcorp.net ([16.236.31.9]) with mapi; Mon, 9 May 2011 19:54:35 +0000 From: "Retana, Alvaro" To: "ospf@ietf.org" Date: Mon, 9 May 2011 19:54:32 +0000 Thread-Topic: Adoption of "OSPF Stub Router Advertisement" (rfc3137bis) as WG Document Thread-Index: AcwOgupnOB2s2uPoSxaRnKke8KgSGg== Message-ID: <24646CE17826CF4A8DF71F9856C7E65659240FE372@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_24646CE17826CF4A8DF71F9856C7E65659240FE372GVW1338EXAame_" MIME-Version: 1.0 Cc: "azinin@cisco.com" , "dmcpherson@verisign.com" , "russwh@cisco.com" Subject: [OSPF] Adoption of "OSPF Stub Router Advertisement" (rfc3137bis) as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 09 May 2011 19:55:36 -0000 --_000_24646CE17826CF4A8DF71F9856C7E65659240FE372GVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! Following up on the WG meeting in Prague... http://tools.ietf.org/html/draft-retana-ospf-rfc3137bis We just published version -01. The only change from -00 is an update on th= e authors' contact information. This e-mail is the formal request for adoption as a WG document. Just like= rfc 3137, the intended status is Informational. Thoughts/comments? Thanks! Alvaro. --_000_24646CE17826CF4A8DF71F9856C7E65659240FE372GVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

Following = up on the WG meeting in Prague…

 

http://tools.ietf.org/html/draft-retana-os= pf-rfc3137bis

 

<= p class=3DMsoNormal>We just published version -01.  The only change fr= om -00 is an update on the authors’ contact information.

 

This e-mai= l is the formal request for adoption as a WG document.  Just like rfc = 3137, the intended status is Informational.

 

Thoughts/comments?=

 

Thanks!<= o:p>

 

Alvaro.

 

 

= --_000_24646CE17826CF4A8DF71F9856C7E65659240FE372GVW1338EXAame_-- From ogier@earthlink.net Mon May 9 13:17:27 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95822E0771 for ; Mon, 9 May 2011 13:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNvRKopBR2C8 for ; Mon, 9 May 2011 13:17:26 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC4FE0723 for ; Mon, 9 May 2011 13:17:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=c75HBH5Wyp2rS0mv2vnh1aCjJDJ05uLmlMObcD74DNKKc4DEbInp/GzNF8qYE9sJ; 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.253.129] by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QJWtO-0002jC-Q2; Mon, 09 May 2011 16:17:24 -0400 Message-ID: <4DC84C40.7030801@earthlink.net> Date: Mon, 09 May 2011 13:19:12 -0700 From: Richard Ogier 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: "Retana, Alvaro" References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> In-Reply-To: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d47802d2bbebba13fc2c44b479e3ae24999014ad0b6cc057901c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.253.129 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 09 May 2011 20:17:27 -0000 In my opinion, the hybrid-bcast-and-p2mp draft is a simple and perfect solution to this problem:
http://tools.ietf.org/id/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt

This has been discussed and some of us agree with this.  For example, Jeffrey Zhang's post dated 4/11/2011 summarizes some of the arguments.

Although both RFC 5820 (OSPF-OR) and RFC 5614 (OSPF-MDR) can be applied to single-hop broadcast networks and thus solve the same problem as the hybrid-bcast-p2mp draft, the hybrid draft is clearly the simplest solution, involving minimal changes to OSPF.

If the network is definitely a single-hop network, so that each router is one hop from all other routers, then there is no need for a MANET solution.  Otherwise, we need a MANET solution, which will also handle the special case of a single-hop network if by chance the network is single-hop (and this can be mentioned in the MANET draft).

But I would never apply a MANET solution if the network is definitely a single-hop network; I would go with the simpler solution in the hybrid draft.  For this reason, I don't think it makes sense to propose applying an OSPF-MANET extension to the case of a single-hop broadcast network.  But if someone can describe a situation where it makes sense to do this, please do so.

Richard


Retana, Alvaro wrote:

Hi!

 

Following up on the WG meeting in Prague…

 

http://tools.ietf.org/html/draft-retana-ospf-manet-single-hop

 

A brief poll at the meeting found no objection to this update to rfc 5820.

 

This e-mail is the formal request for adoption as a WG document.  Just like rfc 5820, the intended status is Experimental.

 

Thoughts/comments?

 

Thanks!

 

Alvaro.

 


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
From alvaro.retana@hp.com Mon May 9 13:59:41 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0027E0971 for ; Mon, 9 May 2011 13:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEXSkZ6cnuuM for ; Mon, 9 May 2011 13:59:39 -0700 (PDT) Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com [15.192.0.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8871EE067B for ; Mon, 9 May 2011 13:59:39 -0700 (PDT) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0009.atlanta.hp.com (Postfix) with ESMTPS id C7FBB3042C; Mon, 9 May 2011 20:59:37 +0000 (UTC) Received: from G1W1916.americas.hpqcorp.net (16.236.60.246) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 May 2011 20:58:57 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.11]) by G1W1916.americas.hpqcorp.net ([16.236.60.246]) with mapi; Mon, 9 May 2011 20:58:57 +0000 From: "Retana, Alvaro" To: Richard Ogier Date: Mon, 9 May 2011 20:58:54 +0000 Thread-Topic: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document Thread-Index: AcwOhhxbEgo7Cjq4QmCfP9SNoV9ABgAA3I9w Message-ID: <24646CE17826CF4A8DF71F9856C7E65659240FE447@GVW1338EXA.americas.hpqcorp.net> References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> <4DC84C40.7030801@earthlink.net> In-Reply-To: <4DC84C40.7030801@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_24646CE17826CF4A8DF71F9856C7E65659240FE447GVW1338EXAame_" MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 09 May 2011 20:59:42 -0000 --_000_24646CE17826CF4A8DF71F9856C7E65659240FE447GVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Richard: You're right to say that the MANET solution can handle the special case of = a single-hop broadcast network, if one was encountered. The deployment les= son that we're taking from that scenario is that it is operationally simple= r to work w/one type of interface: one neighbor discovery process, one inte= rface description model, etc...specially in cases where the ability to conf= igure and troubleshoot the network in the field is greatly reduced by both = access to the nodes as well as the potential abilities of the operators, wh= ich is the case in some of the deployments of rfc5820. IOW, in a mobile network that may include multi-hop and single-hop interfac= es, it is operationally preferred to deploy just one type of interface mode= l. Thanks! Alvaro. From: Richard Ogier [mailto:ogier@earthlink.net] Sent: Monday, May 09, 2011 4:19 PM To: Retana, Alvaro Cc: ospf@ietf.org Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document In my opinion, the hybrid-bcast-and-p2mp draft is a simple and perfect solu= tion to this problem: http://tools.ietf.org/id/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt This has been discussed and some of us agree with this. For example, Jeffr= ey Zhang's post dated 4/11/2011 summarizes some of the arguments. Although both RFC 5820 (OSPF-OR) and RFC 5614 (OSPF-MDR) can be applied to = single-hop broadcast networks and thus solve the same problem as the hybrid= -bcast-p2mp draft, the hybrid draft is clearly the simplest solution, invol= ving minimal changes to OSPF. If the network is definitely a single-hop network, so that each router is o= ne hop from all other routers, then there is no need for a MANET solution. = Otherwise, we need a MANET solution, which will also handle the special ca= se of a single-hop network if by chance the network is single-hop (and this= can be mentioned in the MANET draft). But I would never apply a MANET solution if the network is definitely a sin= gle-hop network; I would go with the simpler solution in the hybrid draft. = For this reason, I don't think it makes sense to propose applying an OSPF-= MANET extension to the case of a single-hop broadcast network. But if some= one can describe a situation where it makes sense to do this, please do so. Richard Retana, Alvaro wrote: Hi! Following up on the WG meeting in Prague... http://tools.ietf.org/html/draft-retana-ospf-manet-single-hop A brief poll at the meeting found no objection to this update to rfc 5820. This e-mail is the formal request for adoption as a WG document. Just like= rfc 5820, the intended status is Experimental. Thoughts/comments? Thanks! Alvaro. ________________________________ _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_24646CE17826CF4A8DF71F9856C7E65659240FE447GVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Richard:

 

You’re right to say that the = MANET solution can handle the special case of a single-hop broadcast networ= k, if one was encountered.  The deployment lesson that we’re tak= ing from that scenario is that it is operationally simpler to work w/one ty= pe of interface: one neighbor discovery process, one interface description = model, etc…specially in cases where the ability to configure and trou= bleshoot the network in the field is greatly reduced by both access to the = nodes as well as the potential abilities of the operators, which is the cas= e in some of the deployments of rfc5820.

 

IOW, in a mobile network that ma= y include multi-hop and single-hop interfaces, it is operationally preferre= d to deploy just one type of interface model.

 

Thanks!

 

Alvaro.<= /span>

 

From: Richard Ogier [mailto:ogier@earthlink.net]
Sent:<= /b> Monday, May 09, 2011 4:19 PM
To: Retana, Alvaro
Cc:= ospf@ietf.org
Subject: Re: [OSPF] Adoption of "Single Hop M= ANET Interface" as WG Document

 

In my opinion, the= hybrid-bcast-and-p2mp draft is a simple and perfect solution to this probl= em:
http://tools.ietf.org/id/draft-nsheth-ospf-hybrid-bcast-and= -p2mp-01.txt

This has been discussed and some of us agree with t= his.  For example, Jeffrey Zhang's post dated 4/11/2011 summarizes som= e of the arguments.

Although both RFC 5820 (OSPF-OR) and RFC 5614 (O= SPF-MDR) can be applied to single-hop broadcast networks and thus solve the= same problem as the hybrid-bcast-p2mp draft, the hybrid draft is clearly t= he simplest solution, involving minimal changes to OSPF.

If the netw= ork is definitely a single-hop network, so that each router is one hop from= all other routers, then there is no need for a MANET solution.  Other= wise, we need a MANET solution, which will also handle the special case of = a single-hop network if by chance the network is single-hop (and this can b= e mentioned in the MANET draft).

But I would never apply a MANET sol= ution if the network is definitely a single-hop network; I would go with th= e simpler solution in the hybrid draft.  For this reason, I don't thin= k it makes sense to propose applying an OSPF-MANET extension to the case of= a single-hop broadcast network.  But if someone can describe a situat= ion where it makes sense to do this, please do so.

Richard

Retana, Alvaro wrote:

Hi!<= /p>

 

Following= up on the WG meeting in Prague…

&= nbsp;

http://tools.ietf.org/html/draft-re= tana-ospf-manet-single-hop

 

A brief poll at the meeting found no objec= tion to this update to rfc 5820.

 <= o:p>

This e-mail is the formal request for ad= option as a WG document.  Just like rfc 5820, the intended status is E= xperimental.

 

Thoughts/comments?

 =

Thanks!

 

Alvaro.

 

 
 
______________________________________________=
_
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinf=
o/ospf
 
= = --_000_24646CE17826CF4A8DF71F9856C7E65659240FE447GVW1338EXAame_-- From ogier@earthlink.net Mon May 9 17:23:24 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850D5E0750 for ; Mon, 9 May 2011 17:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OobULy5yRutP for ; Mon, 9 May 2011 17:23:22 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 97E76E0741 for ; Mon, 9 May 2011 17:23:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SW1enZazyZRCOHpzPkcfDxKX9eGx4IxVtTvy+xe00KAoe4LYUFbpGfalkegfBiiA; 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.246.244] by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QJaW3-0003aJ-N5; Mon, 09 May 2011 20:09:34 -0400 Message-ID: <4DC882AA.4030500@earthlink.net> Date: Mon, 09 May 2011 17:11:22 -0700 From: Richard Ogier 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: "Retana, Alvaro" References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> <4DC84C40.7030801@earthlink.net> <24646CE17826CF4A8DF71F9856C7E65659240FE447@GVW1338EXA.americas.hpqcorp.net> In-Reply-To: <24646CE17826CF4A8DF71F9856C7E65659240FE447@GVW1338EXA.americas.hpqcorp.net> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d47802d2bbebba13fc2c21de7dd87fc948dc87bd85336bacd509350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.246.244 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2011 00:23:24 -0000 Retana, Alvaro wrote:

Richard:

 

You’re right to say that the MANET solution can handle the special case of a single-hop broadcast network, if one was encountered.  The deployment lesson that we’re taking from that scenario is that it is operationally simpler to work w/one type of interface: one neighbor discovery process, one interface description model, etc…specially in cases where the ability to configure and troubleshoot the network in the field is greatly reduced by both access to the nodes as well as the potential abilities of the operators, which is the case in some of the deployments of rfc5820.

 

IOW, in a mobile network that may include multi-hop and single-hop interfaces, it is operationally preferred to deploy just one type of interface model.

That may be true.  But you are specifying a number of changes for a single-hop interface, including not setting the A-bit (so there are no active ORs), enabling flooding for all unsynchronized adjacencies, a simplified reachability check for smart peering, etc.  So one could argue it is really a different interface type.  Since the hybrid-bcast-p2mp draft requires only a small number of changes to OSPF, another approach would be to use that method for single-hop interfaces (i.e., elect a DR/BDR for that interface, etc.) and include this in the spec for OSPF-OR.  This would be easy with OSPF-MDR because it already elects a DR (called MDR) in single-hop networks.  But it should also be possible to do this with OSPF-OR.

Another thing that would make it desirable to integrate the hybrid-bcast-p2mp into OSPF-OR is if it is found to perform better or to be more scalable than smart peering.  It would be interesting to run simulations to compare these two approaches.

Richard

Thanks!

 

Alvaro.

 

From: Richard Ogier [mailto:ogier@earthlink.net]
Sent: Monday, May 09, 2011 4:19 PM
To: Retana, Alvaro
Cc: ospf@ietf.org
Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document

 

In my opinion, the hybrid-bcast-and-p2mp draft is a simple and perfect solution to this problem:
http://tools.ietf.org/id/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt

This has been discussed and some of us agree with this.  For example, Jeffrey Zhang's post dated 4/11/2011 summarizes some of the arguments.

Although both RFC 5820 (OSPF-OR) and RFC 5614 (OSPF-MDR) can be applied to single-hop broadcast networks and thus solve the same problem as the hybrid-bcast-p2mp draft, the hybrid draft is clearly the simplest solution, involving minimal changes to OSPF.

If the network is definitely a single-hop network, so that each router is one hop from all other routers, then there is no need for a MANET solution.  Otherwise, we need a MANET solution, which will also handle the special case of a single-hop network if by chance the network is single-hop (and this can be mentioned in the MANET draft).

But I would never apply a MANET solution if the network is definitely a single-hop network; I would go with the simpler solution in the hybrid draft.  For this reason, I don't think it makes sense to propose applying an OSPF-MANET extension to the case of a single-hop broadcast network.  But if someone can describe a situation where it makes sense to do this, please do so.

Richard


Retana, Alvaro wrote:

Hi!

 

Following up on the WG meeting in Prague…

 

http://tools.ietf.org/html/draft-retana-ospf-manet-single-hop

 

A brief poll at the meeting found no objection to this update to rfc 5820.

 

This e-mail is the formal request for adoption as a WG document.  Just like rfc 5820, the intended status is Experimental.

 

Thoughts/comments?

 

Thanks!

 

Alvaro.

 

 
 
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
 
From acee.lindem@ericsson.com Mon May 9 17:56:54 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8CEE06FE for ; Mon, 9 May 2011 17:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU-h+Z6fgbX6 for ; Mon, 9 May 2011 17:56:54 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39CE0931 for ; Mon, 9 May 2011 17:56:53 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p4A0qQxP030845; Mon, 9 May 2011 19:52:27 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 9 May 2011 20:52:20 -0400 From: Acee Lindem To: Alan Davey Date: Mon, 9 May 2011 20:52:18 -0400 Thread-Topic: [OSPF] OSPFv3 Authentication Trailer (AT) Draft WG Last Call Thread-Index: AcwOrIPOSGoJz3beRJiNbGfiq7yawQ== Message-ID: <32BB39BA-4C21-4A73-97DE-84ABA8CE2B82@ericsson.com> References: <40FF7945-5254-4F70-86EB-A617FBA866E6@lindem.com> <11DE3EEC54A8A44EAD99D8C0D3FD7207AA16D4F20A@ENFIMBOX1.ad.datcon.co.uk> In-Reply-To: <11DE3EEC54A8A44EAD99D8C0D3FD7207AA16D4F20A@ENFIMBOX1.ad.datcon.co.uk> 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 List , Vishwas Manral Subject: Re: [OSPF] OSPFv3 Authentication Trailer (AT) Draft WG Last Call X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2011 00:56:55 -0000 Hi Alan, The authors agree - in the next revision, the Auth Data Length will include= the length of the entire Authentication Trailer.=20 Thanks, Acee=20 On May 9, 2011, at 5:51 AM, Alan Davey wrote: > Folks >=20 > One minor point on the draft; it is not clear to me if the Auth Data Len = field is the inclusive length of the entire authentication trailer, or just= the length of the Authentication Data. >=20 > I think that the inclusive length of the authentication trailer is prefer= able. =20 >=20 > Either way, the text in section 4.1 could be made specific by changing "m= essage digest" to "authentication trailer" or "Authentication Data". >=20 > Regards > Alan Davey >=20 > Network Technologies Division > Metaswitch Networks > alan.davey@metaswitch.com > +44 (0) 20 8366 1177 > www.metaswitch.com >=20 >=20 >=20 >=20 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of A= cee Lindem > Sent: 05 May 2011 13:35 > To: OSPF List > Cc: Vishwas Manral > Subject: [OSPF] OSPFv3 Authentication Trailer (AT) Draft WG Last Call >=20 > All,=20 >=20 > We will make these editorial changes as part of the WG last call ending o= n May 9. We will not issue an 05 version of the draft until the WG last per= iod has ended. Please review the document by May 9th, if you intend to do s= o.=20 >=20 >=20 > Clarification:=20 >=20 > *************** > *** 308,314 **** > Trailer is very similar to how it is done in case of [RFC2328]. The > only difference between the OSPFv2 authentication trailer and the > OSPFv3 authentication trailer is that information in addition to the > ! message digest is included. >=20 > Consistent with OSPFv2 cryptographic authentication [RFC2328], both > OSPFv3 header checksum calculation and verification are omitted when > --- 308,317 ---- > Trailer is very similar to how it is done in case of [RFC2328]. The > only difference between the OSPFv2 authentication trailer and the > OSPFv3 authentication trailer is that information in addition to the > ! message digest is included. The additional information in the OSPFv= 3 > ! Authentication Trailer is included in the message digest computation > ! and, therefore, protected by OSPFv3 cryptographic authentication as > ! described herein. >=20 > Consistent with OSPFv2 cryptographic authentication [RFC2328], both > OSPFv3 header checksum calculation and verification are omitted when > *************** >=20 >=20 > Correction:=20 >=20 > *************** > *** 623,631 **** >=20 > 2. First Hash >=20 > ! First, the OSPFv3 packet's Authentication Trailer (which is very > ! similar to the appendage described in RFC 2328, Section D.4.3, > ! Page 233, items(6)(a) and (6)(d)) is filled with the value Apad. >=20 > Then, a First-Hash, also known as the inner hash, is computed as > follows: > --- 623,632 ---- >=20 > 2. First Hash >=20 > ! First, the OSPFv3 packet's Authentication Data field in the > ! Authentication Trailer (which is very similar to the appendage > ! described in RFC 2328, Section D.4.3, Page 233, items(6)(a) and > ! (6)(d)) is filled with the value Apad. >=20 > Then, a First-Hash, also known as the inner hash, is computed as > follows: > *************** > *** 635,643 **** > Implementation Notes: >=20 > Note that the First-Hash above includes the Authentication > ! Trailer containing the Apad value, as well as the OSPFv3 > ! packet, as per RFC 2328, Section D.4.3 and, if present, the > ! LLS block[RFC5613]. >=20 > The definition of Apad (above) ensures it is always the same > length as the hash output. This is consistent with RFC 2328. > --- 636,643 ---- > Implementation Notes: >=20 > Note that the First-Hash above includes the Authentication > ! Trailer, as well as the OSPFv3 packet, as per RFC 2328, > ! Section D.4.3 and, if present, the LLS block[RFC5613]. >=20 > The definition of Apad (above) ensures it is always the same > length as the hash output. This is consistent with RFC 2328. > *************** >=20 > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From ogier@earthlink.net Mon May 9 22:24:36 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67DEE0665 for ; Mon, 9 May 2011 22:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpwVikjKzzWy for ; Mon, 9 May 2011 22:24:35 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id CE8DAE06F8 for ; Mon, 9 May 2011 22:24:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RDrmEVmDaGfIb6RzI3RjYV0+8IDU6Wfrjsx0ABZzYKKYCI/9jFlNriy2vx30k9Le; 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.201] by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QJfQB-00080O-DX; Tue, 10 May 2011 01:23:50 -0400 Message-ID: <4DC8CC51.3010706@earthlink.net> Date: Mon, 09 May 2011 22:25:37 -0700 From: Richard Ogier 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: "Retana, Alvaro" References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> <4DC84C40.7030801@earthlink.net> <24646CE17826CF4A8DF71F9856C7E65659240FE447@GVW1338EXA.americas.hpqcorp.net> In-Reply-To: <24646CE17826CF4A8DF71F9856C7E65659240FE447@GVW1338EXA.americas.hpqcorp.net> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478504bcfd8a9496c94c62970ac07f3915dae0ccc80deffe912350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.251.201 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2011 05:24:36 -0000 Alvaro,

One more point. If your network includes standard OSPF broadcast interfaces (which don't require a different cost for each pair of routers), then since RFC 5820 only specifies extensions for MANET interfaces, I assume you will not apply RFC 5820 to such broadcast networks, even though you could.

Similarly, if OSPF were already extended to the hybrid-bcast-p2mp interface type, then you would not need to apply RFC 5820 to such interfaces, even though you could, since a good solution would already exist.

My point is that we only need one solution for the hybrid broadcast interface type.  In fact, if we want to standardize OSPF extensions for both the hybrid broadcast and MANET interface types, we should decide on a SINGLE solution.  There is no reason not to have a single solution.

In fact, with the Router Priority heuristic described in draft-retana, this method becomes closer (but not the same) as hybrid-bcast-p2mp.  And I already mentioned the similarity of hybrid-bcast-p2mp to OSPF-MDR applied to a single-hop networks.  Therefore, the three approaches are already somewhat similar, so we should be able to agree on one of these.  In my opinion hybrid-bcast-p2mp is the simplest and involves the fewest changes to OSPF, so I propose that we all adopt that method for the hybrid broadcast interface type.

If you want to argue that it is not a new interface type, but is just a special case of the MANET interface, then you should not need to specify any changes to the MANET extension, and an Informational draft should be sufficient.  But you are proposing changes based on identifying the interface to be single-hop, so this can be considered a new interface type.  We have three similar solutions for this interface type, and we should be able to agree on one of these.

Richard

Retana, Alvaro wrote:

Richard:

 

You’re right to say that the MANET solution can handle the special case of a single-hop broadcast network, if one was encountered.  The deployment lesson that we’re taking from that scenario is that it is operationally simpler to work w/one type of interface: one neighbor discovery process, one interface description model, etc…specially in cases where the ability to configure and troubleshoot the network in the field is greatly reduced by both access to the nodes as well as the potential abilities of the operators, which is the case in some of the deployments of rfc5820.

 

IOW, in a mobile network that may include multi-hop and single-hop interfaces, it is operationally preferred to deploy just one type of interface model.

 

Thanks!

 

Alvaro.

 

From: Richard Ogier [mailto:ogier@earthlink.net]
Sent: Monday, May 09, 2011 4:19 PM
To: Retana, Alvaro
Cc: ospf@ietf.org
Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document

 

In my opinion, the hybrid-bcast-and-p2mp draft is a simple and perfect solution to this problem:
http://tools.ietf.org/id/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt

This has been discussed and some of us agree with this.  For example, Jeffrey Zhang's post dated 4/11/2011 summarizes some of the arguments.

Although both RFC 5820 (OSPF-OR) and RFC 5614 (OSPF-MDR) can be applied to single-hop broadcast networks and thus solve the same problem as the hybrid-bcast-p2mp draft, the hybrid draft is clearly the simplest solution, involving minimal changes to OSPF.

If the network is definitely a single-hop network, so that each router is one hop from all other routers, then there is no need for a MANET solution.  Otherwise, we need a MANET solution, which will also handle the special case of a single-hop network if by chance the network is single-hop (and this can be mentioned in the MANET draft).

But I would never apply a MANET solution if the network is definitely a single-hop network; I would go with the simpler solution in the hybrid draft.  For this reason, I don't think it makes sense to propose applying an OSPF-MANET extension to the case of a single-hop broadcast network.  But if someone can describe a situation where it makes sense to do this, please do so.

Richard


Retana, Alvaro wrote:

Hi!

 

Following up on the WG meeting in Prague…

 

http://tools.ietf.org/html/draft-retana-ospf-manet-single-hop

 

A brief poll at the meeting found no objection to this update to rfc 5820.

 

This e-mail is the formal request for adoption as a WG document.  Just like rfc 5820, the intended status is Experimental.

 

Thoughts/comments?

 

Thanks!

 

Alvaro.

 

 
 
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
 
From akr@cisco.com Tue May 10 09:10:08 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7930BE070C for ; Tue, 10 May 2011 09:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZ5dJ3uuDt0k for ; Tue, 10 May 2011 09:10:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 62CFCE0763 for ; Tue, 10 May 2011 09:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akr@cisco.com; l=7959; q=dns/txt; s=iport; t=1305043802; x=1306253402; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=AUzRN25STR1QFgrRhtNRngq1qo3tGLttNhUrhEDB0K4=; b=JmFfjgPqmrLOTNS1MgFd2/faY86JEZzWopZiODgstXpCXSRBYXGJtUYj z6HnwMmn7Sx0ny1CwZSJPvZP4C8Kjqd/BL5awsuh3lVnNTV0QD2mwDott Asy1eDybr+/rCYdD+U4J1R9G1bAp4xVJ1OX0zjN2FHoP779GCLgHCF7kj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPhiyU2rRDoI/2dsb2JhbACmCneoep5Ghg8EhkKJLo5+ X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208,217";a="354109096" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 10 May 2011 16:09:50 +0000 Received: from sjc-vpn2-775.cisco.com (sjc-vpn2-775.cisco.com [10.21.115.7]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4AG9oqR019215 for ; Tue, 10 May 2011 16:09:50 GMT Message-ID: <4DC9634D.3020301@cisco.com> Date: Tue, 10 May 2011 09:09:49 -0700 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: "ospf@ietf.org" References: <4DA329FE.4050108@cisco.com> <4DB83C2C.6000404@cisco.com> In-Reply-To: <4DB83C2C.6000404@cisco.com> Content-Type: multipart/alternative; boundary="------------080608080809000604020802" Subject: Re: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2011 16:10:08 -0000 This is a multi-part message in MIME format. --------------080608080809000604020802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Working Group last call has ended. We got a couple of editorial comments which authors have already agreed to change in the next revision.. Regards, -Abhay On 4/27/11 8:54 AM, Abhay Roy wrote: > There has been much discussion on the list, and one significant change > was made to -03 version. Cryptographic Sequence Number has changed > from 32 bit to 64 bits. > > We would like to extend the Last Call till 5pm PST, May 9th 2011. > > Please review the changes from 03 -> 04 version. Diff can be found here: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-auth-trailer-ospfv3-04.txt > > -Abhay/Acee > > > > On 4/11/11 9:19 AM, Abhay Roy wrote: >> We are starting the Working Group Last Call of this revision of the >> subject draft. >> >> This drafts is intended to be a Proposed Standard. The OSPF WG last call >> will begin today and will end at 5pm PST, April 25th, 2011. >> >> Abhay/Acee >> >> -------- Original Message -------- >> Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt >> Date: Sat, 19 Feb 2011 12:00:02 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> CC: ospf@ietf.org >> >> >> >> 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 : Supporting Authentication Trailer for OSPFv3 >> Author(s) : M. Bhatia, et al. >> Filename : draft-ietf-ospf-auth-trailer-ospfv3-03.txt >> Pages : 20 >> Date : 2011-02-19 >> >> Currently OSPFv3 uses IPsec for authenticating protocol packets. >> However, there are some environments, e.g., Mobile Ad-hoc Networks >> (MANETs), where IPsec is difficult to configure and maintain, and >> this mechanism cannot be used. This draft proposes an alternative >> mechanism that can be used so that OSPFv3 does not depend upon IPsec >> for authentication. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --------------080608080809000604020802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Working Group last call has ended. We got a couple of editorial comments which authors have already agreed to change in the next revision..

Regards,
-Abhay

On 4/27/11 8:54 AM, Abhay Roy wrote:
There has been much discussion on the list, and one significant change was made to -03 version. Cryptographic Sequence Number has changed from 32 bit to 64 bits.

We would like to extend the Last Call till 5pm PST, May 9th 2011.

Please review the changes from 03 -> 04 version. Diff can be found here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-auth-trailer-ospfv3-04.txt

-Abhay/Acee



On 4/11/11 9:19 AM, Abhay Roy wrote:
We are starting the Working Group Last Call of this revision of the subject draft.

This drafts is intended to be a Proposed Standard. The OSPF WG last call
will begin today and will end at 5pm PST,  April 25th, 2011.

Abhay/Acee

-------- Original Message --------
Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt
Date: Sat, 19 Feb 2011 12:00:02 -0800
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: ospf@ietf.org 


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           : Supporting Authentication Trailer for OSPFv3
	Author(s)       : M. Bhatia, et al.
	Filename        : draft-ietf-ospf-auth-trailer-ospfv3-03.txt
	Pages           : 20
	Date            : 2011-02-19

Currently OSPFv3 uses IPsec for authenticating protocol packets.
However, there are some environments, e.g., Mobile Ad-hoc Networks
(MANETs), where IPsec is difficult to configure and maintain, and
this mechanism cannot be used.  This draft proposes an alternative
mechanism that can be used so that OSPFv3 does not depend upon IPsec
for authentication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

  

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
--------------080608080809000604020802-- From ogier@earthlink.net Tue May 10 09:21:52 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95023E0718 for ; Tue, 10 May 2011 09:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4IeOvphWnkI for ; Tue, 10 May 2011 09:21:51 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 52750E069C for ; Tue, 10 May 2011 09:21:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ESecwrPbGxmOKreThQXaV+n+Hob3pUX7bm+IT8MzxmX616zuPZ9cua0Z3CQpnwV2; 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.105.224] by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QJpgy-0003kw-FF; Tue, 10 May 2011 12:21:50 -0400 Message-ID: <4DC9668C.1050702@earthlink.net> Date: Tue, 10 May 2011 09:23:40 -0700 From: Richard Ogier 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: "Retana, Alvaro" References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> In-Reply-To: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478504bcfd8a9496c9454407cb86baa90f8dea11d7ae91fabc5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.105.224 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2011 16:21:52 -0000 Alvaro,

I did some more thinking and can summarize our disagreement as follows:  I think we should agree on a single method for single-hop broadcast interfaces, and you think the method should depend on whether or not the network also contains MANET interfaces.  Even if the network contains MANET interfaces, I am not sure that treating a single-hop broadcast interface as a modified/simplified MANET interface makes things much easier, compared to using a somewhat similar solution (hybrid-bcast-p2mp) that is a simple modification of OSPF.  I don't think either of us is wrong.  Just different opinions.

Richard


Retana, Alvaro wrote:

Hi!

 

Following up on the WG meeting in Prague…

 

http://tools.ietf.org/html/draft-retana-ospf-manet-single-hop

 

A brief poll at the meeting found no objection to this update to rfc 5820.

 

This e-mail is the formal request for adoption as a WG document.  Just like rfc 5820, the intended status is Experimental.

 

Thoughts/comments?

 

Thanks!

 

Alvaro.

 


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
From acee.lindem@ericsson.com Tue May 10 10:05:18 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2116E086B for ; Tue, 10 May 2011 10:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.722 X-Spam-Level: X-Spam-Status: No, score=-4.722 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf9Qb79EBqVa for ; Tue, 10 May 2011 10:05:17 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2CECBE07DD for ; Tue, 10 May 2011 10:05:16 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p4AGifQN023821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 May 2011 11:44:41 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 10 May 2011 12:44:40 -0400 From: Acee Lindem CC: "ospf@ietf.org" Date: Tue, 10 May 2011 12:44:37 -0400 Thread-Topic: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt Thread-Index: AcwPMY3xHRmCEdizRgWOnv60RCj28A== Message-ID: References: <4DA329FE.4050108@cisco.com> <4DB83C2C.6000404@cisco.com> <4DC9634D.3020301@cisco.com> In-Reply-To: <4DC9634D.3020301@cisco.com> 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] WG Last Call (EXTENDED) for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2011 17:05:19 -0000 All, We've posted http://www.ietf.org/id/draft-ietf-ospf-auth-trailer-ospfv3-05.= txt containing updates for all the WG last call comments. Editorial Comments. 1. Comment from Acee: Clarify that Apad is only placed in the variable au= thentication data portion of the Authentication Trailer (AT) during the mes= sage digest calculation. 2. Comment from Alan Davey: Clarify that the Authentication Trailer lengt= h includes the length of the entire AT (not just the variable data). 3. Comment from Acee: Consistently use "octets" rather than a combination= of "octets" and "bytes". Functional Comment: 1. Comment from Uma Chunduri: Protect IPv6 source address in message dige= st calculation. The associated changes are the addition of section 2.3: 2.3. IPv6 Source Address Protection While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors, the IPv6 source address is learned from OSPFv3 hello packets and copied into the neighbor data structure [RFC5340]. Hence, OSPFv3 is susceptible to Man-in-the-Middle attacks where the IPv6 source address has been modified. To thwart such attacks, the IPv6 source address will be included in the message digest calculation and protected by OSPFv3 authentication. Refer to Section 4.4 for details. This is different than the procedure specified in [RFC5709] but consistent with [I-D.ietf-ospf-security-extension-manual-keying]. And, the update of the definition of Apad in section 4.4: Apad is a value which is the same length as the hash output or message digest. The first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This implies that hash output is always a length of at least 16 octets. We'd appreciate feedback on the updated draft. Thanks, Acee, Manav, and Vishwas On May 10, 2011, at 12:09 PM, Abhay Roy wrote: Working Group last call has ended. We got a couple of editorial comments wh= ich authors have already agreed to change in the next revision.. Regards, -Abhay On 4/27/11 8:54 AM, Abhay Roy wrote: There has been much discussion on the list, and one significant change was = made to -03 version. Cryptographic Sequence Number has changed from 32 bit = to 64 bits. We would like to extend the Last Call till 5pm PST, May 9th 2011. Please review the changes from 03 -> 04 version. Diff can be found here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-auth-trailer-ospfv3-04= .txt -Abhay/Acee On 4/11/11 9:19 AM, Abhay Roy wrote: We are starting the Working Group Last Call of this revision of the subject= draft. This drafts is intended to be a Proposed Standard. The OSPF WG last call will begin today and will end at 5pm PST, April 25th, 2011. Abhay/Acee -------- Original Message -------- Subject: I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt Date: Sat, 19 Feb 2011 12:00:02 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ospf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Open Shortest Path First IGP Working Group= of the IETF. Title : Supporting Authentication Trailer for OSPFv3 Author(s) : M. Bhatia, et al. Filename : draft-ietf-ospf-auth-trailer-ospfv3-03.txt Pages : 20 Date : 2011-02-19 Currently OSPFv3 uses IPsec for authenticating protocol packets. However, there are some environments, e.g., Mobile Ad-hoc Networks (MANETs), where IPsec is difficult to configure and maintain, and this mechanism cannot be used. This draft proposes an alternative mechanism that can be used so that OSPFv3 does not depend upon IPsec for authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-03.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ogier@earthlink.net Wed May 11 10:06:05 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912A5E0867 for ; Wed, 11 May 2011 10:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf6bVYhpgM08 for ; Wed, 11 May 2011 10:06:05 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD95E0866 for ; Wed, 11 May 2011 10:06:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=r2N2XeMxcqm/2LQ6IbSWMOJuhr/WuWC44w9X7S0fy+w4Yvox9luGbQKJJ9EAlMqr; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.251.92] by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QKCrL-0004Bo-Sh for ospf@ietf.org; Wed, 11 May 2011 13:06:04 -0400 Message-ID: <4DCAC26F.4030604@earthlink.net> Date: Wed, 11 May 2011 10:07:59 -0700 From: Richard Ogier 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: "ospf@ietf.org" References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> In-Reply-To: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478504bcfd8a9496c943797f7fd8fb353295903828ee18052dd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.251.92 Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2011 17:06:05 -0000 Note that I plan to submit an analogous draft that describes how OSPF-MDR (RFC 5614) can be applied to single-hop broadcast networks. If draft-retana-ospf-manet-single-hop is accepted as a WG document, then it would also be fair to accept the analogous draft for OSPF-MDR as a WG document. Regards, Richard From jdrake@juniper.net Wed May 11 13:27:16 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD3FE0693 for ; Wed, 11 May 2011 13:27:16 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOydG85fdWNv for ; Wed, 11 May 2011 13:27:15 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 68056E067C for ; Wed, 11 May 2011 13:27:14 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTcrw6oqnS5eCMT+sBtVz4jnPBMdoB2S9@postini.com; Wed, 11 May 2011 13:27:14 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 11 May 2011 13:22:58 -0700 From: John E Drake To: Richard Ogier , "ospf@ietf.org" Date: Wed, 11 May 2011 13:22:56 -0700 Thread-Topic: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document Thread-Index: AcwP/cBH1M3yrTPRSA+pbB/LgDH97QAGqdfw Message-ID: <5E893DB832F57341992548CDBB333163A09A87C342@EMBX01-HQ.jnpr.net> References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> <4DCAC26F.4030604@earthlink.net> In-Reply-To: <4DCAC26F.4030604@earthlink.net> 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] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2011 20:27:16 -0000 Richard, Don't you think you are being a bit presumptuous? I think this decision is= the prerogative of the working group and I don't necessarily think 'fairne= ss' has anything to do with it. Further, having multiple drafts in a given= subject area is generally considered a bad idea. Thanks, John Sent from my iPhone > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Richard Ogier > Sent: Wednesday, May 11, 2011 10:08 AM > To: ospf@ietf.org > Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG > Document >=20 > Note that I plan to submit an analogous draft that describes how > OSPF-MDR (RFC 5614) can be applied to single-hop broadcast networks. > If > draft-retana-ospf-manet-single-hop is accepted as a WG document, then > it > would also be fair to accept the analogous draft for OSPF-MDR as a WG > document. >=20 > Regards, > Richard > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From thomas.r.henderson@boeing.com Wed May 11 14:58:42 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC26E089C for ; Wed, 11 May 2011 14:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DTeGUkjC5Qi for ; Wed, 11 May 2011 14:58:42 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3467DE0877 for ; Wed, 11 May 2011 14:58:42 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4BLwXGL009539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 May 2011 14:58:34 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4BLRIwi018637; Wed, 11 May 2011 14:27:19 -0700 (PDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4BLRIDi018616 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 11 May 2011 14:27:18 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Wed, 11 May 2011 14:58:33 -0700 From: "Henderson, Thomas R" To: "'John E Drake'" , Richard Ogier , "ospf@ietf.org" Date: Wed, 11 May 2011 14:58:32 -0700 Thread-Topic: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document Thread-Index: AcwP/cBH1M3yrTPRSA+pbB/LgDH97QAGqdfwAAM7tnA= Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEED717B5@XCH-NW-10V.nw.nos.boeing.com> References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net><4DCAC26F.4030604@earthlink.net> <5E893DB832F57341992548CDBB333163A09A87C342@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A09A87C342@EMBX01-HQ.jnpr.net> 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] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2011 21:58:42 -0000 > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > John E Drake > Sent: Wednesday, May 11, 2011 1:23 PM > To: Richard Ogier; ospf@ietf.org > Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG > Document >=20 > Richard, >=20 > Don't you think you are being a bit presumptuous? I think this > decision is the prerogative of the working group and I don't > necessarily think 'fairness' has anything to do with it. Further, > having multiple drafts in a given subject area is generally considered > a bad idea. >=20 > Thanks, >=20 > John >=20 John, it has been on the OSPF WG charter to develop multiple OSPFv3 MANET E= xperimental RFCs. - Tom From jdrake@juniper.net Wed May 11 15:11:43 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F02E08C8 for ; Wed, 11 May 2011 15:11:43 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLb94YLZ4eXa for ; Wed, 11 May 2011 15:11:41 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id D41CBE08C7 for ; Wed, 11 May 2011 15:11:40 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTcsJaERlEMMvTlHlum0MrLi98y2U39u/@postini.com; Wed, 11 May 2011 15:11:40 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 11 May 2011 15:10:36 -0700 From: John E Drake To: "Henderson, Thomas R" , Richard Ogier , "ospf@ietf.org" Date: Wed, 11 May 2011 15:10:35 -0700 Thread-Topic: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document Thread-Index: AcwP/cBH1M3yrTPRSA+pbB/LgDH97QAGqdfwAAM7tnAAAGpwAA== Message-ID: <5E893DB832F57341992548CDBB333163A09A87C592@EMBX01-HQ.jnpr.net> References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net><4DCAC26F.4030604@earthlink.net> <5E893DB832F57341992548CDBB333163A09A87C342@EMBX01-HQ.jnpr.net> <7CC566635CFE364D87DC5803D4712A6C4CEED717B5@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEED717B5@XCH-NW-10V.nw.nos.boeing.com> 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] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2011 22:11:43 -0000 Tom, The primary point of my email was Richard's presumptuousness. The comment about having multiple protocols to do the same thing being a ba= d idea was simply a comment in passing. And it is a bad idea - this was th= e rationale given by the IETF in taking a position against multiple OAM pro= tocols for MPLS-TP. Thanks, John Sent from my iPhone > -----Original Message----- > From: Henderson, Thomas R [mailto:thomas.r.henderson@boeing.com] > Sent: Wednesday, May 11, 2011 2:59 PM > To: John E Drake; Richard Ogier; ospf@ietf.org > Subject: RE: [OSPF] Adoption of "Single Hop MANET Interface" as WG > Document >=20 >=20 >=20 > > -----Original Message----- > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf > Of > > John E Drake > > Sent: Wednesday, May 11, 2011 1:23 PM > > To: Richard Ogier; ospf@ietf.org > > Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG > > Document > > > > Richard, > > > > Don't you think you are being a bit presumptuous? I think this > > decision is the prerogative of the working group and I don't > > necessarily think 'fairness' has anything to do with it. Further, > > having multiple drafts in a given subject area is generally > considered > > a bad idea. > > > > Thanks, > > > > John > > >=20 > John, it has been on the OSPF WG charter to develop multiple OSPFv3 > MANET Experimental RFCs. >=20 > - Tom From ogier@earthlink.net Wed May 11 15:15:22 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E454E0870 for ; Wed, 11 May 2011 15:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.941 X-Spam-Level: X-Spam-Status: No, score=-0.941 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-XYd-vcd-7X for ; Wed, 11 May 2011 15:15:21 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 84FC8E07F4 for ; Wed, 11 May 2011 15:15:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZHVuufr2LxCR6qKrMHkKMv155Yfr696AVL7XnZS8ajiCiw8u3CstVelMQ9NF4hLj; 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.104.125] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QKHgd-0000Io-R6; Wed, 11 May 2011 18:15:21 -0400 Message-ID: <4DCB0AEA.3060804@earthlink.net> Date: Wed, 11 May 2011 15:17:14 -0700 From: Richard Ogier 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: John E Drake References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> <4DCAC26F.4030604@earthlink.net> <5E893DB832F57341992548CDBB333163A09A87C342@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A09A87C342@EMBX01-HQ.jnpr.net> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478504bcfd8a9496c945d3421cc13fbf9c1ffd1cb3e6336278d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.104.125 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2011 22:15:22 -0000 John,

A few years ago, we had three drafts dealing with the same problem of OSPF-MANET, and now we have three Experimental RFCs providing different solutions to this problem.  All of these RFCs can be applied just as easily to solve the special case of a single-hop broadcast network.  If we want to choose one of these solutions over the other two, there needs to be a reason and a formal decision, which I have not seen.  One nice thing about having two drafts showing how both OSPF-OR and OSPF-MDR can be applied to single-hop broadcast networks, is that it will help people to understand and compare these different solutions.

Assuming OSPF-MDR is at least as good a solution as OSPF-OR in solving this problem, which I believe, then I don't think it is presumptuous to think it is fair to give both solutions an equal chance.  But it is true that people will need to read both drafts before they can come to that same conclusion.  Therefore, my point is to let people know there will soon be another draft describing how another OSPF-MANET extension can be applied to this case.

Thanks,
Richard

John E Drake wrote: 
Richard,

Don't you think you are being a bit presumptuous?  I think this decision is the prerogative of the working group and I don't necessarily think 'fairness' has anything to do with it.  Further, having multiple drafts in a given subject area is generally considered a bad idea.

Thanks,

John

Sent from my iPhone


  
-----Original Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of
Richard Ogier
Sent: Wednesday, May 11, 2011 10:08 AM
To: ospf@ietf.org
Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG
Document

Note that I plan to submit an analogous draft that describes how
OSPF-MDR (RFC 5614) can be applied to single-hop broadcast networks.
If
draft-retana-ospf-manet-single-hop is accepted as a WG document, then
it
would also be fair to accept the analogous draft for OSPF-MDR as a WG
document.

Regards,
Richard
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
From acee.lindem@ericsson.com Wed May 11 15:22:35 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1826BE0693 for ; Wed, 11 May 2011 15:22:35 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plixCluI4v1n for ; Wed, 11 May 2011 15:22:34 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D4E27E07C9 for ; Wed, 11 May 2011 15:22:33 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p4BMMVsQ017744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 May 2011 17:22:32 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 11 May 2011 18:22:31 -0400 From: Acee Lindem To: OSPF List Date: Wed, 11 May 2011 18:22:29 -0400 Thread-Topic: Single Hop MANET versus Broadcast/P2MP Hybrid Interface Thread-Index: AcwQKesEH1ZtPkRLTmCv11x5NDBn1w== Message-ID: 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: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid Interface X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2011 22:22:35 -0000 Speaking as WG Co-Chair, As many of you remember, we spent a lot of WG time 2004-2007 discussing var= ious OSPF MANET solutions. We were unable to converge on a single solution = and ended up with 3 experimental RFCs. It was thought that possibly one day= a clear winner would emerge and become a standard. While this may still ha= ppen in the future, I don't believe we are there yet and do not feel it wou= ld be beneficial to renew the debate. In Beijing, the hybrid broadcast/P2MP interface was proposed with a radio n= etworks being one of the target environment. This collision with the former= work on OSPF MANET elicited much discussion. In Prague, the chairs, author= s, and some other interested parties met to specifically address this colli= sion. What we agreed was that the existing OSPF MANET RFCs were the agreed = upon solution(s) for MANET environments. The OSPF hybrid interface could st= ill be valuable as a simple adjacency reduction technique on links where br= oadcast capability was available but not all the links had the same costs. = We also agreed that the OSPF MANET mechanisms (with some simplifications) c= ould also handle the single hop case. Hence, the questions for the WG are: 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt as= a WG document? https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and-p2mp 2. Do we wish to allow revisions of the OSPF MANET experimental RFCs to c= over the single-hop case (and possibly minor corrections)? https://datatracker.ietf.org/doc/rfc5449/ https://datatracker.ietf.org/doc/rfc5614/ https://datatracker.ietf.org/doc/rfc5820/ Note that IPR statements are filed for some of the above. Thanks, Acee From jdrake@juniper.net Wed May 11 15:31:22 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218EEE0838 for ; Wed, 11 May 2011 15:31:22 -0700 (PDT) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTTXA8hkidPS for ; Wed, 11 May 2011 15:31:16 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB14E07F4 for ; Wed, 11 May 2011 15:31:16 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTcsOMxQpokYA6xjUtCB7UicrANknLkXA@postini.com; Wed, 11 May 2011 15:31:16 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 11 May 2011 15:28:09 -0700 From: John E Drake To: Richard Ogier Date: Wed, 11 May 2011 15:28:08 -0700 Thread-Topic: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document Thread-Index: AcwQKO0tHOtf6nR8QX2rHb/Kp9WF0wAAOYOw Message-ID: <5E893DB832F57341992548CDBB333163A09A87C5DD@EMBX01-HQ.jnpr.net> References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> <4DCAC26F.4030604@earthlink.net> <5E893DB832F57341992548CDBB333163A09A87C342@EMBX01-HQ.jnpr.net> <4DCB0AEA.3060804@earthlink.net> In-Reply-To: <4DCB0AEA.3060804@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A09A87C5DDEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2011 22:31:22 -0000 --_000_5E893DB832F57341992548CDBB333163A09A87C5DDEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments inline Sent from my iPhone From: Richard Ogier [mailto:ogier@earthlink.net] Sent: Wednesday, May 11, 2011 3:17 PM To: John E Drake Cc: ospf@ietf.org Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document John, A few years ago, we had three drafts dealing with the same problem of OSPF-= MANET, and now we have three Experimental RFCs providing different solution= s to this problem. All of these RFCs can be applied just as easily to solv= e the special case of a single-hop broadcast network. If we want to choose= one of these solutions over the other two, there needs to be a reason and = a formal decision, which I have not seen. One nice thing about having two = drafts showing how both OSPF-OR and OSPF-MDR can be applied to single-hop b= roadcast networks, is that it will help people to understand and compare th= ese different solutions. JD: That is not the statement you made in your email. You said if one bec= ame a working group draft the other should also. That is not your prerogat= ive. Assuming OSPF-MDR is at least as good a solution as OSPF-OR in solving this= problem, which I believe, then I don't think it is presumptuous to think i= t is fair to give both solutions an equal chance JD: Why? Years of this stuff has yet to show one protocol to have a demon= strable superiority over any other. But it is true that people will need to read both drafts before they can = come to that same conclusion. Therefore, my point is to let people know th= ere will soon be another draft describing how another OSPF-MANET extension = can be applied to this case. JD: Again, that is not what you said. And it isn't clear to me that the = world needs yet another protocol choice. Thanks, Richard John E Drake wrote: Richard, Don't you think you are being a bit presumptuous? I think this decision is= the prerogative of the working group and I don't necessarily think 'fairne= ss' has anything to do with it. Further, having multiple drafts in a given= subject area is generally considered a bad idea. Thanks, John Sent from my iPhone -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-boun= ces@ietf.org] On Behalf Of Richard Ogier Sent: Wednesday, May 11, 2011 10:08 AM To: ospf@ietf.org Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document Note that I plan to submit an analogous draft that describes how OSPF-MDR (RFC 5614) can be applied to single-hop broadcast networks. If draft-retana-ospf-manet-single-hop is accepted as a WG document, then it would also be fair to accept the analogous draft for OSPF-MDR as a WG document. Regards, Richard _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_5E893DB832F57341992548CDBB333163A09A87C5DDEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Comments inline

 

Sent from my iPho= ne

 =

From: Richard Ogier [mailto:ogier@earthlink.net]
Sent:= Wednesday, May 11, 2011 3:17 PM
To: John E Drake
Cc: o= spf@ietf.org
Subject: Re: [OSPF] Adoption of "Single Hop MAN= ET Interface" as WG Document

 

John,

A few y= ears ago, we had three drafts dealing with the same problem of OSPF-MANET, = and now we have three Experimental RFCs providing different solutions to th= is problem.  All of these RFCs can be applied just as easily to solve = the special case of a single-hop broadcast network.  If we want to cho= ose one of these solutions over the other two, there needs to be a reason a= nd a formal decision, which I have not seen.  One nice thing about hav= ing two drafts showing how both OSPF-OR and OSPF-MDR can be applied to sing= le-hop broadcast networks, is that it will help people to understand and co= mpare these different solutions.

 

JD:  That is not the statement you made in your em= ail.  You said if one became a working group draft the other should al= so.  That is not your prerogative.

Assuming OSPF-MDR is = at least as good a solution as OSPF-OR in solving this problem, which I bel= ieve, then I don't think it is presumptuous to think it is fair to give bot= h solutions an equal chance=

 

JD:  Why?  Years of this stuff has yet to show one p= rotocol to have a demonstrable superiority over any other.

 

  But it is true that people will need to read both drafts befo= re they can come to that same conclusion.  Therefore, my point is to l= et people know there will soon be another draft describing how another OSPF= -MANET extension can be applied to this case.=

 <= /p>

JD:   Again, that is not what you = said.  And it isn’t clear to me that the world needs yet another= protocol choice.



Thanks,=
Richard

John E Drake wrote: 

Richard,
 
Don't you think you are being a b=
it presumptuous?  I think this decision is the prerogative of the work=
ing group and I don't necessarily think 'fairness' has anything to do with =
it.  Further, having multiple drafts in a given subject area is genera=
lly considered a bad idea.
 
Thanks,
 
John
 
Sent from my iPhone
 
 
  
---=
--Original Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of
Richard Ogier
Sent: Wednesday, May 11, 2011 10:08 A=
M
To: ospf@ietf.org
Subject: Re: [OSPF] Adoption of "Single Hop MA=
NET Interface" as WG
Document
 
Note that I plan to submit an analogous draft=
 that describes how
OSPF-MDR (RFC 5614) can be applied=
 to single-hop broadcast networks.
If
= 
draft-retana-ospf-manet-single-hop is accepted as a WG document, then<=
o:p>
it
would also be fair to accept t=
he analogous draft for OSPF-MDR as a WG
document.=

 
Regards,
=
Richard
______________________________________________=
_
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinf=
o/ospf
    
 
 
= = --_000_5E893DB832F57341992548CDBB333163A09A87C5DDEMBX01HQjnprn_-- From jdrake@juniper.net Wed May 11 15:34:19 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036CCE0870 for ; Wed, 11 May 2011 15:34:19 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+87dwuAi5XQ for ; Wed, 11 May 2011 15:34:18 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id DED0AE07F4 for ; Wed, 11 May 2011 15:34:17 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTcsO5zpFTF8ZeOnTrJfY1V2eV4w1zJKj@postini.com; Wed, 11 May 2011 15:34:17 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 11 May 2011 15:31:00 -0700 From: John E Drake To: Acee Lindem , OSPF List Date: Wed, 11 May 2011 15:30:58 -0700 Thread-Topic: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid Interface Thread-Index: AcwQKesEH1ZtPkRLTmCv11x5NDBn1wAASm5A Message-ID: <5E893DB832F57341992548CDBB333163A09A87C5EC@EMBX01-HQ.jnpr.net> 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] Single Hop MANET versus Broadcast/P2MP Hybrid Interface X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2011 22:34:19 -0000 Yes and No Sent from my iPhone > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Acee Lindem > Sent: Wednesday, May 11, 2011 3:22 PM > To: OSPF List > Subject: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid Interface >=20 > Speaking as WG Co-Chair, >=20 > As many of you remember, we spent a lot of WG time 2004-2007 discussing > various OSPF MANET solutions. We were unable to converge on a single > solution and ended up with 3 experimental RFCs. It was thought that > possibly one day a clear winner would emerge and become a standard. > While this may still happen in the future, I don't believe we are there > yet and do not feel it would be beneficial to renew the debate. >=20 > In Beijing, the hybrid broadcast/P2MP interface was proposed with a > radio networks being one of the target environment. This collision with > the former work on OSPF MANET elicited much discussion. In Prague, the > chairs, authors, and some other interested parties met to specifically > address this collision. What we agreed was that the existing OSPF MANET > RFCs were the agreed upon solution(s) for MANET environments. The OSPF > hybrid interface could still be valuable as a simple adjacency > reduction technique on links where broadcast capability was available > but not all the links had the same costs. We also agreed that the OSPF > MANET mechanisms (with some simplifications) could also handle the > single hop case. >=20 > Hence, the questions for the WG are: >=20 >=20 > 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > 01.txt as a WG document? >=20 > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and- > p2mp >=20 > 2. Do we wish to allow revisions of the OSPF MANET experimental RFCs > to cover the single-hop case (and possibly minor corrections)? >=20 > https://datatracker.ietf.org/doc/rfc5449/ > https://datatracker.ietf.org/doc/rfc5614/ > https://datatracker.ietf.org/doc/rfc5820/ >=20 > Note that IPR statements are filed for some of the above. >=20 > Thanks, > Acee >=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From ogier@earthlink.net Wed May 11 15:38:45 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E348E08B1 for ; Wed, 11 May 2011 15:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIkvIIC+YfWT for ; Wed, 11 May 2011 15:38:44 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id A4594E08A5 for ; Wed, 11 May 2011 15:38:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gUEP9q0C0ESNIQJoXpLY8O3IcRNf850AClYG/giQHhrJmg47GoOnrETy9SIhIFZW; 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.104.125] by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QKI3A-0002WK-F9; Wed, 11 May 2011 18:38:37 -0400 Message-ID: <4DCB105F.9030806@earthlink.net> Date: Wed, 11 May 2011 15:40:31 -0700 From: Richard Ogier 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: John E Drake References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas.hpqcorp.net> <4DCAC26F.4030604@earthlink.net> <5E893DB832F57341992548CDBB333163A09A87C342@EMBX01-HQ.jnpr.net> <4DCB0AEA.3060804@earthlink.net> <5E893DB832F57341992548CDBB333163A09A87C5DD@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A09A87C5DD@EMBX01-HQ.jnpr.net> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478504bcfd8a9496c94657578c282a6579bdb1a844c5709ecbe350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.104.125 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2011 22:38:45 -0000

  But it is true that people will need to read both drafts before they can come to that same conclusion.  Therefore, my point is to let people know there will soon be another draft describing how another OSPF-MANET extension can be applied to this case.

JD:   Again, that is not what you said.  And it isn’t clear to me that the world needs yet another protocol choice.

The fact is that both RFCs already solve the problem.  Therefore, we are not talking about another protocol choice.

Anyway, Acee's recent post shows that he is being fair.

Richard


From thomas.r.henderson@boeing.com Wed May 11 15:59:24 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02423E08D9 for ; Wed, 11 May 2011 15:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DpJ47louSFe for ; Wed, 11 May 2011 15:59:22 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 048AEE0696 for ; Wed, 11 May 2011 15:59:21 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4BMxFwd024544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 May 2011 15:59:16 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4BMxFhv025238; Wed, 11 May 2011 17:59:15 -0500 (CDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4BMxE23025229 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 11 May 2011 17:59:15 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Wed, 11 May 2011 15:59:14 -0700 From: "Henderson, Thomas R" To: "'John E Drake'" , Richard Ogier , "ospf@ietf.org" Date: Wed, 11 May 2011 15:59:13 -0700 Thread-Topic: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document Thread-Index: AcwP/cBH1M3yrTPRSA+pbB/LgDH97QAGqdfwAAM7tnAAAGpwAAAA6Gkg Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEED717B7@XCH-NW-10V.nw.nos.boeing.com> References: <24646CE17826CF4A8DF71F9856C7E65659240FE2F3@GVW1338EXA.americas. hpqcorp.net><4DCAC26F.4030604@earthlink.net><5E893DB832F57341992548CDBB3331 63A09A87C342@EMBX01-HQ.jnpr.net><7CC566635CFE364D87DC5803D4712A6C4CEED717B5@XCH-NW-10V.nw.nos.boeing.com> <5E893DB832F57341992548CDBB333163A09A87C592@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A09A87C592@EMBX01-HQ.jnpr.net> 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] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2011 22:59:24 -0000 John, some replies are inline below. > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Wednesday, May 11, 2011 3:11 PM > To: Henderson, Thomas R; Richard Ogier; ospf@ietf.org > Subject: RE: [OSPF] Adoption of "Single Hop MANET Interface" as WG > Document >=20 > Tom, >=20 > The primary point of my email was Richard's presumptuousness. >=20 I agree that it may be presumptuous to ask a WG to adopt an as-yet-unpublis= hed draft. However, I for one would like to understand better the decision= that is being taken in adopting an update of RFC 5820 to solve the use cas= e of draft-nsheth-ospf-hybrid-bcast-and-p2mp-01. Would similar future upda= tes of the other MANET RFCs be precluded by such a decision? Does this mea= n that ospf-hybrid-bcast-and-p2mp-01 will not be considered further as a WG= document? Perhaps we could try to clarify whether the WG intention is to update the E= xperimental RFCs along these lines or rather to work on a single specificat= ion for the use case introduced by draft-nsheth-ospf-hybrid-bcast-and-p2mp-= 01. > The comment about having multiple protocols to do the same thing being > a bad idea was simply a comment in passing. And it is a bad idea - > this was the rationale given by the IETF in taking a position against > multiple OAM protocols for MPLS-TP. >=20 I understand, but this is one rationale for the experimental track; see for= example=20 http://www.ietf.org/iesg/informational-vs-experimental.html (Section 3 item= 4) - Tom From ogier@earthlink.net Wed May 11 16:02:02 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FDDE08D9 for ; Wed, 11 May 2011 16:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.074 X-Spam-Level: X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti8RLlSp4TGD for ; Wed, 11 May 2011 16:02:02 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 23FFDE0696 for ; Wed, 11 May 2011 16:02:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WdDBCicdqfgINwogq7IKhW44zMBeKZpz6RqlormyHPhqQs1Kxw6YHt83Ggxj9vpn; 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.104.125] by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QKIPo-0006Cq-D6; Wed, 11 May 2011 19:02:01 -0400 Message-ID: <4DCB15DC.4040202@earthlink.net> Date: Wed, 11 May 2011 16:03:56 -0700 From: Richard Ogier 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: Acee Lindem References: In-Reply-To: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478504bcfd8a9496c9436c382c6d0544b9aabada78f877b5720350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.104.125 Cc: OSPF List Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid Interface X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2011 23:02:02 -0000 
  2. Do we wish to allow revisions of the OSPF MANET experimental RFCs to cover the single-hop case (and possibly minor corrections)?

In response to the above question, I will repeat what I said in my earlier post: One nice thing about having two (short) drafts showing how both OSPF-OR and OSPF-MDR can be applied to single-hop broadcast networks, is that it will help people to understand and compare these different solutions .  An alternative is for these OSPF-MANET drafts to be Informational, since they don't require modification of the original protocols, but describe how they can be applied to the single-hop case.

Thanks,
Richard
Acee Lindem wrote:
Speaking as WG Co-Chair,

As many of you remember, we spent a lot of WG time 2004-2007 discussing various OSPF MANET solutions. We were unable to converge on a single solution and ended up with 3 experimental RFCs. It was thought that possibly one day a clear winner would emerge and become a standard. While this may still happen in the future, I don't believe we are there yet and do not feel it would be beneficial to renew the debate.

In Beijing, the hybrid broadcast/P2MP interface was proposed with a radio networks being one of the target environment. This collision with the former work on OSPF MANET elicited much discussion. In Prague, the chairs, authors, and some other interested parties met to specifically address this collision. What we agreed was that the existing OSPF MANET RFCs were the agreed upon solution(s) for MANET environments. The OSPF hybrid interface could still be valuable as a simple adjacency reduction technique on links where broadcast capability was available but not all the links had the same costs. We also agreed that the OSPF MANET mechanisms (with some simplifications) could also handle the single hop case.

Hence, the questions for the WG are:


  1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt as a WG document?

https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and-p2mp

  2. Do we wish to allow revisions of the OSPF MANET experimental RFCs to cover the single-hop case (and possibly minor corrections)?

https://datatracker.ietf.org/doc/rfc5449/
https://datatracker.ietf.org/doc/rfc5614/
https://datatracker.ietf.org/doc/rfc5820/

Note that IPR statements are filed for some of the above.

Thanks,
Acee



_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
From emmanuel.baccelli@gmail.com Thu May 12 01:54:10 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C754CE0669 for ; Thu, 12 May 2011 01:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXa8-DtxG0Mk for ; Thu, 12 May 2011 01:54:06 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 44DA6E0744 for ; Thu, 12 May 2011 01:54:05 -0700 (PDT) Received: by fxm15 with SMTP id 15so1069480fxm.31 for ; Thu, 12 May 2011 01:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type; bh=1jQNB9yIrMghm1yzVvE0QEUmZExuciB8Cg+tqySzvzE=; b=rNZimD2kzOpC10Y3QAnD93GfBKl1bTpZQb45EPrQWWPqgylGay121JsDf75HO7V72Y hs77Ix4KdHXeoQVqSSMabT3Pa4MGu/JpQc9uGXpqlEmx8sSn/eWZVjweCMSqsf+j2ogU h0rIG60K+A2bEekUHHa8kJeSj8IbEcpv7VXK8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=rBCSQXwrK5DnOskqPuQy6e8oU24Bf034dgOjXvX9SM5K0P5BpLOCKVJ2zaahbwkA/j yZxpdo3YczZhoBSWt1xwK/ZUR0tyBskGRMdzb1fTqQ5mdsli9lqcdw7ogciUSq+soL0v 7+vLQszooRPV4SXofyv7mMEuX11D+y3YBGaeQ= Received: by 10.223.54.219 with SMTP id r27mr1348799fag.124.1305190445138; Thu, 12 May 2011 01:54:05 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.223.109.11 with HTTP; Thu, 12 May 2011 01:53:45 -0700 (PDT) In-Reply-To: <279997854.2123749.1305154773692.JavaMail.root@zmbs1.inria.fr> References: <4DCAC26F.4030604@earthlink.net> <7CC566635CFE364D87DC5803D4712A6C4CEED717B5@XCH-NW-10V.nw.nos.boeing.com> <5E893DB832F57341992548CDBB333163A09A87C592@EMBX01-HQ.jnpr.net> <279997854.2123749.1305154773692.JavaMail.root@zmbs1.inria.fr> From: Emmanuel Baccelli Date: Thu, 12 May 2011 10:53:45 +0200 X-Google-Sender-Auth: Y5grr2_r0NmM99xQ5ANOC8xs1a0 Message-ID: To: "ospf@ietf.org" Content-Type: multipart/alternative; boundary=0015174486a2d8c4b604a3105477 Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 12 May 2011 08:54:10 -0000 --0015174486a2d8c4b604a3105477 Content-Type: text/plain; charset=ISO-8859-1 John, I agree with Tom. It's not totally obvious which way to choose to go forward with this. I think a discussion needs to take place before deciding anything. This thread may be the start of such a discussion? Regards, Emmanuel On Thu, May 12, 2011 at 12:59 AM, Henderson, Thomas R < thomas.r.henderson@boeing.com> wrote: > John, some replies are inline below. > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Wednesday, May 11, 2011 3:11 PM > > To: Henderson, Thomas R; Richard Ogier; ospf@ietf.org > > Subject: RE: [OSPF] Adoption of "Single Hop MANET Interface" as WG > > Document > > > > Tom, > > > > The primary point of my email was Richard's presumptuousness. > > > > I agree that it may be presumptuous to ask a WG to adopt an > as-yet-unpublished draft. However, I for one would like to understand > better the decision that is being taken in adopting an update of RFC 5820 to > solve the use case of draft-nsheth-ospf-hybrid-bcast-and-p2mp-01. Would > similar future updates of the other MANET RFCs be precluded by such a > decision? Does this mean that ospf-hybrid-bcast-and-p2mp-01 will not be > considered further as a WG document? > > Perhaps we could try to clarify whether the WG intention is to update the > Experimental RFCs along these lines or rather to work on a single > specification for the use case introduced by > draft-nsheth-ospf-hybrid-bcast-and-p2mp-01. > > > The comment about having multiple protocols to do the same thing being > > a bad idea was simply a comment in passing. And it is a bad idea - > > this was the rationale given by the IETF in taking a position against > > multiple OAM protocols for MPLS-TP. > > > > I understand, but this is one rationale for the experimental track; see for > example > http://www.ietf.org/iesg/informational-vs-experimental.html (Section 3 > item 4) > > - Tom > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --0015174486a2d8c4b604a3105477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John,
I agree with Tom.=A0It's not totally obvious which way to cho= ose to go forward with this.=A0
I think a discussion needs to tak= e place before deciding anything.=A0
This thread may be the start= of such a discussion?
Regards,
Emmanuel

On Thu, = May 12, 2011 at 12:59 AM, Henderson, Thomas R <thomas.r.henderson@boeing.com= > wrote:
John, some replies are in= line below.

> -----Original Message-----
> From: John E Drake [mailto:jdrak= e@juniper.net]
> Sent: Wednesday, May 11, 2011 3:11 PM
> To: Henderson, Thomas R; Richard Ogier; ospf@ietf.org
> Subject: RE: [OSPF] Adoption of "Single Hop MANET Interface"= as WG
> Document
>
> Tom,
>
> The primary point of my email was Richard's presumptuousness.
>

I agree that it may be presumptuous to ask a WG to = adopt an as-yet-unpublished draft. =A0However, I for one would like to unde= rstand better the decision that is being taken in adopting an update of RFC= 5820 to solve the use case of draft-nsheth-ospf-hybrid-bcast-and-p2mp-01. = =A0Would similar future updates of the other MANET RFCs be precluded by suc= h a decision? =A0Does this mean that ospf-hybrid-bcast-and-p2mp-01 will not= be considered further as a WG document?

Perhaps we could try to clarify whether the WG intention is to update the E= xperimental RFCs along these lines or rather to work on a single specificat= ion for the use case introduced by draft-nsheth-ospf-hybrid-bcast-and-p2mp-= 01.

> The comment about having multiple protocols to= do the same thing being
> a bad idea was simply a comment in passing. =A0And it is a bad idea -<= br> > this was the rationale given by the IETF in taking a position against<= br> > multiple OAM protocols for MPLS-TP.
>

I understand, but this is one rationale for the exp= erimental track; see for example
http://www.ietf.org/iesg/informational-vs-experimental.html<= /a> (Section 3 item 4)


--0015174486a2d8c4b604a3105477-- From alvaro.retana@hp.com Thu May 12 10:10:57 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE5BE06C8 for ; Thu, 12 May 2011 10:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANzJNnNsZ6fV for ; Thu, 12 May 2011 10:10:57 -0700 (PDT) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id 4363CE0688 for ; Thu, 12 May 2011 10:10:57 -0700 (PDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id DEF5D2C5EB; Thu, 12 May 2011 17:10:56 +0000 (UTC) Received: from G1W1916.americas.hpqcorp.net (16.236.60.246) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 12 May 2011 17:09:25 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.11]) by G1W1916.americas.hpqcorp.net ([16.236.60.246]) with mapi; Thu, 12 May 2011 17:09:24 +0000 From: "Retana, Alvaro" To: Acee Lindem , OSPF List Date: Thu, 12 May 2011 17:09:21 +0000 Thread-Topic: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid Interface Thread-Index: AcwQKesEH1ZtPkRLTmCv11x5NDBn1wAnSOfw Message-ID: <24646CE17826CF4A8DF71F9856C7E6565924402353@GVW1338EXA.americas.hpqcorp.net> 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] Single Hop MANET versus Broadcast/P2MP Hybrid Interface X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 12 May 2011 17:10:58 -0000 1. Yes. 2. Yes, but...IMHO we don't need a full refresh of the RFCs. An ID updatin= g the RFC should be enough. The ID should be Experimental (just like the R= FC). Alvaro. > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Acee Lindem > Sent: Wednesday, May 11, 2011 6:22 PM > To: OSPF List > Subject: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid Interface >=20 > Speaking as WG Co-Chair, >=20 > As many of you remember, we spent a lot of WG time 2004-2007 discussing > various OSPF MANET solutions. We were unable to converge on a single > solution and ended up with 3 experimental RFCs. It was thought that > possibly one day a clear winner would emerge and become a standard. > While this may still happen in the future, I don't believe we are there > yet and do not feel it would be beneficial to renew the debate. >=20 > In Beijing, the hybrid broadcast/P2MP interface was proposed with a > radio networks being one of the target environment. This collision with > the former work on OSPF MANET elicited much discussion. In Prague, the > chairs, authors, and some other interested parties met to specifically > address this collision. What we agreed was that the existing OSPF MANET > RFCs were the agreed upon solution(s) for MANET environments. The OSPF > hybrid interface could still be valuable as a simple adjacency > reduction technique on links where broadcast capability was available > but not all the links had the same costs. We also agreed that the OSPF > MANET mechanisms (with some simplifications) could also handle the > single hop case. >=20 > Hence, the questions for the WG are: >=20 >=20 > 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > 01.txt as a WG document? >=20 > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and- > p2mp >=20 > 2. Do we wish to allow revisions of the OSPF MANET experimental RFCs > to cover the single-hop case (and possibly minor corrections)? >=20 > https://datatracker.ietf.org/doc/rfc5449/ > https://datatracker.ietf.org/doc/rfc5614/ > https://datatracker.ietf.org/doc/rfc5820/ >=20 > Note that IPR statements are filed for some of the above. >=20 > Thanks, > Acee >=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From akatlas@gmail.com Thu May 12 10:14:22 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4160CE0688 for ; Thu, 12 May 2011 10:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Pm2i1o6xqsU for ; Thu, 12 May 2011 10:14:21 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98DDEE0679 for ; Thu, 12 May 2011 10:14:21 -0700 (PDT) Received: by iyn15 with SMTP id 15so1830844iyn.31 for ; Thu, 12 May 2011 10:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+G0mkfMhqV+iMm6EBlzLaRu1PLW9peE5ATBN9F7tlMo=; b=BXws7Qx+Xl6Xu/t0GN97sGcF6cw3GPJCo2gA/g3k2/QZqKQLqZEc2u+kmmyG/Xck4n +mMQarQ1rgXwu0gbFHjgQiozNQ8onfGibZr8pvTq8u+vR6HqTudzVKq7FirI1/p5s00l ijKZkTNCuiIbdcjWXpsZZFAZc9PZtCUi3Gyqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g4EKauPHf66sEAJEj3NTkJjd6jVmcAQbPtyDUoxkbP4OjYOYaYkxmWFDTwR5kkeTh9 on1R59R3AtP7If+4cMhaekcXcj+pHTpPhyLg/iqvKmScPE1lhgKTqiFjclYqCpV+GCJg w5ba7HzrhdvWKm0KPUEpT/4bJBXKB31+p7x18= MIME-Version: 1.0 Received: by 10.42.159.134 with SMTP id l6mr632244icx.16.1305220460871; Thu, 12 May 2011 10:14:20 -0700 (PDT) Received: by 10.42.3.9 with HTTP; Thu, 12 May 2011 10:14:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2011 13:14:20 -0400 Message-ID: From: Alia Atlas To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OSPF List Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid Interface X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 12 May 2011 17:14:22 -0000 Yes to (1) and no opinion on (2) Alia On Wed, May 11, 2011 at 6:22 PM, Acee Lindem wro= te: > Speaking as WG Co-Chair, > > As many of you remember, we spent a lot of WG time 2004-2007 discussing v= arious OSPF MANET solutions. We were unable to converge on a single solutio= n and ended up with 3 experimental RFCs. It was thought that possibly one d= ay a clear winner would emerge and become a standard. While this may still = happen in the future, I don't believe we are there yet and do not feel it w= ould be beneficial to renew the debate. > > In Beijing, the hybrid broadcast/P2MP interface was proposed with a radio= networks being one of the target environment. This collision with the form= er work on OSPF MANET elicited much discussion. In Prague, the chairs, auth= ors, and some other interested parties met to specifically address this col= lision. What we agreed was that the existing OSPF MANET RFCs were the agree= d upon solution(s) for MANET environments. The OSPF hybrid interface could = still be valuable as a simple adjacency reduction technique on links where = broadcast capability was available but not all the links had the same costs= . We also agreed that the OSPF MANET mechanisms (with some simplifications)= could also handle the single hop case. > > Hence, the questions for the WG are: > > > =A01. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt= as a WG document? > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and-p2mp > > =A02. Do we wish to allow revisions of the OSPF MANET experimental RFCs t= o cover the single-hop case (and possibly minor corrections)? > > https://datatracker.ietf.org/doc/rfc5449/ > https://datatracker.ietf.org/doc/rfc5614/ > https://datatracker.ietf.org/doc/rfc5820/ > > Note that IPR statements are filed for some of the above. > > Thanks, > Acee > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From thomas.r.henderson@boeing.com Thu May 12 13:06:41 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A421DE07D1 for ; Thu, 12 May 2011 13:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MLN3AoWJrs9 for ; Thu, 12 May 2011 13:06:41 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC30E07BE for ; Thu, 12 May 2011 13:06:40 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4CK6b0f013422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 May 2011 15:06:38 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4CK6baR023616; Thu, 12 May 2011 15:06:37 -0500 (CDT) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4CK6bF2023597 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 12 May 2011 15:06:37 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Thu, 12 May 2011 13:06:36 -0700 From: "Henderson, Thomas R" To: "'Acee Lindem'" Date: Thu, 12 May 2011 13:06:36 -0700 Thread-Topic: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid Interface Thread-Index: AcwQKesEH1ZtPkRLTmCv11x5NDBn1wAtTrtw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEED717C8@XCH-NW-10V.nw.nos.boeing.com> 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 List Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid Interface X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 12 May 2011 20:06:41 -0000 > Hence, the questions for the WG are: >=20 >=20 > 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > 01.txt as a WG document? >=20 > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and- > p2mp I have no objection. >=20 > 2. Do we wish to allow revisions of the OSPF MANET experimental RFCs > to cover the single-hop case (and possibly minor corrections)? >=20 > https://datatracker.ietf.org/doc/rfc5449/ > https://datatracker.ietf.org/doc/rfc5614/ > https://datatracker.ietf.org/doc/rfc5820/ >=20 I would be interested to work on this. - Tom From emmanuel.baccelli@gmail.com Thu May 12 13:15:09 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C829DE072E for ; Thu, 12 May 2011 13:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zcdlVYEVXDh for ; Thu, 12 May 2011 13:15:09 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 053C1E06A1 for ; Thu, 12 May 2011 13:15:08 -0700 (PDT) Received: by fxm15 with SMTP id 15so1557132fxm.31 for ; Thu, 12 May 2011 13:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type; bh=p1HSzyMWE87NyO2KyzngHkWlRT6CE1zj/r0DXLOMigE=; b=Os5XmzatGxptYjPxKrTLWlxGoVzqk7pyikZ6CbkkFqlyIz1EmGYClkAPxonftDMXua InjXU2hNTPhZEGi5OXT4yVdsN4l9PsqgUkPUcuxCAJImMwTADgrgWGMp7pL+ywpA4Kb8 yJdCTHk6QC6SZgq3a0AAAjvyDoU1PNLroZcqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=L4bs0t04ylDMdRYN42VRSbOnxqWj13BFTO7xbe6QbMMBp1Hz5oSAI9VHF5WQChcHUv jcemqmMJmVNKnqPp+FZcqrKkuzOEcnZP7aRGMkGMev3I1j8Vr7kTCdk4QwXGYzK+tuQt e2IPdsPWn0KxK6XLefSIpCfCoIkO7YSq9s07E= Received: by 10.223.127.210 with SMTP id h18mr759381fas.67.1305231308125; Thu, 12 May 2011 13:15:08 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.223.109.11 with HTTP; Thu, 12 May 2011 13:14:48 -0700 (PDT) In-Reply-To: <2074293751.2136952.1305230813391.JavaMail.root@zmbs1.inria.fr> References: <2074293751.2136952.1305230813391.JavaMail.root@zmbs1.inria.fr> From: Emmanuel Baccelli Date: Thu, 12 May 2011 22:14:48 +0200 X-Google-Sender-Auth: eOHx8oIe0VpRX_lmAKKjAX2oJk8 Message-ID: To: OSPF List Content-Type: multipart/alternative; boundary=0023545309707875ef04a319d816 Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid Interface X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 12 May 2011 20:15:09 -0000 --0023545309707875ef04a319d816 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R < thomas.r.henderson@boeing.com> wrote: > > Hence, the questions for the WG are: > > > > > > 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > > 01.txt as a WG document? > > > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and- > > p2mp > > I have no objection. > +1 > > > > > 2. Do we wish to allow revisions of the OSPF MANET experimental RFCs > > to cover the single-hop case (and possibly minor corrections)? > > > > https://datatracker.ietf.org/doc/rfc5449/ > > https://datatracker.ietf.org/doc/rfc5614/ > > https://datatracker.ietf.org/doc/rfc5820/ > > > > I would be interested to work on this. > Count me in too! Emmanuel > > - Tom > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --0023545309707875ef04a319d816 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, May 12, 2011 at 10:06 PM, Hender= son, Thomas R <thomas.r.henderson@boeing.com> wrote:
> Hence, the questions for the WG are:
>
>
> =A0 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > 01.txt as a WG document?
>
> https://datatracker.ietf.org/doc/draft-nsheth-= ospf-hybrid-bcast-and-
> p2mp

I have no objection.


+1

=A0

>
> =A0 2. Do we wish to allow revisions of the OSPF MANET experimental RF= Cs
> to cover the single-hop case (and possibly minor corrections)?
>
> https://datatracker.ietf.org/doc/rfc5449/
> https://datatracker.ietf.org/doc/rfc5614/
> https://datatracker.ietf.org/doc/rfc5820/
>

I would be interested to work on this.


Count me in too!
Emmanuel

=A0

- Tom
_______________________________________________

--0023545309707875ef04a319d816-- From sratliff@cisco.com Thu May 12 13:20:22 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F6FE073C for ; Thu, 12 May 2011 13:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8c2Rti3igb2p for ; Thu, 12 May 2011 13:20:22 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEA8E072E for ; Thu, 12 May 2011 13:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4385; q=dns/txt; s=iport; t=1305231622; x=1306441222; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=+CmfadeHSJAg5hEGzPMqxVGUTrnKpXm11aIiZeOpo5c=; b=jo+9BktMF9lVf4Bt02PhqjN/RlC7rQBEZbSJdqUnzp23vW3U5MOZxlqs h8xyFTMyfi5spBMEeFsooH8J2/7/wr3uSSGfyBsKpyqITK9R3LTtyZKpb QJK7mcH9N9wF55TSuEbIPF2pv6Z1Gb9f+cap5dea5LtIT9zUm3mwzQT16 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN4/zE2tJV2Y/2dsb2JhbACleXeIcKFpniyGFQSPe48F X-IronPort-AV: E=Sophos;i="4.64,360,1301875200"; d="scan'208,217";a="314440889" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 12 May 2011 20:20:21 +0000 Received: from dhcp-64-102-54-197.cisco.com (dhcp-64-102-54-197.cisco.com [64.102.54.197]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4CKKLjD001709; Thu, 12 May 2011 20:20:21 GMT Message-Id: From: Stan Ratliff To: Emmanuel Baccelli In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-31-506906799 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 May 2011 16:20:21 -0400 References: <2074293751.2136952.1305230813391.JavaMail.root@zmbs1.inria.fr> X-Mailer: Apple Mail (2.936) Cc: OSPF List Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid Interface X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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, 12 May 2011 20:20:22 -0000 --Apple-Mail-31-506906799 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Yes on both questions. Regards, Stan On May 12, 2011, at 4:14 PM, Emmanuel Baccelli wrote: > > > On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R > wrote: > > Hence, the questions for the WG are: > > > > > > 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > > 01.txt as a WG document? > > > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and- > > p2mp > > I have no objection. > > > +1 > > > > > > > 2. Do we wish to allow revisions of the OSPF MANET experimental > RFCs > > to cover the single-hop case (and possibly minor corrections)? > > > > https://datatracker.ietf.org/doc/rfc5449/ > > https://datatracker.ietf.org/doc/rfc5614/ > > https://datatracker.ietf.org/doc/rfc5820/ > > > > I would be interested to work on this. > > > Count me in too! > > Emmanuel > > > > - Tom > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-31-506906799 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Yes on both = questions.

Regards,
Stan

On May 12, 2011, at 4:14 PM, Emmanuel Baccelli wrote:



On Thu, May 12, 2011 at 10:06 PM, Henderson, = Thomas R <thomas.r.henderson@boeing.co= m> wrote:
> Hence, the questions = for the WG are:
>
>
>   1. Do we want to = accept draft-nsheth-ospf-hybrid-bcast-and-p2mp-
> 01.txt as a WG = document?
>
> https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybri= d-bcast-and-
> p2mp

I have no = objection.


+1

 

>
>   2. = Do we wish to allow revisions of the OSPF MANET experimental RFCs
= > to cover the single-hop case (and possibly minor corrections)?
= >
> https://datatracker.ietf.org/doc/rfc5449/
> = https://datatracker.ietf.org/doc/rfc5614/
> = https://datatracker.ietf.org/doc/rfc5820/
= >

I would be interested to work on = this.


Count me = in = too!

Emmanuel

 
=
- Tom
_______________________________________________
=

= _______________________________________________
OSPF mailing = list
OSPF@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ospf

= --Apple-Mail-31-506906799-- From acee.lindem@ericsson.com Fri May 13 06:59:47 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBA9E06D6 for ; Fri, 13 May 2011 06:59:47 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmbrSOP5Uoag for ; Fri, 13 May 2011 06:59:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD4BE069B for ; Fri, 13 May 2011 06:59:46 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p4DDxhx3031772; Fri, 13 May 2011 08:59:44 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 13 May 2011 09:59:43 -0400 From: Acee Lindem To: "Retana, Alvaro" Date: Fri, 13 May 2011 09:59:42 -0400 Thread-Topic: [OSPF] Adoption of "OSPF Stub Router Advertisement" (rfc3137bis) as WG Document Thread-Index: AcwRdgJhVfsoIBHzTWihqPgRomq9PQ== Message-ID: <901AD859-684E-4DD7-A8FA-8F7276AD007A@ericsson.com> References: <24646CE17826CF4A8DF71F9856C7E65659240FE372@GVW1338EXA.americas.hpqcorp.net> In-Reply-To: <24646CE17826CF4A8DF71F9856C7E65659240FE372@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmcpherson@verisign.com" , "ospf@ietf.org" , "russwh@cisco.com" , "azinin@cisco.com" Subject: Re: [OSPF] Adoption of "OSPF Stub Router Advertisement" (rfc3137bis) as WG Document X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 13 May 2011 13:59:47 -0000 All, At the WG meeting, we tentatively agreed that this RFC 3137 revision is nee= ded in lieu of a separate document for OSPFv3 stub router. Is there anyone = opposed to this becoming a WG document? If there is not significant opposit= ion, we'll make it a WG document on Friday, May 20th (in one week). Thanks, Acee On May 9, 2011, at 3:54 PM, Retana, Alvaro wrote: Hi! Following up on the WG meeting in Prague=85 http://tools.ietf.org/html/draft-retana-ospf-rfc3137bis We just published version -01. The only change from -00 is an update on th= e authors=92 contact information. This e-mail is the formal request for adoption as a WG document. Just like= rfc 3137, the intended status is Informational. Thoughts/comments? Thanks! Alvaro. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From j.a.cordero@gmail.com Sun May 15 15:26:35 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83263E06F7 for ; Sun, 15 May 2011 15:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_STILLSINGLE=1.66] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kxg4C0PqMWKt for ; Sun, 15 May 2011 15:26:33 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42CEFE06EF for ; Sun, 15 May 2011 15:26:33 -0700 (PDT) Received: by vws12 with SMTP id 12so3338082vws.31 for ; Sun, 15 May 2011 15:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=eK5pRJqI/kG+1J19+4eQYMqwcONMPq3OYgZfWPmSL2w=; b=RFDTS1OjlHmdE7wGMr8dw5w9Tu0ag3nI7aUGlw49Kl2azPEeg7b3Tz2mNRvwQIPBdo gGFekALoHtJ/HojnAObaQ4x7ruTSmBZSjMURfQxab8pgE6i4vM9BxqQtFJF2Pn3HFr/4 q+hsfUEl8ReLG1XpOPTWmfSF/UuQbgb8XqQyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=iEqncRajO6GMq6PrW4X0iu59XqAe/PDx5VCHgHNbXmx9kBvF5x6ZuS90jWEZmyAotW Ik662bBtSwAs57oUUbdBcnCanInGqLuSKEU/50qPkxC770z6mT+xDkDD9WmU6uzoKmCq sJT+Kkb2rUdXm/sWxR6idcE6waY/6sSTG6elM= MIME-Version: 1.0 Received: by 10.220.81.3 with SMTP id v3mr1112841vck.92.1305498388260; Sun, 15 May 2011 15:26:28 -0700 (PDT) Received: by 10.220.180.67 with HTTP; Sun, 15 May 2011 15:26:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 May 2011 00:26:28 +0200 Message-ID: From: Juan Antonio Cordero Fuertes To: ospf@ietf.org Content-Type: multipart/alternative; boundary=0016e6475d7aafe76204a358075e Subject: Re: [OSPF] OSPF Digest, Vol 63, Issue 10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 15 May 2011 22:26:35 -0000 --0016e6475d7aafe76204a358075e Content-Type: text/plain; charset=ISO-8859-1 Hi Alvaro, Some comments/thoughts/questions about draft-retana-ospf-manet-single-hop-01 below. Thanks in advance for your attention. 0) The position of routers in the networks addressed in this interface, is fixed or may move as long full connectivity (1-hop) remains? In section 6 it is said that these are fixed networks, but this characteristic is not listed when describing single-hop broadcast networks in section 1.1. *About Hellos:* 1) Incremental Hellos are not used (required) in this proposal. However, in a single-hop MANET, (full) Hellos of any router list all routers in the network every HelloInterval seconds. Since the topology is static (not considering wireless link failures or changes in the link cost), may it be worth to explore a Hello optimization mechanism? Not only incremental Hellos but also, possibly, differential Hellos as specified in RFC 5614. *About Smart Peering:* 2) The proposed heuristic in section 3, is expected to replace or to complement the one presented in RFC 5820? Might be useful to make it more explicit. I assume that the proposed heuristic comes right after the one in RFC 5820 -- otherwise the number of adjacency-forming processes might be higher, some of them redundant. Is that correct? 3) Wait Time[r] mentioned in section 3 is defined in RFC 2328 as RouterDeadInterval. Why tying the waiting time before running the SP state machine to such RouterDeadInterval value? Wouldn't HelloInterval be sufficient? If the goal is to ensure that the router has information about all neighbors from the network, a user-configurable parameter within the interval [HelloInterval, RouterDeadInterval] may be useful. 4) If I'm understanding correctly, the number of adjacencies maintained by a router may be higher than the parameter "maximum number of adjacencies". Consider for instance MAX_ADJ=2 and 4 routers in a single-hop MANET with ids (actually, (RtrPri,RtrId)) 1,2,3,4, that appear in the network (are discovered) in order 4-3-2-1: 4 has three adjacencies. Seems that the "maximum number of adjacencies" corresponds to the number of REQUESTED adjacencies for a router, which is <= than the final number of adjacencies, given that routers accept passively any adjacency-forming request. 5) It is not clear for me in which sense the proposed heuristic is deterministic. Consider again a 4 nodes single-hop network with ids 1,2,3,4. Depending on the order of appearance, the adjacency subgraph changes (e.g., for an appearance order 1-2-3-4 the adjacencies 12, 23, 34 are formed; for the appearance order 4-3-2-1 the formed adjacencies are 14, 24, 34). That is, the adjacency map cannot be extracted from the final topology of the network. *About Unsynchronized adjacencies:* 6) From section 4, it is not clear whether the use of unsynchronized adjacencies is required, possible, not necessary or not acceptable. In my understanding, they are required for correct operation of the interface. Not only for flooding issues, as detailed in the text, but also for shortest paths computation. If all bidirectional neighbors (thus, adjacencies + unsynch.adj.) are not listed in LSAs, the Shortest Path Tree is computed on a pretty fictional and suboptimal topology -- even in a higher degree than in original RFC 5820. Both reasons (flooding in control plane and SPT in data plane) justify the mandatory use of u.a. in this interface. *More general considerations:* 7) Seems to me that the mechanisms presented in this draft, while described as generalizations of RFC 5820, may be applied as well to other extensions, e.g. RFC 5449. Specific mechanisms from OR/SP are either discarded or severely adapted: Incremental Hellos are not used, Smart Peering is (re)defined in a way such that a new router selects only one existing router for synchronization, and the use of unsynchronized adjacencies corresponds to taking into account bidirectional neighbors in Router-LSAs. Maybe it is worth to describe an general interface to which existing extensions should converge when running in these single-hop bc networks? 8) *Behavior of MPR-OSPF in single-hop bc networks.* The use of the MPR-OSPF MANET interface in the single-hop bc leads to a behavior pretty similar to the one specified in the draft. As no MPRs will be elected (because there are no 2-hop neighbors), the only adjacencies will be those performed by the synch router -- by definition, there is only a synch router in the network, and its election (based on the router id) is similar to the heuristic proposed in section 3. Router-LSAs would only describe Path-MPRs, but the SPT would be computed correctly (i.e., not suboptimally) due to the fact that routers use all their 1-hop and 2-hop neighbors when running Dijkstra's. Finally, Router-LSAs would be processed and installed regardless on whether they come from an adjacent neighbor or not; all LSAs coming from bidirectional neighbors are processed in MPR-OSPF. None of such LSAs would be forwarded at any time, since they cannot come from an MPR selector. 9) Even when this may be out of scope, some central aspects of OSPF are clearly useless in networks such as the ones addressed in this draft. The existence of Hello and LSA messages, for instance, makes sense when there are two scopes (local and multi-hop global). For networks in which all routers are neighbors, one of both mechanisms could be not used. Hellos are necessary for establishing bidirectional communication. The only information that LSA may provide (and not Hellos) is link costs. Why not consider the inclusion of such information in Hellos, as in RFC 5449? In this case, that would be sufficient for computing the SPT. 10) This applies as well, at some extent, to the use of adjacencies. Since LSAs are "heard" and processed from all bidirectional neighbors (and not only adjacent), the only interest of adjacent links is reliability of flooding and the exchange of local instances of the LSDB. Allowing a router to synchronize its LSDB with a neighbor may reduce the time required for acquiring the last topology updates. It should however be evaluated the cost in terms of overhead of keeping adjacencies for such synchronizing time reduction. If the network is fixed, then it may be acceptable; for some mobile scenarios (still single-hop broadcast), it may become excessive. Cheers, Juan Antonio Cordero Hipercom -- INRIA 2011/5/13 > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/ospf > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send OSPF mailing list submissions to > ospf@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ospf > or, via email, send a message with subject or body 'help' to > ospf-request@ietf.org > > You can reach the person managing the list at > ospf-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OSPF digest..." > > > Today's Topics: > > 1. Re: Single Hop MANET versus Broadcast/P2MP Hybrid Interface > (Henderson, Thomas R) > 2. Re: Single Hop MANET versus Broadcast/P2MP Hybrid Interface > (Emmanuel Baccelli) > 3. Re: Single Hop MANET versus Broadcast/P2MP Hybrid Interface > (Stan Ratliff) > 4. Re: Adoption of "OSPF Stub Router Advertisement" > (rfc3137bis) as WG Document (Acee Lindem) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 May 2011 13:06:36 -0700 > From: "Henderson, Thomas R" > To: "'Acee Lindem'" > Cc: OSPF List > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid > Interface > Message-ID: > < > 7CC566635CFE364D87DC5803D4712A6C4CEED717C8@XCH-NW-10V.nw.nos.boeing.com> > > Content-Type: text/plain; charset="us-ascii" > > > Hence, the questions for the WG are: > > > > > > 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > > 01.txt as a WG document? > > > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and- > > p2mp > > I have no objection. > > > > > 2. Do we wish to allow revisions of the OSPF MANET experimental RFCs > > to cover the single-hop case (and possibly minor corrections)? > > > > https://datatracker.ietf.org/doc/rfc5449/ > > https://datatracker.ietf.org/doc/rfc5614/ > > https://datatracker.ietf.org/doc/rfc5820/ > > > > I would be interested to work on this. > > - Tom > > > ------------------------------ > > Message: 2 > Date: Thu, 12 May 2011 22:14:48 +0200 > From: Emmanuel Baccelli > To: OSPF List > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid > Interface > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R < > thomas.r.henderson@boeing.com> wrote: > > > > Hence, the questions for the WG are: > > > > > > > > > 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > > > 01.txt as a WG document? > > > > > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and- > > > p2mp > > > > I have no objection. > > > > > +1 > > > > > > > > > > > 2. Do we wish to allow revisions of the OSPF MANET experimental RFCs > > > to cover the single-hop case (and possibly minor corrections)? > > > > > > https://datatracker.ietf.org/doc/rfc5449/ > > > https://datatracker.ietf.org/doc/rfc5614/ > > > https://datatracker.ietf.org/doc/rfc5820/ > > > > > > > I would be interested to work on this. > > > > > Count me in too! > > Emmanuel > > > > > > > - Tom > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/ospf/attachments/20110512/738639c2/attachment.htm > > > > ------------------------------ > > Message: 3 > Date: Thu, 12 May 2011 16:20:21 -0400 > From: Stan Ratliff > To: Emmanuel Baccelli > Cc: OSPF List > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid > Interface > Message-ID: > Content-Type: text/plain; charset="us-ascii"; Format="flowed"; > DelSp="yes" > > Yes on both questions. > > Regards, > Stan > > On May 12, 2011, at 4:14 PM, Emmanuel Baccelli wrote: > > > > > > > On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R < > thomas.r.henderson@boeing.com > > > wrote: > > > Hence, the questions for the WG are: > > > > > > > > > 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > > > 01.txt as a WG document? > > > > > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and- > > > p2mp > > > > I have no objection. > > > > > > +1 > > > > > > > > > > > > 2. Do we wish to allow revisions of the OSPF MANET experimental > > RFCs > > > to cover the single-hop case (and possibly minor corrections)? > > > > > > https://datatracker.ietf.org/doc/rfc5449/ > > > https://datatracker.ietf.org/doc/rfc5614/ > > > https://datatracker.ietf.org/doc/rfc5820/ > > > > > > > I would be interested to work on this. > > > > > > Count me in too! > > > > Emmanuel > > > > > > > > - Tom > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/ospf/attachments/20110512/a8c352b9/attachment.htm > > > > ------------------------------ > > Message: 4 > Date: Fri, 13 May 2011 09:59:42 -0400 > From: Acee Lindem > To: "Retana, Alvaro" > Cc: "dmcpherson@verisign.com" , > "ospf@ietf.org" , "russwh@cisco.com" > , "azinin@cisco.com" > Subject: Re: [OSPF] Adoption of "OSPF Stub Router Advertisement" > (rfc3137bis) as WG Document > Message-ID: <901AD859-684E-4DD7-A8FA-8F7276AD007A@ericsson.com> > Content-Type: text/plain; charset="Windows-1252" > > All, > At the WG meeting, we tentatively agreed that this RFC 3137 revision is > needed in lieu of a separate document for OSPFv3 stub router. Is there > anyone opposed to this becoming a WG document? If there is not significant > opposition, we'll make it a WG document on Friday, May 20th (in one week). > Thanks, > Acee > On May 9, 2011, at 3:54 PM, Retana, Alvaro wrote: > > Hi! > > Following up on the WG meeting in Prague? > > http://tools.ietf.org/html/draft-retana-ospf-rfc3137bis > > We just published version -01. The only change from -00 is an update on > the authors? contact information. > > This e-mail is the formal request for adoption as a WG document. Just like > rfc 3137, the intended status is Informational. > > Thoughts/comments? > > Thanks! > > Alvaro. > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > > > ------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > > End of OSPF Digest, Vol 63, Issue 10 > ************************************ > --0016e6475d7aafe76204a358075e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Alvaro,

=A0

Some comments/thoughts/questions about draft-retana-ospf-manet-single-hop-01 bel= ow. Thanks in advance for your attention.

=A0

0) The positi= on of routers in the networks addressed in this interface, is fixed or may mov= e as long full connectivity (1-hop) remains? In section 6 it is said that these = are fixed networks, but this characteristic is not listed when describing single-hop broadcast networks in section 1.1.=A0

=A0

About Hellos:=

=A0

1) Incrementa= l Hellos are not used (required) in this proposal. However, in a single-hop MANET, (full) Hellos of any router list all routers in the network every HelloInterval seconds. Since the topology is static (not considering wirele= ss link failures or changes in the link cost), may it be worth to explore a He= llo optimization mechanism? Not only incremental Hellos but also, possibly, differential Hellos as specified in RFC 5614.

=A0

About Smart Peering:

=A0

2) The propos= ed heuristic in section 3, is expected to replace or to complement the one presented in RFC 5820? Might be useful to make it more explicit. I assume t= hat the proposed heuristic comes right after the one in RFC 5820 -- otherwise t= he number of adjacency-forming processes might be higher, some of them redunda= nt. Is that correct?

=A0

3) Wait Time[= r] mentioned in section 3 is defined in RFC 2328 as RouterDeadInterval. Why ty= ing the waiting time before running the SP state machine to such RouterDeadInte= rval value? Wouldn't HelloInterval be sufficient? If the goal is to ensure t= hat the router has information about all neighbors from the network, a user-configurable parameter within the interval [HelloInterval, RouterDeadInterval] may be useful.

=A0

4) If I'm understanding correctly, the number of adjacencies maintained by a router m= ay be higher than the parameter "maximum number of adjacencies". Consider for instance MAX_ADJ=3D2 and 4 routers in a single-hop MANET with = ids (actually, (RtrPri,RtrId)) 1,2,3,4, that appear in the network (are dis= covered) in order 4-3-2-1: 4 has three adjacencies. Seems that the "maximum number of adjacencies" corresponds to the number of REQUESTED adjacencies for a router, which is &= lt;=3D than the final number of adjacencies, given that routers accept passively a= ny adjacency-forming request.

=A0

5) It is not clear for me in which sense the proposed heuristic is deterministic. Consid= er again a 4 nodes single-hop network with ids 1,2,3,4. Depending on the order= of appearance, the adjacency subgraph changes (e.g., for an appearance order 1-2-3-4 the adjacencies 12, 23, 34 are formed; for the appearance order 4-3= -2-1 the formed adjacencies are 14, 24, 34). That is, the adjacency map cannot b= e extracted from the final topology of the network.

=A0

About Unsynchronized adjacencies:

=A0

6) From secti= on 4, it is not clear whether the use of unsynchronized adjacencies is require= d, possible, not necessary or not acceptable. In my understanding, they are required for correct operation of the interface. Not only for flooding issu= es, as detailed in the text, but also for shortest paths computation. If all bidirectional neighbors (thus, adjacencies + unsynch.adj.) are not listed i= n LSAs, the Shortest Path Tree is computed on a pretty fictional and suboptim= al topology -- even in a higher degree than in original RFC 5820. Both reasons (flooding in control plane and SPT in data plane) justify the mandatory use= of u.a. in this interface.

=A0

More general considerations:

=A0

7) Seems to m= e that the mechanisms presented in this draft, while described as generalizat= ions of RFC 5820, may be applied as well to other extensions, e.g. RFC 5449. Specific mechanisms from OR/SP are either discarded or severely adapted: Incremental Hellos are not used, Smart Peering is (re)defined in a way such that a new router selects only one existing router for synchronization, and= the use of unsynchronized adjacencies corresponds to taking into account bidirectional neighbors in Router-LSAs. Maybe it is worth to describe an general interface to which existing extensions should converge when running= in these single-hop bc networks?

=A0

8)=A0Behavior of MPR-OSPF in single-hop bc networks.=A0The use of = the MPR-OSPF MANET interface in the single-hop bc leads to a behavior pretty similar to the one specified in the draft. As no MPRs will be elected (beca= use there are no 2-hop neighbors), the only adjacencies will be those performed= by the synch router -- by definition, there is only a synch router in the netw= ork, and its election (based on the router id) is similar to the heuristic propo= sed in section 3. Router-LSAs would only describe Path-MPRs, but the SPT would = be computed correctly (i.e., not suboptimally) due to the fact that routers us= e all their 1-hop and 2-hop neighbors when running Dijkstra's. Finally, Router-LSAs would be processed and installed regardless on whether they com= e from an adjacent neighbor or not; all LSAs coming from bidirectional neighb= ors are processed in MPR-OSPF. None of such LSAs would be forwarded at any time= , since they cannot come from an MPR selector.=A0

=A0

9) Even when = this may be out of scope, some central aspects of OSPF are clearly useless in networks such as the ones addressed in this draft. The existence of Hello a= nd LSA messages, for instance, makes sense when there are two scopes (local an= d multi-hop global). For networks in which all routers are neighbors, one of = both mechanisms could be not used. Hellos are necessary for establishing bidirectional communication. The only information that LSA may provide (and= not Hellos) is link costs. Why not consider the inclusion of such information i= n Hellos, as in RFC 5449? In this case, that would be sufficient for computin= g the SPT.

=A0

10) This appl= ies as well, at some extent, to the use of adjacencies. Since LSAs are "heard" and processed from all bidirectional neighbors (and not o= nly adjacent), the only interest of adjacent links is reliability of flooding a= nd the exchange of local instances of the LSDB. Allowing a router to synchroni= ze its LSDB with a neighbor may reduce the time required for acquiring the las= t topology updates. It should however be evaluated the cost in terms of overh= ead of keeping adjacencies for such synchronizing time reduction. If the networ= k is fixed, then it may be acceptable; for some mobile scenarios (still single-h= op broadcast), it may become excessive.

=A0

Cheers,

=A0

Juan Antonio Cordero

Hipercom -- INRIA

=A0


2011/5/1= 3 <ospf-request@ietf.org>
If you have received this digest without all= the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

ht= tps://www.ietf.org/mailman/listinfo/ospf

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send OSPF mailing list submissions to
=A0 =A0 =A0 =A0ospf@iet= f.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/ospf
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0= ospf-request@ietf.org

You can reach the person managing the list at
=A0 =A0 =A0 =A0os= pf-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OSPF digest..."


Today's Topics:

=A0 1. Re: =A0Single Hop MANET versus Broadcast/P2MP Hybrid Interface
=A0 =A0 =A0(Henderson, Thomas R)
=A0 2. Re: =A0Single Hop MANET versus Broadcast/P2MP Hybrid Interface
=A0 =A0 =A0(Emmanuel Baccelli)
=A0 3. Re: =A0Single Hop MANET versus Broadcast/P2MP Hybrid Interface
=A0 =A0 =A0(Stan Ratliff)
=A0 4. Re: =A0Adoption of "OSPF Stub Router Advertisement"
=A0 =A0 =A0(rfc3137bis) as WG Document (Acee Lindem)


----------------------------------------------------------------------

Message: 1
Date: Thu, 12 May 2011 13:06:36 -0700
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: "'Acee Lindem'" <acee.lindem@ericsson.com>
Cc: OSPF List <ospf@i= etf.org>
Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
=A0 =A0 =A0 =A0Interface
Message-ID:
=A0 =A0 =A0 =A0<7CC566635CFE364D87DC5= 803D4712A6C4CEED717C8@XCH-NW-10V.nw.nos.boeing.com>

Content-Type: text/plain; charset=3D"us-ascii"

> Hence, the questions for the WG are:
>
>
> =A0 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > 01.txt as a WG document?
>
> https://datatracker.ietf.org/doc/draft-nsheth-= ospf-hybrid-bcast-and-
> p2mp

I have no objection.

>
> =A0 2. Do we wish to allow revisions of the OSPF MANET experimental RF= Cs
> to cover the single-hop case (and possibly minor corrections)?
>
> https://datatracker.ietf.org/doc/rfc5449/
> https://datatracker.ietf.org/doc/rfc5614/
> https://datatracker.ietf.org/doc/rfc5820/
>

I would be interested to work on this.

- Tom


------------------------------

Message: 2
Date: Thu, 12 May 2011 22:14:48 +0200
From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
To: OSPF List <ospf@i= etf.org>
Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
=A0 =A0 =A0 =A0Interface
Message-ID: <BANLkTimEkkPbZTU+YigYhPhZ51OX_OhENw@mail.gma= il.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R <
thomas.r= .henderson@boeing.com> wrote:

> > Hence, the questions for the WG are:
> >
> >
> > =A0 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2= mp-
> > 01.txt as a WG document?
> >
> > https://datatracker.ietf.org/doc/draft-ns= heth-ospf-hybrid-bcast-and-
> > p2mp
>
> I have no objection.
>


+1



>
> >
> > =A0 2. Do we wish to allow revisions of the OSPF MANET experiment= al RFCs
> > to cover the single-hop case (and possibly minor corrections)? > >
> > https://datatracker.ietf.org/doc/rfc5449/
> > https://datatracker.ietf.org/doc/rfc5614/
> > https://datatracker.ietf.org/doc/rfc5820/
> >
>
> I would be interested to work on this.
>


Count me in too!

Emmanuel



>
> - Tom
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail= -archive/web/ospf/attachments/20110512/738639c2/attachment.htm>

------------------------------

Message: 3
Date: Thu, 12 May 2011 16:20:21 -0400
From: Stan Ratliff <sratliff@cisco.com>
To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Cc: OSPF List <ospf@i= etf.org>
Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
=A0 =A0 =A0 =A0Interface
Message-ID: <E4FDD8DA-B1EF-4BE8-B73C-D189BC51D9BB@cisco.com= >
Content-Type: text/plain; charset=3D"us-ascii"; Format=3D"fl= owed";
=A0 =A0 =A0 =A0DelSp=3D"yes"

Yes on both questions.

Regards,
Stan

On May 12, 2011, at 4:14 PM, Emmanuel Baccelli wrote:

>
>
> On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R <thomas.r.henderson@b= oeing.com
> > wrote:
> > Hence, the questions for the WG are:
> >
> >
> > =A0 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2= mp-
> > 01.txt as a WG document?
> >
> > https://datatracker.ietf.org/doc/draft-ns= heth-ospf-hybrid-bcast-and-
> > p2mp
>
> I have no objection.
>
>
> +1
>
>
>
> >
> > =A0 2. Do we wish to allow revisions of the OSPF MANET experiment= al
> RFCs
> > to cover the single-hop case (and possibly minor corrections)? > >
> > https://datatracker.ietf.org/doc/rfc5449/
> > https://datatracker.ietf.org/doc/rfc5614/
> > https://datatracker.ietf.org/doc/rfc5820/
> >
>
> I would be interested to work on this.
>
>
> Count me in too!
>
> Emmanuel
>
>
>
> - Tom
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail= -archive/web/ospf/attachments/20110512/a8c352b9/attachment.htm>

------------------------------

Message: 4
Date: Fri, 13 May 2011 09:59:42 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: "Retana, Alvaro" <alvaro.retana@hp.com>
Cc: "dmcp= herson@verisign.com" <dmcpherson@verisign.com>,
=A0 =A0 =A0 =A0"os= pf@ietf.org" <ospf@ietf.org>, "russwh@cisco.com"
=A0 =A0 =A0 =A0<r= usswh@cisco.com>, =A0 =A0 "azinin@cisco.com" <azinin@cisco.com>
Subject: Re: [OSPF] Adoption of "OSPF Stub Router Advertisement"<= br> =A0 =A0 =A0 =A0(rfc3137bis) as WG Document
Message-ID: <901AD859-684E-4DD7-A8FA-8F7276AD007A@ericsson.c= om>
Content-Type: text/plain; charset=3D"Windows-1252"

All,
At the WG meeting, we tentatively agreed that this RFC 3137 revision is nee= ded in lieu of a separate document for OSPFv3 stub router. Is there anyone = opposed to this becoming a WG document? If there is not significant opposit= ion, we'll make it a WG document on Friday, May 20th (in one week).
Thanks,
Acee
On May 9, 2011, at 3:54 PM, Retana, Alvaro wrote:

Hi!

Following up on the WG meeting in Prague?

http://tools.ietf.org/html/draft-retana-ospf-rfc3137bis

We just published version -01. =A0The only change from -00 is an update on = the authors? contact information.

This e-mail is the formal request for adoption as a WG document. =A0Just li= ke rfc 3137, the intended status is Informational.

Thoughts/comments?

Thanks!

Alvaro.


_______________________________________________
OSPF mailing list
OSPF@ietf.org<mai= lto:OSPF@ietf.org>= ;
ht= tps://www.ietf.org/mailman/listinfo/ospf



------------------------------

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf


End of OSPF Digest, Vol 63, Issue 10
************************************

--0016e6475d7aafe76204a358075e-- From j.a.cordero@gmail.com Sun May 15 15:29:00 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD77E06EF for ; Sun, 15 May 2011 15:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_STILLSINGLE=1.66] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sc0Xz9NuzGk for ; Sun, 15 May 2011 15:28:58 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A673CE06F7 for ; Sun, 15 May 2011 15:28:57 -0700 (PDT) Received: by vxg33 with SMTP id 33so3333091vxg.31 for ; Sun, 15 May 2011 15:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=01+Psmctg0X//4qDAc35zlS0xsm81QvhTzTskJBun5A=; b=UsvDSyjo6EcFFKaYnBUTTaSrrF7wCq13SJTGgTw+Zldpx87twlYlpeh5/mrFB3fdij JQPYFyBg2qhufMzCPs3QkeETgR8hWjbVs0Z3JNyYdVCNcr0SnBln8/KC3wh4ikM+Hvy3 w0lLctPS43dDAHPo+Exg5h+IkvNbx1hAuEo+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xkfV+OgS3/YPdX5fak4kDec6p82VZCELAHvj3e8NodtmzD3fg5Z31M/dkoejrgkv6P mtz4btAOHY4O5delJdg+f7KZCNuZHcX2lGiHI9FZfv3/swpEOyME7EOanGI3y9rKnNrI +wYhkln3gvCWEZwLFzaUUfT2XfRwZPzFBxjwQ= MIME-Version: 1.0 Received: by 10.52.179.6 with SMTP id dc6mr5331486vdc.222.1305498536903; Sun, 15 May 2011 15:28:56 -0700 (PDT) Received: by 10.220.180.67 with HTTP; Sun, 15 May 2011 15:28:56 -0700 (PDT) Date: Mon, 16 May 2011 00:28:56 +0200 Message-ID: From: Juan Antonio Cordero Fuertes To: ospf@ietf.org Content-Type: multipart/alternative; boundary=bcaec5196a478c05e204a358102f Subject: [OSPF] Comments on draft-retana-ospf-manet-single-hop-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 15 May 2011 22:29:00 -0000 --bcaec5196a478c05e204a358102f Content-Type: text/plain; charset=ISO-8859-1 ...sorry for not changing the subject. Juan Antonio > Hi Alvaro, > > > > Some comments/thoughts/questions about > draft-retana-ospf-manet-single-hop-01 > below. Thanks in advance for your attention. > > > > 0) The position of routers in the networks addressed in this interface, is > fixed or may move as long full connectivity (1-hop) remains? In section 6 > it > is said that these are fixed networks, but this characteristic is not > listed > when describing single-hop broadcast networks in section 1.1. > > > > *About Hellos:* > > > > 1) Incremental Hellos are not used (required) in this proposal. However, in > a single-hop MANET, (full) Hellos of any router list all routers in the > network every HelloInterval seconds. Since the topology is static (not > considering wireless link failures or changes in the link cost), may it be > worth to explore a Hello optimization mechanism? Not only incremental > Hellos > but also, possibly, differential Hellos as specified in RFC 5614. > > > > *About Smart Peering:* > > > > 2) The proposed heuristic in section 3, is expected to replace or to > complement the one presented in RFC 5820? Might be useful to make it more > explicit. I assume that the proposed heuristic comes right after the one in > RFC 5820 -- otherwise the number of adjacency-forming processes might be > higher, some of them redundant. Is that correct? > > > > 3) Wait Time[r] mentioned in section 3 is defined in RFC 2328 as > RouterDeadInterval. Why tying the waiting time before running the SP state > machine to such RouterDeadInterval value? Wouldn't HelloInterval be > sufficient? If the goal is to ensure that the router has information about > all neighbors from the network, a user-configurable parameter within the > interval [HelloInterval, RouterDeadInterval] may be useful. > > > > 4) If I'm understanding correctly, the number of adjacencies maintained by > a > router may be higher than the parameter "maximum number of adjacencies". > Consider for instance MAX_ADJ=2 and 4 routers in a single-hop MANET with > ids > (actually, (RtrPri,RtrId)) 1,2,3,4, that appear in the network (are > discovered) in order 4-3-2-1: 4 has three adjacencies. Seems that the > "maximum number of adjacencies" corresponds to the number of REQUESTED > adjacencies for a router, which is <= than the final number of adjacencies, > given that routers accept passively any adjacency-forming request. > > > > 5) It is not clear for me in which sense the proposed heuristic is > deterministic. Consider again a 4 nodes single-hop network with ids > 1,2,3,4. > Depending on the order of appearance, the adjacency subgraph changes (e.g., > for an appearance order 1-2-3-4 the adjacencies 12, 23, 34 are formed; for > the appearance order 4-3-2-1 the formed adjacencies are 14, 24, 34). That > is, the adjacency map cannot be extracted from the final topology of the > network. > > > > *About Unsynchronized adjacencies:* > > > > 6) From section 4, it is not clear whether the use of unsynchronized > adjacencies is required, possible, not necessary or not acceptable. In my > understanding, they are required for correct operation of the interface. > Not > only for flooding issues, as detailed in the text, but also for shortest > paths computation. If all bidirectional neighbors (thus, adjacencies + > unsynch.adj.) are not listed in LSAs, the Shortest Path Tree is computed on > a pretty fictional and suboptimal topology -- even in a higher degree than > in original RFC 5820. Both reasons (flooding in control plane and SPT in > data plane) justify the mandatory use of u.a. in this interface. > > > > *More general considerations:* > > > > 7) Seems to me that the mechanisms presented in this draft, while described > as generalizations of RFC 5820, may be applied as well to other extensions, > e.g. RFC 5449. Specific mechanisms from OR/SP are either discarded or > severely adapted: Incremental Hellos are not used, Smart Peering is > (re)defined in a way such that a new router selects only one existing > router > for synchronization, and the use of unsynchronized adjacencies corresponds > to taking into account bidirectional neighbors in Router-LSAs. Maybe it is > worth to describe an general interface to which existing extensions should > converge when running in these single-hop bc networks? > > > > 8) *Behavior of MPR-OSPF in single-hop bc networks.* The use of the > MPR-OSPF > MANET interface in the single-hop bc leads to a behavior pretty similar to > the one specified in the draft. As no MPRs will be elected (because there > are no 2-hop neighbors), the only adjacencies will be those performed by > the > synch router -- by definition, there is only a synch router in the network, > and its election (based on the router id) is similar to the heuristic > proposed in section 3. Router-LSAs would only describe Path-MPRs, but the > SPT would be computed correctly (i.e., not suboptimally) due to the fact > that routers use all their 1-hop and 2-hop neighbors when running > Dijkstra's. Finally, Router-LSAs would be processed and installed > regardless > on whether they come from an adjacent neighbor or not; all LSAs coming from > bidirectional neighbors are processed in MPR-OSPF. None of such LSAs would > be forwarded at any time, since they cannot come from an MPR selector. > > > > 9) Even when this may be out of scope, some central aspects of OSPF are > clearly useless in networks such as the ones addressed in this draft. The > existence of Hello and LSA messages, for instance, makes sense when there > are two scopes (local and multi-hop global). For networks in which all > routers are neighbors, one of both mechanisms could be not used. Hellos are > necessary for establishing bidirectional communication. The only > information > that LSA may provide (and not Hellos) is link costs. Why not consider the > inclusion of such information in Hellos, as in RFC 5449? In this case, that > would be sufficient for computing the SPT. > > > > 10) This applies as well, at some extent, to the use of adjacencies. Since > LSAs are "heard" and processed from all bidirectional neighbors (and not > only adjacent), the only interest of adjacent links is reliability of > flooding and the exchange of local instances of the LSDB. Allowing a router > to synchronize its LSDB with a neighbor may reduce the time required for > acquiring the last topology updates. It should however be evaluated the > cost > in terms of overhead of keeping adjacencies for such synchronizing time > reduction. If the network is fixed, then it may be acceptable; for some > mobile scenarios (still single-hop broadcast), it may become excessive. > > > > Cheers, > > > > Juan Antonio Cordero > > Hipercom -- INRIA > > > > 2011/5/13 > > > If you have received this digest without all the individual message > > attachments you will need to update your digest options in your list > > subscription. To do so, go to > > > > https://www.ietf.org/mailman/listinfo/ospf > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > MIME or Plain Text Digests?" to MIME. You can set this option > > globally for all the list digests you receive at this point. > > > > > > > > Send OSPF mailing list submissions to > > ospf@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/ospf > > or, via email, send a message with subject or body 'help' to > > ospf-request@ietf.org > > > > You can reach the person managing the list at > > ospf-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of OSPF digest..." > > > > > > Today's Topics: > > > > 1. Re: Single Hop MANET versus Broadcast/P2MP Hybrid Interface > > (Henderson, Thomas R) > > 2. Re: Single Hop MANET versus Broadcast/P2MP Hybrid Interface > > (Emmanuel Baccelli) > > 3. Re: Single Hop MANET versus Broadcast/P2MP Hybrid Interface > > (Stan Ratliff) > > 4. Re: Adoption of "OSPF Stub Router Advertisement" > > (rfc3137bis) as WG Document (Acee Lindem) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Thu, 12 May 2011 13:06:36 -0700 > > From: "Henderson, Thomas R" > > To: "'Acee Lindem'" > > Cc: OSPF List > > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid > > Interface > > Message-ID: > > < > > 7CC566635CFE364D87DC5803D4712A6C4CEED717C8@XCH-NW-10V.nw.nos.boeing.com> > > > > Content-Type: text/plain; charset="us-ascii" > > > > > Hence, the questions for the WG are: > > > > > > > > > 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > > > 01.txt as a WG document? > > > > > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and- > > > p2mp > > > > I have no objection. > > > > > > > > 2. Do we wish to allow revisions of the OSPF MANET experimental RFCs > > > to cover the single-hop case (and possibly minor corrections)? > > > > > > https://datatracker.ietf.org/doc/rfc5449/ > > > https://datatracker.ietf.org/doc/rfc5614/ > > > https://datatracker.ietf.org/doc/rfc5820/ > > > > > > > I would be interested to work on this. > > > > - Tom > > > > > > ------------------------------ > > > > Message: 2 > > Date: Thu, 12 May 2011 22:14:48 +0200 > > From: Emmanuel Baccelli > > To: OSPF List > > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid > > Interface > > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > > > On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R < > > thomas.r.henderson@boeing.com> wrote: > > > > > > Hence, the questions for the WG are: > > > > > > > > > > > > 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > > > > 01.txt as a WG document? > > > > > > > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and- > > > > p2mp > > > > > > I have no objection. > > > > > > > > > +1 > > > > > > > > > > > > > > > > > 2. Do we wish to allow revisions of the OSPF MANET experimental > RFCs > > > > to cover the single-hop case (and possibly minor corrections)? > > > > > > > > https://datatracker.ietf.org/doc/rfc5449/ > > > > https://datatracker.ietf.org/doc/rfc5614/ > > > > https://datatracker.ietf.org/doc/rfc5820/ > > > > > > > > > > I would be interested to work on this. > > > > > > > > > Count me in too! > > > > Emmanuel > > > > > > > > > > > > - Tom > > > _______________________________________________ > > > OSPF mailing list > > > OSPF@ietf.org > > > https://www.ietf.org/mailman/listinfo/ospf > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > http://www.ietf.org/mail-archive/web/ospf/attachments/20110512/738639c2/attachment.htm > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Thu, 12 May 2011 16:20:21 -0400 > > From: Stan Ratliff > > To: Emmanuel Baccelli > > Cc: OSPF List > > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid > > Interface > > Message-ID: > > Content-Type: text/plain; charset="us-ascii"; Format="flowed"; > > DelSp="yes" > > > > Yes on both questions. > > > > Regards, > > Stan > > > > On May 12, 2011, at 4:14 PM, Emmanuel Baccelli wrote: > > > > > > > > > > > On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R < > > thomas.r.henderson@boeing.com > > > > wrote: > > > > Hence, the questions for the WG are: > > > > > > > > > > > > 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp- > > > > 01.txt as a WG document? > > > > > > > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and- > > > > p2mp > > > > > > I have no objection. > > > > > > > > > +1 > > > > > > > > > > > > > > > > > 2. Do we wish to allow revisions of the OSPF MANET experimental > > > RFCs > > > > to cover the single-hop case (and possibly minor corrections)? > > > > > > > > https://datatracker.ietf.org/doc/rfc5449/ > > > > https://datatracker.ietf.org/doc/rfc5614/ > > > > https://datatracker.ietf.org/doc/rfc5820/ > > > > > > > > > > I would be interested to work on this. > > > > > > > > > Count me in too! > > > > > > Emmanuel > > > > > > > > > > > > - Tom > > > _______________________________________________ > > > OSPF mailing list > > > OSPF@ietf.org > > > https://www.ietf.org/mailman/listinfo/ospf > > > > > > _______________________________________________ > > > OSPF mailing list > > > OSPF@ietf.org > > > https://www.ietf.org/mailman/listinfo/ospf > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > http://www.ietf.org/mail-archive/web/ospf/attachments/20110512/a8c352b9/attachment.htm > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Fri, 13 May 2011 09:59:42 -0400 > > From: Acee Lindem > > To: "Retana, Alvaro" > > Cc: "dmcpherson@verisign.com" , > > "ospf@ietf.org" , "russwh@cisco.com" > > , "azinin@cisco.com" > > Subject: Re: [OSPF] Adoption of "OSPF Stub Router Advertisement" > > (rfc3137bis) as WG Document > > Message-ID: <901AD859-684E-4DD7-A8FA-8F7276AD007A@ericsson.com> > > Content-Type: text/plain; charset="Windows-1252" > > > > All, > > At the WG meeting, we tentatively agreed that this RFC 3137 revision is > > needed in lieu of a separate document for OSPFv3 stub router. Is there > > anyone opposed to this becoming a WG document? If there is not > significant > > opposition, we'll make it a WG document on Friday, May 20th (in one > week). > > Thanks, > > Acee > > On May 9, 2011, at 3:54 PM, Retana, Alvaro wrote: > > > > Hi! > > > > Following up on the WG meeting in Prague? > > > > http://tools.ietf.org/html/draft-retana-ospf-rfc3137bis > > > > We just published version -01. The only change from -00 is an update on > > the authors? contact information. > > > > This e-mail is the formal request for adoption as a WG document. Just > like > > rfc 3137, the intended status is Informational. > > > > Thoughts/comments? > > > > Thanks! > > > > Alvaro. > > > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > > > > > > ------------------------------ > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > > > > End of OSPF Digest, Vol 63, Issue 10 > > ************************************ > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/ospf/attachments/20110516/e0f257c4/attachment.htm > > > > ------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > > End of OSPF Digest, Vol 63, Issue 11 > ************************************ > --bcaec5196a478c05e204a358102f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
...sorry for not changing the subject.

Juan Antonio
=A0
Hi Alvaro,



Some comments/thoughts/questions about draft-retana-ospf-manet-single-hop-0= 1
below. Thanks in advance for your attention.



0) The position of routers in the networks addressed in this interface, is<= br> fixed or may move as long full connectivity (1-hop) remains? In section 6 i= t
is said that these are fixed networks, but this characteristic is not liste= d
when describing single-hop broadcast networks in section 1.1.



*About Hellos:*



1) Incremental Hellos are not used (required) in this proposal. However, in=
a single-hop MANET, (full) Hellos of any router list all routers in the
network every HelloInterval seconds. Since the topology is static (not
considering wireless link failures or changes in the link cost), may it be<= br> worth to explore a Hello optimization mechanism? Not only incremental Hello= s
but also, possibly, differential Hellos as specified in RFC 5614.



*About Smart Peering:*



2) The proposed heuristic in section 3, is expected to replace or to
complement the one presented in RFC 5820? Might be useful to make it more explicit. I assume that the proposed heuristic comes right after the one in=
RFC 5820 -- otherwise the number of adjacency-forming processes might be higher, some of them redundant. Is that correct?



3) Wait Time[r] mentioned in section 3 is defined in RFC 2328 as
RouterDeadInterval. Why tying the waiting time before running the SP state<= br> machine to such RouterDeadInterval value? Wouldn't HelloInterval be
sufficient? If the goal is to ensure that the router has information about<= br> all neighbors from the network, a user-configurable parameter within the interval [HelloInterval, RouterDeadInterval] may be useful.



4) If I'm understanding correctly, the number of adjacencies maintained= by a
router may be higher than the parameter "maximum number of adjacencies= ".
Consider for instance MAX_ADJ=3D2 and 4 routers in a single-hop MANET with = ids
(actually, (RtrPri,RtrId)) 1,2,3,4, that appear in the network (are
discovered) in order 4-3-2-1: 4 has three adjacencies. Seems that the
"maximum number of adjacencies" corresponds to the number of REQU= ESTED
adjacencies for a router, which is <=3D than the final number of adjacen= cies,
given that routers accept passively any adjacency-forming request.



5) It is not clear for me in which sense the proposed heuristic is
deterministic. Consider again a 4 nodes single-hop network with ids 1,2,3,4= .
Depending on the order of appearance, the adjacency subgraph changes (e.g.,=
for an appearance order 1-2-3-4 the adjacencies 12, 23, 34 are formed; for<= br> the appearance order 4-3-2-1 the formed adjacencies are 14, 24, 34). That is, the adjacency map cannot be extracted from the final topology of the network.



*About Unsynchronized adjacencies:*



6) From section 4, it is not clear whether the use of unsynchronized
adjacencies is required, possible, not necessary or not acceptable. In my understanding, they are required for correct operation of the interface. No= t
only for flooding issues, as detailed in the text, but also for shortest paths computation. If all bidirectional neighbors (thus, adjacencies +
unsynch.adj.) are not listed in LSAs, the Shortest Path Tree is computed on=
a pretty fictional and suboptimal topology -- even in a higher degree than<= br> in original RFC 5820. Both reasons (flooding in control plane and SPT in data plane) justify the mandatory use of u.a. in this interface.



*More general considerations:*



7) Seems to me that the mechanisms presented in this draft, while described=
as generalizations of RFC 5820, may be applied as well to other extensions,=
e.g. RFC 5449. Specific mechanisms from OR/SP are either discarded or
severely adapted: Incremental Hellos are not used, Smart Peering is
(re)defined in a way such that a new router selects only one existing route= r
for synchronization, and the use of unsynchronized adjacencies corresponds<= br> to taking into account bidirectional neighbors in Router-LSAs. Maybe it is<= br> worth to describe an general interface to which existing extensions should<= br> converge when running in these single-hop bc networks?



8) *Behavior of MPR-OSPF in single-hop bc networks.* The use of the MPR-OSP= F
MANET interface in the single-hop bc leads to a behavior pretty similar to<= br> the one specified in the draft. As no MPRs will be elected (because there are no 2-hop neighbors), the only adjacencies will be those performed by th= e
synch router -- by definition, there is only a synch router in the network,=
and its election (based on the router id) is similar to the heuristic
proposed in section 3. Router-LSAs would only describe Path-MPRs, but the SPT would be computed correctly (i.e., not suboptimally) due to the fact that routers use all their 1-hop and 2-hop neighbors when running
Dijkstra's. Finally, Router-LSAs would be processed and installed regar= dless
on whether they come from an adjacent neighbor or not; all LSAs coming from=
bidirectional neighbors are processed in MPR-OSPF. None of such LSAs would<= br> be forwarded at any time, since they cannot come from an MPR selector.



9) Even when this may be out of scope, some central aspects of OSPF are
clearly useless in networks such as the ones addressed in this draft. The existence of Hello and LSA messages, for instance, makes sense when there are two scopes (local and multi-hop global). For networks in which all
routers are neighbors, one of both mechanisms could be not used. Hellos are=
necessary for establishing bidirectional communication. The only informatio= n
that LSA may provide (and not Hellos) is link costs. Why not consider the inclusion of such information in Hellos, as in RFC 5449? In this case, that=
would be sufficient for computing the SPT.



10) This applies as well, at some extent, to the use of adjacencies. Since<= br> LSAs are "heard" and processed from all bidirectional neighbors (= and not
only adjacent), the only interest of adjacent links is reliability of
flooding and the exchange of local instances of the LSDB. Allowing a router=
to synchronize its LSDB with a neighbor may reduce the time required for acquiring the last topology updates. It should however be evaluated the cos= t
in terms of overhead of keeping adjacencies for such synchronizing time
reduction. If the network is fixed, then it may be acceptable; for some
mobile scenarios (still single-hop broadcast), it may become excessive.



Cheers,



Juan Antonio Cordero

Hipercom -- INRIA



2011/5/13 <ospf-request@ietf.or= g>

> If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. =A0To do so, go to
>
> https://www.ietf.org/mailman/listinfo/ospf
>
> Click the 'Unsubscribe or edit options' button, log in, and se= t "Get
> MIME or Plain Text Digests?" to MIME. =A0You can set this option<= br> > globally for all the list digests you receive at this point.
>
>
>
> Send OSPF mailing list submissions to
> =A0 =A0 =A0 =A0ospf@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> =A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/ospf
> or, via email, send a message with subject or body 'help' to > =A0 =A0 =A0 =A0ospf-request@i= etf.org
>
> You can reach the person managing the list at
> =A0 =A0 =A0 =A0ospf-owner@ietf.= org
>
> When replying, please edit your Subject line so it is more specific > than "Re: Contents of OSPF digest..."
>
>
> Today's Topics:
>
> =A0 1. Re: =A0Single Hop MANET versus Broadcast/P2MP Hybrid Interface<= br> > =A0 =A0 =A0(Henderson, Thomas R)
> =A0 2. Re: =A0Single Hop MANET versus Broadcast/P2MP Hybrid Interface<= br> > =A0 =A0 =A0(Emmanuel Baccelli)
> =A0 3. Re: =A0Single Hop MANET versus Broadcast/P2MP Hybrid Interface<= br> > =A0 =A0 =A0(Stan Ratliff)
> =A0 4. Re: =A0Adoption of "OSPF Stub Router Advertisement" > =A0 =A0 =A0(rfc3137bis) as WG Document (Acee Lindem)
>
>
> ----------------------------------------------------------------------=
>
> Message: 1
> Date: Thu, 12 May 2011 13:06:36 -0700
> From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
> To: "'Acee Lindem'" <acee.lindem@ericsson.com>
> Cc: OSPF List <ospf@ietf.org&g= t;
> Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
> =A0 =A0 =A0 =A0Interface
> Message-ID:
> =A0 =A0 =A0 =A0<
> 7CC566635CFE364D87DC5803D4712A6C4CEED717C8@XCH-NW-10V.= nw.nos.boeing.com>
>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> > Hence, the questions for the WG are:
> >
> >
> > =A0 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2= mp-
> > 01.txt as a WG document?
> >
> > https://datatracker.ietf.org/doc/draft-ns= heth-ospf-hybrid-bcast-and-
> > p2mp
>
> I have no objection.
>
> >
> > =A0 2. Do we wish to allow revisions of the OSPF MANET experiment= al RFCs
> > to cover the single-hop case (and possibly minor corrections)? > >
> > https://datatracker.ietf.org/doc/rfc5449/
> > https://datatracker.ietf.org/doc/rfc5614/
> > https://datatracker.ietf.org/doc/rfc5820/
> >
>
> I would be interested to work on this.
>
> - Tom
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 12 May 2011 22:14:48 +0200
> From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
> To: OSPF List <ospf@ietf.org&g= t;
> Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
> =A0 =A0 =A0 =A0Interface
> Message-ID: <BANLkTimEkkPbZTU+YigYhPhZ51OX_OhENw@mail.gmail.com>= ;
> Content-Type: text/plain; charset=3D"iso-8859-1"
>
> On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R <
> thomas.r.henderson@bo= eing.com> wrote:
>
> > > Hence, the questions for the WG are:
> > >
> > >
> > > =A0 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-a= nd-p2mp-
> > > 01.txt as a WG document?
> > >
> > > https://datatracker.ietf.org/doc/dra= ft-nsheth-ospf-hybrid-bcast-and-
> > > p2mp
> >
> > I have no objection.
> >
>
>
> +1
>
>
>
> >
> > >
> > > =A0 2. Do we wish to allow revisions of the OSPF MANET exper= imental RFCs
> > > to cover the single-hop case (and possibly minor corrections= )?
> > >
> > > https://datatracker.ietf.org/doc/rfc5449/
> > > https://datatracker.ietf.org/doc/rfc5614/
> > > https://datatracker.ietf.org/doc/rfc5820/
> > >
> >
> > I would be interested to work on this.
> >
>
>
> Count me in too!
>
> Emmanuel
>
>
>
> >
> > - Tom
> > _______________________________________________
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-arc= hive/web/ospf/attachments/20110512/738639c2/attachment.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Thu, 12 May 2011 16:20:21 -0400
> From: Stan Ratliff <sratliff@= cisco.com>
> To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
> Cc: OSPF List <ospf@ietf.org&g= t;
> Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
> =A0 =A0 =A0 =A0Interface
> Message-ID: <E4FDD8DA-B1EF-4BE8-B73C-D189BC51D9BB@cisco.com>
> Content-Type: text/plain; charset=3D"us-ascii"; Format=3D&qu= ot;flowed";
> =A0 =A0 =A0 =A0DelSp=3D"yes"
>
> Yes on both questions.
>
> Regards,
> Stan
>
> On May 12, 2011, at 4:14 PM, Emmanuel Baccelli wrote:
>
> >
> >
> > On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R <
> thomas.r.henderson@bo= eing.com
> > > wrote:
> > > Hence, the questions for the WG are:
> > >
> > >
> > > =A0 1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-a= nd-p2mp-
> > > 01.txt as a WG document?
> > >
> > > https://datatracker.ietf.org/doc/dra= ft-nsheth-ospf-hybrid-bcast-and-
> > > p2mp
> >
> > I have no objection.
> >
> >
> > +1
> >
> >
> >
> > >
> > > =A0 2. Do we wish to allow revisions of the OSPF MANET exper= imental
> > RFCs
> > > to cover the single-hop case (and possibly minor corrections= )?
> > >
> > > https://datatracker.ietf.org/doc/rfc5449/
> > > https://datatracker.ietf.org/doc/rfc5614/
> > > https://datatracker.ietf.org/doc/rfc5820/
> > >
> >
> > I would be interested to work on this.
> >
> >
> > Count me in too!
> >
> > Emmanuel
> >
> >
> >
> > - Tom
> > _______________________________________________
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
> >
> > _______________________________________________
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-arc= hive/web/ospf/attachments/20110512/a8c352b9/attachment.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Fri, 13 May 2011 09:59:42 -0400
> From: Acee Lindem <acee= .lindem@ericsson.com>
> To: "Retana, Alvaro" <alvaro.retana@hp.com>
> Cc: "dmcpherson@verisi= gn.com" <dmcpherson@= verisign.com>,
> =A0 =A0 =A0 =A0"ospf@ietf.org" <ospf@ietf.org>, "<= a href=3D"mailto:russwh@cisco.com">russwh@cisco.com"
> =A0 =A0 =A0 =A0<russwh@cisco.co= m>, =A0 =A0 "azinin@cisco.c= om" <azinin@cisco.com&g= t;
> Subject: Re: [OSPF] Adoption of "OSPF Stub Router Advertisement&q= uot;
> =A0 =A0 =A0 =A0(rfc3137bis) as WG Document
> Message-ID: <901AD859-684E-4DD7-A8FA-8F7276AD007A@ericsson.com> > Content-Type: text/plain; charset=3D"Windows-1252"
>
> All,
> At the WG meeting, we tentatively agreed that this RFC 3137 revision i= s
> needed in lieu of a separate document for OSPFv3 stub router. Is there=
> anyone opposed to this becoming a WG document? If there is not signifi= cant
> opposition, we'll make it a WG document on Friday, May 20th (in on= e week).
> Thanks,
> Acee
> On May 9, 2011, at 3:54 PM, Retana, Alvaro wrote:
>
> Hi!
>
> Following up on the WG meeting in Prague?
>
> http://tools.ietf.org/html/draft-retana-ospf-rfc3137bis=
>
> We just published version -01. =A0The only change from -00 is an updat= e on
> the authors? contact information.
>
> This e-mail is the formal request for adoption as a WG document. =A0Ju= st like
> rfc 3137, the intended status is Informational.
>
> Thoughts/comments?
>
> Thanks!
>
> Alvaro.
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org<mailto:OSPF@ietf.org>
> https://www.ietf.org/mailman/listinfo/ospf
>
>
>
> ------------------------------
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
>
> End of OSPF Digest, Vol 63, Issue 10
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail= -archive/web/ospf/attachments/20110516/e0f257c4/attachment.htm>

------------------------------

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf


End of OSPF Digest, Vol 63, Issue 11
************************************

--bcaec5196a478c05e204a358102f-- From ogier@earthlink.net Mon May 16 23:02:21 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC862E07A9 for ; Mon, 16 May 2011 23:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dj3Kq8oNywVs for ; Mon, 16 May 2011 23:02:21 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9E1E07A8 for ; Mon, 16 May 2011 23:02:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mZ0n2Mi0T7g7+uyR2sqMOZ4zFyv/dzf+C5OYo/Tu1gSXLXnR24z0eh9RZF21FGmX; 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.105.164] by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QMDMG-0007c8-RM; Tue, 17 May 2011 02:02:18 -0400 Message-ID: <4DD20FEC.9080307@earthlink.net> Date: Mon, 16 May 2011 23:04:28 -0700 From: Richard Ogier 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: Juan Antonio Cordero Fuertes References: In-Reply-To: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478504bcfd8a9496c94cd4343d34ed48c99fd04410bf5c6a99f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.105.164 Cc: ospf@ietf.org Subject: Re: [OSPF] Comments on draft-retana-ospf-manet-single-hop-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 06:02:22 -0000 Juan,

Since you made some good comments for draft-retana and mentioned RFC 5614, I thought I would introduce the following update for RFC 5614 (OSPF-MDR) by addressing some of your comments as they would apply to it.

http://www.ietf.org/id/draft-ogier-ospf-manet-single-hop-00.txt

Please see my comments below.

Juan Antonio Cordero Fuertes wrote:
...sorry for not changing the subject.

Juan Antonio
 
Hi Alvaro,


Some comments/thoughts/questions about draft-retana-ospf-manet-single-hop-01
below. Thanks in advance for your attention.


0) The position of routers in the networks addressed in this interface, is
fixed or may move as long full connectivity (1-hop) remains? In section 6 it
is said that these are fixed networks, but this characteristic is not listed
when describing single-hop broadcast networks in section 1.1.


*About Hellos:*


1) Incremental Hellos are not used (required) in this proposal. However, in
a single-hop MANET, (full) Hellos of any router list all routers in the
network every HelloInterval seconds. Since the topology is static (not
considering wireless link failures or changes in the link cost), may it be
worth to explore a Hello optimization mechanism? Not only incremental Hellos
but also, possibly, differential Hellos as specified in RFC 5614.

I agree, and have included the option for differential Hellos in the update for RFC 5614.


*About Smart Peering:*



2) The proposed heuristic in section 3, is expected to replace or to
complement the one presented in RFC 5820? Might be useful to make it more
explicit. I assume that the proposed heuristic comes right after the one in
RFC 5820 -- otherwise the number of adjacency-forming processes might be
higher, some of them redundant. Is that correct?

The update for RFC 5614 describes two new procedures, both of which are optional.  One is a new option for constructing LSAs for a single-hop network, which is interoperable with the other LSA options and is similar to draft-nsheth.  The other is a simplification of the MDR selection algorithm for a single-hop network, which gives exactly the same result as the original algorithm when the MANET is a single-hop network (and is therefore interoperable with it).


3) Wait Time[r] mentioned in section 3 is defined in RFC 2328 as
RouterDeadInterval. Why tying the waiting time before running the SP state
machine to such RouterDeadInterval value? Wouldn't HelloInterval be
sufficient? If the goal is to ensure that the router has information about
all neighbors from the network, a user-configurable parameter within the
interval [HelloInterval, RouterDeadInterval] may be useful.


4) If I'm understanding correctly, the number of adjacencies maintained by a
router may be higher than the parameter "maximum number of adjacencies".
Consider for instance MAX_ADJ=2 and 4 routers in a single-hop MANET with ids
(actually, (RtrPri,RtrId)) 1,2,3,4, that appear in the network (are
discovered) in order 4-3-2-1: 4 has three adjacencies. Seems that the
"maximum number of adjacencies" corresponds to the number of REQUESTED
adjacencies for a router, which is <= than the final number of adjacencies,
given that routers accept passively any adjacency-forming request.

When OSPF-MDR is run in a single-hop network with AdjConnectivity = 2, every non-MDR/BMDR router will have exactly two adjacencies (one with the MDR and one with a BMDR).  The MDR will have n-1 adjacencies (same as the DR in OSPF).


5) It is not clear for me in which sense the proposed heuristic is
deterministic. Consider again a 4 nodes single-hop network with ids 1,2,3,4.
Depending on the order of appearance, the adjacency subgraph changes (e.g.,
for an appearance order 1-2-3-4 the adjacencies 12, 23, 34 are formed; for
the appearance order 4-3-2-1 the formed adjacencies are 14, 24, 34). That
is, the adjacency map cannot be extracted from the final topology of the
network.
I agree that the heuristic for draft-retana is not deterministic.  But the same is true for an OSPF broadcast network, since the first two routers that appear will be the DR and BDR.

In OSPF-MDR, if one router has higher RtrPri than the others, it will always be the MDR regardless of order of appearance.

Regards,
Richard


From ogier@earthlink.net Tue May 17 09:02:27 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2B3E0837 for ; Tue, 17 May 2011 09:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A97e1BhV4SWV for ; Tue, 17 May 2011 09:02:27 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE14E074C for ; Tue, 17 May 2011 09:02:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=r9sa5qyxNUno6si+0c5tFlf6D5bU2gihonAdePeNvNsva0I8M3X2zv2ns1Hb+MYI; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.255.243] by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QMMj3-0004sb-Ko for ospf@ietf.org; Tue, 17 May 2011 12:02:26 -0400 Message-ID: <4DD29C97.60705@earthlink.net> Date: Tue, 17 May 2011 09:04:39 -0700 From: Richard Ogier 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: "ospf@ietf.org" References: <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: a073897a9455599e74bf435c0eb9d478504bcfd8a9496c945583a1e5b3683aee97ebbe97a30ffb20350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.255.243 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 16:02:27 -0000 Section 3.6 of draft-nsheth-ospf-hybrid-bcast-and-p2mp-01 has the following rule: o If a router is not the DR and has a full adjacency to the DR, it MUST add a Type 1 link corresponding to each neighbor that is in state 2-Way or higher. Suppose i and j are non-DR routers. It seems to me that i should also require that the DR's router-LSA include a link to j before i adds a Type 1 link corresponding to j, in order to ensure that i and j are fully synchronized before either uses the other as a next hop. Is there a reason why this condition was omitted? To explain further, the SPT calculation (Section 16.1 of RFC 2328) requires that router j advertise a link back to router i before i can use j as a next hop (and vice versa). Thus, routers i and j can use each other as a next hop if they both advertise a link to each other. Therefore, the above rule from draft-nsheth only ensures that routers i and j are fully adjacent with the DR before either can use the other as a next hop. As a result, the DR might not be fully adjacent with router i or j, and thus i and j may not be fully synchronized. Note that full adjacency with a neighbor does not imply that the link state databases are synchronized (see footnote 23 in RFC 2328). It only means that the router is at least as up-to-date as the neighbor, since it only means that all Link State Requests have been satisfied. Please correct me if I am mistaken. Richard From ogier@earthlink.net Wed May 18 12:21:23 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2840E06B1 for ; Wed, 18 May 2011 12:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, SARE_STILLSINGLE=1.66] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPoUP1goPCGA for ; Wed, 18 May 2011 12:21:22 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6383FE06B0 for ; Wed, 18 May 2011 12:21:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=hPvsMxE+FZd8L/Z4dhwBc8++/ToBQ5dmkKfhkuNrDpXImr2DgHRStwdHTPD5paPm; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.248.183] by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QMmJ2-0003oA-U7; Wed, 18 May 2011 15:21:21 -0400 Message-ID: <4DD41CB3.40209@earthlink.net> Date: Wed, 18 May 2011 12:23:31 -0700 From: Richard Ogier 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: Juan Antonio Cordero Fuertes , ospf@ietf.org References: In-Reply-To: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478504bcfd8a9496c941203bc9f30e53bcf556867d709dc9bb9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.248.183 Subject: Re: [OSPF] Comments on draft-retana-ospf-manet-single-hop-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 19:21:24 -0000 I also have a few comments on draft-retana-ospf-manet-single-hop.

As Juan pointed out, if routers start one at a time, then using
(RtrPri, RID) won't help much unless the first or second router has
the largest value of (RtrPri, RID), since routers won't become adjacent
with the high priority router if they already have enough adjacencies.

One property of draft-retana is that there does not exist a router
(e.g., DR) that floods each LSA and is also adjacent with all other
routers, as in OSPF and the other proposals.  Having such a router is
a well-tested way to deliver LSAs reliably to all routers with minimal
delay.  It is not clear that the performance will be as good if such
a router does not exist.

Since draft-retana states that flooding should be enabled for
unsychronized adjacencies, I assume also that every router is a
non-active overlapping relay (OR).  That means that ANY router could
(re)flood an LSA after PushbackInterval if it does not hear an Ack
from every router.  (Note that all Acks are multicast, so I
assume that all routers process every received Ack.)
It was found in simulations several years ago that, if
PushbackInterval < RxmtInterval/2 (as required by RFC 5820) and
the number of routers is large, then several routers typically
reflood a given LSA, generating significant overhead.
(This was true even though an OR suppresses its transmission
when it hears another router reflood the LSA.)

I suppose this can be fixed by having only the router with the
largest value of (RtrPri, RID) be a non-active OR, and perhaps
also the router with the second largest value.
This would be like selecting a DR and BDR, and would be closer
to OSPF and the other proposals.

Regards,
Richard


Juan Antonio Cordero Fuertes wrote:
...sorry for not changing the subject.

Juan Antonio
 
Hi Alvaro,



Some comments/thoughts/questions about draft-retana-ospf-manet-single-hop-01
below. Thanks in advance for your attention.



0) The position of routers in the networks addressed in this interface, is
fixed or may move as long full connectivity (1-hop) remains? In section 6 it
is said that these are fixed networks, but this characteristic is not listed
when describing single-hop broadcast networks in section 1.1.



*About Hellos:*



1) Incremental Hellos are not used (required) in this proposal. However, in
a single-hop MANET, (full) Hellos of any router list all routers in the
network every HelloInterval seconds. Since the topology is static (not
considering wireless link failures or changes in the link cost), may it be
worth to explore a Hello optimization mechanism? Not only incremental Hellos
but also, possibly, differential Hellos as specified in RFC 5614.



*About Smart Peering:*



2) The proposed heuristic in section 3, is expected to replace or to
complement the one presented in RFC 5820? Might be useful to make it more
explicit. I assume that the proposed heuristic comes right after the one in
RFC 5820 -- otherwise the number of adjacency-forming processes might be
higher, some of them redundant. Is that correct?



3) Wait Time[r] mentioned in section 3 is defined in RFC 2328 as
RouterDeadInterval. Why tying the waiting time before running the SP state
machine to such RouterDeadInterval value? Wouldn't HelloInterval be
sufficient? If the goal is to ensure that the router has information about
all neighbors from the network, a user-configurable parameter within the
interval [HelloInterval, RouterDeadInterval] may be useful.



4) If I'm understanding correctly, the number of adjacencies maintained by a
router may be higher than the parameter "maximum number of adjacencies".
Consider for instance MAX_ADJ=2 and 4 routers in a single-hop MANET with ids
(actually, (RtrPri,RtrId)) 1,2,3,4, that appear in the network (are
discovered) in order 4-3-2-1: 4 has three adjacencies. Seems that the
"maximum number of adjacencies" corresponds to the number of REQUESTED
adjacencies for a router, which is <= than the final number of adjacencies,
given that routers accept passively any adjacency-forming request.



5) It is not clear for me in which sense the proposed heuristic is
deterministic. Consider again a 4 nodes single-hop network with ids 1,2,3,4.
Depending on the order of appearance, the adjacency subgraph changes (e.g.,
for an appearance order 1-2-3-4 the adjacencies 12, 23, 34 are formed; for
the appearance order 4-3-2-1 the formed adjacencies are 14, 24, 34). That
is, the adjacency map cannot be extracted from the final topology of the
network.



*About Unsynchronized adjacencies:*



6) From section 4, it is not clear whether the use of unsynchronized
adjacencies is required, possible, not necessary or not acceptable. In my
understanding, they are required for correct operation of the interface. Not
only for flooding issues, as detailed in the text, but also for shortest
paths computation. If all bidirectional neighbors (thus, adjacencies +
unsynch.adj.) are not listed in LSAs, the Shortest Path Tree is computed on
a pretty fictional and suboptimal topology -- even in a higher degree than
in original RFC 5820. Both reasons (flooding in control plane and SPT in
data plane) justify the mandatory use of u.a. in this interface.



*More general considerations:*



7) Seems to me that the mechanisms presented in this draft, while described
as generalizations of RFC 5820, may be applied as well to other extensions,
e.g. RFC 5449. Specific mechanisms from OR/SP are either discarded or
severely adapted: Incremental Hellos are not used, Smart Peering is
(re)defined in a way such that a new router selects only one existing router
for synchronization, and the use of unsynchronized adjacencies corresponds
to taking into account bidirectional neighbors in Router-LSAs. Maybe it is
worth to describe an general interface to which existing extensions should
converge when running in these single-hop bc networks?



8) *Behavior of MPR-OSPF in single-hop bc networks.* The use of the MPR-OSPF
MANET interface in the single-hop bc leads to a behavior pretty similar to
the one specified in the draft. As no MPRs will be elected (because there
are no 2-hop neighbors), the only adjacencies will be those performed by the
synch router -- by definition, there is only a synch router in the network,
and its election (based on the router id) is similar to the heuristic
proposed in section 3. Router-LSAs would only describe Path-MPRs, but the
SPT would be computed correctly (i.e., not suboptimally) due to the fact
that routers use all their 1-hop and 2-hop neighbors when running
Dijkstra's. Finally, Router-LSAs would be processed and installed regardless
on whether they come from an adjacent neighbor or not; all LSAs coming from
bidirectional neighbors are processed in MPR-OSPF. None of such LSAs would
be forwarded at any time, since they cannot come from an MPR selector.



9) Even when this may be out of scope, some central aspects of OSPF are
clearly useless in networks such as the ones addressed in this draft. The
existence of Hello and LSA messages, for instance, makes sense when there
are two scopes (local and multi-hop global). For networks in which all
routers are neighbors, one of both mechanisms could be not used. Hellos are
necessary for establishing bidirectional communication. The only information
that LSA may provide (and not Hellos) is link costs. Why not consider the
inclusion of such information in Hellos, as in RFC 5449? In this case, that
would be sufficient for computing the SPT.



10) This applies as well, at some extent, to the use of adjacencies. Since
LSAs are "heard" and processed from all bidirectional neighbors (and not
only adjacent), the only interest of adjacent links is reliability of
flooding and the exchange of local instances of the LSDB. Allowing a router
to synchronize its LSDB with a neighbor may reduce the time required for
acquiring the last topology updates. It should however be evaluated the cost
in terms of overhead of keeping adjacencies for such synchronizing time
reduction. If the network is fixed, then it may be acceptable; for some
mobile scenarios (still single-hop broadcast), it may become excessive.



Cheers,



Juan Antonio Cordero

Hipercom -- INRIA



2011/5/13 <ospf-request@ietf.org>

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/ospf
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send OSPF mailing list submissions to
>        ospf@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/ospf
> or, via email, send a message with subject or body 'help' to
>        ospf-request@ietf.org
>
> You can reach the person managing the list at
>        ospf-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OSPF digest..."
>
>
> Today's Topics:
>
>   1. Re:  Single Hop MANET versus Broadcast/P2MP Hybrid Interface
>      (Henderson, Thomas R)
>   2. Re:  Single Hop MANET versus Broadcast/P2MP Hybrid Interface
>      (Emmanuel Baccelli)
>   3. Re:  Single Hop MANET versus Broadcast/P2MP Hybrid Interface
>      (Stan Ratliff)
>   4. Re:  Adoption of "OSPF Stub Router Advertisement"
>      (rfc3137bis) as WG Document (Acee Lindem)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 12 May 2011 13:06:36 -0700
> From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
> To: "'Acee Lindem'" <acee.lindem@ericsson.com>
> Cc: OSPF List <ospf@ietf.org>
> Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
>        Interface
> Message-ID:
>        <
> 7CC566635CFE364D87DC5803D4712A6C4CEED717C8@XCH-NW-10V.nw.nos.boeing.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> > Hence, the questions for the WG are:
> >
> >
> >   1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp-
> > 01.txt as a WG document?
> >
> > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and-
> > p2mp
>
> I have no objection.
>
> >
> >   2. Do we wish to allow revisions of the OSPF MANET experimental RFCs
> > to cover the single-hop case (and possibly minor corrections)?
> >
> > https://datatracker.ietf.org/doc/rfc5449/
> > https://datatracker.ietf.org/doc/rfc5614/
> > https://datatracker.ietf.org/doc/rfc5820/
> >
>
> I would be interested to work on this.
>
> - Tom
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 12 May 2011 22:14:48 +0200
> From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
> To: OSPF List <ospf@ietf.org>
> Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
>        Interface
> Message-ID: <BANLkTimEkkPbZTU+YigYhPhZ51OX_OhENw@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R <
> thomas.r.henderson@boeing.com> wrote:
>
> > > Hence, the questions for the WG are:
> > >
> > >
> > >   1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp-
> > > 01.txt as a WG document?
> > >
> > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and-
> > > p2mp
> >
> > I have no objection.
> >
>
>
> +1
>
>
>
> >
> > >
> > >   2. Do we wish to allow revisions of the OSPF MANET experimental RFCs
> > > to cover the single-hop case (and possibly minor corrections)?
> > >
> > > https://datatracker.ietf.org/doc/rfc5449/
> > > https://datatracker.ietf.org/doc/rfc5614/
> > > https://datatracker.ietf.org/doc/rfc5820/
> > >
> >
> > I would be interested to work on this.
> >
>
>
> Count me in too!
>
> Emmanuel
>
>
>
> >
> > - Tom
> > _______________________________________________
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/ospf/attachments/20110512/738639c2/attachment.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Thu, 12 May 2011 16:20:21 -0400
> From: Stan Ratliff <sratliff@cisco.com>
> To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
> Cc: OSPF List <ospf@ietf.org>
> Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
>        Interface
> Message-ID: <E4FDD8DA-B1EF-4BE8-B73C-D189BC51D9BB@cisco.com>
> Content-Type: text/plain; charset="us-ascii"; Format="flowed";
>        DelSp="yes"
>
> Yes on both questions.
>
> Regards,
> Stan
>
> On May 12, 2011, at 4:14 PM, Emmanuel Baccelli wrote:
>
> >
> >
> > On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R <
> thomas.r.henderson@boeing.com
> > > wrote:
> > > Hence, the questions for the WG are:
> > >
> > >
> > >   1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp-
> > > 01.txt as a WG document?
> > >
> > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and-
> > > p2mp
> >
> > I have no objection.
> >
> >
> > +1
> >
> >
> >
> > >
> > >   2. Do we wish to allow revisions of the OSPF MANET experimental
> > RFCs
> > > to cover the single-hop case (and possibly minor corrections)?
> > >
> > > https://datatracker.ietf.org/doc/rfc5449/
> > > https://datatracker.ietf.org/doc/rfc5614/
> > > https://datatracker.ietf.org/doc/rfc5820/
> > >
> >
> > I would be interested to work on this.
> >
> >
> > Count me in too!
> >
> > Emmanuel
> >
> >
> >
> > - Tom
> > _______________________________________________
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
> >
> > _______________________________________________
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/ospf/attachments/20110512/a8c352b9/attachment.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Fri, 13 May 2011 09:59:42 -0400
> From: Acee Lindem <acee.lindem@ericsson.com>
> To: "Retana, Alvaro" <alvaro.retana@hp.com>
> Cc: "dmcpherson@verisign.com" <dmcpherson@verisign.com>,
>        "ospf@ietf.org" <ospf@ietf.org>, "russwh@cisco.com"
>        <russwh@cisco.com>,     "azinin@cisco.com" <azinin@cisco.com>
> Subject: Re: [OSPF] Adoption of "OSPF Stub Router Advertisement"
>        (rfc3137bis) as WG Document
> Message-ID: <901AD859-684E-4DD7-A8FA-8F7276AD007A@ericsson.com>
> Content-Type: text/plain; charset="Windows-1252"
>
> All,
> At the WG meeting, we tentatively agreed that this RFC 3137 revision is
> needed in lieu of a separate document for OSPFv3 stub router. Is there
> anyone opposed to this becoming a WG document? If there is not significant
> opposition, we'll make it a WG document on Friday, May 20th (in one week).
> Thanks,
> Acee
> On May 9, 2011, at 3:54 PM, Retana, Alvaro wrote:
>
> Hi!
>
> Following up on the WG meeting in Prague?
>
> http://tools.ietf.org/html/draft-retana-ospf-rfc3137bis
>
> We just published version -01.  The only change from -00 is an update on
> the authors? contact information.
>
> This e-mail is the formal request for adoption as a WG document.  Just like
> rfc 3137, the intended status is Informational.
>
> Thoughts/comments?
>
> Thanks!
>
> Alvaro.
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org<mailto:OSPF@ietf.org>
> https://www.ietf.org/mailman/listinfo/ospf
>
>
>
> ------------------------------
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
>
> End of OSPF Digest, Vol 63, Issue 10
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/ospf/attachments/20110516/e0f257c4/attachment.htm>

------------------------------

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf


End of OSPF Digest, Vol 63, Issue 11
************************************


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
From ogier@earthlink.net Thu May 19 10:28:47 2011 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0B9E06AE for ; Thu, 19 May 2011 10:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfJ39DEj-nrc for ; Thu, 19 May 2011 10:28:47 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id E7348E0658 for ; Thu, 19 May 2011 10:28:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=nG+kSwqX/O7OTGiITSVkf0mkdBnGJnzQWPoC76VxX+sxHFVAo/R7kfUDGOHeVH8O; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.249.123] by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QN71h-0006dX-IS for ospf@ietf.org; Thu, 19 May 2011 13:28:46 -0400 Message-ID: <4DD553D5.9020109@earthlink.net> Date: Thu, 19 May 2011 10:31:01 -0700 From: Richard Ogier 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: ospf@ietf.org References: <4DD41CB3.40209@earthlink.net> In-Reply-To: <4DD41CB3.40209@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478504bcfd8a9496c94d2769e9c89745e7064dcf1e7786ad75e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.249.123 Subject: Re: [OSPF] Comments on draft-retana-ospf-manet-single-hop-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 17:28:47 -0000 I thought about why it might be best to have a single router (e.g., DR) that floods each LSA and is also adjacent with all other routers. I think the following example shows that it is best to have such a router (versus smart peering). Consider a single-hop broadcast network with 3 routers having RIDs 1, 2, and 3. Assume 3 is adjacent to both 1 and 2. If OSPF (or draft-nsheth or OSPF-MDR) is used, router 3 will be the DR. (Even though each router should have at least 2 adjacencies, this uniconnected example will demonstrate my point.) 3 / \ 1 2 Suppose router 1 floods an LSA, but none of the other routers receive it. Router 1 will retransmit the LSA to router 3 after RxmtInterval if either OSPF or draft-retana is used. If OSPF is used, router 3 (the DR) will flood the LSA immediately and router 2 will receive it. However, if draft-retana (or RFC 5820) is used, router 3 will not immediately forward the LSA (since it is not an MPR or active OR), but will wait PushbackInterval plus jitter before flooding the LSA. This interval may be small (e.g., 2 seconds) but as I mentioned in my last post, in large networks this mechanism may result in several routers forwarding the same LSA unless PushbackInterval is larger than stated in RFC 5820. Suppose we fix this by having only one router/relay that forwards the LSA when it is received from another router. If, in the above example, that relay is router 2, then it still would not work, since 1 is not adjacent with 2. So the single relay must be router 3. In general, the single relay must be be adjacent with all other routers. Therefore, one can conclude that it is best to have a special router (e.g., DR) that is adjacent with all other routers. Note that draft-retana does not have this property, and would have to dispense with "smart peering" in order achieve this property. Regards, Richard