From nobody Tue May 3 11:06:36 2016 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 6B72D12D77D; Tue, 3 May 2016 11:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuHRh7ec2xcS; Tue, 3 May 2016 11:06:29 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C4912D11E; Tue, 3 May 2016 11:06:25 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u43I6Klt004640; Tue, 3 May 2016 19:06:20 +0100 Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u43I6HTf004625 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 3 May 2016 19:06:18 +0100 From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> <094e01d1a14d$dee2e320$9ca8a960$@olddog.co.uk> <40BAEA74-73C5-4CA9-B581-FD0864DCDFF8@cisco.com> In-Reply-To: <40BAEA74-73C5-4CA9-B581-FD0864DCDFF8@cisco.com> Date: Tue, 3 May 2016 19:06:16 +0100 Message-ID: <051101d1a566$7d582170$78086450$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0512_01D1A56E.DF211D50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFw1kCCaiIwUNLtEKxshcWR2bdBZAEdXWDpAeZ8YfwCW7Rb+gM0ffgPoCR9zKA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22300.001 X-TM-AS-Result: No--27.919-10.0-31-10 X-imss-scan-details: No--27.919-10.0-31-10 X-TMASE-MatchedRID: pS5owHKhBO3FJ6ywrp0gou5xcghYf69z1kqyrcMalqVElaZ44wdr5OB8 OdeiJ2JqQ66AfpgtCSFb/YntQAmqPCh5A3bWOsipliwpJdZauweLKfr4l0eFzzCmUYns3FLTcs4 A80KaakCs1nrDbiMM4nLHqPoioImUjh97YmbtUFLhG1IOMb7PsDFFLhGUD8AWlxrbJNbm/wSmyQ VG1kMNf1YmKyHeh965kjcEZRdXvqZB1m5nja+ukRcqpH7D1rtQXru95hSuhjSUvX/ci5TjsgQyX K9eC6mUsHABAwbw/VrO/WH+Jlz/QMcxC9l7kaqpi1u/Wt2ORDrvJY9pBzgg1P/0n/rX0NETdni0 h/RUcQR1kXKt8agVAqEjdrAqXFao0H/zLeBgX2/UWdZik3yrYeiY+s2L3xQEFFn/3AEyEaz0t3k tSH728veBD01Dl6u2LSi5+Ear6Yj8BymGA9MWAoQnnAFRgjn9BdebOqawiLvMbKh5QsVRoN7EHA uRAfwU+pOmmUIxFU48QSrJjunoMZELwEFeVXChiVYleIBIrY/6e9LB8NtoJadrpTvh7T6oaUehc Y2jtkUZCegJ5M3wUKqNEi0TOKDzOXJUfyM1K02cgbKevk5shqTYf9v9flolslgQm+u5vajKooqv Q0Sk9I/1zKj4Efpl0ZQB2zwuLEbWcuaikvd2WoCOjMAO81E5CQ3xS+zL6e0g1QuRyB58YfyL40X ovS1aNtrqBJtuOX5BVgr5vOsPONLF6Y0L7R/QcFEiuPxHjsW0X0Yw27VuouQ45nVtPqmxrsFU8U w5BC6ytmB2/5InT/zxIC9LasqudG57tpB6osSeAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCsgxrwr9aUfM2GwbyzEn0NCHzt0LjaI+ob6YL3Fz0tpLPPpCuffGH9zI= Archived-At: Cc: rtg-dir@ietf.org, 'Manav Bhatia' , rtg-ads@ietf.org, 'OSPF WG List' , draft-ietf-ospf-sbfd-discriminator.all@ietf.org Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 18:06:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0512_01D1A56E.DF211D50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Carlos, =20 Alia asked me to confirm whether your proposed change would have caused = me to not have made this comment on review. =20 It would certainly have helped. But... =20 "quite static" is not very clear as a relative term. =20 I think the concern might be that the network is large and there are = many BFD sessions.=20 Unless have I have misunderstood, it is not just a change in = discriminator, but also a change to whether reflection is wanted or not. =20 Anyway, this is not a trap, just an encouragement to make a statement = that helps readers to know that they don't need to worry. The parameters = are: - what causes an LSA to be flooded? - how does that compare to the number of LSAs normally flooded? - the security thing about using this as a way to cause excess flooding - how much extra state info does an OSPF implementation have to hold for these LSA in the LSA DB? =20 Cheers, Adrian =20 From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: 28 April 2016 17:15 To: Adrian Farrel Cc: Acee Lindem (acee); Manav Bhatia; ; = ; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; = OSPF WG List Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Adrian, =20 I would not oppose to making a clarification similar to the following, = if the WG things its useful: =20 The S-BFD Discriminators are expected to be quite static. S-BFD = Discriminators may change when enabling the S-BFD functionality or via = an explicit configuration event. These will result in a change in the = information advertised in the S-BFD Discriminator TLV in OSPF, but are = not expected to happen with any regularity. =20 [I expect that text needs (a lot of) wordsmithing, and might not be = useful or desired at all, but just to make the discussion more real] =20 Thanks, =20 =E2=80=94 Carlos. =20 On Apr 28, 2016, at 8:59 AM, Adrian Farrel wrote: =20 Acee has it right. =20 While (of course) stuff can be done in implementations to mitigate the = effects, the protocol extensions here increase the size of LSA and = increase the amount of flooding. Since the LSAs have to be stored (in = some form), it is reasonable to describe the amount of extra information = that reflects across a network - maybe express it as "LSA data" and = leave it up to an implementation to choose how to store it. Since the = number of LSA updates impacts the routing plane processing and bits on = the wire, it is reasonable to ask what impact that might have. =20 I am interested to hear whether turning Reflectors on and off could be a = feature that could cause LSAs to flap and so create flooding ripples in = the network. =20 Adrian =20 From: Acee Lindem (acee) [mailto:acee@cisco.com]=20 Sent: 28 April 2016 10:21 To: Manav Bhatia; Adrian Farrel Cc: ; rtg-dir@ietf.org; = draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG List Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Manav, =20 From: Manav Bhatia < = manav@ionosnetworks.com> Date: Thursday, April 28, 2016 at 1:31 AM To: Adrian Farrel < adrian@olddog.co.uk> Cc: "< rtg-ads@ietf.org>" < = rtg-ads@ietf.org>, Routing Directorate < = rtg-dir@ietf.org>, " = = draft-ietf-ospf-sbfd-discriminator.all@ietf.org" < = = draft-ietf-ospf-sbfd-discriminator.all@ietf.org>, OSPF WG List < = ospf@ietf.org> Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Adrian, =20 Thanks for the extensive review. I have a minor comment on a minor issue = that you raised. =20 Minor Issues: I should like to see some small amount of text on the scaling impact on OSPF. 1. How much additional information will implementations have to store per node/link in the network? 2. What is the expected churn in LSAs introduced by this mechanism (especially when the Reflector is turned on and off)? =20 Isnt this implementation specific? This is what will differentiate one = vendor implementation from the other.=20 =20 I am not sure how we can quantify this -- any ideas? =20 This is akin to saying that IS-IS, in contrast to OSPFv2, is more = attuned for partial SPF runs because the node information is cleanly = separated from the reachability information. However, this isnt entirely = true. While i concede that node information is mixed with prefix = information in OSPFv2, there still are ways in which clever = implementations could separate the two and do exactly what IS-IS does.=20 =20 I took this rather circuitous approach to drive home the point that = scalability, churn, overheads on the system are in many cases dependent = on the protocol implementation and by that token outside the scope of = the IETF drafts. =20 I believe what is being requested is a discussion of how often the S-BFD = TLV is likely to change, the effects on flooding, and, if required, = recommendations for any rate-limiting or other measures to prevent = churn.=20 =20 Thanks, Acee =20 =20 =20 =20 You *do* have... A change in information in the S-BFD Discriminator TLV MUST NOT trigger any SPF computation at a receiving router. ...which is a help. =20 I would be alarmed if an implementation in an absence of this pedantic = note triggered SPF runs each time an S-BFD disc changed ! I mean if you = understand the idea being discussed then you also understand that a = change in this TLV has no bearing on the reachability anywhere. And that = knowledge should be enough to prevent SPF runs in most cases !=20 =20 I know that we have added this note but if we need to explicitly spell = such things out in all standards then we clearly have bigger problems ! = :-) =20 Cheers, Manav =20 ------=_NextPart_000_0512_01D1A56E.DF211D50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Carlos,

 

Alia asked me to confirm = whether your proposed change would have caused me to not have made this = comment on review.

 

It would certainly have = helped. But...

 

"quite static" is = not very clear as a relative term.

 

I think the concern might be = that the network is large and there are many BFD sessions. =

Unless have I have = misunderstood, it is not just a change in discriminator, but also a = change to whether reflection is wanted or not.

 

Anyway, this is not a trap, = just an encouragement to make a statement that helps readers to know = that they don't need to worry. The parameters = are:

- what causes an LSA to be = flooded?

- how does that compare to the = number of LSAs normally flooded?

- the security thing about = using this as a way to cause excess flooding

- how much extra state info = does an OSPF implementation have to hold

=C2=A0=C2=A0 for these LSA in the LSA = DB?

 

Cheers,

Adrian

 

From: Carlos Pignataro = (cpignata) [mailto:cpignata@cisco.com]
Sent: 28 April 2016 = 17:15
To: Adrian Farrel
Cc: Acee Lindem (acee); = Manav Bhatia; <rtg-ads@ietf.org>; <rtg-dir@ietf.org>; = draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Adrian,

 

I would not oppose to making a clarification similar to the = following, if the WG things its = useful:

 

The S-BFD Discriminators are expected to be quite static. S-BFD = Discriminators may change when enabling the S-BFD functionality or via = an explicit configuration event. These will result in a change in the = information advertised in the S-BFD Discriminator TLV in OSPF, but are = not expected to happen with any = regularity.

 

[I expect that text needs (a lot of) wordsmithing, and might not = be useful or desired at all, but just to make the discussion more = real]

 

Thanks,

 

=E2=80=94 Carlos.

 

On Apr 28, 2016, at 8:59 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

 

Acee has it = right.

 

While (of course) stuff can = be done in implementations to mitigate the effects, the protocol = extensions here increase the size of LSA and increase the amount of = flooding. Since the LSAs have to be stored (in some form), it is = reasonable to describe the amount of extra information that reflects = across a network - maybe express it as "LSA data" and leave it = up to an implementation to choose how to store it. Since the number of = LSA updates impacts the routing plane processing and bits on the wire, = it is reasonable to ask what impact that might have.

 

I am interested to hear = whether turning Reflectors on and off could be a feature that could = cause LSAs to flap and so create flooding ripples in the = network.

 

Adrian

 

From: Acee Lindem (acee) = [mailto:acee@cisco.com] 
Sent: 28 April 2016 = 10:21
To: Manav Bhatia; Adrian = Farrel
Cc: <rtg-ads@ietf.org>; rtg-dir@ietf.org; draft-iet= f-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Hi Manav,

 

From: Manav Bhatia <manav@ionosnetworks.com>
Date:=  Thursday, April 28, = 2016 at 1:31 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, Routing = Directorate <rtg-dir@ietf.org>, "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" <draft-ietf-ospf-sbfd-discriminator.all@ietf.org>, OSPF WG List <ospf@ietf.org>
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Hi Adrian,

 

Thanks for the extensive review. I have a = minor comment on a minor issue that you raised.

 


Minor Issues:

I should like to = see some small amount of text on the scaling impact on
OSPF. 1. How = much additional information will implementations have to
store per = node/link in the network? 2. What is the expected churn in
LSAs = introduced by this mechanism (especially when the Reflector is
turned = on and off)?

 

Isnt this implementation specific? This = is what will differentiate one vendor implementation from the = other. 

 

I am not sure how we can quantify this -- = any ideas?

 

This is akin to saying that IS-IS, in = contrast to OSPFv2, is more attuned for partial SPF runs because the = node information is cleanly separated from the reachability information. = However, this isnt entirely true. While i concede that node information = is mixed with prefix information in OSPFv2, there still are ways in = which clever implementations could separate the two and do exactly what = IS-IS does. 

 

I took this rather circuitous approach to = drive home the point that scalability, churn, overheads on the system = are in many cases dependent on the protocol implementation and by that = token outside the scope of the IETF drafts.

<= /blockquote>

 

I believe what is being requested is a = discussion of how often the S-BFD TLV is likely to change, the effects = on flooding, and, if required, recommendations for any rate-limiting or = other measures to prevent churn. 

 

Thanks,

Acee

 

 

 

<= div>

 


You *do* have...
   A = change in information in the S-BFD Discriminator TLV MUST NOT
  =  trigger any SPF computation at a receiving router.
...which is = a help.

 

I would be alarmed if an implementation = in an absence of this pedantic note triggered SPF runs each time an = S-BFD disc changed ! I mean if you understand the idea being discussed = then you also understand that a change in this TLV has no bearing on the = reachability anywhere. And that knowledge should be enough to prevent = SPF runs in most cases ! 

 

I know that we have added this note but = if we need to explicitly spell such things out in all standards then we = clearly have bigger problems ! :-)

 

Cheers, Manav

<= /blockquote>

 

------=_NextPart_000_0512_01D1A56E.DF211D50-- From nobody Tue May 3 12:49:53 2016 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 5D1F212D859; Tue, 3 May 2016 12:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7qQg2vETgbE; Tue, 3 May 2016 12:49:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC9C12B03A; Tue, 3 May 2016 12:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45481; q=dns/txt; s=iport; t=1462304986; x=1463514586; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LHHGsp7G1XeosZ3jpxLFgXLuPZSvJ53b/NgyRphGXvw=; b=YSgh31XEdfqi2bPXQqGVpByBXi0rT5CsZ7CbOLX2YJbWDE2Q75VqoKA4 d9dDMAijmOaHmNJjg0lY+AiJWbVsDsdSRK/fMeHCQpifZSkUxswJjRmPJ Sd1JZsW6RtH57bQ/csPxmkBhsNY5/O9NcFc5RsKRDPX2ME8/V7waV3HjG Q=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAgDR/yhX/5hdJa1egmxMgVAGuhsOg?= =?us-ascii?q?XWGEAKBQTgUAQEBAQEBAWUnhEEBAQEDASNWBQsCAQgRAwEBAQEgAQYDAgIyFAk?= =?us-ascii?q?IAgQOBQ6IFAircJB5AQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGIIF2CIJPhF8Wg?= =?us-ascii?q?korgi4Fh3qLKoRyAYMngWeJCY8SjzEBHgFDg2tshz1/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,573,1454976000"; d="asc'?scan'208,217";a="268374322" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 19:49:45 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u43JniLu030869 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 19:49:44 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 15:49:43 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 15:49:43 -0400 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt Thread-Index: AQHRoQ9JJPZzPVazJE6j7eBXSSMiMJ+fX3YAgAA9NICAADaFgIAH+rkAgAAc54A= Date: Tue, 3 May 2016 19:49:43 +0000 Message-ID: References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> <094e01d1a14d$dee2e320$9ca8a960$@olddog.co.uk> <40BAEA74-73C5-4CA9-B581-FD0864DCDFF8@cisco.com> <051101d1a566$7d582170$78086450$@olddog.co.uk> In-Reply-To: <051101d1a566$7d582170$78086450$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.199] Content-Type: multipart/signed; boundary="Apple-Mail=_D83EA809-DB89-4AE3-88B0-63D14AD204CE"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "" , Manav Bhatia , "" , OSPF WG List , "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 03 May 2016 19:49:51 -0000 --Apple-Mail=_D83EA809-DB89-4AE3-88B0-63D14AD204CE Content-Type: multipart/alternative; boundary="Apple-Mail=_9B96C277-716E-4C8A-8E27-72DE3C300ED7" --Apple-Mail=_9B96C277-716E-4C8A-8E27-72DE3C300ED7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Adrian, Thanks for the follow-up. As I wrote to Alia, I am hesitant to quantify this further. These are = identifiers expected to be static (think of a loopback IP address or a = hostname as identifiers), on a feature that is not toggled on-and-off = constantly. I really think that the document is saying enough for = implementors to understand and take action (we are saying how often they = change, and saying that when they do they are advertised). Plus, regarding how much extra info additionally flooded or stored, as = Alia also acknowledged, this isn=E2=80=99t a high-volume TLV, and the = format is shown. I do like helpful advice in an RFC, but it seems to me that the current = text goes as far. Perhaps I am misunderstanding the intention or the concern. In that = case, if you have specific ideas in mind, it might help if you could = provide a text proposal to compare and contrast. Thanks, =E2=80=94 Carlos. > On May 3, 2016, at 2:06 PM, Adrian Farrel wrote: >=20 > Carlos, >=20 > Alia asked me to confirm whether your proposed change would have = caused me to not have made this comment on review. >=20 > It would certainly have helped. But... >=20 > "quite static" is not very clear as a relative term. >=20 > I think the concern might be that the network is large and there are = many BFD sessions. > Unless have I have misunderstood, it is not just a change in = discriminator, but also a change to whether reflection is wanted or not. >=20 > Anyway, this is not a trap, just an encouragement to make a statement = that helps readers to know that they don't need to worry. The parameters = are: > - what causes an LSA to be flooded? > - how does that compare to the number of LSAs normally flooded? > - the security thing about using this as a way to cause excess = flooding > - how much extra state info does an OSPF implementation have to hold > for these LSA in the LSA DB? >=20 > Cheers, > Adrian >=20 > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: 28 April 2016 17:15 > To: Adrian Farrel > Cc: Acee Lindem (acee); Manav Bhatia; ; = ; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; = OSPF WG List > Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt >=20 > Adrian, >=20 > I would not oppose to making a clarification similar to the following, = if the WG things its useful: >=20 >> The S-BFD Discriminators are expected to be quite static. S-BFD = Discriminators may change when enabling the S-BFD functionality or via = an explicit configuration event. These will result in a change in the = information advertised in the S-BFD Discriminator TLV in OSPF, but are = not expected to happen with any regularity. >=20 > [I expect that text needs (a lot of) wordsmithing, and might not be = useful or desired at all, but just to make the discussion more real] >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> On Apr 28, 2016, at 8:59 AM, Adrian Farrel > wrote: >>=20 >> Acee has it right. >>=20 >> While (of course) stuff can be done in implementations to mitigate = the effects, the protocol extensions here increase the size of LSA and = increase the amount of flooding. Since the LSAs have to be stored (in = some form), it is reasonable to describe the amount of extra information = that reflects across a network - maybe express it as "LSA data" and = leave it up to an implementation to choose how to store it. Since the = number of LSA updates impacts the routing plane processing and bits on = the wire, it is reasonable to ask what impact that might have. >>=20 >> I am interested to hear whether turning Reflectors on and off could = be a feature that could cause LSAs to flap and so create flooding = ripples in the network. >>=20 >> Adrian >>=20 >> From: Acee Lindem (acee) [mailto:acee@cisco.com = ] >> Sent: 28 April 2016 10:21 >> To: Manav Bhatia; Adrian Farrel >> Cc: >; rtg-dir@ietf.org = ; = draft-ietf-ospf-sbfd-discriminator.all@ietf.org = ; OSPF WG List >> Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt >>=20 >> Hi Manav, >>=20 >> From: Manav Bhatia > >> Date: Thursday, April 28, 2016 at 1:31 AM >> To: Adrian Farrel > >> Cc: ">" >, Routing Directorate >, = "draft-ietf-ospf-sbfd-discriminator.all@ietf.org = " = >, OSPF WG List = > >> Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt >>=20 >>> Hi Adrian, >>>=20 >>> Thanks for the extensive review. I have a minor comment on a minor = issue that you raised. >>>=20 >>>>=20 >>>> Minor Issues: >>>>=20 >>>> I should like to see some small amount of text on the scaling = impact on >>>> OSPF. 1. How much additional information will implementations have = to >>>> store per node/link in the network? 2. What is the expected churn = in >>>> LSAs introduced by this mechanism (especially when the Reflector is >>>> turned on and off)? >>>=20 >>> Isnt this implementation specific? This is what will differentiate = one vendor implementation from the other. >>>=20 >>> I am not sure how we can quantify this -- any ideas? >>>=20 >>> This is akin to saying that IS-IS, in contrast to OSPFv2, is more = attuned for partial SPF runs because the node information is cleanly = separated from the reachability information. However, this isnt entirely = true. While i concede that node information is mixed with prefix = information in OSPFv2, there still are ways in which clever = implementations could separate the two and do exactly what IS-IS does. >>>=20 >>> I took this rather circuitous approach to drive home the point that = scalability, churn, overheads on the system are in many cases dependent = on the protocol implementation and by that token outside the scope of = the IETF drafts. >>=20 >> I believe what is being requested is a discussion of how often the = S-BFD TLV is likely to change, the effects on flooding, and, if = required, recommendations for any rate-limiting or other measures to = prevent churn. >>=20 >> Thanks, >> Acee >>=20 >>=20 >>=20 >>>=20 >>>>=20 >>>> You *do* have... >>>> A change in information in the S-BFD Discriminator TLV MUST NOT >>>> trigger any SPF computation at a receiving router. >>>> ...which is a help. >>>=20 >>> I would be alarmed if an implementation in an absence of this = pedantic note triggered SPF runs each time an S-BFD disc changed ! I = mean if you understand the idea being discussed then you also understand = that a change in this TLV has no bearing on the reachability anywhere. = And that knowledge should be enough to prevent SPF runs in most cases ! >>>=20 >>> I know that we have added this note but if we need to explicitly = spell such things out in all standards then we clearly have bigger = problems ! :-) >>>=20 >>> Cheers, Manav --Apple-Mail=_9B96C277-716E-4C8A-8E27-72DE3C300ED7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Adrian,

Thanks for the follow-up.

As I wrote to Alia, I am hesitant to = quantify this further. These are identifiers expected to be static = (think of a loopback IP address or a hostname as identifiers), on a = feature that is not toggled on-and-off constantly. I really think that = the document is saying enough for implementors to understand and take = action (we are saying how often they change, and saying that when they = do they are advertised). 

Plus, regarding how much extra info = additionally flooded or stored, as Alia also acknowledged, this isn=E2=80=99= t a high-volume TLV, and the format is shown.

I do like helpful advice in an RFC, but = it seems to me that the current text goes as far. 

Perhaps I am = misunderstanding the intention or the concern. In that case, if you have = specific ideas in mind, it might help if you could provide a text = proposal to compare and contrast.

Thanks,

=E2=80=94 Carlos.

On May 3, 2016, at 2:06 PM, Adrian Farrel <adrian@olddog.co.uk>= wrote:

Carlos,
 
Alia asked me to = confirm whether your proposed change would have caused me to not have = made this comment on review.
 
It would certainly have = helped. But...
 
"quite static" is not = very clear as a relative term.
 
I think the concern = might be that the network is large and there are many BFD sessions. 
Unless have I have misunderstood, it is = not just a change in discriminator, but also a change to whether = reflection is wanted or not.
 
Anyway, this is not a = trap, just an encouragement to make a statement that helps readers to = know that they don't need to worry. The parameters are:
- what causes an LSA to be flooded?
- how does that compare to the number of = LSAs normally flooded?
- = the security thing about using this as a way to cause excess = flooding
- how much extra state = info does an OSPF implementation have to hold
   for these LSA in the = LSA DB?
 
Cheers,
Adrian
 
From: Carlos Pignataro (cpignata) = [mailto:cpignata@cisco.com] 
Sent: 28 = April 2016 17:15
To: Adrian Farrel
Cc: Acee Lindem (acee); Manav = Bhatia; <rtg-ads@ietf.org>; <rtg-dir@ietf.org>; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt
 
Adrian,
 
I would not oppose to = making a clarification similar to the following, if the WG things its = useful:
 
The S-BFD Discriminators are expected to be quite static. = S-BFD Discriminators may change when enabling the S-BFD functionality or = via an explicit configuration event. These will result in a change in = the information advertised in the S-BFD Discriminator TLV in OSPF, but = are not expected to happen with any regularity.
 
[I expect that text = needs (a lot of) wordsmithing, and might not be useful or desired at = all, but just to make the discussion more real]
 
Thanks,
 
=E2=80=94 Carlos.
 
On Apr 28, 2016, at 8:59 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:
 
Acee has it right.
 
While (of course) stuff = can be done in implementations to mitigate the effects, the protocol = extensions here increase the size of LSA and increase the amount of = flooding. Since the LSAs have to be stored (in some form), it is = reasonable to describe the amount of extra information that reflects = across a network - maybe express it as "LSA data" and leave it up to an = implementation to choose how to store it. Since the number of LSA = updates impacts the routing plane processing and bits on the wire, it is = reasonable to ask what impact that might have.
 
I = am interested to hear whether turning Reflectors on and off could be a = feature that could cause LSAs to flap and so create flooding ripples in = the network.
 
Adrian
 
From: Acee Lindem (acee) = [mailto:acee@cisco.com] 
Sent: 28 = April 2016 10:21
To: Manav Bhatia; Adrian = Farrel
Cc: <rtg-ads@ietf.org>; rtg-dir@ietf.org; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt
 
Hi Manav,
 
From: Manav Bhatia <manav@ionosnetworks.com>
Date: Thursday, April 28, = 2016 at 1:31 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, Routing Directorate <rtg-dir@ietf.org>, "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" = <draft-ietf-ospf-sbfd-discriminator.all@ietf.org>,= OSPF WG List <ospf@ietf.org>
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt
 
Hi Adrian,
 
Thanks for the extensive review. I have a minor comment on a = minor issue that you raised.
 

Minor Issues:

I = should like to see some small amount of text on the scaling impact on
OSPF. 1. How much additional information will implementations = have to
store per node/link in the network? 2. What is the = expected churn in
LSAs introduced by this mechanism = (especially when the Reflector is
turned on and = off)?
 
Isnt this implementation specific? This is what will = differentiate one vendor implementation from the = other. 
 
I am not sure how we can quantify this -- any = ideas?
 
This is akin to saying that IS-IS, in contrast to OSPFv2, is = more attuned for partial SPF runs because the node information is = cleanly separated from the reachability information. However, this isnt = entirely true. While i concede that node information is mixed with = prefix information in OSPFv2, there still are ways in which clever = implementations could separate the two and do exactly what IS-IS = does. 
 
I took this rather circuitous approach to drive home the = point that scalability, churn, overheads on the system are in many cases = dependent on the protocol implementation and by that token outside the = scope of the IETF drafts.
 
I believe what is being requested is a discussion of how = often the S-BFD TLV is likely to change, the effects on flooding, and, = if required, recommendations for any rate-limiting or other measures to = prevent churn. 
 
Thanks,
Acee
 
 
 
 

You *do* = have...
   A change in information in the S-BFD = Discriminator TLV MUST NOT
   trigger any SPF = computation at a receiving router.
...which is a = help.
 
I would be alarmed if an implementation in an absence of this = pedantic note triggered SPF runs each time an S-BFD disc changed ! I = mean if you understand the idea being discussed then you also understand = that a change in this TLV has no bearing on the reachability anywhere. = And that knowledge should be enough to prevent SPF runs in most cases = ! 
 
I know that we have added this note but if we need to = explicitly spell such things out in all standards then we clearly have = bigger problems ! :-)
 
Cheers, = Manav
<= /div>
<= br class=3D"">= --Apple-Mail=_9B96C277-716E-4C8A-8E27-72DE3C300ED7-- --Apple-Mail=_D83EA809-DB89-4AE3-88B0-63D14AD204CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXKQDXAAoJEIXgpQGOZny9JxAQAInsv1lrwyA7fWRl6WYzLZ1w 6lVb1OBqW60gwcshyUOnB6Jv0mRehzcpqeQG7oQ89Sy70+klm09AtE4KPpOqsMU3 XFPhs65Q0vKt7QiD1n8IbS9gRGx9lb50/WbFrWFTUfhVocwatxgNNdMRM/QvLc9P TY+WeSSX2cNO7FRTHIFN8BnrqgcdT0moGebLoErbBJ6JKdfyMEfG1QYGhqv/4h3Y 9G0sKpkFMq8ulukL2ZDHSWECGchzxw1sPmAcCt/vTSj3/xQL4tOH87jTQxUdpbm1 ySxygKorZHmjOLqql8sV6GMX5aOKYU1XkcJIIIFFNnKtHi6sFy1a3OYQbebqOtAj 30WT1A5Le6BTzDE3B5z3zWN8dN1JuIsghZstMbkv5Ud5Aa4Tl5uFM8ZGyo0vJ+ae qwWPAkf57IEubdalIbEpfR7vHL4B0z40g7dp6TYwWQeus3yLswiiGLptMIT9Y1sM d27cdkfBTOXEIPtL0k+4KgQCWlmhJ/ZIXvASXohjolI+UfmD1Wmrp7MxalNEVttF 2q1jaDxZ0/JxZn6zIWcoEZxkNwlwVz0h5HSEkSoXcHQURcb5o8WDhlxvgeBy0dP7 AmBgWY02+ClvsNfndshqVZkjyB5J+VZrWCZZFtFIn132NqJeVYrTpfZqxH5fW9Cm L9/8NdJ9rqZkwMEyR2OL =u+Ir -----END PGP SIGNATURE----- --Apple-Mail=_D83EA809-DB89-4AE3-88B0-63D14AD204CE-- From nobody Tue May 3 13:19:15 2016 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 EB4D712D0A3; Tue, 3 May 2016 13:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aVHiNiOgFcW; Tue, 3 May 2016 13:19:08 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F4C12D183; Tue, 3 May 2016 13:19:07 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u43KJ1qR030245; Tue, 3 May 2016 21:19:01 +0100 Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u43KInNl030092 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 3 May 2016 21:18:56 +0100 From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> <094e01d1a14d$dee2e320$9ca8a960$@olddog.co.uk> <40BAEA74-73C5-4CA9-B581-FD0864DCDFF8@cisco.com> <051101d1a566$7d582170$78086450$@olddog.co.uk> In-Reply-To: Date: Tue, 3 May 2016 21:18:48 +0100 Message-ID: <057401d1a579$0498e590$0dcab0b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0575_01D1A581.66667550" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFw1kCCaiIwUNLtEKxshcWR2bdBZAEdXWDpAeZ8YfwCW7Rb+gM0ffgPAY8JisMBq1EeiaAK0T+g Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22300.002 X-TM-AS-Result: No--27.464-10.0-31-10 X-imss-scan-details: No--27.464-10.0-31-10 X-TMASE-MatchedRID: pS5owHKhBO3JmaR8yBHGWKtWSWds/km2JCrNy6AbUJU4YKAM3oRt9i1l xAVVUrr2bvW8aqeo1n/Zlz8AwBLzjgkSzeMXko3JlVHM/F6YkvTNc6i32ftlfFQM54jP4h79QQ/ s9vEJJndsCEyIlk/eK5RYnhdItKOavCCmpyR752bAJnGRMfFxySseSAhqf1rR9jKBJYRpd1WDtx 8lDD0Wx0wvouS4U62BS/SrDavrFvGajZkb8TuLc1bWTTCHhOTxNNuh+5zmS68GgDV8o5u6Ewf7t X34v0pRoz8HTl+z1fZ6Nbm0VXGmc294Ipa1otxo4t2mucDkRBE0AKed0u9fBzNzZQXTq3sO8r9C VH8D1cgO1eozpdHlEuWQbb0Cu6INg+QbvWfvu8jXIwmz2YEJxTFFLhGUD8AW/Gw/uDwGV4t/7Ay 3ZInh8stjasHBa2Ue8/KQbghbCcn6Z227DrLqQ7dQIb8hCnY+e8tOW/bXHfCynk7TnYzMug+d/P hKYS9yrviYvHHdDkeOMDjZHc3LHcPlDt/vDJ7ECPKPqEbU3ZM5SAOCkuqVt33gfGZAU8fL4dLjx sRvbiIkX04GlzHMEZ7i1fZ4FYu3S5RTlYwa1oi20BbG4zmyXquvxGMwcZCYMXzBFhtQJWaZWy2Q OOrssXHDLxnhxMLIRLhdGHVxa6MUPKwcuWzcJDNKWYiz0CE6LJm8FOE9WLXgt9a0YyfLFLHaqZB ohRwhz+B9FumCXDfVbj7GXfjjmvD8WL7IHVq/B7TqRAYVohYmOHJ0aBcO1AJJmsCdNLQGrtNoTx L6qvdJlZFF2klNPrjsIvtIbWCRR1vveBQPCReeAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCsqsWJn5Qp6QCGfUbSgrAnCbn+lRFo8pReg8bNgitPAlvCStjCuOR/hg= Archived-At: Cc: rtg-dir@ietf.org, 'Manav Bhatia' , rtg-ads@ietf.org, 'OSPF WG List' , draft-ietf-ospf-sbfd-discriminator.all@ietf.org Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 20:19:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0575_01D1A581.66667550 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I might express the concern as one that an operator might voice. "If I = turn on this feature, what will happen to my IGP?" =20 But look, my review was for Alia to give her stuff to think about as AD. = If I really cared that much about this feature I would have reviewed the = I-D within the WG well before last call (not, as currently, well after). = So, if Alia is happy I have nothing more to say. =20 Thanks, Adrian =20 From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: 03 May 2016 20:50 To: Adrian Farrel Cc: Acee Lindem (acee); Manav Bhatia; ; = ; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; = OSPF WG List Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Adrian, =20 Thanks for the follow-up. =20 As I wrote to Alia, I am hesitant to quantify this further. These are = identifiers expected to be static (think of a loopback IP address or a = hostname as identifiers), on a feature that is not toggled on-and-off = constantly. I really think that the document is saying enough for = implementors to understand and take action (we are saying how often they = change, and saying that when they do they are advertised).=20 =20 Plus, regarding how much extra info additionally flooded or stored, as = Alia also acknowledged, this isn=E2=80=99t a high-volume TLV, and the = format is shown. =20 I do like helpful advice in an RFC, but it seems to me that the current = text goes as far.=20 =20 Perhaps I am misunderstanding the intention or the concern. In that = case, if you have specific ideas in mind, it might help if you could = provide a text proposal to compare and contrast. =20 Thanks, =20 =E2=80=94 Carlos. =20 On May 3, 2016, at 2:06 PM, Adrian Farrel wrote: =20 Carlos, =20 Alia asked me to confirm whether your proposed change would have caused = me to not have made this comment on review. =20 It would certainly have helped. But... =20 "quite static" is not very clear as a relative term. =20 I think the concern might be that the network is large and there are = many BFD sessions.=20 Unless have I have misunderstood, it is not just a change in = discriminator, but also a change to whether reflection is wanted or not. =20 Anyway, this is not a trap, just an encouragement to make a statement = that helps readers to know that they don't need to worry. The parameters = are: - what causes an LSA to be flooded? - how does that compare to the number of LSAs normally flooded? - the security thing about using this as a way to cause excess flooding - how much extra state info does an OSPF implementation have to hold for these LSA in the LSA DB? =20 Cheers, Adrian =20 From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: 28 April 2016 17:15 To: Adrian Farrel Cc: Acee Lindem (acee); Manav Bhatia; ; = ; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; = OSPF WG List Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Adrian, =20 I would not oppose to making a clarification similar to the following, = if the WG things its useful: =20 The S-BFD Discriminators are expected to be quite static. S-BFD = Discriminators may change when enabling the S-BFD functionality or via = an explicit configuration event. These will result in a change in the = information advertised in the S-BFD Discriminator TLV in OSPF, but are = not expected to happen with any regularity. =20 [I expect that text needs (a lot of) wordsmithing, and might not be = useful or desired at all, but just to make the discussion more real] =20 Thanks, =20 =E2=80=94 Carlos. =20 On Apr 28, 2016, at 8:59 AM, Adrian Farrel < = adrian@olddog.co.uk> wrote: =20 Acee has it right. =20 While (of course) stuff can be done in implementations to mitigate the = effects, the protocol extensions here increase the size of LSA and = increase the amount of flooding. Since the LSAs have to be stored (in = some form), it is reasonable to describe the amount of extra information = that reflects across a network - maybe express it as "LSA data" and = leave it up to an implementation to choose how to store it. Since the = number of LSA updates impacts the routing plane processing and bits on = the wire, it is reasonable to ask what impact that might have. =20 I am interested to hear whether turning Reflectors on and off could be a = feature that could cause LSAs to flap and so create flooding ripples in = the network. =20 Adrian =20 From: Acee Lindem (acee) [ = mailto:acee@cisco.com]=20 Sent: 28 April 2016 10:21 To: Manav Bhatia; Adrian Farrel Cc: < rtg-ads@ietf.org>; = rtg-dir@ietf.org; = = draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG List Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Manav, =20 From: Manav Bhatia < = manav@ionosnetworks.com> Date: Thursday, April 28, 2016 at 1:31 AM To: Adrian Farrel < adrian@olddog.co.uk> Cc: "< rtg-ads@ietf.org>" < = rtg-ads@ietf.org>, Routing Directorate < = rtg-dir@ietf.org>, " = = draft-ietf-ospf-sbfd-discriminator.all@ietf.org" < = = draft-ietf-ospf-sbfd-discriminator.all@ietf.org>, OSPF WG List < = ospf@ietf.org> Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Adrian, =20 Thanks for the extensive review. I have a minor comment on a minor issue = that you raised. =20 Minor Issues: I should like to see some small amount of text on the scaling impact on OSPF. 1. How much additional information will implementations have to store per node/link in the network? 2. What is the expected churn in LSAs introduced by this mechanism (especially when the Reflector is turned on and off)? =20 Isnt this implementation specific? This is what will differentiate one = vendor implementation from the other.=20 =20 I am not sure how we can quantify this -- any ideas? =20 This is akin to saying that IS-IS, in contrast to OSPFv2, is more = attuned for partial SPF runs because the node information is cleanly = separated from the reachability information. However, this isnt entirely = true. While i concede that node information is mixed with prefix = information in OSPFv2, there still are ways in which clever = implementations could separate the two and do exactly what IS-IS does.=20 =20 I took this rather circuitous approach to drive home the point that = scalability, churn, overheads on the system are in many cases dependent = on the protocol implementation and by that token outside the scope of = the IETF drafts. =20 I believe what is being requested is a discussion of how often the S-BFD = TLV is likely to change, the effects on flooding, and, if required, = recommendations for any rate-limiting or other measures to prevent = churn.=20 =20 Thanks, Acee =20 =20 =20 =20 You *do* have... A change in information in the S-BFD Discriminator TLV MUST NOT trigger any SPF computation at a receiving router. ...which is a help. =20 I would be alarmed if an implementation in an absence of this pedantic = note triggered SPF runs each time an S-BFD disc changed ! I mean if you = understand the idea being discussed then you also understand that a = change in this TLV has no bearing on the reachability anywhere. And that = knowledge should be enough to prevent SPF runs in most cases !=20 =20 I know that we have added this note but if we need to explicitly spell = such things out in all standards then we clearly have bigger problems ! = :-) =20 Cheers, Manav =20 ------=_NextPart_000_0575_01D1A581.66667550 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I might express the concern as = one that an operator might voice. "If I turn on this feature, what = will happen to my IGP?"

 

But look, my review was for = Alia to give her stuff to think about as AD. If I really cared that much = about this feature I would have reviewed the I-D within the WG well = before last call (not, as currently, well after). So, if Alia is happy I = have nothing more to say.

 

Thanks,

Adrian

 

From: Carlos Pignataro = (cpignata) [mailto:cpignata@cisco.com]
Sent: 03 May 2016 = 20:50
To: Adrian Farrel
Cc: Acee Lindem (acee); = Manav Bhatia; <rtg-ads@ietf.org>; <rtg-dir@ietf.org>; = draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Hi = Adrian,

 

Thanks for the follow-up.

 

As I wrote to Alia, I am hesitant to quantify this further. = These are identifiers expected to be static (think of a loopback IP = address or a hostname as identifiers), on a feature that is not toggled = on-and-off constantly. I really think that the document is saying enough = for implementors to understand and take action (we are saying how often = they change, and saying that when they do they are = advertised). 

 

Plus, regarding how much extra info additionally flooded or = stored, as Alia also acknowledged, this isn=E2=80=99t a high-volume TLV, = and the format is shown.

 

I do like helpful advice in an RFC, but it seems to me that the = current text goes as far. 

 

Perhaps I am misunderstanding the intention or the concern. In = that case, if you have specific ideas in mind, it might help if you = could provide a text proposal to compare and = contrast.

 

Thanks,

 

=E2=80=94 Carlos.

 

On May 3, 2016, at 2:06 PM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

 

Carlos,

 

Alia asked me to confirm = whether your proposed change would have caused me to not have made this = comment on review.

 

It would certainly have = helped. But...

 

"quite static" is = not very clear as a relative term.

 

I think the concern might = be that the network is large and there are many BFD sessions. 

Unless have I have = misunderstood, it is not just a change in discriminator, but also a = change to whether reflection is wanted or not.

 

Anyway, this is not a trap, = just an encouragement to make a statement that helps readers to know = that they don't need to worry. The parameters are:

- what causes an LSA to be = flooded?

- how does that compare to = the number of LSAs normally flooded?

- the security thing about = using this as a way to cause excess flooding

- how much extra state info = does an OSPF implementation have to hold

   for these LSA in the LSA = DB?

 

Cheers,

Adrian

 

From: Carlos Pignataro = (cpignata) [mailto:cpignata@cisco.com] 
Sent: 28 April 2016 = 17:15
To: Adrian = Farrel
Cc: Acee Lindem (acee); Manav = Bhatia; <rtg-ads@ietf.org>; <rtg-dir@ietf.org>; draft-iet= f-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Adrian,

 

I would not oppose to making a clarification similar to the = following, if the WG things its = useful:

 

The S-BFD = Discriminators are expected to be quite static. S-BFD Discriminators may = change when enabling the S-BFD functionality or via an explicit = configuration event. These will result in a change in the information = advertised in the S-BFD Discriminator TLV in OSPF, but are not expected = to happen with any = regularity.

 

[I expect that text needs (a lot of) wordsmithing, and might not = be useful or desired at all, but just to make the discussion more = real]

 

Thanks,

 

=E2=80=94 Carlos.

 

On Apr 28, 2016, at 8:59 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

 

Acee has it = right.

 

While (of course) stuff can = be done in implementations to mitigate the effects, the protocol = extensions here increase the size of LSA and increase the amount of = flooding. Since the LSAs have to be stored (in some form), it is = reasonable to describe the amount of extra information that reflects = across a network - maybe express it as "LSA data" and leave it = up to an implementation to choose how to store it. Since the number of = LSA updates impacts the routing plane processing and bits on the wire, = it is reasonable to ask what impact that might have.

 

I am interested to hear = whether turning Reflectors on and off could be a feature that could = cause LSAs to flap and so create flooding ripples in the = network.

 

Adrian

 

From: Acee Lindem (acee) = [mailto:acee@cisco.com] 
Sent: 28 April 2016 = 10:21
To: Manav Bhatia; Adrian = Farrel
Cc: <rtg-ads@ietf.org>; rtg-dir@ietf.org; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Hi Manav,

 

From: Manav Bhatia <manav@ionosnetworks.com>
Date:=  Thursday, April 28, = 2016 at 1:31 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, Routing = Directorate <rtg-dir@ietf.org>, "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" <draft-ietf-ospf-sbfd-discriminator.all@ietf.org>, OSPF WG List <ospf@ietf.org>
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

<= p class=3DMsoNormal>Hi Adrian,

 

Thanks for the extensive review. I have a = minor comment on a minor issue that you raised.

 


Minor Issues:

I should like to = see some small amount of text on the scaling impact on
OSPF. 1. How = much additional information will implementations have to
store per = node/link in the network? 2. What is the expected churn in
LSAs = introduced by this mechanism (especially when the Reflector is
turned = on and off)?

 

Isnt this implementation specific? This = is what will differentiate one vendor implementation from the = other. 

 

I am not sure how we can quantify this -- = any ideas?

 

This is akin to saying that IS-IS, in = contrast to OSPFv2, is more attuned for partial SPF runs because the = node information is cleanly separated from the reachability information. = However, this isnt entirely true. While i concede that node information = is mixed with prefix information in OSPFv2, there still are ways in = which clever implementations could separate the two and do exactly what = IS-IS does. 

 

I took this rather circuitous approach to = drive home the point that scalability, churn, overheads on the system = are in many cases dependent on the protocol implementation and by that = token outside the scope of the IETF drafts.

<= /div>

 

I believe what is being requested is a = discussion of how often the S-BFD TLV is likely to change, the effects = on flooding, and, if required, recommendations for any rate-limiting or = other measures to prevent churn. 

 

Thanks,

Acee

 

 

 

<= div>

 


You *do* have...
   A = change in information in the S-BFD Discriminator TLV MUST NOT
  =  trigger any SPF computation at a receiving router.
...which is = a help.

 

I would be alarmed if an implementation = in an absence of this pedantic note triggered SPF runs each time an = S-BFD disc changed ! I mean if you understand the idea being discussed = then you also understand that a change in this TLV has no bearing on the = reachability anywhere. And that knowledge should be enough to prevent = SPF runs in most cases ! 

 

I know that we have added this note but = if we need to explicitly spell such things out in all standards then we = clearly have bigger problems ! :-)

 

Cheers, Manav

<= /div>

 

------=_NextPart_000_0575_01D1A581.66667550-- From nobody Wed May 4 00:23:42 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A381F12B012; Wed, 4 May 2016 00:23:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504072338.8311.92142.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 00:23:38 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-mpls-elc-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 07:23:38 -0000 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 of the IETF. Title : Signaling Entropy Label Capability Using OSPF Authors : Xiaohu Xu Sriganesh Kini Siva Sivabalan Clarence Filsfils Stephane Litkowski Filename : draft-ietf-ospf-mpls-elc-02.txt Pages : 6 Date : 2016-05-04 Abstract: Multi Protocol Label Switching (MPLS) has defined a mechanism to load balance traffic flows using Entropy Labels (EL). An ingress LSR cannot insert ELs for packets going into a given tunnel unless an egress LSR has indicated via signaling that it can process ELs on that tunnel. This draft defines a mechanism to signal that capability using OSPF. This mechanism is useful when the label advertisement is also done via OSPF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 4 08:44:12 2016 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 4B5DF12D799 for ; Wed, 4 May 2016 08:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV8zrj9ZYm00 for ; Wed, 4 May 2016 08:44:05 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59B512D7DE for ; Wed, 4 May 2016 08:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=690; q=dns/txt; s=iport; t=1462376286; x=1463585886; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=hgCJrQ8yZPCIjkwAuupAc3lxrgFI5r+ya66lRTPFPgg=; b=cMMg6U1XGnNIetLjGXz0/RXlg4Ju9gr2tk9ZZsy1d7BRzStMrqoSbgD1 bAFs+Y5ZEm1NZ5VDKQ6wRktkW1V+tg+odX25QQsYZmpT4KoRHm5OPHoua 4ph6Eaj2gl6UknM+iCMU7FbxgDUFoSs6TBICTP+t7jCdIQnZyhOVGWjNV c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAgD/FSpX/4sNJK1egzhTgQO3U4IPA?= =?us-ascii?q?Q2BdSSFbB6BGTgUAQEBAQEBAWUnhEgdBhFFEgEiAh8HAgQwFRIEDogvDqwrkQY?= =?us-ascii?q?BAQEBAQEBAwEBAQEBAQEBARMEfJEwglkFmBkBhXuIHIFSFoRNiF6PMwEeAQFCg?= =?us-ascii?q?jaBNYgpfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,577,1454976000"; d="scan'208";a="269430953" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2016 15:38:06 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u44Fc5An018155 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 15:38:06 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 11:38:05 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 4 May 2016 11:38:05 -0400 From: "Acee Lindem (acee)" To: OSPF WG List Thread-Topic: Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions-08 Thread-Index: AQHRphrzBZFyJm30SU2yG3TklpkjFA== Date: Wed, 4 May 2016 15:38:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <707F1468836CCB4191A008B6262F0BBB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ospf-segment-routing-extensions@ietf.orig" Subject: [OSPF] Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions-08 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 15:44:11 -0000 VGhlIHN1YmplY3QgZHJhZnQgaXMgdmVyeSBzdGFibGUsIGhhcyBtdWx0aXBsZSBpbnRlcm9wZXJh YmxlDQppbXBsZW1lbnRhdGlvbnMsIGFuZCBtYW55IChpbmNsdWRpbmcgbXlzZWxmKSBoYXZlIGRv bmUgdGhvcm91Z2ggcmV2aWV3cy4gSQ0KYmVsaWV2ZSB3ZSBhcmUgcmVhZHkgZm9yIFdHIGxhc3Qg Y2FsbCBmb3IgdGhpcyB2ZXJ5IGltcG9ydGFudCBkcmFmdC4NCg0KV2l0aCBncmVhdCBwbGVhc3Vy ZSwgdGhpcyBiZWdpbnMgdGhlIFdHIGxhc3QgY2FsbCBmb3IgdGhlIHN1YmplY3QgZHJhZnQuDQpQ bGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoaXMgbGlzdCBwcmlvciB0byAxMjowMCBBTSBH TVQsIE1heSAxOXRoLA0KMjAxNi4gDQoNCkhlcmUgaXMgYSBVUkwgZm9yIHlvdXIgY29udmVuYW5j ZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3NwZi1zZWdt ZW50LXJvdXRpbmctZXh0ZW5zaW9ucw0KLyANCg0KVGhhbmtzLA0KQWNlZQ0KDQo= From nobody Wed May 4 08:47:21 2016 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 4A16412D7CA; Wed, 4 May 2016 08:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybOITrXWtH3E; Wed, 4 May 2016 08:47:18 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B9712DA55; Wed, 4 May 2016 08:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=690; q=dns/txt; s=iport; t=1462376488; x=1463586088; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=4pSt34bXgAqfF5xbRbWXpFbJsUzdDtZ2/zFsdTOABHI=; b=SPfSBka5dXHbcA1rvaagSR/P/x/wy/MOwCXXorGmM2eKggiG9y6pG0at DFwQf2E3CYT8f0HB3VBFivp2PIBDSx1eti0eNAkS4dMxztHAjwYURvwxB YBqaVhwZhEYDPodvrVUhpU/oAG0SkXvA11+4zDSfCVeBj3GrCtRStiCVf c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAgDvFipX/4ENJK1egzhTgQO3U4IPA?= =?us-ascii?q?Q2BdSSFbB6BGTgUAQEBAQEBAWUnhEgdBhFFEgEiAh8HAgQwFRIEDogvDqwqkQQ?= =?us-ascii?q?BAQEBAQEBAwEBAQEBAQEBARMEfJEwglkFmBkBhXuIHIFSFoRNiF6PMwEeAQFCg?= =?us-ascii?q?jaBNYgpfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,577,1454976000"; d="scan'208";a="267727524" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2016 15:41:27 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u44FfRYn025180 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 15:41:27 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 11:41:26 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 4 May 2016 11:41:26 -0400 From: "Acee Lindem (acee)" To: OSPF WG List Thread-Topic: Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions (Correct Draft Authors E-mail) Thread-Index: AQHRphtrmKmlLOn4hUS3HYB9goqNXA== Date: Wed, 4 May 2016 15:41:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <2C76127ED6C48D478DF3693B8E640D36@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ospf-segment-routing-extensions@ietf.org" Subject: [OSPF] Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions (Correct Draft Authors E-mail) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 15:47:20 -0000 VGhlIHN1YmplY3QgZHJhZnQgaXMgdmVyeSBzdGFibGUsIGhhcyBtdWx0aXBsZSBpbnRlcm9wZXJh YmxlDQppbXBsZW1lbnRhdGlvbnMsIGFuZCBtYW55IChpbmNsdWRpbmcgbXlzZWxmKSBoYXZlIGRv bmUgdGhvcm91Z2ggcmV2aWV3cy4gSQ0KYmVsaWV2ZSB3ZSBhcmUgcmVhZHkgZm9yIFdHIGxhc3Qg Y2FsbCBmb3IgdGhpcyB2ZXJ5IGltcG9ydGFudCBkcmFmdC4NCg0KV2l0aCBncmVhdCBwbGVhc3Vy ZSwgdGhpcyBiZWdpbnMgdGhlIFdHIGxhc3QgY2FsbCBmb3IgdGhlIHN1YmplY3QgZHJhZnQuDQpQ bGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoaXMgbGlzdCBwcmlvciB0byAxMjowMCBBTSBH TVQsIE1heSAxOXRoLA0KMjAxNi4NCg0KSGVyZSBpcyBhIFVSTCBmb3IgeW91ciBjb252ZW5hbmNl Og0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9zcGYtc2Vn bWVudC1yb3V0aW5nLWV4dGVuc2lvbnMNCi8NCg0KVGhhbmtzLA0KQWNlZQ0KDQo= From nobody Wed May 4 11:13:23 2016 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 897F912D9DC for ; Wed, 4 May 2016 11:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czyjG7QiQheW for ; Wed, 4 May 2016 11:13:20 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0199F12D981 for ; Wed, 4 May 2016 11:13:19 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id c189so28948725pfb.3 for ; Wed, 04 May 2016 11:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4do9Q7c3MxQlsiCnJFLVqh5sGQAk5JED3xXD5vr1nl0=; b=hyQrZmWY/Mra3irR+cw+DAbm+IOoENVmcDcfxxBK/KcuNRxmvXO3e2NjgJWmQHi3Eq akpigBw0bbKEkzNUrAbRe0nvckQOQ/uytcAZ71kdh9Sk0u0BXNPwDCSxznjPf6ZyaHkK Ojq1jF1lfbsjhMd/ee+u+JPS41B+zNCWexlUugbG9q1bdiwjX02/vAspLufmTVUGe5kZ 8+MNemyVtSS3ethD1qB9juo4t4AttavkvrYRdVploMJ+aBJJJO2zCi4aK7XjRbHLLwz4 yDGzQDIvxtyk1gjDiXe42PoSL1vkjunWvdO4icuxDiDsY6vKF6cfTqUgO51XTxFkFLj2 15pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4do9Q7c3MxQlsiCnJFLVqh5sGQAk5JED3xXD5vr1nl0=; b=luQDJwi3Z506YsWzj1oQCDD4WR/QF3zdO1MABJJWosYM9ZpAtIezO3scnyb7fGQad4 MnkZP76P2ZY/27pCoJJuo+unfLB9Zuhy7UhG5RIJEoddNx6cYJcKgFl4X6E47oVbeDH6 hnZqUV0a4dmfr0i6ho96Fb1Ps+lNEXoMwNB/RvIHjnlg51GVBTDe59S7Ek/KdTpkVmW3 4OBjoEZL8p3/3+CZv2rAQS1YEHIpkjkH4PzctOiHmYJuKzqe5D5Jbf+259sjjQx700v5 czBDZYwyiElh4+0+pZU+5FrjQixecs7piiE+5IAX9A6u2HJsGqC7azLv+6d59nABgtJi uTcA== X-Gm-Message-State: AOPr4FW7xrxvw76r99QdHPrDpyZpS51Q8g+LknZfRqkbqS7IDKpq8HZg1UkvlAvvrNBnnw== X-Received: by 10.98.102.20 with SMTP id a20mr14073400pfc.137.1462385599648; Wed, 04 May 2016 11:13:19 -0700 (PDT) Received: from [192.168.1.28] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id g27sm7717030pfd.25.2016.05.04.11.13.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2016 11:13:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Wed, 4 May 2016 11:13:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4A36A5BB-DF25-4459-B045-D42106191BD6@gmail.com> References: To: "Acee Lindem (acee)" Archived-At: Cc: OSPF WG List , "draft-ietf-ospf-segment-routing-extensions@ietf.orig" Subject: Re: [OSPF] Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions-08 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 18:13:22 -0000 Acee, The draft is indeed very stable, significant amount of interoperability tes= ting has been done. Support as coauthor. Regards, Jeff > On May 4, 2016, at 8:38 AM, Acee Lindem (acee) wrote: >=20 > The subject draft is very stable, has multiple interoperable > implementations, and many (including myself) have done thorough reviews. I= > believe we are ready for WG last call for this very important draft. >=20 > With great pleasure, this begins the WG last call for the subject draft. > Please send your comments to this list prior to 12:00 AM GMT, May 19th, > 2016.=20 >=20 > Here is a URL for your convenance: > https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extension= s > /=20 >=20 > Thanks, > Acee >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Wed May 4 14:57:14 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC0A12D56E; Wed, 4 May 2016 14:57:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504215712.8284.50208.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 14:57:12 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-two-part-metric-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 21:57:12 -0000 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 of the IETF. Title : OSPF Two-part Metric Authors : Zhaohui Zhang Lili Wang Acee Lindem David Dubois Vibhor Julka Tom McMillan Filename : draft-ietf-ospf-two-part-metric-04.txt Pages : 9 Date : 2016-05-04 Abstract: This document specifies an optional extension to the OSPF protocol, to represent the metric on a multi-access network as two parts: the metric from a router to the network, and the metric from the network to the router. The router to router metric would be the sum of the two. This document updates RFC 2328 and RFC 5340. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-two-part-metric/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-two-part-metric-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-two-part-metric-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 4 18:35:34 2016 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 1055312D13D; Wed, 4 May 2016 18:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUao0df1xHe7; Wed, 4 May 2016 18:35:31 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2920C12B004; Wed, 4 May 2016 18:35:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 764BA2CC6F; Thu, 5 May 2016 04:35:30 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 693CJkNMqevJ; Thu, 5 May 2016 04:35:30 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 633422CC64; Thu, 5 May 2016 04:35:29 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_72529E7C-F9B9-4984-A9F0-0CE260DF9CC4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Jari Arkko In-Reply-To: Date: Wed, 4 May 2016 21:35:31 -0400 Message-Id: References: <262CC2D9-1F83-45BB-8DA4-0FC70FAE88B4@qti.qualcomm.com> To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" , "ospf@ietf.org" , Pete Resnick , General Area Review Team Subject: Re: [OSPF] [Gen-art] Gen-ART LC review of draft-ietf-ospf-sbfd-discriminator-04 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 01:35:33 -0000 --Apple-Mail=_72529E7C-F9B9-4984-A9F0-0CE260DF9CC4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thanks for your review, Pete! Jari --Apple-Mail=_72529E7C-F9B9-4984-A9F0-0CE260DF9CC4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXKqNkAAoJEM80gCTQU46qLPkQAL9XkJ94QC/gSZfdJB7Qz+ra 0qJKIX3wypn2vbDxBiU8FYlByerJjcolY6LBb9OF1XiHhdj2aTWSbQNsww/qaIUD LSIYmKQlwxqWlcqHVAPdGb0IXxdI8hySpq7sG9ZfBMAyaclO6psOSsEJh8Ey7Tz6 HpX1G51kOibo3rMKgNZX3zDXZwvB57v8x6lj4Fg2as4awo39BI9G8Ec43bLc0wci n16BkzKfk72hugAA29GCAJjJFs1yWOy/DYSKsLlRI+mE3eP/G/bdTFgpf5bkNWhx 6u7/i+4k/zLsID1XUpMeFgqVFV2BlaiKPowScV2S/nalCPdmdaMULsfvm8cycEZv VxCa6EpTsAur8zkfGLIGyR6t+Sf+y8IiTgryL2987QZFpM5TzB+rQa4UCeOI9ZQB Q4+7ixp5ZjrSkOt22ORY8gsbnHi8SJNV0vhaToBvQGzBgTDWX/6Ex7LCYUqUVgvP aJ1T+BYh1BKcEYuhPusGfN6dcxclEq61ehxwwdhwm/9o1pYWgVftitR6zmaa19m/ kALSAKYKTUSZEHqW5mG7gO+ZIrhxK9cnBNJdHH2kImvh6qDvZ7cIA/qrmvPjN2zu IX0Sbku+6Y95b5mpOJGQwRXOUf071PMVDJeeYiC9oRFOGhfARrhdh//5SIVKVVtt sBTG4QY8cszIxuMAnnTX =SXiH -----END PGP SIGNATURE----- --Apple-Mail=_72529E7C-F9B9-4984-A9F0-0CE260DF9CC4-- From nobody Thu May 5 06:12:18 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7451112D63B; Thu, 5 May 2016 06:12:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505131216.15525.38680.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 06:12:16 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-two-part-metric-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 13:12:17 -0000 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 of the IETF. Title : OSPF Two-part Metric Authors : Zhaohui Zhang Lili Wang Acee Lindem David Dubois Vibhor Julka Tom McMillan Filename : draft-ietf-ospf-two-part-metric-05.txt Pages : 9 Date : 2016-05-05 Abstract: This document specifies an optional extension to the OSPF protocol, to represent the metric on a multi-access network as two parts: the metric from a router to the network, and the metric from the network to the router. The router to router metric would be the sum of the two. This document updates RFC 2328 and RFC 5340. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-two-part-metric/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-two-part-metric-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-two-part-metric-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 5 16:51:46 2016 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 6738512B012; Thu, 5 May 2016 16:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayyHkf3q6wSI; Thu, 5 May 2016 16:51:42 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E4E12B00F; Thu, 5 May 2016 16:51:41 -0700 (PDT) Received: from [199.87.120.129] (helo=jivecommunications.com) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ayT3A-0003mR-Mg; Fri, 06 May 2016 00:51:20 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rob Shakir In-Reply-To: Date: Thu, 5 May 2016 17:51:38 -0600 Content-Transfer-Encoding: 7bit Message-Id: <0712C067-DE46-4DC4-8470-33D527A4E0FD@rob.sh> References: To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-ospf-segment-routing-extensions@ietf.orig" , OSPF WG List Subject: Re: [OSPF] Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions-08 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 23:51:44 -0000 > On 4 May, 2016, at 9:38 AM, Acee Lindem (acee) wrote: > > The subject draft is very stable, has multiple interoperable > implementations, and many (including myself) have done thorough reviews. I > believe we are ready for WG last call for this very important draft. I support this draft progressing (as a co-author). Cheers, r. From nobody Thu May 5 17:17:53 2016 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 8E33912D118 for ; Thu, 5 May 2016 17:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WPEoBL6qK3p for ; Thu, 5 May 2016 17:17:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AAC112D0A3 for ; Thu, 5 May 2016 17:17:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5545D180003; Thu, 5 May 2016 17:17:11 -0700 (PDT) To: aretana@cisco.com, lhnguyen@cisco.com, alex.zinin@gmail.com, Russ.White@vce.com, dmcpherson@verisign.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, akr@cisco.com, acee@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160506001711.5545D180003@rfc-editor.org> Date: Thu, 5 May 2016 17:17:11 -0700 (PDT) Archived-At: Cc: alexander.okonnikov@gmail.com, ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC6987 (4685) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 06 May 2016 00:17:51 -0000 The following errata report has been submitted for RFC6987, "OSPF Stub Router Advertisement". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6987&eid=4685 -------------------------------------- Type: Technical Reported by: Alexander Okonnikov Section: 4 Original Text ------------- Corrected Text -------------- (At the end of the section) If the stub router is located in transit area, crossed by virtual link(s), latter will become inoperational in case the stub router is on path between two virtual link endpoints - either due to only path in transit area or due to topology changes which move stub router onto this path. Notes ----- Virtual links become inoperational in case path metric between two endpoints is > 0xffff. Path metric of two or more links, one of which has MaxLinkMetric, will inevitably exceed value 0xffff. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6987 (draft-ietf-ospf-rfc3137bis-04) -------------------------------------- Title : OSPF Stub Router Advertisement Publication Date : September 2013 Author(s) : A. Retana, L. Nguyen, A. Zinin, R. White, D. McPherson Category : INFORMATIONAL Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu May 5 18:40:26 2016 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 6D4E812D846 for ; Thu, 5 May 2016 18:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwBMNY5FXu0Y for ; Thu, 5 May 2016 18:40:21 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1FCE12D840 for ; Thu, 5 May 2016 18:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2804; q=dns/txt; s=iport; t=1462498821; x=1463708421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iSLgBtGbtn9OPbfW7uX2N5Bk4zrpameajRP9ZjrZOBI=; b=GY8ElDtfourpa2mVU5Gf76QFoGi9yY95ISxe77SCyFPeX16/AnoFVOCz TEmBLITEvrPfeK9hbwGLo3Z3YsElc61cJYNI+xKBoDTLuWBJ6f0lgSt0h B4V3FfF8hqJPv117xVk9ZlsTYJrnKU8p1sC1+eAq8w9KCs/LZa7l2evfA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAgDY9CtX/4QNJK1EGoM4U30GrT2LY?= =?us-ascii?q?QENgXYihW4CHIEZOBQBAQEBAQEBZSeEQgEBBCMRRRACAQgaAiYCAgIfERUQAgQ?= =?us-ascii?q?BDQWIFQMSDiytJ4w4DYQ5AQEBAQEBAQEBAQEBAQEBAQEBAQEBFXyJcIE5gQqBf?= =?us-ascii?q?IMAglkFh3kKhwiIXjEBjCCBeIFohE2IXodTh2ABHgEBQoIFDQ6BS2wBE4cafwE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.24,584,1454976000"; d="scan'208";a="269517794" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 May 2016 01:40:20 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u461eKao029847 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 May 2016 01:40:20 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 May 2016 21:40:19 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 5 May 2016 21:40:19 -0400 From: "Acee Lindem (acee)" To: RFC Errata System , "Alvaro Retana (aretana)" , "Liem Nguyen (lhnguyen)" , "alex.zinin@gmail.com" , "Russ.White@vce.com" , "dmcpherson@verisign.com" , "akatlas@gmail.com" , "db3546@att.com" , "Abhay Roy (akr)" Thread-Topic: [Technical Errata Reported] RFC6987 (4685) Thread-Index: AQHRpyy7sXWdtAlpg0CzQKa04LilsJ+rIiKA Date: Fri, 6 May 2016 01:40:19 +0000 Message-ID: References: <20160506001711.5545D180003@rfc-editor.org> In-Reply-To: <20160506001711.5545D180003@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <29700D0B90CA3048829886AAA945D537@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "alexander.okonnikov@gmail.com" , "ospf@ietf.org" Subject: Re: [OSPF] [Technical Errata Reported] RFC6987 (4685) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 06 May 2016 01:40:24 -0000 VGhlIHRleHQgYmVsb3cgaXMgdGVjaG5pY2FsbHkgY29ycmVjdCAob3RoZXIgdGhhbiB0aGUgZ3Jh bW1hcikuIEhvd2V2ZXIsDQpJ4oCZZCB2aWV3IGl0IG1vcmUgYXMgYWRkaXRpb25hbCBpbmZvcm1h dGlvbiB0aGFuIGFuIGFjdHVhbCBlcnJhdGEuDQoNClRoYW5rcywNCkFjZWUNCg0KT24gNS81LzE2 LCA4OjE3IFBNLCAiUkZDIEVycmF0YSBTeXN0ZW0iIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3Jn PiB3cm90ZToNCg0KPlRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0 ZWQgZm9yIFJGQzY5ODcsDQo+Ik9TUEYgU3R1YiBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCIuDQo+DQo+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5Zb3UgbWF5IHJldmlldyB0 aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCj5odHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0 YV9zZWFyY2gucGhwP3JmYz02OTg3JmVpZD00Njg1DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj5UeXBlOiBUZWNobmljYWwNCj5SZXBvcnRlZCBieTogQWxleGFu ZGVyIE9rb25uaWtvdiA8YWxleGFuZGVyLm9rb25uaWtvdkBnbWFpbC5jb20+DQo+DQo+U2VjdGlv bjogNA0KPg0KPk9yaWdpbmFsIFRleHQNCj4tLS0tLS0tLS0tLS0tDQo+DQo+DQo+Q29ycmVjdGVk IFRleHQNCj4tLS0tLS0tLS0tLS0tLQ0KPihBdCB0aGUgZW5kIG9mIHRoZSBzZWN0aW9uKQ0KPg0K PklmIHRoZSBzdHViIHJvdXRlciBpcyBsb2NhdGVkIGluIHRyYW5zaXQgYXJlYSwgY3Jvc3NlZCBi eSB2aXJ0dWFsDQo+bGluayhzKSwgbGF0dGVyIHdpbGwgYmVjb21lIGlub3BlcmF0aW9uYWwgaW4g Y2FzZSB0aGUgc3R1YiByb3V0ZXIgaXMNCj5vbiBwYXRoIGJldHdlZW4gdHdvIHZpcnR1YWwgbGlu ayBlbmRwb2ludHMgLSBlaXRoZXIgZHVlIHRvIG9ubHkgcGF0aA0KPmluIHRyYW5zaXQgYXJlYSBv ciBkdWUgdG8gdG9wb2xvZ3kgY2hhbmdlcyB3aGljaCBtb3ZlIHN0dWIgcm91dGVyIG9udG8NCj50 aGlzIHBhdGguIA0KPg0KPk5vdGVzDQo+LS0tLS0NCj5WaXJ0dWFsIGxpbmtzIGJlY29tZSBpbm9w ZXJhdGlvbmFsIGluIGNhc2UgcGF0aCBtZXRyaWMgYmV0d2VlbiB0d28NCj5lbmRwb2ludHMgaXMg PiAweGZmZmYuIFBhdGggbWV0cmljIG9mIHR3byBvciBtb3JlIGxpbmtzLCBvbmUgb2Ygd2hpY2gg aGFzDQo+TWF4TGlua01ldHJpYywgd2lsbCBpbmV2aXRhYmx5IGV4Y2VlZCB2YWx1ZSAweGZmZmYu DQo+DQo+SW5zdHJ1Y3Rpb25zOg0KPi0tLS0tLS0tLS0tLS0NCj5UaGlzIGVycmF0dW0gaXMgY3Vy cmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFzZQ0KPnVzZSAi UmVwbHkgQWxsIiB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yDQo+ cmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5 IChJRVNHKQ0KPmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJl cG9ydCwgaWYgbmVjZXNzYXJ5Lg0KPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+UkZDNjk4NyAoZHJhZnQtaWV0Zi1vc3BmLXJmYzMxMzdiaXMtMDQpDQo+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5UaXRsZSAgICAgICAgICAgICAgIDog T1NQRiBTdHViIFJvdXRlciBBZHZlcnRpc2VtZW50DQo+UHVibGljYXRpb24gRGF0ZSAgICA6IFNl cHRlbWJlciAyMDEzDQo+QXV0aG9yKHMpICAgICAgICAgICA6IEEuIFJldGFuYSwgTC4gTmd1eWVu LCBBLiBaaW5pbiwgUi4gV2hpdGUsIEQuDQo+TWNQaGVyc29uDQo+Q2F0ZWdvcnkgICAgICAgICAg ICA6IElORk9STUFUSU9OQUwNCj5Tb3VyY2UgICAgICAgICAgICAgIDogT3BlbiBTaG9ydGVzdCBQ YXRoIEZpcnN0IElHUA0KPkFyZWEgICAgICAgICAgICAgICAgOiBSb3V0aW5nDQo+U3RyZWFtICAg ICAgICAgICAgICA6IElFVEYNCj5WZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0KPg0KDQo= From nobody Thu May 5 18:48:39 2016 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 C41D712D84F for ; Thu, 5 May 2016 18:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJJtfDU3Z_VJ for ; Thu, 5 May 2016 18:48:36 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9352E12D84C for ; Thu, 5 May 2016 18:48:35 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id j8so115538226lfd.2 for ; Thu, 05 May 2016 18:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=ixzya8d8dgUvXKxAfUHHnUWDsOH2/QOpf5OTH4FB+jc=; b=wyBVAyJfW5EDh0oL83UEGTP5G1G5deYiqivQ/fK097fJ/U1+IhIjmQzLa0u16ueFj0 qJO0bjqlp3Wf4C0IFv2F2s7dAviTQb1whVaxszC55ARnAimMivB7kSyFEBcupE/t1/D9 LH2ZFgIjb5jOsuKKZOE+lHscMEyhJOUzGcAI+9mhjBUtET8Lj/AzXOWvSvrDR7MJi54u 8o/3dxAK1esV5a60Fk9JTwpRGYxCRPEgSLGDGwd4OzOtsm4j5FbUzHwih7+T/3IUpEJh Vu+8VifHTS74cfrq/fYtFzT5PZbA6Pa4Ihe7jllK6vVfDUINEbDNWXDn6FaRLcgv8bnv BkGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=ixzya8d8dgUvXKxAfUHHnUWDsOH2/QOpf5OTH4FB+jc=; b=Z8MUJivjWc1ZjDlZfcrNSPHdN1LeDIjCt52xGLfHkTovItH3h4wTJ0Dd/LkeJ4NAAF WuP0YaQJTITUftz+/BGMugbBqOzHzOzuk6s84Tpw4tkj+LeO2c9Hr2TgHyA6PASBZV29 rsjqSFASUeYX1lZvtdW40W9z/osVQjeLjEsq/LWcBi2bg7RWZjg3d/XWUxgn7dXaTF6B eEa8K+IbOjub5VIyD6sDBGZJF6KWHD261s13qDN+/lvWCMdqb2n8urv1FcIC5rfB0aAQ JcKfIncyNHcUfV7Wr+4Cu3MXxOUW009Yerdo40tDcByMYlt1hVzrPrKadQDU9wKx7CJb MSpw== X-Gm-Message-State: AOPr4FWRXtD6HTJf8bHzNuKa2pZlx2Z+TLJn8GNNALs1DKkiyGPIgraw7iirxw6Xm01y9Q== X-Received: by 10.25.162.76 with SMTP id l73mr3082636lfe.45.1462499313787; Thu, 05 May 2016 18:48:33 -0700 (PDT) Received: from [10.0.1.9] (85-114-21-254.obit.ru. [85.114.21.254]) by smtp.gmail.com with ESMTPSA id ez1sm1958754lbc.29.2016.05.05.18.48.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2016 18:48:33 -0700 (PDT) Date: Fri, 6 May 2016 04:48:10 +0300 From: Alexander Okonnikov To: RFC Errata System , "Alvaro Retana (aretana)" , "Liem Nguyen (lhnguyen)" , "=?utf-8?Q?alex.zinin=40gmail.com?=" , "=?utf-8?Q?Russ.White=40vce.com?=" , "=?utf-8?Q?dmcpherson=40verisign.com?=" , "=?utf-8?Q?akatlas=40gmail.com?=" , "=?utf-8?Q?db3546=40att.com?=" , "Abhay Roy (akr)" , "Acee Lindem (acee)" Message-ID: In-Reply-To: References: <20160506001711.5545D180003@rfc-editor.org> X-Readdle-Message-ID: d78754d0-2b77-40f6-9816-14cfe8938b78@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="572bf7f0_327b23c6_ca" Archived-At: Cc: "=?utf-8?Q?ospf=40ietf.org?=" Subject: Re: [OSPF] [Technical Errata Reported] RFC6987 (4685) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 06 May 2016 01:48:37 -0000 --572bf7f0_327b23c6_ca Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Acee, Yes, it is addition, but I have no idea about another way how to add this= clarification rather than via errata tool. Thank you. 6 =D0=BC=D0=B0=D1=8F 2016 =D0=B3., 4:40 +0300, Acee Lindem (acee), =D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > The text below is technically correct (other than the grammar). However= , > I=E2=80=99d view it more as additional information than an actual errat= a. > =20 > Thanks, > Acee > =20 > On 5/5/16, 8:17 PM, =22R=46C Errata System=22wrote: > =20 > > The following errata report has been submitted for R=46C6987, > > =22OSP=46 Stub Router Advertisement=22. > > =20 > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata=5Fsearch.php=3Frfc=3D6987&eid=3D4685= > > =20 > > -------------------------------------- > > Type: Technical > > Reported by: Alexander Okonnikov > =20 > > Section: 4 > > =20 > > Original Text > > ------------- > > =20 > > =20 > > Corrected Text > > -------------- > > (At the end of the section) > > =20 > > If the stub router is located in transit area, crossed by virtual > > link(s), latter will become inoperational in case the stub router is > > on path between two virtual link endpoints - either due to only path > > in transit area or due to topology changes which move stub router ont= o > > this path. > > =20 > > Notes > > ----- > > Virtual links become inoperational in case path metric between two > > endpoints is>0xffff. Path metric of two or more links, one of which h= as > > MaxLinkMetric, will inevitably exceed value 0xffff. > > =20 > > Instructions: > > ------------- > > This erratum is currently posted as =22Reported=22. If necessary, ple= ase > > use =22Reply All=22 to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > =20 > > -------------------------------------- > > R=46C6987 (draft-ietf-ospf-rfc3137bis-04) > > -------------------------------------- > > Title : OSP=46 Stub Router Advertisement > > Publication Date : September 2013 > > Author(s) : A. Retana, L. Nguyen, A. Zinin, R. White, D. > > McPherson > > Category : IN=46ORMATIONAL > > Source : Open Shortest Path =46irst IGP > > Area : Routing > > Stream : IET=46 > > Verifying Party : IESG > > =20 > =20 --572bf7f0_327b23c6_ca Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello Acee,

Yes, it is addition, but I have no idea about another way how to add this= clarification rather than via errata tool.

Thank you.


6 =D0=BC=D0=B0=D1=8F 2016 =D0=B3., 4:40 +0300, Acee Lindem (acee) <ace= e=40cisco.com>, =D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
The text below is technically correct (othe= r than the grammar). However,
I=E2=80=99d view it more as additional information than an actual errata.=

Thanks,
Acee

On 5/5/16, 8:17 PM, =22R=46C Errata System=22 <rfc-editor=40rfc-editor= .org> wrote:

The following errata report has been submit= ted for R=46C6987,
=22OSP=46 Stub Router Advertisement=22.

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata=5Fsearch.php=3Frfc=3D6987&eid=3D4685=

--------------------------------------
Type: Technical
Reported by: Alexander Okonnikov <alexander.okonnikov=40gmail.com

Section: 4

Original Text
-------------


Corrected Text
--------------
(At the end of the section)

If the stub router is located in transit area, crossed by virtual
link(s), latter will become inoperational in case the stub router is
on path between two virtual link endpoints - either due to only path
in transit area or due to topology changes which move stub router onto this path.

Notes
-----
Virtual links become inoperational in case path metric between two
endpoints is > 0xffff. Path metric of two or more links, one of which = has
MaxLinkMetric, will inevitably exceed value 0xffff.

Instructions:
-------------
This erratum is currently posted as =22Reported=22. If necessary, please<= br /> use =22Reply All=22 to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
R=46C6987 (draft-ietf-ospf-rfc3137bis-04)
--------------------------------------
Title : OSP=46 Stub Router Advertisement
Publication Date : September 2013
Author(s) : A. Retana, L. Nguyen, A. Zinin, R. White, D.
McPherson
Category : IN=46ORMATIONAL
Source : Open Shortest Path =46irst IGP
Area : Routing
Stream : IET=46
Verifying Party : IESG


--572bf7f0_327b23c6_ca-- From nobody Sat May 7 04:44:26 2016 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 4828A12D0C9 for ; Sat, 7 May 2016 04:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_H95dhC-zH8 for ; Sat, 7 May 2016 04:44:21 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AD412B028 for ; Sat, 7 May 2016 04:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15729; q=dns/txt; s=iport; t=1462621461; x=1463831061; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rfHfsYGL+emqbAx434fYui7P81pK+TuTAQwNekDnw8I=; b=Z9J5ch6+pOyrKjAOo7Hztl8960sTv5onvnCfFIG7qtnq6VCTSyc8pduL LbPEFZLPbGj/GRQTFggq5Huqfcx9w3TzOHtEXH3iXRJHlz+iw1fbMaEJT pCtGKPGINQi4jrv3tqTYEI/fR/g1A/cncXMvSfYfhDmYwor3a7rsYmAQs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgB61C1X/40NJK1EGoJsTFV9Bq0jh?= =?us-ascii?q?m6EdAENgXYkhWwCHIEMOBQBAQEBAQEBZSeEQQEBAQQjVhACAQYCEQMBAigDAgI?= =?us-ascii?q?CHxEUCQgCBAENBYgVAxMOLJAXnR2MGg2EPQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RWKbIE5gQqCHBiCSIJZBYd9CocJhByERTEBhXyGJoF5gWmET4hfh1iHYgEeAQF?= =?us-ascii?q?CggUNDoFLbgEThw1/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,589,1454976000"; d="scan'208,217";a="268901205" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 May 2016 11:44:20 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u47BiJuH026564 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 7 May 2016 11:44:20 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 7 May 2016 07:44:19 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sat, 7 May 2016 07:44:19 -0400 From: "Acee Lindem (acee)" To: Alexander Okonnikov , RFC Errata System , "Alvaro Retana (aretana)" , "Liem Nguyen (lhnguyen)" , "alex.zinin@gmail.com" , "dmcpherson@verisign.com" , "akatlas@gmail.com" , "db3546@att.com" , "Abhay Roy (akr)" , Russ White <7riw77@gmail.com> Thread-Topic: [Technical Errata Reported] RFC6987 (4685) Thread-Index: AQHRpyy7sXWdtAlpg0CzQKa04LilsJ+rIiKAgABFQgCAAfXTAA== Date: Sat, 7 May 2016 11:44:19 +0000 Message-ID: References: <20160506001711.5545D180003@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D3534BA1602E2aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "ospf@ietf.org" Subject: Re: [OSPF] [Technical Errata Reported] RFC6987 (4685) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 07 May 2016 11:44:24 -0000 --_000_D3534BA1602E2aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxleCwNCg0KSSBkb27igJl0IHJlYWxseSBhZ3JlZSB3aXRoIHRoZSBwcmVjZWRlbnQgb2Yg Z29pbmcgYmFjayBhbmQgaW1wcm92aW5nIGV4aXN0aW5nIGRvY3VtZW50cyB0aHJvdWdoIGVycmF0 YS4gTXkgdmlldyBvZiBlcnJhdGEgaXMgdGhhdCBpdCBpcyBtZWFudCB0byBjb3JyZWN0IHRoaW5n cyB0aGF0ICBhcmUgd3JvbmcgcmF0aGVyIHRoYW4gYWRkIGltcHJvdmVtZW50cyBhbmQgY2xhcmlm aWNhdGlvbnMuIEhvd2V2ZXIsIEnigJlsbCBsZWF2ZSB0aGUgZGVjaXNpb24gdG8gdGhlIEFEcy4N Cg0KTm90ZSB0aGF0IHdlIGN1cnJlbnRseSBoYXZlIHNldmVyYWwgZG9jdW1lbnRzIGluIHRoZSBX RyBsYXN0IGNhbGwgb3Ig4oCcUHVibGljYXRpb24gUmVxdWVzdGVk4oCdIHN0YXRlIGFuZCBpdCB3 b3VsZCBiZSBncmVhdCBpZiB5b3XigJlkIGZvY3VzIHlvdXIgZWZmb3J0cyB0aGVyZS4NCg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vc3BmLXR3by1wYXJ0LW1l dHJpYy8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3NwZi10 cmFuc2l0aW9uLXRvLW9zcGZ2My8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucy8NCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3NwZi10dHovDQoNClRoYW5rcywNCkFjZWUN Cg0KDQpGcm9tOiBBbGV4YW5kZXIgT2tvbm5pa292IDxhbGV4YW5kZXIub2tvbm5pa292QGdtYWls LmNvbTxtYWlsdG86YWxleGFuZGVyLm9rb25uaWtvdkBnbWFpbC5jb20+Pg0KRGF0ZTogVGh1cnNk YXksIE1heSA1LCAyMDE2IGF0IDk6NDggUE0NClRvOiBSRkMgRXJyYXRhIFN5c3RlbSA8cmZjLWVk aXRvckByZmMtZWRpdG9yLm9yZzxtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZz4+LCAi QWx2YXJvIFJldGFuYSAoYXJldGFuYSkiIDxhcmV0YW5hQGNpc2NvLmNvbTxtYWlsdG86YXJldGFu YUBjaXNjby5jb20+PiwgIkxpZW0gTmd1eWVuIChsaG5ndXllbikiIDxsaG5ndXllbkBjaXNjby5j b208bWFpbHRvOmxobmd1eWVuQGNpc2NvLmNvbT4+LCAiYWxleC56aW5pbkBnbWFpbC5jb208bWFp bHRvOmFsZXguemluaW5AZ21haWwuY29tPiIgPGFsZXguemluaW5AZ21haWwuY29tPG1haWx0bzph bGV4LnppbmluQGdtYWlsLmNvbT4+LCAiUnVzcy5XaGl0ZUB2Y2UuY29tPG1haWx0bzpSdXNzLldo aXRlQHZjZS5jb20+IiA8UnVzcy5XaGl0ZUB2Y2UuY29tPG1haWx0bzpSdXNzLldoaXRlQHZjZS5j b20+PiwgImRtY3BoZXJzb25AdmVyaXNpZ24uY29tPG1haWx0bzpkbWNwaGVyc29uQHZlcmlzaWdu LmNvbT4iIDxkbWNwaGVyc29uQHZlcmlzaWduLmNvbTxtYWlsdG86ZG1jcGhlcnNvbkB2ZXJpc2ln bi5jb20+PiwgQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21h aWwuY29tPj4sIERlYm9yYWggQnJ1bmdhcmQgPGRiMzU0NkBhdHQuY29tPG1haWx0bzpkYjM1NDZA YXR0LmNvbT4+LCAiQWJoYXkgUm95IChha3IpIiA8YWtyQGNpc2NvLmNvbTxtYWlsdG86YWtyQGNp c2NvLmNvbT4+LCBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28u Y29tPj4NCkNjOiBPU1BGIFdHIExpc3QgPG9zcGZAaWV0Zi5vcmc8bWFpbHRvOm9zcGZAaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2OTg3ICg0 Njg1KQ0KDQpIZWxsbyBBY2VlLA0KDQpZZXMsIGl0IGlzIGFkZGl0aW9uLCBidXQgSSBoYXZlIG5v IGlkZWEgYWJvdXQgYW5vdGhlciB3YXkgaG93IHRvIGFkZCB0aGlzIGNsYXJpZmljYXRpb24gcmF0 aGVyIHRoYW4gdmlhIGVycmF0YSB0b29sLg0KDQpUaGFuayB5b3UuDQoNCg0KNiDQvNCw0Y8gMjAx NiDQsy4sIDQ6NDAgKzAzMDAsIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb208bWFp bHRvOmFjZWVAY2lzY28uY29tPj4sINC/0LjRgdCw0Ls6DQpUaGUgdGV4dCBiZWxvdyBpcyB0ZWNo bmljYWxseSBjb3JyZWN0IChvdGhlciB0aGFuIHRoZSBncmFtbWFyKS4gSG93ZXZlciwNCknigJlk IHZpZXcgaXQgbW9yZSBhcyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRoYW4gYW4gYWN0dWFsIGVy cmF0YS4NCg0KVGhhbmtzLA0KQWNlZQ0KDQpPbiA1LzUvMTYsIDg6MTcgUE0sICJSRkMgRXJyYXRh IFN5c3RlbSIgPHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8bWFpbHRvOnJmYy1lZGl0b3JAcmZj LWVkaXRvci5vcmc+PiB3cm90ZToNCg0KVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBi ZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNjk4NywNCiJPU1BGIFN0dWIgUm91dGVyIEFkdmVydGlzZW1l bnQiLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWW91IG1heSBy ZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6DQpodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2VycmF0YV9zZWFyY2gucGhwP3JmYz02OTg3JmVpZD00Njg1DQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUeXBlOiBUZWNobmljYWwNClJlcG9ydGVkIGJ5OiBBbGV4 YW5kZXIgT2tvbm5pa292IDxhbGV4YW5kZXIub2tvbm5pa292QGdtYWlsLmNvbTxtYWlsdG86YWxl eGFuZGVyLm9rb25uaWtvdkBnbWFpbC5jb20+DQoNClNlY3Rpb246IDQNCg0KT3JpZ2luYWwgVGV4 dA0KLS0tLS0tLS0tLS0tLQ0KDQoNCkNvcnJlY3RlZCBUZXh0DQotLS0tLS0tLS0tLS0tLQ0KKEF0 IHRoZSBlbmQgb2YgdGhlIHNlY3Rpb24pDQoNCklmIHRoZSBzdHViIHJvdXRlciBpcyBsb2NhdGVk IGluIHRyYW5zaXQgYXJlYSwgY3Jvc3NlZCBieSB2aXJ0dWFsDQpsaW5rKHMpLCBsYXR0ZXIgd2ls bCBiZWNvbWUgaW5vcGVyYXRpb25hbCBpbiBjYXNlIHRoZSBzdHViIHJvdXRlciBpcw0Kb24gcGF0 aCBiZXR3ZWVuIHR3byB2aXJ0dWFsIGxpbmsgZW5kcG9pbnRzIC0gZWl0aGVyIGR1ZSB0byBvbmx5 IHBhdGgNCmluIHRyYW5zaXQgYXJlYSBvciBkdWUgdG8gdG9wb2xvZ3kgY2hhbmdlcyB3aGljaCBt b3ZlIHN0dWIgcm91dGVyIG9udG8NCnRoaXMgcGF0aC4NCg0KTm90ZXMNCi0tLS0tDQpWaXJ0dWFs IGxpbmtzIGJlY29tZSBpbm9wZXJhdGlvbmFsIGluIGNhc2UgcGF0aCBtZXRyaWMgYmV0d2VlbiB0 d28NCmVuZHBvaW50cyBpcyA+IDB4ZmZmZi4gUGF0aCBtZXRyaWMgb2YgdHdvIG9yIG1vcmUgbGlu a3MsIG9uZSBvZiB3aGljaCBoYXMNCk1heExpbmtNZXRyaWMsIHdpbGwgaW5ldml0YWJseSBleGNl ZWQgdmFsdWUgMHhmZmZmLg0KDQpJbnN0cnVjdGlvbnM6DQotLS0tLS0tLS0tLS0tDQpUaGlzIGVy cmF0dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBs ZWFzZQ0KdXNlICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQgYmUgdmVy aWZpZWQgb3INCnJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlm eWluZyBwYXJ0eSAoSUVTRykNCmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVk aXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KUkZDNjk4NyAoZHJhZnQtaWV0Zi1vc3BmLXJmYzMxMzdiaXMtMDQpDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGl0bGUgOiBPU1BGIFN0dWIg Um91dGVyIEFkdmVydGlzZW1lbnQNClB1YmxpY2F0aW9uIERhdGUgOiBTZXB0ZW1iZXIgMjAxMw0K QXV0aG9yKHMpIDogQS4gUmV0YW5hLCBMLiBOZ3V5ZW4sIEEuIFppbmluLCBSLiBXaGl0ZSwgRC4N Ck1jUGhlcnNvbg0KQ2F0ZWdvcnkgOiBJTkZPUk1BVElPTkFMDQpTb3VyY2UgOiBPcGVuIFNob3J0 ZXN0IFBhdGggRmlyc3QgSUdQDQpBcmVhIDogUm91dGluZw0KU3RyZWFtIDogSUVURg0KVmVyaWZ5 aW5nIFBhcnR5IDogSUVTRw0KDQoNCg== --_000_D3534BA1602E2aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <251435AE25E6F449BEAAC0AB684DD27A@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K SGkgQWxleCwmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KSSBkb27igJl0IHJlYWxseSBh Z3JlZSB3aXRoIHRoZSBwcmVjZWRlbnQgb2YgZ29pbmcgYmFjayBhbmQgaW1wcm92aW5nIGV4aXN0 aW5nIGRvY3VtZW50cyB0aHJvdWdoIGVycmF0YS4gTXkgdmlldyBvZiBlcnJhdGEgaXMgdGhhdCBp dCBpcyBtZWFudCB0byBjb3JyZWN0IHRoaW5ncyB0aGF0ICZuYnNwO2FyZSB3cm9uZyByYXRoZXIg dGhhbiBhZGQgaW1wcm92ZW1lbnRzIGFuZCBjbGFyaWZpY2F0aW9ucy4gSG93ZXZlciwgSeKAmWxs IGxlYXZlIHRoZSBkZWNpc2lvbg0KIHRvIHRoZSBBRHMuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCk5vdGUgdGhhdCB3ZSBjdXJyZW50bHkgaGF2ZSBzZXZlcmFsIGRvY3VtZW50cyBpbiB0 aGUgV0cgbGFzdCBjYWxsIG9yIOKAnFB1YmxpY2F0aW9uIFJlcXVlc3RlZOKAnSBzdGF0ZSBhbmQg aXQgd291bGQgYmUgZ3JlYXQgaWYgeW914oCZZCBmb2N1cyB5b3VyIGVmZm9ydHMgdGhlcmUuJm5i c3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLW9zcGYtdHdvLXBhcnQtbWV0cmljLzwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9zcGYtdHJhbnNpdGlvbi10by1vc3BmdjMvPC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0 ZW5zaW9ucy88L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vc3BmLXR0ei88 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+PGJyPg0K PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPlRoYW5r cyw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+QWNl ZSZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3Bh biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5BbGV4YW5kZXIgT2tvbm5pa292ICZsdDs8YSBocmVm PSJtYWlsdG86YWxleGFuZGVyLm9rb25uaWtvdkBnbWFpbC5jb20iPmFsZXhhbmRlci5va29ubmlr b3ZAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ RGF0ZTogPC9zcGFuPlRodXJzZGF5LCBNYXkgNSwgMjAxNiBhdCA5OjQ4IFBNPGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+UkZDIEVycmF0YSBTeXN0ZW0gJmx0 OzxhIGhyZWY9Im1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnIj5yZmMtZWRpdG9yQHJm Yy1lZGl0b3Iub3JnPC9hPiZndDssICZxdW90O0FsdmFybyBSZXRhbmEgKGFyZXRhbmEpJnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86YXJldGFuYUBjaXNjby5jb20iPmFyZXRhbmFAY2lzY28uY29t PC9hPiZndDssICZxdW90O0xpZW0gTmd1eWVuIChsaG5ndXllbikmcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpsaG5ndXllbkBjaXNjby5jb20iPmxobmd1eWVuQGNpc2NvLmNvbTwvYT4mZ3Q7LA0K ICZxdW90OzxhIGhyZWY9Im1haWx0bzphbGV4LnppbmluQGdtYWlsLmNvbSI+YWxleC56aW5pbkBn bWFpbC5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWxleC56aW5pbkBnbWFpbC5j b20iPmFsZXguemluaW5AZ21haWwuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpS dXNzLldoaXRlQHZjZS5jb20iPlJ1c3MuV2hpdGVAdmNlLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpSdXNzLldoaXRlQHZjZS5jb20iPlJ1c3MuV2hpdGVAdmNlLmNvbTwvYT4mZ3Q7 LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZG1jcGhlcnNvbkB2ZXJpc2lnbi5jb20iPmRtY3BoZXJz b25AdmVyaXNpZ24uY29tPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86ZG1jcGhlcnNv bkB2ZXJpc2lnbi5jb20iPmRtY3BoZXJzb25AdmVyaXNpZ24uY29tPC9hPiZndDssIEFsaWEgQXRs YXMgJmx0OzxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+YWthdGxhc0BnbWFpbC5j b208L2E+Jmd0OywgRGVib3JhaCBCcnVuZ2FyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiMzU0NkBh dHQuY29tIj5kYjM1NDZAYXR0LmNvbTwvYT4mZ3Q7LCAmcXVvdDtBYmhheSBSb3kgKGFrcikmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpha3JAY2lzY28uY29tIj5ha3JAY2lzY28uY29tPC9hPiZn dDssDQogQWNlZSBMaW5kZW0gJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSI+YWNl ZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5D YzogPC9zcGFuPk9TUEYgV0cgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9zcGZAaWV0Zi5vcmci Pm9zcGZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5TdWJqZWN0OiA8L3NwYW4+UmU6IFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2OTg3 ICg0Njg1KTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJN QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNi NWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4 bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCI+DQo8dGl0bGU+PC90aXRsZT4NCjxk aXY+DQo8ZGl2IG5hbWU9Im1lc3NhZ2VCb2R5U2VjdGlvbiI+SGVsbG8gQWNlZSw8YnI+DQo8YnI+ DQpZZXMsIGl0IGlzIGFkZGl0aW9uLCBidXQgSSBoYXZlIG5vIGlkZWEgYWJvdXQgYW5vdGhlciB3 YXkgaG93IHRvIGFkZCB0aGlzIGNsYXJpZmljYXRpb24gcmF0aGVyIHRoYW4gdmlhIGVycmF0YSB0 b29sLjxicj4NCjxicj4NClRoYW5rIHlvdS48L2Rpdj4NCjxkaXYgbmFtZT0ibWVzc2FnZVNpZ25h dHVyZVNlY3Rpb24iPjxicj4NCjwvZGl2Pg0KPGRpdiBuYW1lPSJtZXNzYWdlUmVwbHlTZWN0aW9u Ij48YnI+DQo2INC80LDRjyAyMDE2INCzLiwgNDo0MCAmIzQzOzAzMDAsIEFjZWUgTGluZGVtIChh Y2VlKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIj5hY2VlQGNpc2NvLmNvbTwv YT4mZ3Q7LCDQv9C40YHQsNC7Ojxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPlRoZSB0ZXh0 IGJlbG93IGlzIHRlY2huaWNhbGx5IGNvcnJlY3QgKG90aGVyIHRoYW4gdGhlIGdyYW1tYXIpLiBI b3dldmVyLDxicj4NCknigJlkIHZpZXcgaXQgbW9yZSBhcyBhZGRpdGlvbmFsIGluZm9ybWF0aW9u IHRoYW4gYW4gYWN0dWFsIGVycmF0YS48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KQWNlZTxicj4N Cjxicj4NCk9uIDUvNS8xNiwgODoxNyBQTSwgJnF1b3Q7UkZDIEVycmF0YSBTeXN0ZW0mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnIj5yZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+VGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBm b3IgUkZDNjk4Nyw8YnI+DQomcXVvdDtPU1BGIFN0dWIgUm91dGVyIEFkdmVydGlzZW1lbnQmcXVv dDsuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDo8YnI+DQo8YSBocmVmPSJo dHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz02OTg3JmFtcDtl aWQ9NDY4NSI+aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9 Njk4NyZhbXA7ZWlkPTQ2ODU8L2E+PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQpUeXBlOiBUZWNobmljYWw8YnI+DQpSZXBvcnRlZCBieTogQWxl eGFuZGVyIE9rb25uaWtvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRlci5va29ubmlrb3ZA Z21haWwuY29tIj5hbGV4YW5kZXIub2tvbm5pa292QGdtYWlsLmNvbTwvYT48YnI+DQo8YnI+DQpT ZWN0aW9uOiA0PGJyPg0KPGJyPg0KT3JpZ2luYWwgVGV4dDxicj4NCi0tLS0tLS0tLS0tLS08YnI+ DQo8YnI+DQo8YnI+DQpDb3JyZWN0ZWQgVGV4dDxicj4NCi0tLS0tLS0tLS0tLS0tPGJyPg0KKEF0 IHRoZSBlbmQgb2YgdGhlIHNlY3Rpb24pPGJyPg0KPGJyPg0KSWYgdGhlIHN0dWIgcm91dGVyIGlz IGxvY2F0ZWQgaW4gdHJhbnNpdCBhcmVhLCBjcm9zc2VkIGJ5IHZpcnR1YWw8YnI+DQpsaW5rKHMp LCBsYXR0ZXIgd2lsbCBiZWNvbWUgaW5vcGVyYXRpb25hbCBpbiBjYXNlIHRoZSBzdHViIHJvdXRl ciBpczxicj4NCm9uIHBhdGggYmV0d2VlbiB0d28gdmlydHVhbCBsaW5rIGVuZHBvaW50cyAtIGVp dGhlciBkdWUgdG8gb25seSBwYXRoPGJyPg0KaW4gdHJhbnNpdCBhcmVhIG9yIGR1ZSB0byB0b3Bv bG9neSBjaGFuZ2VzIHdoaWNoIG1vdmUgc3R1YiByb3V0ZXIgb250bzxicj4NCnRoaXMgcGF0aC48 YnI+DQo8YnI+DQpOb3Rlczxicj4NCi0tLS0tPGJyPg0KVmlydHVhbCBsaW5rcyBiZWNvbWUgaW5v cGVyYXRpb25hbCBpbiBjYXNlIHBhdGggbWV0cmljIGJldHdlZW4gdHdvPGJyPg0KZW5kcG9pbnRz IGlzICZndDsgMHhmZmZmLiBQYXRoIG1ldHJpYyBvZiB0d28gb3IgbW9yZSBsaW5rcywgb25lIG9m IHdoaWNoIGhhczxicj4NCk1heExpbmtNZXRyaWMsIHdpbGwgaW5ldml0YWJseSBleGNlZWQgdmFs dWUgMHhmZmZmLjxicj4NCjxicj4NCkluc3RydWN0aW9uczo8YnI+DQotLS0tLS0tLS0tLS0tPGJy Pg0KVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJnF1b3Q7UmVwb3J0ZWQmcXVv dDsuIElmIG5lY2Vzc2FyeSwgcGxlYXNlPGJyPg0KdXNlICZxdW90O1JlcGx5IEFsbCZxdW90OyB0 byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yPGJyPg0KcmVqZWN0ZWQu IFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5IChJRVNHKTxi cj4NCmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwg aWYgbmVjZXNzYXJ5Ljxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KUkZDNjk4NyAoZHJhZnQtaWV0Zi1vc3BmLXJmYzMxMzdiaXMtMDQpPGJyPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpUaXRsZSA6IE9TUEYg U3R1YiBSb3V0ZXIgQWR2ZXJ0aXNlbWVudDxicj4NClB1YmxpY2F0aW9uIERhdGUgOiBTZXB0ZW1i ZXIgMjAxMzxicj4NCkF1dGhvcihzKSA6IEEuIFJldGFuYSwgTC4gTmd1eWVuLCBBLiBaaW5pbiwg Ui4gV2hpdGUsIEQuPGJyPg0KTWNQaGVyc29uPGJyPg0KQ2F0ZWdvcnkgOiBJTkZPUk1BVElPTkFM PGJyPg0KU291cmNlIDogT3BlbiBTaG9ydGVzdCBQYXRoIEZpcnN0IElHUDxicj4NCkFyZWEgOiBS b3V0aW5nPGJyPg0KU3RyZWFtIDogSUVURjxicj4NClZlcmlmeWluZyBQYXJ0eSA6IElFU0c8YnI+ DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D3534BA1602E2aceeciscocom_-- From nobody Mon May 9 13:34:16 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD0B12D636; Mon, 9 May 2016 13:34:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160509203413.18393.13951.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2016 13:34:13 -0700 Archived-At: Cc: draft-ietf-ospf-sbfd-discriminator@ietf.org, ospf@ietf.org, The IESG , ospf-chairs@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] Protocol Action: 'OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators' to Proposed Standard (draft-ietf-ospf-sbfd-discriminator-06.txt) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 20:34:13 -0000 The IESG has approved the following document: - 'OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators' (draft-ietf-ospf-sbfd-discriminator-06.txt) as Proposed Standard This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-sbfd-discriminator/ Technical Summary This document specifies extensions to OSPF Router Informational (RI) to for an OSPF router to advertise its Seamless BFD discriminators. The scope of an advertisement can be an OSPF area or the entire OSPF routing domain. The architecture for seamless BFD is described in "Seamless Bidirectional Forwarding Detection (S-BFD)" - draft-ietf-bfd-seamless-base-05. Working Group Summary The document is an adjunct to the Seamless-BFD work being done in the BFD WG. It is very straight-forward and there hasn't been many comments. During WG last call, it was noted that the behavior must be specified when there are multiple instances of the S-BFD discriminator TLV. This comment was subsequently handled. The question of multiple S-BFD discriminators was also discussed in reference to the base Seamless BFD draft. This results in much discussion with appropriate text added to the base document indicating that this was basically a local matter and outside the scope of the standard. Document Quality This document has been a WG document for some time and is being advanced now that the seamless BFD work is being advanced in the BFD working group. Personnel Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. From nobody Wed May 11 07:19:55 2016 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 4681912DAF1 for ; Wed, 11 May 2016 07:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorg676131.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkGHma85qpKO for ; Wed, 11 May 2016 07:19:51 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0120.outbound.protection.outlook.com [104.47.125.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E3712D6C2 for ; Wed, 11 May 2016 07:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORG676131.onmicrosoft.com; s=selector1-nivettisystems-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DTXfQTIcbftkEGrXvbsq6tyQp2I+EDylxgKhFKA3RA4=; b=pWH02OoK/tnVAdAbtrLJTCnfhPp8EJ9wyrPpOzbnjcAHX3zFc1WnGxzQW7gS2I+YyWr/pc84m1OEOLduByMugNu4pfV2QvlsgFuHHXqTQMpPpids/x0s48GswH4gN9Ucd3Jw6/ZHzf7/P1AEQhRTSMTjWCGQEWStFw5hPgdI/fA= Received: from HK2PR04MB1602.apcprd04.prod.outlook.com (10.167.71.24) by KL1PR0401MB1544.apcprd04.prod.outlook.com (10.165.249.158) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 14:19:47 +0000 Received: from HK2PR04MB1602.apcprd04.prod.outlook.com ([10.167.71.24]) by HK2PR04MB1602.apcprd04.prod.outlook.com ([10.167.71.24]) with mapi id 15.01.0492.016; Wed, 11 May 2016 14:19:47 +0000 From: Manjul Khandelwal To: "ospf@ietf.org" Thread-Topic: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt Thread-Index: AQHRqfn+1yTM+TGAuE+qPXKPuAawcJ+zzAUp Date: Wed, 11 May 2016 14:19:46 +0000 Message-ID: References: <20160509135208.4911.75434.idtracker@ietfa.amsl.com> In-Reply-To: <20160509135208.4911.75434.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nivettisystems.com; dkim=none (message not signed) header.d=none;nivettisystems.com; dmarc=none action=none header.from=nivettisystems.com; x-originating-ip: [25.169.49.132] x-ms-office365-filtering-correlation-id: 5ebb43f7-df29-4946-2ca0-08d379a74e8b x-microsoft-exchange-diagnostics: 1; KL1PR0401MB1544; 5:zXVeVe7uxv2VcuMYs7owDkRrcR6D4i8Y9vDPtqna/HTm4w0ikG34jZtX6PL7m/Rwick5p91Z99gT7zJx7nAX6yrha2+xQ0LHsdfkG/nNuUPg0T2p4KPK3vJ6JuBTjdh6MOR/ve2eayKL7g8Ch7B7dg==; 24:Y5D+PSg6WryrwTEugGUKQP7+KfwH2RlzNX0uj6vUTzR37J4dNcu9GIXZMhCYt/SuIMkv9/A3HkMQDedU8dq7VmFul7Ym5mA9/Pooda24km8=; 7:vKODz3NvCJBFPjcbgQIeX9Wpe3FO6YX9Z6ajcUaSnlYEuBrbun/DsfvqwoXuQE+RZmHxsSHlYHhsvM0XXp8xAKQWTJ9XihkOmWxujj19anXyADwm9wBVxJmxPei/dM0ZN7zOzs7GpDfYJVvuNAn7RDxJxHap61RuVz7jqZtnSmN3gYbs/90lPdRpKKIJ1s0v x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KL1PR0401MB1544; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:KL1PR0401MB1544; BCL:0; PCL:0; RULEID:; SRVR:KL1PR0401MB1544; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(377454003)(102836003)(230783001)(6116002)(106116001)(3846002)(2906002)(1730700002)(5640700001)(4001430100002)(2351001)(586003)(10400500002)(77096005)(76576001)(19580395003)(5008740100001)(19580405001)(9686002)(5003600100002)(1220700001)(87936001)(15975445007)(11100500001)(8936002)(50986999)(4326007)(110136002)(33656002)(54356999)(2900100001)(2501003)(74316001)(76176999)(3660700001)(107886002)(3900700001)(450100001)(3280700002)(15650500001)(92566002)(2950100001)(66066001)(81166006)(5004730100002)(189998001)(86362001)(122556002)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:KL1PR0401MB1544; H:HK2PR04MB1602.apcprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nivettisystems.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 14:19:46.5177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b780cc-c0fe-4e87-8da2-4702ecb31b90 X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1PR0401MB1544 Archived-At: Cc: Ramakrishna DTV Subject: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 14:19:54 -0000 Hi, We have recently submitted a draft which deals with OSPF LS sequence number generation mechanism. Abstract of the draft: The mechanism for LS sequence number generation as specified in RFC 2328 and RFC 5340 is completely predictable. This makes it prone to certain security attacks which exploit the predictable nature of LS sequence numbers. This draft updates the RFC 2328 to make LS sequence number generation an implementation choice rather than a fixed increment by 1 for successive LSAs. https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ We solicit feedback/comments on the draft and request for adoption by the OSPF working group. Regards, Manjul Khandelwal DTV Ramakrishna Rao=20 ________________________________________ From: internet-drafts@ietf.org Sent: Monday, May 9, 2016 7:22 PM To: Manjul Khandelwal; Ramakrishna DTV Subject: New Version Notification for draft-manjuldtv-ospf-sequence-number-= 00.txt A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt has been successfully submitted by Manjul Khandelwal and posted to the IETF repository. Name: draft-manjuldtv-ospf-sequence-number Revision: 00 Title: OSPF LSA sequence number generation Document date: 2016-05-09 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-manjuldtv-ospf-s= equence-number-00.txt Status: https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-seque= nce-number/ Htmlized: https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-n= umber-00 Abstract: The mechanism for LS sequence number generation as specified in RFC 2328 and RFC 5340 is completely predictable. This makes it prone to certain security attacks which exploit the predictable nature of LS sequence numbers. This draft updates the RFC 2328 to make LS sequence number generation an implementation choice rather than a fixed increment by 1 for successive LSAs. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed May 11 08:19:39 2016 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 747CA12DB40 for ; Wed, 11 May 2016 08:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyVhzuMsr5rL for ; Wed, 11 May 2016 08:19:31 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA71812DB47 for ; Wed, 11 May 2016 08:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3828; q=dns/txt; s=iport; t=1462979971; x=1464189571; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=7SncMqokwZeonYtQ+Y/2RsfEdnTxsHnNqD9/Y76gIEI=; b=lQFPGrePKp3LqFB4iNyLIug1KWbLiA7v2blGBsCtce7bQAkhb3VpDpud bT9gur+NDL9Pi2Vt87caGcl43pDgL3f2jNtMMFzZVpY2t+r2GeFBQ/nlw FGXET7y5CA0MtPj2aI67i1Uf1Y/NDkjR61AOlSAgJkfQtDMFBVo7D/pJZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQD9TDNX/4MNJK1dgzhVfQa5KQENg?= =?us-ascii?q?XYXDYVsHoEcOBQBAQEBAQEBZSeEQgEBAQQBAQEgEToJAhIBCBEEAQEDAiYCBCU?= =?us-ascii?q?LFQgKBAENBYgvDqgckHABAQEBAQEBAQEBAQEBAQEBAQEBAQEVfIlwhD+DAIJZB?= =?us-ascii?q?Y1fikgBhX2IIIFpToQBgyqFN49AAR4BAUKCNoE1bogLfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,608,1454976000"; d="scan'208";a="271581744" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2016 15:19:30 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4BFJUeo017709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 May 2016 15:19:30 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 11:19:29 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 11 May 2016 11:19:29 -0400 From: "Acee Lindem (acee)" To: Manjul Khandelwal , "ospf@ietf.org" Thread-Topic: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt Thread-Index: AQHRq5iDI45ZmPCOekqfeZl/Lp+NDg== Date: Wed, 11 May 2016 15:19:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <49693EB87A4DBE47857FF338C6CE1413@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ramakrishna DTV Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 15:19:38 -0000 SGkgTWFuanVsLCANCg0KV291bGQgaXQgYmUgcG9zc2libGUgdG8gc3VjY2luY3RseSBkZXNjcmli ZSB0aGVzZSDigJxjZXJ0YWluIHNlY3VyaXR5DQphdHRhY2tz4oCdIGluIHRoZSBkcmFmdCByYXRo ZXIgdGhhbiBleHBlY3RpbmcgZXZlcnlvbmUgdG8gcmVhZCB0aGUNCnJlZmVyZW5jZWQgcGFwZXI/ IA0KDQpUaGFua3MsDQpBY2VlIA0KDQpPbiA1LzExLzE2LCAxMDoxOSBBTSwgIk9TUEYgb24gYmVo YWxmIG9mIE1hbmp1bCBLaGFuZGVsd2FsIg0KPG9zcGYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgbWFuanVsQG5pdmV0dGlzeXN0ZW1zLmNvbT4gd3JvdGU6DQoNCj5IaSwNCj4NCj5XZSBo YXZlIHJlY2VudGx5IHN1Ym1pdHRlZCBhIGRyYWZ0IHdoaWNoIGRlYWxzIHdpdGggT1NQRiBMUyBz ZXF1ZW5jZQ0KPm51bWJlcg0KPmdlbmVyYXRpb24gbWVjaGFuaXNtLg0KPg0KPkFic3RyYWN0IG9m IHRoZSBkcmFmdDoNCj4gICBUaGUgbWVjaGFuaXNtIGZvciBMUyBzZXF1ZW5jZSBudW1iZXIgZ2Vu ZXJhdGlvbiBhcyBzcGVjaWZpZWQgaW4gUkZDDQo+ICAgMjMyOCBhbmQgUkZDIDUzNDAgaXMgY29t cGxldGVseSBwcmVkaWN0YWJsZS4gIFRoaXMgbWFrZXMgaXQgcHJvbmUgdG8NCj4gICBjZXJ0YWlu IHNlY3VyaXR5IGF0dGFja3Mgd2hpY2ggZXhwbG9pdCB0aGUgcHJlZGljdGFibGUgbmF0dXJlIG9m IExTDQo+ICAgc2VxdWVuY2UgbnVtYmVycy4gIFRoaXMgZHJhZnQgdXBkYXRlcyB0aGUgUkZDIDIz MjggdG8gbWFrZSBMUw0KPiAgIHNlcXVlbmNlIG51bWJlciBnZW5lcmF0aW9uIGFuIGltcGxlbWVu dGF0aW9uIGNob2ljZSByYXRoZXIgdGhhbiBhDQo+ICAgZml4ZWQgaW5jcmVtZW50IGJ5IDEgZm9y IHN1Y2Nlc3NpdmUgTFNBcy4NCj4NCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1tYW5qdWxkdHYtb3NwZi1zZXF1ZW5jZS1udW1iZXIvDQo+DQo+V2Ugc29saWNpdCBmZWVk YmFjay9jb21tZW50cyBvbiB0aGUgZHJhZnQgYW5kIHJlcXVlc3QgZm9yIGFkb3B0aW9uIGJ5IHRo ZQ0KPk9TUEYgd29ya2luZyBncm91cC4NCj4NCj5SZWdhcmRzLA0KPk1hbmp1bCBLaGFuZGVsd2Fs DQo+RFRWIFJhbWFrcmlzaG5hIFJhbw0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5Gcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz4NCj5TZW50OiBNb25kYXksIE1heSA5LCAyMDE2IDc6MjIgUE0NCj5UbzogTWFu anVsIEtoYW5kZWx3YWw7IFJhbWFrcmlzaG5hIERUVg0KPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3INCj5kcmFmdC1tYW5qdWxkdHYtb3NwZi1zZXF1ZW5jZS1udW1iZXItMDAu dHh0DQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1hbmp1bGR0di1vc3BmLXNlcXVl bmNlLW51bWJlci0wMC50eHQNCj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1h bmp1bCBLaGFuZGVsd2FsIGFuZCBwb3N0ZWQgdG8gdGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0K Pk5hbWU6ICAgICAgICAgICBkcmFmdC1tYW5qdWxkdHYtb3NwZi1zZXF1ZW5jZS1udW1iZXINCj5S ZXZpc2lvbjogICAgICAgMDANCj5UaXRsZTogICAgICAgICAgT1NQRiBMU0Egc2VxdWVuY2UgbnVt YmVyIGdlbmVyYXRpb24NCj5Eb2N1bWVudCBkYXRlOiAgMjAxNi0wNS0wOQ0KPkdyb3VwOiAgICAg ICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5QYWdlczogICAgICAgICAgMTANCj5VUkw6ICAg ICAgICAgICAgDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1h bmp1bGR0di1vc3BmLXNlcXVlbmNlLW51bWJlci0NCj4wMC50eHQNCj5TdGF0dXM6ICAgICAgICAg DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWFuanVsZHR2LW9zcGYt c2VxdWVuY2UtbnVtYmVyLw0KPkh0bWxpemVkOiAgICAgICANCj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbWFuanVsZHR2LW9zcGYtc2VxdWVuY2UtbnVtYmVyLTAwDQo+DQo+DQo+ QWJzdHJhY3Q6DQo+ICAgVGhlIG1lY2hhbmlzbSBmb3IgTFMgc2VxdWVuY2UgbnVtYmVyIGdlbmVy YXRpb24gYXMgc3BlY2lmaWVkIGluIFJGQw0KPiAgIDIzMjggYW5kIFJGQyA1MzQwIGlzIGNvbXBs ZXRlbHkgcHJlZGljdGFibGUuICBUaGlzIG1ha2VzIGl0IHByb25lIHRvDQo+ICAgY2VydGFpbiBz ZWN1cml0eSBhdHRhY2tzIHdoaWNoIGV4cGxvaXQgdGhlIHByZWRpY3RhYmxlIG5hdHVyZSBvZiBM Uw0KPiAgIHNlcXVlbmNlIG51bWJlcnMuICBUaGlzIGRyYWZ0IHVwZGF0ZXMgdGhlIFJGQyAyMzI4 IHRvIG1ha2UgTFMNCj4gICBzZXF1ZW5jZSBudW1iZXIgZ2VuZXJhdGlvbiBhbiBpbXBsZW1lbnRh dGlvbiBjaG9pY2UgcmF0aGVyIHRoYW4gYQ0KPiAgIGZpeGVkIGluY3JlbWVudCBieSAxIGZvciBz dWNjZXNzaXZlIExTQXMuDQo+DQo+DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+dW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+T1NQRiBtYWlsaW5nIGxpc3QNCj5PU1BG QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3BmDQoN Cg== From nobody Wed May 11 09:40:33 2016 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 AAA4412D0A0; Wed, 11 May 2016 09:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpHMK1_0i2lD; Wed, 11 May 2016 09:40:27 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1225412B02C; Wed, 11 May 2016 09:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RBH66WPAbvM2rUr2q43cd5yOyP1Ryi+uQhNWx9dZ6h4=; b=EWJQUXoasYxZC3EdTidPqLKPf+wyW6scVPoOZT1p4HYGdzlOuJoKWLDYKglalALUMS9oPeHYwf5mB46FJSRZIcUdD9h++3+Kg279bGx1RPL1sVjarDVhix3IWoCFmraGlA8DO+mw910TqGp5m1Wpz0Qr6OwAY6fs+PO8iIy2s6M= Received: from BN3PR0201MB1059.namprd02.prod.outlook.com (10.161.209.14) by BN3PR0201MB1057.namprd02.prod.outlook.com (10.161.209.13) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 16:40:25 +0000 Received: from BN3PR0201MB1059.namprd02.prod.outlook.com ([10.161.209.14]) by BN3PR0201MB1059.namprd02.prod.outlook.com ([10.161.209.14]) with mapi id 15.01.0492.016; Wed, 11 May 2016 16:40:25 +0000 From: Alan Davey To: "Derek Man-Kit Yeung (myeung)" , "draft-ietf-ospf-yang@ietf.org" Thread-Topic: draft-ietf-ospf-yang-03 questions and doubts Thread-Index: AdE3NLGjjtMGuql0QfiSt+s9ulh9zgoPjYmAAiVQNuADX5obgAcESYLgBoJ48NA= Date: Wed, 11 May 2016 16:40:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [2620:104:4001:72:c16c:9d39:5d:4b0d] x-ms-office365-filtering-correlation-id: 6e896526-0945-4a51-7da9-08d379baf42c x-microsoft-exchange-diagnostics: 1; BN3PR0201MB1057; 5:RA+l4tIMcEmd2CVrJn/wjTrwssc3P4fOMiNuY5VPixZg0YqgrvQEb4O2CJN8zFa/yynXh84zdlRUoEtYIZuYJ2KMTPUPhbheyPFLMOs+LnGJLXqMLRALPjxV+mm7D0dfpSWCmK29NNNMaENhoH+b/A==; 24:vWt0pja8IUhT/h1pPOY6yjgErLny7mmbJIE+fxslv0JhYJeWEXDXOZlnb29zz0Zj0YIYYjfIJD3ICrhpXfmon2Ded/OonlTGQx4DMTYjGRE=; 7:Fz6EeJpLkd/wMdO6ZE5NKTqN+h0IdrPTCtel4hpjAOcbs0IHwJv2UoCBGgR0sRGbVSDJSpSmHR5xmExjugmS1+60JCyl8G9TX1UpYSAXaIJbtPrFb8YbvnkuQXTStgp+qci/aHFtEPKorG0nQlNKRc+O+PjG7pBxKqxCp1w9UqfIG3g44fMtQ5LFcQ3cXPBa x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0201MB1057; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0201MB1057; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB1057; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(3660700001)(9686002)(15975445007)(77096005)(5008740100001)(122556002)(3280700002)(19300405004)(76576001)(76176999)(54356999)(74316001)(189998001)(50986999)(10400500002)(8936002)(2950100001)(2900100001)(87936001)(1220700001)(19580395003)(86362001)(19625215002)(33656002)(5001770100001)(6116002)(5004730100002)(586003)(102836003)(790700001)(5002640100001)(11100500001)(93886004)(5003600100002)(4326007)(2906002)(230783001)(81166006)(92566002)(16236675004)(2501003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB1057; H:BN3PR0201MB1059.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB10593ECF530B4B73B7EDEA38F9720BN3PR0201MB1059_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 16:40:25.3681 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB1057 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 16:40:31 -0000 --_000_BN3PR0201MB10593ECF530B4B73B7EDEA38F9720BN3PR0201MB1059_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Derek A question about the key for OSPF interfaces in the Yang draft. Please let= me know what you think. The background is that the Management Information Base definitions define i= ndices for OSPF interfaces as follows. - For OSPFv2, RFC 4750 defines the index as ospfIfIpAddress, ospfA= ddressLessIf. - For OSPFv3, RFC 5643 defines the index as ospfv3IfIndex, ospfv3I= fInstId. However, in the OSPF Yang draft, the key is defined as "interface", which I= believe is a name of the interface. How does "interface" map to the indices defined in RFCs 4750 and 5643? Thanks Alan --_000_BN3PR0201MB10593ECF530B4B73B7EDEA38F9720BN3PR0201MB1059_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Derek

 

A question about the k= ey for OSPF interfaces in the Yang draft.  Please let me know what you= think.

 

The background is that= the Management Information Base definitions define indices for OSPF interf= aces as follows.

 

-&n= bsp;         For OSPFv2, RF= C 4750 defines the index as ospfIfIpAddress, ospfAddressLessIf.<= /span>

-&n= bsp;         For OSPFv3, RF= C 5643 defines the index as ospfv3IfIndex, ospfv3IfInstId.

 

However, in the OSPF Y= ang draft, the key is defined as "interface", which I believe is = a name of the interface.

 

How does “interf= ace” map to the indices defined in RFCs 4750 and 5643?

 

Thanks

Alan=

 =

--_000_BN3PR0201MB10593ECF530B4B73B7EDEA38F9720BN3PR0201MB1059_-- From nobody Wed May 11 14:08:07 2016 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 2FC8D12D824 for ; Wed, 11 May 2016 14:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoJXUDBL4wb4 for ; Wed, 11 May 2016 14:08:03 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8978B12D147 for ; Wed, 11 May 2016 14:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2690; q=dns/txt; s=iport; t=1463000883; x=1464210483; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=++OGiBbGXtPz4SuOafvaELgMmhk8p9hJoTrkDuaQbYQ=; b=GN+jKOY/BHbJNU3aOLQeyMq9hMgWh0x86X+yby/fTjeGNIB2oPwo70kp 4QCLAqYyo7TGHZVbfXA7NpSulkdZfqXFDBcygcNJkE0OOB/vdA/ltZ+V5 9JYvEZkcywoiUGPXCCHEc+OYuVbMvDG95pky0rE3RRRFEQAQ0lMWdE/lg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAgDLnjNX/4wNJK1egziBUga3I4IPA?= =?us-ascii?q?Q2BdoYUAhyBIjgUAQEBAQEBAWUnhEMBAQQjEUUQAgEGAhoCIwMCAgIwFAEQAgQ?= =?us-ascii?q?OBYgvjFidHZBlAQEBAQEBAQEBAQEBAQEBAQEBARd8iXCEP4MAglkBBJgnAY4dg?= =?us-ascii?q?WmET4hhj0ABHgEBQoI2gTVuiAt/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,609,1454976000"; d="scan'208";a="106193172" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2016 21:08:02 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4BL81ft013379 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 May 2016 21:08:02 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 17:08:01 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 11 May 2016 17:08:01 -0400 From: "Acee Lindem (acee)" To: "Wunan (Eric)" Thread-Topic: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" Thread-Index: AQHRf/Ho6WRxQA5zQE2bUJRokiTbP5+KuacAgCnY2AA= Date: Wed, 11 May 2016 21:08:01 +0000 Message-ID: References: <0F26584357FD124DB93F1535E4B0A650841024E2@szxema508-mbx.china.huawei.com> In-Reply-To: <0F26584357FD124DB93F1535E4B0A650841024E2@szxema508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <0B97FD42BEDBE849947414163EF81209@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 21:08:05 -0000 SGkgRXJpYywgDQpXZSBkaXNjdXNzZWQgdGhpcyBib3RoIG9uIHRoZSBsaXN0IGFuZCBhdCBJRVRG IDk1LiBJbiBzdW1tYXJ5LCB0aGVyZSBpcyBubw0KZ2VuZXJhbCBhZ3JlZW1lbnQgb24gZWl0aGVy IHdoZXRoZXIgdGhlcmUgaXMgYW4gT1NQRiB0aGlyZC1wYXJ0eQ0KYXBwbGljYXRpb24gaW5mbyBk aXN0cmlidXRpb24gdXNlIGNhc2Ugb3IsIGlmIHRoZXJlIGlzIG9uZSwgd2hldGhlciB0aGlzDQpk cmFmdCBtZWV0cyB0aGUgcmVxdWlyZW1lbnRzLg0KVGhhbmtzLA0KQWNlZSANCg0KT24gNC8xNC8x NiwgMTA6MDUgUE0sICJXdW5hbiAoRXJpYykiIDxlcmljLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0K DQo+SGkgQWNlZSwNCj4NCj5JIHRoaW5rIHRoZSBtb3RpdmF0aW9uIGJlbG93IG1ha2VzIHNlbnNl LiBBY3R1YWxseSB0aGlzIGlzIHRoZSB3YXkgcGVvcGxlDQo+aGFkIGFscmVhZHkgYmVlbiBkb2lu Zywgbm90IG9ubHkgb3BlcmF0b3JzLg0KPg0KPiJPbmUgbWFqb3IgYmVuZWZpdCBvZiB1c2luZyBh ZG1pbmlzdHJhdGl2ZSB0YWdzIHJhdGhlcg0KPiAgIHRoYW4gSUFOQSBkZWZpbmVkIFRMVnMgb3Ig c3ViLVRMVnMgdG8gaW5kaWNhdGUgZGlmZmVyZW50IHNlcnZpY2VzIGlzDQo+ICAgdG8gZmFjaWxp dGF0ZSB0aGUgcmFwaWQgZGVwbG95bWVudCBvZiBuZXcgc2VydmljZXMgd2l0aG91dCBhbnkgbmVl ZA0KPiAgIGZvciB0aGUgc3RhbmRhcmRpemF0aW9uIG9mIHRob3NlIFRMVnMgb3Igc3ViLVRMVnMu ICBIb3dldmVyLCB0aGVyZQ0KPiAgIGFyZSBzb21lIHNwZWNpYWwgdXNlIGNhc2VzIHdoZXJlIHRo ZSBzZXJ2aWNlIHRvIGJlIGFkdmVydGlzZWQgaGFzIG9uZQ0KPiAgIG9yIG1vcmUgYXR0cmlidXRl cyB3aGljaCBuZWVkIHRvIGJlIGFkdmVydGlzZWQgYXMgd2VsbC4gIEluIHN1Y2gNCj4gICBjYXNl LCB0aGUgYWRtaW5pc3RyYXRpdmUgdGFnIGlzIG5vdCBtdWNoIGFwcGxpY2FibGUgYW55bW9yZSIN Cj4NCj5QZXJzb25hbGx5IEkgd2lzaCBvbmUgbW9yZSBnZW5lcmFsaXplZCBtZWNoYW5pc20gY2Fu IGV4aXN0IGluc3RlYWQgb2Ygb25lDQo+Tm9kZSB0YWcgYW5kIG9uZSBwcm9wcmlldGFyeSBUTFYu DQo+QW55d2F5LCBJJ2QgbGlrZSB0byBzZWUgdGhpcyBJLUQgY2FuIGdvIGZ1cnRoZXIgYW5kICJs b3Qgb2YgdGhpbmdzIHdlIGNhbg0KPmZ1cnRoZXIgaW1wcm92ZSIgYXQgdGhlIHNhbWUgdGltZSwg YXMgVW1hIG1lbnRpb25lZC4NCj4NCj5SZWdhcmRzDQo+RXJpYw0KPg0KPj4gLS0tLS3pgq7ku7bl jp/ku7YtLS0tLQ0KPj4g5Y+R5Lu25Lq6OiBBY2VlIExpbmRlbSAoYWNlZSkgW21haWx0bzphY2Vl QGNpc2NvLmNvbV0NCj4+IOWPkemAgeaXtumXtDogMjAxNuW5tDPmnIgxN+aXpSAxMDowOQ0KPj4g 5pS25Lu25Lq6OiBPU1BGIFdHIExpc3QNCj4+IOS4u+mimDogW09TUEZdIFdHIEFkb3B0aW9uIFBv bGwgZm9yICJVc2luZyBPcGVyYXRvci1kZWZpbmVkIFRMVnMgZm9yIEFnaWxlDQo+PlNlcnZpY2UN Cj4+IERlcGxveW1lbnQiDQo+PiANCj4+IFdl4oCZdmUgZGlzY3Vzc2VkIHRoaXMgZHJhZnQgYSBu dW1iZXIgb2YgdGltZXMuIEluIG15IG9waW5pb24sIGl0IHNlZW1zDQo+Pmxpa2UgYSB1c2VmdWwN Cj4+IG1lY2hhbmlzbSBpZiBvbmUgZW52aXNpb25zIGEgZ2VuZXJhbGl6ZWQgQVBJIGJldHdlZW4g T1NQRiBhbmQgdXNlciBhbmQNCj4+dGhpcmQtcGFydHkNCj4+IGFwcGxpY2F0aW9ucyB0byBjb252 ZXkgYXBwbGljYXRpb24tc3BlY2lmaWMgaW5mb3JtYXRpb24gbGVhcm5lZCBmcm9tDQo+Pm90aGVy IE9TUEYNCj4+IHJvdXRlcnMuIEluIG1hbnkgcmVzcGVjdHMsIHRoaXMgaGFzIGFscmVhZHkgYmVl biBlbnZpc2lvbmVkIGZvciBPU1BGDQo+Pk5vZGUgVGFncy4NCj4+IFBsZWFzZSBpbmRpY2F0ZSB5 b3VyIG9waW5pb24gb24gdGhpcyBkcmFmdCBiZWZvcmUgTWFyY2ggMzFzdCwgMjAxNi4NCj4+IA0K Pj4gVGhhbmtzLA0KPj4gQWNlZQ0KPg0KDQo= From nobody Wed May 11 19:29:36 2016 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 8793512D842 for ; Wed, 11 May 2016 19:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorg676131.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wE5lvu9PoFNK for ; Wed, 11 May 2016 19:29:31 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0099.outbound.protection.outlook.com [104.47.124.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6820312D0D8 for ; Wed, 11 May 2016 19:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORG676131.onmicrosoft.com; s=selector1-nivettisystems-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BgjBDb+R7nJwonB9AZ1RYnicajcU4wd/tXOFV5iATOc=; b=mCBi2KB7ljxTOrtZSaWPkS5XtuWiaiIthB4wRj14+sS8IiaUbHqvG+xcokTEJxgvCp+ovgSJCqaIS+G9MnHBk8fwGfrCgAfLLCeLTcHlgtpEbmXfBBDkZ+c8PHI4uRI+atJVUOYUmxVKtza9+q5EyL2tMltednFGtmDs1CcI3z0= Received: from KL1PR0401MB1544.apcprd04.prod.outlook.com (10.165.249.158) by HK2PR04MB1601.apcprd04.prod.outlook.com (10.167.71.23) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 02:29:28 +0000 Received: from KL1PR0401MB1544.apcprd04.prod.outlook.com ([10.165.249.158]) by KL1PR0401MB1544.apcprd04.prod.outlook.com ([10.165.249.158]) with mapi id 15.01.0492.016; Thu, 12 May 2016 02:29:27 +0000 From: Ramakrishna DTV To: "Acee Lindem (acee)" , Manjul Khandelwal , "ospf@ietf.org" Thread-Topic: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt Thread-Index: AQHRq5iDI45ZmPCOekqfeZl/Lp+NDp+0k8d6 Date: Thu, 12 May 2016 02:29:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nivettisystems.com; x-originating-ip: [132.245.69.37] x-ms-office365-filtering-correlation-id: c9049cce-166d-4f40-15cb-08d37a0d3d9d x-microsoft-exchange-diagnostics: 1; HK2PR04MB1601; 5:xJvhPOtXM7MkYnQ24Fml0hfFOlsA6tF7xP/VxxhPfb2GmyZSVlvKTStVF6ZPdCCpk2Ir81Hi0h/xny2cPaFtGduX0RO12QXqWquyhVS6rrDizZ5XmPvQX9vUSJICFYyndDZDYC2Zu1Fwim2703VDjw==; 24:fg70W/QTgsyMc4M4y9eauUiGYfxrpQv/7ImQYKpwwtWd3i0+/BGA3mb1LjPA++mSbHKUZUq7RbjZKkTL61EaYW4G/R5Te5+Wwdg5Kupvt7E=; 7:+zeV503UyWsn80LkRWJwXLWDsxvTDucpJQXxuWoT8OcNzRU4QYlPKhveFsD9J1lapx3Bu5xndrcgtgBPaScJJMgRpl0DN/E0EJaqKsL7YXNltI6AbItWuoluwIpg4J8A8O9vQth/d7lhZ8cVg9T9hHxD6fVKhldfcUDZV6LhW0FFlZKIJ1Hdo3cvqcBLJe6u x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HK2PR04MB1601; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:HK2PR04MB1601; BCL:0; PCL:0; RULEID:; SRVR:HK2PR04MB1601; x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377424004)(377454003)(51884002)(87936001)(10400500002)(102836003)(54356999)(50986999)(76176999)(6116002)(3280700002)(586003)(1220700001)(3846002)(3660700001)(106116001)(19580395003)(81166006)(5008740100001)(92566002)(74316001)(66066001)(9686002)(2501003)(19580405001)(8936002)(2950100001)(3900700001)(15650500001)(2900100001)(5003600100002)(5002640100001)(86362001)(15975445007)(122556002)(230783001)(5004730100002)(2906002)(76576001)(33656002)(5001770100001)(107886002)(189998001)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:HK2PR04MB1601; H:KL1PR0401MB1544.apcprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nivettisystems.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2016 02:29:26.8583 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b780cc-c0fe-4e87-8da2-4702ecb31b90 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2PR04MB1601 Archived-At: Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 02:29:34 -0000 Hi Acee, We currently provided the following description of this attack in the draft= : "The paper refers to the attack as "Disguised LSA" and is of persistent nature. This attack is launched from a compromised router inside a routing domain. In this attack, the compromised router alters the LSA of an uncompromised router (victim). Normally, such an attempt does not have persistence because the victim generates a new LSA when it sees such self-originated LSAs (referred to as "fight-back" mechanism in the paper). But the paper makes disguised LSA persistent because all the fields { LS sequence number, checksum} are predictable. It alters the existing LSA of victim to suit its needs but sets the sequence number to +1 of the existing LSA and alters the LSA so that checksum matches with checksum that would be generated by the victim when it generates the new LSA. When this disguised LSA reaches the victim, it does not fight back because it compares only the fields { LS sequence number, checksum, age} to check for duplicates and not the actual content of LSA. This attack enables an insider attacker to fully control the entire content of an LSA. We think this attack is powerful." These details are currently present in Section 4, which is titled "Implemen= tation advice". We can probably move it to a different section (e.g., "Introduction") to ma= ke it clear. If you think even more additional details about the attack are useful to th= e working group,=20 please let us know. We will add. Thank you. Regards, Ramakrishna DTV. ________________________________________ From: Acee Lindem (acee) Sent: Wednesday, May 11, 2016 8:49 PM To: Manjul Khandelwal; ospf@ietf.org Cc: Ramakrishna DTV Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-s= equence-number-00.txt Hi Manjul, Would it be possible to succinctly describe these =93certain security attacks=94 in the draft rather than expecting everyone to read the referenced paper? Thanks, Acee On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal" wrote: >Hi, > >We have recently submitted a draft which deals with OSPF LS sequence >number >generation mechanism. > >Abstract of the draft: > The mechanism for LS sequence number generation as specified in RFC > 2328 and RFC 5340 is completely predictable. This makes it prone to > certain security attacks which exploit the predictable nature of LS > sequence numbers. This draft updates the RFC 2328 to make LS > sequence number generation an implementation choice rather than a > fixed increment by 1 for successive LSAs. > >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ > >We solicit feedback/comments on the draft and request for adoption by the >OSPF working group. > >Regards, >Manjul Khandelwal >DTV Ramakrishna Rao >________________________________________ >From: internet-drafts@ietf.org >Sent: Monday, May 9, 2016 7:22 PM >To: Manjul Khandelwal; Ramakrishna DTV >Subject: New Version Notification for >draft-manjuldtv-ospf-sequence-number-00.txt > >A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt >has been successfully submitted by Manjul Khandelwal and posted to the >IETF repository. > >Name: draft-manjuldtv-ospf-sequence-number >Revision: 00 >Title: OSPF LSA sequence number generation >Document date: 2016-05-09 >Group: Individual Submission >Pages: 10 >URL: >https://www.ietf.org/internet-drafts/draft-manjuldtv-ospf-sequence-number- >00.txt >Status: >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ >Htmlized: >https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00 > > >Abstract: > The mechanism for LS sequence number generation as specified in RFC > 2328 and RFC 5340 is completely predictable. This makes it prone to > certain security attacks which exploit the predictable nature of LS > sequence numbers. This draft updates the RFC 2328 to make LS > sequence number generation an implementation choice rather than a > fixed increment by 1 for successive LSAs. > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From nobody Wed May 11 19:55:41 2016 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 B631A12D0B7 for ; Wed, 11 May 2016 19:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDuRyIUvyv0w for ; Wed, 11 May 2016 19:55:36 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8980D12B041 for ; Wed, 11 May 2016 19:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5466; q=dns/txt; s=iport; t=1463021736; x=1464231336; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JVvcpPFz2kJUxyqQRiJWxhtBd6X5uywWNZzohJaBHiA=; b=LFlhiYjP7o/Ux9MpvWjTYJ1BhBK39mrdB4tj99nKF2PXUrAQfk/wy3ad iin4duDZNmel3jw6SBGIqkQVEa6c69lsbj6/sQcyKD00Jf50vQ+/yUv/L o51o0AMESW4FbQ2kNh9TMm7FM7PvlrgNkkJb4jr7VW9IEV2tCItjlNRw5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQCn7zNX/4UNJK1egzhVfQa5RgENg?= =?us-ascii?q?XYXDYVwAoE1OBQBAQEBAQEBZSeEQgEBAQMBAQEBawkCBQsCAQgRBAEBAS4nCx0?= =?us-ascii?q?IAgQOBYgnCA66aAEBAQEBAQEBAQEBAQEBAQEBAQEBARWIFoJWhD+DK4IuAQSNX?= =?us-ascii?q?4pIAYV9iCCBaU6EAYMqhTePQAEeAQFCgjaBNW6HMn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,609,1454976000"; d="scan'208";a="272395871" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 May 2016 02:55:35 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u4C2tZJD008983 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 May 2016 02:55:35 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 22:55:34 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 11 May 2016 22:55:34 -0400 From: "Acee Lindem (acee)" To: Ramakrishna DTV Thread-Topic: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt Thread-Index: AQHRq5iDI45ZmPCOekqfeZl/Lp+NDp+0k8d6gABLlwA= Date: Thu, 12 May 2016 02:55:34 +0000 Message-ID: <8BADADAD-9B3F-4CC0-AF80-7B41E909F324@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.201] Content-Type: text/plain; charset="Windows-1252" Content-ID: <98B3CDC9D3005E46894EFCDCD5F741B6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ospf@ietf.org" , Manjul Khandelwal Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 02:55:39 -0000 Hi Ramakrishna,=20 I believe there is a flaw in the description of the =93Disguised LSA=94 att= ack. If the sequence number of the LSA is set to +1 by the attacker, the or= iginator (aka, the victim) will determine that the received LSA is newer an= d will originate a newer LSA (=93fight-back=94) as described below. See sec= tion 13.1 and 13.4 in RFC 2328.=20 Thanks, Acee=20 > On May 11, 2016, at 10:29 PM, Ramakrishna DTV wrote: >=20 > Hi Acee, >=20 > We currently provided the following description of this attack in the dra= ft: >=20 > "The paper refers to the attack as "Disguised LSA" and is of > persistent nature. This attack is launched from a compromised router > inside a routing domain. In this attack, the compromised router > alters the LSA of an uncompromised router (victim). Normally, such > an attempt does not have persistence because the victim generates a > new LSA when it sees such self-originated LSAs (referred to as > "fight-back" mechanism in the paper). But the paper makes disguised > LSA persistent because all the fields { LS sequence number, checksum} > are predictable. It alters the existing LSA of victim to suit its > needs but sets the sequence number to +1 of the existing LSA and > alters the LSA so that checksum matches with checksum that would be > generated by the victim when it generates the new LSA. When this > disguised LSA reaches the victim, it does not fight back because it > compares only the fields { LS sequence number, checksum, age} to > check for duplicates and not the actual content of LSA. >=20 > This attack enables an insider attacker to fully control the entire > content of an LSA. We think this attack is powerful." >=20 > These details are currently present in Section 4, which is titled "Implem= entation advice". > We can probably move it to a different section (e.g., "Introduction") to = make it clear. >=20 > If you think even more additional details about the attack are useful to = the working group,=20 > please let us know. We will add. >=20 > Thank you. >=20 > Regards, > Ramakrishna DTV. >=20 >=20 > ________________________________________ > From: Acee Lindem (acee) > Sent: Wednesday, May 11, 2016 8:49 PM > To: Manjul Khandelwal; ospf@ietf.org > Cc: Ramakrishna DTV > Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf= -sequence-number-00.txt >=20 > Hi Manjul, >=20 > Would it be possible to succinctly describe these =93certain security > attacks=94 in the draft rather than expecting everyone to read the > referenced paper? >=20 > Thanks, > Acee >=20 > On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal" > wrote: >=20 >> Hi, >>=20 >> We have recently submitted a draft which deals with OSPF LS sequence >> number >> generation mechanism. >>=20 >> Abstract of the draft: >> The mechanism for LS sequence number generation as specified in RFC >> 2328 and RFC 5340 is completely predictable. This makes it prone to >> certain security attacks which exploit the predictable nature of LS >> sequence numbers. This draft updates the RFC 2328 to make LS >> sequence number generation an implementation choice rather than a >> fixed increment by 1 for successive LSAs. >>=20 >> https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ >>=20 >> We solicit feedback/comments on the draft and request for adoption by th= e >> OSPF working group. >>=20 >> Regards, >> Manjul Khandelwal >> DTV Ramakrishna Rao >> ________________________________________ >> From: internet-drafts@ietf.org >> Sent: Monday, May 9, 2016 7:22 PM >> To: Manjul Khandelwal; Ramakrishna DTV >> Subject: New Version Notification for >> draft-manjuldtv-ospf-sequence-number-00.txt >>=20 >> A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt >> has been successfully submitted by Manjul Khandelwal and posted to the >> IETF repository. >>=20 >> Name: draft-manjuldtv-ospf-sequence-number >> Revision: 00 >> Title: OSPF LSA sequence number generation >> Document date: 2016-05-09 >> Group: Individual Submission >> Pages: 10 >> URL: >> https://www.ietf.org/internet-drafts/draft-manjuldtv-ospf-sequence-numbe= r- >> 00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ >> Htmlized: >> https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00 >>=20 >>=20 >> Abstract: >> The mechanism for LS sequence number generation as specified in RFC >> 2328 and RFC 5340 is completely predictable. This makes it prone to >> certain security attacks which exploit the predictable nature of LS >> sequence numbers. This draft updates the RFC 2328 to make LS >> sequence number generation an implementation choice rather than a >> fixed increment by 1 for successive LSAs. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >=20 From nobody Wed May 11 20:46:41 2016 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 22F5D12B048 for ; Wed, 11 May 2016 20:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fO74GVIrZ_lE for ; Wed, 11 May 2016 20:46:37 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EABC12D5C9 for ; Wed, 11 May 2016 20:46:34 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id j74so62089526ywg.1 for ; Wed, 11 May 2016 20:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Jbxdk2SkK0drN6mvmLAI07XAPthTyG8dPn4JQhmzaKg=; b=A1WaCP6SNY9MxxaHpsl+vxP0ulT5uWTEKl7fcyJw/Krp8PSOkyzsA6zf8fzbqZt3dT X+2bNF2sFAMVWsrVs++z5imaKlx8lmONlfFrnKblXnFJVS6IfCmxob79eRWCLXhbIBoN ktTawW6vE/yH0LS+Eg5k9jxTAit0wxGHdbIXawcGc6dsZgOtge2xlEfPXJX+pX/VHdoo 3ssSBoZPBZ3p/dmvUYf8Di538rwywIqu+zDwsGtI3wXV0MLM4GeLlNMV3fpdgwepZxXC iFXIqLzV/aB+gB09N+OkzEPr1Ej169bsIWr6uWuWqn3n24psURz+3OVtFhWbW+NPC7lC 1YAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Jbxdk2SkK0drN6mvmLAI07XAPthTyG8dPn4JQhmzaKg=; b=hZAY2rv2UBM31WHxCnfeK3RuPLhzTGNilPXbZBKrY+rVxhuIkWWvfud2Utf0nN0oeu Pq0pdIPCd0v7N1VTI9TQLq63dePfcuphu1+1W10l+U6sUEeTyGOw1trY93pj+TTipIFx 6vQR6k85Qevh6MEItsCw2lXskNHAfhuD1VB6OqVYXYlLO9LE6DUTq8hcaRW/WyNRVcx5 nPjxEvcUQS8HNeR8nT6/xJ7w7VWd3U2iHfbFRWVpHL8E86JdjLQQdKCUPGbrIf4aB8CB CYe3RQkXynKfZbHMtctraCGrsbH7R8jzvNqMlqhBe2FsypXHYZcYPhPvkRTsTRiw8TXB wYLg== X-Gm-Message-State: AOPr4FWdn3Z//iGVnBZOgFEnk0EPAWEc5OY8+e1uYL3t+ZIe6xwrbL5I6YE5/yO4G9R8oJJoUWbQRI0ySNUvlw== MIME-Version: 1.0 X-Received: by 10.37.47.85 with SMTP id v82mr3475064ybv.75.1463024793427; Wed, 11 May 2016 20:46:33 -0700 (PDT) Received: by 10.13.216.129 with HTTP; Wed, 11 May 2016 20:46:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2016 09:16:33 +0530 Message-ID: From: Manav Bhatia To: Ramakrishna DTV Content-Type: multipart/alternative; boundary=001a1140be9e1c2a0705329d01d5 Archived-At: Cc: "ospf@ietf.org" , Manjul Khandelwal Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 03:46:40 -0000 --001a1140be9e1c2a0705329d01d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi DTV, I dont agree to your assessment of how the attack evades the "natural fight-back mechanism" in OSPF. Its got *nothing* to do with the sequence numbers being predictable, etc. I have explained in depth how the Gaby attack works here: https://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerabi= lity-exposed-by-black-hat/ Clipped from the blog: "This attack exploits a potential omission (or a bug if you will) in the standard where it does not mandate that the receiving router verifies that the Link State ID and the Advertising Router fields in the Router LSA are the exact same value. This attack sends malacious Router LSAs with two different values in the LS header. The Link State ID carries the Router ID of the router that is being attacked (the victim) and the Advertising Router is set to some different (any) value. When the victim receives the malacious Router LSA, it does not refresh this LSA as it doesnt recognize this as its own self generated LSA. This is because the OSPF spec clearly says in Sec 13.4 that =E2=80=9CA self-origina= ted LSA is detected when either 1) The LSA=E2=80=99s Advertising Router is equal to= the router=E2=80=99s own Router ID or 2) the LSA is a network LSA .. =E2=80=9C. This means that OSPF=E2=80=99s natural fight back mechanism is NOT triggere= d by the victim router as long as the field =E2=80=98Advertising Router=E2=80=99 of = a LSA is NOT equal to the victim=E2=80=99s Router ID. This is true even if the =E2=80=98= Link State ID=E2=80=99 of that LSA is equal to the victim=E2=80=99s Router ID. Going further it me= ans no LSA refresh is triggered even if the malacious LSA claims to describe the links of the victim router!" I describe further in the blog that not all router implementations are susceptible to the attack. Its dependent on how the LSA is picked up from the LSDB. Cheers, Manav On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV < ramakrishnadtv@nivettisystems.com> wrote: > Hi Acee, > > We currently provided the following description of this attack in the > draft: > > "The paper refers to the attack as "Disguised LSA" and is of > persistent nature. This attack is launched from a compromised router > inside a routing domain. In this attack, the compromised router > alters the LSA of an uncompromised router (victim). Normally, such > an attempt does not have persistence because the victim generates a > new LSA when it sees such self-originated LSAs (referred to as > "fight-back" mechanism in the paper). But the paper makes disguised > LSA persistent because all the fields { LS sequence number, checksum} > are predictable. It alters the existing LSA of victim to suit its > needs but sets the sequence number to +1 of the existing LSA and > alters the LSA so that checksum matches with checksum that would be > generated by the victim when it generates the new LSA. When this > disguised LSA reaches the victim, it does not fight back because it > compares only the fields { LS sequence number, checksum, age} to > check for duplicates and not the actual content of LSA. > > This attack enables an insider attacker to fully control the entire > content of an LSA. We think this attack is powerful." > > These details are currently present in Section 4, which is titled > "Implementation advice". > We can probably move it to a different section (e.g., "Introduction") to > make it clear. > > If you think even more additional details about the attack are useful to > the working group, > please let us know. We will add. > > Thank you. > > Regards, > Ramakrishna DTV. > > > ________________________________________ > From: Acee Lindem (acee) > Sent: Wednesday, May 11, 2016 8:49 PM > To: Manjul Khandelwal; ospf@ietf.org > Cc: Ramakrishna DTV > Subject: Re: [OSPF] Fw: New Version Notification for > draft-manjuldtv-ospf-sequence-number-00.txt > > Hi Manjul, > > Would it be possible to succinctly describe these =E2=80=9Ccertain securi= ty > attacks=E2=80=9D in the draft rather than expecting everyone to read the > referenced paper? > > Thanks, > Acee > > On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal" > wrote: > > >Hi, > > > >We have recently submitted a draft which deals with OSPF LS sequence > >number > >generation mechanism. > > > >Abstract of the draft: > > The mechanism for LS sequence number generation as specified in RFC > > 2328 and RFC 5340 is completely predictable. This makes it prone to > > certain security attacks which exploit the predictable nature of LS > > sequence numbers. This draft updates the RFC 2328 to make LS > > sequence number generation an implementation choice rather than a > > fixed increment by 1 for successive LSAs. > > > >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ > > > >We solicit feedback/comments on the draft and request for adoption by th= e > >OSPF working group. > > > >Regards, > >Manjul Khandelwal > >DTV Ramakrishna Rao > >________________________________________ > >From: internet-drafts@ietf.org > >Sent: Monday, May 9, 2016 7:22 PM > >To: Manjul Khandelwal; Ramakrishna DTV > >Subject: New Version Notification for > >draft-manjuldtv-ospf-sequence-number-00.txt > > > >A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt > >has been successfully submitted by Manjul Khandelwal and posted to the > >IETF repository. > > > >Name: draft-manjuldtv-ospf-sequence-number > >Revision: 00 > >Title: OSPF LSA sequence number generation > >Document date: 2016-05-09 > >Group: Individual Submission > >Pages: 10 > >URL: > > > https://www.ietf.org/internet-drafts/draft-manjuldtv-ospf-sequence-number= - > >00.txt > >Status: > >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ > >Htmlized: > >https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00 > > > > > >Abstract: > > The mechanism for LS sequence number generation as specified in RFC > > 2328 and RFC 5340 is completely predictable. This makes it prone to > > certain security attacks which exploit the predictable nature of LS > > sequence numbers. This draft updates the RFC 2328 to make LS > > sequence number generation an implementation choice rather than a > > fixed increment by 1 for successive LSAs. > > > > > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >The IETF Secretariat > > > >_______________________________________________ > >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 > --001a1140be9e1c2a0705329d01d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi DTV,

I dont agree to your assessment= of how the attack evades the "natural fight-back mechanism" in O= SPF.=C2=A0

Its got *nothing* to do with the sequen= ce numbers being predictable, etc. I have explained in depth how the Gaby a= ttack works here:


Clipped = from the blog:

"This attack exploits a potential omissio= n (or a bug if you will) in the standard where it does not mandate that the= receiving router verifies that the Link State ID and the Advertising Route= r fields in the Router LSA are the exact same value.

This attack sen= ds malacious Router LSAs with two different values in the LS header. The Li= nk State ID carries the Router ID of the router that is being attacked (the= victim) and the Advertising Router is set to some different (any) value.
When the victim receives the malacious Router LSA, it does not refres= h this LSA as it doesnt recognize this as its own=C2=A0self generated LSA. = This is because the OSPF spec clearly says in Sec 13.4 that =E2=80=9CA self= -originated LSA is detected when either 1) The LSA=E2=80=99s Advertising Ro= uter is equal to the router=E2=80=99s own Router ID or 2) the LSA is a netw= ork LSA .. =E2=80=9C.

This means that OSPF=E2=80=99s natural f= ight back mechanism is NOT triggered by the victim router as long as the fi= eld =E2=80=98Advertising Router=E2=80=99 of a LSA is NOT equal to the victi= m=E2=80=99s Router ID. This is true even if the =E2=80=98Link State ID=E2= =80=99 of that LSA is equal to the victim=E2=80=99s Router ID. Going furthe= r it means no LSA refresh is triggered even if the malacious LSA claims to = describe the links of the victim router!"

I describ= e further in the blog that not all router implementations are susceptible t= o the attack. Its dependent on how the LSA is picked up from the LSDB.=C2= =A0

Cheers, Manav

On Thu, May 12, 2016 at 7:59 AM, Ramak= rishna DTV <ramakrishnadtv@nivettisystems.com> wrote:
Hi Acee,

We currently provided the following description of this attack in the draft= :

=C2=A0"The paper refers to the attack as "Disguised LSA" and= is of
=C2=A0 =C2=A0persistent nature.=C2=A0 This attack is launched from a compro= mised router
=C2=A0 =C2=A0inside a routing domain.=C2=A0 In this attack, the compromised= router
=C2=A0 =C2=A0alters the LSA of an uncompromised router (victim).=C2=A0 Norm= ally, such
=C2=A0 =C2=A0an attempt does not have persistence because the victim genera= tes a
=C2=A0 =C2=A0new LSA when it sees such self-originated LSAs (referred to as=
=C2=A0 =C2=A0"fight-back" mechanism in the paper).=C2=A0 But the = paper makes disguised
=C2=A0 =C2=A0LSA persistent because all the fields { LS sequence number, ch= ecksum}
=C2=A0 =C2=A0are predictable.=C2=A0 It alters the existing LSA of victim to= suit its
=C2=A0 =C2=A0needs but sets the sequence number to +1 of the existing LSA a= nd
=C2=A0 =C2=A0alters the LSA so that checksum matches with checksum that wou= ld be
=C2=A0 =C2=A0generated by the victim when it generates the new LSA.=C2=A0 W= hen this
=C2=A0 =C2=A0disguised LSA reaches the victim, it does not fight back becau= se it
=C2=A0 =C2=A0compares only the fields { LS sequence number, checksum, age} = to
=C2=A0 =C2=A0check for duplicates and not the actual content of LSA.

=C2=A0 =C2=A0This attack enables an insider attacker to fully control the e= ntire
=C2=A0 =C2=A0content of an LSA.=C2=A0 We think this attack is powerful.&quo= t;

These details are currently present in Section 4, which is titled "Imp= lementation advice".
We can probably move it to a different section (e.g., "Introduction&qu= ot;) to make it clear.

If you think even more additional details about the attack are useful to th= e working group,
please let us know. We will add.

Thank you.

Regards,
Ramakrishna DTV.


________________________________________
From: Acee Lindem (acee) <acee@cisco.c= om>
Sent: Wednesday, May 11, 2016 8:49 PM
To: Manjul Khandelwal; ospf@ietf.org Cc: Ramakrishna DTV
Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-s= equence-number-00.txt

Hi Manjul,

Would it be possible to succinctly describe these =E2=80=9Ccertain security=
attacks=E2=80=9D in the draft rather than expecting everyone to read the referenced paper?

Thanks,
Acee

On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal"
<ospf-bounces@ietf.org on b= ehalf of manjul@nivettisystems= .com> wrote:

>Hi,
>
>We have recently submitted a draft which deals with OSPF LS sequence >number
>generation mechanism.
>
>Abstract of the draft:
>=C2=A0 =C2=A0The mechanism for LS sequence number generation as specifi= ed in RFC
>=C2=A0 =C2=A02328 and RFC 5340 is completely predictable.=C2=A0 This ma= kes it prone to
>=C2=A0 =C2=A0certain security attacks which exploit the predictable nat= ure of LS
>=C2=A0 =C2=A0sequence numbers.=C2=A0 This draft updates the RFC 2328 to= make LS
>=C2=A0 =C2=A0sequence number generation an implementation choice rather= than a
>=C2=A0 =C2=A0fixed increment by 1 for successive LSAs.
>
>https://datatracker.ietf.o= rg/doc/draft-manjuldtv-ospf-sequence-number/
>
>We solicit feedback/comments on the draft and request for adoption by t= he
>OSPF working group.
>
>Regards,
>Manjul Khandelwal
>DTV Ramakrishna Rao
>________________________________________
>From: internet-drafts@ietf.= org <internet-drafts@iet= f.org>
>Sent: Monday, May 9, 2016 7:22 PM
>To: Manjul Khandelwal; Ramakrishna DTV
>Subject: New Version Notification for
>draft-manjuldtv-ospf-sequence-number-00.txt
>
>A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt
>has been successfully submitted by Manjul Khandelwal and posted to the<= br> >IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-manjuldtv-ospf-sequ= ence-number
>Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OSPF LSA sequence number gener= ation
>Document date:=C2=A0 2016-05-09
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
>URL:
>https://www.ietf.org/i= nternet-drafts/draft-manjuldtv-ospf-sequence-number-
>00.txt
>Status:
>https://datatracker.ietf.o= rg/doc/draft-manjuldtv-ospf-sequence-number/
>Htmlized:
>https://tools.ietf.org/html/d= raft-manjuldtv-ospf-sequence-number-00
>
>
>Abstract:
>=C2=A0 =C2=A0The mechanism for LS sequence number generation as specifi= ed in RFC
>=C2=A0 =C2=A02328 and RFC 5340 is completely predictable.=C2=A0 This ma= kes it prone to
>=C2=A0 =C2=A0certain security attacks which exploit the predictable nat= ure of LS
>=C2=A0 =C2=A0sequence numbers.=C2=A0 This draft updates the RFC 2328 to= make LS
>=C2=A0 =C2=A0sequence number generation an implementation choice rather= than a
>=C2=A0 =C2=A0fixed increment by 1 for successive LSAs.
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org. >
>The IETF Secretariat
>
>_______________________________________________
>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

--001a1140be9e1c2a0705329d01d5-- From nobody Wed May 11 21:49:08 2016 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 C4E4912D679 for ; Wed, 11 May 2016 21:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorg676131.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euF9k24QzXkN for ; Wed, 11 May 2016 21:49:04 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0110.outbound.protection.outlook.com [104.47.124.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C92212D0DD for ; Wed, 11 May 2016 21:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORG676131.onmicrosoft.com; s=selector1-nivettisystems-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6sqqEb71bYqDF/0cEUde6D2f+/ZG9XNLDBQwqJst2xA=; b=Ythu352CU+yhD5wdolOnCPTYJZ4OK8/GbVCj4T/J5hh/G9w5D+VNmTJw7ww1aF2u/5Aq/eNgQCgJjiW3gdthVlkJJQGO1VoJKtrwL3IMvRX2tmWGDNZeZ81RYVjNQG7w9NcPZ8czJPcJ20g0B/9aHPY2E0kFSBxHzS2v18iU0oY= Received: from KL1PR0401MB1544.apcprd04.prod.outlook.com (10.165.249.158) by KL1PR04MB1606.apcprd04.prod.outlook.com (10.167.61.28) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 04:49:00 +0000 Received: from KL1PR0401MB1544.apcprd04.prod.outlook.com ([10.165.249.158]) by KL1PR0401MB1544.apcprd04.prod.outlook.com ([10.165.249.158]) with mapi id 15.01.0492.016; Thu, 12 May 2016 04:48:59 +0000 From: Ramakrishna DTV To: Manav Bhatia Thread-Topic: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt Thread-Index: AQHRq5iDI45ZmPCOekqfeZl/Lp+NDp+0k8d6gAAWyICAABC5kQ== Date: Thu, 12 May 2016 04:48:59 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nivettisystems.com; x-originating-ip: [25.169.49.132] x-ms-office365-filtering-correlation-id: ac24acd0-1281-4e3e-8310-08d37a20bbe7 x-microsoft-exchange-diagnostics: 1; KL1PR04MB1606; 5:SQ+/HHb3vK6AMJSbs0/VeZl0ThncOyY3sqioRlex2NekZHI44XfCs4WxKNLIIFazGVlz9QAQM6Y6Fw3NDcSoiH0GuJMfplgmAN4nzqNOTcT4rkjhno3Nipx5hoCV2LCkdefqPrKnOC7ETXc08ucYww==; 24:SsVOBlT1jco/k0TaqmL8IjauX7Fj3N2wXBsaadNIJsvsDBcGY97qDNOiyT8DslM50stsqTb/bKxdjxh+fzTBR3QPbDJnQOjrEBqkSGqE+wM=; 7:egpO0QE8fQHnnBcyvnXmIOVfV6VT8D7gFK9e1/OWShqfDhq52Yt3JI4ChbpLO5xE7MMULx0cmt9KJouCMZ8gTV7RL7sTjkRVAWfzfDPOmatwretLkEr/pTuw5Lclm1xXhQ2W99qFFsjznWm+PzGSSMECsGHwAnVGWt38kmQe1YxA+d1MyMgH2eoOHJZqMAda x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KL1PR04MB1606; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046); SRVR:KL1PR04MB1606; BCL:0; PCL:0; RULEID:; SRVR:KL1PR04MB1606; x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51884002)(24454002)(377424004)(377454003)(3660700001)(122556002)(10400500002)(77096005)(14971765001)(92566002)(87936001)(19580395003)(19580405001)(3900700001)(5002640100001)(66066001)(33656002)(86362001)(19625215002)(5004730100002)(74316001)(16236675004)(76176999)(50986999)(54356999)(10710500007)(19617315012)(3280700002)(4326007)(5008740100001)(1220700001)(16601075003)(2420400007)(9686002)(6116002)(586003)(102836003)(5003600100002)(3846002)(110136002)(106116001)(2950100001)(2900100001)(189998001)(19627405001)(76576001)(7110500001)(345774005)(15650500001)(15975445007)(2906002)(8936002)(230783001)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:KL1PR04MB1606; H:KL1PR0401MB1544.apcprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_KL1PR0401MB1544349FCF40E95494CC1D4EA3730KL1PR0401MB1544_" MIME-Version: 1.0 X-OriginatorOrg: nivettisystems.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2016 04:48:59.7394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b780cc-c0fe-4e87-8da2-4702ecb31b90 X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1PR04MB1606 Archived-At: Cc: "ospf@ietf.org" , Manjul Khandelwal Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 04:49:08 -0000 --_000_KL1PR0401MB1544349FCF40E95494CC1D4EA3730KL1PR0401MB1544_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Manav, Thank you for your comments. Gabi has published multiple attacks against OSPF. The attack we are targeting is published in @inproceedings{nakibly2012persistent, title=3D{Persistent OSPF Attacks.}, author=3D{Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and Boneh, D= an}, booktitle=3D{NDSS}, year=3D{2012} } This attack indeed depends on predictability of sequence numbers. On a side note, we even verified that fact with Gabi Nakibly himself over a private mail. The attack you are discussing in your article is a different attack. It was described by Gabi in great detail in a different paper: @inproceedings{nakibly2014ospf, title=3D{OSPF vulnerability to persistent poisoning attacks: a systematic= analysis}, author=3D{Nakibly, Gabi and Sosnovich, Adi and Menahem, Eitan and Waizel,= Ariel and Elovici, Yuval}, booktitle=3D{Proceedings of the 30th Annual Computer Security Application= s Conference}, pages=3D{336--345}, year=3D{2014}, organization=3D{ACM} } As you rightly mentioned, this attack does not depend upon sequence number predictability. But our draft is *not* targeting *this* attack. Thanks and regards, Ramakrishna DTV. ________________________________ From: Manav Bhatia Sent: Thursday, May 12, 2016 9:16 AM To: Ramakrishna DTV Cc: Acee Lindem (acee); Manjul Khandelwal; ospf@ietf.org Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-s= equence-number-00.txt Hi DTV, I dont agree to your assessment of how the attack evades the "natural fight= -back mechanism" in OSPF. Its got *nothing* to do with the sequence numbers being predictable, etc. I= have explained in depth how the Gaby attack works here: https://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerabi= lity-exposed-by-black-hat/ How bad is the OSPF vulnerability exposed by Black Hat ... routingfreak.wordpress.com I was asked a few weeks ago by our field engineers to provide a fix for the= OSPF vulnerability exposed by Black Hat last month. Prima facie there appe= ared ... Clipped from the blog: "This attack exploits a potential omission (or a bug if you will) in the st= andard where it does not mandate that the receiving router verifies that th= e Link State ID and the Advertising Router fields in the Router LSA are the= exact same value. This attack sends malacious Router LSAs with two different values in the LS= header. The Link State ID carries the Router ID of the router that is bein= g attacked (the victim) and the Advertising Router is set to some different= (any) value. When the victim receives the malacious Router LSA, it does not refresh this= LSA as it doesnt recognize this as its own self generated LSA. This is bec= ause the OSPF spec clearly says in Sec 13.4 that =93A self-originated LSA i= s detected when either 1) The LSA=92s Advertising Router is equal to the ro= uter=92s own Router ID or 2) the LSA is a network LSA .. =93. This means that OSPF=92s natural fight back mechanism is NOT triggered by t= he victim router as long as the field =91Advertising Router=92 of a LSA is = NOT equal to the victim=92s Router ID. This is true even if the =91Link Sta= te ID=92 of that LSA is equal to the victim=92s Router ID. Going further it= means no LSA refresh is triggered even if the malacious LSA claims to desc= ribe the links of the victim router!" I describe further in the blog that not all router implementations are susc= eptible to the attack. Its dependent on how the LSA is picked up from the L= SDB. Cheers, Manav On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV > wrote: Hi Acee, We currently provided the following description of this attack in the draft= : "The paper refers to the attack as "Disguised LSA" and is of persistent nature. This attack is launched from a compromised router inside a routing domain. In this attack, the compromised router alters the LSA of an uncompromised router (victim). Normally, such an attempt does not have persistence because the victim generates a new LSA when it sees such self-originated LSAs (referred to as "fight-back" mechanism in the paper). But the paper makes disguised LSA persistent because all the fields { LS sequence number, checksum} are predictable. It alters the existing LSA of victim to suit its needs but sets the sequence number to +1 of the existing LSA and alters the LSA so that checksum matches with checksum that would be generated by the victim when it generates the new LSA. When this disguised LSA reaches the victim, it does not fight back because it compares only the fields { LS sequence number, checksum, age} to check for duplicates and not the actual content of LSA. This attack enables an insider attacker to fully control the entire content of an LSA. We think this attack is powerful." These details are currently present in Section 4, which is titled "Implemen= tation advice". We can probably move it to a different section (e.g., "Introduction") to ma= ke it clear. If you think even more additional details about the attack are useful to th= e working group, please let us know. We will add. Thank you. Regards, Ramakrishna DTV. ________________________________________ From: Acee Lindem (acee) > Sent: Wednesday, May 11, 2016 8:49 PM To: Manjul Khandelwal; ospf@ietf.org Cc: Ramakrishna DTV Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-s= equence-number-00.txt Hi Manjul, Would it be possible to succinctly describe these =93certain security attacks=94 in the draft rather than expecting everyone to read the referenced paper? Thanks, Acee On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal" on behalf of manjul@ni= vettisystems.com> wrote: >Hi, > >We have recently submitted a draft which deals with OSPF LS sequence >number >generation mechanism. > >Abstract of the draft: > The mechanism for LS sequence number generation as specified in RFC > 2328 and RFC 5340 is completely predictable. This makes it prone to > certain security attacks which exploit the predictable nature of LS > sequence numbers. This draft updates the RFC 2328 to make LS > sequence number generation an implementation choice rather than a > fixed increment by 1 for successive LSAs. > >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ > >We solicit feedback/comments on the draft and request for adoption by the >OSPF working group. > >Regards, >Manjul Khandelwal >DTV Ramakrishna Rao >________________________________________ >From: internet-drafts@ietf.org > >Sent: Monday, May 9, 2016 7:22 PM >To: Manjul Khandelwal; Ramakrishna DTV >Subject: New Version Notification for >draft-manjuldtv-ospf-sequence-number-00.txt > >A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt >has been successfully submitted by Manjul Khandelwal and posted to the >IETF repository. > >Name: draft-manjuldtv-ospf-sequence-number >Revision: 00 >Title: OSPF LSA sequence number generation >Document date: 2016-05-09 >Group: Individual Submission >Pages: 10 >URL: >https://www.ietf.org/internet-drafts/draft-manjuldtv-ospf-sequence-number- >00.txt >Status: >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ >Htmlized: >https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00 > > >Abstract: > The mechanism for LS sequence number generation as specified in RFC > 2328 and RFC 5340 is completely predictable. This makes it prone to > certain security attacks which exploit the predictable nature of LS > sequence numbers. This draft updates the RFC 2328 to make LS > sequence number generation an implementation choice rather than a > fixed increment by 1 for successive LSAs. > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >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 --_000_KL1PR0401MB1544349FCF40E95494CC1D4EA3730KL1PR0401MB1544_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Manav,

Thank you for your comments.

Gabi has published multiple attacks against OSPF.

The attack we are targeting is published in

@inproceedings{nakibly2012persistent,
  title=3D{Persistent OSPF Attacks.},
  author=3D{Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and Bon= eh, Dan},
  booktitle=3D{NDSS},
  year=3D{2012}
}

This attack indeed depends on predictability of sequence numbers.
On a side note, we even verified that fact with Gabi Nakibly himself
over a private mail.

The attack you are discussing in your article is a different attack.
It was described by Gabi in great detail in a different paper:

@inproceedings{nakibly2014ospf,
  title=3D{OSPF vulnerability to persistent poisoning attacks: a syste= matic analysis},
  author=3D{Nakibly, Gabi and Sosnovich, Adi and Menahem, Eitan and Wa= izel, Ariel and Elovici, Yuval},
  booktitle=3D{Proceedings of the 30th Annual Computer Security Applic= ations Conference},
  pages=3D{336--345},
  year=3D{2014},
  organization=3D{ACM}
}

As you rightly mentioned, this attack does not depend upon sequence number<= br> predictability. But our draft is *not* targeting *this* attack.

Thanks and regards,
Ramakrishna DTV.



From: Manav Bhatia <man= avbhatia@gmail.com>
Sent: Thursday, May 12, 2016 9:16 AM
To: Ramakrishna DTV
Cc: Acee Lindem (acee); Manjul Khandelwal; ospf@ietf.org
Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv= -ospf-sequence-number-00.txt
 
Hi DTV,

I dont agree to your assessment of how the attack evades the "nat= ural fight-back mechanism" in OSPF. 

Its got *nothing* to do with the sequence numbers being predictable, e= tc. I have explained in depth how the Gaby attack works here:

https://rout= ingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerability-exposed= -by-black-hat/
routingfreak.wordpress.com
I was asked a few weeks ago by our field engineers to provide a fix for the= OSPF vulnerability exposed by Black Hat last month. Prima facie there appe= ared ...


Clipped from the blog:

"This attack exploits a potential omission (or a bug if you will) in t= he standard where it does not mandate that the receiving router verifies th= at the Link State ID and the Advertising Router fields in the Router LSA ar= e the exact same value.

This attack sends malacious Router LSAs with two different values in the LS= header. The Link State ID carries the Router ID of the router that is bein= g attacked (the victim) and the Advertising Router is set to some different= (any) value.

When the victim receives the malacious Router LSA, it does not refresh this= LSA as it doesnt recognize this as its own self generated LSA. This i= s because the OSPF spec clearly says in Sec 13.4 that =93A self-originated = LSA is detected when either 1) The LSA=92s Advertising Router is equal to the router=92s own Router ID or 2) the LSA = is a network LSA .. =93.

This means that OSPF=92s natural fight back mechanism is NOT triggered by t= he victim router as long as the field =91Advertising Router=92 of a LSA is = NOT equal to the victim=92s Router ID. This is true even if the =91Link Sta= te ID=92 of that LSA is equal to the victim=92s Router ID. Going further it means no LSA refresh is triggered even if the = malacious LSA claims to describe the links of the victim router!"

I describe further in the blog that not all router implementations are= susceptible to the attack. Its dependent on how the LSA is picked up from = the LSDB. 

Cheers, Manav

On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV= <= ramakrishnadtv@nivettisystems.com> wrote:
Hi Acee,

We currently provided the following description of this attack in the draft= :

 "The paper refers to the attack as "Disguised LSA" and= is of
   persistent nature.  This attack is launched from a compro= mised router
   inside a routing domain.  In this attack, the compromised= router
   alters the LSA of an uncompromised router (victim).  Norm= ally, such
   an attempt does not have persistence because the victim genera= tes a
   new LSA when it sees such self-originated LSAs (referred to as=
   "fight-back" mechanism in the paper).  But the = paper makes disguised
   LSA persistent because all the fields { LS sequence number, ch= ecksum}
   are predictable.  It alters the existing LSA of victim to= suit its
   needs but sets the sequence number to +1 of the existing L= SA and
   alters the LSA so that checksum matches with checksum that wou= ld be
   generated by the victim when it generates the new LSA.  W= hen this
   disguised LSA reaches the victim, it does not fight back becau= se it
   compares only the fields { LS sequence number, checksum, age} = to
   check for duplicates and not the actual content of LSA.

   This attack enables an insider attacker to fully control the e= ntire
   content of an LSA.  We think this attack is powerful.&quo= t;

These details are currently present in Section 4, which is titled "Imp= lementation advice".
We can probably move it to a different section (e.g., "Introduction&qu= ot;) to make it clear.

If you think even more additional details about the attack are useful to th= e working group,
please let us know. We will add.

Thank you.

Regards,
Ramakrishna DTV.


________________________________________
From: Acee Lindem (acee) <acee@cisco.c= om>
Sent: Wednesday, May 11, 2016 8:49 PM
To: Manjul Khandelwal; ospf@ietf.org Cc: Ramakrishna DTV
Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-s= equence-number-00.txt

Hi Manjul,

Would it be possible to succinctly describe these =93certain security
attacks=94 in the draft rather than expecting everyone to read the
referenced paper?

Thanks,
Acee

On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal"
<ospf-bounces@ietf.org on b= ehalf of manjul@nivettisystems.com> wrote:

>Hi,
>
>We have recently submitted a draft which deals with OSPF LS sequence >number
>generation mechanism.
>
>Abstract of the draft:
>   The mechanism for LS sequence number generation as specifi= ed in RFC
>   2328 and RFC 5340 is completely predictable.  This ma= kes it prone to
>   certain security attacks which exploit the predictable nat= ure of LS
>   sequence numbers.  This draft updates the RFC 2328 to= make LS
>   sequence number generation an implementation choice rather= than a
>   fixed increment by 1 for successive LSAs.
>
>https://datatracker.ietf.o= rg/doc/draft-manjuldtv-ospf-sequence-number/
>
>We solicit feedback/comments on the draft and request for adoption by t= he
>OSPF working group.
>
>Regards,
>Manjul Khandelwal
>DTV Ramakrishna Rao
>________________________________________
>From: internet-drafts@ietf.= org <internet-drafts@iet= f.org>
>Sent: Monday, May 9, 2016 7:22 PM
>To: Manjul Khandelwal; Ramakrishna DTV
>Subject: New Version Notification for
>draft-manjuldtv-ospf-sequence-number-00.txt
>
>A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt
>has been successfully submitted by Manjul Khandelwal and posted to the<= br> >IETF repository.
>
>Name:           draft-manjuldtv-ospf-sequ= ence-number
>Revision:       00
>Title:          OSPF LSA sequence number gener= ation
>Document date:  2016-05-09
>Group:          Individual Submission
>Pages:          10
>URL:
>https://www.ietf.org/i= nternet-drafts/draft-manjuldtv-ospf-sequence-number-
>00.txt
>Status:
>https://datatracker.ietf.o= rg/doc/draft-manjuldtv-ospf-sequence-number/
>Htmlized:
>https://tools.ietf.org/html/d= raft-manjuldtv-ospf-sequence-number-00
>
>
>Abstract:
>   The mechanism for LS sequence number generation as specifi= ed in RFC
>   2328 and RFC 5340 is completely predictable.  This ma= kes it prone to
>   certain security attacks which exploit the predictable nat= ure of LS
>   sequence numbers.  This draft updates the RFC 2328 to= make LS
>   sequence number generation an implementation choice rather= than a
>   fixed increment by 1 for successive LSAs.
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>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

--_000_KL1PR0401MB1544349FCF40E95494CC1D4EA3730KL1PR0401MB1544_-- From nobody Wed May 11 22:11:31 2016 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 A58A912D149 for ; Wed, 11 May 2016 22:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muuDF4TL2WVk for ; Wed, 11 May 2016 22:11:26 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6DD12B031 for ; Wed, 11 May 2016 22:11:26 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id j74so63255384ywg.1 for ; Wed, 11 May 2016 22:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=MQdY/vE/HE0Eh4wDbScCNL5bnKU4Kyx+mXDvFtQoYGg=; b=l1VatKVwuQ1RQEQgjgJfToNDxAifUIV3/Ocrvnwn01BQJpr3V66VC1BXW1FOGFsnPX ylgsSCX1N8luCnMpHNGsxIzUkVAFSUo56JWWESz0hElSkLHIg7pHhZLAKTdRoEv7LvSa RHOpxyvl4RGgBZZiCL/LfHJqjCZ/jWfA91rF+ARVUMcshHYxq8X390lafnxs1rMWo099 X/maM4g5nxV2Eb4qX9tOnTKqKMezpOAfEZzHQZeg/snslYrX8Lz3MJkXmPOKmCoRjz4Q N2aaS1tz9lG8WElr2uU42ITFQwIatnSmok5LDW3d0RkJJuvrKp4LbkVOuT2/E6JXVqjg Bq4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MQdY/vE/HE0Eh4wDbScCNL5bnKU4Kyx+mXDvFtQoYGg=; b=EJFBROCa/QymQz3xtwh+bO1oXsVOEJBH8xP5tjn6QDUf87d5TaGAI9sr6HB/+e2Lkl KkkKxl7KgpXr+exnnP/qdpjJeWsYlnJgeaPASbJOtIywzAZTqR4G8WuJiGlxWTQbVXPM 1tS2vcqW9JRlf4DCevnVVf26TgKBoQjftnopYsgzBq+u+b9gDLqAWQ9XNpVEMOT4k4gz 3S3kl0Eu98LYMee7XS/wUlhcOU4YQXkacCOliChK9FdotCmGDFLeqcrYDiDFUrN5l2rD opEVx6rFMua5twxlX6BBeHFD21mLS/EKi65YQPAfGK+IgcSWCNgJ6aGK52XJFlJimqkq 0xww== X-Gm-Message-State: AOPr4FXkqjx0+UITupTzyasW35MKQ9otiLjVvs1YtYirVU7eGpoU881HiU0tUazfgD4AB3LO39nGzSZ5wgQODA== MIME-Version: 1.0 X-Received: by 10.129.111.196 with SMTP id k187mr3590894ywc.11.1463029885276; Wed, 11 May 2016 22:11:25 -0700 (PDT) Received: by 10.13.216.129 with HTTP; Wed, 11 May 2016 22:11:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2016 10:41:25 +0530 Message-ID: From: Manav Bhatia To: Ramakrishna DTV Content-Type: multipart/alternative; boundary=001a1141ab889b9a0005329e301e Archived-At: Cc: "ospf@ietf.org" , Manjul Khandelwal Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 05:11:29 -0000 --001a1141ab889b9a0005329e301e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi DTV, Aha. Thanks for the catch ! In that case, i dont understand why the "victim" will NOT generate a new LSA with LS sequence number one past the received LS sequence number. I see that the new attack tries to do something by updating the sequence number and the checksum -- did not spend too much time on trying to understand what exactly its doing there. However, OSPF also has provisions to get around that, and i wrote about this many years ago here: https://routingfreak.wordpress.com/2010/07/02/using-checksum-in-determining= -the-newer-lsa/ So i have the same question as Acee -- why will the natural fight-back mechanism not work here? Cheers, Manav On Thu, May 12, 2016 at 10:18 AM, Ramakrishna DTV < ramakrishnadtv@nivettisystems.com> wrote: > Hi Manav, > > Thank you for your comments. > > Gabi has published multiple attacks against OSPF. > > The attack we are targeting is published in > > @inproceedings{nakibly2012persistent, > title=3D{Persistent OSPF Attacks.}, > author=3D{Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and Boneh, > Dan}, > booktitle=3D{NDSS}, > year=3D{2012} > } > > This attack indeed depends on predictability of sequence numbers. > On a side note, we even verified that fact with Gabi Nakibly himself > over a private mail. > > The attack you are discussing in your article is a different attack. > It was described by Gabi in great detail in a different paper: > > @inproceedings{nakibly2014ospf, > title=3D{OSPF vulnerability to persistent poisoning attacks: a systemat= ic > analysis}, > author=3D{Nakibly, Gabi and Sosnovich, Adi and Menahem, Eitan and Waize= l, > Ariel and Elovici, Yuval}, > booktitle=3D{Proceedings of the 30th Annual Computer Security Applicati= ons > Conference}, > pages=3D{336--345}, > year=3D{2014}, > organization=3D{ACM} > } > > As you rightly mentioned, this attack does not depend upon sequence numbe= r > predictability. But our draft is *not* targeting *this* attack. > > Thanks and regards, > Ramakrishna DTV. > > > > ------------------------------ > *From:* Manav Bhatia > *Sent:* Thursday, May 12, 2016 9:16 AM > *To:* Ramakrishna DTV > *Cc:* Acee Lindem (acee); Manjul Khandelwal; ospf@ietf.org > *Subject:* Re: [OSPF] Fw: New Version Notification for > draft-manjuldtv-ospf-sequence-number-00.txt > > Hi DTV, > > I dont agree to your assessment of how the attack evades the "natural > fight-back mechanism" in OSPF. > > Its got *nothing* to do with the sequence numbers being predictable, etc. > I have explained in depth how the Gaby attack works here: > > > https://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnera= bility-exposed-by-black-hat/ > How bad is the OSPF vulnerability exposed by Black Hat ... > > routingfreak.wordpress.com > I was asked a few weeks ago by our field engineers to provide a fix for > the OSPF vulnerability exposed by Black Hat last month. Prima facie there > appeared ... > > > Clipped from the blog: > > "This attack exploits a potential omission (or a bug if you will) in the > standard where it does not mandate that the receiving router verifies tha= t > the Link State ID and the Advertising Router fields in the Router LSA are > the exact same value. > > This attack sends malacious Router LSAs with two different values in the > LS header. The Link State ID carries the Router ID of the router that is > being attacked (the victim) and the Advertising Router is set to some > different (any) value. > > When the victim receives the malacious Router LSA, it does not refresh > this LSA as it doesnt recognize this as its own self generated LSA. This = is > because the OSPF spec clearly says in Sec 13.4 that =E2=80=9CA self-origi= nated LSA > is detected when either 1) The LSA=E2=80=99s Advertising Router is equal = to the > router=E2=80=99s own Router ID or 2) the LSA is a network LSA .. =E2=80= =9C. > > This means that OSPF=E2=80=99s natural fight back mechanism is NOT trigge= red by > the victim router as long as the field =E2=80=98Advertising Router=E2=80= =99 of a LSA is NOT > equal to the victim=E2=80=99s Router ID. This is true even if the =E2=80= =98Link State ID=E2=80=99 > of that LSA is equal to the victim=E2=80=99s Router ID. Going further it = means no > LSA refresh is triggered even if the malacious LSA claims to describe the > links of the victim router!" > > I describe further in the blog that not all router implementations are > susceptible to the attack. Its dependent on how the LSA is picked up from > the LSDB. > > Cheers, Manav > > On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV < > ramakrishnadtv@nivettisystems.com> wrote: > >> Hi Acee, >> >> We currently provided the following description of this attack in the >> draft: >> >> "The paper refers to the attack as "Disguised LSA" and is of >> persistent nature. This attack is launched from a compromised router >> inside a routing domain. In this attack, the compromised router >> alters the LSA of an uncompromised router (victim). Normally, such >> an attempt does not have persistence because the victim generates a >> new LSA when it sees such self-originated LSAs (referred to as >> "fight-back" mechanism in the paper). But the paper makes disguised >> LSA persistent because all the fields { LS sequence number, checksum} >> are predictable. It alters the existing LSA of victim to suit its >> needs but sets the sequence number to +1 of the existing LSA and >> alters the LSA so that checksum matches with checksum that would be >> generated by the victim when it generates the new LSA. When this >> disguised LSA reaches the victim, it does not fight back because it >> compares only the fields { LS sequence number, checksum, age} to >> check for duplicates and not the actual content of LSA. >> >> This attack enables an insider attacker to fully control the entire >> content of an LSA. We think this attack is powerful." >> >> These details are currently present in Section 4, which is titled >> "Implementation advice". >> We can probably move it to a different section (e.g., "Introduction") to >> make it clear. >> >> If you think even more additional details about the attack are useful to >> the working group, >> please let us know. We will add. >> >> Thank you. >> >> Regards, >> Ramakrishna DTV. >> >> >> ________________________________________ >> From: Acee Lindem (acee) >> Sent: Wednesday, May 11, 2016 8:49 PM >> To: Manjul Khandelwal; ospf@ietf.org >> Cc: Ramakrishna DTV >> Subject: Re: [OSPF] Fw: New Version Notification for >> draft-manjuldtv-ospf-sequence-number-00.txt >> >> Hi Manjul, >> >> Would it be possible to succinctly describe these =E2=80=9Ccertain secur= ity >> attacks=E2=80=9D in the draft rather than expecting everyone to read the >> referenced paper? >> >> Thanks, >> Acee >> >> On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal" >> wrote: >> >> >Hi, >> > >> >We have recently submitted a draft which deals with OSPF LS sequence >> >number >> >generation mechanism. >> > >> >Abstract of the draft: >> > The mechanism for LS sequence number generation as specified in RFC >> > 2328 and RFC 5340 is completely predictable. This makes it prone to >> > certain security attacks which exploit the predictable nature of LS >> > sequence numbers. This draft updates the RFC 2328 to make LS >> > sequence number generation an implementation choice rather than a >> > fixed increment by 1 for successive LSAs. >> > >> >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ >> > >> >We solicit feedback/comments on the draft and request for adoption by t= he >> >OSPF working group. >> > >> >Regards, >> >Manjul Khandelwal >> >DTV Ramakrishna Rao >> >________________________________________ >> >From: internet-drafts@ietf.org >> >Sent: Monday, May 9, 2016 7:22 PM >> >To: Manjul Khandelwal; Ramakrishna DTV >> >Subject: New Version Notification for >> >draft-manjuldtv-ospf-sequence-number-00.txt >> > >> >A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt >> >has been successfully submitted by Manjul Khandelwal and posted to the >> >IETF repository. >> > >> >Name: draft-manjuldtv-ospf-sequence-number >> >Revision: 00 >> >Title: OSPF LSA sequence number generation >> >Document date: 2016-05-09 >> >Group: Individual Submission >> >Pages: 10 >> >URL: >> > >> https://www.ietf.org/internet-drafts/draft-manjuldtv-ospf-sequence-numbe= r- >> >00.txt >> >Status: >> >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ >> >Htmlized: >> >https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00 >> > >> > >> >Abstract: >> > The mechanism for LS sequence number generation as specified in RFC >> > 2328 and RFC 5340 is completely predictable. This makes it prone to >> > certain security attacks which exploit the predictable nature of LS >> > sequence numbers. This draft updates the RFC 2328 to make LS >> > sequence number generation an implementation choice rather than a >> > fixed increment by 1 for successive LSAs. >> > >> > >> > >> > >> >Please note that it may take a couple of minutes from the time of >> >submission >> >until the htmlized version and diff are available at tools.ietf.org. >> > >> >The IETF Secretariat >> > >> >_______________________________________________ >> >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 >> > > --001a1141ab889b9a0005329e301e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi DTV,

Aha. Thanks for the catch !=C2= =A0

In that case, i dont understand why the "= victim" will NOT generate a new LSA with LS sequence number one past t= he received LS sequence number. I see that the new attack tries to do somet= hing by updating the sequence number and the checksum -- did not spend too = much time on trying to understand what exactly its doing there. However, OS= PF also has provisions to get around that, and i wrote about this many year= s ago here:


So i have the same question as Acee = -- why will the natural fight-back mechanism not work here?

<= /div>
Cheers, Manav

On Thu, May 12, 2016 at 10:18 AM, Ramakrishna DTV <ramakrishnadtv@nivettisystems.com> wrote:

Hi Manav,

Thank you for your comments.

Gabi has published multiple attacks against OSPF.

The attack we are targeting is published in

@inproceedings{nakibly2012persistent,
=C2=A0 title=3D{Persistent OSPF Attacks.},
=C2=A0 author=3D{Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and Bon= eh, Dan},
=C2=A0 booktitle=3D{NDSS},
=C2=A0 year=3D{2012}
}

This attack indeed depends on predictability of sequence numbers.
On a side note, we even verified that fact with Gabi Nakibly himself
over a private mail.

The attack you are discussing in your article is a different attack.
It was described by Gabi in great detail in a different paper:

@inproceedings{nakibly2014ospf,
=C2=A0 title=3D{OSPF vulnerability to persistent poisoning attacks: a syste= matic analysis},
=C2=A0 author=3D{Nakibly, Gabi and Sosnovich, Adi and Menahem, Eitan and Wa= izel, Ariel and Elovici, Yuval},
=C2=A0 booktitle=3D{Proceedings of the 30th Annual Computer Security Applic= ations Conference},
=C2=A0 pages=3D{336--345},
=C2=A0 year=3D{2014},
=C2=A0 organization=3D{ACM}
}

As you rightly mentioned, this attack does not depend upon sequence number<= br> predictability. But our draft is *not* targeting *this* attack.

Thanks and regards,
Ramakrishna DTV.



From: Manav Bhatia <manavbhatia@gmail.com>
Sent: Thursday, May 12, 2016 9:16 AM
To: Ramakrishna DTV
Cc: Acee Lindem (acee); Manjul Khandelwal; ospf@ietf.org
Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv= -ospf-sequence-number-00.txt
=C2=A0
Hi DTV,

I dont agree to your assessment of how the attack evades the "nat= ural fight-back mechanism" in OSPF.=C2=A0

Its got *nothing* to do with the sequence numbers being predictable, e= tc. I have explained in depth how the Gaby attack works here:

https:= //routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerability-e= xposed-by-black-hat/
I was asked a few weeks ago by our field engineers to provide a fix for the= OSPF vulnerability exposed by Black Hat last month. Prima facie there appe= ared ...


Clipped from the blog:

"This attack exploits a potential omission (or a bug if you will) in t= he standard where it does not mandate that the receiving router verifies th= at the Link State ID and the Advertising Router fields in the Router LSA ar= e the exact same value.

This attack sends malacious Router LSAs with two different values in the LS= header. The Link State ID carries the Router ID of the router that is bein= g attacked (the victim) and the Advertising Router is set to some different= (any) value.

When the victim receives the malacious Router LSA, it does not refresh this= LSA as it doesnt recognize this as its own=C2=A0self generated LSA. This i= s because the OSPF spec clearly says in Sec 13.4 that =E2=80=9CA self-origi= nated LSA is detected when either 1) The LSA=E2=80=99s Advertising Router is equal to the router=E2=80=99s own Router ID or 2) th= e LSA is a network LSA .. =E2=80=9C.

This means that OSPF=E2=80=99s natural fight back mechanism is NOT triggere= d by the victim router as long as the field =E2=80=98Advertising Router=E2= =80=99 of a LSA is NOT equal to the victim=E2=80=99s Router ID. This is tru= e even if the =E2=80=98Link State ID=E2=80=99 of that LSA is equal to the v= ictim=E2=80=99s Router ID. Going further it means no LSA refresh is triggered even if the = malacious LSA claims to describe the links of the victim router!"

I describe further in the blog that not all router implementations are= susceptible to the attack. Its dependent on how the LSA is picked up from = the LSDB.=C2=A0

Cheers, Manav

On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV= <= ramakrishnadtv@nivettisystems.com> wrote:
Hi Acee,

We currently provided the following description of this attack in the draft= :

=C2=A0"The paper refers to the attack as "Disguised LSA" and= is of
=C2=A0 =C2=A0persistent nature.=C2=A0 This attack is launched from a compro= mised router
=C2=A0 =C2=A0inside a routing domain.=C2=A0 In this attack, the compromised= router
=C2=A0 =C2=A0alters the LSA of an uncompromised router (victim).=C2=A0 Norm= ally, such
=C2=A0 =C2=A0an attempt does not have persistence because the victim genera= tes a
=C2=A0 =C2=A0new LSA when it sees such self-originated LSAs (referred to as=
=C2=A0 =C2=A0"fight-back" mechanism in the paper).=C2=A0 But the = paper makes disguised
=C2=A0 =C2=A0LSA persistent because all the fields { LS sequence number, ch= ecksum}
=C2=A0 =C2=A0are predictable.=C2=A0 It alters the existing LSA of victim to= suit its
=C2=A0 =C2=A0needs but sets the sequence number to +1 of the existing LSA a= nd
=C2=A0 =C2=A0alters the LSA so that checksum matches with checksum that wou= ld be
=C2=A0 =C2=A0generated by the victim when it generates the new LSA.=C2=A0 W= hen this
=C2=A0 =C2=A0disguised LSA reaches the victim, it does not fight back becau= se it
=C2=A0 =C2=A0compares only the fields { LS sequence number, checksum, age} = to
=C2=A0 =C2=A0check for duplicates and not the actual content of LSA.

=C2=A0 =C2=A0This attack enables an insider attacker to fully control the e= ntire
=C2=A0 =C2=A0content of an LSA.=C2=A0 We think this attack is powerful.&quo= t;

These details are currently present in Section 4, which is titled "Imp= lementation advice".
We can probably move it to a different section (e.g., "Introduction&qu= ot;) to make it clear.

If you think even more additional details about the attack are useful to th= e working group,
please let us know. We will add.

Thank you.

Regards,
Ramakrishna DTV.


________________________________________
From: Acee Lindem (acee) <acee@cisco.com>
Sent: Wednesday, May 11, 2016 8:49 PM
To: Manjul Khandelwal; o= spf@ietf.org
Cc: Ramakrishna DTV
Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-s= equence-number-00.txt

Hi Manjul,

Would it be possible to succinctly describe these =E2=80=9Ccertain security=
attacks=E2=80=9D in the draft rather than expecting everyone to read the referenced paper?

Thanks,
Acee

On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal"
<ospf-bounces= @ietf.org on behalf of manjul@nivettisystems.com> wrote:

>Hi,
>
>We have recently submitted a draft which deals with OSPF LS sequence >number
>generation mechanism.
>
>Abstract of the draft:
>=C2=A0 =C2=A0The mechanism for LS sequence number generation as specifi= ed in RFC
>=C2=A0 =C2=A02328 and RFC 5340 is completely predictable.=C2=A0 This ma= kes it prone to
>=C2=A0 =C2=A0certain security attacks which exploit the predictable nat= ure of LS
>=C2=A0 =C2=A0sequence numbers.=C2=A0 This draft updates the RFC 2328 to= make LS
>=C2=A0 =C2=A0sequence number generation an implementation choice rather= than a
>=C2=A0 =C2=A0fixed increment by 1 for successive LSAs.
>
>https://datatracker.ietf.o= rg/doc/draft-manjuldtv-ospf-sequence-number/
>
>We solicit feedback/comments on the draft and request for adoption by t= he
>OSPF working group.
>
>Regards,
>Manjul Khandelwal
>DTV Ramakrishna Rao
>________________________________________
>From: int= ernet-drafts@ietf.org <internet-drafts@ietf.org>
>Sent: Monday, May 9, 2016 7:22 PM
>To: Manjul Khandelwal; Ramakrishna DTV
>Subject: New Version Notification for
>draft-manjuldtv-ospf-sequence-number-00.txt
>
>A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt
>has been successfully submitted by Manjul Khandelwal and posted to the<= br> >IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-manjuldtv-ospf-sequ= ence-number
>Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OSPF LSA sequence number gener= ation
>Document date:=C2=A0 2016-05-09
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
>URL:
>https://www.ietf.org/i= nternet-drafts/draft-manjuldtv-ospf-sequence-number-
>00.txt
>Status:
>https://datatracker.ietf.o= rg/doc/draft-manjuldtv-ospf-sequence-number/
>Htmlized:
>https://tools.ietf.org/html/d= raft-manjuldtv-ospf-sequence-number-00
>
>
>Abstract:
>=C2=A0 =C2=A0The mechanism for LS sequence number generation as specifi= ed in RFC
>=C2=A0 =C2=A02328 and RFC 5340 is completely predictable.=C2=A0 This ma= kes it prone to
>=C2=A0 =C2=A0certain security attacks which exploit the predictable nat= ure of LS
>=C2=A0 =C2=A0sequence numbers.=C2=A0 This draft updates the RFC 2328 to= make LS
>=C2=A0 =C2=A0sequence number generation an implementation choice rather= than a
>=C2=A0 =C2=A0fixed increment by 1 for successive LSAs.
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>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


--001a1141ab889b9a0005329e301e-- From nobody Thu May 12 04:03:27 2016 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 CB28512D8E7 for ; Thu, 12 May 2016 04:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXmMYFLrAPZw for ; Thu, 12 May 2016 04:03:22 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F294A12D8D4 for ; Thu, 12 May 2016 04:03:21 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id o66so77942824ywc.3 for ; Thu, 12 May 2016 04:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tDEL2DjwfEhjA7HqISEgQ5flg1S+JOMFM1CC/RBUYZ4=; b=rcsmgfmDWvx7laZ1iJWAkuNqhWlQdEV7JDeSq9sZOXjcwInzeIT1Lt1/7tKnslVnXC fPC+NZLoettqlR60pJND7Ue+uyE2hRfXHAv8bu6oZhRLV8IOtxl8h5flegpzw5EvsPWW nabd2qtFrISAEcCpuJ7y4hlK7ehLvClOJnECTgRh54NSzkCQWdaCNNjJRnMWl7zTpqn6 BNyLw8N8N2kSDebmKwp3MU6VCF4EV4RgUZ4LAdYexlR2yVL6Y38Uttn2hB86AP8Qs7tU NzNJHfsx6UzQ8sTVhS8sXBg4RPP29D958RAdqbewss6fVTF3m3xwBL8uWEve+yuDcUwm VL0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tDEL2DjwfEhjA7HqISEgQ5flg1S+JOMFM1CC/RBUYZ4=; b=lJwZRU1IA2o51YInxn1zTXxFW2oq0QXMX1U8HZhpcprs3ECetBH7XNZi2WE1WXtX6D 7johH9FIjIM9NB7ENlth7S038+LhldQc5fWIRtBaNH+r1scQuSiazdDwv0gSOhQC7VX7 cv9wUi3kS84tVaQMfERPKrT4TAdnUFSCPlXr9m7tLV1tUOLbo2Gt20yH2qg5lnAOU1HN 4JxNGB8xBPv/egmvJAZm3RNQ4U82fUf0tzZBZ5JjxLC7pRNyv1oNufxe7SiOXc/btO5b sTwpfLsT3/mGHdO8jieYOpZjnmlJIdu2MWFyW5vubdFylIgBWVPlF87rdQ2hODSKW1Ki EBcA== X-Gm-Message-State: AOPr4FV3qFBkwdNkuG9MCRWx961bPwt8IQqvCKZqyZt3frk2M953+HDW10yWqzeILByCfg== X-Received: by 10.13.237.130 with SMTP id w124mr4125367ywe.248.1463051000896; Thu, 12 May 2016 04:03:20 -0700 (PDT) Received: from [10.0.1.18] (cpe-65-190-56-15.nc.res.rr.com. [65.190.56.15]) by smtp.gmail.com with ESMTPSA id o75sm6923276ywd.7.2016.05.12.04.03.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2016 04:03:20 -0700 (PDT) From: Acee Lindem X-Google-Original-From: Acee Lindem Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) In-Reply-To: Date: Thu, 12 May 2016 07:03:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <89E7259B-72EE-4B60-BFC1-BA55BE761B9C@lindem.com> References: To: Manav Bhatia X-Mailer: Apple Mail (2.3124) Archived-At: Cc: OSPF List , Ramakrishna DTV , Manjul Khandelwal Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 11:03:25 -0000 Hi Manav,=20 > On May 12, 2016, at 1:11 AM, Manav Bhatia = wrote: >=20 > Hi DTV, >=20 > Aha. Thanks for the catch !=20 >=20 > In that case, i dont understand why the "victim" will NOT generate a = new LSA with LS sequence number one past the received LS sequence = number. I see that the new attack tries to do something by updating the = sequence number and the checksum -- did not spend too much time on = trying to understand what exactly its doing there. However, OSPF also = has provisions to get around that, and i wrote about this many years ago = here: >=20 > = https://routingfreak.wordpress.com/2010/07/02/using-checksum-in-determinin= g-the-newer-lsa/ >=20 > So i have the same question as Acee -- why will the natural fight-back = mechanism not work here? It will and that was my point. I can think of only one possible attack = where the same sequence number is used but the attacker can only change = the contents of the LSA for OSPF routers for which it is in the flooding = path from the originator.=20 Thanks, Acee >=20 > Cheers, Manav >=20 > On Thu, May 12, 2016 at 10:18 AM, Ramakrishna DTV = wrote: >=20 > Hi Manav, >=20 > Thank you for your comments. >=20 > Gabi has published multiple attacks against OSPF. >=20 > The attack we are targeting is published in >=20 > @inproceedings{nakibly2012persistent, > title=3D{Persistent OSPF Attacks.}, > author=3D{Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and = Boneh, Dan}, > booktitle=3D{NDSS}, > year=3D{2012} > } >=20 > This attack indeed depends on predictability of sequence numbers. > On a side note, we even verified that fact with Gabi Nakibly himself > over a private mail. >=20 > The attack you are discussing in your article is a different attack. > It was described by Gabi in great detail in a different paper: >=20 > @inproceedings{nakibly2014ospf, > title=3D{OSPF vulnerability to persistent poisoning attacks: a = systematic analysis}, > author=3D{Nakibly, Gabi and Sosnovich, Adi and Menahem, Eitan and = Waizel, Ariel and Elovici, Yuval}, > booktitle=3D{Proceedings of the 30th Annual Computer Security = Applications Conference}, > pages=3D{336--345}, > year=3D{2014}, > organization=3D{ACM} > } >=20 > As you rightly mentioned, this attack does not depend upon sequence = number > predictability. But our draft is *not* targeting *this* attack. >=20 > Thanks and regards, > Ramakrishna DTV. >=20 >=20 >=20 > From: Manav Bhatia > Sent: Thursday, May 12, 2016 9:16 AM > To: Ramakrishna DTV > Cc: Acee Lindem (acee); Manjul Khandelwal; ospf@ietf.org > Subject: Re: [OSPF] Fw: New Version Notification for = draft-manjuldtv-ospf-sequence-number-00.txt > =20 > Hi DTV, >=20 > I dont agree to your assessment of how the attack evades the "natural = fight-back mechanism" in OSPF.=20 >=20 > Its got *nothing* to do with the sequence numbers being predictable, = etc. I have explained in depth how the Gaby attack works here: >=20 > = https://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerab= ility-exposed-by-black-hat/ > How bad is the OSPF vulnerability exposed by Black Hat ... > routingfreak.wordpress.com > I was asked a few weeks ago by our field engineers to provide a fix = for the OSPF vulnerability exposed by Black Hat last month. Prima facie = there appeared ... >=20 >=20 > Clipped from the blog: >=20 > "This attack exploits a potential omission (or a bug if you will) in = the standard where it does not mandate that the receiving router = verifies that the Link State ID and the Advertising Router fields in the = Router LSA are the exact same value. >=20 > This attack sends malacious Router LSAs with two different values in = the LS header. The Link State ID carries the Router ID of the router = that is being attacked (the victim) and the Advertising Router is set to = some different (any) value. >=20 > When the victim receives the malacious Router LSA, it does not refresh = this LSA as it doesnt recognize this as its own self generated LSA. This = is because the OSPF spec clearly says in Sec 13.4 that =E2=80=9CA = self-originated LSA is detected when either 1) The LSA=E2=80=99s = Advertising Router is equal to the router=E2=80=99s own Router ID or 2) = the LSA is a network LSA .. =E2=80=9C. >=20 > This means that OSPF=E2=80=99s natural fight back mechanism is NOT = triggered by the victim router as long as the field =E2=80=98Advertising = Router=E2=80=99 of a LSA is NOT equal to the victim=E2=80=99s Router ID. = This is true even if the =E2=80=98Link State ID=E2=80=99 of that LSA is = equal to the victim=E2=80=99s Router ID. Going further it means no LSA = refresh is triggered even if the malacious LSA claims to describe the = links of the victim router!"=20 >=20 > I describe further in the blog that not all router implementations are = susceptible to the attack. Its dependent on how the LSA is picked up = from the LSDB.=20 >=20 > Cheers, Manav >=20 > On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV = wrote: > Hi Acee, >=20 > We currently provided the following description of this attack in the = draft: >=20 > "The paper refers to the attack as "Disguised LSA" and is of > persistent nature. This attack is launched from a compromised = router > inside a routing domain. In this attack, the compromised router > alters the LSA of an uncompromised router (victim). Normally, such > an attempt does not have persistence because the victim generates a > new LSA when it sees such self-originated LSAs (referred to as > "fight-back" mechanism in the paper). But the paper makes = disguised > LSA persistent because all the fields { LS sequence number, = checksum} > are predictable. It alters the existing LSA of victim to suit its > needs but sets the sequence number to +1 of the existing LSA and > alters the LSA so that checksum matches with checksum that would be > generated by the victim when it generates the new LSA. When this > disguised LSA reaches the victim, it does not fight back because it > compares only the fields { LS sequence number, checksum, age} to > check for duplicates and not the actual content of LSA. >=20 > This attack enables an insider attacker to fully control the entire > content of an LSA. We think this attack is powerful." >=20 > These details are currently present in Section 4, which is titled = "Implementation advice". > We can probably move it to a different section (e.g., "Introduction") = to make it clear. >=20 > If you think even more additional details about the attack are useful = to the working group, > please let us know. We will add. >=20 > Thank you. >=20 > Regards, > Ramakrishna DTV. >=20 >=20 > ________________________________________ > From: Acee Lindem (acee) > Sent: Wednesday, May 11, 2016 8:49 PM > To: Manjul Khandelwal; ospf@ietf.org > Cc: Ramakrishna DTV > Subject: Re: [OSPF] Fw: New Version Notification for = draft-manjuldtv-ospf-sequence-number-00.txt >=20 > Hi Manjul, >=20 > Would it be possible to succinctly describe these =E2=80=9Ccertain = security > attacks=E2=80=9D in the draft rather than expecting everyone to read = the > referenced paper? >=20 > Thanks, > Acee >=20 > On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal" > wrote: >=20 > >Hi, > > > >We have recently submitted a draft which deals with OSPF LS sequence > >number > >generation mechanism. > > > >Abstract of the draft: > > The mechanism for LS sequence number generation as specified in = RFC > > 2328 and RFC 5340 is completely predictable. This makes it prone = to > > certain security attacks which exploit the predictable nature of = LS > > sequence numbers. This draft updates the RFC 2328 to make LS > > sequence number generation an implementation choice rather than a > > fixed increment by 1 for successive LSAs. > > > = >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ > > > >We solicit feedback/comments on the draft and request for adoption by = the > >OSPF working group. > > > >Regards, > >Manjul Khandelwal > >DTV Ramakrishna Rao > >________________________________________ > >From: internet-drafts@ietf.org > >Sent: Monday, May 9, 2016 7:22 PM > >To: Manjul Khandelwal; Ramakrishna DTV > >Subject: New Version Notification for > >draft-manjuldtv-ospf-sequence-number-00.txt > > > >A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt > >has been successfully submitted by Manjul Khandelwal and posted to = the > >IETF repository. > > > >Name: draft-manjuldtv-ospf-sequence-number > >Revision: 00 > >Title: OSPF LSA sequence number generation > >Document date: 2016-05-09 > >Group: Individual Submission > >Pages: 10 > >URL: > = >https://www.ietf.org/internet-drafts/draft-manjuldtv-ospf-sequence-number= - > >00.txt > >Status: > = >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ > >Htmlized: > >https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00 > > > > > >Abstract: > > The mechanism for LS sequence number generation as specified in = RFC > > 2328 and RFC 5340 is completely predictable. This makes it prone = to > > certain security attacks which exploit the predictable nature of = LS > > sequence numbers. This draft updates the RFC 2328 to make LS > > sequence number generation an implementation choice rather than a > > fixed increment by 1 for successive LSAs. > > > > > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >The IETF Secretariat > > > >_______________________________________________ > >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 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Thu May 12 04:09:58 2016 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 39D5812D64C for ; Thu, 12 May 2016 04:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorg676131.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnleblhYg6gE for ; Thu, 12 May 2016 04:09:52 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0099.outbound.protection.outlook.com [104.47.125.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA6712D108 for ; Thu, 12 May 2016 04:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORG676131.onmicrosoft.com; s=selector1-nivettisystems-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5p+zelUnzBF7uZZL10pOK+pN0mWlaDTeKIHw7iGlINw=; b=LjH1bMOWTkBWvgS1Y7/qV1WsLYqPv2istcjKUdC0XccCfUxOUabau0XWfsHBhpfSCyU/2w4GLuZWI8jrkm1GtM44cwcpztS4M9QkNoX129HzVpp+IKMYPWX1YeiNDJuH/Z4cwDEQwOWiz3KU9tcaD5KUe5OVE3DCL3Lz4fU2dLw= Received: from KL1PR0401MB1544.apcprd04.prod.outlook.com (10.165.249.158) by HK2PR04MB1603.apcprd04.prod.outlook.com (10.167.71.25) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 11:09:47 +0000 Received: from KL1PR0401MB1544.apcprd04.prod.outlook.com ([10.165.249.158]) by KL1PR0401MB1544.apcprd04.prod.outlook.com ([10.165.249.158]) with mapi id 15.01.0492.016; Thu, 12 May 2016 11:09:47 +0000 From: Ramakrishna DTV To: Acee Lindem , Manav Bhatia Thread-Topic: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt Thread-Index: AQHRq5iDI45ZmPCOekqfeZl/Lp+NDp+0k8d6gAAWyICAABC5kYAABv2AgABiUACAAAFjQQ== Date: Thu, 12 May 2016 11:09:46 +0000 Message-ID: References: , <89E7259B-72EE-4B60-BFC1-BA55BE761B9C@lindem.com> In-Reply-To: <89E7259B-72EE-4B60-BFC1-BA55BE761B9C@lindem.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nivettisystems.com; x-originating-ip: [132.245.41.117] x-ms-office365-filtering-correlation-id: 524130ce-8042-4aa6-3e25-08d37a55ede3 x-microsoft-exchange-diagnostics: 1; HK2PR04MB1603; 5:VX6eBXFEYebaaa/WqRlZTGuJRpi1Sptyg0O6/tqlEaV1W0TYk9jIWq3de20GJUTOSpk9e40mBPg/OQmRL/4aNEwu2U9xY1pxDy5CaQvIYZLKF18hYY2UVIhekF+XE8hIzFt3VVXDf1ifIzek1CbtxA==; 24:0bhRVYgc+Bq1iDGW5EiyQdSffjjrWRu8o+G/1tM2zI6Xa1fYOv4OxDIBRRI4aR7m8omZ4S1WnvwFR9wF0Wl9LnpeFJCe0MZVO7UlqoJf0jw=; 7:nak8U8jdSTrj6MrRkQKRPLUhuGcXM5BUs6HAxfJcV+tpGIf8c1gq/eG9Vf1/j6U/6myD91ceEPvgneSZyWefpny+nX9iUqZEHyT5w/aO/fDJoTJYMuHTtFeened+TUBUpAuqcc/dJRqAibZWUpVNxbC0qYIS8GQFqNV6aprtvY3va5lMGWfMiOPc5DS3bBsQ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HK2PR04MB1603; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046); SRVR:HK2PR04MB1603; BCL:0; PCL:0; RULEID:; SRVR:HK2PR04MB1603; x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(243025005)(377424004)(51884002)(51914003)(4326007)(2906002)(66066001)(19580395003)(8936002)(86362001)(19580405001)(5001770100001)(74316001)(2900100001)(10710500007)(2950100001)(107886002)(189998001)(76576001)(586003)(3846002)(1220700001)(11100500001)(5004730100002)(87936001)(77096005)(6116002)(15975445007)(230783001)(7110500001)(102836003)(4001430100002)(10400500002)(9686002)(5003600100002)(92566002)(81166006)(122556002)(33656002)(106116001)(5008740100001)(3660700001)(50986999)(76176999)(345774005)(3900700001)(3280700002)(54356999)(15650500001)(5002640100001)(2420400007)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:HK2PR04MB1603; H:KL1PR0401MB1544.apcprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nivettisystems.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2016 11:09:46.9398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b780cc-c0fe-4e87-8da2-4702ecb31b90 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2PR04MB1603 Archived-At: Cc: OSPF List , Manjul Khandelwal Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 11:09:56 -0000 Hi Acee/Manav, I guess we were a little too brief in our description of the attack in the = draft. The paper "Nakibly, G. et al, Persistent OSPF attacks, NDSS , 2012" discusses about multiple variants of the "Disguised LSA attack". I will des= cribe one variant below. Some facts: Quoting from the paper: "Section 13.1 of the OSPF spec states that two instances of an LSA are=20 considered identical if they have the same values in the following three fi= elds: Sequence Number, Checksum, and Age. In fact, two LSAs are considered identical even if their Age fields differ by up to 15 minutes (and the Sequence Number and Checksum fields are the same). The key point is that the spec considers these two LSAs to be the same even if the actual advertised links in the LSAs differ." Network setup: There are a set of routers in a routing domain. In this network 'C' is the compromised router. 'V' is the victim router. Intention: C intends to change an LSA of V without V fighting back. Here is a time-line of events: t0: V generated an LSA with sequence number 's' and all routers have it installed in their database including C. t1: C changes the LSA of V to sequence number 's+1' and floods it. The pape= r refers this as "trigger LSA". While this LSA is flooding the network, and it is on its way to V as well..= . t2: C changes the LSA of V to sequence number 's+2' and changes the LSA in such a way that checksum will be same as what V would have calculated. V th= en floods this "disguised LSA". (Note: The time-gap between t1 and t2 is governed by MinLSArrival of RFC 23= 28.) t3: V receives LSA with sequence number 's+1' and as part of 'fight-back' mechanism reissues LSA with sequence number 's+2' and starts flooding. (Note that t3 may even be between t1 and t2 in some cases. But the attack s= till works in either case.) The important point now is that there are two LSAs in race for flooding in the network -- one prepared by C and other prepared by V. Both the LSAs have same values for the following values: Sequence Number ('s+2'), Checksum, and Age. But note that their contents are different! Any receiving router (including victim V) will consider these as duplicates= and installs the first one it receives. The point is that LSA with sequence number 's+2' will not trigger fight-bac= k. Instead, it will be considered as a duplicate. The entire attack is made possible because C knows that V will generate LSA= with sequence number 's+2' when it is fighting back an LSA with sequence number = 's+1'. Note that at the end of the attack, some routers have the LSA as prepared b= y V. This is the correct LSA. The remaining routers will have the LSA as prepare= d by C. It is obvious that LSDB of this second set is effectively corrupted. An important point is that even those routers which got correct LSA, it is sti= ll troublesome because LSDB is not same across all the routers. Unsynchronized= LSDB across routers cause routing issues. Gabi and co-authors have also provided a nice presentation which describes this attack in graphical form with little more detail (especially look at slides 14 to 20): http://www.internetsociety.org/sites/default/files/P01_3.pdf Thanks and regards, Ramakrishna DTV. ________________________________________ From: Acee Lindem Sent: Thursday, May 12, 2016 4:33 PM To: Manav Bhatia Cc: Ramakrishna DTV; OSPF List; Manjul Khandelwal Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-s= equence-number-00.txt Hi Manav, > On May 12, 2016, at 1:11 AM, Manav Bhatia wrote: > > Hi DTV, > > Aha. Thanks for the catch ! > > In that case, i dont understand why the "victim" will NOT generate a new = LSA with LS sequence number one past the received LS sequence number. I see= that the new attack tries to do something by updating the sequence number = and the checksum -- did not spend too much time on trying to understand wha= t exactly its doing there. However, OSPF also has provisions to get around = that, and i wrote about this many years ago here: > > https://routingfreak.wordpress.com/2010/07/02/using-checksum-in-determini= ng-the-newer-lsa/ > > So i have the same question as Acee -- why will the natural fight-back me= chanism not work here? It will and that was my point. I can think of only one possible attack wher= e the same sequence number is used but the attacker can only change the con= tents of the LSA for OSPF routers for which it is in the flooding path from= the originator. Thanks, Acee > > Cheers, Manav > > On Thu, May 12, 2016 at 10:18 AM, Ramakrishna DTV wrote: > > Hi Manav, > > Thank you for your comments. > > Gabi has published multiple attacks against OSPF. > > The attack we are targeting is published in > > @inproceedings{nakibly2012persistent, > title=3D{Persistent OSPF Attacks.}, > author=3D{Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and Boneh,= Dan}, > booktitle=3D{NDSS}, > year=3D{2012} > } > > This attack indeed depends on predictability of sequence numbers. > On a side note, we even verified that fact with Gabi Nakibly himself > over a private mail. > > The attack you are discussing in your article is a different attack. > It was described by Gabi in great detail in a different paper: > > @inproceedings{nakibly2014ospf, > title=3D{OSPF vulnerability to persistent poisoning attacks: a systemat= ic analysis}, > author=3D{Nakibly, Gabi and Sosnovich, Adi and Menahem, Eitan and Waize= l, Ariel and Elovici, Yuval}, > booktitle=3D{Proceedings of the 30th Annual Computer Security Applicati= ons Conference}, > pages=3D{336--345}, > year=3D{2014}, > organization=3D{ACM} > } > > As you rightly mentioned, this attack does not depend upon sequence numbe= r > predictability. But our draft is *not* targeting *this* attack. > > Thanks and regards, > Ramakrishna DTV. > > > > From: Manav Bhatia > Sent: Thursday, May 12, 2016 9:16 AM > To: Ramakrishna DTV > Cc: Acee Lindem (acee); Manjul Khandelwal; ospf@ietf.org > Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf= -sequence-number-00.txt > > Hi DTV, > > I dont agree to your assessment of how the attack evades the "natural fig= ht-back mechanism" in OSPF. > > Its got *nothing* to do with the sequence numbers being predictable, etc.= I have explained in depth how the Gaby attack works here: > > https://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnera= bility-exposed-by-black-hat/ > How bad is the OSPF vulnerability exposed by Black Hat ... > routingfreak.wordpress.com > I was asked a few weeks ago by our field engineers to provide a fix for t= he OSPF vulnerability exposed by Black Hat last month. Prima facie there ap= peared ... > > > Clipped from the blog: > > "This attack exploits a potential omission (or a bug if you will) in the = standard where it does not mandate that the receiving router verifies that = the Link State ID and the Advertising Router fields in the Router LSA are t= he exact same value. > > This attack sends malacious Router LSAs with two different values in the = LS header. The Link State ID carries the Router ID of the router that is be= ing attacked (the victim) and the Advertising Router is set to some differe= nt (any) value. > > When the victim receives the malacious Router LSA, it does not refresh th= is LSA as it doesnt recognize this as its own self generated LSA. This is b= ecause the OSPF spec clearly says in Sec 13.4 that =93A self-originated LSA= is detected when either 1) The LSA=92s Advertising Router is equal to the = router=92s own Router ID or 2) the LSA is a network LSA .. =93. > > This means that OSPF=92s natural fight back mechanism is NOT triggered by= the victim router as long as the field =91Advertising Router=92 of a LSA i= s NOT equal to the victim=92s Router ID. This is true even if the =91Link S= tate ID=92 of that LSA is equal to the victim=92s Router ID. Going further = it means no LSA refresh is triggered even if the malacious LSA claims to de= scribe the links of the victim router!" > > I describe further in the blog that not all router implementations are su= sceptible to the attack. Its dependent on how the LSA is picked up from the= LSDB. > > Cheers, Manav > > On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV wrote: > Hi Acee, > > We currently provided the following description of this attack in the dra= ft: > > "The paper refers to the attack as "Disguised LSA" and is of > persistent nature. This attack is launched from a compromised router > inside a routing domain. In this attack, the compromised router > alters the LSA of an uncompromised router (victim). Normally, such > an attempt does not have persistence because the victim generates a > new LSA when it sees such self-originated LSAs (referred to as > "fight-back" mechanism in the paper). But the paper makes disguised > LSA persistent because all the fields { LS sequence number, checksum} > are predictable. It alters the existing LSA of victim to suit its > needs but sets the sequence number to +1 of the existing LSA and > alters the LSA so that checksum matches with checksum that would be > generated by the victim when it generates the new LSA. When this > disguised LSA reaches the victim, it does not fight back because it > compares only the fields { LS sequence number, checksum, age} to > check for duplicates and not the actual content of LSA. > > This attack enables an insider attacker to fully control the entire > content of an LSA. We think this attack is powerful." > > These details are currently present in Section 4, which is titled "Implem= entation advice". > We can probably move it to a different section (e.g., "Introduction") to = make it clear. > > If you think even more additional details about the attack are useful to = the working group, > please let us know. We will add. > > Thank you. > > Regards, > Ramakrishna DTV. > > > ________________________________________ > From: Acee Lindem (acee) > Sent: Wednesday, May 11, 2016 8:49 PM > To: Manjul Khandelwal; ospf@ietf.org > Cc: Ramakrishna DTV > Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf= -sequence-number-00.txt > > Hi Manjul, > > Would it be possible to succinctly describe these =93certain security > attacks=94 in the draft rather than expecting everyone to read the > referenced paper? > > Thanks, > Acee > > On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal" > wrote: > > >Hi, > > > >We have recently submitted a draft which deals with OSPF LS sequence > >number > >generation mechanism. > > > >Abstract of the draft: > > The mechanism for LS sequence number generation as specified in RFC > > 2328 and RFC 5340 is completely predictable. This makes it prone to > > certain security attacks which exploit the predictable nature of LS > > sequence numbers. This draft updates the RFC 2328 to make LS > > sequence number generation an implementation choice rather than a > > fixed increment by 1 for successive LSAs. > > > >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ > > > >We solicit feedback/comments on the draft and request for adoption by th= e > >OSPF working group. > > > >Regards, > >Manjul Khandelwal > >DTV Ramakrishna Rao > >________________________________________ > >From: internet-drafts@ietf.org > >Sent: Monday, May 9, 2016 7:22 PM > >To: Manjul Khandelwal; Ramakrishna DTV > >Subject: New Version Notification for > >draft-manjuldtv-ospf-sequence-number-00.txt > > > >A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt > >has been successfully submitted by Manjul Khandelwal and posted to the > >IETF repository. > > > >Name: draft-manjuldtv-ospf-sequence-number > >Revision: 00 > >Title: OSPF LSA sequence number generation > >Document date: 2016-05-09 > >Group: Individual Submission > >Pages: 10 > >URL: > >https://www.ietf.org/internet-drafts/draft-manjuldtv-ospf-sequence-numbe= r- > >00.txt > >Status: > >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ > >Htmlized: > >https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00 > > > > > >Abstract: > > The mechanism for LS sequence number generation as specified in RFC > > 2328 and RFC 5340 is completely predictable. This makes it prone to > > certain security attacks which exploit the predictable nature of LS > > sequence numbers. This draft updates the RFC 2328 to make LS > > sequence number generation an implementation choice rather than a > > fixed increment by 1 for successive LSAs. > > > > > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >The IETF Secretariat > > > >_______________________________________________ > >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 > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Thu May 12 10:45:52 2016 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 3D64712D107; Thu, 12 May 2016 10:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4-JlEUgsGWQ; Thu, 12 May 2016 10:45:49 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89F012D0F7; Thu, 12 May 2016 10:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5fY3myGoHzImZCv4uMid6nKYxkKEhHxMRnYr2hiJ9ok=; b=QDjPrevhHXp4qFq5MUU85jS+TSBTwbFG5HEbt7p07Yckch8zVlrl1Ik38Bjw3UiYIqbxTQJuSaYMQFjRzHjvTjhLOFJpiCiXCCsx4hxx2M7JTmJkJM3In61QR62uzlxFWxSozWJnk5+HU4j5eH8St6LD840exAItcuH2gCM+Ll4= Authentication-Results: metaswitch.com; dkim=none (message not signed) header.d=none;metaswitch.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (109.145.193.232) by VI1PR07MB1632.eurprd07.prod.outlook.com (10.166.142.150) with Microsoft SMTP Server (TLS) id 15.1.497.12; Thu, 12 May 2016 17:45:31 +0000 Message-ID: <01f101d1ac75$8fd66a80$4001a8c0@gateway.2wire.net> From: t.petch To: Alan Davey , "Derek Man-Kit Yeung (myeung)" , References: Date: Thu, 12 May 2016 18:41:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.145.193.232] X-ClientProxiedBy: DB3PR05CA0016.eurprd05.prod.outlook.com (10.160.41.144) To VI1PR07MB1632.eurprd07.prod.outlook.com (10.166.142.150) X-MS-Office365-Filtering-Correlation-Id: 1ff47432-8677-4a2a-a692-08d37a8d36ec X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 2:muk5F4FKY2YBPtE68+ByAX/OhxjFUbrm5OMq645selRGllKeex3VFvsIfd5Wj7WxGFq+1sMUEq73CjW+WLGO2kFpwS55JrX5GET4ETVEUMkkn3c2Uz5MlcMhDjLd5ijwkYxTa2bH+2OPGsFLHlzbu8XlYOyHYo0cwAlecU8X2jxrjuY9KN5lVx4rUK52DLr2; 3:QUwEOcNyZUPFwoSus8pi50gKL/uXhVNBcmk+Cbxu/I+dCwQZWWVHW6BzgBSF5/+49wGiYrqnieH0j7gqUcMxkIuxvNcOSVG6o+ONASDVDPZAA8y41UjZN/kjLWLe9Y9Q X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1632; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 25:BHR9O2bAfo58TP4w1iAsvsxv4++TKMzSS3IPOAYUA3ayYY2hRYKs41n/R+rAUN/BS1BJJBsCiMhoRnEWPSVOV/7aypd0LduN8zPf4FDpaw4+4BvSFpiud/UQrwpPa3jdwxM8n5itXAP6hP1rA1Qlhr8z3cNBtM18gX1TnuPig03uOq038vGeo09eZ5yVyh8D1iXdwqj3pvyiEEKi06dnQT7Zr9ukxHd3V3bg81h6SBkN4I7m5LCRrBJQE3jd4EctTYpgjaDAUmewSfEoEow4tjiE0F4uT+WmecOhLIIfc1lpJdieGZ6jEAV8Euyx6+4B4Y3kotHkD6EujMM/ejZz/Ho7zsBjg8e92uHOQV1hAWtdDXO/4OuHDy6tutbHaWGpzLxb79CM4XZhToVC/DFJavRezBzddQzRdpFv8Fj83jgAZen/MQbgzDmAQFGBIgMcazwwsmTLRwQJpvoiJOmPPiYvzqj61zoi8UIL/jjhQUg2fVl5JYnH4ZA3k4urZv1a5eL30nFco+PExt0nu/IE0ld2r8SEpkC5cTKf7YdHWBqWmNkW5fz1pxCNW492jTHtdjUx/2HBf4p68rm+oMjUzhDzTYO8jvyn/U1c/9g+xCYed1NDRqsTtBfhig+JLu/bRha67285XPi+ZjBI7zd1lqp62fslB5Alt2J9g92mUOBvWz4L2EvcCJOhLRY/444VquGZlBiyqmpZ7MBwSqAz2/N4iYkkxp2uxrqMRX0r/Ic= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB1632; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1632; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 4:WDQ537dueFMg3cxZhKoF3LEAR7kwZLZ4+nTT2KVbtAhMyDN8VDWeQtaZKdrtux/M4eXE5vBMuYfhu0TtM5TK07UQh9HzHk5LFRLg36XQrPQzrqLNbNORsN7rObr2fjMN1F7eVEkr7wk4wILrAVCGmvpS7ephmyiCR1WNGZp67xKd0GKEiIB+JfZOzTMys0nrSw0q2bOK5XPNaXSF3mRvfOyjy/pwVhNkfN6AFCBFFtG4xD3Iu9PSN4SECl+5mmmvRNpjyWwsyoQtU52e2+upBoF3Zr+YxPXJcJo4TCYuTkpFrCdVHDOBxnZ5LqUDuTJGkBDLQxWYjrQD8OB04/EZxu16XE8oEXcNmoNV3kcRGSWCCo1gd4tFglVfZFYdf2KR8UzCIJMeApoM2WFYr6iTS6ioYm/9Yd/uYB3BsBKGmBs= X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(377454003)(13464003)(76104003)(81816999)(14496001)(86362001)(81686999)(93886004)(76176999)(50986999)(9686002)(47776003)(62236002)(1556002)(1456003)(230700001)(77096005)(19580405001)(116806002)(4326007)(84392002)(19580395003)(50466002)(44716002)(44736004)(50226002)(92566002)(106356001)(2906002)(5004730100002)(81166006)(230783001)(5001770100001)(33646002)(97736004)(66066001)(189998001)(23756003)(5008740100001)(42186005)(586003)(6116002)(3846002)(61296003)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1632; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR07MB1632; 23:1Z0h0rEhg/lzY8biAVrtknUr8C+eHs3eEzIF+EM?= =?iso-8859-1?Q?Cv4J1esZ1WfkYFfAXP6XVd9wlFRRq006LWb8SgXA5ToKpnaTHgURC0gJos?= =?iso-8859-1?Q?1G3oN+950F2gfejkSXvAMdjQOFustDXq/0gnRS8OiIQIKFOGZPOUwM0HZS?= =?iso-8859-1?Q?WsyOFZnt0CH3oSiHWON6trEINQ5ax4MuZ9KcECCxGkA/x29+ilFY8PJVc5?= =?iso-8859-1?Q?/M97w/z67tGu/8Te9AzYGbUu/uD5Rj8PFVPsdBWT/O5EHrMGrabSo9SHfB?= =?iso-8859-1?Q?ZDcQNutqZUxnFJrjuaFa/JpnGETZBOTIaQ6KYQpSTWDSdEV399p0MrC0I4?= =?iso-8859-1?Q?bn21Nl7O1q3yTyWx+ZllC8j1eqfeM9SonVu/HycT2RjRcwOEDSZyj7xTKt?= =?iso-8859-1?Q?XrsIunNAo00fyuRw78pDz4TgUWXSQq//8OIijd4JxmhReCpZr5QdrfK8ck?= =?iso-8859-1?Q?f7xmDt9tmSdBAuzHFvXj5Pwn2nrQfnmb5Tji6swfRjNItle/c1zRqraVFE?= =?iso-8859-1?Q?YwEFX5fmQUVnZFjGrRqiDikjEyaMHW+KmCJAa2WsLH5dvUTD1UiIFg4nbX?= =?iso-8859-1?Q?9oZVXr+x5FPQnacI8ttn4t9nw0R4Vumy5+B9vPAs6xbX+ABZilG+bg6nKz?= =?iso-8859-1?Q?CVLgmHF2jz84PZ9Io3o78oEp9TX0j9HjWgtZis3vvkGuUQ9B7RJNTWNYZX?= =?iso-8859-1?Q?eCD6AkWa91LRM+tCTnESSVgxzbOlKEvKUqoBw9Nkcs5x84wHTdlt4TDUpw?= =?iso-8859-1?Q?klxxr6qbVvUOrJnC6oJsa9ERaqusvMEXNHAGKdNbvQfHKCGdJwxteZr1s8?= =?iso-8859-1?Q?mXvWNmaGVg24qk6PfAHh591LzWz93HIOybOVnljzTUH+XdyAHCfg5hxclL?= =?iso-8859-1?Q?f2ErOiHvtzZZddbm/AyEUcgKbkMPdrH3VMqaB64WKIAd6aIQP8Y5Noyf16?= =?iso-8859-1?Q?UovBstxSDYXzOU8nXHS4kO4cok57Rzd0RC6Xzton0HoaxY8NPYjYNMS04R?= =?iso-8859-1?Q?ohoPoyJ6KbdVIS7mJ+CDS2S1QRqvyRbp5f/l+Rm15hPiG29psTF3iAPfgC?= =?iso-8859-1?Q?hhP/qFh9Ql+hzAF6NBqRyz7kJ+xCM1kUvHdaeAeddqKWbDmt0w6YKMdCQ7?= =?iso-8859-1?Q?ECcEliPUsB4RSGLPypzKPqztp1aEFXL+Ggog/lrwWjTPCY8qAtD7FQknwx?= =?iso-8859-1?Q?lxzkLPGrl3Fa9ZUSikQK2M+RHh+Quiv4lMli/Jo/mkJi+uSm5tNphTawJ3?= =?iso-8859-1?Q?eFnoiPdQhsNDNbABlHc+WLTz/El1+rma0uKyL1D6IrNh8SyPweQ+qMIeCn?= =?iso-8859-1?Q?ps=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 5:udsKsoC/CPKZoa0IQgRUhE8jNt2RF3yIpPerLecHeL/y7Jt+zXYvEJEoA7nZ8jlIIXqFy54Aa4pvVJ1LJJla3ddN3HYYnheYxGV8x4HlZH7VpkXEntEzml8tFwEeHCfYmXKF9RN8wl98M84jdMTMLw==; 24:4JOeRNYf2uOnYRiGajSmfBJ1nznQC3ctUygxleaf4Wqb5YidK0LIRxdEuDc0Wx2ZfFCMQ48SpzP9lNsW6vzcBBtwfYXyW8Ai9Wp4X06Q1Dc=; 7:rjbIfDKRvw3Xk0FZtjLTUZ8QDJpQSFjlfK4uwb0qx7W3ih3PgyVHFIh3ita0AMBpl9Ez+zjcycFAXDjPd2x01I3J1eByjaUwIxV+AppD1buKastElVUSmXmBps+AwDS+qieRI4Yt7bX2yZPCjEqi2lrKbLJIKHa91qUCg3uroohiQhIpJUXkjHhaCWbz1PJ6 SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 17:45:31.5452 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1632 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 17:45:52 -0000 ----- Original Message ----- From: "Alan Davey" To: "Derek Man-Kit Yeung (myeung)" ; Cc: "OSPF WG List" Sent: Wednesday, May 11, 2016 5:40 PM Hi Derek A question about the key for OSPF interfaces in the Yang draft. Please let me know what you think. The background is that the Management Information Base definitions define indices for OSPF interfaces as follows. - For OSPFv2, RFC 4750 defines the index as ospfIfIpAddress, ospfAddressLessIf. - For OSPFv3, RFC 5643 defines the index as ospfv3IfIndex, ospfv3IfInstId. However, in the OSPF Yang draft, the key is defined as "interface", which I believe is a name of the interface. How does "interface" map to the indices defined in RFCs 4750 and 5643? It doesn't (IMHO). You have two lists of interfaces in this I-D container interfaces { description "All interfaces."; list interface { key "interface"; description "List of OSPF interfaces."; container interfaces { description "All interfaces in the area."; list interface { key "interface"; description "List of OSPF interfaces."; both keyed on 'interface' (which is two separate lists so two separate 'interface' leaf, different sets of key objects.). Both are defined as type if:interface-ref; and the if: harks back to import ietf-interfaces {prefix "if"; and ietf-interfaces is in RFC7223 where interface-ref is defined as " An interface is identified by its name, which is unique within the server. This property is captured in the "interface-ref" and "interface-state-ref" typedefs, which other YANG modules SHOULD use when they need to reference a configured interface or operationally used interface, respectively." So both lists are keyed on a name which is unique within the server and can be anything, such as 'lan0' or 'fast-ethernet-23/7' or 'hotplug23/6/15' or... It all depends; names may be dictated by the hardware with no choice, or they may be dictated by the software to compliant hardware or ... Underlying this is the thought that we have no good definition of an interface, one that works across all protocols and other aspects of a configuration; an interface is like a blob of jelly and pinning it down to be a name is about as good a grasp of it as we will get (IMO). Tom Petch Thanks Alan From nobody Fri May 13 07:02:34 2016 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 C2DB212D159; Fri, 13 May 2016 07:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKq19mtK2MgY; Fri, 13 May 2016 07:02:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EF112D18A; Fri, 13 May 2016 07:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4020; q=dns/txt; s=iport; t=1463148149; x=1464357749; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=q6KSyVMvziFFpXKaIFFuI/F0Eq/7+GKyHrY/DL8uu7Q=; b=Z7ffrTsmkxL94dxLy4NBhDXBiboYntWE/VBCy6jYbDGD1AMB42LfEhBQ uQC2pzKauPUXO6XAKYoOSm5Y/0Qx7UVLTN+iyYwI0ZLNCEkiLqcAzxp3f fA6sry5CbMUSDz8WA9a8LDNjmGUhABoalrwW0aucu0iVewLnCGdcAB6Q5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQAl3jVX/5RdJa1egzdVfga5UQENg?= =?us-ascii?q?XYXC4JAgzICHIEQOBQBAQEBAQEBZSeEQgEBAQQBAQEgEToLDAQCAQgVAQQCJgI?= =?us-ascii?q?CAiULFRACBAENBYgvDq9DkQgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBiXGEK?= =?us-ascii?q?RYHMQKCRoJZBY1fikgBjh2BaYRPiGGPQAEeAQFCg2xuh1t/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208";a="107616487" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2016 14:02:28 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4DE2Sia010129 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2016 14:02:28 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 May 2016 10:02:27 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 13 May 2016 10:02:27 -0400 From: "Acee Lindem (acee)" To: "t.petch" , Alan Davey , "Derek Man-Kit Yeung (myeung)" , "draft-ietf-ospf-yang@ietf.org" Thread-Topic: [OSPF] draft-ietf-ospf-yang-03 questions and doubts Thread-Index: AQHRrHYn2XZTM8Zh7Ea9M+xWxcvHEp+25z2A Date: Fri, 13 May 2016 14:02:27 +0000 Message-ID: References: <01f101d1ac75$8fd66a80$4001a8c0@gateway.2wire.net> In-Reply-To: <01f101d1ac75$8fd66a80$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <13C65CE6EF58E04D99665334839BBC14@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 14:02:33 -0000 SGkgVG9tLCANCg0KT24gNS8xMi8xNiwgMTo0MSBQTSwgIk9TUEYgb24gYmVoYWxmIG9mIHQucGV0 Y2giIDxvc3BmLWJvdW5jZXNAaWV0Zi5vcmcgb24NCmJlaGFsZiBvZiBpZXRmY0BidGNvbm5lY3Qu Y29tPiB3cm90ZToNCg0KPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj5Gcm9tOiAiQWxh biBEYXZleSIgPEFsYW4uRGF2ZXlAbWV0YXN3aXRjaC5jb20+DQo+VG86ICJEZXJlayBNYW4tS2l0 IFlldW5nIChteWV1bmcpIiA8bXlldW5nQGNpc2NvLmNvbT47DQo+PGRyYWZ0LWlldGYtb3NwZi15 YW5nQGlldGYub3JnPg0KPkNjOiAiT1NQRiBXRyBMaXN0IiA8b3NwZkBpZXRmLm9yZz4NCj5TZW50 OiBXZWRuZXNkYXksIE1heSAxMSwgMjAxNiA1OjQwIFBNDQo+DQo+SGkgRGVyZWsNCj4NCj5BIHF1 ZXN0aW9uIGFib3V0IHRoZSBrZXkgZm9yIE9TUEYgaW50ZXJmYWNlcyBpbiB0aGUgWWFuZyBkcmFm dC4gIFBsZWFzZQ0KPmxldCBtZSBrbm93IHdoYXQgeW91IHRoaW5rLg0KPg0KPlRoZSBiYWNrZ3Jv dW5kIGlzIHRoYXQgdGhlIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZSBkZWZpbml0aW9ucw0K PmRlZmluZSBpbmRpY2VzIGZvciBPU1BGIGludGVyZmFjZXMgYXMgZm9sbG93cy4NCj4NCj4NCj4t ICAgICAgICAgIEZvciBPU1BGdjIsIFJGQyA0NzUwIGRlZmluZXMgdGhlIGluZGV4IGFzIG9zcGZJ ZklwQWRkcmVzcywNCj5vc3BmQWRkcmVzc0xlc3NJZi4NCj4NCj4tICAgICAgICAgIEZvciBPU1BG djMsIFJGQyA1NjQzIGRlZmluZXMgdGhlIGluZGV4IGFzIG9zcGZ2M0lmSW5kZXgsDQo+b3NwZnYz SWZJbnN0SWQuDQo+DQo+SG93ZXZlciwgaW4gdGhlIE9TUEYgWWFuZyBkcmFmdCwgdGhlIGtleSBp cyBkZWZpbmVkIGFzICJpbnRlcmZhY2UiLA0KPndoaWNoIEkgYmVsaWV2ZSBpcyBhIG5hbWUgb2Yg dGhlIGludGVyZmFjZS4NCj4NCj5Ib3cgZG9lcyAiaW50ZXJmYWNlIiBtYXAgdG8gdGhlIGluZGlj ZXMgZGVmaW5lZCBpbiBSRkNzIDQ3NTAgYW5kIDU2NDM/DQo+DQo+PHRwPg0KPg0KPkl0IGRvZXNu J3QgKElNSE8pLiAgWW91IGhhdmUgdHdvIGxpc3RzIG9mIGludGVyZmFjZXMgaW4gdGhpcyBJLUQN Cj4NCj5jb250YWluZXIgaW50ZXJmYWNlcyB7IGRlc2NyaXB0aW9uICJBbGwgaW50ZXJmYWNlcy4i OyBsaXN0IGludGVyZmFjZSB7DQo+a2V5ICJpbnRlcmZhY2UiOw0KPmRlc2NyaXB0aW9uICJMaXN0 IG9mIE9TUEYgaW50ZXJmYWNlcy4iOw0KPg0KPmNvbnRhaW5lciBpbnRlcmZhY2VzIHsgZGVzY3Jp cHRpb24gIkFsbCBpbnRlcmZhY2VzIGluIHRoZSBhcmVhLiI7ICBsaXN0DQo+aW50ZXJmYWNlIHsg a2V5ICJpbnRlcmZhY2UiOw0KPmRlc2NyaXB0aW9uICJMaXN0IG9mIE9TUEYgaW50ZXJmYWNlcy4i Ow0KPg0KPmJvdGgga2V5ZWQgb24gJ2ludGVyZmFjZScgKHdoaWNoIGlzIHR3byBzZXBhcmF0ZSBs aXN0cyBzbyB0d28gc2VwYXJhdGUNCj4naW50ZXJmYWNlJyBsZWFmLCBkaWZmZXJlbnQgc2V0cyBv ZiBrZXkgb2JqZWN0cy4pLg0KDQpUaGVzZSBhcmUgYmFzaWNhbGx5IHRoZSBzYW1lIGxpc3RzIC0g b25lIGlzIGZvciBvcGVyYXRpb25hbCBzdGF0ZSBhbmQgdGhlDQpvdGhlciBpcyBmb3IgY29uZmln dXJhdGlvbi4NCg0KDQo+DQo+Qm90aCBhcmUgZGVmaW5lZCBhcw0KPg0KPiAgICAgdHlwZSBpZjpp bnRlcmZhY2UtcmVmOw0KPg0KPmFuZCB0aGUgaWY6IGhhcmtzIGJhY2sgdG8NCj4gICAgIGltcG9y dCBpZXRmLWludGVyZmFjZXMge3ByZWZpeCAiaWYiOw0KPmFuZCBpZXRmLWludGVyZmFjZXMgaXMg aW4gUkZDNzIyMyB3aGVyZSBpbnRlcmZhY2UtcmVmIGlzIGRlZmluZWQgYXMNCj4iICAgQW4gaW50 ZXJmYWNlIGlzIGlkZW50aWZpZWQgYnkgaXRzIG5hbWUsIHdoaWNoIGlzIHVuaXF1ZSB3aXRoaW4g dGhlDQo+ICAgc2VydmVyLiAgVGhpcyBwcm9wZXJ0eSBpcyBjYXB0dXJlZCBpbiB0aGUgImludGVy ZmFjZS1yZWYiIGFuZA0KPiAgICJpbnRlcmZhY2Utc3RhdGUtcmVmIiB0eXBlZGVmcywgd2hpY2gg b3RoZXIgWUFORyBtb2R1bGVzIFNIT1VMRCB1c2UNCj4gICB3aGVuIHRoZXkgbmVlZCB0byByZWZl cmVuY2UgYSBjb25maWd1cmVkIGludGVyZmFjZSBvciBvcGVyYXRpb25hbGx5DQo+ICAgdXNlZCBp bnRlcmZhY2UsIHJlc3BlY3RpdmVseS4iDQo+DQo+U28gYm90aCBsaXN0cyBhcmUga2V5ZWQgb24g YSBuYW1lIHdoaWNoIGlzIHVuaXF1ZSB3aXRoaW4gdGhlIHNlcnZlciBhbmQNCj5jYW4gYmUgYW55 dGhpbmcsIHN1Y2ggYXMgJ2xhbjAnIG9yICdmYXN0LWV0aGVybmV0LTIzLzcnIG9yDQo+J2hvdHBs dWcyMy82LzE1JyBvci4uLiBJdCBhbGwgZGVwZW5kczsgbmFtZXMgbWF5IGJlIGRpY3RhdGVkIGJ5 IHRoZQ0KPmhhcmR3YXJlIHdpdGggbm8gY2hvaWNlLCBvciB0aGV5IG1heSBiZSBkaWN0YXRlZCBi eSB0aGUgc29mdHdhcmUgdG8NCj5jb21wbGlhbnQgaGFyZHdhcmUgb3IgLi4uDQo+DQo+VW5kZXJs eWluZyB0aGlzIGlzIHRoZSB0aG91Z2h0IHRoYXQgd2UgaGF2ZSBubyBnb29kIGRlZmluaXRpb24g b2YgYW4NCj5pbnRlcmZhY2UsIG9uZSB0aGF0IHdvcmtzIGFjcm9zcyBhbGwgcHJvdG9jb2xzIGFu ZCBvdGhlciBhc3BlY3RzIG9mIGENCj5jb25maWd1cmF0aW9uOyBhbiBpbnRlcmZhY2UgaXMgbGlr ZSBhIGJsb2Igb2YgamVsbHkgYW5kIHBpbm5pbmcgaXQgZG93bg0KPnRvIGJlIGEgbmFtZSBpcyBh Ym91dCBhcyBnb29kIGEgZ3Jhc3Agb2YgaXQgYXMgd2Ugd2lsbCBnZXQgKElNTykuDQoNCkFncmVl ZC4gDQoNClRoYW5rcywNCkFjZWUgDQoNCg0KDQo+DQo+VG9tIFBldGNoDQo+DQo+VGhhbmtzDQo+ QWxhbg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+T1NQRiBtYWlsaW5nIGxpc3QNCj5PU1BGQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vc3BmDQoNCg== From nobody Fri May 13 07:37:51 2016 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 6C32112B01A; Fri, 13 May 2016 07:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plizPe6fslW9; Fri, 13 May 2016 07:37:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0770.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D728012B013; Fri, 13 May 2016 07:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6p+700LHm+ljDr4NEGU9TDgivf89HYfvLLTpj62WRTc=; b=faXWe2wFqBlE/M9Db1Cg3aGSjg30wZSaZjd8xdJpiw/EamB5eWwTC7hc60XcRAbU7mgZ9KlHe4e/BgqS3AWVxpdOJPH8TlSfEJsRJOVjq8LEK8qgoyZcgvy1RH0rEF9pRW8wLNJ4WQiKTLeX1CQzmscN+i8T79R/BPG98kdgBfo= Received: from BN3PR0201MB1059.namprd02.prod.outlook.com (10.161.209.14) by BN3PR0201MB1058.namprd02.prod.outlook.com (10.161.209.139) with Microsoft SMTP Server (TLS) id 15.1.492.11; Fri, 13 May 2016 14:37:26 +0000 Received: from BN3PR0201MB1059.namprd02.prod.outlook.com ([10.161.209.14]) by BN3PR0201MB1059.namprd02.prod.outlook.com ([10.161.209.14]) with mapi id 15.01.0492.019; Fri, 13 May 2016 14:37:26 +0000 From: Alan Davey To: "Acee Lindem (acee)" , t.petch , "Derek Man-Kit Yeung (myeung)" , "draft-ietf-ospf-yang@ietf.org" Thread-Topic: [OSPF] draft-ietf-ospf-yang-03 questions and doubts Thread-Index: AdE3NLGjjtMGuql0QfiSt+s9ulh9zgoPjYmAAiVQNuADX5obgAcESYLgBoJ48NAANR+BoQAqfv2AAACIaOA= Date: Fri, 13 May 2016 14:37:26 +0000 Message-ID: References: <01f101d1ac75$8fd66a80$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [86.31.33.199] x-ms-office365-filtering-correlation-id: efa2dee7-8f48-4612-4fc0-08d37b3c1acf x-microsoft-exchange-diagnostics: 1; BN3PR0201MB1058; 5:x3r2A0KA2tOOsxdspZtNyl48SJdkQrW8WjuD6WRD+A1zoKRFMV0H2upuHNvmDEShhSTXVDvVdPF3HWBmIvaU0EORCWYM1yD5IZ6vUamwj2Ik72hqFSuQwzxnwlwFe6d8CBHPLULNLaUruZYdzU8i6A==; 24:v1TIhBZtZNm6C3hWofuXuu1lBi4qYESnCLxoqjIZCXrSr9FZZqJFAnX5TcE+cb9yJj8cvLmRZzdE+X6TJaSJDcZZo8uG9jpDf5kRaQNvJNw=; 7:LfFEC2qvQ6wRk7XwkOiA/7359V7EHWCK0dnHceTO9bc60ESXe+1uGFXIk42uRhrnV7wT1kxR3IafDsabePvAV6yP5JxP53Q2RMWhH2ZVFnLzv4VBKwYAg8TzxtCadKqawIzWtEhBpPSVSuHz1pvVY8gFG7guwGKgtsN8K+5WEvwgmwG67a40iMBiF6rq37t5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0201MB1058; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0201MB1058; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB1058; x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(24454002)(76104003)(92566002)(5008740100001)(99286002)(76576001)(93886004)(5003600100002)(5002640100001)(33656002)(19580405001)(8676002)(345774005)(9686002)(4326007)(19580395003)(87936001)(76176999)(77096005)(50986999)(2900100001)(2950100001)(10400500002)(81166006)(2906002)(86362001)(54356999)(15975445007)(74316001)(3280700002)(8936002)(1220700001)(5004730100002)(586003)(6116002)(11100500001)(102836003)(3846002)(66066001)(189998001)(5001770100001)(230783001)(122556002)(3660700001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB1058; H:BN3PR0201MB1059.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2016 14:37:26.5545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB1058 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 14:37:50 -0000 SGkgVG9tIGFuZCBBY2VlDQoNClRoYW5rIHlvdSBmb3IgZ2V0dGluZyBiYWNrIHRvIG1lLiAgSSB1 bmRlcnN0YW5kIHRoYXQgYW4gImludGVyZmFjZSIgaXMgaWRlbnRpZmllZCBieSBpdHMgbmFtZS4g IE15IGRvdWJ0IGlzIGFib3V0IGhvdyBPU1BGdjIgY29uZmlndXJhdGlvbiBkZWZpbmVkIGZvciBh biAiaW50ZXJmYWNlIiBpcyBtYXBwZWQgdG8gYW4gaW50ZXJuYWwgT1NQRnYyIGludGVyZmFjZSBv YmplY3QgdGhhdCBpcyBpbmRleGVkIG9uIElQIGFkZHJlc3MgKGFzIHBlciBSRkMgNDc1MCkuICBQ ZXJoYXBzIHlvdSBjb3VsZCBsZXQgbWUga25vdyB3aGF0IHlvdSB0aGluay4NCg0KSW4gbW9yZSBk ZXRhaWwsIGNvbnNpZGVyIHRoZSBjYXNlIHdoZXJlIG9uZSBpbnRlcmZhY2UgaXMgYXNzaWduZWQg bXVsdGlwbGUgSVAgYWRkcmVzc2VzLiAgVGhlIE9TUEZ2MiBwcm90b2NvbCBjb25zaWRlcnMgdGhl c2UgdG8gYmUgc2VwYXJhdGUgbmV0d29ya3MgKGFzIHBlciBSRkMgMjMyOCwgc2VjdGlvbiAxLjIs IGZvciBleGFtcGxlKS4gIElmIHRoZSBPU1BGdjIgY29uZmlndXJhdGlvbiBpcyBkZWZpbmVkIHBl ciBpbnRlcmZhY2UsIGlzIHRoYXQgY29uZmlndXJhdGlvbiBhcHBsaWVkIHRvIGFsbCBvZiB0aGUg c2VwYXJhdGUgT1NQRnYyIGludGVyZmFjZXMgb3IgdG8gb25lIG9mIHRoZW0/ICBJZiB0byBvbmUg b2YgdGhlbSB0aGVuIGhvdyBpcyB0aGF0IG9uZSBzZWxlY3RlZD8NCg0KUmVnYXJkcw0KQWxhbg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBY2VlIExpbmRlbSAoYWNlZSkg W21haWx0bzphY2VlQGNpc2NvLmNvbV0gDQpTZW50OiAxMyBNYXkgMjAxNiAxNTowMg0KVG86IHQu cGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb20+OyBBbGFuIERhdmV5IDxBbGFuLkRhdmV5QG1ldGFz d2l0Y2guY29tPjsgRGVyZWsgTWFuLUtpdCBZZXVuZyAobXlldW5nKSA8bXlldW5nQGNpc2NvLmNv bT47IGRyYWZ0LWlldGYtb3NwZi15YW5nQGlldGYub3JnDQpDYzogT1NQRiBXRyBMaXN0IDxvc3Bm QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPU1BGXSBkcmFmdC1pZXRmLW9zcGYteWFuZy0wMyBx dWVzdGlvbnMgYW5kIGRvdWJ0cw0KDQpIaSBUb20sIA0KDQpPbiA1LzEyLzE2LCAxOjQxIFBNLCAi T1NQRiBvbiBiZWhhbGYgb2YgdC5wZXRjaCIgPG9zcGYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgaWV0ZmNAYnRjb25uZWN0LmNvbT4gd3JvdGU6DQoNCj4tLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tDQo+RnJvbTogIkFsYW4gRGF2ZXkiIDxBbGFuLkRhdmV5QG1ldGFzd2l0Y2guY29t Pg0KPlRvOiAiRGVyZWsgTWFuLUtpdCBZZXVuZyAobXlldW5nKSIgPG15ZXVuZ0BjaXNjby5jb20+ OyANCj48ZHJhZnQtaWV0Zi1vc3BmLXlhbmdAaWV0Zi5vcmc+DQo+Q2M6ICJPU1BGIFdHIExpc3Qi IDxvc3BmQGlldGYub3JnPg0KPlNlbnQ6IFdlZG5lc2RheSwgTWF5IDExLCAyMDE2IDU6NDAgUE0N Cj4NCj5IaSBEZXJlaw0KPg0KPkEgcXVlc3Rpb24gYWJvdXQgdGhlIGtleSBmb3IgT1NQRiBpbnRl cmZhY2VzIGluIHRoZSBZYW5nIGRyYWZ0LiAgUGxlYXNlIA0KPmxldCBtZSBrbm93IHdoYXQgeW91 IHRoaW5rLg0KPg0KPlRoZSBiYWNrZ3JvdW5kIGlzIHRoYXQgdGhlIE1hbmFnZW1lbnQgSW5mb3Jt YXRpb24gQmFzZSBkZWZpbml0aW9ucyANCj5kZWZpbmUgaW5kaWNlcyBmb3IgT1NQRiBpbnRlcmZh Y2VzIGFzIGZvbGxvd3MuDQo+DQo+DQo+LSAgICAgICAgICBGb3IgT1NQRnYyLCBSRkMgNDc1MCBk ZWZpbmVzIHRoZSBpbmRleCBhcyBvc3BmSWZJcEFkZHJlc3MsDQo+b3NwZkFkZHJlc3NMZXNzSWYu DQo+DQo+LSAgICAgICAgICBGb3IgT1NQRnYzLCBSRkMgNTY0MyBkZWZpbmVzIHRoZSBpbmRleCBh cyBvc3BmdjNJZkluZGV4LA0KPm9zcGZ2M0lmSW5zdElkLg0KPg0KPkhvd2V2ZXIsIGluIHRoZSBP U1BGIFlhbmcgZHJhZnQsIHRoZSBrZXkgaXMgZGVmaW5lZCBhcyAiaW50ZXJmYWNlIiwgDQo+d2hp Y2ggSSBiZWxpZXZlIGlzIGEgbmFtZSBvZiB0aGUgaW50ZXJmYWNlLg0KPg0KPkhvdyBkb2VzICJp bnRlcmZhY2UiIG1hcCB0byB0aGUgaW5kaWNlcyBkZWZpbmVkIGluIFJGQ3MgNDc1MCBhbmQgNTY0 Mz8NCj4NCj48dHA+DQo+DQo+SXQgZG9lc24ndCAoSU1ITykuICBZb3UgaGF2ZSB0d28gbGlzdHMg b2YgaW50ZXJmYWNlcyBpbiB0aGlzIEktRA0KPg0KPmNvbnRhaW5lciBpbnRlcmZhY2VzIHsgZGVz Y3JpcHRpb24gIkFsbCBpbnRlcmZhY2VzLiI7IGxpc3QgaW50ZXJmYWNlIHsgDQo+a2V5ICJpbnRl cmZhY2UiOyBkZXNjcmlwdGlvbiAiTGlzdCBvZiBPU1BGIGludGVyZmFjZXMuIjsNCj4NCj5jb250 YWluZXIgaW50ZXJmYWNlcyB7IGRlc2NyaXB0aW9uICJBbGwgaW50ZXJmYWNlcyBpbiB0aGUgYXJl YS4iOyAgbGlzdCANCj5pbnRlcmZhY2UgeyBrZXkgImludGVyZmFjZSI7IGRlc2NyaXB0aW9uICJM aXN0IG9mIE9TUEYgaW50ZXJmYWNlcy4iOw0KPg0KPmJvdGgga2V5ZWQgb24gJ2ludGVyZmFjZScg KHdoaWNoIGlzIHR3byBzZXBhcmF0ZSBsaXN0cyBzbyB0d28gc2VwYXJhdGUgDQo+J2ludGVyZmFj ZScgbGVhZiwgZGlmZmVyZW50IHNldHMgb2Yga2V5IG9iamVjdHMuKS4NCg0KVGhlc2UgYXJlIGJh c2ljYWxseSB0aGUgc2FtZSBsaXN0cyAtIG9uZSBpcyBmb3Igb3BlcmF0aW9uYWwgc3RhdGUgYW5k IHRoZSBvdGhlciBpcyBmb3IgY29uZmlndXJhdGlvbi4NCg0KDQo+DQo+Qm90aCBhcmUgZGVmaW5l ZCBhcw0KPg0KPiAgICAgdHlwZSBpZjppbnRlcmZhY2UtcmVmOw0KPg0KPmFuZCB0aGUgaWY6IGhh cmtzIGJhY2sgdG8NCj4gICAgIGltcG9ydCBpZXRmLWludGVyZmFjZXMge3ByZWZpeCAiaWYiOyBh bmQgaWV0Zi1pbnRlcmZhY2VzIGlzIGluIA0KPlJGQzcyMjMgd2hlcmUgaW50ZXJmYWNlLXJlZiBp cyBkZWZpbmVkIGFzDQo+IiAgIEFuIGludGVyZmFjZSBpcyBpZGVudGlmaWVkIGJ5IGl0cyBuYW1l LCB3aGljaCBpcyB1bmlxdWUgd2l0aGluIHRoZQ0KPiAgIHNlcnZlci4gIFRoaXMgcHJvcGVydHkg aXMgY2FwdHVyZWQgaW4gdGhlICJpbnRlcmZhY2UtcmVmIiBhbmQNCj4gICAiaW50ZXJmYWNlLXN0 YXRlLXJlZiIgdHlwZWRlZnMsIHdoaWNoIG90aGVyIFlBTkcgbW9kdWxlcyBTSE9VTEQgdXNlDQo+ ICAgd2hlbiB0aGV5IG5lZWQgdG8gcmVmZXJlbmNlIGEgY29uZmlndXJlZCBpbnRlcmZhY2Ugb3Ig b3BlcmF0aW9uYWxseQ0KPiAgIHVzZWQgaW50ZXJmYWNlLCByZXNwZWN0aXZlbHkuIg0KPg0KPlNv IGJvdGggbGlzdHMgYXJlIGtleWVkIG9uIGEgbmFtZSB3aGljaCBpcyB1bmlxdWUgd2l0aGluIHRo ZSBzZXJ2ZXIgYW5kIA0KPmNhbiBiZSBhbnl0aGluZywgc3VjaCBhcyAnbGFuMCcgb3IgJ2Zhc3Qt ZXRoZXJuZXQtMjMvNycgb3IgDQo+J2hvdHBsdWcyMy82LzE1JyBvci4uLiBJdCBhbGwgZGVwZW5k czsgbmFtZXMgbWF5IGJlIGRpY3RhdGVkIGJ5IHRoZSANCj5oYXJkd2FyZSB3aXRoIG5vIGNob2lj ZSwgb3IgdGhleSBtYXkgYmUgZGljdGF0ZWQgYnkgdGhlIHNvZnR3YXJlIHRvIA0KPmNvbXBsaWFu dCBoYXJkd2FyZSBvciAuLi4NCj4NCj5VbmRlcmx5aW5nIHRoaXMgaXMgdGhlIHRob3VnaHQgdGhh dCB3ZSBoYXZlIG5vIGdvb2QgZGVmaW5pdGlvbiBvZiBhbiANCj5pbnRlcmZhY2UsIG9uZSB0aGF0 IHdvcmtzIGFjcm9zcyBhbGwgcHJvdG9jb2xzIGFuZCBvdGhlciBhc3BlY3RzIG9mIGEgDQo+Y29u ZmlndXJhdGlvbjsgYW4gaW50ZXJmYWNlIGlzIGxpa2UgYSBibG9iIG9mIGplbGx5IGFuZCBwaW5u aW5nIGl0IGRvd24gDQo+dG8gYmUgYSBuYW1lIGlzIGFib3V0IGFzIGdvb2QgYSBncmFzcCBvZiBp dCBhcyB3ZSB3aWxsIGdldCAoSU1PKS4NCg0KQWdyZWVkLiANCg0KVGhhbmtzLA0KQWNlZSANCg0K DQoNCj4NCj5Ub20gUGV0Y2gNCj4NCj5UaGFua3MNCj5BbGFuDQo+DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5PU1BGIG1haWxpbmcgbGlzdA0KPk9T UEZAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGYN Cg0K From nobody Fri May 13 09:35:27 2016 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 6FB1B12D5D1; Fri, 13 May 2016 09:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqWKDb5NMant; Fri, 13 May 2016 09:35:22 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BB012D5CF; Fri, 13 May 2016 09:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AeROjXF9MaAOoSODsX9MXGnngKiztJNTDk1qA/O9qFI=; b=WgA7IlhVAuSKhwjVmBEdMi5Q8JQpNDdbVUMMiexnZ+qeuxUPMeyog/IEC1nOIB1c5w8aUjDiGdhqxbHNe27U1QqlnklH8EtkLz8d5LHaucI4RuZDIkJZjkcL5vbj1hXbgB2esS25VqAGPUnp7pe7zHZpTxmm5Z52cHPA3Juml4s= Authentication-Results: metaswitch.com; dkim=none (message not signed) header.d=none;metaswitch.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (109.145.193.232) by HE1PR07MB1625.eurprd07.prod.outlook.com (10.166.124.21) with Microsoft SMTP Server (TLS) id 15.1.497.12; Fri, 13 May 2016 16:35:02 +0000 Message-ID: <00ef01d1ad34$e0e406c0$4001a8c0@gateway.2wire.net> From: t.petch To: Alan Davey , "Acee Lindem (acee)" , "Derek Man-Kit Yeung (myeung)" , References: <01f101d1ac75$8fd66a80$4001a8c0@gateway.2wire.net> Date: Fri, 13 May 2016 17:31:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.145.193.232] X-ClientProxiedBy: DB5PR08CA0025.eurprd08.prod.outlook.com (10.163.102.163) To HE1PR07MB1625.eurprd07.prod.outlook.com (10.166.124.21) X-MS-Office365-Filtering-Correlation-Id: 570b4ca4-9617-44dc-f388-08d37b4c88bc X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 2:vyyyfpcd6I1OXzB6dogGt6VcV5X59CLVQPG5I1yktnMPWjYooK+hxWWcX++my3zrUZ3jBsl85eta261j3t+/YVt4YgILmi0+Mn3v5v4Vhpz3OTJ4oeciCirbHe03olZvOlnmkp9kycrnSl1IrNefJly+wZknw+JWs5dP/GRA8vdl5Ph4FJDD7NqRdzNbdwgi; 3:MYIhPnjhUZM0o/PNWTRibShe18K0F3HE4tNsu1HzP+mJ5sKfJ85bufdHdvmdhmvmnJCOwclR4jjJuC80yAIfL38i3uisjQhI75Ez9rVZzvtDzitlMnn02vAqtaz/ooNJ; 25:9zV3PPFsoTWOPSQoJOSvDwFlt+1J+SirJ0XaI/z2H3sjOU/Ln8BoEEX6BuR3MlnLxF1DBZG9F0gdt5Ki1O7JUPnEp7Ur7yG+T60STrBCmfgTIkrZV355IZpgSnWecMsKZSv60GYu80TJq5Thcys/tAx2Cw5OpnfEreBQqaTNVp7/XqkBzGJyeYZJl7IsgrpVe73CqjvSOrsxhEopSu/Wa9rmKBQMgofgjKi41dC7E+rPCU2Af5ygAAxei8XQV7svmN4TuPS51HJuGGWejRNan1Na8F7tCOzuqsML7F4W2JsCEBhEf+3WzevgA6jwMAOXeqEsByhFVeKYE4ub1AhgopkPvN10+aYyoWVsObB/dBlVpEozvOubAiGHBF8y9AhOOq5TgG1Km/iWarFEg0BkxdW4pzUY4Qm8AcM1q4XfoIs= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1625; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR07MB1625; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1625; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 4:lntWaaLSWCFyDrrJ+y/cq8NpAgGLxlzci2JEnE0j+LnZIme0DEzHZTxyn90XuPxJ25BgrPxvkyRQMWLaheYgBf/AM9DM+ynBxcMAIesNs/UXRcyAG9GEjjuBnkTYvwktoWwdCB0f2Veh0sOGUSYv1xLRCwP/7t2iZQqOppavyXaRcL7RVId82kESO2NnEFOXcThtv5mrjFHB++xvLSyJAyrYei0NqP31S4n2vslKfO0bMP1lTBfL254U67JL3ThmfRFjVaGoRAp/h15/S4RlK6pWdzRAr5TSiv29//b6yeHsouVw6JxbTj0XV5zR1pX7tl8FhEccCL6OUZ3gldYc2B/G9LkwALFlxkIf0K9E6rMUKbTO2zh17iUagPqnV4qgqNQcs+tTNKJ8cRY9EPJ/mXrsa3+racz5SEQ435GD8nE= X-Forefront-PRVS: 0941B96580 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(76104003)(24454002)(13464003)(377454003)(345774005)(84392002)(4326007)(62236002)(44716002)(2906002)(33646002)(23676002)(14496001)(19580405001)(19580395003)(50466002)(66066001)(6116002)(5820100001)(93886004)(92566002)(3846002)(77096005)(1456003)(586003)(189998001)(81816999)(76176999)(81166006)(81686999)(50986999)(44736004)(8676002)(5008740100001)(5004730100002)(15975445007)(1556002)(47776003)(86362001)(61296003)(116806002)(230700001)(42186005)(5001770100001)(9686002)(50226002)(230783001)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1625; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIxNjI1OzIzOkFYMlBqUjd0UmlMNi95bU5MSlgvSVJ0OFFk?= =?utf-8?B?NVQ3OTNUd2wyKzJHREQwd2FTWnVGell6aFFPMXdZeHRrZVZLcnA2RVA3Vzho?= =?utf-8?B?Qm8raXFaaUNINkdmY3F6bDVhZTdYeHFiaTRuaXc2VitLTjQzZTNLQ2J3N1Bi?= =?utf-8?B?clFwV2V0STVDQVhXem0ya2ZvOGgySzAveFQ4bE5BUUVWVHpwcnlYZ1Z3ekln?= =?utf-8?B?dWl6UjNpU3pncGcycHRZMmNRcVk5ckQ3dmdSOEhrd1FOc2NRbkhzNDArY3Jq?= =?utf-8?B?TzBCNjZuZmlXTlNiRWYvNlJoNEs5MEJtSGx6RUFmdm0wbnFVME5xKzBML2JV?= =?utf-8?B?VzJIMEQweTBYUzhyR3pIbEJidjFJL1NNajBUc1ZEV294S0JSZ1NaeVRHYlc3?= =?utf-8?B?Rk1IVk5RNittTXYzZWN0VWhCYWorT1NoQnhyTUFnTWxYQTIzelhQckxnY1NL?= =?utf-8?B?cmFFSEpkN1VHZ0RiaXNMUGsrbjJaMG1ZRmRVZFp5ajNrR0ZlUHRaZU1FUEdq?= =?utf-8?B?bVI0Y09YU3F1VXliY0thQlZtdDA4MXhYRE5xZ3JIRUtvVTNncG5Sbkhnalhm?= =?utf-8?B?NzBHK3NmVnhYd3kzeFR2Y2NHNEdBNW54bUJtaVdldG5wbEcxUm1JMldxUzVn?= =?utf-8?B?d090NCtIV0xZcVBnL3FEUHJldmFRTDZaYm9zMXJvQWNFZUZ5ZThSMzZPZXk1?= =?utf-8?B?OEozbmdPWkJBY1d1bXpxcG5IQTRFbFJMZWJ2VkxGd1F3M3BHV1N2bzZIdXRo?= =?utf-8?B?bkhrajl4UWhsaVFET0dDR0svTy90K1M3b3ZSWGNwQVpnbXZrN1JvQm4rdHd2?= =?utf-8?B?RTZ1N25JR3RpUkN6S2FBUXdyS0I1azlzdjhXclhKZlNqb3JpdklFZkVMOGdL?= =?utf-8?B?djlKQ2VLMERYVTFocGYwWG0vTE5Uem52Z0RkQmpFQ281NkxkL3BHVnlCVmdG?= =?utf-8?B?a09qZnY2dlZ2bS9SM1lyRWpld01zOUlwbFpPL05KNkM0ZXhiVjBvQTVGQS9Z?= =?utf-8?B?OTBFbkhnMEFTcTBmM1I3d1B4SUVuR2pxMVZ6N2pKV2FjSU81M0dTVEhoRHZC?= =?utf-8?B?UVl2R3NQUWtPZkdQMnBCQjExS0ZRL0hWbE9iWjRvNEJwSjFWekh2elpHM0Rk?= =?utf-8?B?L01wV3MzOUhuTkUxbGRjZ0VyTW9TdkFPL1BUZ3Z5MzlVeDFlYWlGNy90L254?= =?utf-8?B?ZUl0SEJDOFRsU0VlWGh1U05OQmQ5Y3ZrWFJjdmQ4ZFVyQ3VyZnhCM2dpR1Fl?= =?utf-8?B?V3EwUHRFUU9iMjJkTVFDMHdNVG5oWGswM0h1bTcwMExhV2xkejUzS3l3MmFt?= =?utf-8?B?WDlMTkhxMkNhRGNJN2FLcFVDNzRaM1k4SjlFaThIdnlicC8yREtLVDk5Z01z?= =?utf-8?B?aW5nTENzaFNXNDliK2hkTUVKeWhZNExtK2JVVlFYdzNrbE9nS0lsZXRRMkcw?= =?utf-8?B?alFtU3UrQzhIV0ZsSnh2L3lxRlFHeEJXWUhPNkxyM0pmOFNWUjNjY2dMalAv?= =?utf-8?B?akUyUFVYTjhGSytKK0Z4T1BUNnpTNTA5RGc5aHlFakVia3JpTWJKVmpNV0xk?= =?utf-8?B?U2pTUEdxS01RTEhoT0lKWFpjVWxWVEZTdk9nZEx0SkJRcUIvbVBxZEJLVXl2?= =?utf-8?B?bUMwYXhGYUJpVzNZWnBhY1lHQVhyR1JEUlY0bjRrQmdOL0lOdVVuenNTSVNB?= =?utf-8?B?V2R1ZEt5amQvZWlEOEdoUnlkTXZMRWF4NmFtV1Y3WTd2UUpNSit4ZVY4RFF1?= =?utf-8?B?dmRnaUd1S1BvR2xsaGEzNzNraGZqZDljWnJLUHF5a2hNM3psT2p5MEVZRmhF?= =?utf-8?Q?V25NV9hLYGc2r?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 5:R0qbqO02zBcdeDFWnpkUo0n3R3C3rHkyeJEsdBJwj+dz7xsqjSTWu8nvTLQWhX7oyFb5LOinsV8kZMo/h5FQFN5IinxXrIQVMVkcNKycFWbtgmvGmxPwCrUzgqPX9LH3RPthIUr5bFYLutwpVTaHpQ==; 24:MdImRyv7vl7zgWi16MgsVPZcHGJ68D5eTBCc+6L1ayG9pulxqvBZf7HaKVa1LeUEPZoaF1XkHxT1bIIexzi0wcgGZwYVunKbCeDu2SX7heA=; 7:PegotDc08IvO2rDWcz0fZpRUH6KJxwUKoOqr/hZ9X6hTg0lrpYJHIy8KMzT8pGdGqDuXwLR6i8ZAZU7c6frhcA898CK2GbA7IeZztFJ89W6MRtwQvXhbHh+ikliMHTjNGdV9RcO/ysQbVdlZr/YBg8HkZ6xqJ2/bA64CuSka6Op1OScnni9ETZW3yudiZVSr SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2016 16:35:02.4468 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1625 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 16:35:25 -0000 ----- Original Message ----- From: "Alan Davey" Sent: Friday, May 13, 2016 3:37 PM > Hi Tom and Acee > > Thank you for getting back to me. I understand that an "interface" is identified by its name. My doubt is about how OSPFv2 configuration defined for an "interface" is mapped to an internal OSPFv2 interface object that is indexed on IP address (as per RFC 4750). Perhaps you could let me know what you think. > > In more detail, consider the case where one interface is assigned multiple IP addresses. The OSPFv2 protocol considers these to be separate networks (as per RFC 2328, section 1.2, for example). If the OSPFv2 configuration is defined per interface, is that configuration applied to all of the separate OSPFv2 interfaces or to one of them? If to one of them then how is that one selected? > On your first point, RFC4750 defines the appearance of a box to the outside world, as all MIB modules do; how this is implemented internally is an implementation decision so internally, there may not be the concept of an object let alone one that is keyed on IP address! Equally, a YANG module is a contract between device and NMS; it is the appearance that matters, the internal implementaton can be quite different. YANG requires that interfaces have names but that allows a lot of choice. The YANG OSPF module maps configuration information to an interface, identified by name. The YANG ip module augments the interface with a list of IP addresses. An implementor can choose to have an interface with one IP address, many interfaces each with one address, many with many and so on, may be constrained by the protocols in use. My experience of multiple IPv4 addresses is using them to overcome the limitations of subnet masks with one as primary, the others as secondary; I cannot recall configuring OSPF on more than one, the primary, in which case OSPF configuration would only apply to that. I suspect that multicast considerations would make it impossible to run OSPF over a secondary address but I could be wrong. The YANG modules allow an implementor to treat each IP address as a separate named interface, one address per interface, which would allow each to run OSPF and be configured separately for that. I do not know if anyone will implement this - ask your favourite supplier of hardware:-) This issue, of multiple addresses on an interface, was discussed on the netmod list in 2011/2012. Tom Petch > Regards > Alan > > > -----Original Message----- > From: Acee Lindem (acee) [mailto:acee@cisco.com] > Sent: 13 May 2016 15:02 > To: t.petch ; Alan Davey ; Derek Man-Kit Yeung (myeung) ; draft-ietf-ospf-yang@ietf.org > Cc: OSPF WG List > Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts > > Hi Tom, > > On 5/12/16, 1:41 PM, "OSPF on behalf of t.petch" wrote: > > >----- Original Message ----- > >From: "Alan Davey" > >To: "Derek Man-Kit Yeung (myeung)" ; > > > >Cc: "OSPF WG List" > >Sent: Wednesday, May 11, 2016 5:40 PM > > > >Hi Derek > > > >A question about the key for OSPF interfaces in the Yang draft. Please > >let me know what you think. > > > >The background is that the Management Information Base definitions > >define indices for OSPF interfaces as follows. > > > > > >- For OSPFv2, RFC 4750 defines the index as ospfIfIpAddress, > >ospfAddressLessIf. > > > >- For OSPFv3, RFC 5643 defines the index as ospfv3IfIndex, > >ospfv3IfInstId. > > > >However, in the OSPF Yang draft, the key is defined as "interface", > >which I believe is a name of the interface. > > > >How does "interface" map to the indices defined in RFCs 4750 and 5643? > > > > > > > >It doesn't (IMHO). You have two lists of interfaces in this I-D > > > >container interfaces { description "All interfaces."; list interface { > >key "interface"; description "List of OSPF interfaces."; > > > >container interfaces { description "All interfaces in the area."; list > >interface { key "interface"; description "List of OSPF interfaces."; > > > >both keyed on 'interface' (which is two separate lists so two separate > >'interface' leaf, different sets of key objects.). > > These are basically the same lists - one is for operational state and the other is for configuration. > > > > > >Both are defined as > > > > type if:interface-ref; > > > >and the if: harks back to > > import ietf-interfaces {prefix "if"; and ietf-interfaces is in > >RFC7223 where interface-ref is defined as > >" An interface is identified by its name, which is unique within the > > server. This property is captured in the "interface-ref" and > > "interface-state-ref" typedefs, which other YANG modules SHOULD use > > when they need to reference a configured interface or operationally > > used interface, respectively." > > > >So both lists are keyed on a name which is unique within the server and > >can be anything, such as 'lan0' or 'fast-ethernet-23/7' or > >'hotplug23/6/15' or... It all depends; names may be dictated by the > >hardware with no choice, or they may be dictated by the software to > >compliant hardware or ... > > > >Underlying this is the thought that we have no good definition of an > >interface, one that works across all protocols and other aspects of a > >configuration; an interface is like a blob of jelly and pinning it down > >to be a name is about as good a grasp of it as we will get (IMO). > > Agreed. > > Thanks, > Acee > > > > > > >Tom Petch > > > >Thanks > >Alan > > > >_______________________________________________ > >OSPF mailing list > >OSPF@ietf.org > >https://www.ietf.org/mailman/listinfo/ospf > > From nobody Mon May 16 01:44:38 2016 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 8B77C12D11A; Mon, 16 May 2016 01:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzHAESmSmmny; Mon, 16 May 2016 01:44:35 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E77E12D0E7; Mon, 16 May 2016 01:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+qGIILEuVX3+0UXzAwUcLGqJTpIXa8iAeagL7hRuwM8=; b=J5Is2QynAmGIk0ulzTNN7/3FptLtg4V4J+XclYJu15gBl5COJi2aVe+DaIAaK7Yr2lENgDTk3cBz3Bb7bkgHAYQO0P/pZJyAv25BzvVFCmtL1+jMIchzRIoIZTIUcemlx8AY7u33aVsuxKD5B7G/32qU+2TlWphBy+teohxv9Ug= Received: from BN3PR0201MB1059.namprd02.prod.outlook.com (10.161.209.14) by BN3PR0201MB1060.namprd02.prod.outlook.com (10.161.209.140) with Microsoft SMTP Server (TLS) id 15.1.492.11; Mon, 16 May 2016 08:44:32 +0000 Received: from BN3PR0201MB1059.namprd02.prod.outlook.com ([10.161.209.14]) by BN3PR0201MB1059.namprd02.prod.outlook.com ([10.161.209.14]) with mapi id 15.01.0492.019; Mon, 16 May 2016 08:44:32 +0000 From: Alan Davey To: t.petch , "Acee Lindem (acee)" , "Derek Man-Kit Yeung (myeung)" , "draft-ietf-ospf-yang@ietf.org" Thread-Topic: [OSPF] draft-ietf-ospf-yang-03 questions and doubts Thread-Index: AdE3NLGjjtMGuql0QfiSt+s9ulh9zgoPjYmAAiVQNuADX5obgAcESYLgBoJ48NAANR+BoQAqfv2AAACIaOAABMymEQBcakow Date: Mon, 16 May 2016 08:44:32 +0000 Message-ID: References: <01f101d1ac75$8fd66a80$4001a8c0@gateway.2wire.net> <00ef01d1ad34$e0e406c0$4001a8c0@gateway.2wire.net> In-Reply-To: <00ef01d1ad34$e0e406c0$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [2620:104:4001:72:e993:3f22:b10a:6fb4] x-ms-office365-filtering-correlation-id: b78c675a-231f-45a8-2cb2-08d37d664d7b x-microsoft-exchange-diagnostics: 1; BN3PR0201MB1060; 5:ZFYX5X1TW+2i7q91H5xgKks1BOWNa7EyPl9WBR1aJkZ1Y/Z+aSFwUm6GCGRUXeHWKbfUiqisLxHwZsDDHbEEQXvc1PpxVLku7O1ZPCw/sRba6CkjJpLzV+2L83HJdVVdzb/B8WoMn5GkPNiX7NFKcg==; 24:8bh5UyD0r/RFjvRbxDojv1/O59XHtfEa7pswj054+6oxMHl8jrZpFxvysfebSlB+QB1/c2iTdRtVmtcTJ7rsYdUuWUC+Z4NqtBQ/gamcU9M=; 7:sSmvGPKy/m7BNtkCCerazOhAqTQNs1SPpW6DQ7N64f0e/SVGRaPVcMCe8a+Ot/1Yroxsf90R2/V0ez/25A5Rmc+oEo5U4ambu8ZNSo7D4Pt2lXPn2xiRKo9S0gdhWkjHsMGGcjT98iSnHGAEkv8IeYWRjaWldU2ZhAG43S4rluo003R0oLB4CcQZpYJybhKa x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0201MB1060; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0201MB1060; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB1060; x-forefront-prvs: 09443CAA7E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(76104003)(377454003)(230783001)(74316001)(76576001)(189998001)(50986999)(5003600100002)(5002640100001)(54356999)(76176999)(86362001)(33656002)(19580405001)(19580395003)(99286002)(87936001)(5001770100001)(93886004)(92566002)(3660700001)(8936002)(5004730100002)(4326007)(2501003)(10400500002)(5008740100001)(345774005)(9686002)(77096005)(11100500001)(2906002)(122556002)(102836003)(6116002)(81166006)(8676002)(2900100001)(586003)(15975445007)(2950100001)(3280700002)(1220700001)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB1060; H:BN3PR0201MB1059.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2016 08:44:32.5832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB1060 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 16 May 2016 08:44:37 -0000 SGkgVG9tDQoNClRoYW5rcyBmb3IgeW91ciBxdWljayByZXNwb25zZS4gIEkganVzdCB3YW50IHRv IGNoZWNrIHRoYXQgSSB1bmRlcnN0YW5kIHlvdXIgZW1haWwuICBQbGVhc2UgbGV0IG1lIGtub3cg aWYgdGhlIGZvbGxvd2luZyBpcyBjb3JyZWN0IG9yIG5vdC4NCg0KLSAgWW91IGV4cGVjdCB0aGF0 IHRoZSBOTVMgd291bGQgaWRlbnRpZnkgYW4gaW50ZXJmYWNlIGJ5IG5hbWUgaW4gYWxsIGNhc2Vz IG9mIHByb3RvY29sIGNvbmZpZ3VyYXRpb24sIHdoZXJlIHRoZXJlIGlzIGZsZXhpYmlsaXR5IG9u IHdoYXQgdGhlICJpbnRlcmZhY2UiIHJlcHJlc2VudHMuDQoNCi0gIFRoZXJlIHdpbGwgb25seSBl dmVyIGJlIG9uZSBwcmltYXJ5IElQIGFkZHJlc3MgYXNzaWduZWQgdG8gYW4gaW50ZXJmYWNlIChv ciB6ZXJvIGluIHRoZSBjYXNlIG9mIHVubnVtYmVyZWQgcG9pbnQgdG8gcG9pbnQgaW50ZXJmYWNl cykuDQoNCi0gIFRoZXJlIGlzIGEgc2V0IG9mIHplcm8gb3IgbW9yZSBzZWNvbmRhcnkgSVAgYWRk cmVzc2VzIHRoYXQgbWF5IGJlIGFzc2lnbmVkIHRvIHRoZSBpbnRlcmZhY2UuDQoNCi0gIE9ubHkg dGhlIHByaW1hcnkgYWRkcmVzcyAob3IgdW5udW1iZXJlZCBpbnRlcmZhY2UpIHdvdWxkIGV2ZXIg aGF2ZSBPU1BGIGNvbmZpZ3VyYXRpb24gYXNzb2NpYXRlZCB3aXRoIGl0LiAgU2Vjb25kYXJ5IGFk ZHJlc3NlcyBuZXZlciBoYXZlIE9TUEYgY29uZmlndXJhdGlvbiBhc3NvY2lhdGVkLiAgKEFzIGFu IGFzaWRlLCBtdWx0aWNhc3QgY29uc2lkZXJhdGlvbnMgZG8gbm90IHByZWNsdWRlIHJ1bm5pbmcg T1NQRiB1c2luZyBhIHNlY29uZGFyeSBhZGRyZXNzLikNCg0KLSAgSSBhc3N1bWUgdGhhdCBpbiB0 aGUgY2FzZSBvZiBhIG5vbi1lbXB0eSBzZXQgb2Ygc2Vjb25kYXJ5IGFkZHJlc3NlcywgdGhlIHNl Y29uZGFyeSBhZGRyZXNzZXMgc2hvdWxkIGJlIGFkdmVydGlzZWQgYnkgdGhlIE9TUEYgcHJvdG9j b2wuICBJcyB0aGlzIHRydWU/DQoNClJlZ2FyZHMNCkFsYW4NCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogdC5wZXRjaCBbbWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb21dIA0K U2VudDogMTMgTWF5IDIwMTYgMTc6MzENClRvOiBBbGFuIERhdmV5IDxBbGFuLkRhdmV5QG1ldGFz d2l0Y2guY29tPjsgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT47IERlcmVrIE1h bi1LaXQgWWV1bmcgKG15ZXVuZykgPG15ZXVuZ0BjaXNjby5jb20+OyBkcmFmdC1pZXRmLW9zcGYt eWFuZ0BpZXRmLm9yZw0KQ2M6IE9TUEYgV0cgTGlzdCA8b3NwZkBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbT1NQRl0gZHJhZnQtaWV0Zi1vc3BmLXlhbmctMDMgcXVlc3Rpb25zIGFuZCBkb3VidHMN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkFsYW4gRGF2ZXkiIDxBbGFu LkRhdmV5QG1ldGFzd2l0Y2guY29tPg0KU2VudDogRnJpZGF5LCBNYXkgMTMsIDIwMTYgMzozNyBQ TQ0KDQoNCj4gSGkgVG9tIGFuZCBBY2VlDQo+DQo+IFRoYW5rIHlvdSBmb3IgZ2V0dGluZyBiYWNr IHRvIG1lLiAgSSB1bmRlcnN0YW5kIHRoYXQgYW4gImludGVyZmFjZSIgaXMNCmlkZW50aWZpZWQg YnkgaXRzIG5hbWUuICBNeSBkb3VidCBpcyBhYm91dCBob3cgT1NQRnYyIGNvbmZpZ3VyYXRpb24g ZGVmaW5lZCBmb3IgYW4gImludGVyZmFjZSIgaXMgbWFwcGVkIHRvIGFuIGludGVybmFsIE9TUEZ2 MiBpbnRlcmZhY2Ugb2JqZWN0IHRoYXQgaXMgaW5kZXhlZCBvbiBJUCBhZGRyZXNzIChhcyBwZXIg UkZDIDQ3NTApLiAgUGVyaGFwcyB5b3UgY291bGQgbGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsu DQo+DQo+IEluIG1vcmUgZGV0YWlsLCBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSBvbmUgaW50ZXJm YWNlIGlzIGFzc2lnbmVkDQptdWx0aXBsZSBJUCBhZGRyZXNzZXMuICBUaGUgT1NQRnYyIHByb3Rv Y29sIGNvbnNpZGVycyB0aGVzZSB0byBiZSBzZXBhcmF0ZSBuZXR3b3JrcyAoYXMgcGVyIFJGQyAy MzI4LCBzZWN0aW9uIDEuMiwgZm9yIGV4YW1wbGUpLiAgSWYgdGhlDQpPU1BGdjIgY29uZmlndXJh dGlvbiBpcyBkZWZpbmVkIHBlciBpbnRlcmZhY2UsIGlzIHRoYXQgY29uZmlndXJhdGlvbiBhcHBs aWVkIHRvIGFsbCBvZiB0aGUgc2VwYXJhdGUgT1NQRnYyIGludGVyZmFjZXMgb3IgdG8gb25lIG9m IHRoZW0/ICBJZiB0byBvbmUgb2YgdGhlbSB0aGVuIGhvdyBpcyB0aGF0IG9uZSBzZWxlY3RlZD8N Cj4NCg0KT24geW91ciBmaXJzdCBwb2ludCwgUkZDNDc1MCBkZWZpbmVzIHRoZSBhcHBlYXJhbmNl IG9mIGEgYm94IHRvIHRoZSBvdXRzaWRlIHdvcmxkLCBhcyBhbGwgTUlCIG1vZHVsZXMgZG87IGhv dyB0aGlzIGlzIGltcGxlbWVudGVkIGludGVybmFsbHkgaXMgYW4gaW1wbGVtZW50YXRpb24gZGVj aXNpb24gc28gaW50ZXJuYWxseSwgdGhlcmUgbWF5IG5vdCBiZSB0aGUgY29uY2VwdCBvZiBhbiBv YmplY3QgbGV0IGFsb25lIG9uZSB0aGF0IGlzIGtleWVkIG9uIElQIGFkZHJlc3MhDQpFcXVhbGx5 LCBhIFlBTkcgbW9kdWxlIGlzIGEgY29udHJhY3QgYmV0d2VlbiBkZXZpY2UgYW5kIE5NUzsgaXQg aXMgdGhlIGFwcGVhcmFuY2UgdGhhdCBtYXR0ZXJzLCB0aGUgaW50ZXJuYWwgaW1wbGVtZW50YXRv biBjYW4gYmUgcXVpdGUgZGlmZmVyZW50LiAgWUFORyByZXF1aXJlcyB0aGF0IGludGVyZmFjZXMg aGF2ZSBuYW1lcyBidXQgdGhhdCBhbGxvd3MgYSBsb3Qgb2YgY2hvaWNlLg0KDQpUaGUgWUFORyBP U1BGIG1vZHVsZSBtYXBzIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gdG8gYW4gaW50ZXJmYWNl LCBpZGVudGlmaWVkIGJ5IG5hbWUuICBUaGUgWUFORyBpcCBtb2R1bGUgYXVnbWVudHMgdGhlIGlu dGVyZmFjZSB3aXRoIGEgbGlzdCBvZiBJUCBhZGRyZXNzZXMuICBBbiBpbXBsZW1lbnRvciBjYW4g Y2hvb3NlIHRvIGhhdmUgYW4gaW50ZXJmYWNlIHdpdGggb25lIElQIGFkZHJlc3MsIG1hbnkgaW50 ZXJmYWNlcyBlYWNoIHdpdGggb25lIGFkZHJlc3MsIG1hbnkgd2l0aCBtYW55IGFuZCBzbyBvbiwg bWF5IGJlIGNvbnN0cmFpbmVkIGJ5IHRoZSBwcm90b2NvbHMgaW4gdXNlLg0KDQpNeSBleHBlcmll bmNlIG9mIG11bHRpcGxlIElQdjQgYWRkcmVzc2VzIGlzIHVzaW5nIHRoZW0gdG8gb3ZlcmNvbWUg dGhlIGxpbWl0YXRpb25zIG9mIHN1Ym5ldCBtYXNrcyB3aXRoIG9uZSBhcyBwcmltYXJ5LCB0aGUg b3RoZXJzIGFzIHNlY29uZGFyeTsgSSBjYW5ub3QgcmVjYWxsIGNvbmZpZ3VyaW5nIE9TUEYgb24g bW9yZSB0aGFuIG9uZSwgdGhlIHByaW1hcnksIGluIHdoaWNoIGNhc2UgT1NQRiBjb25maWd1cmF0 aW9uIHdvdWxkIG9ubHkgYXBwbHkgdG8gdGhhdC4gIEkgc3VzcGVjdCB0aGF0IG11bHRpY2FzdCBj b25zaWRlcmF0aW9ucyB3b3VsZCBtYWtlIGl0IGltcG9zc2libGUgdG8gcnVuIE9TUEYgb3ZlciBh IHNlY29uZGFyeSBhZGRyZXNzIGJ1dCBJIGNvdWxkIGJlIHdyb25nLg0KDQpUaGUgWUFORyBtb2R1 bGVzIGFsbG93IGFuIGltcGxlbWVudG9yIHRvIHRyZWF0IGVhY2ggSVAgYWRkcmVzcyBhcyBhIHNl cGFyYXRlIG5hbWVkIGludGVyZmFjZSwgb25lIGFkZHJlc3MgcGVyIGludGVyZmFjZSwgd2hpY2gg d291bGQgYWxsb3cgZWFjaCB0byBydW4gT1NQRiBhbmQgYmUgY29uZmlndXJlZCBzZXBhcmF0ZWx5 IGZvciB0aGF0LiAgSSBkbyBub3Qga25vdyBpZiBhbnlvbmUgd2lsbCBpbXBsZW1lbnQgdGhpcyAt IGFzayB5b3VyIGZhdm91cml0ZSBzdXBwbGllciBvZg0KaGFyZHdhcmU6LSkNCg0KVGhpcyBpc3N1 ZSwgb2YgbXVsdGlwbGUgYWRkcmVzc2VzIG9uIGFuIGludGVyZmFjZSwgd2FzIGRpc2N1c3NlZCBv biB0aGUgbmV0bW9kIGxpc3QgaW4gMjAxMS8yMDEyLg0KDQpUb20gUGV0Y2gNCg0KPiBSZWdhcmRz DQo+IEFsYW4NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWNl ZSBMaW5kZW0gKGFjZWUpIFttYWlsdG86YWNlZUBjaXNjby5jb21dDQo+IFNlbnQ6IDEzIE1heSAy MDE2IDE1OjAyDQo+IFRvOiB0LnBldGNoIDxpZXRmY0BidGNvbm5lY3QuY29tPjsgQWxhbiBEYXZl eQ0KPEFsYW4uRGF2ZXlAbWV0YXN3aXRjaC5jb20+OyBEZXJlayBNYW4tS2l0IFlldW5nIChteWV1 bmcpIDxteWV1bmdAY2lzY28uY29tPjsgZHJhZnQtaWV0Zi1vc3BmLXlhbmdAaWV0Zi5vcmcNCj4g Q2M6IE9TUEYgV0cgTGlzdCA8b3NwZkBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtPU1BGXSBk cmFmdC1pZXRmLW9zcGYteWFuZy0wMyBxdWVzdGlvbnMgYW5kIGRvdWJ0cw0KPg0KPiBIaSBUb20s DQo+DQo+IE9uIDUvMTIvMTYsIDE6NDEgUE0sICJPU1BGIG9uIGJlaGFsZiBvZiB0LnBldGNoIg0K PG9zcGYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaWV0ZmNAYnRjb25uZWN0LmNvbT4g d3JvdGU6DQo+DQo+ID4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID5Gcm9tOiAiQWxh biBEYXZleSIgPEFsYW4uRGF2ZXlAbWV0YXN3aXRjaC5jb20+DQo+ID5UbzogIkRlcmVrIE1hbi1L aXQgWWV1bmcgKG15ZXVuZykiIDxteWV1bmdAY2lzY28uY29tPjsgDQo+ID48ZHJhZnQtaWV0Zi1v c3BmLXlhbmdAaWV0Zi5vcmc+DQo+ID5DYzogIk9TUEYgV0cgTGlzdCIgPG9zcGZAaWV0Zi5vcmc+ DQo+ID5TZW50OiBXZWRuZXNkYXksIE1heSAxMSwgMjAxNiA1OjQwIFBNDQo+ID4NCj4gPkhpIERl cmVrDQo+ID4NCj4gPkEgcXVlc3Rpb24gYWJvdXQgdGhlIGtleSBmb3IgT1NQRiBpbnRlcmZhY2Vz IGluIHRoZSBZYW5nIGRyYWZ0Lg0KUGxlYXNlDQo+ID5sZXQgbWUga25vdyB3aGF0IHlvdSB0aGlu ay4NCj4gPg0KPiA+VGhlIGJhY2tncm91bmQgaXMgdGhhdCB0aGUgTWFuYWdlbWVudCBJbmZvcm1h dGlvbiBCYXNlIGRlZmluaXRpb25zIA0KPiA+ZGVmaW5lIGluZGljZXMgZm9yIE9TUEYgaW50ZXJm YWNlcyBhcyBmb2xsb3dzLg0KPiA+DQo+ID4NCj4gPi0gICAgICAgICAgRm9yIE9TUEZ2MiwgUkZD IDQ3NTAgZGVmaW5lcyB0aGUgaW5kZXggYXMgb3NwZklmSXBBZGRyZXNzLA0KPiA+b3NwZkFkZHJl c3NMZXNzSWYuDQo+ID4NCj4gPi0gICAgICAgICAgRm9yIE9TUEZ2MywgUkZDIDU2NDMgZGVmaW5l cyB0aGUgaW5kZXggYXMgb3NwZnYzSWZJbmRleCwNCj4gPm9zcGZ2M0lmSW5zdElkLg0KPiA+DQo+ ID5Ib3dldmVyLCBpbiB0aGUgT1NQRiBZYW5nIGRyYWZ0LCB0aGUga2V5IGlzIGRlZmluZWQgYXMg ImludGVyZmFjZSIsIA0KPiA+d2hpY2ggSSBiZWxpZXZlIGlzIGEgbmFtZSBvZiB0aGUgaW50ZXJm YWNlLg0KPiA+DQo+ID5Ib3cgZG9lcyAiaW50ZXJmYWNlIiBtYXAgdG8gdGhlIGluZGljZXMgZGVm aW5lZCBpbiBSRkNzIDQ3NTAgYW5kDQo1NjQzPw0KPiA+DQo+ID48dHA+DQo+ID4NCj4gPkl0IGRv ZXNuJ3QgKElNSE8pLiAgWW91IGhhdmUgdHdvIGxpc3RzIG9mIGludGVyZmFjZXMgaW4gdGhpcyBJ LUQNCj4gPg0KPiA+Y29udGFpbmVyIGludGVyZmFjZXMgeyBkZXNjcmlwdGlvbiAiQWxsIGludGVy ZmFjZXMuIjsgbGlzdCBpbnRlcmZhY2UNCnsNCj4gPmtleSAiaW50ZXJmYWNlIjsgZGVzY3JpcHRp b24gIkxpc3Qgb2YgT1NQRiBpbnRlcmZhY2VzLiI7DQo+ID4NCj4gPmNvbnRhaW5lciBpbnRlcmZh Y2VzIHsgZGVzY3JpcHRpb24gIkFsbCBpbnRlcmZhY2VzIGluIHRoZSBhcmVhLiI7DQpsaXN0DQo+ ID5pbnRlcmZhY2UgeyBrZXkgImludGVyZmFjZSI7IGRlc2NyaXB0aW9uICJMaXN0IG9mIE9TUEYg aW50ZXJmYWNlcy4iOw0KPiA+DQo+ID5ib3RoIGtleWVkIG9uICdpbnRlcmZhY2UnICh3aGljaCBp cyB0d28gc2VwYXJhdGUgbGlzdHMgc28gdHdvDQpzZXBhcmF0ZQ0KPiA+J2ludGVyZmFjZScgbGVh ZiwgZGlmZmVyZW50IHNldHMgb2Yga2V5IG9iamVjdHMuKS4NCj4NCj4gVGhlc2UgYXJlIGJhc2lj YWxseSB0aGUgc2FtZSBsaXN0cyAtIG9uZSBpcyBmb3Igb3BlcmF0aW9uYWwgc3RhdGUgYW5kDQp0 aGUgb3RoZXIgaXMgZm9yIGNvbmZpZ3VyYXRpb24uDQo+DQo+DQo+ID4NCj4gPkJvdGggYXJlIGRl ZmluZWQgYXMNCj4gPg0KPiA+ICAgICB0eXBlIGlmOmludGVyZmFjZS1yZWY7DQo+ID4NCj4gPmFu ZCB0aGUgaWY6IGhhcmtzIGJhY2sgdG8NCj4gPiAgICAgaW1wb3J0IGlldGYtaW50ZXJmYWNlcyB7 cHJlZml4ICJpZiI7IGFuZCBpZXRmLWludGVyZmFjZXMgaXMgaW4NCj4gPlJGQzcyMjMgd2hlcmUg aW50ZXJmYWNlLXJlZiBpcyBkZWZpbmVkIGFzDQo+ID4iICAgQW4gaW50ZXJmYWNlIGlzIGlkZW50 aWZpZWQgYnkgaXRzIG5hbWUsIHdoaWNoIGlzIHVuaXF1ZSB3aXRoaW4NCnRoZQ0KPiA+ICAgc2Vy dmVyLiAgVGhpcyBwcm9wZXJ0eSBpcyBjYXB0dXJlZCBpbiB0aGUgImludGVyZmFjZS1yZWYiIGFu ZA0KPiA+ICAgImludGVyZmFjZS1zdGF0ZS1yZWYiIHR5cGVkZWZzLCB3aGljaCBvdGhlciBZQU5H IG1vZHVsZXMgU0hPVUxEDQp1c2UNCj4gPiAgIHdoZW4gdGhleSBuZWVkIHRvIHJlZmVyZW5jZSBh IGNvbmZpZ3VyZWQgaW50ZXJmYWNlIG9yDQpvcGVyYXRpb25hbGx5DQo+ID4gICB1c2VkIGludGVy ZmFjZSwgcmVzcGVjdGl2ZWx5LiINCj4gPg0KPiA+U28gYm90aCBsaXN0cyBhcmUga2V5ZWQgb24g YSBuYW1lIHdoaWNoIGlzIHVuaXF1ZSB3aXRoaW4gdGhlIHNlcnZlcg0KYW5kDQo+ID5jYW4gYmUg YW55dGhpbmcsIHN1Y2ggYXMgJ2xhbjAnIG9yICdmYXN0LWV0aGVybmV0LTIzLzcnIG9yIA0KPiA+ J2hvdHBsdWcyMy82LzE1JyBvci4uLiBJdCBhbGwgZGVwZW5kczsgbmFtZXMgbWF5IGJlIGRpY3Rh dGVkIGJ5IHRoZSANCj4gPmhhcmR3YXJlIHdpdGggbm8gY2hvaWNlLCBvciB0aGV5IG1heSBiZSBk aWN0YXRlZCBieSB0aGUgc29mdHdhcmUgdG8gDQo+ID5jb21wbGlhbnQgaGFyZHdhcmUgb3IgLi4u DQo+ID4NCj4gPlVuZGVybHlpbmcgdGhpcyBpcyB0aGUgdGhvdWdodCB0aGF0IHdlIGhhdmUgbm8g Z29vZCBkZWZpbml0aW9uIG9mIGFuIA0KPiA+aW50ZXJmYWNlLCBvbmUgdGhhdCB3b3JrcyBhY3Jv c3MgYWxsIHByb3RvY29scyBhbmQgb3RoZXIgYXNwZWN0cyBvZiBhIA0KPiA+Y29uZmlndXJhdGlv bjsgYW4gaW50ZXJmYWNlIGlzIGxpa2UgYSBibG9iIG9mIGplbGx5IGFuZCBwaW5uaW5nIGl0DQpk b3duDQo+ID50byBiZSBhIG5hbWUgaXMgYWJvdXQgYXMgZ29vZCBhIGdyYXNwIG9mIGl0IGFzIHdl IHdpbGwgZ2V0IChJTU8pLg0KPg0KPiBBZ3JlZWQuDQo+DQo+IFRoYW5rcywNCj4gQWNlZQ0KPg0K Pg0KPg0KPiA+DQo+ID5Ub20gUGV0Y2gNCj4gPg0KPiA+VGhhbmtzDQo+ID5BbGFuDQo+ID4NCj4g Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID5PU1BG IG1haWxpbmcgbGlzdA0KPiA+T1NQRkBpZXRmLm9yZw0KPiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vc3BmDQo+DQo+DQoNCg== From nobody Tue May 17 02:51:35 2016 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 25AAC12D0AC; Tue, 17 May 2016 02:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ci1VYJEsELB; Tue, 17 May 2016 02:51:31 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E01C12B030; Tue, 17 May 2016 02:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aW9EUOSiSqnTptDGDIC1Fmu5mVfxWp6ORFQjR8ncvP4=; b=Oh+ER7mhrmkaWrq6ePglGMBcv0lhfnvqRlRPHlddNVnxmyin+kcxgYN/g7eINdf7c4U+k+PP2Kq2ERr4VCW73JMrr2i4mtsMdAkTU5UKtUG4IqTF4QsC6iHu2AgkA/QMuVsL68hmZxMjDgbflOGfFPjW3TJTDrWA9tISWyfrBx8= Authentication-Results: metaswitch.com; dkim=none (message not signed) header.d=none;metaswitch.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (109.145.193.232) by VI1PR07MB1632.eurprd07.prod.outlook.com (10.166.142.150) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 17 May 2016 09:51:07 +0000 Message-ID: <01c201d1b021$1b09ee20$4001a8c0@gateway.2wire.net> From: t.petch To: Alan Davey , "Acee Lindem (acee)" , "Derek Man-Kit Yeung (myeung)" , References: <01f101d1ac75$8fd66a80$4001a8c0@gateway.2wire.net> <00ef01d1ad34$e0e406c0$4001a8c0@gateway.2wire.net> Date: Tue, 17 May 2016 10:42:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.145.193.232] X-ClientProxiedBy: VI1PR0101CA0018.eurprd01.prod.exchangelabs.com (10.166.38.28) To VI1PR07MB1632.eurprd07.prod.outlook.com (10.166.142.150) X-MS-Office365-Filtering-Correlation-Id: 089d8321-8b3c-4569-ad27-08d37e38c52c X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 2:ywyGaR8WorpL5HEtrnCjYKd4bzKfL8K9HihJmo8IM8xOKO/CnojAJW6TgKF4UDEf243a9xBfgEUHgLUKJ9uongf7lFECp/ZhkLjhNLJFihnKcpq8O7uQ5DI8Ue4aTj7HIaubiyhef7WmETyrlHs7T8Vj77tfzSZ/QO8oVo/baD/5x6TftAahFcgjh7I3DqMq; 3:wfxbUPezHFEGJEw4/WEpcr5ss+zaWjdYpl7XFR0aXRL796UgtOoY606hpBxyfG3WYY66WGKluShK9plRGwLwI4/e+mhFK0FHUeQ/UmOAUyL6gP8BZM1A8YrsibZfdzYp X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1632; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 25:p7H/Ujqr6fLhQTemnx/FBh1TDbkgfOe+inTohjc6JmlvPsePdTNdnZ/4N6ylE0+vIl8Npkl69+koqVLZpwKneM9I6Ju9QCwi7IGs4Urw70MP1S9udl0i6wuF50ibxv+Dgs0tQUcqczeZu7+4Ls7ADR9Y4niVyP5Udt+El4wIqnBPQj5cZEdu3HNxDtq9oWjczbMZdgWl8DikX9LCV2T8xxw45iqOQzCGfQPssfMHi98vFhqdNYVAGfA1styJ/v8e0+CyhtoiGJm2PYrgO1tuxqs7NgbEf0XieFvC74Jj34ijvMjkLtsyNDeo6aXdrPDH4yVKiCpXdS/dXFFQqWEY/6WeYSwjPROBfEhvsZRQH1Nn5Xmf6Iwz//tcndDxuJZfvp+eg3Ng+rVmnKrIkiAQy4qwE+vKZYtTLvFYWCpOq6hgWLmA/9Wk4gCuG4QGR/Tf146W7dLn+iZZp5IyW0+Ot2J5SOyBlWdw+NFdMW5SRFC5FKF8C3jzYpKgC1WbFeK4KdLF7zq1s9pIreLP543mjxTkt3BCpHw2kMz8wA6qJrBm3OMchptQK8UAXzJ3BL/cdqdnmJ50f3/dSkwXuP9rLbejGqlNSZyaADjPrQqdFNnProZkjVDlZkf4fXhP3aZGLYavoVqvyfhdGiHaiHUP8aT/Zu8mDvE/gyT0Gz8TE9M+eJMyn3Q1fFcep5Aaegeh2o6HPgnzRlHxVuxz7Q+ay+MS7H+/RARtyCvtPvyAwo0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR07MB1632; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1632; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 4:qQFIR8T2nRtj6Nj0fz7LSvkE/ib8li/iML+8m7OQHna1gyPDdwMDpLEUlZ7bso3XpEawoOlabOwm6PLSO+PUY0bUBfevgsNoagTYVixiZ+fe3lS5cAu8dIC+Kiko+fis6BBdSb6Eh3rzwou7rg8TL/72oPbzHujxo8ZXto77NsRcoqChYJJFTAS9BAql/U/h4kCsu7eINrIqDRj7ingCxdcv2x8Uk3E8V7QA3JGl8Tlt+b2puBd6ZDn6RTrBnxNOkaw0g+vHrjL8jH+wJsiz9+kJmMsj4hILsSvQcpxR9FS9eDW1rJ4qJa84Eu3YuoXOJVfSFV33bqLdYjBzsqKIgxg4YLMaye70kbt6Ug3aU4GPG3Lcift5bavzupBBqMEUC8kAeu7shqaDDwMqrwWd8eEnx3xtnNYhmX0kDkTuL0A= X-Forefront-PRVS: 0945B0CC72 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(377454003)(13464003)(230700001)(84392002)(4326007)(76176999)(50986999)(81686999)(81166006)(2906002)(47776003)(61296003)(66066001)(5001770100001)(5004730100002)(189998001)(93886004)(62236002)(44716002)(5008740100001)(86362001)(77096005)(42186005)(586003)(3846002)(6116002)(23676002)(9686002)(8676002)(50226002)(19580405001)(33646002)(19580395003)(92566002)(50466002)(230783001)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1632; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIxNjMyOzIzOlE1QUR2dWpyUDNxVk5xMEt6VE9XdS9mSFBK?= =?utf-8?B?NnlaUzF2RkgyRGNNaXNEVVJ2ZzFVdWkxZi8vRFNMK2NlSlhkN24rTk9GZUND?= =?utf-8?B?NmJJRFVPdndvcmtCbFZhamdYcnJKNktIakViTkJPYncxekxRMHF0ZzkwQWJJ?= =?utf-8?B?TFBmOGdRTFRTdEpKVUFvdmRFYm16bnBEb1hhUXkzTGF5ZFM5cWxtb3ZleFh0?= =?utf-8?B?MC9qRVNyMmh2TVVqbXE0THZ5RVhoaDhad29kQnFiMkppcWlxbm8xSm9qM1Zl?= =?utf-8?B?cGhMK0xXc3REeUo4V0lzSm5LSE02NjhFVFBwNVowM3NDbVBLc0xmVkFwNnBu?= =?utf-8?B?ZGJmbi9WbzlzaW9DK2tXUlVOYkdpT1AvUmRSN2dqVEg5djk0RHoyUDY1THp0?= =?utf-8?B?YmJqcEs1OUsyazRtTWEvVDgvZWdIV28zSk9RbHUvMjBxRmloWktPdjljaWdN?= =?utf-8?B?dm9sNDRpcUQzVWhUUnVlWmpNc1ROSUxleFZoUW9nbDBCVGF6MW0zUHhyTmpJ?= =?utf-8?B?eDNnSWxZT1p2NW13Ynh6TkpuN3hxblVqNmZ6TlNoRmNBZ2pYaXlxaU13OWFG?= =?utf-8?B?QUFTTFo4WnB5M0FpemlZRGxSZlpKR25qVUNzSHZTQmpwcGZXbGJmeGlmL09u?= =?utf-8?B?QnhEWXA1OUx1T1crbURINHkvdlRrU1VXOG9nY2Q1MEZNQThxSGJZUloybGRH?= =?utf-8?B?YjF6L0JQcjVyM21lajBNcmI1SVEvc1dzQllISXhWL3FVbEdsdjZvU3g4ZGxt?= =?utf-8?B?ZmRmbzcwbll0UHZhRUlqclIvaVYxb2Z3ZmJVOVFjMlQxbE1ET1hjUjY1Z1Ba?= =?utf-8?B?UlMwbVFCM2VZeW9YcUFwL3N3MzhRdDFIUUtHZ2pXR2R1bDFUcnRTUi9HSWQr?= =?utf-8?B?V3p6K28xY0RDS2tHUzZGK0gxNW0wNW5lREc4Qkh1VG15MXlBdkpwMUYreXRK?= =?utf-8?B?TUZUSW03ZnlwV3FtUHY0QXVmS1NxTkZtd0FmWi91N28zWHJ6bTA5c3VGRUNj?= =?utf-8?B?OFN3Q3A1S2t0Z09KWHVLNGdXVzZvWVJFU0dwZzE0eHBHZHIzWEN3Rm1ER2lo?= =?utf-8?B?NU81UXQzUWQ5ZTZORno0aXY5WnVTemNuOWphL0VGYjF3N3h6dk1YSDV6MmNv?= =?utf-8?B?OVZxN2ZOU1pWZUpweFR2Y1hJSE8rY241alF5SDRURXhNbTF2cjVVeTVxK2p2?= =?utf-8?B?eVZrSlZuWlJTK3pSTVpjNVdCVWc2bGNKM1oyOUJCV2g2UEtEYkNIbXdRWTg1?= =?utf-8?B?Nmg3QkJBNndtbmFFWGk3eldFLy9vdDUyWnhKZnF3aDNkcDZBdk5OaXZsSzMz?= =?utf-8?B?UXBwR2tBWkdFK1NNTWlJUWNWRXFkNS9YbTc5czduM3BKUG54L0JmbHRMUjZo?= =?utf-8?B?WUdPNXRuVzhxSHFPV0pPTnozbURWRnFqNEhRRjZaSVh2a3hLWFdMUkpkTmlX?= =?utf-8?Q?kp+eL999ucLFfZFhHHy5n7P2Qcn?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 5:RlzbMWN4FkJ1IbxbTxXF2fyxp9GvHZfZQCY25VAFOC1AyQLShV8Ev889XkUjuwZhGmADEIO5mY1T77/VaUW70zUpxY3qTzi970nPk86x/gRbEndD0X4sBztMdvb2vN0vZyQc/BjXwopg/XbX7l70Ow==; 24:zJkrs3zue79hubOATwlr7kTIv2PxHBn11+om1xyrQTBkkt0qMHhL3Gl04heE1vvdTyOzzjHy5At1SA0aU45LkU1OCiGPWrtjxe8yJS5sS9Q=; 7:iT/bBdsxJmapZH+MmOB8eVeUGYeFx6oRkJKh11EpsT8Q/YOx+DMBNQepieNiyUNz4HBrha3B5fW9hZBkpgMX2iUJdw6tzWBkZVgSE7ayHPQ7dVWEKocY3yVkfVhNl+/V7Ok0Jpt1wLOJly89Tk/r4npOzxjd2cgLdaWdQWMrxdlBeUHZGF496TkwmxwgXw22 SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2016 09:51:07.7242 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1632 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 09:51:33 -0000 ----- Original Message ----- From: "Alan Davey" To: "t.petch" ; "Acee Lindem (acee)" ; "Derek Man-Kit Yeung (myeung)" ; Cc: "OSPF WG List" Sent: Monday, May 16, 2016 9:44 AM > Hi Tom > > Thanks for your quick response. I just want to check that I understand your email. Please let me know if the following is correct or not. > > - You expect that the NMS would identify an interface by name in all cases of protocol configuration, where there is flexibility on what the "interface" represents. > > - There will only ever be one primary IP address assigned to an interface (or zero in the case of unnumbered point to point interfaces). > > - There is a set of zero or more secondary IP addresses that may be assigned to the interface. > > - Only the primary address (or unnumbered interface) would ever have OSPF configuration associated with it. Secondary addresses never have OSPF configuration associated. (As an aside, multicast considerations do not preclude running OSPF using a secondary address.) > > - I assume that in the case of a non-empty set of secondary addresses, the secondary addresses should be advertised by the OSPF protocol. Is this true? My context is IPv4 (despite my erroneous reference to multicast:-); with IPv6, interfaces are expected to have multiple IP addresses and so applications must be prepared for that. With IPv4, the concept came late in the day which is why I am uncertain about how much support there is thereof. Using a NMS with NETCONF and the IETF YANG models, then the protocol/DDL identifies the interface, whatever that may be, physical, logical (FR VC, MPLS LSP, ...) by name; the YANG list is keyed by 'name' which is a change in approach from that of the MIB module. How the NMS presents that to the user is up to the NMS (it could be - I don't know - that an NMS chooses to use IPv4 addresses because that is what users are familiar with). Secondary addresses I saw first with one router manufacturer and then later with others; I would expect most to support them. The implementations I have seen have only one primary. I have always seen secondary addresses as an unsatisfactory solution to addressing issues and while they were needed at the time, I would like to think that their use has diminished since. I would look askance at a design that uses them in this day and age. Doubtless they are still around but how widespread they are, I don't know. (I was active in getting them included in the YANG model which I do not think that all those involved were). The configuration of OSPF may have an option to advertise or to suppress the advertisement of secondary addresses in the LSA. Whether or not a secondary address can be used for other purposes in OSPF, such as DR or BDR, I am unsure; something at the back of my mind says there is an issue with the use of broadcast by a DR but I cannot track down a reference to that. With the proposed YANG models - if-cfg, ip-cfg, ospf - it is feasible to configure a secondary interface in the same way as a primary one, should the device support that. Tom Petch > Regards > Alan > > > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: 13 May 2016 17:31 From nobody Tue May 17 05:04:09 2016 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 D736E12D881; Tue, 17 May 2016 05:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDN2fRMVq8FL; Tue, 17 May 2016 05:04:06 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEB512D150; Tue, 17 May 2016 05:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5296; q=dns/txt; s=iport; t=1463486645; x=1464696245; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kXjuKVGMpF4/UzhHxStXKkDY4FqVQojm9OL+PLFMuMY=; b=D7E3r1PNp8vkS29aBAQfwpTE6BgHgyBqA514KtDonRKopP26d7E3JKh+ TMd+YHZ4qgrS11QF9XfADRQgroe1GbJUIvSLLtneN14Ey8+p3VS2+0Vbo n2PDx09My07P06iJ6GBaaxnD6qyp0DXvfnyjX7+tGwBh6F13prrZwb78+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBBAAtCDtX/4kNJK1SCoM3gQNQBrdeg?= =?us-ascii?q?g8BDYF2hhECHIEZOBQBAQEBAQEBZSeEQgEBAQQjEUUMBAIBCBUBBAIjAwICAjA?= =?us-ascii?q?UARACBAENBRuIFLF4kXEBAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQGJcYQRBgsBH?= =?us-ascii?q?AczgkaCWQEEiAOFXIpKAY4egWmET4hhj0EBHgEBQoIGG4FLboZRNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="274582722" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2016 12:04:04 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4HC44u7026887 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 12:04:04 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 08:04:03 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Tue, 17 May 2016 08:04:03 -0400 From: "Acee Lindem (acee)" To: "t.petch" , Alan Davey , "Derek Man-Kit Yeung (myeung)" , "draft-ietf-ospf-yang@ietf.org" Thread-Topic: [OSPF] draft-ietf-ospf-yang-03 questions and doubts Thread-Index: AQHRrHYn2XZTM8Zh7Ea9M+xWxcvHEgoPjYmAAiVQNuADX5obgAcESYLgBoJ48NAANR+BoQAqfv2AAACIaOAABMymEQBcakowns4FoA+AACMagA== Date: Tue, 17 May 2016 12:04:03 +0000 Message-ID: References: <01f101d1ac75$8fd66a80$4001a8c0@gateway.2wire.net> <00ef01d1ad34$e0e406c0$4001a8c0@gateway.2wire.net> <01c201d1b021$1b09ee20$4001a8c0@gateway.2wire.net> In-Reply-To: <01c201d1b021$1b09ee20$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 12:04:08 -0000 PFNwZWFraW5nIGFzIGEgbWVtYmVyIG9mIHRoZSBPU1BGIFlBTkcgRGVzaWduIFRlYW0+DQpXaGF0 IHdlIGRpZCB3aXRoIHRoZSBPU1BGIFlBTkcgbW9kZWwgd2FzIHVzZSBpbnRlcmZhY2UgYXMgdGhl IGtleSB0byBsaXN0DQpldmVuIHRob3VnaCBPU1BGdjIgYWxsb3dzIGNvbmZpZ3VyYXRpb24gYnkg SVAgc3VibmV0LiBUaGlzIGlzIGNvbnNpc3RlbnQNCndpdGggYm90aCBPU1BGdjMgYW5kIHRoZSBp bnRlcmZhY2UgWUFORyBtb2RlbHMgaW4gUkZDIDcyMjMgYW5kIFJGQyA3Mjc3Lg0KDQpUaGFua3Ms DQpBY2VlDQoNCk9uIDUvMTcvMTYsIDU6NDIgQU0sICJ0LnBldGNoIiA8aWV0ZmNAYnRjb25uZWN0 LmNvbT4gd3JvdGU6DQoNCj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+RnJvbTogIkFs YW4gRGF2ZXkiIDxBbGFuLkRhdmV5QG1ldGFzd2l0Y2guY29tPg0KPlRvOiAidC5wZXRjaCIgPGll dGZjQGJ0Y29ubmVjdC5jb20+OyAiQWNlZSBMaW5kZW0gKGFjZWUpIg0KPjxhY2VlQGNpc2NvLmNv bT47ICJEZXJlayBNYW4tS2l0IFlldW5nIChteWV1bmcpIiA8bXlldW5nQGNpc2NvLmNvbT47DQo+ PGRyYWZ0LWlldGYtb3NwZi15YW5nQGlldGYub3JnPg0KPkNjOiAiT1NQRiBXRyBMaXN0IiA8b3Nw ZkBpZXRmLm9yZz4NCj5TZW50OiBNb25kYXksIE1heSAxNiwgMjAxNiA5OjQ0IEFNDQo+DQo+PiBI aSBUb20NCj4+DQo+PiBUaGFua3MgZm9yIHlvdXIgcXVpY2sgcmVzcG9uc2UuICBJIGp1c3Qgd2Fu dCB0byBjaGVjayB0aGF0IEkNCj51bmRlcnN0YW5kIHlvdXIgZW1haWwuICBQbGVhc2UgbGV0IG1l IGtub3cgaWYgdGhlIGZvbGxvd2luZyBpcyBjb3JyZWN0DQo+b3Igbm90Lg0KPj4NCj4+IC0gIFlv dSBleHBlY3QgdGhhdCB0aGUgTk1TIHdvdWxkIGlkZW50aWZ5IGFuIGludGVyZmFjZSBieSBuYW1l IGluIGFsbA0KPmNhc2VzIG9mIHByb3RvY29sIGNvbmZpZ3VyYXRpb24sIHdoZXJlIHRoZXJlIGlz IGZsZXhpYmlsaXR5IG9uIHdoYXQgdGhlDQo+ImludGVyZmFjZSIgcmVwcmVzZW50cy4NCj4+DQo+ PiAtICBUaGVyZSB3aWxsIG9ubHkgZXZlciBiZSBvbmUgcHJpbWFyeSBJUCBhZGRyZXNzIGFzc2ln bmVkIHRvIGFuDQo+aW50ZXJmYWNlIChvciB6ZXJvIGluIHRoZSBjYXNlIG9mIHVubnVtYmVyZWQg cG9pbnQgdG8gcG9pbnQgaW50ZXJmYWNlcykuDQo+Pg0KPj4gLSAgVGhlcmUgaXMgYSBzZXQgb2Yg emVybyBvciBtb3JlIHNlY29uZGFyeSBJUCBhZGRyZXNzZXMgdGhhdCBtYXkgYmUNCj5hc3NpZ25l ZCB0byB0aGUgaW50ZXJmYWNlLg0KPj4NCj4+IC0gIE9ubHkgdGhlIHByaW1hcnkgYWRkcmVzcyAo b3IgdW5udW1iZXJlZCBpbnRlcmZhY2UpIHdvdWxkIGV2ZXIgaGF2ZQ0KPk9TUEYgY29uZmlndXJh dGlvbiBhc3NvY2lhdGVkIHdpdGggaXQuICBTZWNvbmRhcnkgYWRkcmVzc2VzIG5ldmVyIGhhdmUN Cj5PU1BGIGNvbmZpZ3VyYXRpb24gYXNzb2NpYXRlZC4gIChBcyBhbiBhc2lkZSwgbXVsdGljYXN0 IGNvbnNpZGVyYXRpb25zDQo+ZG8gbm90IHByZWNsdWRlIHJ1bm5pbmcgT1NQRiB1c2luZyBhIHNl Y29uZGFyeSBhZGRyZXNzLikNCj4+DQo+PiAtICBJIGFzc3VtZSB0aGF0IGluIHRoZSBjYXNlIG9m IGEgbm9uLWVtcHR5IHNldCBvZiBzZWNvbmRhcnkNCj5hZGRyZXNzZXMsIHRoZSBzZWNvbmRhcnkg YWRkcmVzc2VzIHNob3VsZCBiZSBhZHZlcnRpc2VkIGJ5IHRoZSBPU1BGDQo+cHJvdG9jb2wuICBJ cyB0aGlzIHRydWU/DQo+DQo+TXkgY29udGV4dCBpcyBJUHY0IChkZXNwaXRlIG15IGVycm9uZW91 cyByZWZlcmVuY2UgdG8gbXVsdGljYXN0Oi0pOyB3aXRoDQo+SVB2NiwgaW50ZXJmYWNlcyBhcmUg ZXhwZWN0ZWQgdG8gaGF2ZSBtdWx0aXBsZSBJUCBhZGRyZXNzZXMgYW5kIHNvDQo+YXBwbGljYXRp b25zIG11c3QgYmUgcHJlcGFyZWQgZm9yIHRoYXQuICBXaXRoIElQdjQsIHRoZSBjb25jZXB0IGNh bWUNCj5sYXRlIGluIHRoZSBkYXkgd2hpY2ggaXMgd2h5IEkgYW0gdW5jZXJ0YWluIGFib3V0IGhv dyBtdWNoIHN1cHBvcnQgdGhlcmUNCj5pcyB0aGVyZW9mLg0KPg0KPlVzaW5nIGEgTk1TIHdpdGgg TkVUQ09ORiBhbmQgdGhlIElFVEYgWUFORyBtb2RlbHMsIHRoZW4gdGhlIHByb3RvY29sL0RETA0K PmlkZW50aWZpZXMgdGhlIGludGVyZmFjZSwgd2hhdGV2ZXIgdGhhdCBtYXkgYmUsIHBoeXNpY2Fs LCBsb2dpY2FsIChGUg0KPlZDLCBNUExTIExTUCwgLi4uKSBieSBuYW1lOyB0aGUgWUFORyBsaXN0 IGlzIGtleWVkIGJ5ICduYW1lJyB3aGljaCBpcyBhDQo+Y2hhbmdlIGluIGFwcHJvYWNoIGZyb20g dGhhdCBvZiB0aGUgTUlCIG1vZHVsZS4gIEhvdyB0aGUgTk1TIHByZXNlbnRzDQo+dGhhdCB0byB0 aGUgdXNlciBpcyB1cCB0byB0aGUgTk1TIChpdCBjb3VsZCBiZSAtIEkgZG9uJ3Qga25vdyAtIHRo YXQgYW4NCj5OTVMgY2hvb3NlcyB0byB1c2UgSVB2NCBhZGRyZXNzZXMgYmVjYXVzZSB0aGF0IGlz IHdoYXQgdXNlcnMgYXJlDQo+ZmFtaWxpYXIgd2l0aCkuDQo+DQo+U2Vjb25kYXJ5IGFkZHJlc3Nl cyBJIHNhdyBmaXJzdCB3aXRoIG9uZSByb3V0ZXIgbWFudWZhY3R1cmVyIGFuZCB0aGVuDQo+bGF0 ZXIgd2l0aCBvdGhlcnM7IEkgd291bGQgZXhwZWN0IG1vc3QgdG8gc3VwcG9ydCB0aGVtLiAgVGhl DQo+aW1wbGVtZW50YXRpb25zIEkgaGF2ZSBzZWVuIGhhdmUgb25seSBvbmUgcHJpbWFyeS4gIEkg aGF2ZSBhbHdheXMgc2Vlbg0KPnNlY29uZGFyeSBhZGRyZXNzZXMgYXMgYW4gdW5zYXRpc2ZhY3Rv cnkgc29sdXRpb24gdG8gYWRkcmVzc2luZyBpc3N1ZXMNCj5hbmQgd2hpbGUgdGhleSB3ZXJlIG5l ZWRlZCBhdCB0aGUgdGltZSwgSSB3b3VsZCBsaWtlIHRvIHRoaW5rIHRoYXQgdGhlaXINCj51c2Ug aGFzIGRpbWluaXNoZWQgc2luY2UuICBJIHdvdWxkIGxvb2sgYXNrYW5jZSBhdCBhIGRlc2lnbiB0 aGF0IHVzZXMNCj50aGVtIGluIHRoaXMgZGF5IGFuZCBhZ2UuICBEb3VidGxlc3MgdGhleSBhcmUg c3RpbGwgYXJvdW5kIGJ1dCBob3cNCj53aWRlc3ByZWFkIHRoZXkgYXJlLCBJIGRvbid0IGtub3cu ICAoSSB3YXMgYWN0aXZlIGluIGdldHRpbmcgdGhlbQ0KPmluY2x1ZGVkIGluIHRoZSBZQU5HIG1v ZGVsIHdoaWNoIEkgZG8gbm90IHRoaW5rIHRoYXQgYWxsIHRob3NlIGludm9sdmVkDQo+d2VyZSku DQo+DQo+VGhlIGNvbmZpZ3VyYXRpb24gb2YgT1NQRiBtYXkgaGF2ZSBhbiBvcHRpb24gdG8gYWR2 ZXJ0aXNlIG9yIHRvIHN1cHByZXNzDQo+dGhlIGFkdmVydGlzZW1lbnQgb2Ygc2Vjb25kYXJ5IGFk ZHJlc3NlcyBpbiB0aGUgTFNBLg0KPg0KPldoZXRoZXIgb3Igbm90IGEgc2Vjb25kYXJ5IGFkZHJl c3MgY2FuIGJlIHVzZWQgZm9yIG90aGVyIHB1cnBvc2VzIGluDQo+T1NQRiwgc3VjaCBhcyBEUiBv ciBCRFIsIEkgYW0gdW5zdXJlOyBzb21ldGhpbmcgYXQgdGhlIGJhY2sgb2YgbXkgbWluZA0KPnNh eXMgdGhlcmUgaXMgYW4gaXNzdWUgd2l0aCB0aGUgdXNlIG9mIGJyb2FkY2FzdCBieSBhIERSIGJ1 dCBJIGNhbm5vdA0KPnRyYWNrIGRvd24gYSByZWZlcmVuY2UgdG8gdGhhdC4gIFdpdGggdGhlIHBy b3Bvc2VkIFlBTkcgbW9kZWxzIC0gaWYtY2ZnLA0KPmlwLWNmZywgb3NwZiAtIGl0IGlzIGZlYXNp YmxlIHRvIGNvbmZpZ3VyZSBhIHNlY29uZGFyeSBpbnRlcmZhY2UgaW4gdGhlDQo+c2FtZSB3YXkg YXMgYSBwcmltYXJ5IG9uZSwgc2hvdWxkIHRoZSBkZXZpY2Ugc3VwcG9ydCB0aGF0Lg0KPg0KPlRv bSBQZXRjaA0KPg0KPj4gUmVnYXJkcw0KPj4gQWxhbg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogdC5wZXRjaCBbbWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5j b21dDQo+PiBTZW50OiAxMyBNYXkgMjAxNiAxNzozMQ0KPg0KPjxzbmlwPg0KPg0KDQo= From nobody Tue May 17 10:28:23 2016 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 13FAB12DC21 for ; Tue, 17 May 2016 10:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi7UXQMLARXa for ; Tue, 17 May 2016 10:28:18 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E161912DC16 for ; Tue, 17 May 2016 10:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21570; q=dns/txt; s=iport; t=1463506097; x=1464715697; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=J2v9tPRWGuSL40lEB6Q5XhXmbeTk9ye/ccd9xMVzvvE=; b=LlQcGUXRikOZHBatl5GAR0cI9Sk46Uh6+imfNCbA8TBaik9zZqGwv2zx Jgtpze75E1CWdhFAWx3Wagjn9ja5aiuhwfbJ4gaHEohVirmFjQ2jKFha3 7/JIBwH2U1Ug5bIkPNAkyRjoLH21vesS6pN8Sn0yq6in8v7yLXPaglGlU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQCwUztX/4kNJK1cgzdVfgauC4tmA?= =?us-ascii?q?Q2BdRcNhW0CHIEeOBQBAQEBAQEBZSeEQgEBAQIBAQEBASARMwEGCQIQAgEIEQQ?= =?us-ascii?q?BAQECAiYCAgIfBgsVCAgCBAENBQmIDAMPCA6xfI1LDYQfAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHIEBiG6BA4JDgUMcAQEbOoJGglkBBI1fihkxAYV+hieBeYFpToQ?= =?us-ascii?q?BgyqFN4ddh2QBHgEBQoIGHBaBNW4BhkcGAxcffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="273949492" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2016 17:28:16 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4HHSFb1001229 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 17:28:16 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 13:28:15 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Tue, 17 May 2016 13:28:15 -0400 From: "Acee Lindem (acee)" To: Ramakrishna DTV , Acee Lindem , Manav Bhatia Thread-Topic: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt Thread-Index: AQHRq5iDI45ZmPCOekqfeZl/Lp+NDp+0k8d6gABZ1oCAABFxgIAABkWAgABiUQCAAAHOAIAIAlEA Date: Tue, 17 May 2016 17:28:14 +0000 Message-ID: References: <89E7259B-72EE-4B60-BFC1-BA55BE761B9C@lindem.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <5C14041F41C67C4BB3841821A5050C8B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF List , Manjul Khandelwal Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 17:28:21 -0000 PFNwZWFraW5nIGFzIGFuIE9TUEYgV0cgbWVtYmVyPg0KDQpIaSBSYW1ha3Jpc2huYSwgDQoNClNv IHRoZSBhdHRhY2sgaXMgcHJlZGljYXRlZCBvbiB0aGUgZm9sbG93aW5nOg0KDQogICAgMS4gVGhl IGF0dGFja2VyIGlzIGFibGUgdG8gbW9kaWZ5IHRoZSByaWdodCBmaWVsZHMgaW4gdGhlIExTQSB0 byBnZXQNCnRoZSBkZXNpcmVkIGJlaGF2aW9yIGFuZCBzdGlsbCBnZW5lcmF0ZSB0aGUgc2FtZSBG bGV0Y2hlciBjaGVja3N1bS4gVGhpcw0KaXMgcHJvYmFibHkgZG9hYmxlIC0gaGF2ZSB5b3UgZG9u ZSBpdD8NCiAgICAyLiBUaGUgYXR0YWNrZXLigJlzIExTQSByZWFjaGVzIHRoZSBvcmlnaW5hdG9y IChha2EsIHRoZSB2aWN0aW0pIGFmdGVyDQppdCBoYXMgcmVzcG9uZGVkIHRvIHRoZSBhdHRhY2sg YW5kIGdlbmVyYXRlZCB0aGUgTFNBIHdpdGggdGhlIGRlc2lyZWQNCnNlcXVlbmNlIG51bWJlci4g DQogICAgMy4gVGhlIGF0dGFja2Vyc+KAmXMgTFNBIHJlYWNoZXMgb3RoZXIgcm91dGVycyBiZWZv cmUgdGhlIG9yaWdpbmF0b3LigJlzDQpMU0EgKHdoaWNoIGlzIHByb2JhYmx5IG9ubHkgYXNzdXJl ZCBmb3Igcm91dGVycyBkb3duc3RyZWFtIGZyb20gdGhlDQphdHRhY2tlciBpbiB0aGUgYmVzdCBj YXNlIGZsb29kaW5nIGdyYXBoIHJvb3RlZCBhdCB0aGUgb3JpZ2luYXRvcikuIElmIHRoZQ0Kb3Jp Z2luYXRvcuKAmXMgTFNBIHJlYWNoZXMgdGhlc2Ugcm91dGVycyBmaXJzdCwgaXQgaXMgaWdub3Jl ZC4NCg0KSSBtdXN0IGFkbWl0IEnigJltIG5vdCBhIGJpZyBmYW4gb2YgdGhlIHByb3Bvc2VkIGNo YW5nZSBnaXZlbiB0aGF0IG9uY2UgYQ0Kcm91dGVyIGluIHRoZSByb3V0aW5nIGRvbWFpbiBpcyBj b21wcm9taXNlZCAoaW5jbHVkaW5nIG9idGFpbmluZw0KYXV0aGVudGljYXRpb24ga2V5cyksIHRo ZXJlIGFyZSBtYW55IGhhcm1mdWwgYXR0YWNrcyB0aGF0IG1heSBiZSBsZXZpZWQNCmFuZCB0aGlz IGlzIGp1c3Qgb25lIG9mIHRoZW0uIE1vcmUgaW1wb3J0YW50bHksIHlvdSBuZWdsZWN0IHRoZSBm YWN0IHRoYXQNCnlvdeKAmWxsIGhhc3RlbiB0aGUgZGlzcnVwdGlvbiBjYXVzZWQgYnkgdGhlIHNl cXVlbmNlIG51bWJlciBhZHZhbmNpbmcgdG8NCk1heFNlcXVlbmNlTnVtYmVyICh3aGljaCBjYW5u b3QgYmUgc2tpcHBlZCkuDQoNCkluIHNob3J0LCBJIHRoaW5rIHRoaXMgaXMgZGVmaW5pdGVseSBh IGNhc2Ugd2hlcmUg4oCcdGhlIG1lZGljaW5lIGlzIHdvcnNlDQp0aGFuIHRoZSBjdXJlLuKAnSAN Cg0KVGhhbmtzLA0KQWNlZSANCg0KT24gNS8xMi8xNiwgNzowOSBBTSwgIk9TUEYgb24gYmVoYWxm IG9mIFJhbWFrcmlzaG5hIERUViINCjxvc3BmLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IHJhbWFrcmlzaG5hZHR2QG5pdmV0dGlzeXN0ZW1zLmNvbT4NCndyb3RlOg0KDQo+SGkgQWNlZS9N YW5hdiwNCj4NCj5JIGd1ZXNzIHdlIHdlcmUgYSBsaXR0bGUgdG9vIGJyaWVmIGluIG91ciBkZXNj cmlwdGlvbiBvZiB0aGUgYXR0YWNrIGluDQo+dGhlIGRyYWZ0Lg0KPg0KPlRoZSBwYXBlciAiTmFr aWJseSwgRy4gZXQgYWwsIFBlcnNpc3RlbnQgT1NQRiBhdHRhY2tzLCBORFNTICwgMjAxMiINCj5k aXNjdXNzZXMgYWJvdXQgbXVsdGlwbGUgdmFyaWFudHMgb2YgdGhlICJEaXNndWlzZWQgTFNBIGF0 dGFjayIuIEkgd2lsbA0KPmRlc2NyaWJlDQo+b25lIHZhcmlhbnQgYmVsb3cuDQo+DQo+U29tZSBm YWN0czoNCj4NCj5RdW90aW5nIGZyb20gdGhlIHBhcGVyOg0KPg0KPiJTZWN0aW9uIDEzLjEgb2Yg dGhlIE9TUEYgc3BlYyBzdGF0ZXMgdGhhdCB0d28gaW5zdGFuY2VzIG9mIGFuIExTQSBhcmUNCj5j b25zaWRlcmVkIGlkZW50aWNhbCBpZiB0aGV5IGhhdmUgdGhlIHNhbWUgdmFsdWVzIGluIHRoZSBm b2xsb3dpbmcgdGhyZWUNCj5maWVsZHM6DQo+DQo+CVNlcXVlbmNlIE51bWJlciwgQ2hlY2tzdW0s IGFuZCBBZ2UuDQo+DQo+SW4gZmFjdCwgdHdvIExTQXMgYXJlIGNvbnNpZGVyZWQgaWRlbnRpY2Fs IGV2ZW4gaWYgdGhlaXIgQWdlIGZpZWxkcw0KPmRpZmZlciBieSB1cCB0byAxNSBtaW51dGVzIChh bmQgdGhlIFNlcXVlbmNlIE51bWJlciBhbmQgQ2hlY2tzdW0NCj5maWVsZHMgYXJlIHRoZSBzYW1l KS4gVGhlIGtleSBwb2ludCBpcyB0aGF0IHRoZSBzcGVjIGNvbnNpZGVycyB0aGVzZQ0KPnR3byBM U0FzIHRvIGJlIHRoZSBzYW1lIGV2ZW4gaWYgdGhlIGFjdHVhbCBhZHZlcnRpc2VkIGxpbmtzIGlu IHRoZSBMU0FzDQo+ZGlmZmVyLiINCj4NCj5OZXR3b3JrIHNldHVwOg0KPg0KPlRoZXJlIGFyZSBh IHNldCBvZiByb3V0ZXJzIGluIGEgcm91dGluZyBkb21haW4uDQo+DQo+SW4gdGhpcyBuZXR3b3Jr ICdDJyBpcyB0aGUgY29tcHJvbWlzZWQgcm91dGVyLiAnVicgaXMgdGhlIHZpY3RpbSByb3V0ZXIu DQo+DQo+SW50ZW50aW9uOiBDIGludGVuZHMgdG8gY2hhbmdlIGFuIExTQSBvZiBWIHdpdGhvdXQg ViBmaWdodGluZyBiYWNrLg0KPg0KPkhlcmUgaXMgYSB0aW1lLWxpbmUgb2YgZXZlbnRzOg0KPg0K PnQwOiBWIGdlbmVyYXRlZCBhbiBMU0Egd2l0aCBzZXF1ZW5jZSBudW1iZXIgJ3MnIGFuZCBhbGwg cm91dGVycyBoYXZlIGl0DQo+aW5zdGFsbGVkIGluIHRoZWlyIGRhdGFiYXNlIGluY2x1ZGluZyBD Lg0KPg0KPnQxOiBDIGNoYW5nZXMgdGhlIExTQSBvZiBWIHRvIHNlcXVlbmNlIG51bWJlciAncysx JyBhbmQgZmxvb2RzIGl0LiBUaGUNCj5wYXBlcg0KPnJlZmVycyB0aGlzIGFzICJ0cmlnZ2VyIExT QSIuDQo+DQo+V2hpbGUgdGhpcyBMU0EgaXMgZmxvb2RpbmcgdGhlIG5ldHdvcmssIGFuZCBpdCBp cyBvbiBpdHMgd2F5IHRvIFYgYXMNCj53ZWxsLi4uDQo+DQo+dDI6IEMgY2hhbmdlcyB0aGUgTFNB IG9mIFYgdG8gc2VxdWVuY2UgbnVtYmVyICdzKzInIGFuZCBjaGFuZ2VzIHRoZSBMU0EgaW4NCj5z dWNoIGEgd2F5IHRoYXQgY2hlY2tzdW0gd2lsbCBiZSBzYW1lIGFzIHdoYXQgViB3b3VsZCBoYXZl IGNhbGN1bGF0ZWQuIFYNCj50aGVuDQo+Zmxvb2RzIHRoaXMgImRpc2d1aXNlZCBMU0EiLg0KPg0K PihOb3RlOiBUaGUgdGltZS1nYXAgYmV0d2VlbiB0MSBhbmQgdDIgaXMgZ292ZXJuZWQgYnkgTWlu TFNBcnJpdmFsIG9mIFJGQw0KPjIzMjguKQ0KPg0KPnQzOiBWIHJlY2VpdmVzIExTQSB3aXRoIHNl cXVlbmNlIG51bWJlciAncysxJyBhbmQgYXMgcGFydCBvZiAnZmlnaHQtYmFjaycNCj5tZWNoYW5p c20gcmVpc3N1ZXMgTFNBIHdpdGggc2VxdWVuY2UgbnVtYmVyICdzKzInIGFuZCBzdGFydHMgZmxv b2RpbmcuDQo+DQo+KE5vdGUgdGhhdCB0MyBtYXkgZXZlbiBiZSBiZXR3ZWVuIHQxIGFuZCB0MiBp biBzb21lIGNhc2VzLiBCdXQgdGhlIGF0dGFjaw0KPnN0aWxsDQo+d29ya3MgaW4gZWl0aGVyIGNh c2UuKQ0KPg0KPlRoZSBpbXBvcnRhbnQgcG9pbnQgbm93IGlzIHRoYXQgdGhlcmUgYXJlIHR3byBM U0FzIGluIHJhY2UgZm9yIGZsb29kaW5nIGluDQo+dGhlIG5ldHdvcmsgLS0gb25lIHByZXBhcmVk IGJ5IEMgYW5kIG90aGVyIHByZXBhcmVkIGJ5IFYuDQo+DQo+Qm90aCB0aGUgTFNBcyBoYXZlIHNh bWUgdmFsdWVzIGZvciB0aGUgZm9sbG93aW5nIHZhbHVlczoNCj4NCj4JU2VxdWVuY2UgTnVtYmVy ICgncysyJyksIENoZWNrc3VtLCBhbmQgQWdlLg0KPg0KPkJ1dCBub3RlIHRoYXQgdGhlaXIgY29u dGVudHMgYXJlIGRpZmZlcmVudCENCj4NCj5BbnkgcmVjZWl2aW5nIHJvdXRlciAoaW5jbHVkaW5n IHZpY3RpbSBWKSB3aWxsIGNvbnNpZGVyIHRoZXNlIGFzDQo+ZHVwbGljYXRlcyBhbmQNCj5pbnN0 YWxscyB0aGUgZmlyc3Qgb25lIGl0IHJlY2VpdmVzLg0KPg0KPlRoZSBwb2ludCBpcyB0aGF0IExT QSB3aXRoIHNlcXVlbmNlIG51bWJlciAncysyJyB3aWxsIG5vdCB0cmlnZ2VyDQo+ZmlnaHQtYmFj ay4NCj5JbnN0ZWFkLCBpdCB3aWxsIGJlIGNvbnNpZGVyZWQgYXMgYSBkdXBsaWNhdGUuDQo+DQo+ VGhlIGVudGlyZSBhdHRhY2sgaXMgbWFkZSBwb3NzaWJsZSBiZWNhdXNlIEMga25vd3MgdGhhdCBW IHdpbGwgZ2VuZXJhdGUNCj5MU0Egd2l0aA0KPnNlcXVlbmNlIG51bWJlciAncysyJyB3aGVuIGl0 IGlzIGZpZ2h0aW5nIGJhY2sgYW4gTFNBIHdpdGggc2VxdWVuY2UNCj5udW1iZXIgJ3MrMScuDQo+ DQo+Tm90ZSB0aGF0IGF0IHRoZSBlbmQgb2YgdGhlIGF0dGFjaywgc29tZSByb3V0ZXJzIGhhdmUg dGhlIExTQSBhcyBwcmVwYXJlZA0KPmJ5IFYuDQo+VGhpcyBpcyB0aGUgY29ycmVjdCBMU0EuIFRo ZSByZW1haW5pbmcgcm91dGVycyB3aWxsIGhhdmUgdGhlIExTQSBhcw0KPnByZXBhcmVkIGJ5DQo+ Qy4gSXQgaXMgb2J2aW91cyB0aGF0IExTREIgb2YgdGhpcyBzZWNvbmQgc2V0IGlzIGVmZmVjdGl2 ZWx5IGNvcnJ1cHRlZC4gQW4NCj5pbXBvcnRhbnQgcG9pbnQgaXMgdGhhdCBldmVuIHRob3NlIHJv dXRlcnMgd2hpY2ggZ290IGNvcnJlY3QgTFNBLCBpdCBpcw0KPnN0aWxsDQo+dHJvdWJsZXNvbWUg YmVjYXVzZSBMU0RCIGlzIG5vdCBzYW1lIGFjcm9zcyBhbGwgdGhlIHJvdXRlcnMuDQo+VW5zeW5j aHJvbml6ZWQgTFNEQg0KPmFjcm9zcyByb3V0ZXJzIGNhdXNlIHJvdXRpbmcgaXNzdWVzLg0KPg0K PkdhYmkgYW5kIGNvLWF1dGhvcnMgaGF2ZSBhbHNvIHByb3ZpZGVkIGEgbmljZSBwcmVzZW50YXRp b24gd2hpY2ggZGVzY3JpYmVzDQo+dGhpcyBhdHRhY2sgaW4gZ3JhcGhpY2FsIGZvcm0gd2l0aCBs aXR0bGUgbW9yZSBkZXRhaWwgKGVzcGVjaWFsbHkgbG9vayBhdA0KPnNsaWRlcyAxNCB0byAyMCk6 DQo+DQo+CWh0dHA6Ly93d3cuaW50ZXJuZXRzb2NpZXR5Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVz L1AwMV8zLnBkZg0KPg0KPlRoYW5rcyBhbmQgcmVnYXJkcywNCj5SYW1ha3Jpc2huYSBEVFYuDQo+ DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkZyb206IEFj ZWUgTGluZGVtIDxhY2VlLmxpbmRlbUBnbWFpbC5jb20+DQo+U2VudDogVGh1cnNkYXksIE1heSAx MiwgMjAxNiA0OjMzIFBNDQo+VG86IE1hbmF2IEJoYXRpYQ0KPkNjOiBSYW1ha3Jpc2huYSBEVFY7 IE9TUEYgTGlzdDsgTWFuanVsIEtoYW5kZWx3YWwNCj5TdWJqZWN0OiBSZTogW09TUEZdIEZ3OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ZHJhZnQtbWFuanVsZHR2LW9zcGYtc2VxdWVu Y2UtbnVtYmVyLTAwLnR4dA0KPg0KPkhpIE1hbmF2LA0KPj4gT24gTWF5IDEyLCAyMDE2LCBhdCAx OjExIEFNLCBNYW5hdiBCaGF0aWEgPG1hbmF2YmhhdGlhQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pg0K Pj4gSGkgRFRWLA0KPj4NCj4+IEFoYS4gVGhhbmtzIGZvciB0aGUgY2F0Y2ggIQ0KPj4NCj4+IElu IHRoYXQgY2FzZSwgaSBkb250IHVuZGVyc3RhbmQgd2h5IHRoZSAidmljdGltIiB3aWxsIE5PVCBn ZW5lcmF0ZSBhDQo+Pm5ldyBMU0Egd2l0aCBMUyBzZXF1ZW5jZSBudW1iZXIgb25lIHBhc3QgdGhl IHJlY2VpdmVkIExTIHNlcXVlbmNlDQo+Pm51bWJlci4gSSBzZWUgdGhhdCB0aGUgbmV3IGF0dGFj ayB0cmllcyB0byBkbyBzb21ldGhpbmcgYnkgdXBkYXRpbmcgdGhlDQo+PnNlcXVlbmNlIG51bWJl ciBhbmQgdGhlIGNoZWNrc3VtIC0tIGRpZCBub3Qgc3BlbmQgdG9vIG11Y2ggdGltZSBvbg0KPj50 cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0IGV4YWN0bHkgaXRzIGRvaW5nIHRoZXJlLiBIb3dldmVy LCBPU1BGIGFsc28NCj4+aGFzIHByb3Zpc2lvbnMgdG8gZ2V0IGFyb3VuZCB0aGF0LCBhbmQgaSB3 cm90ZSBhYm91dCB0aGlzIG1hbnkgeWVhcnMgYWdvDQo+PmhlcmU6DQo+Pg0KPj4gDQo+Pmh0dHBz Oi8vcm91dGluZ2ZyZWFrLndvcmRwcmVzcy5jb20vMjAxMC8wNy8wMi91c2luZy1jaGVja3N1bS1p bi1kZXRlcm1pbmkNCj4+bmctdGhlLW5ld2VyLWxzYS8NCj4+DQo+PiBTbyBpIGhhdmUgdGhlIHNh bWUgcXVlc3Rpb24gYXMgQWNlZSAtLSB3aHkgd2lsbCB0aGUgbmF0dXJhbCBmaWdodC1iYWNrDQo+ Pm1lY2hhbmlzbSBub3Qgd29yayBoZXJlPw0KPg0KPkl0IHdpbGwgYW5kIHRoYXQgd2FzIG15IHBv aW50LiBJIGNhbiB0aGluayBvZiBvbmx5IG9uZSBwb3NzaWJsZSBhdHRhY2sNCj53aGVyZSB0aGUg c2FtZSBzZXF1ZW5jZSBudW1iZXIgaXMgdXNlZCBidXQgdGhlIGF0dGFja2VyIGNhbiBvbmx5IGNo YW5nZQ0KPnRoZSBjb250ZW50cyBvZiB0aGUgTFNBIGZvciBPU1BGIHJvdXRlcnMgZm9yIHdoaWNo IGl0IGlzIGluIHRoZSBmbG9vZGluZw0KPnBhdGggZnJvbSB0aGUgb3JpZ2luYXRvci4NCj4NCj5U aGFua3MsDQo+QWNlZQ0KPg0KPj4NCj4+IENoZWVycywgTWFuYXYNCj4+DQo+PiBPbiBUaHUsIE1h eSAxMiwgMjAxNiBhdCAxMDoxOCBBTSwgUmFtYWtyaXNobmEgRFRWDQo+PjxyYW1ha3Jpc2huYWR0 dkBuaXZldHRpc3lzdGVtcy5jb20+IHdyb3RlOg0KPj4NCj4+IEhpIE1hbmF2LA0KPj4NCj4+IFRo YW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4NCj4+DQo+PiBHYWJpIGhhcyBwdWJsaXNoZWQgbXVs dGlwbGUgYXR0YWNrcyBhZ2FpbnN0IE9TUEYuDQo+Pg0KPj4gVGhlIGF0dGFjayB3ZSBhcmUgdGFy Z2V0aW5nIGlzIHB1Ymxpc2hlZCBpbg0KPj4NCj4+IEBpbnByb2NlZWRpbmdze25ha2libHkyMDEy cGVyc2lzdGVudCwNCj4+ICAgdGl0bGU9e1BlcnNpc3RlbnQgT1NQRiBBdHRhY2tzLn0sDQo+PiAg IGF1dGhvcj17TmFraWJseSwgR2FiaSBhbmQgS2lyc2hvbiwgQWxleCBhbmQgR29uaWttYW4sIERp bWEgYW5kIEJvbmVoLA0KPj5EYW59LA0KPj4gICBib29rdGl0bGU9e05EU1N9LA0KPj4gICB5ZWFy PXsyMDEyfQ0KPj4gfQ0KPj4NCj4+IFRoaXMgYXR0YWNrIGluZGVlZCBkZXBlbmRzIG9uIHByZWRp Y3RhYmlsaXR5IG9mIHNlcXVlbmNlIG51bWJlcnMuDQo+PiBPbiBhIHNpZGUgbm90ZSwgd2UgZXZl biB2ZXJpZmllZCB0aGF0IGZhY3Qgd2l0aCBHYWJpIE5ha2libHkgaGltc2VsZg0KPj4gb3ZlciBh IHByaXZhdGUgbWFpbC4NCj4+DQo+PiBUaGUgYXR0YWNrIHlvdSBhcmUgZGlzY3Vzc2luZyBpbiB5 b3VyIGFydGljbGUgaXMgYSBkaWZmZXJlbnQgYXR0YWNrLg0KPj4gSXQgd2FzIGRlc2NyaWJlZCBi eSBHYWJpIGluIGdyZWF0IGRldGFpbCBpbiBhIGRpZmZlcmVudCBwYXBlcjoNCj4+DQo+PiBAaW5w cm9jZWVkaW5nc3tuYWtpYmx5MjAxNG9zcGYsDQo+PiAgIHRpdGxlPXtPU1BGIHZ1bG5lcmFiaWxp dHkgdG8gcGVyc2lzdGVudCBwb2lzb25pbmcgYXR0YWNrczogYQ0KPj5zeXN0ZW1hdGljIGFuYWx5 c2lzfSwNCj4+ICAgYXV0aG9yPXtOYWtpYmx5LCBHYWJpIGFuZCBTb3Nub3ZpY2gsIEFkaSBhbmQg TWVuYWhlbSwgRWl0YW4gYW5kDQo+PldhaXplbCwgQXJpZWwgYW5kIEVsb3ZpY2ksIFl1dmFsfSwN Cj4+ICAgYm9va3RpdGxlPXtQcm9jZWVkaW5ncyBvZiB0aGUgMzB0aCBBbm51YWwgQ29tcHV0ZXIg U2VjdXJpdHkNCj4+QXBwbGljYXRpb25zIENvbmZlcmVuY2V9LA0KPj4gICBwYWdlcz17MzM2LS0z NDV9LA0KPj4gICB5ZWFyPXsyMDE0fSwNCj4+ICAgb3JnYW5pemF0aW9uPXtBQ019DQo+PiB9DQo+ Pg0KPj4gQXMgeW91IHJpZ2h0bHkgbWVudGlvbmVkLCB0aGlzIGF0dGFjayBkb2VzIG5vdCBkZXBl bmQgdXBvbiBzZXF1ZW5jZQ0KPj5udW1iZXINCj4+IHByZWRpY3RhYmlsaXR5LiBCdXQgb3VyIGRy YWZ0IGlzICpub3QqIHRhcmdldGluZyAqdGhpcyogYXR0YWNrLg0KPj4NCj4+IFRoYW5rcyBhbmQg cmVnYXJkcywNCj4+IFJhbWFrcmlzaG5hIERUVi4NCj4+DQo+Pg0KPj4NCj4+IEZyb206IE1hbmF2 IEJoYXRpYSA8bWFuYXZiaGF0aWFAZ21haWwuY29tPg0KPj4gU2VudDogVGh1cnNkYXksIE1heSAx MiwgMjAxNiA5OjE2IEFNDQo+PiBUbzogUmFtYWtyaXNobmEgRFRWDQo+PiBDYzogQWNlZSBMaW5k ZW0gKGFjZWUpOyBNYW5qdWwgS2hhbmRlbHdhbDsgb3NwZkBpZXRmLm9yZw0KPj4gU3ViamVjdDog UmU6IFtPU1BGXSBGdzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj5kcmFmdC1tYW5q dWxkdHYtb3NwZi1zZXF1ZW5jZS1udW1iZXItMDAudHh0DQo+Pg0KPj4gSGkgRFRWLA0KPj4NCj4+ IEkgZG9udCBhZ3JlZSB0byB5b3VyIGFzc2Vzc21lbnQgb2YgaG93IHRoZSBhdHRhY2sgZXZhZGVz IHRoZSAibmF0dXJhbA0KPj5maWdodC1iYWNrIG1lY2hhbmlzbSIgaW4gT1NQRi4NCj4+DQo+PiBJ dHMgZ290ICpub3RoaW5nKiB0byBkbyB3aXRoIHRoZSBzZXF1ZW5jZSBudW1iZXJzIGJlaW5nIHBy ZWRpY3RhYmxlLA0KPj5ldGMuIEkgaGF2ZSBleHBsYWluZWQgaW4gZGVwdGggaG93IHRoZSBHYWJ5 IGF0dGFjayB3b3JrcyBoZXJlOg0KPj4NCj4+IA0KPj5odHRwczovL3JvdXRpbmdmcmVhay53b3Jk cHJlc3MuY29tLzIwMTMvMDkvMDkvaG93LWJhZC1pcy10aGUtb3NwZi12dWxuZXJhDQo+PmJpbGl0 eS1leHBvc2VkLWJ5LWJsYWNrLWhhdC8NCj4+IEhvdyBiYWQgaXMgdGhlIE9TUEYgdnVsbmVyYWJp bGl0eSBleHBvc2VkIGJ5IEJsYWNrIEhhdCAuLi4NCj4+IHJvdXRpbmdmcmVhay53b3JkcHJlc3Mu Y29tDQo+PiBJIHdhcyBhc2tlZCBhIGZldyB3ZWVrcyBhZ28gYnkgb3VyIGZpZWxkIGVuZ2luZWVy cyB0byBwcm92aWRlIGEgZml4IGZvcg0KPj50aGUgT1NQRiB2dWxuZXJhYmlsaXR5IGV4cG9zZWQg YnkgQmxhY2sgSGF0IGxhc3QgbW9udGguIFByaW1hIGZhY2llDQo+PnRoZXJlIGFwcGVhcmVkIC4u Lg0KPj4NCj4+DQo+PiBDbGlwcGVkIGZyb20gdGhlIGJsb2c6DQo+Pg0KPj4gIlRoaXMgYXR0YWNr IGV4cGxvaXRzIGEgcG90ZW50aWFsIG9taXNzaW9uIChvciBhIGJ1ZyBpZiB5b3Ugd2lsbCkgaW4N Cj4+dGhlIHN0YW5kYXJkIHdoZXJlIGl0IGRvZXMgbm90IG1hbmRhdGUgdGhhdCB0aGUgcmVjZWl2 aW5nIHJvdXRlcg0KPj52ZXJpZmllcyB0aGF0IHRoZSBMaW5rIFN0YXRlIElEIGFuZCB0aGUgQWR2 ZXJ0aXNpbmcgUm91dGVyIGZpZWxkcyBpbiB0aGUNCj4+Um91dGVyIExTQSBhcmUgdGhlIGV4YWN0 IHNhbWUgdmFsdWUuDQo+Pg0KPj4gVGhpcyBhdHRhY2sgc2VuZHMgbWFsYWNpb3VzIFJvdXRlciBM U0FzIHdpdGggdHdvIGRpZmZlcmVudCB2YWx1ZXMgaW4NCj4+dGhlIExTIGhlYWRlci4gVGhlIExp bmsgU3RhdGUgSUQgY2FycmllcyB0aGUgUm91dGVyIElEIG9mIHRoZSByb3V0ZXINCj4+dGhhdCBp cyBiZWluZyBhdHRhY2tlZCAodGhlIHZpY3RpbSkgYW5kIHRoZSBBZHZlcnRpc2luZyBSb3V0ZXIg aXMgc2V0IHRvDQo+PnNvbWUgZGlmZmVyZW50IChhbnkpIHZhbHVlLg0KPj4NCj4+IFdoZW4gdGhl IHZpY3RpbSByZWNlaXZlcyB0aGUgbWFsYWNpb3VzIFJvdXRlciBMU0EsIGl0IGRvZXMgbm90IHJl ZnJlc2gNCj4+dGhpcyBMU0EgYXMgaXQgZG9lc250IHJlY29nbml6ZSB0aGlzIGFzIGl0cyBvd24g c2VsZiBnZW5lcmF0ZWQgTFNBLiBUaGlzDQo+PmlzIGJlY2F1c2UgdGhlIE9TUEYgc3BlYyBjbGVh cmx5IHNheXMgaW4gU2VjIDEzLjQgdGhhdCDigJxBDQo+PnNlbGYtb3JpZ2luYXRlZCBMU0EgaXMg ZGV0ZWN0ZWQgd2hlbiBlaXRoZXIgMSkgVGhlIExTQeKAmXMgQWR2ZXJ0aXNpbmcNCj4+Um91dGVy IGlzIGVxdWFsIHRvIHRoZSByb3V0ZXLigJlzIG93biBSb3V0ZXIgSUQgb3IgMikgdGhlIExTQSBp cyBhIG5ldHdvcmsNCj4+TFNBIC4uIOKAnC4NCj4+DQo+PiBUaGlzIG1lYW5zIHRoYXQgT1NQRuKA mXMgbmF0dXJhbCBmaWdodCBiYWNrIG1lY2hhbmlzbSBpcyBOT1QgdHJpZ2dlcmVkIGJ5DQo+PnRo ZSB2aWN0aW0gcm91dGVyIGFzIGxvbmcgYXMgdGhlIGZpZWxkIOKAmEFkdmVydGlzaW5nIFJvdXRl cuKAmSBvZiBhIExTQSBpcw0KPj5OT1QgZXF1YWwgdG8gdGhlIHZpY3RpbeKAmXMgUm91dGVyIElE LiBUaGlzIGlzIHRydWUgZXZlbiBpZiB0aGUg4oCYTGluaw0KPj5TdGF0ZSBJROKAmSBvZiB0aGF0 IExTQSBpcyBlcXVhbCB0byB0aGUgdmljdGlt4oCZcyBSb3V0ZXIgSUQuIEdvaW5nIGZ1cnRoZXIN Cj4+aXQgbWVhbnMgbm8gTFNBIHJlZnJlc2ggaXMgdHJpZ2dlcmVkIGV2ZW4gaWYgdGhlIG1hbGFj aW91cyBMU0EgY2xhaW1zIHRvDQo+PmRlc2NyaWJlIHRoZSBsaW5rcyBvZiB0aGUgdmljdGltIHJv dXRlciEiDQo+Pg0KPj4gSSBkZXNjcmliZSBmdXJ0aGVyIGluIHRoZSBibG9nIHRoYXQgbm90IGFs bCByb3V0ZXIgaW1wbGVtZW50YXRpb25zIGFyZQ0KPj5zdXNjZXB0aWJsZSB0byB0aGUgYXR0YWNr LiBJdHMgZGVwZW5kZW50IG9uIGhvdyB0aGUgTFNBIGlzIHBpY2tlZCB1cA0KPj5mcm9tIHRoZSBM U0RCLg0KPj4NCj4+IENoZWVycywgTWFuYXYNCj4+DQo+PiBPbiBUaHUsIE1heSAxMiwgMjAxNiBh dCA3OjU5IEFNLCBSYW1ha3Jpc2huYSBEVFYNCj4+PHJhbWFrcmlzaG5hZHR2QG5pdmV0dGlzeXN0 ZW1zLmNvbT4gd3JvdGU6DQo+PiBIaSBBY2VlLA0KPj4NCj4+IFdlIGN1cnJlbnRseSBwcm92aWRl ZCB0aGUgZm9sbG93aW5nIGRlc2NyaXB0aW9uIG9mIHRoaXMgYXR0YWNrIGluIHRoZQ0KPj5kcmFm dDoNCj4+DQo+PiAgIlRoZSBwYXBlciByZWZlcnMgdG8gdGhlIGF0dGFjayBhcyAiRGlzZ3Vpc2Vk IExTQSIgYW5kIGlzIG9mDQo+PiAgICBwZXJzaXN0ZW50IG5hdHVyZS4gIFRoaXMgYXR0YWNrIGlz IGxhdW5jaGVkIGZyb20gYSBjb21wcm9taXNlZCByb3V0ZXINCj4+ICAgIGluc2lkZSBhIHJvdXRp bmcgZG9tYWluLiAgSW4gdGhpcyBhdHRhY2ssIHRoZSBjb21wcm9taXNlZCByb3V0ZXINCj4+ICAg IGFsdGVycyB0aGUgTFNBIG9mIGFuIHVuY29tcHJvbWlzZWQgcm91dGVyICh2aWN0aW0pLiAgTm9y bWFsbHksIHN1Y2gNCj4+ICAgIGFuIGF0dGVtcHQgZG9lcyBub3QgaGF2ZSBwZXJzaXN0ZW5jZSBi ZWNhdXNlIHRoZSB2aWN0aW0gZ2VuZXJhdGVzIGENCj4+ICAgIG5ldyBMU0Egd2hlbiBpdCBzZWVz IHN1Y2ggc2VsZi1vcmlnaW5hdGVkIExTQXMgKHJlZmVycmVkIHRvIGFzDQo+PiAgICAiZmlnaHQt YmFjayIgbWVjaGFuaXNtIGluIHRoZSBwYXBlcikuICBCdXQgdGhlIHBhcGVyIG1ha2VzIGRpc2d1 aXNlZA0KPj4gICAgTFNBIHBlcnNpc3RlbnQgYmVjYXVzZSBhbGwgdGhlIGZpZWxkcyB7IExTIHNl cXVlbmNlIG51bWJlciwgY2hlY2tzdW19DQo+PiAgICBhcmUgcHJlZGljdGFibGUuICBJdCBhbHRl cnMgdGhlIGV4aXN0aW5nIExTQSBvZiB2aWN0aW0gdG8gc3VpdCBpdHMNCj4+ICAgIG5lZWRzIGJ1 dCBzZXRzIHRoZSBzZXF1ZW5jZSBudW1iZXIgdG8gKzEgb2YgdGhlIGV4aXN0aW5nIExTQSBhbmQN Cj4+ICAgIGFsdGVycyB0aGUgTFNBIHNvIHRoYXQgY2hlY2tzdW0gbWF0Y2hlcyB3aXRoIGNoZWNr c3VtIHRoYXQgd291bGQgYmUNCj4+ICAgIGdlbmVyYXRlZCBieSB0aGUgdmljdGltIHdoZW4gaXQg Z2VuZXJhdGVzIHRoZSBuZXcgTFNBLiAgV2hlbiB0aGlzDQo+PiAgICBkaXNndWlzZWQgTFNBIHJl YWNoZXMgdGhlIHZpY3RpbSwgaXQgZG9lcyBub3QgZmlnaHQgYmFjayBiZWNhdXNlIGl0DQo+PiAg ICBjb21wYXJlcyBvbmx5IHRoZSBmaWVsZHMgeyBMUyBzZXF1ZW5jZSBudW1iZXIsIGNoZWNrc3Vt LCBhZ2V9IHRvDQo+PiAgICBjaGVjayBmb3IgZHVwbGljYXRlcyBhbmQgbm90IHRoZSBhY3R1YWwg Y29udGVudCBvZiBMU0EuDQo+Pg0KPj4gICAgVGhpcyBhdHRhY2sgZW5hYmxlcyBhbiBpbnNpZGVy IGF0dGFja2VyIHRvIGZ1bGx5IGNvbnRyb2wgdGhlIGVudGlyZQ0KPj4gICAgY29udGVudCBvZiBh biBMU0EuICBXZSB0aGluayB0aGlzIGF0dGFjayBpcyBwb3dlcmZ1bC4iDQo+Pg0KPj4gVGhlc2Ug ZGV0YWlscyBhcmUgY3VycmVudGx5IHByZXNlbnQgaW4gU2VjdGlvbiA0LCB3aGljaCBpcyB0aXRs ZWQNCj4+IkltcGxlbWVudGF0aW9uIGFkdmljZSIuDQo+PiBXZSBjYW4gcHJvYmFibHkgbW92ZSBp dCB0byBhIGRpZmZlcmVudCBzZWN0aW9uIChlLmcuLCAiSW50cm9kdWN0aW9uIikNCj4+dG8gbWFr ZSBpdCBjbGVhci4NCj4+DQo+PiBJZiB5b3UgdGhpbmsgZXZlbiBtb3JlIGFkZGl0aW9uYWwgZGV0 YWlscyBhYm91dCB0aGUgYXR0YWNrIGFyZSB1c2VmdWwNCj4+dG8gdGhlIHdvcmtpbmcgZ3JvdXAs DQo+PiBwbGVhc2UgbGV0IHVzIGtub3cuIFdlIHdpbGwgYWRkLg0KPj4NCj4+IFRoYW5rIHlvdS4N Cj4+DQo+PiBSZWdhcmRzLA0KPj4gUmFtYWtyaXNobmEgRFRWLg0KPj4NCj4+DQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBGcm9tOiBBY2VlIExpbmRlbSAo YWNlZSkgPGFjZWVAY2lzY28uY29tPg0KPj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMTEsIDIwMTYg ODo0OSBQTQ0KPj4gVG86IE1hbmp1bCBLaGFuZGVsd2FsOyBvc3BmQGlldGYub3JnDQo+PiBDYzog UmFtYWtyaXNobmEgRFRWDQo+PiBTdWJqZWN0OiBSZTogW09TUEZdIEZ3OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yDQo+PmRyYWZ0LW1hbmp1bGR0di1vc3BmLXNlcXVlbmNlLW51bWJlci0w MC50eHQNCj4+DQo+PiBIaSBNYW5qdWwsDQo+Pg0KPj4gV291bGQgaXQgYmUgcG9zc2libGUgdG8g c3VjY2luY3RseSBkZXNjcmliZSB0aGVzZSDigJxjZXJ0YWluIHNlY3VyaXR5DQo+PiBhdHRhY2tz 4oCdIGluIHRoZSBkcmFmdCByYXRoZXIgdGhhbiBleHBlY3RpbmcgZXZlcnlvbmUgdG8gcmVhZCB0 aGUNCj4+IHJlZmVyZW5jZWQgcGFwZXI/DQo+Pg0KPj4gVGhhbmtzLA0KPj4gQWNlZQ0KPj4NCj4+ IE9uIDUvMTEvMTYsIDEwOjE5IEFNLCAiT1NQRiBvbiBiZWhhbGYgb2YgTWFuanVsIEtoYW5kZWx3 YWwiDQo+PiA8b3NwZi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYW5qdWxAbml2ZXR0 aXN5c3RlbXMuY29tPiB3cm90ZToNCj4+DQo+PiA+SGksDQo+PiA+DQo+PiA+V2UgaGF2ZSByZWNl bnRseSBzdWJtaXR0ZWQgYSBkcmFmdCB3aGljaCBkZWFscyB3aXRoIE9TUEYgTFMgc2VxdWVuY2UN Cj4+ID5udW1iZXINCj4+ID5nZW5lcmF0aW9uIG1lY2hhbmlzbS4NCj4+ID4NCj4+ID5BYnN0cmFj dCBvZiB0aGUgZHJhZnQ6DQo+PiA+ICAgVGhlIG1lY2hhbmlzbSBmb3IgTFMgc2VxdWVuY2UgbnVt YmVyIGdlbmVyYXRpb24gYXMgc3BlY2lmaWVkIGluIFJGQw0KPj4gPiAgIDIzMjggYW5kIFJGQyA1 MzQwIGlzIGNvbXBsZXRlbHkgcHJlZGljdGFibGUuICBUaGlzIG1ha2VzIGl0IHByb25lIHRvDQo+ PiA+ICAgY2VydGFpbiBzZWN1cml0eSBhdHRhY2tzIHdoaWNoIGV4cGxvaXQgdGhlIHByZWRpY3Rh YmxlIG5hdHVyZSBvZiBMUw0KPj4gPiAgIHNlcXVlbmNlIG51bWJlcnMuICBUaGlzIGRyYWZ0IHVw ZGF0ZXMgdGhlIFJGQyAyMzI4IHRvIG1ha2UgTFMNCj4+ID4gICBzZXF1ZW5jZSBudW1iZXIgZ2Vu ZXJhdGlvbiBhbiBpbXBsZW1lbnRhdGlvbiBjaG9pY2UgcmF0aGVyIHRoYW4gYQ0KPj4gPiAgIGZp eGVkIGluY3JlbWVudCBieSAxIGZvciBzdWNjZXNzaXZlIExTQXMuDQo+PiA+DQo+PiA+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWFuanVsZHR2LW9zcGYtc2VxdWVuY2Ut bnVtYmVyLw0KPj4gPg0KPj4gPldlIHNvbGljaXQgZmVlZGJhY2svY29tbWVudHMgb24gdGhlIGRy YWZ0IGFuZCByZXF1ZXN0IGZvciBhZG9wdGlvbiBieQ0KPj50aGUNCj4+ID5PU1BGIHdvcmtpbmcg Z3JvdXAuDQo+PiA+DQo+PiA+UmVnYXJkcywNCj4+ID5NYW5qdWwgS2hhbmRlbHdhbA0KPj4gPkRU ViBSYW1ha3Jpc2huYSBSYW8NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiA+RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDxpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+DQo+PiA+U2VudDogTW9uZGF5LCBNYXkgOSwgMjAxNiA3OjIyIFBNDQo+PiA+ VG86IE1hbmp1bCBLaGFuZGVsd2FsOyBSYW1ha3Jpc2huYSBEVFYNCj4+ID5TdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+PiA+ZHJhZnQtbWFuanVsZHR2LW9zcGYtc2VxdWVu Y2UtbnVtYmVyLTAwLnR4dA0KPj4gPg0KPj4gPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1t YW5qdWxkdHYtb3NwZi1zZXF1ZW5jZS1udW1iZXItMDAudHh0DQo+PiA+aGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBNYW5qdWwgS2hhbmRlbHdhbCBhbmQgcG9zdGVkIHRvIHRoZQ0K Pj4gPklFVEYgcmVwb3NpdG9yeS4NCj4+ID4NCj4+ID5OYW1lOiAgICAgICAgICAgZHJhZnQtbWFu anVsZHR2LW9zcGYtc2VxdWVuY2UtbnVtYmVyDQo+PiA+UmV2aXNpb246ICAgICAgIDAwDQo+PiA+ VGl0bGU6ICAgICAgICAgIE9TUEYgTFNBIHNlcXVlbmNlIG51bWJlciBnZW5lcmF0aW9uDQo+PiA+ RG9jdW1lbnQgZGF0ZTogIDIwMTYtMDUtMDkNCj4+ID5Hcm91cDogICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQo+PiA+UGFnZXM6ICAgICAgICAgIDEwDQo+PiA+VVJMOg0KPj4gDQo+Pj5o dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFuanVsZHR2LW9zcGYt c2VxdWVuY2UtbnVtYmUNCj4+PnItDQo+PiA+MDAudHh0DQo+PiA+U3RhdHVzOg0KPj4gPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1hbmp1bGR0di1vc3BmLXNlcXVlbmNl LW51bWJlci8NCj4+ID5IdG1saXplZDoNCj4+ID5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbWFuanVsZHR2LW9zcGYtc2VxdWVuY2UtbnVtYmVyLTAwDQo+PiA+DQo+PiA+DQo+PiA+ QWJzdHJhY3Q6DQo+PiA+ICAgVGhlIG1lY2hhbmlzbSBmb3IgTFMgc2VxdWVuY2UgbnVtYmVyIGdl bmVyYXRpb24gYXMgc3BlY2lmaWVkIGluIFJGQw0KPj4gPiAgIDIzMjggYW5kIFJGQyA1MzQwIGlz IGNvbXBsZXRlbHkgcHJlZGljdGFibGUuICBUaGlzIG1ha2VzIGl0IHByb25lIHRvDQo+PiA+ICAg Y2VydGFpbiBzZWN1cml0eSBhdHRhY2tzIHdoaWNoIGV4cGxvaXQgdGhlIHByZWRpY3RhYmxlIG5h dHVyZSBvZiBMUw0KPj4gPiAgIHNlcXVlbmNlIG51bWJlcnMuICBUaGlzIGRyYWZ0IHVwZGF0ZXMg dGhlIFJGQyAyMzI4IHRvIG1ha2UgTFMNCj4+ID4gICBzZXF1ZW5jZSBudW1iZXIgZ2VuZXJhdGlv biBhbiBpbXBsZW1lbnRhdGlvbiBjaG9pY2UgcmF0aGVyIHRoYW4gYQ0KPj4gPiAgIGZpeGVkIGlu Y3JlbWVudCBieSAxIGZvciBzdWNjZXNzaXZlIExTQXMuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+ DQo+PiA+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YNCj4+ID5zdWJtaXNzaW9uDQo+PiA+dW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+ID4NCj4+ ID5UaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4gPg0KPj4gPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+T1NQRiBtYWlsaW5nIGxpc3QNCj4+ID5PU1BG QGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3Bm DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IE9TUEYgbWFpbGluZyBsaXN0DQo+PiBPU1BGQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGYNCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IE9TUEYgbWFpbGluZyBsaXN0DQo+ PiBPU1BGQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29zcGYNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPk9TUEYgbWFpbGluZyBsaXN0DQo+T1NQRkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb3NwZg0KDQo= From nobody Tue May 17 19:12:20 2016 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 813C112D57B for ; Tue, 17 May 2016 19:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QldXrM7Deuml for ; Tue, 17 May 2016 19:12:16 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C684C12D14F for ; Tue, 17 May 2016 19:12:16 -0700 (PDT) Received: by mail-pa0-x22b.google.com with SMTP id xk12so12407501pac.0 for ; Tue, 17 May 2016 19:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TCPVzI8jS5eBioY9dCFSE2CcYX282jwZe3VvplwJz04=; b=gax9EtQMsgivSlpcIHJosIEvGzQ7QyWCV0Qiuace+xMBTpHhA5x4c7cMzW2yUtu7l3 0y8fyeR8KIIi+KyJOE04hwVli57Ri+CIEtoLZ5+ojR4VDk9oFa8saRdOJaeti5z1Eoua OPptus1GkGq+MxL3FlvkVUHWrRNNf81RNPpXUPbxn7t06QZtu3TCg+QK+xNMPtLv5W2l hGyqSY1QNM8Ys1PxUdR+a1uzZ0lVsELOLB78YeeE6i7yaSIOBIhnJGWQCKJCWGBxXUtP EwhOgxBSrL5aVvcqsrwT/hxdchVCb1J7mgcFIVsD3S6q0eg4Qb0E9kXEbHZ9pa2fQg04 C+Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TCPVzI8jS5eBioY9dCFSE2CcYX282jwZe3VvplwJz04=; b=SGTIzxyDYrv+QAjGpz6dX6A86TpDJDsfLs+vSjNNs2XtN0h/0oHmesbqEBQj1R6Rgh HpNt/ZOnVUj3kD0H/yAsdmZEwceuY2KPKUYbgaQt5kPc0UeO+67VgSZ6vMjMATuIoFBX xZbNJcfeocccJpt/eeaA8YhBPcLPzWDRStaIkvDXStl4VNjhCvL38eJ3ppzITft1W0K4 TlqUkKuvzEPCWONCqp++hcaJIvUVMwgFA0/vA+c3sLbpIaLCPMCewnTuKM1cZtk8otDa K0RVYrWIj5JVRzPhlUqdUzWLAq9V41JcBaoOC1a6OYAsbaarsDUEp/SVJ0L9MuyDs/I/ 7fvQ== X-Gm-Message-State: AOPr4FWch9OLdqqZHiakczPAyeBxtPZ2e7GDP9TJsSasYuYWWDvgxoB5fVNA5M9sAQpkBQ== X-Received: by 10.66.132.103 with SMTP id ot7mr7074599pab.60.1463537536372; Tue, 17 May 2016 19:12:16 -0700 (PDT) Received: from [10.138.61.184] ([166.170.39.30]) by smtp.gmail.com with ESMTPSA id vg9sm7668263pab.35.2016.05.17.19.12.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 19:12:15 -0700 (PDT) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Tue, 17 May 2016 19:12:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7813B81C-7F50-4B51-97A6-00A0D6797801@gmail.com> References: <89E7259B-72EE-4B60-BFC1-BA55BE761B9C@lindem.com> To: "Acee Lindem (acee)" Archived-At: Cc: OSPF List , Ramakrishna DTV , Acee Lindem , Manjul Khandelwal Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 02:12:19 -0000 I fully agree with Acee's assessment, to my feeling the solution proposed w= ould cause more harm than good Regards, Jeff > On May 17, 2016, at 10:28 AM, Acee Lindem (acee) wrote: >=20 > >=20 > Hi Ramakrishna,=20 >=20 > So the attack is predicated on the following: >=20 > 1. The attacker is able to modify the right fields in the LSA to get > the desired behavior and still generate the same Fletcher checksum. This > is probably doable - have you done it? > 2. The attacker=92s LSA reaches the originator (aka, the victim) after > it has responded to the attack and generated the LSA with the desired > sequence number.=20 > 3. The attackers=92s LSA reaches other routers before the originator=92= s > LSA (which is probably only assured for routers downstream from the > attacker in the best case flooding graph rooted at the originator). If the= > originator=92s LSA reaches these routers first, it is ignored. >=20 > I must admit I=92m not a big fan of the proposed change given that once a > router in the routing domain is compromised (including obtaining > authentication keys), there are many harmful attacks that may be levied > and this is just one of them. More importantly, you neglect the fact that > you=92ll hasten the disruption caused by the sequence number advancing to > MaxSequenceNumber (which cannot be skipped). >=20 > In short, I think this is definitely a case where =93the medicine is worse= > than the cure.=94=20 >=20 > Thanks, > Acee=20 >=20 > On 5/12/16, 7:09 AM, "OSPF on behalf of Ramakrishna DTV" > > wrote: >=20 >> Hi Acee/Manav, >>=20 >> I guess we were a little too brief in our description of the attack in >> the draft. >>=20 >> The paper "Nakibly, G. et al, Persistent OSPF attacks, NDSS , 2012" >> discusses about multiple variants of the "Disguised LSA attack". I will >> describe >> one variant below. >>=20 >> Some facts: >>=20 >> Quoting from the paper: >>=20 >> "Section 13.1 of the OSPF spec states that two instances of an LSA are >> considered identical if they have the same values in the following three >> fields: >>=20 >> Sequence Number, Checksum, and Age. >>=20 >> In fact, two LSAs are considered identical even if their Age fields >> differ by up to 15 minutes (and the Sequence Number and Checksum >> fields are the same). The key point is that the spec considers these >> two LSAs to be the same even if the actual advertised links in the LSAs >> differ." >>=20 >> Network setup: >>=20 >> There are a set of routers in a routing domain. >>=20 >> In this network 'C' is the compromised router. 'V' is the victim router. >>=20 >> Intention: C intends to change an LSA of V without V fighting back. >>=20 >> Here is a time-line of events: >>=20 >> t0: V generated an LSA with sequence number 's' and all routers have it >> installed in their database including C. >>=20 >> t1: C changes the LSA of V to sequence number 's+1' and floods it. The >> paper >> refers this as "trigger LSA". >>=20 >> While this LSA is flooding the network, and it is on its way to V as >> well... >>=20 >> t2: C changes the LSA of V to sequence number 's+2' and changes the LSA i= n >> such a way that checksum will be same as what V would have calculated. V >> then >> floods this "disguised LSA". >>=20 >> (Note: The time-gap between t1 and t2 is governed by MinLSArrival of RFC >> 2328.) >>=20 >> t3: V receives LSA with sequence number 's+1' and as part of 'fight-back'= >> mechanism reissues LSA with sequence number 's+2' and starts flooding. >>=20 >> (Note that t3 may even be between t1 and t2 in some cases. But the attack= >> still >> works in either case.) >>=20 >> The important point now is that there are two LSAs in race for flooding i= n >> the network -- one prepared by C and other prepared by V. >>=20 >> Both the LSAs have same values for the following values: >>=20 >> Sequence Number ('s+2'), Checksum, and Age. >>=20 >> But note that their contents are different! >>=20 >> Any receiving router (including victim V) will consider these as >> duplicates and >> installs the first one it receives. >>=20 >> The point is that LSA with sequence number 's+2' will not trigger >> fight-back. >> Instead, it will be considered as a duplicate. >>=20 >> The entire attack is made possible because C knows that V will generate >> LSA with >> sequence number 's+2' when it is fighting back an LSA with sequence >> number 's+1'. >>=20 >> Note that at the end of the attack, some routers have the LSA as prepared= >> by V. >> This is the correct LSA. The remaining routers will have the LSA as >> prepared by >> C. It is obvious that LSDB of this second set is effectively corrupted. A= n >> important point is that even those routers which got correct LSA, it is >> still >> troublesome because LSDB is not same across all the routers. >> Unsynchronized LSDB >> across routers cause routing issues. >>=20 >> Gabi and co-authors have also provided a nice presentation which describe= s >> this attack in graphical form with little more detail (especially look at= >> slides 14 to 20): >>=20 >> http://www.internetsociety.org/sites/default/files/P01_3.pdf >>=20 >> Thanks and regards, >> Ramakrishna DTV. >>=20 >>=20 >> ________________________________________ >> From: Acee Lindem >> Sent: Thursday, May 12, 2016 4:33 PM >> To: Manav Bhatia >> Cc: Ramakrishna DTV; OSPF List; Manjul Khandelwal >> Subject: Re: [OSPF] Fw: New Version Notification for >> draft-manjuldtv-ospf-sequence-number-00.txt >>=20 >> Hi Manav, >>> On May 12, 2016, at 1:11 AM, Manav Bhatia wrote:= >>>=20 >>> Hi DTV, >>>=20 >>> Aha. Thanks for the catch ! >>>=20 >>> In that case, i dont understand why the "victim" will NOT generate a >>> new LSA with LS sequence number one past the received LS sequence >>> number. I see that the new attack tries to do something by updating the >>> sequence number and the checksum -- did not spend too much time on >>> trying to understand what exactly its doing there. However, OSPF also >>> has provisions to get around that, and i wrote about this many years ago= >>> here: >>>=20 >>>=20 >>> https://routingfreak.wordpress.com/2010/07/02/using-checksum-in-determin= i >>> ng-the-newer-lsa/ >>>=20 >>> So i have the same question as Acee -- why will the natural fight-back >>> mechanism not work here? >>=20 >> It will and that was my point. I can think of only one possible attack >> where the same sequence number is used but the attacker can only change >> the contents of the LSA for OSPF routers for which it is in the flooding >> path from the originator. >>=20 >> Thanks, >> Acee >>=20 >>>=20 >>> Cheers, Manav >>>=20 >>> On Thu, May 12, 2016 at 10:18 AM, Ramakrishna DTV >>> wrote: >>>=20 >>> Hi Manav, >>>=20 >>> Thank you for your comments. >>>=20 >>> Gabi has published multiple attacks against OSPF. >>>=20 >>> The attack we are targeting is published in >>>=20 >>> @inproceedings{nakibly2012persistent, >>> title=3D{Persistent OSPF Attacks.}, >>> author=3D{Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and Boneh,= >>> Dan}, >>> booktitle=3D{NDSS}, >>> year=3D{2012} >>> } >>>=20 >>> This attack indeed depends on predictability of sequence numbers. >>> On a side note, we even verified that fact with Gabi Nakibly himself >>> over a private mail. >>>=20 >>> The attack you are discussing in your article is a different attack. >>> It was described by Gabi in great detail in a different paper: >>>=20 >>> @inproceedings{nakibly2014ospf, >>> title=3D{OSPF vulnerability to persistent poisoning attacks: a >>> systematic analysis}, >>> author=3D{Nakibly, Gabi and Sosnovich, Adi and Menahem, Eitan and >>> Waizel, Ariel and Elovici, Yuval}, >>> booktitle=3D{Proceedings of the 30th Annual Computer Security >>> Applications Conference}, >>> pages=3D{336--345}, >>> year=3D{2014}, >>> organization=3D{ACM} >>> } >>>=20 >>> As you rightly mentioned, this attack does not depend upon sequence >>> number >>> predictability. But our draft is *not* targeting *this* attack. >>>=20 >>> Thanks and regards, >>> Ramakrishna DTV. >>>=20 >>>=20 >>>=20 >>> From: Manav Bhatia >>> Sent: Thursday, May 12, 2016 9:16 AM >>> To: Ramakrishna DTV >>> Cc: Acee Lindem (acee); Manjul Khandelwal; ospf@ietf.org >>> Subject: Re: [OSPF] Fw: New Version Notification for >>> draft-manjuldtv-ospf-sequence-number-00.txt >>>=20 >>> Hi DTV, >>>=20 >>> I dont agree to your assessment of how the attack evades the "natural >>> fight-back mechanism" in OSPF. >>>=20 >>> Its got *nothing* to do with the sequence numbers being predictable, >>> etc. I have explained in depth how the Gaby attack works here: >>>=20 >>>=20 >>> https://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulner= a >>> bility-exposed-by-black-hat/ >>> How bad is the OSPF vulnerability exposed by Black Hat ... >>> routingfreak.wordpress.com >>> I was asked a few weeks ago by our field engineers to provide a fix for >>> the OSPF vulnerability exposed by Black Hat last month. Prima facie >>> there appeared ... >>>=20 >>>=20 >>> Clipped from the blog: >>>=20 >>> "This attack exploits a potential omission (or a bug if you will) in >>> the standard where it does not mandate that the receiving router >>> verifies that the Link State ID and the Advertising Router fields in the= >>> Router LSA are the exact same value. >>>=20 >>> This attack sends malacious Router LSAs with two different values in >>> the LS header. The Link State ID carries the Router ID of the router >>> that is being attacked (the victim) and the Advertising Router is set to= >>> some different (any) value. >>>=20 >>> When the victim receives the malacious Router LSA, it does not refresh >>> this LSA as it doesnt recognize this as its own self generated LSA. This= >>> is because the OSPF spec clearly says in Sec 13.4 that =93A >>> self-originated LSA is detected when either 1) The LSA=92s Advertising >>> Router is equal to the router=92s own Router ID or 2) the LSA is a netwo= rk >>> LSA .. =93. >>>=20 >>> This means that OSPF=92s natural fight back mechanism is NOT triggered b= y >>> the victim router as long as the field =91Advertising Router=92 of a LSA= is >>> NOT equal to the victim=92s Router ID. This is true even if the =91Link >>> State ID=92 of that LSA is equal to the victim=92s Router ID. Going furt= her >>> it means no LSA refresh is triggered even if the malacious LSA claims to= >>> describe the links of the victim router!" >>>=20 >>> I describe further in the blog that not all router implementations are >>> susceptible to the attack. Its dependent on how the LSA is picked up >>> from the LSDB. >>>=20 >>> Cheers, Manav >>>=20 >>> On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV >>> wrote: >>> Hi Acee, >>>=20 >>> We currently provided the following description of this attack in the >>> draft: >>>=20 >>> "The paper refers to the attack as "Disguised LSA" and is of >>> persistent nature. This attack is launched from a compromised router >>> inside a routing domain. In this attack, the compromised router >>> alters the LSA of an uncompromised router (victim). Normally, such >>> an attempt does not have persistence because the victim generates a >>> new LSA when it sees such self-originated LSAs (referred to as >>> "fight-back" mechanism in the paper). But the paper makes disguised >>> LSA persistent because all the fields { LS sequence number, checksum} >>> are predictable. It alters the existing LSA of victim to suit its >>> needs but sets the sequence number to +1 of the existing LSA and >>> alters the LSA so that checksum matches with checksum that would be >>> generated by the victim when it generates the new LSA. When this >>> disguised LSA reaches the victim, it does not fight back because it >>> compares only the fields { LS sequence number, checksum, age} to >>> check for duplicates and not the actual content of LSA. >>>=20 >>> This attack enables an insider attacker to fully control the entire >>> content of an LSA. We think this attack is powerful." >>>=20 >>> These details are currently present in Section 4, which is titled >>> "Implementation advice". >>> We can probably move it to a different section (e.g., "Introduction") >>> to make it clear. >>>=20 >>> If you think even more additional details about the attack are useful >>> to the working group, >>> please let us know. We will add. >>>=20 >>> Thank you. >>>=20 >>> Regards, >>> Ramakrishna DTV. >>>=20 >>>=20 >>> ________________________________________ >>> From: Acee Lindem (acee) >>> Sent: Wednesday, May 11, 2016 8:49 PM >>> To: Manjul Khandelwal; ospf@ietf.org >>> Cc: Ramakrishna DTV >>> Subject: Re: [OSPF] Fw: New Version Notification for >>> draft-manjuldtv-ospf-sequence-number-00.txt >>>=20 >>> Hi Manjul, >>>=20 >>> Would it be possible to succinctly describe these =93certain security >>> attacks=94 in the draft rather than expecting everyone to read the >>> referenced paper? >>>=20 >>> Thanks, >>> Acee >>>=20 >>> On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal" >>> wrote: >>>=20 >>>> Hi, >>>>=20 >>>> We have recently submitted a draft which deals with OSPF LS sequence >>>> number >>>> generation mechanism. >>>>=20 >>>> Abstract of the draft: >>>> The mechanism for LS sequence number generation as specified in RFC >>>> 2328 and RFC 5340 is completely predictable. This makes it prone to >>>> certain security attacks which exploit the predictable nature of LS >>>> sequence numbers. This draft updates the RFC 2328 to make LS >>>> sequence number generation an implementation choice rather than a >>>> fixed increment by 1 for successive LSAs. >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ >>>>=20 >>>> We solicit feedback/comments on the draft and request for adoption by >>> the >>>> OSPF working group. >>>>=20 >>>> Regards, >>>> Manjul Khandelwal >>>> DTV Ramakrishna Rao >>>> ________________________________________ >>>> From: internet-drafts@ietf.org >>>> Sent: Monday, May 9, 2016 7:22 PM >>>> To: Manjul Khandelwal; Ramakrishna DTV >>>> Subject: New Version Notification for >>>> draft-manjuldtv-ospf-sequence-number-00.txt >>>>=20 >>>> A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt >>>> has been successfully submitted by Manjul Khandelwal and posted to the >>>> IETF repository. >>>>=20 >>>> Name: draft-manjuldtv-ospf-sequence-number >>>> Revision: 00 >>>> Title: OSPF LSA sequence number generation >>>> Document date: 2016-05-09 >>>> Group: Individual Submission >>>> Pages: 10 >>>> URL: >>>=20 >>>> https://www.ietf.org/internet-drafts/draft-manjuldtv-ospf-sequence-numb= e >>>> r- >>>> 00.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/ >>>> Htmlized: >>>> https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> The mechanism for LS sequence number generation as specified in RFC >>>> 2328 and RFC 5340 is completely predictable. This makes it prone to >>>> certain security attacks which exploit the predictable nature of LS >>>> sequence numbers. This draft updates the RFC 2328 to make LS >>>> sequence number generation an implementation choice rather than a >>>> fixed increment by 1 for successive LSAs. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>> _______________________________________________ >>>> 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 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Wed May 18 11:49:04 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F4A12D5BA; Wed, 18 May 2016 11:49:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518184900.14653.44869.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 11:49:00 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-mrt-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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 2016 18:49:00 -0000 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 of the IETF. Title : OSPF Extensions to Support Maximally Redundant Trees Authors : Alia Atlas Shraddha Hegde Chris Bowers Jeff Tantsura Zhenbin Li Filename : draft-ietf-ospf-mrt-02.txt Pages : 14 Date : 2016-05-18 Abstract: This document specifies extensions to OSPF to support the distributed computation of Maximally Redundant Trees (MRT). Some example uses of the MRTs include IP/LDP Fast-Reroute and global protection or live- live for multicast traffic. The extensions indicate what MRT profile(s) each router supports. Different MRT profiles can be defined to support different uses and to allow transitioning of capabilities. An extension is introduced to flood MRT-Ineligible links, due to administrative policy. The need for a mechanism to allow routers to advertise a worst-case FIB compute/install time is well understood for controlling convergence. This specification introduces the Controlled Convergence TLV to be carried in the Router Information LSA. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-mrt/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-mrt-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mrt-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 20 15:18:42 2016 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 3A56712D165 for ; Fri, 20 May 2016 15:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU2_jsTnNxAE for ; Fri, 20 May 2016 15:18:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2416412D13E for ; Fri, 20 May 2016 15:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6742; q=dns/txt; s=iport; t=1463782717; x=1464992317; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4VDkNrEQo51F/RMQveFAYdTCJlymBUcIC1ln4ymK3MY=; b=ObkCsktFCMILYEej72YljaPS+nFB0eeCs743mVEhNCC+x14e9iYunzad t7zstbAv8xfgU+sgjgOo/TWr5Ty4BVj0bqXX7HhsekT4UihI4eZZbDFqU Dqc32nK8p1n9RJVb/55yPL3lYQw6RL+VCy/7ig3nXre7TAW/5MuwXia9Q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBBQCrjD9X/4kNJK1NEYM3Vn0GuhKBd?= =?us-ascii?q?SKFbwIcgRw5EwEBAQEBAQFlJ4RCAQEBBB0GETQdBAIBCBEEAQEDAiMDAgICMBQ?= =?us-ascii?q?BBgEBBQMCBBMUiBsOsxKFDAKIeIMuAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBA?= =?us-ascii?q?YhugQOBOQGCVxEBgx2CWQWNZIpQAYV/iCCBaYRPiGSPSgEhAUCCE4FaboZONn8?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.26,341,1459814400"; d="scan'208";a="104485568" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 May 2016 22:18:36 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4KMIaFf020323 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 20 May 2016 22:18:36 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 20 May 2016 18:18:35 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 20 May 2016 18:18:35 -0400 From: "Acee Lindem (acee)" To: OSPF WG List Thread-Topic: NomCom 2016-2017 Call for Volunteers Thread-Index: AQHRsrTQbgsb+Gsr7UatV//xCaaXp5/CUwiQgAASpAA= Date: Fri, 20 May 2016 22:18:35 +0000 Message-ID: References: <20160519190342.15488.2118.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [OSPF] FW: NomCom 2016-2017 Call for Volunteers X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 20 May 2016 22:18:40 -0000 UGxlYXNlIGNvbnNpZGVyIHZvbHVudGVlcmluZyBpZiB5b3UgbWVldCB0aGUgY3JpdGVyaWHigKYg T2YgY291cnNlLCB3ZSBoYXZlDQpkb2N1bWVudCBzaGVwaGVyZGluZyBvcHBvcnR1bml0aWVzIGFz IHdlbGwgO14pDQpUaGFua3MsDQpBY2VlIA0KDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj5Gcm9tOiBJRVRGLUFubm91bmNlIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YNCj5Ob21Db20gQ2hhaXIgMjAxNg0KPlNlbnQ6IFRodXJzZGF5 LCBNYXkgMTksIDIwMTYgMzowNCBQTQ0KPlRvOiBJRVRGIEFubm91bmNlbWVudCBMaXN0IDxpZXRm LWFubm91bmNlQGlldGYub3JnPg0KPlN1YmplY3Q6IE5vbUNvbSAyMDE2LTIwMTcgQ2FsbCBmb3Ig Vm9sdW50ZWVycw0KPg0KPlN1YmplY3Q6IE5vbUNvbSAyMDE2LTIwMTcgQ2FsbCBmb3IgVm9sdW50 ZWVycw0KPg0KPlRoZSBJRVRGIG5vbWNvbSBhcHBvaW50cyBmb2xrcyB0byBmaWxsIHRoZSBvcGVu IHNsb3RzIG9uIHRoZSBJQU9DLCB0aGUNCj5JQUIsIGFuZCANCj50aGUgSUVTRy4NCj4NCj5UZW4g dm90aW5nIG1lbWJlcnMgZm9yIHRoZSBub21jb20gYXJlIHNlbGVjdGVkIGluIGEgdmVyaWZpYWJs eSByYW5kb20gd2F5DQo+ZnJvbSANCj5hIHBvb2wgb2Ygdm9sdW50ZWVycy4gVGhlIG1vcmUgdm9s dW50ZWVycywgdGhlIGJldHRlciBjaGFuY2Ugd2UgaGF2ZSBvZg0KPmNob29zaW5nDQo+YSByYW5k b20geWV0IHJlcHJlc2VudGF0aXZlIGNyb3NzIHNlY3Rpb24gb2YgdGhlIElFVEYgcG9wdWxhdGlv bi4NCj4NCj5UaGUgZGV0YWlscyBvZiB0aGUgb3BlcmF0aW9uIG9mIHRoZSBub21jb20gY2FuIGJl IGZvdW5kIGluIFJGQyA3NDM3LCBhbmQNCj5CQ1AxMC9SRkMzNzk3IGRldGFpbHMgdGhlIHNlbGVj dGlvbiBhbGdvcml0aG0uDQo+DQo+Vm9sdW50ZWVycyBtdXN0IGhhdmUgYXR0ZW5kZWQgMyBvZiB0 aGUgcGFzdCA1IElFVEYgbWVldGluZ3MuICBBcw0KPnNwZWNpZmllZCBpbiANCj5SRkMgNzQzNywg dGhhdCBtZWFucyB0aHJlZSBvdXQgb2YgdGhlIGZpdmUgcGFzdCBtZWV0aW5ncyB1cCB0byB0aGUg dGltZQ0KPnRoaXMgDQo+ZW1haWwgYW5ub3VuY2VtZW50IGdvZXMgb3V0IHRvIHN0YXJ0IHRoZSBz b2xpY2l0YXRpb24gb2Ygdm9sdW50ZWVycy4gVGhlDQo+Zml2ZSANCj5tZWV0aW5ncyBvdXQgb2Yg d2hpY2ggeW91IG11c3QgaGF2ZSBhdHRlbmRlZCAqdGhyZWUqIGFyZToNCj4NCj5JRVRGID0gOTEg KEhvbm9sdWx1KSAgICAgIFwNCj4gICAgICAgOTIgKERhbGxhcykgICAgICAgICBcDQo+ICAgICAg IDkzIChQcmFndWUpICAgICAgICAgIC0qKiogQU5ZIFRIUkVFIQ0KPiAgICAgICA5NCAoWW9rb2hh bWEpICAgICAgIC8NCj4gICAgICAgOTUgKEJ1ZW5vcyBBaXJlcykgIC8NCj4NCj4NCj5JZiB5b3Ug cXVhbGlmeSwgcGxlYXNlIHZvbHVudGVlci4gQmVmb3JlIHlvdSBkZWNpZGUgdG8gdm9sdW50ZWVy LCBwbGVhc2UNCj5yZW1lbWJlciB0aGF0IGFueW9uZSBhcHBvaW50ZWQgdG8gdGhpcyBOb21jb20g d2lsbCBub3QgYmUgY29uc2lkZXJlZCBhcyBhDQo+Y2FuZGlkYXRlIGZvciBhbnkgb2YgdGhlIHBv c2l0aW9ucyB0aGF0IHRoZSAyMDE2IC0gMjAxNyBOb21jb20gaXMNCj5yZXNwb25zaWJsZSANCj5m b3IgZmlsbGluZy4NCj4NCj5Tb21lIDIyOSBwZW9wbGUgaGF2ZSBhbHJlYWR5IHZvbHVudGVlcmVk IGJ5IHRpY2tpbmcgdGhlIGJveCBvbiB0aGUgSUVURg0KPjk1IA0KPnJlZ2lzdHJhdGlvbiBmb3Jt LiAxMzEgb2YgdGhlc2UgaGF2ZSBiZWVuIHZlcmlmaWVkIGFzIGVsaWdpYmxlLiBJIHdpbGwNCj5j b250YWN0IA0KPmFsbCBvZiB0aGVzZSBzaG9ydGx5LiBUaGFuayB5b3UgZm9yIHZvbHVudGVlcmlu ZyENCj4NCj5UaGUgbGlzdCBvZiBwZW9wbGUgYW5kIHBvc3RzIHdob3NlIHRlcm1zIGVuZCB3aXRo IHRoZSBNYXJjaCAyMDE3IElFVEYNCj5tZWV0aW5nLCANCj5hbmQgdGh1cyB0aGUgcG9zaXRpb25z IGZvciB3aGljaCB0aGlzIG5vbWNvbSBpcyByZXNwb25zaWJsZSwgYXJlDQo+DQo+SUFPQzoNCj4N Cj4gICAgTG91IEJlcmdlcg0KPg0KPklBQjoNCj4NCj4gICAgUmFscGggRHJvbXMNCj4gICAgUnVz cyBIb3VzbGV5DQo+ICAgIFJvYmVydCBTcGFya3MNCj4gICAgQW5kcmV3IFN1bGxpdmFuDQo+ICAg IERhdmUgVGhhbGVyDQo+ICAgIFN1emFubmUgV29vbGYNCj4NCj5JRVNHOg0KPg0KPiAgICBKYXJp IEFya2tvIChHRU4pDQo+ICAgIERlYm9yYWggQnJ1bmdhcmQgKFJURykNCj4gICAgQmVuIENhbXBi ZWxsIChBUlQpDQo+ICAgIFNwZW5jZXIgRGF3a2lucyAoVFNWKQ0KPiAgICBTdGVwaGVuIEZhcnJl bGwgKFNFQykNCj4gICAgSm9lbCBKYWVnZ2xpIChPUFMpDQo+ICAgIFRlcnJ5IE1hbmRlcnNvbiAo SU5UKQ0KPiAgICBBbHZhcm8gUmV0YW5hIChSVEcpDQo+DQo+DQo+QWxsIGFwcG9pbnRtZW50cyBh cmUgZm9yIDIgeWVhcnMuIFRoZSBBUlQgYW5kIFJvdXRpbmcgYXJlYXMgaGF2ZSAzIEFEcw0KPmFu ZCB0aGUgDQo+R2VuZXJhbCBhcmVhIGhhcyAxOyBhbGwgb3RoZXIgYXJlYXMgaGF2ZSAyIEFEcy4g VGh1cywgYWxsIGFyZWFzICh3aXRoIHRoZQ0KPmV4Y2VwdGlvbiBvZiBHRU4pIGhhdmUgYXQgbGVh c3Qgb25lIGNvbnRpbnVpbmcgQUQuDQo+DQo+VGhlIHByaW1hcnkgYWN0aXZpdHkgZm9yIHRoaXMg bm9tY29tIHdpbGwgYmVnaW4gaW4gSnVseSAyMDE2IGFuZCBzaG91bGQNCj5iZSANCj5jb21wbGV0 ZWQgaW4gSmFudWFyeSAyMDE3LiAgIFRoZSBub21jb20gd2lsbCBoYXZlIHJlZ3VsYXJseSBzY2hl ZHVsZWQNCj5jb25mZXJlbmNlIA0KPmNhbGxzIHRvIGVuc3VyZSBwcm9ncmVzcy4gVGhlcmUgd2ls bCBiZSBhY3Rpdml0aWVzIHRvIGNvbGxlY3QNCj5yZXF1aXJlbWVudHMgZnJvbSANCj50aGUgY29t bXVuaXR5LCByZXZpZXcgY2FuZGlkYXRlIHF1ZXN0aW9ubmFpcmVzLCByZXZpZXcgZmVlZGJhY2sg ZnJvbQ0KPmNvbW11bml0eSANCj5tZW1iZXJzIGFib3V0IGNhbmRpZGF0ZXMsIGFuZCB0YWxrIHRv IGNhbmRpZGF0ZXMuDQo+DQo+V2hpbGUgYmVpbmcgYSBub21jb20gbWVtYmVyIGRvZXMgcmVxdWly ZSBzb21lIHRpbWUgY29tbWl0bWVudCBpdCBpcyBhbHNvDQo+YSB2ZXJ5IA0KPnJld2FyZGluZyBl eHBlcmllbmNlLg0KPg0KPkFzIGEgbWVtYmVyIG9mIHRoZSBub21jb20gaXQgaXMgdmVyeSBpbXBv cnRhbnQgdGhhdCB5b3UgYmUgYWJsZSB0byBhdHRlbmQNCj5JRVRGOTcNCj4oU2VvdWwpIHRvIGNv bmR1Y3QgaW50ZXJ2aWV3cy4gQmVpbmcgYXQgSUVURjk2IChCZXJsaW4pIGlzIHVzZWZ1bCBmb3IN Cj5vcmllbnRhdGlvbi4gIEJlaW5nIGF0IElFVEY5OCBpcyBub3QgZXNzZW50aWFsLg0KPg0KPlBs ZWFzZSB2b2x1bnRlZXIgYnkgc2VuZGluZyBtZSBhbiBlbWFpbCBiZWZvcmUgMjM6NTkgVVRDIEp1 bmUgMjAsIDIwMTYsDQo+YXMgDQo+Zm9sbG93czoNCj4NCj5Ubzogbm9tY29tLWNoYWlyLTIwMTZA aWV0Zi5vcmcNCj5TdWJqZWN0OiBOb21jb20gMjAxNi0xNyBWb2x1bnRlZXINCj4NCj5QbGVhc2Ug aW5jbHVkZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIGluIHRoZSBlbWFpbCBib2R5Og0KPg0K PllvdXIgRnVsbCBOYW1lOiBfX19fX19fX19fDQo+ICAgIC8vIGFzIHlvdSB3cml0ZSBpdCBvbiB0 aGUgSUVURiByZWdpc3RyYXRpb24gZm9ybQ0KPkN1cnJlbnQgUHJpbWFyeSBBZmZpbGlhdGlvbjoN Cj4gICAgLy8gVHlwaWNhbGx5IHdoYXQgZ29lcyBpbiB0aGUgQ29tcGFueSBmaWVsZA0KPiAgICAv LyBpbiB0aGUgSUVURiBSZWdpc3RyYXRpb24gRm9ybQ0KPkVtYWlsczogX19fX19fX19fX19fX19f DQo+ICAgLy8gQWxsIGVtYWlsIGFkZHJlc3NlcyB1c2VkIHRvIHJlZ2lzdGVyIGZvciB0aGUgcGFz dCA1IElFVEYgbWVldGluZ3MNCj4gICAvLyBQcmVmZXJyZWQgZW1haWwgYWRkcmVzcyBmaXJzdA0K PlRlbGVwaG9uZTogX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgLy8gRm9yIGNvbmZpcm1h dGlvbiBpZiBzZWxlY3RlZA0KPg0KPllvdSBzaG91bGQgZXhwZWN0IGFuIGVtYWlsIHJlc3BvbnNl IGZyb20gbWUgd2l0aGluIDUgYnVzaW5lc3MgZGF5cw0KPnN0YXRpbmcgDQo+d2hldGhlciBvciBu b3QgeW91IGFyZSBxdWFsaWZpZWQuICBJZiB5b3UgZG9uJ3QgcmVjZWl2ZSB0aGlzIHJlc3BvbnNl LA0KPnBsZWFzZSANCj5yZS1zZW5kIHlvdXIgZW1haWwgd2l0aCB0aGUgdGFnICJSRVNFTkQiIiBh ZGRlZCB0byB0aGUgc3ViamVjdCBsaW5lLg0KPg0KPklmIHlvdSBhcmUgbm90IHlldCBzdXJlIGlm IHlvdSB3b3VsZCBsaWtlIHRvIHZvbHVudGVlciwgcGxlYXNlIGNvbnNpZGVyDQo+dGhhdCANCj5u b21jb20gbWVtYmVycyBwbGF5IGEgdmVyeSBpbXBvcnRhbnQgcm9sZSBpbiBzaGFwaW5nIHRoZSBs ZWFkZXJzaGlwIG9mDQo+dGhlIElFVEYuDQo+UXVlc3Rpb25zIGJ5IGVtYWlsIG9yIHZvaWNlIGFy ZSB3ZWxjb21lLiBWb2x1bnRlZXJpbmcgZm9yIHRoZSBub21jb20gaXMgYQ0KPmdyZWF0IA0KPndh eSB0byBjb250cmlidXRlIHRvIHRoZSBJRVRGIQ0KPg0KPllvdSBjYW4gZmluZCBhIGRldGFpbGVk IHRpbWVsaW5lIG9uIHRoZSBub21jb20gd2ViIHNpdGUgYXQ6DQo+ICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTYvDQo+DQo+SSB3aWxsIGJlIHB1Ymxpc2hpbmcgYSBt b3JlIGRldGFpbGVkIHRhcmdldCB0aW1ldGFibGUsIGFzIHdlbGwgYXMgZGV0YWlscw0KPm9mIHRo ZSANCj5yYW5kb21uZXNzIHNlZWRzIHRvIGJlIHVzZWQgZm9yIHRoZSBSRkMgMzc5NyBzZWxlY3Rp b24gcHJvY2Vzcywgd2l0aGluDQo+dGhlIG5leHQgDQo+ZmV3IHdlZWtzLg0KPg0KPlRoYW5rIHlv dSENCj4NCj5MdWN5IEx5bmNoDQo+bGx5bmNoQGNpdmlsLXRvbmd1ZS5uZXQNCj5ub21jb20tY2hh aXItMjAxNkBpZXRmLm9yZw0KPg0KDQo= From nobody Mon May 23 07:51:07 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B412D0F3; Mon, 23 May 2016 07:51:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523145105.10755.98057.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 07:51:05 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-lsa-extend-10.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 14:51:05 -0000 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 of the IETF. Title : OSPFv3 LSA Extendibility Authors : Acee Lindem Sina Mirtorabi Abhay Roy Fred Baker Filename : draft-ietf-ospf-ospfv3-lsa-extend-10.txt Pages : 37 Date : 2016-05-23 Abstract: OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward compatibility mechanisms are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 23 08:14:33 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F04112D965; Mon, 23 May 2016 08:14:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523151419.10740.10893.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 08:14:19 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-transition-to-ospfv3-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 15:14:19 -0000 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 of the IETF. Title : OSPFv3 over IPv4 for IPv6 Transition Authors : I. Chen A. Lindem R. Atkinson Filename : draft-ietf-ospf-transition-to-ospfv3-05.txt Pages : 10 Date : 2016-05-23 Abstract: This document defines a mechanism to use IPv4 to transport OSPFv3 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address Family extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-transition-to-ospfv3-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-transition-to-ospfv3-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 23 08:26:44 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF6512D970; Mon, 23 May 2016 08:26:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523152643.10715.66187.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 08:26:43 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-transition-to-ospfv3-06.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 15:26:43 -0000 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 of the IETF. Title : OSPFv3 over IPv4 for IPv6 Transition Authors : I. Chen A. Lindem R. Atkinson Filename : draft-ietf-ospf-transition-to-ospfv3-06.txt Pages : 10 Date : 2016-05-23 Abstract: This document defines a mechanism to use IPv4 to transport OSPFv3 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address Family extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-transition-to-ospfv3-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-transition-to-ospfv3-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 24 06:49:00 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB20312D7AD; Tue, 24 May 2016 06:48:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160524134857.4461.56851.idtracker@ietfa.amsl.com> Date: Tue, 24 May 2016 06:48:57 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-transition-to-ospfv3-07.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 13:48:58 -0000 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 of the IETF. Title : OSPFv3 over IPv4 for IPv6 Transition Authors : I. Chen A. Lindem R. Atkinson Filename : draft-ietf-ospf-transition-to-ospfv3-07.txt Pages : 10 Date : 2016-05-24 Abstract: This document defines a mechanism to use IPv4 to transport OSPFv3 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address Family extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-transition-to-ospfv3-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-transition-to-ospfv3-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 30 23:59:10 2016 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 A06C012B038 for ; Mon, 30 May 2016 23:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUlZBmOj0OfY for ; Mon, 30 May 2016 23:59:07 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89F012B029 for ; Mon, 30 May 2016 23:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=617; q=dns/txt; s=iport; t=1464677946; x=1465887546; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=3dpN1Q2Rp4pStDzXK7eDSKWs78uEefAyaO7rqrfSHyg=; b=gmSUgVJr/SlRXKI4gyPZ5TmWh6oeH4P+T36jDwCk+Fp9r5O8WgZ+YDdY 5vaflQ0LBu/jkn0BGQ4RDcBvHer8g99Ifq/u/6BvIDkCwBBHuobsF8qMF k9QnUifKeW67YGO4OWmz1Qo4Y9VJChFxc1+NY45dXiKYtYT/1e+LwoBnh s=; X-IronPort-AV: E=Sophos;i="5.26,394,1459814400"; d="scan'208";a="637752137" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 May 2016 06:59:05 +0000 Received: from [10.60.140.56] (ams-ppsenak-nitro7.cisco.com [10.60.140.56]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4V6x41u022066; Tue, 31 May 2016 06:59:04 GMT Message-ID: <574D3639.1070602@cisco.com> Date: Tue, 31 May 2016 08:59:05 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Acee Lindem (acee)" , OSPF WG List References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OSPF] Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions (Correct Draft Authors E-mail) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 31 May 2016 06:59:08 -0000 Support as coauthor. Thanks, Peter On 5/4/16 17:41 , Acee Lindem (acee) wrote: > The subject draft is very stable, has multiple interoperable > implementations, and many (including myself) have done thorough reviews. I > believe we are ready for WG last call for this very important draft. > > With great pleasure, this begins the WG last call for the subject draft. > Please send your comments to this list prior to 12:00 AM GMT, May 19th, > 2016. > > Here is a URL for your convenance: > > https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions > / > > Thanks, > Acee > From nobody Tue May 31 04:30:48 2016 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 A468012D194; Tue, 31 May 2016 04:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvCYQS_p24ED; Tue, 31 May 2016 04:30:44 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D76812D597; Tue, 31 May 2016 04:30:43 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 9FFA12255C454; Tue, 31 May 2016 11:30:39 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4VBUfLn032513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 May 2016 11:30:42 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4VBUdOQ011352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 May 2016 13:30:41 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.193]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 31 May 2016 13:28:34 +0200 From: "Henderickx, Wim (Nokia - BE)" To: "acee@cisco.com" , "ospf@ietf.org" Thread-Topic: Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions (Correct Draft Authors E-mail) Thread-Index: AQHRuwpTq5WOib87xEKVSNEmrXSY3Z/SUiyA Date: Tue, 31 May 2016 11:28:33 +0000 Message-ID: <21AF52BF-667E-4B0E-AAA5-AFE3530144E5@alcatel-lucent.com> References: <574D36D2.2060409@cisco.com> In-Reply-To: <574D36D2.2060409@cisco.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ospf-segment-routing-extensions@ietf.org" Subject: Re: [OSPF] Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions (Correct Draft Authors E-mail) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 31 May 2016 11:30:47 -0000 SSBhZ3JlZSB0aGUgZG9jIGlzIHJlYWR5IGZvciBXRyBsYXN0IGNhbGwgYW5kIGFzIEkgYWxyZWFk eSBtZW50aW9uZWQgd2UgaW1wbGVtZW50ZWQgdGhpcyArIGRpZCBJT1QuDQoNCj4tLS0tLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQo+U3ViamVjdDogV29ya2luZyBHcm91cCAgTGFzdCBD YWxsIGZvciBPU1BGIEV4dGVuc2lvbnMgZm9yIFNlZ21lbnQgDQo+Um91dGluZyAtIGRyYWZ0LWll dGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucyAoQ29ycmVjdCBEcmFmdCANCj5BdXRo b3JzIEUtbWFpbCkNCj5EYXRlOiBXZWQsIDQgTWF5IDIwMTYgMTU6NDE6MjYgKzAwMDANCj5Gcm9t OiBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPg0KPlRvOiBPU1BGIFdHIExpc3Qg PG9zcGZAaWV0Zi5vcmc+DQo+Q0M6IGRyYWZ0LWlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0 ZW5zaW9uc0BpZXRmLm9yZyANCj48ZHJhZnQtaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRl bnNpb25zQGlldGYub3JnPg0KPg0KPlRoZSBzdWJqZWN0IGRyYWZ0IGlzIHZlcnkgc3RhYmxlLCBo YXMgbXVsdGlwbGUgaW50ZXJvcGVyYWJsZQ0KPmltcGxlbWVudGF0aW9ucywgYW5kIG1hbnkgKGlu Y2x1ZGluZyBteXNlbGYpIGhhdmUgZG9uZSB0aG9yb3VnaCByZXZpZXdzLiBJDQo+YmVsaWV2ZSB3 ZSBhcmUgcmVhZHkgZm9yIFdHIGxhc3QgY2FsbCBmb3IgdGhpcyB2ZXJ5IGltcG9ydGFudCBkcmFm dC4NCj4NCj5XaXRoIGdyZWF0IHBsZWFzdXJlLCB0aGlzIGJlZ2lucyB0aGUgV0cgbGFzdCBjYWxs IGZvciB0aGUgc3ViamVjdCBkcmFmdC4NCj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRo aXMgbGlzdCBwcmlvciB0byAxMjowMCBBTSBHTVQsIE1heSAxOXRoLA0KPjIwMTYuDQo+DQo+SGVy ZSBpcyBhIFVSTCBmb3IgeW91ciBjb252ZW5hbmNlOg0KPg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucw0K Pi8NCj4NCj5UaGFua3MsDQo+QWNlZQ0KPg0KPg0KPg0K From nobody Tue May 31 08:23:20 2016 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 C3B0912D600; Tue, 31 May 2016 08:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeOhkln8HZHH; Tue, 31 May 2016 08:23:16 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E8C12D5FD; Tue, 31 May 2016 08:23:15 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id bz2so42795653pad.1; Tue, 31 May 2016 08:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=2yEf3FGimFRi8eecWIB/FYpvBoiTlYUKwjMZXjiu5q8=; b=wvk3fz72zFJtE4ToID1R3IGmVVY5ofcYewZAeGXyTakWv66IGaZUym7XKENE6UumTN 3AqIy6rSSy8h+NKiAUjcnFMeAuN3BLBnQsiCx97IQ+C4BIEsBQ1vxn0Vv/dnGBQ6+Pi9 fI4x1tRun7J7qiagk5UHo8JXyk1wGy3G3/EcahzcDnDnwIG8SOsd1HawcrdIWPthVCKr xYT5711ZIBIgIXDi6IgHSTyBlpxSNm/GvspysTcMpq1W+RB4S7CQ8BrutVP6/uT2yhYJ L+3DQTxVxmoOPLjF+Db8q0CXC+vRiqn4XOzOzxtY4JtBc4yWn94dH4mMiIyEzgWKz6VN y9Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=2yEf3FGimFRi8eecWIB/FYpvBoiTlYUKwjMZXjiu5q8=; b=Z10uswL7VIXMhEcBd9ddMLlB4tC7YoQJGTCdELG8Bbz7Nen2E0ewpvlciM2gEB3qvO dsueXNe5bAYmfgP02mWPjXdjlVN7iyss9U/ysaBCtTuZcUMcc0P5IqMb4AuU6G3Nji1x o9Zdfz+4dhVhQWfWcF4tkVsf+IIfW0uZXCPXTMhnTETxIP5oxLaq1U1o6DH1b5+Sb+z6 S8S1bTC/ccx60rRsftqHKkASP77T9K8UgoOn9SaNRDgQapVBRP2G+tXtYsBBHm7sY6IA wuuco8Tsf48N5xlxb0Ynuu9eLkzsKo32RBvDFRuWr62Kv0Sf072sQDXL+zd7zNCWXRws Y+4A== X-Gm-Message-State: ALyK8tLKyQFQtN38mpZST2RXI1sZOcWggZg/X8mh7HZMLC1VZv0AWmm+t4Phv7u13R4GDA== X-Received: by 10.66.142.232 with SMTP id rz8mr56119146pab.22.1464708195514; Tue, 31 May 2016 08:23:15 -0700 (PDT) Received: from [192.168.0.117] (66-189-255-235.dhcp.reno.nv.charter.com. [66.189.255.235]) by smtp.gmail.com with ESMTPSA id x19sm41234583pfi.81.2016.05.31.08.23.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2016 08:23:14 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.16.0.160506 Date: Tue, 31 May 2016 08:23:08 -0700 From: Jeff Tantsura To: "Acee Lindem (acee)" , OSPF WG List Message-ID: <5529608E-408F-4EB0-A53C-C971888C716B@gmail.com> Thread-Topic: [OSPF] Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions (Correct Draft Authors E-mail) Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: "draft-ietf-ospf-segment-routing-extensions@ietf.org" Subject: Re: [OSPF] Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions (Correct Draft Authors E-mail) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 31 May 2016 15:23:18 -0000 Hi Acee, Support as co-author. Thanks, Jeff On 5/4/16, 8:41 AM, "OSPF on behalf of Acee Lindem (acee)" wrote: >The subject draft is very stable, has multiple interoperable >implementations, and many (including myself) have done thorough reviews. I >believe we are ready for WG last call for this very important draft. > >With great pleasure, this begins the WG last call for the subject draft. >Please send your comments to this list prior to 12:00 AM GMT, May 19th, >2016. > >Here is a URL for your convenance: > >https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions >/ > >Thanks, >Acee > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From nobody Tue May 31 10:52:20 2016 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 CBA6412D88E; Tue, 31 May 2016 10:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qGz33ENn94I; Tue, 31 May 2016 10:52:17 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7121712D553; Tue, 31 May 2016 10:52:16 -0700 (PDT) Received: from [199.87.120.129] (helo=jivecommunications.com) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1b7npb-0002u9-Mp; Tue, 31 May 2016 18:51:56 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_2619895B-395B-4A50-8AC7-5078E2A73DC4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rob Shakir In-Reply-To: Date: Tue, 31 May 2016 11:52:33 -0600 Message-Id: References: To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-ospf-segment-routing-extensions@ietf.org" , OSPF WG List Subject: Re: [OSPF] Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions (Correct Draft Authors E-mail) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 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, 31 May 2016 17:52:20 -0000 --Apple-Mail=_2619895B-395B-4A50-8AC7-5078E2A73DC4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Acee, > On 4 May, 2016, at 9:41 AM, Acee Lindem (acee) wrote: > > The subject draft is very stable, has multiple interoperable > implementations, and many (including myself) have done thorough reviews. I > believe we are ready for WG last call for this very important draft. > > With great pleasure, this begins the WG last call for the subject draft. > Please send your comments to this list prior to 12:00 AM GMT, May 19th, > 2016. I also support as a co-author. Thanks, r. --Apple-Mail=_2619895B-395B-4A50-8AC7-5078E2A73DC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Acee,

On 4 May, 2016, at 9:41 AM, = Acee Lindem (acee) <acee@cisco.com> wrote:

The subject draft is very stable, has multiple = interoperable
implementations, and many (including myself) = have done thorough reviews. I
believe we are ready for WG last call for = this very important draft.

With great pleasure, this begins the WG last = call for the subject draft.
Please send your comments to this list = prior to 12:00 AM GMT, May 19th,
2016.

I= also support as a co-author.

Thanks,
r.
= --Apple-Mail=_2619895B-395B-4A50-8AC7-5078E2A73DC4--