From nobody Tue Dec 5 08:41:24 2017 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 5EBB81296CF; Tue, 5 Dec 2017 08:41:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: Cc: draft-ietf-ospf-segment-routing-extensions.all@ietf.org, ietf@ietf.org, ospf@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151249207030.23054.15249449053256280816@ietfa.amsl.com> Date: Tue, 05 Dec 2017 08:41:10 -0800 Archived-At: Subject: [OSPF] Genart telechat review of draft-ietf-ospf-segment-routing-extensions-22 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 16:41:10 -0000 Reviewer: Dan Romascanu Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-ospf-segment-routing-extensions-22 Reviewer: Dan Romascanu Review Date: 2017-12-05 IETF LC End Date: 2017-10-13 IESG Telechat date: 2017-12-14 Summary: Ready A useful and well-written document. It requires previous reading and understanding of OSPF, SPRING and other routing work. It is Ready for publication. My initial review included a few minor requests for clarifications. Most of these were addressed with text changes or additions. Major issues: Minor issues: Nits/editorial comments: From nobody Wed Dec 6 03:26:48 2017 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 A3B90126B7E; Wed, 6 Dec 2017 03:26:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ladislav Lhotka To: Cc: draft-ietf-ospf-yang.all@ietf.org, ietf@ietf.org, ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151255960762.30655.17225294251460480729@ietfa.amsl.com> Date: Wed, 06 Dec 2017 03:26:47 -0800 Archived-At: Subject: [OSPF] Yangdoctors last call review of draft-ietf-ospf-yang-09 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 11:26:48 -0000 Reviewer: Ladislav Lhotka Review result: Ready with Issues The data model defined in this document is a massive piece of work: it consists of 11 YANG modules and defines around 1200 schema nodes. The "ietf-ospf@2017-10-30" module is compatible with the NMDA architecture. **** Comments 1. Unless there is a really compelling reason not to do so, the "ietf-ospf" should declare YANG version 1.1. For one, "ietf-routing" that is being augmented by "ietf-ospf" already declares this version. Some of my suggestions below also assume version 1.1. 2. The "ietf-ospf" can work only with the new NMDA-compatible revisions of some modules, such as "ietf-interfaces" and "ietf-routing". I understand it is not desirable to import such modules by revision, but at least it should be mentioned in a description attached to every such import. 3. Maybe the draft could mention that implementations should supply a default routing domain as a system-controlled resource. 4. In "when" expressions, the module uses literal strings for identities. This is known to be problematic, the XPath functions derived-from() or derived-from-or-self() should be used instead. 5. Some enumerations, such as "packet-type" and "if-state-type" define enum identifiers with uppercase letters and/or underscores, for example "Database-Description" or "LONG_WAIT". RFC6087bis recommends that only lowercase letters, numbers and dashes. I think this convention should be observed despite the fact that the current names are traditionally used in OSPF specs. The "ietf-routing" module also defines "router-id" even though the documents use "Router ID". 6. The types of LSA headers are modelled as integers. While OSPF gurus probably know these numbers by heart, it is not very reader-frienly. So at least some references to documents defining these numbers should be provided, but my suggestion is to consider implementing them with identities. It seems it might also be useful to define some "abstract" identities for these types. For example, if "opaque-lsa" is defined, then the definition of container "opaque" could simply use when "derived-from(../../header/type, 'ospf:opaque-lsa')"; instead of when "../../header/type = 9 or " + "../../header/type = 10 or " + "../../header/type = 11"; 7. The title of sec. 2.9 should be "OSPF Notifications" rather than "OSPF notification". From nobody Wed Dec 13 02:34:12 2017 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 E48351241F3; Wed, 13 Dec 2017 02:34:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151316124588.30134.17253986444238366940@ietfa.amsl.com> Date: Wed, 13 Dec 2017 02:34:05 -0800 Archived-At: Subject: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-23.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 10:34:06 -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 WG of the IETF. Title : OSPF Extensions for Segment Routing Authors : Peter Psenak Stefano Previdi Clarence Filsfils Hannes Gredler Rob Shakir Wim Henderickx Jeff Tantsura Filename : draft-ietf-ospf-segment-routing-extensions-23.txt Pages : 28 Date : 2017-12-13 Abstract: Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPF extensions required for Segment Routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-23 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-extensions-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-extensions-23 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 Dec 13 02:47:50 2017 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 35CE21241F3; Wed, 13 Dec 2017 02:47:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-ospf-segment-routing-extensions@ietf.org, Acee Lindem , ospf-chairs@ietf.org, acee@cisco.com, ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151316206521.30067.6744549826451674092.idtracker@ietfa.amsl.com> Date: Wed, 13 Dec 2017 02:47:45 -0800 Archived-At: Subject: [OSPF] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 10:47:45 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ospf-segment-routing-extensions-23: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is generally a clearly written document, but it needs a few minor changes before I can recommend its approval for publication. 1) In Section 3.2: o When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [I-D.ietf-spring-conflict-resolution]. RFC 2119 keyword usage makes the reference a Normative reference, yet it is currently listed as informative. 3.4. SRMS Preference TLV The Segment Routing Mapping Server Preference TLV (SRMS Preference TLV) is used to advertise a preference associated with the node that acts as an SR Mapping Server. The role of an SRMS is described in [I-D.ietf-spring-segment-routing-ldp-interop]. As draff-ietf-spring-segment-routing-ldp-interop needs to be read in order to understand what SR Mapping Server is, this reference must also be Normative. SRMS preference is defined in [I-D.ietf-spring-conflict-resolution]. This just confirms that this reference must be Normative. 2) In Section 3.1: When multiple SR-Algorithm TLVs are received from a given router, the receiver SHOULD use the first occurrence of the TLV in the Router Information LSA. If the SR-Algorithm TLV appears in multiple Router Information LSAs that have different flooding scopes, the SR- Algorithm TLV in the Router Information LSA with the area-scoped flooding scope SHOULD be used. If the SR-Algorithm TLV appears in multiple Router Information LSAs that have the same flooding scope, the SR-Algorithm TLV in the Router Information (RI) LSA with the numerically smallest Instance ID SHOULD be used and subsequent instances of the SR-Algorithm TLV SHOULD be ignored. In the last 2 sentences: why are you using SHOULD (twice) instead of MUST? This seems to affect interoperability. (I think there is similar text in another section.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Several TLVs have "Reserved" fields, yet you never explain what "Reserved" means. You do explain what reserved flags mean in some of them. I suggest either explicitly explaining what Reserved means in each case or specify this in the terminology section near the beginning of the document. The document never specifies byte order for length fields. The acronym NSSA is never explained and it has no reference. From nobody Wed Dec 13 10:28:28 2017 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 052D6128BBB; Wed, 13 Dec 2017 10:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 bTos40kkIuph; Wed, 13 Dec 2017 10:28:19 -0800 (PST) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (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 ABC2D128CF0; Wed, 13 Dec 2017 10:28:14 -0800 (PST) Received: by mail-ot0-x241.google.com with SMTP id v21so2782721oth.6; Wed, 13 Dec 2017 10:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=V0P8bQ5WjlFKq22SfkAH5yNC6yEfHw1X8LgprwMsZ2g=; b=hrvq7nJNe9visoVaPeHDv+2SNlyqb6+O2xkmsV7MIuDm1XlAGibQu8nNWTzllCY6sY pTM28F0mlbhR8xmR+icnHjhEBlgRpVSNd0QPo82rMzQB8ESKMZM9z0wVG+PhTA0yVU+A nTWWc1Cx75S4xPwOgwj9pcszvJsKh8WsfKBk45JqBQ8/SXB9LDsXjFg81sTlxXxPqEYH 9l+nxBq3QqlWxGPwYsrYfkJBonudNWJl1SgpzzJA4RQtOCWx900w3bbVu384HnsQjRXv 0K+zAF+xviCZT3wjOhVbVcyjDnBXdGCCHd+UCr7PCbXZw/0KF1wuYjOSgScHYH2spuuJ sKFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=V0P8bQ5WjlFKq22SfkAH5yNC6yEfHw1X8LgprwMsZ2g=; b=F1Ae+letdSGlC3r6FlcfZbkI5HXZZdkE7KBB2kNXpWVqdLTVnstCewQZvl0/qSoBBV PmrJlMne5D6n1HLK1ZcID8Kfq+xR2AKeE5o1wKDNk6vEDZt5NIZ/HvP+sU2YsdL0reag NrF2dAVjpa0OQVGM2tlePIHuPO+XWg4Rk3ggJrwZzVOHgwp49Snz8GGdYvV+KPh1BDER G8ODjtGi8K5YNT9pnGoOiwgp3YXP6jt+2MZcluzryaJMjpvVlkJGWty5epuEwkZD53hN q3iMALVrGGLLpdbDK0A0ELJrqMvUyrGIPgUM92yZV8ElOCTgDtXRAtYLCDnW1WhmC5yq Mvdg== X-Gm-Message-State: AKGB3mJAM0iAVMwILtMPD1Jm5vmcUPp4ZiR3TtF1hdcMukQ4L4bI2Hxr wmQ50GJni7vE8T7xdtX199z/LpEg8o6L6sKkLYo= X-Google-Smtp-Source: ACJfBovGHVdc8/6X0fnI74c1ciMkVTyqpvdNSvxZ6MR1Txum7yQsf8uW+TaYbExwJwcD3G+hHbpJSWI7VqbrnhuCi4M= X-Received: by 10.157.56.200 with SMTP id k8mr2572828ote.3.1513189693841; Wed, 13 Dec 2017 10:28:13 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Dec 2017 13:28:13 -0500 From: Alvaro Retana X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Wed, 13 Dec 2017 13:28:13 -0500 Message-ID: To: dcrouting@ietf.org, routing-discussion@ietf.org Cc: roll@ietf.org, rtg-dir@ietf.org, ospf@ietf.org, isis-wg@ietf.org, babel@ietf.org, manet@ietf.org Content-Type: multipart/alternative; boundary="001a11c01f182de59c05603cee49" Archived-At: Subject: Re: [OSPF] dcrouting BOF in Singapore (Mailing LIsts) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 13 Dec 2017 18:28:22 -0000 --001a11c01f182de59c05603cee49 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Adding routing-discussion, other IGP-focused WGs and rtg-dir, please feel free to forward.] Hi! As we move these efforts forward, we have now created two new mailing lists= : Routing In Fat Trees (rift): https://www.ietf.org/mailman/admin/rift Link State Vector Routing (lsvr): https://www.ietf.org/mailman/admin/lsvr If you are interested in either effort (or both!), please subscribe!! The next step is to discuss and agree on a suitable charter for each of the proposed WGs =E2=80=94 I have asked the proponents to start a discussion on= the respective lists in the next few days. The goal is to take the Charters to the IESG and have them approved significantly in advance of IETF 101. As a reminder, the focus of these efforts (resulting from the dcrouting BOF) is on new solutions: ones that require a standalone effort (WG) =E2=80= =93 It is not expected that work/discussions on related incremental enhancements in an existing WG be delayed or deferred. Thanks! Alvaro. On November 23, 2017 at 4:17:26 AM, Alvaro Retana (aretana.ietf@gmail.com) wrote: Hi! Thank you to everyone who participated in last week=E2=80=99s BOF!! After comparing notes with the BOF Chairs and my co-ADs, we believe there is good interest to start working on proposed charters for both RIFT and BGP-LS SPF. I will be working with the proponents on that in the next few weeks =E2=80=94 the current plan is for me to be the Responsible AD for bot= h of these efforts. Please stay tuned to this mailing list for further announcements on mailing lists and other details as we iron them out. Thanks!! Alvaro. --001a11c01f182de59c05603cee49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Adding routing-discussion, other IGP-focused WGs and rtg-dir, please feel free to forward.]


Hi!

As we move these efforts forward, we have now created two new mailing lists:

Routing In Fat Trees (rift):=C2=A0https://www.ietf.org/mailman/admin/rift=C2=A0
Link State Vector Routing (lsvr):=C2=A0https://www.ietf.org/mailman/admin/lsvr=C2=A0

If you are interested in either effort (or both!), please subscribe!!

The next step is to discuss and agree on a suitable charter for each of the proposed WGs =E2=80=94 I have asked the proponents to start a discussion on the respective lists in the next few days.=C2=A0 The goal is to take the Charters to the IESG and have them approved significantly in advance of IETF 101.

As a reminder, the focus of these efforts (resulting from the dcrouting BOF) is on new solutions: ones that require a standalone effort (WG) =E2=80=93 It is not expected that work/discussions on related incremental enhancements in an existing WG be delayed or deferred.

Thanks!

Alvaro.


On November 23, 2017 at 4:17:26 AM, Alvaro Retana (aretana.ietf@gmail.com) wrote:

Hi!

Thank you to everyone who participated in last week=E2=80=99s BOF!!

After comparing notes with the BOF Chairs and my co-ADs, we believe there is good interest to start working on proposed charters for both RIFT and BGP-LS SPF.=C2=A0 I will be working with the proponents on that in the next few weeks =E2=80=94 the current plan is for me to be the Responsible AD for both of these efforts.

Please stay tuned to this mailing list for further announcements on mailing lists and other details as we iron them out.

Thanks!!

Alvaro.
--001a11c01f182de59c05603cee49-- From nobody Wed Dec 13 10:38:13 2017 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 301B212714F; Wed, 13 Dec 2017 10:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 BRSrEqhut57o; Wed, 13 Dec 2017 10:38:05 -0800 (PST) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::242]) (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 2B283124D6C; Wed, 13 Dec 2017 10:38:05 -0800 (PST) Received: by mail-ot0-x242.google.com with SMTP id j2so2784287ota.13; Wed, 13 Dec 2017 10:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=h4/MaJNvomeevDTG3p2QGnvNfz5lYyi8YqsJZXJN6fg=; b=kmJNkvfqMG7zHI5j8Dy7ulTiLzIxxmOiOQ2UMhuqiiIo3VvZJWsHPa/+FsOC07OQpl +SvRRMbFFH1mr5TxBSoL0Xx/7SA4wmDEBVib4xa6CiswMEQDIw0HGUpO/gbOJQ5Nf+m2 z1zzUM5fTh5dxgmXa3ZAt57dVw5N+Bg8fcXdLjarSuV0Dy/iSq50tWLHhDs1KEzym1RI qh3o6G9/8+7ZBsssG1XoLcE6TQFUfxB5MemwOEvLuPkN1NEzADUX7nzPF5QCaOhUo7ot qN0HmLRk1KrQGew9VRj54k8yD+EhPSKifSsTg+fJjvKGaLhGj/Aq2ynDTJR77Sic3rPX 2RCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=h4/MaJNvomeevDTG3p2QGnvNfz5lYyi8YqsJZXJN6fg=; b=KFRtxM977g4zWdFxPNHs8ZmOH0GwNWJCGaRfLWi4XhwoalOGuNDF0QOxY7rgblOPHX Nodftw5aFWj0T9JJZyKlmkgkY6KRqDnTzelNdaaOW976HQrt9NDE4IusqGArU4Hm6+QO WBOVC1qvaYoLqfQj8wc3s6AdPce+XenlcmHdbaF7q2ltu1NeauUXMQn+8s6p5MK5ZTzH mq2M4z1RVi2xcUa5QcXFjuFY8nco6C2ODTPMWtLKMqxgc/H0piE+G44jCVym97h2tBZW pu81R3hrQ9KRMXAE6FF/tpyQPnk0rs5seg6HSTi873z827Gcuo491kmYL+AG/cKQI7Ci 2/Iw== X-Gm-Message-State: AKGB3mKZ6D7X9RkC5LPYDMVhTb/h3UEhys+Wao+hMAHkmTuhfz5Al2wg 0t1TZ4nH0EwWQAT/U3GR1mamrl29Ko/Fhd3B0AM= X-Google-Smtp-Source: ACJfBotpLlXPuBOGfX0NjCGgKZu8AlVokF1wzRavzTLXSYY6z+rI3XPTt2/6xhTMUQumWUO9ujKSoDeh/EfqRSj31M8= X-Received: by 10.157.56.200 with SMTP id k8mr2593526ote.3.1513190284506; Wed, 13 Dec 2017 10:38:04 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Dec 2017 13:38:04 -0500 From: Alvaro Retana In-Reply-To: References: X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Wed, 13 Dec 2017 13:38:04 -0500 Message-ID: To: dcrouting@ietf.org, routing-discussion@ietf.org Cc: babel@ietf.org, manet@ietf.org, ospf@ietf.org, roll@ietf.org, rtg-dir@ietf.org, isis-wg@ietf.org Content-Type: multipart/alternative; boundary="001a11c01f1862b98605603d1194" Archived-At: Subject: Re: [OSPF] dcrouting BOF in Singapore (Mailing LIsts) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 13 Dec 2017 18:38:07 -0000 --001a11c01f1862b98605603d1194 Content-Type: text/plain; charset="UTF-8" Sorry, here are the right links: rift: https://www.ietf.org/mailman/listinfo/rift lsvr: https://www.ietf.org/mailman/listinfo/lsvr Thanks to the eager people already subscribing for pointing this out! Alvaro. On December 13, 2017 at 10:28:13 AM, Alvaro Retana (aretana.ietf@gmail.com) wrote: Routing In Fat Trees (rift): https://www.ietf.org/mailman/admin/rift Link State Vector Routing (lsvr): https://www.ietf.org/mailman/admin/lsvr --001a11c01f1862b98605603d1194 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Sorry, here are the right links:

lsvr:=C2=A0<= a href=3D"https://www.ietf.org/mailman/listinfo/lsvr">https://www.ietf.org/= mailman/listinfo/lsvr=C2=A0

Thanks to the eager people already subscribing for pointing this= out!=C2=A0
<= br>
Alvaro.

On December 13, 2017 at 10:28:13 AM, Alvar= o Retana (aretana.ietf@gmail.com<= /a>) wrote:

Link State Vector Routing (lsvr):=C2=A0https://www.ietf.org/mailman/a= dmin/lsvr=C2=A0

--001a11c01f1862b98605603d1194-- From nobody Wed Dec 13 11:52:48 2017 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 465F1126D45; Wed, 13 Dec 2017 11:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, 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 ZEfjp7PQmjKM; Wed, 13 Dec 2017 11:52:42 -0800 (PST) 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 946CF126B71; Wed, 13 Dec 2017 11:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5366; q=dns/txt; s=iport; t=1513194762; x=1514404362; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yqXFtUFLrnRKR5x56DMo8gjX/ChQFG4sJxacIowUChk=; b=aWKv/qIUGLa8bkKeyT68Er6l8SAWylVccGlHBxgFkem1OvdjRJFAzcL5 ZFfvFcJUIDj5NfldBMlipSzcSNSNdWf4NQytIyWUOZ3lkhn1AfHsBtc2G Q9dw4i6/pMONDLnL7nbX7z15a0goHSixYth1aPrC9O2eOJNuaLfUllie4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAACLhDFa/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPBpkOFIIBCiWFFgIahHk/GAEBAQEBAQEBAWs?= =?us-ascii?q?ohSQGIxFFEAIBCA4MAh8HAgICMBUQAgQBDQWKKBCoZIInimEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYEPglGCC4M/gyuDLgEBgToBEgEJgyuCYwWKSphVAod5g3G?= =?us-ascii?q?JO4IWhhKED4cxjRCJKQIRGQGBOgEfOWBWGG8VgmODCIFOeAGHcoEkgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,398,1508803200"; d="scan'208";a="43687284" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2017 19:52:41 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vBDJqfNG032205 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 19:52:41 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.1320.4; Wed, 13 Dec 2017 14:52:40 -0500 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.1320.000; Wed, 13 Dec 2017 14:52:40 -0500 From: "Acee Lindem (acee)" To: Alexey Melnikov , The IESG CC: "draft-ietf-ospf-segment-routing-extensions@ietf.org" , "ospf-chairs@ietf.org" , "ospf@ietf.org" Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT) Thread-Index: AQHTc//QW8KMe4rBDkeHYsGEb/PtbKNBr9QA Date: Wed, 13 Dec 2017 19:52:40 +0000 Message-ID: References: <151316206521.30067.6744549826451674092.idtracker@ietfa.amsl.com> In-Reply-To: <151316206521.30067.6744549826451674092.idtracker@ietfa.amsl.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.198] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 13 Dec 2017 19:52:46 -0000 SGkgQWxleGV5DQoNClRoZXNlIGFsbCBzZWVtIHRvIGJlIHZhbGlkIGNvbW1lbnRzIGV4Y2VwdCBm b3IgdGhlIG9uZSBvbiBieXRlIG9yZGVyLiBOb3RlDQp0aGF0IHNlY3Rpb24gMy4xIG9mIFJGQyAy MzYwIGFscmVhZHkgc3RhdGVzIHRoYXQgSUVURiBkb2N1bWVudCBwYWNrZXQNCmVuY29kaW5ncyBh cmUgaW4gTmV0d29yay1CeXRlIE9yZGVyIChOQk8pLg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj L3JmYzIzNjAudHh0DQoNClR5cGljYWxseSwgd2UgaGF2ZSBub3QgZGVmaW5lZCBSZXNlcnZlZCBm aWVsZCB1c2FnZS4gSG93ZXZlciwgSSBndWVzcyB3ZQ0KY291bGQgc2F5IHRoYXQgdGhleSBTSE9V TEQgYmUgc2V0IHRvIDAgb24gdHJhbnNtaXNzaW9uIGFuZCBNVVNUIGJlIGlnbm9yZWQNCm9uIHJl Y2VwdGlvbi4gVGhpcyB3aWxsIGFsbG93IGZvciBmdXR1cmUgcmV1c2UgaW4gYSBiYWNrd2FyZCBj b21wYXRpYmxlDQptYW5uZXIuIA0KDQpUaGFua3MsDQpBY2VlIA0KDQoNCg0KDQoNCk9uIDEyLzEz LzE3LCA1OjQ3IEFNLCAiQWxleGV5IE1lbG5pa292IiA8YWFtZWxuaWtvdkBmYXN0bWFpbC5mbT4g d3JvdGU6DQoNCj5BbGV4ZXkgTWVsbmlrb3YgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxs b3QgcG9zaXRpb24gZm9yDQo+ZHJhZnQtaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNp b25zLTIzOiBEaXNjdXNzDQo+DQo+V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ZW1haWwgYWRkcmVzc2VzIGluY2x1 ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj5pbnRy b2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4NCj4NCj5QbGVhc2UgcmVmZXIgdG8gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCj4NCj4NCj5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0 aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb24NCj5zLw0KPg0KPg0K Pg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj5ESVNDVVNTOg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj5UaGlzIGlz IGdlbmVyYWxseSBhIGNsZWFybHkgd3JpdHRlbiBkb2N1bWVudCwgYnV0IGl0IG5lZWRzIGEgZmV3 IG1pbm9yDQo+Y2hhbmdlcw0KPmJlZm9yZSBJIGNhbiByZWNvbW1lbmQgaXRzIGFwcHJvdmFsIGZv ciBwdWJsaWNhdGlvbi4NCj4NCj4xKSBJbiBTZWN0aW9uIDMuMjoNCj4NCj4gICBvICBXaGVuIGEg cm91dGVyIHJlY2VpdmVzIG11bHRpcGxlIG92ZXJsYXBwaW5nIHJhbmdlcywgaXQgTVVTVA0KPiAg ICAgIGNvbmZvcm0gdG8gdGhlIHByb2NlZHVyZXMgZGVmaW5lZCBpbg0KPiAgICAgIFtJLUQuaWV0 Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbl0uDQo+DQo+UkZDIDIxMTkga2V5d29yZCB1c2Fn ZSBtYWtlcyB0aGUgcmVmZXJlbmNlIGEgTm9ybWF0aXZlIHJlZmVyZW5jZSwgeWV0IGl0DQo+aXMN Cj5jdXJyZW50bHkgbGlzdGVkIGFzIGluZm9ybWF0aXZlLg0KPg0KPjMuNC4gIFNSTVMgUHJlZmVy ZW5jZSBUTFYNCj4NCj4gICBUaGUgU2VnbWVudCBSb3V0aW5nIE1hcHBpbmcgU2VydmVyIFByZWZl cmVuY2UgVExWIChTUk1TIFByZWZlcmVuY2UNCj4gICBUTFYpIGlzIHVzZWQgdG8gYWR2ZXJ0aXNl IGEgcHJlZmVyZW5jZSBhc3NvY2lhdGVkIHdpdGggdGhlIG5vZGUgdGhhdA0KPiAgIGFjdHMgYXMg YW4gU1IgTWFwcGluZyBTZXJ2ZXIuICBUaGUgcm9sZSBvZiBhbiBTUk1TIGlzIGRlc2NyaWJlZCBp bg0KPiAgIFtJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLWxkcC1pbnRlcm9wXS4NCj4N Cj5BcyBkcmFmZi1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3AgbmVlZHMg dG8gYmUgcmVhZCBpbg0KPm9yZGVyIHRvDQo+dW5kZXJzdGFuZCB3aGF0IFNSIE1hcHBpbmcgU2Vy dmVyIGlzLCB0aGlzIHJlZmVyZW5jZSBtdXN0IGFsc28gYmUNCj5Ob3JtYXRpdmUuDQo+DQo+ICBT Uk1TIHByZWZlcmVuY2UgaXMgZGVmaW5lZCBpbiBbSS1ELmlldGYtc3ByaW5nLWNvbmZsaWN0LXJl c29sdXRpb25dLg0KPg0KPlRoaXMganVzdCBjb25maXJtcyB0aGF0IHRoaXMgcmVmZXJlbmNlIG11 c3QgYmUgTm9ybWF0aXZlLg0KPg0KPjIpIEluIFNlY3Rpb24gMy4xOg0KPg0KPiAgIFdoZW4gbXVs dGlwbGUgU1ItQWxnb3JpdGhtIFRMVnMgYXJlIHJlY2VpdmVkIGZyb20gYSBnaXZlbiByb3V0ZXIs IHRoZQ0KPiAgIHJlY2VpdmVyIFNIT1VMRCB1c2UgdGhlIGZpcnN0IG9jY3VycmVuY2Ugb2YgdGhl IFRMViBpbiB0aGUgUm91dGVyDQo+ICAgSW5mb3JtYXRpb24gTFNBLiAgSWYgdGhlIFNSLUFsZ29y aXRobSBUTFYgYXBwZWFycyBpbiBtdWx0aXBsZSBSb3V0ZXINCj4gICBJbmZvcm1hdGlvbiBMU0Fz IHRoYXQgaGF2ZSBkaWZmZXJlbnQgZmxvb2Rpbmcgc2NvcGVzLCB0aGUgU1ItDQo+ICAgQWxnb3Jp dGhtIFRMViBpbiB0aGUgUm91dGVyIEluZm9ybWF0aW9uIExTQSB3aXRoIHRoZSBhcmVhLXNjb3Bl ZA0KPiAgIGZsb29kaW5nIHNjb3BlIFNIT1VMRCBiZSB1c2VkLiAgSWYgdGhlIFNSLUFsZ29yaXRo bSBUTFYgYXBwZWFycyBpbg0KPiAgIG11bHRpcGxlIFJvdXRlciBJbmZvcm1hdGlvbiBMU0FzIHRo YXQgaGF2ZSB0aGUgc2FtZSBmbG9vZGluZyBzY29wZSwNCj4gICB0aGUgU1ItQWxnb3JpdGhtIFRM ViBpbiB0aGUgUm91dGVyIEluZm9ybWF0aW9uIChSSSkgTFNBIHdpdGggdGhlDQo+ICAgbnVtZXJp Y2FsbHkgc21hbGxlc3QgSW5zdGFuY2UgSUQgU0hPVUxEIGJlIHVzZWQgYW5kIHN1YnNlcXVlbnQN Cj4gICBpbnN0YW5jZXMgb2YgdGhlIFNSLUFsZ29yaXRobSBUTFYgU0hPVUxEIGJlIGlnbm9yZWQu DQo+DQo+SW4gdGhlIGxhc3QgMiBzZW50ZW5jZXM6IHdoeSBhcmUgeW91IHVzaW5nIFNIT1VMRCAo dHdpY2UpIGluc3RlYWQgb2YNCj5NVVNUPyBUaGlzDQo+c2VlbXMgdG8gYWZmZWN0IGludGVyb3Bl cmFiaWxpdHkuDQo+DQo+KEkgdGhpbmsgdGhlcmUgaXMgc2ltaWxhciB0ZXh0IGluIGFub3RoZXIg c2VjdGlvbi4pDQo+DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPg0KPlNldmVyYWwgVExWcyBoYXZlICJSZXNlcnZlZCIgZmllbGRzLCB5ZXQgeW91IG5ldmVy IGV4cGxhaW4gd2hhdCAiUmVzZXJ2ZWQiDQo+bWVhbnMuIFlvdSBkbyBleHBsYWluIHdoYXQgcmVz ZXJ2ZWQgZmxhZ3MgbWVhbiBpbiBzb21lIG9mIHRoZW0uIEkgc3VnZ2VzdA0KPmVpdGhlciBleHBs aWNpdGx5IGV4cGxhaW5pbmcgd2hhdCBSZXNlcnZlZCBtZWFucyBpbiBlYWNoIGNhc2Ugb3Igc3Bl Y2lmeQ0KPnRoaXMNCj5pbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBuZWFyIHRoZSBiZWdpbm5p bmcgb2YgdGhlIGRvY3VtZW50Lg0KPg0KPlRoZSBkb2N1bWVudCBuZXZlciBzcGVjaWZpZXMgYnl0 ZSBvcmRlciBmb3IgbGVuZ3RoIGZpZWxkcy4NCj4NCj5UaGUgYWNyb255bSBOU1NBIGlzIG5ldmVy IGV4cGxhaW5lZCBhbmQgaXQgaGFzIG5vIHJlZmVyZW5jZS4NCj4NCj4NCg0K From nobody Wed Dec 13 11:57:39 2017 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 6AAA012009C; Wed, 13 Dec 2017 11:57:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Acee Lindem To: X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Cc: ospf@ietf.org, iesg-secretary@ietf.org, acee@cisco.com, ospf-chairs@ietf.org, Acee Lindem Message-ID: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> Date: Wed, 13 Dec 2017 11:57:37 -0800 Archived-At: Subject: [OSPF] Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 19:57:37 -0000 Acee Lindem has requested publication of draft-ietf-ospf-link-overload-10 as Proposed Standard on behalf of the OSPF working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ From nobody Wed Dec 13 11:58:12 2017 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 60908128D2E for ; Wed, 13 Dec 2017 11:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, 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 IKQDCVNF1E2g for ; Wed, 13 Dec 2017 11:58:09 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B9D128CDC for ; Wed, 13 Dec 2017 11:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4363; q=dns/txt; s=iport; t=1513195089; x=1514404689; h=from:to:subject:date:message-id:mime-version; bh=/zO/iS67qM88cMWh9pi72VpcLOluPZMxqNQ3UTD5V5c=; b=LxecTfmlnId2IkDWpwQzmldUDYhq/vk5Q1IrFCldBHcuniZwQIO7l4cW FsYPXJAIjLCd/AyAQLYlQt6Llglrn1Ihlq7XmSwHFTN9chLXUhaXsW9mL fUbEJsEYd0l0bmch6hqqkzTrU8aTQmaSsrFHJTzVpPxVOH0zaupLQrcFq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DtAAC4hTFa/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdGZ0FRIHg3tjiT6PBoF9kUSFTYIVCiOFGByEeT8YAQEBAQE?= =?us-ascii?q?BAQEBayiFIwEGHQZoAQgEDQMBAiQEAwIEMBQJCgQBEolEZBCoZIInimEBAQEBA?= =?us-ascii?q?QUBAQEBAQEdBYNggguDP4Mrgy4Bgg6CdYJjBaMfApUlghaGEotAljkCERkBgTo?= =?us-ascii?q?BHzmBTm8VOoIpgwiBTngBiRaBFQEBAQ?= X-IronPort-AV: E=Sophos; i="5.45,398,1508803200"; d="scan'208,217"; a="43701904" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2017 19:57:08 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBDJv8Be023399 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Dec 2017 19:57:08 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.1320.4; Wed, 13 Dec 2017 14:57:07 -0500 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.1320.000; Wed, 13 Dec 2017 14:57:07 -0500 From: "Acee Lindem (acee)" To: "Acee Lindem (acee)" , OSPF WG List Thread-Topic: [OSPF] OSPF Working Group Last Call for "OSPF Link Overload" - draft-ietf-ospf-link-overload-10 Thread-Index: AQHTdEyOL1SVHWa35UGTaX1bVLyOvg== Date: Wed, 13 Dec 2017 19:57:07 +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.198] Content-Type: multipart/alternative; boundary="_000_D656F01AE14F4aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] OSPF Working Group Last Call for "OSPF Link Overload" - draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 13 Dec 2017 19:58:11 -0000 --_000_D656F01AE14F4aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFdHIExhc3QgQ2FsbCBoYXMgY29tcGxldGVkLiBJ4oCZbSByZXF1ZXN0aW5nIHB1YmxpY2F0 aW9uIGFuZCBJQU5BIEVhcmx5IGFsbG9jYXRpb24gb2YgdGhlIGNvZGUgcG9pbnRzLg0KVGhhbmtz LA0KQWNlZQ0KDQpGcm9tOiBPU1BGIDxvc3BmLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9zcGYt Ym91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5j b208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCkRhdGU6IFR1ZXNkYXksIE5vdmVtYmVyIDI4LCAy MDE3IGF0IDk6MTIgQU0NClRvOiBPU1BGIFdHIExpc3QgPG9zcGZAaWV0Zi5vcmc8bWFpbHRvOm9z cGZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW09TUEZdIE9TUEYgV29ya2luZyBHcm91cCBMYXN0IENh bGwgZm9yICJPU1BGIExpbmsgT3ZlcmxvYWQiIC0gZHJhZnQtaWV0Zi1vc3BmLWxpbmstb3Zlcmxv YWQtMTANCg0KVGhpcyBiZWdpbnMgdGhlIE9TUEYgV29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9y IHRoZSBzdWJqZWN0IGRvY3VtZW50LiBQbGVhc2Ugc3VibWl0IGNvbW1lbnRzIHRvIHRoaXMgbGlz dCBiZWZvcmUgMTI6MDAgQU0gUFNUIG9uIFdlZG5lc2RheSwgRGVjZW1iZXIgMTN0aCwgMjAxNy4g Rm9yIHlvdXIgY29udmVuaWVuY2UsIGhlcmUgaXMgYSBVUkwgZm9yIHRoZSBkcmFmdDoNCg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1vc3BmLWxpbmstb3ZlcmxvYWQtMTAudHh0 DQoNClRoYW5rcywNCkFjZWUNCg== --_000_D656F01AE14F4aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9240D694F79F304CB233DA79CAE0CCCA@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5UaGUgV0cgTGFz dCBDYWxsIGhhcyBjb21wbGV0ZWQuIEnigJltIHJlcXVlc3RpbmcgcHVibGljYXRpb24gYW5kIElB TkEgRWFybHkgYWxsb2NhdGlvbiBvZiB0aGUgY29kZSBwb2ludHMuJm5ic3A7PC9kaXY+DQo8ZGl2 PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsg Qk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFE RElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsg Qk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206 IDwvc3Bhbj5PU1BGICZsdDs8YSBocmVmPSJtYWlsdG86b3NwZi1ib3VuY2VzQGlldGYub3JnIj5v c3BmLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQWNlZSBMaW5kZW0gJmx0 OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSI+YWNlZUBjaXNjby5jb208L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwg Tm92ZW1iZXIgMjgsIDIwMTcgYXQgOToxMiBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5UbzogPC9zcGFuPk9TUEYgV0cgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9zcGZA aWV0Zi5vcmciPm9zcGZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W09TUEZdIE9TUEYgV29ya2luZyBHcm91cCBMYXN0 IENhbGwgZm9yICZxdW90O09TUEYgTGluayBPdmVybG9hZCZxdW90OyAtIGRyYWZ0LWlldGYtb3Nw Zi1saW5rLW92ZXJsb2FkLTEwPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JE RVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1 OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7Ij4NCjxkaXY+VGhpcyBiZWdpbnMgdGhlIE9TUEYgV29ya2luZyBHcm91cCBM YXN0IENhbGwgZm9yIHRoZSBzdWJqZWN0IGRvY3VtZW50LiBQbGVhc2Ugc3VibWl0IGNvbW1lbnRz IHRvIHRoaXMgbGlzdCBiZWZvcmUgMTI6MDAgQU0gUFNUIG9uIFdlZG5lc2RheSwgRGVjZW1iZXIg MTN0aCwgMjAxNy4gRm9yIHlvdXIgY29udmVuaWVuY2UsIGhlcmUgaXMgYSBVUkwgZm9yIHRoZSBk cmFmdDo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtb3NwZi1saW5rLW92ZXJsb2FkLTEwLnR4dCI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1vc3BmLWxpbmstb3ZlcmxvYWQtMTAudHh0PC9h PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2Vl Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_D656F01AE14F4aceeciscocom_-- From nobody Wed Dec 13 13:15:02 2017 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 D566A126B7E; Wed, 13 Dec 2017 13:15:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-ospf-segment-routing-extensions@ietf.org, Acee Lindem , ospf-chairs@ietf.org, acee@cisco.com, ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151319970086.30105.10327182151493185093.idtracker@ietfa.amsl.com> Date: Wed, 13 Dec 2017 13:15:00 -0800 Archived-At: Subject: [OSPF] Suresh Krishnan's No Objection on draft-ietf-ospf-segment-routing-extensions-23: (with COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 21:15:01 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-ospf-segment-routing-extensions-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * It would be good to clarify that this document is intended for OSPFv2 only (probably in the title and/or abstract). It may also be worthwhile for the document and/or the Shepherd writeup to explain why the WG decided to separate the OSPFv3 extensions into a different document. * I think RFC2328 should be a Normative Reference and not an informative reference. From nobody Wed Dec 13 16:40:03 2017 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 AFDD91200F1 for ; Wed, 13 Dec 2017 16:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 4bQOP56kX2Fv for ; Wed, 13 Dec 2017 16:40:00 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14B51243FE for ; Wed, 13 Dec 2017 16:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1118; q=dns/txt; s=iport; t=1513211999; x=1514421599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dopiJGFKEHgAxwas0vvQ3FH3SL5trgAR9UlUkKyJecs=; b=Mh7K5huWkP/W3Jda+EicI9rGBIFy8ermtHS8WwPiQV/VihMiTbJzO15X rJwn5hjlUS3rVMPZm0GQbduqOCCjW+x/mz8NzF2phqhxY/C4E1CzRw/zV R7l3gUhtY9EIn8upynbRsf+0Y9jW7mpJ3rMA+8bf9+loNLO5WUOqVNd9b A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAAAzxzFa/4sNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPB5kOghUKI4UYAhqEeT8YAQEBAQEBAQEBayi?= =?us-ascii?q?FJAYjEUUQAgEIGgImAgICMBUGAQYDAgQOBYooEKkbgieKXwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgQ+CUYILgz+DK4MuAQGFAoJjBaMfAod5jSyCFoYSi0CNEIk?= =?us-ascii?q?pAhEZAYE6AR85gU5vFYJjhFZ4iReBFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,399,1508803200"; d="scan'208";a="330284492" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2017 00:39:59 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vBE0dwGf023275 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 00:39:59 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.1320.4; Wed, 13 Dec 2017 19:39:58 -0500 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.1320.000; Wed, 13 Dec 2017 19:39:58 -0500 From: "Acee Lindem (acee)" To: IANA CC: OSPF WG List Thread-Topic: Publication has been requested for draft-ietf-ospf-link-overload-10 Thread-Index: AQHTdHQRIguhjQmtOke8EJ3PPxRuDA== Date: Thu, 14 Dec 2017 00:39:58 +0000 Message-ID: References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> In-Reply-To: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.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.198] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [OSPF] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 00:40:03 -0000 UGxlYXNlIHByb3ZpZGUgYWxsb2NhdGlvbnMgZm9yIHRoZSBjb2RlIHBvaW50cyBpbg0KZHJhZnQt aWV0Zi1vc3BmLWxpbmstb3ZlcmxvYWQtMTAudHh0Og0KDQogT1NQRiBFeHRlbmRlZCBMaW5rIFRM VnMgUmVnaXN0cnkNCg0KICAgaSkgTGluay1PdmVybG9hZCBzdWItVExWIC0gU3VnZ2VzdGVkIHZh bHVlIDUNCg0KICAgaWkpIFJlbW90ZSBJUHY0IGFkZHJlc3Mgc3ViLVRMViAtIFN1Z2dlc3RlZCB2 YWx1ZSA0DQoNCiAgIGlpaSkgTG9jYWwvUmVtb3RlIEludGVyZmFjZSBJRCBzdWItVExWIC0gU3Vn Z2VzdGVkIFZhbHVlIDExDQoNCiAgIE9TUEZWMyBSb3V0ZXIgTGluayBUTFYgUmVnaXN0cnkNCg0K ICAgaSkgTGluay1PdmVybG9hZCBzdWItVExWIC0gc3VnZ2VzdGVkIHZhbHVlIDQNCg0KICAgQkdQ LUxTIExpbmsgTkxSSSBSZWdpc3RyeSBbUkZDNzc1Ml0NCg0KaSlMaW5rLU92ZXJsb2FkIFRMViAt IFN1Z2dlc3RlZCAxMTAxDQoNClRoYW5rcywNCg0KQWNlZSANCg0KT24gMTIvMTMvMTcsIDI6NTcg UE0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5BY2Vl IExpbmRlbSBoYXMgcmVxdWVzdGVkIHB1YmxpY2F0aW9uIG9mIGRyYWZ0LWlldGYtb3NwZi1saW5r LW92ZXJsb2FkLTEwDQo+YXMgUHJvcG9zZWQgU3RhbmRhcmQgb24gYmVoYWxmIG9mIHRoZSBPU1BG IHdvcmtpbmcgZ3JvdXAuDQo+DQo+UGxlYXNlIHZlcmlmeSB0aGUgZG9jdW1lbnQncyBzdGF0ZSBh dA0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3NwZi1saW5r LW92ZXJsb2FkLw0KPg0KDQo= From nobody Wed Dec 13 16:42:27 2017 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 427951243FE for ; Wed, 13 Dec 2017 16:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BTQJiJBzh84G for ; Wed, 13 Dec 2017 16:42:23 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 455E61200F1 for ; Wed, 13 Dec 2017 16:42:23 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id e74so3588732ote.7 for ; Wed, 13 Dec 2017 16:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1IVPjcSU2SOGM8jbojlAZzC4pG7g6Jd1ZCRbuJD/hdE=; b=Tb7470kAAgTdAxmTMps9ZV1c5rxYtcgbcqnqf3QwFD+nftcdaWA8oy9vuWfX7ak469 vrS6vJiyY8wRCPL4JlGVV8tTjUJMnET2kwS6DahYApWUP/W7XSYdAjHy2keHKJIeEiC+ ssyx7KW6s6iX6Am9Bc8OYISQ4mrcVKlILcD2RK4gfmA8izHGbsZm3EoPfz1kA8rAG2Sj X+33jAxw4t11U3rotD52qIk9FEplTi8hazqHWWI3ZVLT7dkoMYyUl3wMI1vNg23ru//S bCs2fwmMPvQun/rqYRqS7Sn1/k/uzlXybmd8CnfyusoYlDBbs6BliKVIQXsTWpuwUT/j 3F3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1IVPjcSU2SOGM8jbojlAZzC4pG7g6Jd1ZCRbuJD/hdE=; b=DA4Wl6OyYey0JKFnjBkeMp813SLgCfdOVu4YpIlaALMy2bbI9TdmynHHVGGjJali7v YKQYFrk6BTYYl90sl5cKOAKtz+nm1b6Fj5EGSBYmoQ59S6hClwzcnTOe7El4aSSkxZqe oSyPoBNTI2v1oJZ5mjTcCmO3pdaulHchIG++3aITf1XRKZDimj/xcIHC3KyCJ9Az375I 1iNpSYmbXcL+6t1TgYPQ00mTJ81S+SYr0oL8EHLsyhN5IBem2RUkKigLtgxlyj9sBJSP oV+FnA2917872iARlhs85fxoJltTdla3PwtXXC+HBy9qwOv4duP69uFdZB58YcyqbNAe wJ7Q== X-Gm-Message-State: AKGB3mKiUFOruCk9Ez+PoZ8ORuRw5fzkt1uHifo0Jd95NU37ivzhk+Lf KP8dRkn2g7/VFXNg1FvvfJ+/RDLFwTF+nnRaJng= X-Google-Smtp-Source: ACJfBouYnb7TgrIOd7nobGu6VcQcH7PqOOXhfwT2jMhc+y5TGBoK37W2182oXi5UBxPFXU+4/rGYtoz2sUzyP/Sr5Kw= X-Received: by 10.157.47.34 with SMTP id h31mr3689632otb.362.1513212142482; Wed, 13 Dec 2017 16:42:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.0.143 with HTTP; Wed, 13 Dec 2017 16:42:21 -0800 (PST) In-Reply-To: References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> From: Alia Atlas Date: Wed, 13 Dec 2017 19:42:21 -0500 Message-ID: To: "Acee Lindem (acee)" Cc: IANA , OSPF WG List Content-Type: multipart/alternative; boundary="94eb2c0442b038f97d05604228a3" Archived-At: Subject: Re: [OSPF] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 00:42:25 -0000 --94eb2c0442b038f97d05604228a3 Content-Type: text/plain; charset="UTF-8" approved On Wed, Dec 13, 2017 at 7:39 PM, Acee Lindem (acee) wrote: > Please provide allocations for the code points in > draft-ietf-ospf-link-overload-10.txt: > > OSPF Extended Link TLVs Registry > > i) Link-Overload sub-TLV - Suggested value 5 > > ii) Remote IPv4 address sub-TLV - Suggested value 4 > > iii) Local/Remote Interface ID sub-TLV - Suggested Value 11 > > OSPFV3 Router Link TLV Registry > > i) Link-Overload sub-TLV - suggested value 4 > > BGP-LS Link NLRI Registry [RFC7752] > > i)Link-Overload TLV - Suggested 1101 > > Thanks, > > Acee > > On 12/13/17, 2:57 PM, "Acee Lindem (acee)" wrote: > > >Acee Lindem has requested publication of draft-ietf-ospf-link-overload-10 > >as Proposed Standard on behalf of the OSPF working group. > > > >Please verify the document's state at > >https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --94eb2c0442b038f97d05604228a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
approved

On Wed, Dec 13, 2017 at 7:39 PM, Acee Lindem (acee) <acee@cisco= .com> wrote:
Please provide= allocations for the code points in
draft-ietf-ospf-link-overload-10.txt:

=C2=A0OSPF Extended Link TLVs Registry

=C2=A0 =C2=A0i) Link-Overload sub-TLV - Suggested value 5

=C2=A0 =C2=A0ii) Remote IPv4 address sub-TLV - Suggested value 4

=C2=A0 =C2=A0iii) Local/Remote Interface ID sub-TLV - Suggested Value 11
=C2=A0 =C2=A0OSPFV3 Router Link TLV Registry

=C2=A0 =C2=A0i) Link-Overload sub-TLV - suggested value 4

=C2=A0 =C2=A0BGP-LS Link NLRI Registry [RFC7752]

i)Link-Overload TLV - Suggested 1101

Thanks,

Acee

On 12/13/17, 2:57 PM, "Acee Lindem (acee)" <acee@cisco.com> wrote:

>Acee Lindem has requested publication of draft-ietf-ospf-link-overload-= 10
>as Proposed Standard on behalf of the OSPF working group.
>
>Please verify the document's state at
>https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
>

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

--94eb2c0442b038f97d05604228a3-- From nobody Wed Dec 13 18:43:13 2017 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 2277D120727; Wed, 13 Dec 2017 18:43:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-ospf-segment-routing-extensions@ietf.org, Acee Lindem , ospf-chairs@ietf.org, acee@cisco.com, ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151321938613.6116.16631743860290967254.idtracker@ietfa.amsl.com> Date: Wed, 13 Dec 2017 18:43:06 -0800 Archived-At: Subject: [OSPF] Ben Campbell's No Objection on draft-ietf-ospf-segment-routing-extensions-23: (with COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 02:43:06 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ospf-segment-routing-extensions-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive Comments: - Requirements Language: There are a few instances of 2119 keywords in lower case. Please consider if those are meant to be normative. If not, then please use the boilerplate from RFC 8184, which explicitly excludes lower case instances as normative keywords. -3.1, 2nd to last paragraph: Why aren't the 3 "SHOULDs" "MUSTs"? It seems like these might have an impact on interoperability, or at least predictable behavior in edge conditions. -3.4: (same comment as for 3.1) Editorial Comments and Nits: -1, first paragraph: There are a lot of ideas packed into that paragraph. It's not clear to me which the "For example" sentences means to exemplify. -3.3, 2nd to last paragraph: Why is "NOT" capitalized? From nobody Thu Dec 14 00:52:33 2017 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 6B8641271DF for ; Thu, 14 Dec 2017 00:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 cHmETq17JuFQ for ; Thu, 14 Dec 2017 00:52:20 -0800 (PST) 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 00279120046 for ; Thu, 14 Dec 2017 00:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1470; q=dns/txt; s=iport; t=1513241540; x=1514451140; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=05/WP16yktAfu5RQqn+vE2GJtrg/89o6ky4niFJaX7s=; b=EyJveHA/kxVpkLEdHQbsz9zrxKE0TGyhsEjfzAXkWzK1mPbY+aRtoIic DalWWfxw27ZbM1mfJqikDckQPOX8S+lhBj75wDh1KnXK344US/vD6WYVl 8trCBAOSpqhGxWOpqeoDX1eRYviJq7rrDS0IwwDRb4+ugV5WC8FqpZTwt g=; X-IronPort-AV: E=Sophos;i="5.45,399,1508803200"; d="scan'208";a="848125" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 08:52:18 +0000 Received: from [10.60.140.55] (ams-ppsenak-nitro6.cisco.com [10.60.140.55]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vBE8qHgn003690; Thu, 14 Dec 2017 08:52:17 GMT Message-ID: <5A323BC6.80209@cisco.com> Date: Thu, 14 Dec 2017 09:52:22 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Acee Lindem (acee)" , IANA CC: OSPF WG List References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OSPF] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 08:52:23 -0000 Hi Acee, On 14/12/17 01:39 , Acee Lindem (acee) wrote: > Please provide allocations for the code points in > draft-ietf-ospf-link-overload-10.txt: > > OSPF Extended Link TLVs Registry more precisely, these should be allocated from "OSPFv2 Extended Link TLV Sub-TLVs" registry. The text in the draft should be updated as well to reflect the correct registry name. At this point it says "OSPF Extended Link TLVs Registry", which would suggest it is from a different, top level TLV registry. Also I see that value 5 has been taken by RFC8169 already. thanks, Peter > > i) Link-Overload sub-TLV - Suggested value 5 > > ii) Remote IPv4 address sub-TLV - Suggested value 4 > > iii) Local/Remote Interface ID sub-TLV - Suggested Value 11 > > OSPFV3 Router Link TLV Registry > > i) Link-Overload sub-TLV - suggested value 4 > > BGP-LS Link NLRI Registry [RFC7752] > > i)Link-Overload TLV - Suggested 1101 > > Thanks, > > Acee > > On 12/13/17, 2:57 PM, "Acee Lindem (acee)" wrote: > >> Acee Lindem has requested publication of draft-ietf-ospf-link-overload-10 >> as Proposed Standard on behalf of the OSPF working group. >> >> Please verify the document's state at >> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > . > From nobody Thu Dec 14 04:36:52 2017 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 6507C1200B9; Thu, 14 Dec 2017 04:36:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151325500636.6079.15082401751133959838@ietfa.amsl.com> Date: Thu, 14 Dec 2017 04:36:46 -0800 Archived-At: Subject: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-24.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 12:36:46 -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 WG of the IETF. Title : OSPF Extensions for Segment Routing Authors : Peter Psenak Stefano Previdi Clarence Filsfils Hannes Gredler Rob Shakir Wim Henderickx Jeff Tantsura Filename : draft-ietf-ospf-segment-routing-extensions-24.txt Pages : 29 Date : 2017-12-14 Abstract: Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv2 extensions required for Segment Routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-24 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-extensions-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-extensions-24 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 Dec 14 04:37:31 2017 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 3C256128BB7; Thu, 14 Dec 2017 04:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 MZTrSebFXnl5; Thu, 14 Dec 2017 04:37:28 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8797127A90; Thu, 14 Dec 2017 04:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1757; q=dns/txt; s=iport; t=1513255048; x=1514464648; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XI0ktvESymbNhRw3A53D9EzMduvu7VC8kgVI8S0jhKM=; b=nKMOxLbiZsW5HAnypCeSXrV+bo+YIwNaejD6ivfIvgxbxDslnAuCpeC3 1I4F7zF0rs313aS4e2atFMabz7GeyC1e4x5lhv6nHYSNExbhB/IiC4gVU PF9dltkC4avSxGsV2zOzxHzDqdrXOAsiv2VtcGfw0wokN/Y53dGlgG2VK c=; X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="860724" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 12:37:26 +0000 Received: from [10.147.24.18] ([10.147.24.18]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vBECbOxw005954; Thu, 14 Dec 2017 12:37:25 GMT Message-ID: <5A32708A.9040101@cisco.com> Date: Thu, 14 Dec 2017 13:37:30 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Suresh Krishnan , The IESG CC: draft-ietf-ospf-segment-routing-extensions@ietf.org, Acee Lindem , ospf-chairs@ietf.org, ospf@ietf.org References: <151319970086.30105.10327182151493185093.idtracker@ietfa.amsl.com> In-Reply-To: <151319970086.30105.10327182151493185093.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OSPF] Suresh Krishnan's No Objection on draft-ietf-ospf-segment-routing-extensions-23: (with COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 12:37:30 -0000 Hi Suresh, please see inline: On 13/12/17 22:15 , Suresh Krishnan wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-ospf-segment-routing-extensions-23: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * It would be good to clarify that this document is intended for OSPFv2 only > (probably in the title and/or abstract). I changed the text in the abstract, which now says: "This draft describes the OSPFv2 extensions required for Segment Routing." > It may also be worthwhile for the > document and/or the Shepherd writeup to explain why the WG decided to separate > the OSPFv3 extensions into a different document. OSPFv3 SR extensions are based on the draft-ietf-ospf-ospfv3-lsa-extend, which is OSPFv3 specific. That's why WG decided to use a separate document to describe OSPFv3 SR extensions. > > * I think RFC2328 should be a Normative Reference and not an informative > reference. done. Please see the updated version at: https://www.ietf.org/internet-drafts/draft-ietf-ospf-segment-routing-extensions-24.txt thanks, Peter > > > . > From nobody Thu Dec 14 04:37:57 2017 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 4B6051292AE; Thu, 14 Dec 2017 04:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 75FoYUUdBLxX; Thu, 14 Dec 2017 04:37:38 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92850127A90; Thu, 14 Dec 2017 04:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1957; q=dns/txt; s=iport; t=1513255058; x=1514464658; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uG4gdqbKWYasKCWgW47Bi7yiN216/3rTwSZQplAdhlQ=; b=MfIhdmEAdCfkhRY1veldw1xGTszCFWTapBlk24OcRvmoZx/llJVaVG6+ XSPqGzXzzXrGbXWSOaS9MnyNNSmZqTzc6yquU1MUISX38O5rxFEHdg7RF 2E/F6HeJ9YKcdkXY7jMSOlenw7vRQdvGuGPMvWYN68T/q4vqydHsoRaRT k=; X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="860732" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 12:37:36 +0000 Received: from [10.147.24.18] ([10.147.24.18]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBECbZKQ013099; Thu, 14 Dec 2017 12:37:35 GMT Message-ID: <5A327094.40000@cisco.com> Date: Thu, 14 Dec 2017 13:37:40 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ben Campbell , The IESG CC: draft-ietf-ospf-segment-routing-extensions@ietf.org, Acee Lindem , ospf-chairs@ietf.org, ospf@ietf.org References: <151321938613.6116.16631743860290967254.idtracker@ietfa.amsl.com> In-Reply-To: <151321938613.6116.16631743860290967254.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OSPF] Ben Campbell's No Objection on draft-ietf-ospf-segment-routing-extensions-23: (with COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 12:37:43 -0000 Hi Ben, please see inline: On 14/12/17 03:43 , Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-ospf-segment-routing-extensions-23: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive Comments: > > - Requirements Language: There are a few instances of 2119 keywords in lower > case. Please consider if those are meant to be normative.If not, then please > use the boilerplate from RFC 8184, which explicitly excludes lower case > instances as normative keywords. changed some of them to normative, replaced rest with alternative wording. > > -3.1, 2nd to last paragraph: Why aren't the 3 "SHOULDs" "MUSTs"? It seems like > these might have an impact on interoperability, or at least predictable > behavior in edge conditions. done. > > -3.4: (same comment as for 3.1) done. > > Editorial Comments and Nits: > > -1, first paragraph: There are a lot of ideas packed into that paragraph. It's > not clear to me which the "For example" sentences means to exemplify. Removed "For example". > > -3.3, 2nd to last paragraph: Why is "NOT" capitalized? Changed to "not". Please see the updated version at: https://www.ietf.org/internet-drafts/draft-ietf-ospf-segment-routing-extensions-24.txt thanks, Peter > > > . > From nobody Thu Dec 14 04:38:53 2017 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 ECF99127A90; Thu, 14 Dec 2017 04:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 S1sHsGDuk8KY; Thu, 14 Dec 2017 04:38:49 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC101200B9; Thu, 14 Dec 2017 04:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3788; q=dns/txt; s=iport; t=1513255128; x=1514464728; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UyJDYnBpUheRO+Cw7+or03BMFAmm97lj3sBAluJkcII=; b=BC1DHoXF1gfESdI7l6ycEojzPsUsNpSReo3mni/BbouT/eUYCuDX79FU 7qAw/kZezYkKI+hs7knX99YRS5OZjgzwgnj2PeFBVM5D2WFOyQR5OK43x IJpx4F7bXEx2tn9UqdrK1WX2usxX08PAfpjaRfIwztdWnW2EznMAzwhMl g=; X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="860736" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 12:37:46 +0000 Received: from [10.147.24.18] ([10.147.24.18]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vBECbjDf006107; Thu, 14 Dec 2017 12:37:45 GMT Message-ID: <5A32709E.3090108@cisco.com> Date: Thu, 14 Dec 2017 13:37:50 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alexey Melnikov , The IESG CC: draft-ietf-ospf-segment-routing-extensions@ietf.org, Acee Lindem , ospf-chairs@ietf.org, ospf@ietf.org References: <151316206521.30067.6744549826451674092.idtracker@ietfa.amsl.com> In-Reply-To: <151316206521.30067.6744549826451674092.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OSPF] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 12:38:51 -0000 Hi Alexey, thanks for your comments. I have addressed them all except the one on the byte ordering, because as Acee has mentioned already all encodings are always in Network-Byte order. Please see the updated version at: https://www.ietf.org/internet-drafts/draft-ietf-ospf-segment-routing-extensions-24.txt thanks, Peter On 13/12/17 11:47 , Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-ospf-segment-routing-extensions-23: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is generally a clearly written document, but it needs a few minor changes > before I can recommend its approval for publication. > > 1) In Section 3.2: > > o When a router receives multiple overlapping ranges, it MUST > conform to the procedures defined in > [I-D.ietf-spring-conflict-resolution]. > > RFC 2119 keyword usage makes the reference a Normative reference, yet it is > currently listed as informative. > > 3.4. SRMS Preference TLV > > The Segment Routing Mapping Server Preference TLV (SRMS Preference > TLV) is used to advertise a preference associated with the node that > acts as an SR Mapping Server. The role of an SRMS is described in > [I-D.ietf-spring-segment-routing-ldp-interop]. > > As draff-ietf-spring-segment-routing-ldp-interop needs to be read in order to > understand what SR Mapping Server is, this reference must also be Normative. > > SRMS preference is defined in [I-D.ietf-spring-conflict-resolution]. > > This just confirms that this reference must be Normative. > > 2) In Section 3.1: > > When multiple SR-Algorithm TLVs are received from a given router, the > receiver SHOULD use the first occurrence of the TLV in the Router > Information LSA. If the SR-Algorithm TLV appears in multiple Router > Information LSAs that have different flooding scopes, the SR- > Algorithm TLV in the Router Information LSA with the area-scoped > flooding scope SHOULD be used. If the SR-Algorithm TLV appears in > multiple Router Information LSAs that have the same flooding scope, > the SR-Algorithm TLV in the Router Information (RI) LSA with the > numerically smallest Instance ID SHOULD be used and subsequent > instances of the SR-Algorithm TLV SHOULD be ignored. > > In the last 2 sentences: why are you using SHOULD (twice) instead of MUST? This > seems to affect interoperability. > > (I think there is similar text in another section.) > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Several TLVs have "Reserved" fields, yet you never explain what "Reserved" > means. You do explain what reserved flags mean in some of them. I suggest > either explicitly explaining what Reserved means in each case or specify this > in the terminology section near the beginning of the document. > > The document never specifies byte order for length fields. > > The acronym NSSA is never explained and it has no reference. > > > . > From nobody Thu Dec 14 04:39:28 2017 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 60556128DF6 for ; Thu, 14 Dec 2017 04:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 9lZtFWHFpNCn for ; Thu, 14 Dec 2017 04:39:25 -0800 (PST) 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 22445128DE5 for ; Thu, 14 Dec 2017 04:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2288; q=dns/txt; s=iport; t=1513255161; x=1514464761; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FaDMEjY+/WiTiXyzSaos5yxJ38z/mQiCzmNnBFXo3GM=; b=ieka6J1WQW8d/U2EyMLAjR4QNNJE898ZvOzU3JrEiHb5lRCQLumhiNCZ Tk5YtGP8fGknLWhgX0XaiRGIprGoa1IuABpBwYVyvLok55PpUfHgWwkhL RKU+PTKCmxxxUd6jKFM9jM1gEjTlNMEm6yt2DHntTysxEOe7lmqwVo1jP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAAAscDJa/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPBoF9lxaCFQoYC4UYAhqEXD8YAQEBAQEBAQE?= =?us-ascii?q?BayiFJAEBAQMBASEROgsQAgEIGAICJgICAiULFRACBAENBYoqEKkVgieKYAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CUYIOgz+DK4MuAQGBbReCfoJjBZIVkRA?= =?us-ascii?q?Ch3uNLYIWhhKLRI0ViSsCERkBgToBHzmBTm8VOoIpgwiBTniJNoEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="44004313" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2017 12:39:20 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vBECdKbn027199 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 12:39:20 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.1320.4; Thu, 14 Dec 2017 07:39:19 -0500 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.1320.000; Thu, 14 Dec 2017 07:39:19 -0500 From: "Acee Lindem (acee)" To: "Peter Psenak (ppsenak)" , IANA CC: OSPF WG List Thread-Topic: [OSPF] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 Thread-Index: AQHTdHQRIguhjQmtOke8EJ3PPxRuDKNC3J8A///riYA= Date: Thu, 14 Dec 2017 12:39:19 +0000 Message-ID: References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> <5A323BC6.80209@cisco.com> In-Reply-To: <5A323BC6.80209@cisco.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.198] Content-Type: text/plain; charset="utf-8" Content-ID: <39C2FD9A0E8C4446AD6F13737BBAD1CD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 12:39:27 -0000 VGhhbmtzIFBldGVyIC0gQWdyZWUgdGhlIHJlZ2lzdHJ5IG5lZWRzIHRvIGJlIHVwZGF0ZWQuDQpB Y2VlIA0KDQpPbiAxMi8xNC8xNywgMzo1MiBBTSwgIlBldGVyIFBzZW5hayAocHBzZW5haykiIDxw cHNlbmFrQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5IaSBBY2VlLA0KPg0KPk9uIDE0LzEyLzE3IDAx OjM5ICwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPj4gUGxlYXNlIHByb3ZpZGUgYWxsb2Nh dGlvbnMgZm9yIHRoZSBjb2RlIHBvaW50cyBpbg0KPj4gZHJhZnQtaWV0Zi1vc3BmLWxpbmstb3Zl cmxvYWQtMTAudHh0Og0KPj4NCj4+ICAgT1NQRiBFeHRlbmRlZCBMaW5rIFRMVnMgUmVnaXN0cnkN Cj4NCj5tb3JlIHByZWNpc2VseSwgdGhlc2Ugc2hvdWxkIGJlIGFsbG9jYXRlZCBmcm9tICJPU1BG djIgRXh0ZW5kZWQgTGluayBUTFYNCj5TdWItVExWcyIgcmVnaXN0cnkuIFRoZSB0ZXh0IGluIHRo ZSBkcmFmdCBzaG91bGQgYmUgdXBkYXRlZCBhcyB3ZWxsIHRvDQo+cmVmbGVjdCB0aGUgY29ycmVj dCByZWdpc3RyeSBuYW1lLiBBdCB0aGlzIHBvaW50IGl0IHNheXMgIk9TUEYgRXh0ZW5kZWQNCj5M aW5rIFRMVnMgUmVnaXN0cnkiLCB3aGljaCB3b3VsZCBzdWdnZXN0IGl0IGlzIGZyb20gYSBkaWZm ZXJlbnQsIHRvcA0KPmxldmVsIFRMViByZWdpc3RyeS4NCj4NCj5BbHNvIEkgc2VlIHRoYXQgdmFs dWUgNSBoYXMgYmVlbiB0YWtlbiBieSBSRkM4MTY5IGFscmVhZHkuDQo+DQo+dGhhbmtzLA0KPlBl dGVyDQo+DQo+Pg0KPj4gICAgIGkpIExpbmstT3ZlcmxvYWQgc3ViLVRMViAtIFN1Z2dlc3RlZCB2 YWx1ZSA1DQo+Pg0KPj4gICAgIGlpKSBSZW1vdGUgSVB2NCBhZGRyZXNzIHN1Yi1UTFYgLSBTdWdn ZXN0ZWQgdmFsdWUgNA0KPj4NCj4+ICAgICBpaWkpIExvY2FsL1JlbW90ZSBJbnRlcmZhY2UgSUQg c3ViLVRMViAtIFN1Z2dlc3RlZCBWYWx1ZSAxMQ0KPj4NCj4+ICAgICBPU1BGVjMgUm91dGVyIExp bmsgVExWIFJlZ2lzdHJ5DQo+Pg0KPj4gICAgIGkpIExpbmstT3ZlcmxvYWQgc3ViLVRMViAtIHN1 Z2dlc3RlZCB2YWx1ZSA0DQo+Pg0KPj4gICAgIEJHUC1MUyBMaW5rIE5MUkkgUmVnaXN0cnkgW1JG Qzc3NTJdDQo+Pg0KPj4gaSlMaW5rLU92ZXJsb2FkIFRMViAtIFN1Z2dlc3RlZCAxMTAxDQo+Pg0K Pj4gVGhhbmtzLA0KPj4NCj4+IEFjZWUNCj4+DQo+PiBPbiAxMi8xMy8xNywgMjo1NyBQTSwgIkFj ZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+DQo+Pj4gQWNlZSBM aW5kZW0gaGFzIHJlcXVlc3RlZCBwdWJsaWNhdGlvbiBvZg0KPj4+ZHJhZnQtaWV0Zi1vc3BmLWxp bmstb3ZlcmxvYWQtMTANCj4+PiBhcyBQcm9wb3NlZCBTdGFuZGFyZCBvbiBiZWhhbGYgb2YgdGhl IE9TUEYgd29ya2luZyBncm91cC4NCj4+Pg0KPj4+IFBsZWFzZSB2ZXJpZnkgdGhlIGRvY3VtZW50 J3Mgc3RhdGUgYXQNCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLW9zcGYtbGluay1vdmVybG9hZC8NCj4+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBPU1BGIG1haWxpbmcgbGlzdA0KPj4gT1NQ RkBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3Bm DQo+PiAuDQo+Pg0KPg0KDQo= From nobody Thu Dec 14 04:59:56 2017 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 151821292CE; Thu, 14 Dec 2017 04:59:50 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=mVnGf3I/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OuG+hzs5 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 EC6SKY0r9gD6; Thu, 14 Dec 2017 04:59:47 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E1C128DF3; Thu, 14 Dec 2017 04:59:47 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CD8312076C; Thu, 14 Dec 2017 07:59:46 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 14 Dec 2017 07:59:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=H63zn18zkkHluGXUmWWZsxBcw0W7N 0hmXk13yowQ1o8=; b=mVnGf3I/9NFwk6HHQEFSr2JhVPNdt/h2LwOq+KOTDqo30 woE8LNrdK3Z92URKD+nYNmKyvclI7JJ84P8pL6E4I9FYrsOMmh+neyvqP+5KVcHT 6Nj2qbhea5cy4PMDkgMjx4PwQWbDfA2YQatdqEhK6vy5Amb/CS1IIuSPj5ZocPvI jCLyZOqsiPIJFozfYKRquc+c/dRfCKjJEaA1BM5ml3dC9XgF4gZVL757Gi76qMIL xdwewlste4ouBOpikpRQ7K5Wxh9I4y95n6hfZYbnIUBLm+k5ZAxlSrqe/YSKaAyU dclkdyl4ys9YwuTb32xXB5vwTd7+rSFbxZU+4CCgQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=H63zn1 8zkkHluGXUmWWZsxBcw0W7N0hmXk13yowQ1o8=; b=OuG+hzs57AkKLfS7cmPDa6 NpMLg/4fs6mu4xBGjlV+lc5LjBXYs/XnUTBJtWLAmCsZ1gD0jIXhHaFMncMHY/Y4 hl9qwMzUoz2UAG1tTgSmFp2QVkccnb0wHEhxHePfY/O6bMhMPiXVIy4MPyeZrTS3 X8Y++LnQ4F8PwtU7WYLSzOY0uuzR6Ow974P6h13PzuPjcL/iheAO5nzxfG0G19hT NFFnfsEwHyXXNfwDRfWWUnMofRp5t2kk4o5m/pXe/hYRqrIkj667B/sLXh1ypQyW fswv8Qp75Jr2qwPqa39id2FwgpOK2WDYrBHEcSAfOM8YoWn0RIfHmA/I0WL/8rSA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9CA899E098; Thu, 14 Dec 2017 07:59:46 -0500 (EST) Message-Id: <1513256386.2380101.1204908824.6B6A1C47@webmail.messagingengine.com> From: Alexey Melnikov To: "Acee Lindem (acee)" , The IESG Cc: draft-ietf-ospf-segment-routing-extensions@ietf.org, ospf-chairs@ietf.org, ospf@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c9e5630e In-Reply-To: References: <151316206521.30067.6744549826451674092.idtracker@ietfa.amsl.com> Date: Thu, 14 Dec 2017 12:59:46 +0000 Archived-At: Subject: Re: [OSPF] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 12:59:50 -0000 On Wed, Dec 13, 2017, at 07:52 PM, Acee Lindem (acee) wrote: > Hi Alexey > > These all seem to be valid comments except for the one on byte order. > Note > that section 3.1 of RFC 2360 already states that IETF document packet > encodings are in Network-Byte Order (NBO). > https://www.ietf.org/rfc/rfc2360.txt Well, lots of recent RFCs violate this, so repeating it doesn't hurt. > Typically, we have not defined Reserved field usage. However, I guess we > could say that they SHOULD be set to 0 on transmission and MUST be > ignored > on reception. Yes, please. Just mention it once early in the document. > This will allow for future reuse in a backward compatible > manner. > Thanks, > Acee > > > > > > On 12/13/17, 5:47 AM, "Alexey Melnikov" wrote: > > >Alexey Melnikov has entered the following ballot position for > >draft-ietf-ospf-segment-routing-extensions-23: Discuss > > > >When responding, please keep the subject line intact and reply to all > >email addresses included in the To and CC lines. (Feel free to cut this > >introductory paragraph, however.) > > > > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >for more information about IESG DISCUSS and COMMENT positions. > > > > > >The document, along with other ballot positions, can be found here: > >https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extension > >s/ > > > > > > > >---------------------------------------------------------------------- > >DISCUSS: > >---------------------------------------------------------------------- > > > >This is generally a clearly written document, but it needs a few minor > >changes > >before I can recommend its approval for publication. > > > >1) In Section 3.2: > > > > o When a router receives multiple overlapping ranges, it MUST > > conform to the procedures defined in > > [I-D.ietf-spring-conflict-resolution]. > > > >RFC 2119 keyword usage makes the reference a Normative reference, yet it > >is > >currently listed as informative. > > > >3.4. SRMS Preference TLV > > > > The Segment Routing Mapping Server Preference TLV (SRMS Preference > > TLV) is used to advertise a preference associated with the node that > > acts as an SR Mapping Server. The role of an SRMS is described in > > [I-D.ietf-spring-segment-routing-ldp-interop]. > > > >As draff-ietf-spring-segment-routing-ldp-interop needs to be read in > >order to > >understand what SR Mapping Server is, this reference must also be > >Normative. > > > > SRMS preference is defined in [I-D.ietf-spring-conflict-resolution]. > > > >This just confirms that this reference must be Normative. > > > >2) In Section 3.1: > > > > When multiple SR-Algorithm TLVs are received from a given router, the > > receiver SHOULD use the first occurrence of the TLV in the Router > > Information LSA. If the SR-Algorithm TLV appears in multiple Router > > Information LSAs that have different flooding scopes, the SR- > > Algorithm TLV in the Router Information LSA with the area-scoped > > flooding scope SHOULD be used. If the SR-Algorithm TLV appears in > > multiple Router Information LSAs that have the same flooding scope, > > the SR-Algorithm TLV in the Router Information (RI) LSA with the > > numerically smallest Instance ID SHOULD be used and subsequent > > instances of the SR-Algorithm TLV SHOULD be ignored. > > > >In the last 2 sentences: why are you using SHOULD (twice) instead of > >MUST? This > >seems to affect interoperability. > > > >(I think there is similar text in another section.) > > > > > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > > >Several TLVs have "Reserved" fields, yet you never explain what "Reserved" > >means. You do explain what reserved flags mean in some of them. I suggest > >either explicitly explaining what Reserved means in each case or specify > >this > >in the terminology section near the beginning of the document. > > > >The document never specifies byte order for length fields. > > > >The acronym NSSA is never explained and it has no reference. > > > > > From nobody Thu Dec 14 05:03:43 2017 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 A9313128DE5; Thu, 14 Dec 2017 05:03:41 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=eFmO3RHb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k+aFEOPN 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 6iL3ftSXZAxB; Thu, 14 Dec 2017 05:03:35 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329321243F6; Thu, 14 Dec 2017 05:03:35 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 95EC620BF0; Thu, 14 Dec 2017 08:03:34 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 14 Dec 2017 08:03:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=HKzrls95Qgr62e67CPRx+iOmXEc2Y fZi8300t2/2y8U=; b=eFmO3RHbi9EqMypaqEqiQr0rviNI8VM5zkr8IXO6tvHwq VDY+8XQLvkQpmqYVbv7a+12r6oDgsGv+oj3ILjetzMbMoVZtXn1w6x22qvt8ERu9 mHz1lUAtznNmhtOhQW6upn9f0Kdqx2alSiJkkQmTXKnINHlR5/nTsYpZvfxm8OYj iCnb9uyHB5o+Ks1t9rGQFSOIxmnLS3Bjo7O/GFylSVojXQYlz2lZE5PsTng7ldoJ Fzo8FXi5GmgljsZtgX6QTnBcBLPvuATi6VDcLX2WNDuhUAcw+UZWWcsTqVo6giUH tYUDICnZkFC96smrId+r9v3ZVunCx55gbN7pMWnyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=HKzrls 95Qgr62e67CPRx+iOmXEc2YfZi8300t2/2y8U=; b=k+aFEOPNJTKw07VQ5/kfPD Xxva2wY7A8yPtQnKkL3MSbdWd94ZrDSyeKcGDRl2NEe45+Ygp0nvMo5jHTw0b4JX /6vNdPsCZIf1/DUUG5t3CpZDPdPVNEwdExw1bsPp96MtA9z2/nJFLDTUC1EyPPj8 CL5eWBaXlrbNoDskmQpa0Ep9/VYmXL43SjaIbNVZU+0boc4nLTOQuInsv1Keai1c J0HJZRI4v6iOOjQbCMFyI7QY1Ax8gls77rrfwuhcr9Eoy/vOE4JiCW8clGA8uFzq 0j43saxSbbbVsUHSb111vT4juEasjooYlaqoaQeJmAb9H94vBAlofMmzajs67H3Q == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7246B9E098; Thu, 14 Dec 2017 08:03:34 -0500 (EST) Message-Id: <1513256614.2381192.1204915408.205D958D@webmail.messagingengine.com> From: Alexey Melnikov To: Peter Psenak , The IESG Cc: draft-ietf-ospf-segment-routing-extensions@ietf.org, Acee Lindem , ospf-chairs@ietf.org, ospf@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c9e5630e References: <151316206521.30067.6744549826451674092.idtracker@ietfa.amsl.com> <5A32709E.3090108@cisco.com> In-Reply-To: <5A32709E.3090108@cisco.com> Date: Thu, 14 Dec 2017 13:03:34 +0000 Archived-At: Subject: Re: [OSPF] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 13:03:42 -0000 Hi Peter, Thank you for the changes, I cleared my DISCUSS. Best Regards, Alexey On Thu, Dec 14, 2017, at 12:37 PM, Peter Psenak wrote: > Hi Alexey, > > thanks for your comments. I have addressed them all except the one on > the byte ordering, because as Acee has mentioned already all encodings > are always in Network-Byte order. > > Please see the updated version at: > https://www.ietf.org/internet-drafts/draft-ietf-ospf-segment-routing-extensions-24.txt > > > thanks, > Peter > > On 13/12/17 11:47 , Alexey Melnikov wrote: > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-ospf-segment-routing-extensions-23: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This is generally a clearly written document, but it needs a few minor changes > > before I can recommend its approval for publication. > > > > 1) In Section 3.2: > > > > o When a router receives multiple overlapping ranges, it MUST > > conform to the procedures defined in > > [I-D.ietf-spring-conflict-resolution]. > > > > RFC 2119 keyword usage makes the reference a Normative reference, yet it is > > currently listed as informative. > > > > 3.4. SRMS Preference TLV > > > > The Segment Routing Mapping Server Preference TLV (SRMS Preference > > TLV) is used to advertise a preference associated with the node that > > acts as an SR Mapping Server. The role of an SRMS is described in > > [I-D.ietf-spring-segment-routing-ldp-interop]. > > > > As draff-ietf-spring-segment-routing-ldp-interop needs to be read in order to > > understand what SR Mapping Server is, this reference must also be Normative. > > > > SRMS preference is defined in [I-D.ietf-spring-conflict-resolution]. > > > > This just confirms that this reference must be Normative. > > > > 2) In Section 3.1: > > > > When multiple SR-Algorithm TLVs are received from a given router, the > > receiver SHOULD use the first occurrence of the TLV in the Router > > Information LSA. If the SR-Algorithm TLV appears in multiple Router > > Information LSAs that have different flooding scopes, the SR- > > Algorithm TLV in the Router Information LSA with the area-scoped > > flooding scope SHOULD be used. If the SR-Algorithm TLV appears in > > multiple Router Information LSAs that have the same flooding scope, > > the SR-Algorithm TLV in the Router Information (RI) LSA with the > > numerically smallest Instance ID SHOULD be used and subsequent > > instances of the SR-Algorithm TLV SHOULD be ignored. > > > > In the last 2 sentences: why are you using SHOULD (twice) instead of MUST? This > > seems to affect interoperability. > > > > (I think there is similar text in another section.) > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Several TLVs have "Reserved" fields, yet you never explain what "Reserved" > > means. You do explain what reserved flags mean in some of them. I suggest > > either explicitly explaining what Reserved means in each case or specify this > > in the terminology section near the beginning of the document. > > > > The document never specifies byte order for length fields. > > > > The acronym NSSA is never explained and it has no reference. > > > > > > . > > > From nobody Thu Dec 14 05:32:19 2017 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 96B561250B8; Thu, 14 Dec 2017 05:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 5hiZZ9P-ypIh; Thu, 14 Dec 2017 05:32:16 -0800 (PST) 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 7AB16124205; Thu, 14 Dec 2017 05:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6402; q=dns/txt; s=iport; t=1513258336; x=1514467936; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=53lJ894Z7d9JcmSscfgee6fnJUf95ksO1k/YY90gIKw=; b=CW8le1ItuahOsiGFk0ESbexg+fE9M8peCd912wc4/V523hgugWtWNeNf lpt99sGGWHe4sRuhGV1mfEpB+HoiZgGL4cAQ0j0cKvO1FpQ2CRBt2yGLM Z+MsbNOz67IxCNWGlt4h4SGSWWSv/3XkCkCI/+5g6QPLKWGy0NBIhF9rm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAABCfDJa/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPBoF9lxYUggEKJYUWAhqEXD8YAQEBAQEBAQE?= =?us-ascii?q?BayiFJAEFIxFFEAIBCA4KAgIfBwICAjAVEAIEAQ0FiioQqHyCJ4pgAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWBD4JRgg6DP4Mrgy4BAYE6ARIBCRaDFYJjBYpLmFo?= =?us-ascii?q?Ch3uDcYk8ghaGEoQQhzSNFYkrAhEZAYE6AR85YFYYbxWCY4MIgU54AYgRgSSBF?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="44576180" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 13:32:15 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id vBEDWFCX013393 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 13:32:15 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.1320.4; Thu, 14 Dec 2017 08:32:14 -0500 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.1320.000; Thu, 14 Dec 2017 08:32:14 -0500 From: "Acee Lindem (acee)" To: Alexey Melnikov , The IESG CC: "draft-ietf-ospf-segment-routing-extensions@ietf.org" , "ospf-chairs@ietf.org" , "ospf@ietf.org" Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT) Thread-Index: AQHTc//QW8KMe4rBDkeHYsGEb/PtbKNBr9QAgAFy0wD//7UzgA== Date: Thu, 14 Dec 2017 13:32:14 +0000 Message-ID: References: <151316206521.30067.6744549826451674092.idtracker@ietfa.amsl.com> <1513256386.2380101.1204908824.6B6A1C47@webmail.messagingengine.com> In-Reply-To: <1513256386.2380101.1204908824.6B6A1C47@webmail.messagingengine.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.198] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 13:32:19 -0000 DQoNCk9uIDEyLzE0LzE3LCA3OjU5IEFNLCAiQWxleGV5IE1lbG5pa292IiA8YWFtZWxuaWtvdkBm YXN0bWFpbC5mbT4gd3JvdGU6DQoNCj5PbiBXZWQsIERlYyAxMywgMjAxNywgYXQgMDc6NTIgUE0s IEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCj4+IEhpIEFsZXhleQ0KPj4gDQo+PiBUaGVzZSBh bGwgc2VlbSB0byBiZSB2YWxpZCBjb21tZW50cyBleGNlcHQgZm9yIHRoZSBvbmUgb24gYnl0ZSBv cmRlci4NCj4+IE5vdGUNCj4+IHRoYXQgc2VjdGlvbiAzLjEgb2YgUkZDIDIzNjAgYWxyZWFkeSBz dGF0ZXMgdGhhdCBJRVRGIGRvY3VtZW50IHBhY2tldA0KPj4gZW5jb2RpbmdzIGFyZSBpbiBOZXR3 b3JrLUJ5dGUgT3JkZXIgKE5CTykuDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmMvcmZjMjM2 MC50eHQNCj4NCj5XZWxsLCBsb3RzIG9mIHJlY2VudCBSRkNzIHZpb2xhdGUgdGhpcywgc28gcmVw ZWF0aW5nIGl0IGRvZXNuJ3QgaHVydC4NCg0KQ2FuIHlvdSBwcm92aWRlIGFuIGV4YW1wbGU/IElF VEYgc3RhbmRhcmQgcGFja2V0cyBzaG91bGQgYWx3YXlzIGJlIGluDQpOZXR3b3JrLUJ5dGUgT3Jk ZXIuDQoNClRoYW5rcywNCkFjZWUgDQo+DQo+PiBUeXBpY2FsbHksIHdlIGhhdmUgbm90IGRlZmlu ZWQgUmVzZXJ2ZWQgZmllbGQgdXNhZ2UuIEhvd2V2ZXIsIEkgZ3Vlc3Mgd2UNCj4+IGNvdWxkIHNh eSB0aGF0IHRoZXkgU0hPVUxEIGJlIHNldCB0byAwIG9uIHRyYW5zbWlzc2lvbiBhbmQgTVVTVCBi ZQ0KPj4gaWdub3JlZA0KPj4gb24gcmVjZXB0aW9uLg0KPg0KPlllcywgcGxlYXNlLiBKdXN0IG1l bnRpb24gaXQgb25jZSBlYXJseSBpbiB0aGUgZG9jdW1lbnQuDQo+DQo+PiBUaGlzIHdpbGwgYWxs b3cgZm9yIGZ1dHVyZSByZXVzZSBpbiBhIGJhY2t3YXJkIGNvbXBhdGlibGUNCj4+IG1hbm5lci4g DQo+PiBUaGFua3MsDQo+PiBBY2VlIA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IE9uIDEy LzEzLzE3LCA1OjQ3IEFNLCAiQWxleGV5IE1lbG5pa292IiA8YWFtZWxuaWtvdkBmYXN0bWFpbC5m bT4gd3JvdGU6DQo+PiANCj4+ID5BbGV4ZXkgTWVsbmlrb3YgaGFzIGVudGVyZWQgdGhlIGZvbGxv d2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+PiA+ZHJhZnQtaWV0Zi1vc3BmLXNlZ21lbnQtcm91 dGluZy1leHRlbnNpb25zLTIzOiBEaXNjdXNzDQo+PiA+DQo+PiA+V2hlbiByZXNwb25kaW5nLCBw bGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+PiA+ ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy ZWUgdG8gY3V0IHRoaXMNCj4+ID5pbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4+ ID4NCj4+ID4NCj4+ID5QbGVhc2UgcmVmZXIgdG8NCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+PiA+Zm9yIG1vcmUgaW5mb3JtYXRp b24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4+ID4NCj4+ID4N Cj4+ID5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu IGJlIGZvdW5kIGhlcmU6DQo+PiANCj4+Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaQ0KPj4+b24NCj4+ID5zLw0K Pj4gPg0KPj4gPg0KPj4gPg0KPj4gPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ID5ESVNDVVNTOg0KPj4gPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+ID4NCj4+ID5UaGlzIGlzIGdlbmVyYWxseSBhIGNsZWFybHkgd3JpdHRl biBkb2N1bWVudCwgYnV0IGl0IG5lZWRzIGEgZmV3IG1pbm9yDQo+PiA+Y2hhbmdlcw0KPj4gPmJl Zm9yZSBJIGNhbiByZWNvbW1lbmQgaXRzIGFwcHJvdmFsIGZvciBwdWJsaWNhdGlvbi4NCj4+ID4N Cj4+ID4xKSBJbiBTZWN0aW9uIDMuMjoNCj4+ID4NCj4+ID4gICBvICBXaGVuIGEgcm91dGVyIHJl Y2VpdmVzIG11bHRpcGxlIG92ZXJsYXBwaW5nIHJhbmdlcywgaXQgTVVTVA0KPj4gPiAgICAgIGNv bmZvcm0gdG8gdGhlIHByb2NlZHVyZXMgZGVmaW5lZCBpbg0KPj4gPiAgICAgIFtJLUQuaWV0Zi1z cHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbl0uDQo+PiA+DQo+PiA+UkZDIDIxMTkga2V5d29yZCB1 c2FnZSBtYWtlcyB0aGUgcmVmZXJlbmNlIGEgTm9ybWF0aXZlIHJlZmVyZW5jZSwgeWV0DQo+Pml0 DQo+PiA+aXMNCj4+ID5jdXJyZW50bHkgbGlzdGVkIGFzIGluZm9ybWF0aXZlLg0KPj4gPg0KPj4g PjMuNC4gIFNSTVMgUHJlZmVyZW5jZSBUTFYNCj4+ID4NCj4+ID4gICBUaGUgU2VnbWVudCBSb3V0 aW5nIE1hcHBpbmcgU2VydmVyIFByZWZlcmVuY2UgVExWIChTUk1TIFByZWZlcmVuY2UNCj4+ID4g ICBUTFYpIGlzIHVzZWQgdG8gYWR2ZXJ0aXNlIGEgcHJlZmVyZW5jZSBhc3NvY2lhdGVkIHdpdGgg dGhlIG5vZGUgdGhhdA0KPj4gPiAgIGFjdHMgYXMgYW4gU1IgTWFwcGluZyBTZXJ2ZXIuICBUaGUg cm9sZSBvZiBhbiBTUk1TIGlzIGRlc2NyaWJlZCBpbg0KPj4gPiAgIFtJLUQuaWV0Zi1zcHJpbmct c2VnbWVudC1yb3V0aW5nLWxkcC1pbnRlcm9wXS4NCj4+ID4NCj4+ID5BcyBkcmFmZi1pZXRmLXNw cmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3AgbmVlZHMgdG8gYmUgcmVhZCBpbg0KPj4g Pm9yZGVyIHRvDQo+PiA+dW5kZXJzdGFuZCB3aGF0IFNSIE1hcHBpbmcgU2VydmVyIGlzLCB0aGlz IHJlZmVyZW5jZSBtdXN0IGFsc28gYmUNCj4+ID5Ob3JtYXRpdmUuDQo+PiA+DQo+PiA+ICBTUk1T IHByZWZlcmVuY2UgaXMgZGVmaW5lZCBpbiBbSS1ELmlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29s dXRpb25dLg0KPj4gPg0KPj4gPlRoaXMganVzdCBjb25maXJtcyB0aGF0IHRoaXMgcmVmZXJlbmNl IG11c3QgYmUgTm9ybWF0aXZlLg0KPj4gPg0KPj4gPjIpIEluIFNlY3Rpb24gMy4xOg0KPj4gPg0K Pj4gPiAgIFdoZW4gbXVsdGlwbGUgU1ItQWxnb3JpdGhtIFRMVnMgYXJlIHJlY2VpdmVkIGZyb20g YSBnaXZlbiByb3V0ZXIsDQo+PnRoZQ0KPj4gPiAgIHJlY2VpdmVyIFNIT1VMRCB1c2UgdGhlIGZp cnN0IG9jY3VycmVuY2Ugb2YgdGhlIFRMViBpbiB0aGUgUm91dGVyDQo+PiA+ICAgSW5mb3JtYXRp b24gTFNBLiAgSWYgdGhlIFNSLUFsZ29yaXRobSBUTFYgYXBwZWFycyBpbiBtdWx0aXBsZSBSb3V0 ZXINCj4+ID4gICBJbmZvcm1hdGlvbiBMU0FzIHRoYXQgaGF2ZSBkaWZmZXJlbnQgZmxvb2Rpbmcg c2NvcGVzLCB0aGUgU1ItDQo+PiA+ICAgQWxnb3JpdGhtIFRMViBpbiB0aGUgUm91dGVyIEluZm9y bWF0aW9uIExTQSB3aXRoIHRoZSBhcmVhLXNjb3BlZA0KPj4gPiAgIGZsb29kaW5nIHNjb3BlIFNI T1VMRCBiZSB1c2VkLiAgSWYgdGhlIFNSLUFsZ29yaXRobSBUTFYgYXBwZWFycyBpbg0KPj4gPiAg IG11bHRpcGxlIFJvdXRlciBJbmZvcm1hdGlvbiBMU0FzIHRoYXQgaGF2ZSB0aGUgc2FtZSBmbG9v ZGluZyBzY29wZSwNCj4+ID4gICB0aGUgU1ItQWxnb3JpdGhtIFRMViBpbiB0aGUgUm91dGVyIElu Zm9ybWF0aW9uIChSSSkgTFNBIHdpdGggdGhlDQo+PiA+ICAgbnVtZXJpY2FsbHkgc21hbGxlc3Qg SW5zdGFuY2UgSUQgU0hPVUxEIGJlIHVzZWQgYW5kIHN1YnNlcXVlbnQNCj4+ID4gICBpbnN0YW5j ZXMgb2YgdGhlIFNSLUFsZ29yaXRobSBUTFYgU0hPVUxEIGJlIGlnbm9yZWQuDQo+PiA+DQo+PiA+ SW4gdGhlIGxhc3QgMiBzZW50ZW5jZXM6IHdoeSBhcmUgeW91IHVzaW5nIFNIT1VMRCAodHdpY2Up IGluc3RlYWQgb2YNCj4+ID5NVVNUPyBUaGlzDQo+PiA+c2VlbXMgdG8gYWZmZWN0IGludGVyb3Bl cmFiaWxpdHkuDQo+PiA+DQo+PiA+KEkgdGhpbmsgdGhlcmUgaXMgc2ltaWxhciB0ZXh0IGluIGFu b3RoZXIgc2VjdGlvbi4pDQo+PiA+DQo+PiA+DQo+PiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gPkNPTU1F TlQ6DQo+PiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gPg0KPj4gPlNldmVyYWwgVExWcyBoYXZlICJSZXNl cnZlZCIgZmllbGRzLCB5ZXQgeW91IG5ldmVyIGV4cGxhaW4gd2hhdA0KPj4iUmVzZXJ2ZWQiDQo+ PiA+bWVhbnMuIFlvdSBkbyBleHBsYWluIHdoYXQgcmVzZXJ2ZWQgZmxhZ3MgbWVhbiBpbiBzb21l IG9mIHRoZW0uIEkNCj4+c3VnZ2VzdA0KPj4gPmVpdGhlciBleHBsaWNpdGx5IGV4cGxhaW5pbmcg d2hhdCBSZXNlcnZlZCBtZWFucyBpbiBlYWNoIGNhc2Ugb3INCj4+c3BlY2lmeQ0KPj4gPnRoaXMN Cj4+ID5pbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBuZWFyIHRoZSBiZWdpbm5pbmcgb2YgdGhl IGRvY3VtZW50Lg0KPj4gPg0KPj4gPlRoZSBkb2N1bWVudCBuZXZlciBzcGVjaWZpZXMgYnl0ZSBv cmRlciBmb3IgbGVuZ3RoIGZpZWxkcy4NCj4+ID4NCj4+ID5UaGUgYWNyb255bSBOU1NBIGlzIG5l dmVyIGV4cGxhaW5lZCBhbmQgaXQgaGFzIG5vIHJlZmVyZW5jZS4NCj4+ID4NCj4+ID4NCj4+IA0K DQo= From nobody Thu Dec 14 09:26:16 2017 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 897781293DA; Thu, 14 Dec 2017 09:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.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 YdsjHzLbyWk2; Thu, 14 Dec 2017 09:26:12 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0131.outbound.protection.outlook.com [104.47.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05464127871; Thu, 14 Dec 2017 09:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.onmicrosoft.com; s=selector1-kaloom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X5nWtkuIIbGyYqu1mjCVcUB5LkxH5Ryqkp0t5F5UA/A=; b=Zyj+wVZZVvaGyG4lKGi2lK5i9IytLTvDfdIKu7jd/1rOAl8ibX0GeEKBh0PDE80FXr4jxYQ2f/HC76gHzr8wBrOMWStS9JesxAYAM8BvqZ16Yo1afcRhbo7WswXYKAkEtFqxWYv2I6P5+XgPsV8q8X0irftPhU6x737WwiBBNs0= Received: from YTXPR0101MB2061.CANPRD01.PROD.OUTLOOK.COM (52.132.40.13) by YTXPR0101MB2062.CANPRD01.PROD.OUTLOOK.COM (52.132.40.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Thu, 14 Dec 2017 17:26:09 +0000 Received: from YTXPR0101MB2061.CANPRD01.PROD.OUTLOOK.COM ([fe80::547a:d52c:d27e:329f]) by YTXPR0101MB2061.CANPRD01.PROD.OUTLOOK.COM ([fe80::547a:d52c:d27e:329f%13]) with mapi id 15.20.0302.017; Thu, 14 Dec 2017 17:26:09 +0000 From: Suresh Krishnan To: Peter Psenak CC: The IESG , "draft-ietf-ospf-segment-routing-extensions@ietf.org" , Acee Lindem , "ospf-chairs@ietf.org" , "ospf@ietf.org" Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-ospf-segment-routing-extensions-23: (with COMMENT) Thread-Index: AQHTdNhNgU3oQdebt06PMbEErNtljaNDF5MA Date: Thu, 14 Dec 2017 17:26:09 +0000 Message-ID: <768C6831-98FE-4786-871E-1F70B9280EA8@kaloom.com> References: <151319970086.30105.10327182151493185093.idtracker@ietfa.amsl.com> <5A32708A.9040101@cisco.com> In-Reply-To: <5A32708A.9040101@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [67.22.228.35] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR0101MB2062; 6:dgj0ZRW4CnK2hPNzBw+E17Tl8p/aq6hPsKi1YxR86k0aePeYjDVHBvq0GuHDvPG6FntBL0uy3VCr31Xpezsy8t9LwgTERHTwg738KYjOJJ8sfAMV4oPIm/YSjhAFG+k2zK9qvQJGdPPUZaNQtDjZH12cDmy7K0VDjj3LC+re+dmjg/Obj5pZRW239IwhME6SYtmk8Jj2FdHpMkukRPmDUQUKCD2hwiFnYX9o4LiWXAUZH1Bdb1lBI0T+v5HJN+sDEP+/d9FVCEFvKSqaJbm+X/pDkzvPHkJnk1IgGVtzf0AwVp2pzYPjdb2+QPp5257vBYDqAvFuMhkgX+1aO3Wn0FucEaC5my72/Y+epxB29Ls=; 5:2mTLDy2mNnJbjdnlrORiZHWCqhvvFjmWxMe239ZauV6swB4j2jJ/Pnry+CRvOcY8Kf14eDUGRoM3GHGarbwiOvq70PGTcPokFi6dgdNA6N0qD8v93Y0kaQ6wmsNBhR/yz6N2v6EXNLmTB8jT35QQU3dcVKf73ROMD7a0Yh7TQIg=; 24:tpYF+0Gn5d1/XSGiofnJFPk+H6n2R1Lxn6GLGVxArzyqDI9TV7Ny4hSCup7E4HIzmip3eOckUPsCvjfScs3H5rLs6/s/k0AdUGQVMUeyDrU=; 7:pWeaS9tQ0frL7cixUNcKwib1kKjXjXZtQjxezXyQMeOJD1ac8rqlqXLMRM6/tXQz6TgjbAdT7UPbqB7c/y3T2k4p1Jrwt+p6nZdcaLGfixPrqodw2YWXLYelts2wZVt4ubc/7/h+l0ZKs1DBV4xIup/BCu5fH/9hrNZ5tLQyyb1+o/BqB5bODJ4j214pAwiGUmVwQfZ5Zg/Mz2sY75BQapzpkSuCPkW7f3Lsf6lNmzOOo3PYHphu/VX3x+8u0FXq x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d9daa439-6bd0-434a-0ce9-08d54317c447 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603307); SRVR:YTXPR0101MB2062; x-ms-traffictypediagnostic: YTXPR0101MB2062: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231023)(10201501046)(6041248)(20161123564025)(2016111802025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6043046)(6072148)(201708071742011); SRVR:YTXPR0101MB2062; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTXPR0101MB2062; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(396003)(346002)(376002)(366004)(24454002)(199004)(189003)(5250100002)(66066001)(82746002)(14454004)(80792005)(8676002)(53546011)(6506007)(81156014)(81166006)(966005)(97736004)(83716003)(25786009)(606006)(7736002)(99286004)(3280700002)(2906002)(478600001)(76176011)(72206003)(2950100002)(54906003)(86362001)(6916009)(3660700001)(53936002)(316002)(33656002)(2900100001)(229853002)(105586002)(230783001)(6116002)(6486002)(4326008)(236005)(36756003)(102836003)(8936002)(5660300001)(68736007)(3846002)(6306002)(106356001)(54896002)(6436002)(6246003)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:YTXPR0101MB2062; H:YTXPR0101MB2061.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_768C683198FE4786871E1F70B9280EA8kaloomcom_" MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: d9daa439-6bd0-434a-0ce9-08d54317c447 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 17:26:09.8155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB2062 Archived-At: Subject: Re: [OSPF] Suresh Krishnan's No Objection on draft-ietf-ospf-segment-routing-extensions-23: (with COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 14 Dec 2017 17:26:14 -0000 --_000_768C683198FE4786871E1F70B9280EA8kaloomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, Thanks a lot for addressing my comments. Your changes look good to me. Regards Suresh On Dec 14, 2017, at 7:37 AM, Peter Psenak > wrote: Hi Suresh, please see inline: On 13/12/17 22:15 , Suresh Krishnan wrote: Suresh Krishnan has entered the following ballot position for draft-ietf-ospf-segment-routing-extensions-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions= / ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * It would be good to clarify that this document is intended for OSPFv2 onl= y (probably in the title and/or abstract). I changed the text in the abstract, which now says: "This draft describes the OSPFv2 extensions required for Segment Routing." It may also be worthwhile for the document and/or the Shepherd writeup to explain why the WG decided to separ= ate the OSPFv3 extensions into a different document. OSPFv3 SR extensions are based on the draft-ietf-ospf-ospfv3-lsa-extend, which is OSPFv3 specific. That's why WG = decided to use a separate document to describe OSPFv3 SR extensions. * I think RFC2328 should be a Normative Reference and not an informative reference. done. Please see the updated version at: https://www.ietf.org/internet-drafts/draft-ietf-ospf-segment-routing-extens= ions-24.txt thanks, Peter . --_000_768C683198FE4786871E1F70B9280EA8kaloomcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Peter,
  Thanks a lot for addressing my comments. Your change= s look good to me.

Regards
Suresh

On Dec 14, 2017, at 7:37 AM, Peter Psenak <ppsenak@cisco.com> wrote:

Hi Suresh,

please see inline:

On 13/12/17 22:15 , Suresh Krishnan wrote:
Suresh Krishnan has entered the following ballot position for
draft-ietf-ospf-segment-routing-extensions-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-s= egment-routing-extensions/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* It would be good to clarify that this document is intended for OSPFv2 onl= y
(probably in the title and/or abstract).

I changed the text in the abstract, which now says:

"This draft describes the OSPFv2 extensions required for Segment Routing."<= /span>

It may also be worthwhile for the
document and/or the Shepherd writeup to explain why the WG decided to separ= ate
the OSPFv3 extensions into a different document.

OSPFv3 SR extensions are based on the  
draft-ietf-ospf-ospfv3-lsa-extend, which is OSPFv3 specific. That's why WG decided to use a separate document= to describe OSPFv3 SR extensions.


* I think RFC2328 should be a Normative Reference and not an informative reference.

done.

Please see the updated version at:
https= ://www.ietf.org/internet-drafts/draft-ietf-ospf-segment-routing-extensions-= 24.txt

thanks,
Peter


.

--_000_768C683198FE4786871E1F70B9280EA8kaloomcom_-- From nobody Thu Dec 14 15:16:24 2017 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 A93F81205F0; Thu, 14 Dec 2017 15:16:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151329338265.30366.9482510149733006931@ietfa.amsl.com> Date: Thu, 14 Dec 2017 15:16:22 -0800 Archived-At: Subject: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-msd-07.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 23:16:23 -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 WG of the IETF. Title : Signaling MSD (Maximum SID Depth) using OSPF Authors : Jeff Tantsura Uma Chunduri Sam Aldrin Peter Psenak Filename : draft-ietf-ospf-segment-routing-msd-07.txt Pages : 8 Date : 2017-12-14 Abstract: This document proposes a way to signal Maximum SID Depth (MSD) supported by a node at node and/or link granularity by an OSPF Router. In a Segment Routing (SR) enabled network a centralized controller that programs SR tunnels needs to know the MSD supported by the head-end at node and/or link granularity to impose the SID stack of an appropriate depth. MSD is relevant to the head-end of a SR tunnel or Binding-SID anchor node where Binding-SID expansions might result in creation of a new SID stack. Here the term OSPF means both OSPFv2 and OSPFv3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-msd-07 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-msd-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-msd-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 Thu Dec 14 15:36:56 2017 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 9653A128C84; Thu, 14 Dec 2017 15:36:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151329460555.30350.13128680107632566816@ietfa.amsl.com> Date: Thu, 14 Dec 2017 15:36:45 -0800 Archived-At: Subject: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-msd-08.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 23:36:46 -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 WG of the IETF. Title : Signaling MSD (Maximum SID Depth) using OSPF Authors : Jeff Tantsura Uma Chunduri Sam Aldrin Peter Psenak Filename : draft-ietf-ospf-segment-routing-msd-08.txt Pages : 8 Date : 2017-12-14 Abstract: This document proposes a way to signal Maximum SID Depth (MSD) supported by a node at node and/or link granularity by an OSPF Router. In a Segment Routing (SR) enabled network a centralized controller that programs SR tunnels needs to know the MSD supported by the head-end at node and/or link granularity to impose the SID stack of an appropriate depth. MSD is relevant to the head-end of a SR tunnel or Binding-SID anchor node where Binding-SID expansions might result in creation of a new SID stack. Here the term OSPF means both OSPFv2 and OSPFv3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-msd-08 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-msd-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-msd-08 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 Dec 14 16:55:13 2017 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 A7A5D126C3D for ; Thu, 14 Dec 2017 16:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 6mVJhYZvJTYH for ; Thu, 14 Dec 2017 16:55:09 -0800 (PST) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 C10F21200F3 for ; Thu, 14 Dec 2017 16:55:09 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id F3AC5E0587; Fri, 15 Dec 2017 00:55:08 +0000 (UTC) Received: by request3.lax.icann.org (Postfix, from userid 48) id B276CC20667; Fri, 15 Dec 2017 00:55:08 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-prot-param-comment@iana.org In-Reply-To: <5A323BC6.80209@cisco.com> References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> <5A323BC6.80209@cisco.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #992646 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: ospf@ietf.org, ppsenak@cisco.com, shraddha@juniper.net, pushpasis.ietf@gmail.com, hannes@gredler.at, mnanduri@ebay.com, luay.jalil@verizon.com, acee@cisco.com, akr@cisco.com, aretana.ietf@gmail.com, db3546@att.com, akatlas@gmail.com, acee@cisco.com Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 15 Dec 2017 00:55:08 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 00:55:12 -0000 Hi all, As Peter pointed out, there appear to be issues with these registrations. Is the first registry, "OSPF Extended Link TLVs Registry," meant to refer to "OSPFv2 Extended Link Opaque LSA TLVs" or "OSPFv2 Extended Link TLV Sub-TLVs"? In the first of those, values 4, 5, and 11 are available. In the second, values 4 and 5 are not available. Please see https://www.iana.org/assignments/ospfv2-parameters For the second registry in the document, if "OSPFV3 Router Link TLV Registry" refers to "OSPFv3 Router LSA Link Types," value 4 is not available. Please see https://www.iana.org/assignments/ospfv3-parameters For the third registry in the document, if "BGP-LS Link NLRI Registry" refers to "BGP-LS NLRI-Types," value 1101 is available, but because this is a Specification Required registry, we'll have to ask the designated experts to confirm that this is OK. Can you confirm that this is the correct registry? https://www.iana.org/assignments/bgp-ls-parameters You can see a list of registries here: https://www.iana.org/protocols thanks, Amanda Baber Lead IANA Services Specialist On Thu Dec 14 08:52:23 2017, ppsenak@cisco.com wrote: > Hi Acee, > > On 14/12/17 01:39 , Acee Lindem (acee) wrote: > > Please provide allocations for the code points in > > draft-ietf-ospf-link-overload-10.txt: > > > > OSPF Extended Link TLVs Registry > > more precisely, these should be allocated from "OSPFv2 Extended Link TLV > Sub-TLVs" registry. The text in the draft should be updated as well to > reflect the correct registry name. At this point it says "OSPF Extended > Link TLVs Registry", which would suggest it is from a different, top > level TLV registry. > > Also I see that value 5 has been taken by RFC8169 already. > > thanks, > Peter > > > > > i) Link-Overload sub-TLV - Suggested value 5 > > > > ii) Remote IPv4 address sub-TLV - Suggested value 4 > > > > iii) Local/Remote Interface ID sub-TLV - Suggested Value 11 > > > > OSPFV3 Router Link TLV Registry > > > > i) Link-Overload sub-TLV - suggested value 4 > > > > BGP-LS Link NLRI Registry [RFC7752] > > > > i)Link-Overload TLV - Suggested 1101 > > > > Thanks, > > > > Acee > > > > On 12/13/17, 2:57 PM, "Acee Lindem (acee)" wrote: > > > >> Acee Lindem has requested publication of draft-ietf-ospf-link-overload-10 > >> as Proposed Standard on behalf of the OSPF working group. > >> > >> Please verify the document's state at > >> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ > >> > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > . > > > From nobody Thu Dec 14 17:34:53 2017 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 4EC7112704B for ; Thu, 14 Dec 2017 17:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Wjjs3cDV9HVV for ; Thu, 14 Dec 2017 17:34:49 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::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 0B978124239 for ; Thu, 14 Dec 2017 17:34:48 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id q3so6596345oth.2 for ; Thu, 14 Dec 2017 17:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=wmaeO/evNOn5kcvBiaNghwymG7BlaHiIu8AxDr4uUlY=; b=NLenqbprEXo3/SObbZwpt+26FPBCpiNDgBHAdzT+f1w3IIifqvwsNyq6bGrRAUkLOe 9AXhfpPJAhdwR2xLLDJqKFezSv+eyCqExvQ35icE64ZRa+oCKiJW/L7WkD/DFdeIhODE 5VtlhGxbGNfnrnR+c3nlYPDIlaNWp7KiHC1jqpJ+FpuwQh0IaZ+INPUBwEaq4KpPQ7oo Cx2QOxaqQDQ3LYat0PeZbkYRHqykir1TpMWfKJH9S2D6wJMEm/lL/8Yfnl5oeeeMulex ioMS2I3HycZxjCKp/YQXhAEFtKS1Vw7qYdgeesNkwqr9F5swSPtlIpYn1YsljSdwWokf KPbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=wmaeO/evNOn5kcvBiaNghwymG7BlaHiIu8AxDr4uUlY=; b=rERnGPaoGBBoprJFPenSq7caJuk7LrYapi+u54VimkJztWYgU9gG2PnZoWK0DuWICl aKzeMydc/CAfpLlbcXqnkzfUHzfYDebgR22sBlB6yaVBsZZ1+qdNyDnPiBiAc+Ji04kq JKgYISP3l1IxQSoebM4CBwPY3+213A97tM1nNaDmuesGhp6wv5e3ruNG5hedb65YMna4 ultRDltM8IModYYlSsNJshQ3U+RBHIxJpy2OXqosa8oEugjwdm1GzUhLOUGAh3BiMfnM yaqq2ojttnW2PyqpPPDHSVsNS7aT643RgEKVa8uf5NHF4LbAEYa/j1uEh8t1luNFspJy OV6A== X-Gm-Message-State: AKGB3mJT6kewarIuSHLSANJJHpYfAfvzpjpcNQrKhbNzOlSyokqyYGwg qP/s9LI4A6te36eBATbx7CA= X-Google-Smtp-Source: ACJfBos3D39J/wy0pyztJsq5z0XItze4dpxVfgOd8KgpDCh6AN8wws/kMmw503aXaXFsYHx2s52njw== X-Received: by 10.157.15.205 with SMTP id m13mr6364711otd.389.1513301688279; Thu, 14 Dec 2017 17:34:48 -0800 (PST) Received: from [100.65.101.83] ([206.16.17.196]) by smtp.gmail.com with ESMTPSA id i17sm2650384ote.40.2017.12.14.17.34.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 17:34:47 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.29.0.171205 Date: Thu, 14 Dec 2017 17:34:45 -0800 From: Jeff Tantsura To: , Acee Lindem CC: , , Message-ID: Thread-Topic: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> <5A323BC6.80209@cisco.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 15 Dec 2017 01:34:51 -0000 Hi Amanda, Please note, in the draft-ietf-ospf-segment-routing-msd regretfully, the au= thors have requested an allocation from OSPFv2 Extended Link Opaque LSA TLVs= while it should have been from OSPFv2 Extended Link TLV Sub-TLVs registry. Updated draft has been published (draft-ietf-ospf-segment-routing-msd-08) a= nd email to update the allocation (value of 6 from OSPFv2 Extended Link TLV = Sub-TLVs registry) has been sent to iana-issues-comment@iana.org (so 6 is u= navailable) Back to draft-ietf-ospf-link-overload OSPFv3 allocations- it is quite comp= licated and requires resolution. I believe, the registry in question would be =E2=80=9COSPFv3 Extend-LSA Sub-TLV=E2=80= =9D, please note - draft-ietf-ospf-ospfv3-segment-routing-extensions has alrea= dy suggested values 3(used already by the base draft for route-tag) to 14 fo= r their use. Hopefully I haven=E2=80=99t caused even more confusion than before, we just need = to sort out who is getting what ;-) Many thanks! Cheers, Jeff -----Original Message----- From: OSPF on behalf of Amanda Baber via RT Reply-To: Date: Thursday, December 14, 2017 at 16:55 Cc: , , Subject: [OSPF] [IANA #992646] FW: Publication has been requested for draft= -ietf-ospf-link-overload-10 Hi all, =20 As Peter pointed out, there appear to be issues with these registration= s.=20 =20 Is the first registry, "OSPF Extended Link TLVs Registry," meant to ref= er to "OSPFv2 Extended Link Opaque LSA TLVs" or "OSPFv2 Extended Link TLV S= ub-TLVs"? In the first of those, values 4, 5, and 11 are available. In the s= econd, values 4 and 5 are not available. Please see =20 https://www.iana.org/assignments/ospfv2-parameters =20 For the second registry in the document, if "OSPFV3 Router Link TLV Reg= istry" refers to "OSPFv3 Router LSA Link Types," value 4 is not available. P= lease see =20 https://www.iana.org/assignments/ospfv3-parameters =20 For the third registry in the document, if "BGP-LS Link NLRI Registry" = refers to "BGP-LS NLRI-Types," value 1101 is available, but because this is = a Specification Required registry, we'll have to ask the designated experts = to confirm that this is OK. Can you confirm that this is the correct registr= y? =20 https://www.iana.org/assignments/bgp-ls-parameters =20 You can see a list of registries here: =20 https://www.iana.org/protocols =20 thanks, =20 Amanda Baber Lead IANA Services Specialist =20 On Thu Dec 14 08:52:23 2017, ppsenak@cisco.com wrote: > Hi Acee, >=20 > On 14/12/17 01:39 , Acee Lindem (acee) wrote: > > Please provide allocations for the code points in > > draft-ietf-ospf-link-overload-10.txt: > > > > OSPF Extended Link TLVs Registry >=20 > more precisely, these should be allocated from "OSPFv2 Extended Link = TLV=20 > Sub-TLVs" registry. The text in the draft should be updated as well t= o=20 > reflect the correct registry name. At this point it says "OSPF Extend= ed=20 > Link TLVs Registry", which would suggest it is from a different, top=20 > level TLV registry. >=20 > Also I see that value 5 has been taken by RFC8169 already. >=20 > thanks, > Peter >=20 > > > > i) Link-Overload sub-TLV - Suggested value 5 > > > > ii) Remote IPv4 address sub-TLV - Suggested value 4 > > > > iii) Local/Remote Interface ID sub-TLV - Suggested Value 11 > > > > OSPFV3 Router Link TLV Registry > > > > i) Link-Overload sub-TLV - suggested value 4 > > > > BGP-LS Link NLRI Registry [RFC7752] > > > > i)Link-Overload TLV - Suggested 1101 > > > > Thanks, > > > > Acee > > > > On 12/13/17, 2:57 PM, "Acee Lindem (acee)" wrote: > > > >> Acee Lindem has requested publication of draft-ietf-ospf-link-over= load-10 > >> as Proposed Standard on behalf of the OSPF working group. > >> > >> Please verify the document's state at > >> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ > >> > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > . > > >=20 =20 =20 =20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf =20 From nobody Thu Dec 14 17:39:28 2017 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 6CDEE127F0E for ; Thu, 14 Dec 2017 17:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 VvhS9fJvSglN for ; Thu, 14 Dec 2017 17:39:24 -0800 (PST) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 3590A1270FC for ; Thu, 14 Dec 2017 17:39:24 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 54462E0451; Fri, 15 Dec 2017 01:39:23 +0000 (UTC) Received: by request3.lax.icann.org (Postfix, from userid 48) id 1A505C20667; Fri, 15 Dec 2017 01:39:23 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-prot-param-comment@iana.org In-Reply-To: References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> <5A323BC6.80209@cisco.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #992646 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: pushpasis.ietf@gmail.com, luay.jalil@verizon.com, shraddha@juniper.net, ppsenak@cisco.com, akatlas@gmail.com, hannes@gredler.at, akr@cisco.com, ospf@ietf.org, mnanduri@ebay.com, db3546@att.com, jefftant.ietf@gmail.com Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 15 Dec 2017 01:39:23 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 01:39:26 -0000 Hi Jeff, I just sent a separate note about draft-ietf-ospf-segment-routing-msd from ticket [IANA #992766] to the people on the draft-string-all list. Thanks! Amanda On Fri Dec 15 01:35:11 2017, jefftant.ietf@gmail.com wrote: > Hi Amanda, > > Please note, in the draft-ietf-ospf-segment-routing-msd regretfully, > the authors have requested an allocation from OSPFv2 Extended Link > Opaque LSA TLVs while it should have been from OSPFv2 Extended Link > TLV Sub-TLVs registry. > > Updated draft has been published (draft-ietf-ospf-segment-routing-msd- > 08) and email to update the allocation (value of 6 from OSPFv2 > Extended Link TLV Sub-TLVs registry) has been sent to iana-issues- > comment@iana.org (so 6 is unavailable) > > > Back to draft-ietf-ospf-link-overload OSPFv3 allocations- it is quite > complicated and requires resolution. > I believe, the registry in question would be “OSPFv3 Extend-LSA Sub- > TLV”, please note - draft-ietf-ospf-ospfv3-segment-routing-extensions > has already suggested values 3(used already by the base draft for > route-tag) to 14 for their use. > > Hopefully I haven’t caused even more confusion than before, we just > need to sort out who is getting what ;-) > > Many thanks! > > Cheers, > Jeff > > -----Original Message----- > From: OSPF on behalf of Amanda Baber via RT > > Reply-To: > Date: Thursday, December 14, 2017 at 16:55 > Cc: , , > Subject: [OSPF] [IANA #992646] FW: Publication has been requested for > draft-ietf-ospf-link-overload-10 > > Hi all, > > As Peter pointed out, there appear to be issues with these > registrations. > > Is the first registry, "OSPF Extended Link TLVs Registry," meant to > refer to "OSPFv2 Extended Link Opaque LSA TLVs" or "OSPFv2 Extended > Link TLV Sub-TLVs"? In the first of those, values 4, 5, and 11 are > available. In the second, values 4 and 5 are not available. Please see > > https://www.iana.org/assignments/ospfv2-parameters > > For the second registry in the document, if "OSPFV3 Router Link TLV > Registry" refers to "OSPFv3 Router LSA Link Types," value 4 is not > available. Please see > > https://www.iana.org/assignments/ospfv3-parameters > > For the third registry in the document, if "BGP-LS Link NLRI Registry" > refers to "BGP-LS NLRI-Types," value 1101 is available, but because > this is a Specification Required registry, we'll have to ask the > designated experts to confirm that this is OK. Can you confirm that > this is the correct registry? > > https://www.iana.org/assignments/bgp-ls-parameters > > You can see a list of registries here: > > https://www.iana.org/protocols > > thanks, > > Amanda Baber > Lead IANA Services Specialist > > On Thu Dec 14 08:52:23 2017, ppsenak@cisco.com wrote: > > Hi Acee, > > > > On 14/12/17 01:39 , Acee Lindem (acee) wrote: > > > Please provide allocations for the code points in > > > draft-ietf-ospf-link-overload-10.txt: > > > > > > OSPF Extended Link TLVs Registry > > > > more precisely, these should be allocated from "OSPFv2 Extended Link > > TLV > > Sub-TLVs" registry. The text in the draft should be updated as well > > to > > reflect the correct registry name. At this point it says "OSPF > > Extended > > Link TLVs Registry", which would suggest it is from a different, top > > level TLV registry. > > > > Also I see that value 5 has been taken by RFC8169 already. > > > > thanks, > > Peter > > > > > > > > i) Link-Overload sub-TLV - Suggested value 5 > > > > > > ii) Remote IPv4 address sub-TLV - Suggested value 4 > > > > > > iii) Local/Remote Interface ID sub-TLV - Suggested Value 11 > > > > > > OSPFV3 Router Link TLV Registry > > > > > > i) Link-Overload sub-TLV - suggested value 4 > > > > > > BGP-LS Link NLRI Registry [RFC7752] > > > > > > i)Link-Overload TLV - Suggested 1101 > > > > > > Thanks, > > > > > > Acee > > > > > > On 12/13/17, 2:57 PM, "Acee Lindem (acee)" wrote: > > > > > >> Acee Lindem has requested publication of draft-ietf-ospf-link- > > >> overload-10 > > >> as Proposed Standard on behalf of the OSPF working group. > > >> > > >> Please verify the document's state at > > >> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ > > >> > > > > > > _______________________________________________ > > > 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 Fri Dec 15 01:48:30 2017 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 B49DF128799 for ; Fri, 15 Dec 2017 01:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 7ddRo3I4dVPp for ; Fri, 15 Dec 2017 01:48:26 -0800 (PST) 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 0668412711E for ; Fri, 15 Dec 2017 01:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5786; q=dns/txt; s=iport; t=1513331306; x=1514540906; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2BMAKTCBiwd/VznWWYDgdegln+i3LbCfBt5F2jHw+94=; b=MIhOhW34E3nIIdYgvQEpO244Dor4Mc96/QwnBzCrB2trOfhfBJvil5zV KZYp1e896tnPC1x2kBSzcXnDxqzOQAVz4k8sfo6/XJxcf9bZAFskuicIi ldPtn+Huh+pTp46S35D6ih/H5IxR6MGveKQZ/8xyG6S6JQhSb9QVJK+JU 4=; X-IronPort-AV: E=Sophos;i="5.45,404,1508803200"; d="scan'208";a="880620" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2017 09:48:24 +0000 Received: from [10.60.140.55] (ams-ppsenak-nitro6.cisco.com [10.60.140.55]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vBF9mNTI004177; Fri, 15 Dec 2017 09:48:24 GMT Message-ID: <5A339A6F.9020508@cisco.com> Date: Fri, 15 Dec 2017 10:48:31 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jeff Tantsura , iana-prot-param-comment@iana.org, Acee Lindem CC: mnanduri@ebay.com, luay.jalil@verizon.com, ospf@ietf.org References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> <5A323BC6.80209@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 15 Dec 2017 09:48:29 -0000 Hi Amanda, Jeff, On 15/12/17 02:34 , Jeff Tantsura wrote: > Hi Amanda, > > Please note, in the draft-ietf-ospf-segment-routing-msd regretfully, the authors have requested an allocation from OSPFv2 Extended Link Opaque LSA TLVs while it should have been from OSPFv2 Extended Link TLV Sub-TLVs registry. > > Updated draft has been published (draft-ietf-ospf-segment-routing-msd-08) and email to update the allocation (value of 6 from OSPFv2 Extended Link TLV Sub-TLVs registry) has been sent to iana-issues-comment@iana.org (so 6 is unavailable) > > > Back to draft-ietf-ospf-link-overload OSPFv3 allocations- it is quite complicated and requires resolution. > I believe, the registry in question would be “OSPFv3 Extend-LSA Sub-TLV”, please note - draft-ietf-ospf-ospfv3-segment-routing-extensions has already suggested values 3(used already by the base draft for route-tag) to 14 for their use. right, the correct registry should be OSPFv3 Extended-LSA sub-TLV. Unfortunately, this registry has not yet been created as it comes from draft-ietf-ospf-ospfv3-lsa-extend, which has not yet been published as RFC. Now, draft-ietf-ospf-ospfv3-segment-routing-extensions have origially defined values 3-14 out of "OSPFv3 Extended-LSA sub-TLV" registry, but only values 3 to 6 would be needed. We should make early IANA allocation for these values (3,4,5,6) immediately as the "OSPFv3 Extended-LSA sub-TLV" becomes available - the reason is that there are implementation of OSPFv3 SR out there. Then draft-ietf-ospf-link-overload can take the next value, e.g. 7 from "OSPFv3 Extended-LSA sub-TLV" registry. thanks, Peter > > Hopefully I haven’t caused even more confusion than before, we just need to sort out who is getting what ;-) > > Many thanks! > > Cheers, > Jeff > > -----Original Message----- > From: OSPF on behalf of Amanda Baber via RT > Reply-To: > Date: Thursday, December 14, 2017 at 16:55 > Cc: , , > Subject: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 > > Hi all, > > As Peter pointed out, there appear to be issues with these registrations. > > Is the first registry, "OSPF Extended Link TLVs Registry," meant to refer to "OSPFv2 Extended Link Opaque LSA TLVs" or "OSPFv2 Extended Link TLV Sub-TLVs"? In the first of those, values 4, 5, and 11 are available. In the second, values 4 and 5 are not available. Please see > > https://www.iana.org/assignments/ospfv2-parameters > > For the second registry in the document, if "OSPFV3 Router Link TLV Registry" refers to "OSPFv3 Router LSA Link Types," value 4 is not available. Please see > > https://www.iana.org/assignments/ospfv3-parameters > > For the third registry in the document, if "BGP-LS Link NLRI Registry" refers to "BGP-LS NLRI-Types," value 1101 is available, but because this is a Specification Required registry, we'll have to ask the designated experts to confirm that this is OK. Can you confirm that this is the correct registry? > > https://www.iana.org/assignments/bgp-ls-parameters > > You can see a list of registries here: > > https://www.iana.org/protocols > > thanks, > > Amanda Baber > Lead IANA Services Specialist > > On Thu Dec 14 08:52:23 2017, ppsenak@cisco.com wrote: > > Hi Acee, > > > > On 14/12/17 01:39 , Acee Lindem (acee) wrote: > > > Please provide allocations for the code points in > > > draft-ietf-ospf-link-overload-10.txt: > > > > > > OSPF Extended Link TLVs Registry > > > > more precisely, these should be allocated from "OSPFv2 Extended Link TLV > > Sub-TLVs" registry. The text in the draft should be updated as well to > > reflect the correct registry name. At this point it says "OSPF Extended > > Link TLVs Registry", which would suggest it is from a different, top > > level TLV registry. > > > > Also I see that value 5 has been taken by RFC8169 already. > > > > thanks, > > Peter > > > > > > > > i) Link-Overload sub-TLV - Suggested value 5 > > > > > > ii) Remote IPv4 address sub-TLV - Suggested value 4 > > > > > > iii) Local/Remote Interface ID sub-TLV - Suggested Value 11 > > > > > > OSPFV3 Router Link TLV Registry > > > > > > i) Link-Overload sub-TLV - suggested value 4 > > > > > > BGP-LS Link NLRI Registry [RFC7752] > > > > > > i)Link-Overload TLV - Suggested 1101 > > > > > > Thanks, > > > > > > Acee > > > > > > On 12/13/17, 2:57 PM, "Acee Lindem (acee)" wrote: > > > > > >> Acee Lindem has requested publication of draft-ietf-ospf-link-overload-10 > > >> as Proposed Standard on behalf of the OSPF working group. > > >> > > >> Please verify the document's state at > > >> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ > > >> > > > > > > _______________________________________________ > > > 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 Fri Dec 15 09:10:58 2017 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 38EFC127241 for ; Fri, 15 Dec 2017 09:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, 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 4hBJvjG9Xzho for ; Fri, 15 Dec 2017 09:10:55 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29082126CD8 for ; Fri, 15 Dec 2017 09:10:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4616; q=dns/txt; s=iport; t=1513357855; x=1514567455; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1M5dDK18eC8L05ZIdo41Sf5nk6vqqVp5onkTn1q88MY=; b=lgkcAk9l9XcHo0TX8z41xt/EndRxWrCXPcRDQ6THHE0I+9gL5OWteRXS USss6fu+ADqJvikwOCWX7BrDZXgqWgAHS5kMdPBcyeE0v1C3/ydwREDjO MOaBs7U5IGwOZ3fz85syphVnbLYtmZQJOJccwysIJq3BePAyBiOviIq3b g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DIAABtATRa/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPCIIAlyCCFQoYC4UYAhqEZj8YAQEBAQEBAQE?= =?us-ascii?q?Bax0LhSQBAQQBASERNwMLEAIBCBgCAiYCAgIlCxUQAgQOBYoqEKkYgieKVQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CWoIOgz+DLIFJgWUBAYFtF4J+gmMFkhq?= =?us-ascii?q?HQolaAod8jS2CFoYTi0iNGIkwAhEZAYE6AR85gU9vFTyCKYJfKYFOeIkxgRUBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.45,405,1508803200"; d="scan'208";a="331032006" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2017 17:10:54 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vBFHArou032292 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Dec 2017 17:10:54 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.1320.4; Fri, 15 Dec 2017 12:10:53 -0500 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.1320.000; Fri, 15 Dec 2017 12:10:53 -0500 From: "Acee Lindem (acee)" To: "iana-prot-param-comment@iana.org" CC: "ospf@ietf.org" , "Peter Psenak (ppsenak)" , "shraddha@juniper.net" , "pushpasis.ietf@gmail.com" , "hannes@gredler.at" , "mnanduri@ebay.com" , "luay.jalil@verizon.com" , "Abhay Roy (akr)" , "aretana.ietf@gmail.com" , "db3546@att.com" , "akatlas@gmail.com" , Hannes Gredler , Adrian Farrel Thread-Topic: [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 Thread-Index: AQHTdHQRIguhjQmtOke8EJ3PPxRuDKNDldD7gAEQkAA= Date: Fri, 15 Dec 2017 17:10:53 +0000 Message-ID: References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> <5A323BC6.80209@cisco.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.198] Content-Type: text/plain; charset="utf-8" Content-ID: <825332D2F4C52F4A8669BECCCA586AD2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 15 Dec 2017 17:10:57 -0000 SGkgQW1hbmRhLCANCg0KT24gMTIvMTQvMTcsIDc6NTUgUE0sICJBbWFuZGEgQmFiZXIgdmlhIFJU Ig0KPGlhbmEtcHJvdC1wYXJhbS1jb21tZW50QGlhbmEub3JnPiB3cm90ZToNCg0KPkhpIGFsbCwN Cj4NCj5BcyBQZXRlciBwb2ludGVkIG91dCwgdGhlcmUgYXBwZWFyIHRvIGJlIGlzc3VlcyB3aXRo IHRoZXNlIHJlZ2lzdHJhdGlvbnMuDQo+DQo+SXMgdGhlIGZpcnN0IHJlZ2lzdHJ5LCAiT1NQRiBF eHRlbmRlZCBMaW5rIFRMVnMgUmVnaXN0cnksIiBtZWFudCB0byByZWZlcg0KPnRvICAiT1NQRnYy IEV4dGVuZGVkIExpbmsgT3BhcXVlIExTQSBUTFZzIiBvciAiT1NQRnYyIEV4dGVuZGVkIExpbmsg VExWDQo+U3ViLVRMVnMiPyBJbiB0aGUgZmlyc3Qgb2YgdGhvc2UsIHZhbHVlcyA0LCA1LCBhbmQg MTEgYXJlIGF2YWlsYWJsZS4gSW4NCj50aGUgc2Vjb25kLCB2YWx1ZXMgNCBhbmQgNSBhcmUgbm90 IGF2YWlsYWJsZS4gUGxlYXNlIHNlZQ0KPg0KPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1l bnRzL29zcGZ2Mi1wYXJhbWV0ZXJzDQoNClNvdW5kcyBnb29kIHRvIG1lLg0KDQo+DQo+Rm9yIHRo ZSBzZWNvbmQgcmVnaXN0cnkgaW4gdGhlIGRvY3VtZW50LCBpZiAiT1NQRlYzIFJvdXRlciBMaW5r IFRMVg0KPlJlZ2lzdHJ5IiByZWZlcnMgdG8gIk9TUEZ2MyBSb3V0ZXIgTFNBIExpbmsgVHlwZXMs IiB2YWx1ZSA0IGlzIG5vdA0KPmF2YWlsYWJsZS4gUGxlYXNlIHNlZQ0KPg0KPmh0dHBzOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29zcGZ2My1wYXJhbWV0ZXJzDQoNCkxldOKAmXMgZGVmZXIg dGhpcyBmb3Igbm93LiBXZSBkb27igJl0IGV2ZW4gaGF2ZSBlYXJseSBhbGxvY2F0aW9uIGZvciB0 aGUNCnJlZ2lzdHJpZXMgeWV0IGFuZCB0aGlzIHdvdWxkIGJlIHJlcXVlc3RlZCBmb3Ig4oCcT1NQ RnYzIEV4dGVuZGVkIExTQXPigJ0uDQpTb3JyeSBmb3Igbm90IHNlZWluZyB0aGlzIGluIG15IGlu aXRpYWwgRS1tYWlsLiBXZSByZWNlbnRseSByZWluc3RhdGVkIHRoZQ0KT1NQRnYzIHNwZWNpZmlj YXRpb24gc2luY2UgT1NQRnYzIEV4dGVuZGVkIExTQXMgaXMgYmVpbmcgcHJvZ3Jlc3NlZC4NCg0K Pg0KPkZvciB0aGUgdGhpcmQgcmVnaXN0cnkgaW4gdGhlIGRvY3VtZW50LCBpZiAiQkdQLUxTIExp bmsgTkxSSSBSZWdpc3RyeSINCj5yZWZlcnMgdG8gIkJHUC1MUyBOTFJJLVR5cGVzLCIgdmFsdWUg MTEwMSBpcyBhdmFpbGFibGUsIGJ1dCBiZWNhdXNlIHRoaXMNCj5pcyBhIFNwZWNpZmljYXRpb24g UmVxdWlyZWQgcmVnaXN0cnksIHdlJ2xsIGhhdmUgdG8gYXNrIHRoZSBkZXNpZ25hdGVkDQo+ZXhw ZXJ0cyB0byBjb25maXJtIHRoYXQgdGhpcyBpcyBPSy4gQ2FuIHlvdSBjb25maXJtIHRoYXQgdGhp cyBpcyB0aGUNCj5jb3JyZWN0IHJlZ2lzdHJ5Pw0KPg0KPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fz c2lnbm1lbnRzL2JncC1scy1wYXJhbWV0ZXJzDQoNClNvdW5kcyBnb29kLCBJ4oCZdmUgY29waWVk IEhhbm5lcyBhbmQgQWRyaWFuLg0KDQpUaGFua3MsDQpBY2VlDQoNCg0KPllvdSBjYW4gc2VlIGEg bGlzdCBvZiByZWdpc3RyaWVzIGhlcmU6DQo+DQo+aHR0cHM6Ly93d3cuaWFuYS5vcmcvcHJvdG9j b2xzDQo+DQo+dGhhbmtzLA0KPg0KPkFtYW5kYSBCYWJlcg0KPkxlYWQgSUFOQSBTZXJ2aWNlcyBT cGVjaWFsaXN0DQo+DQo+T24gVGh1IERlYyAxNCAwODo1MjoyMyAyMDE3LCBwcHNlbmFrQGNpc2Nv LmNvbSB3cm90ZToNCj4+IEhpIEFjZWUsDQo+PiANCj4+IE9uIDE0LzEyLzE3IDAxOjM5ICwgQWNl ZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPj4gPiBQbGVhc2UgcHJvdmlkZSBhbGxvY2F0aW9ucyBm b3IgdGhlIGNvZGUgcG9pbnRzIGluDQo+PiA+IGRyYWZ0LWlldGYtb3NwZi1saW5rLW92ZXJsb2Fk LTEwLnR4dDoNCj4+ID4NCj4+ID4gICBPU1BGIEV4dGVuZGVkIExpbmsgVExWcyBSZWdpc3RyeQ0K Pj4gDQo+PiBtb3JlIHByZWNpc2VseSwgdGhlc2Ugc2hvdWxkIGJlIGFsbG9jYXRlZCBmcm9tICJP U1BGdjIgRXh0ZW5kZWQgTGluaw0KPj5UTFYgDQo+PiBTdWItVExWcyIgcmVnaXN0cnkuIFRoZSB0 ZXh0IGluIHRoZSBkcmFmdCBzaG91bGQgYmUgdXBkYXRlZCBhcyB3ZWxsIHRvDQo+PiByZWZsZWN0 IHRoZSBjb3JyZWN0IHJlZ2lzdHJ5IG5hbWUuIEF0IHRoaXMgcG9pbnQgaXQgc2F5cyAiT1NQRiBF eHRlbmRlZA0KPj4gTGluayBUTFZzIFJlZ2lzdHJ5Iiwgd2hpY2ggd291bGQgc3VnZ2VzdCBpdCBp cyBmcm9tIGEgZGlmZmVyZW50LCB0b3ANCj4+IGxldmVsIFRMViByZWdpc3RyeS4NCj4+IA0KPj4g QWxzbyBJIHNlZSB0aGF0IHZhbHVlIDUgaGFzIGJlZW4gdGFrZW4gYnkgUkZDODE2OSBhbHJlYWR5 Lg0KPj4gDQo+PiB0aGFua3MsDQo+PiBQZXRlcg0KPj4gDQo+PiA+DQo+PiA+ICAgICBpKSBMaW5r LU92ZXJsb2FkIHN1Yi1UTFYgLSBTdWdnZXN0ZWQgdmFsdWUgNQ0KPj4gPg0KPj4gPiAgICAgaWkp IFJlbW90ZSBJUHY0IGFkZHJlc3Mgc3ViLVRMViAtIFN1Z2dlc3RlZCB2YWx1ZSA0DQo+PiA+DQo+ PiA+ICAgICBpaWkpIExvY2FsL1JlbW90ZSBJbnRlcmZhY2UgSUQgc3ViLVRMViAtIFN1Z2dlc3Rl ZCBWYWx1ZSAxMQ0KPj4gPg0KPj4gPiAgICAgT1NQRlYzIFJvdXRlciBMaW5rIFRMViBSZWdpc3Ry eQ0KPj4gPg0KPj4gPiAgICAgaSkgTGluay1PdmVybG9hZCBzdWItVExWIC0gc3VnZ2VzdGVkIHZh bHVlIDQNCj4+ID4NCj4+ID4gICAgIEJHUC1MUyBMaW5rIE5MUkkgUmVnaXN0cnkgW1JGQzc3NTJd DQo+PiA+DQo+PiA+IGkpTGluay1PdmVybG9hZCBUTFYgLSBTdWdnZXN0ZWQgMTEwMQ0KPj4gPg0K Pj4gPiBUaGFua3MsDQo+PiA+DQo+PiA+IEFjZWUNCj4+ID4NCj4+ID4gT24gMTIvMTMvMTcsIDI6 NTcgUE0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiA+ DQo+PiA+PiBBY2VlIExpbmRlbSBoYXMgcmVxdWVzdGVkIHB1YmxpY2F0aW9uIG9mDQo+PmRyYWZ0 LWlldGYtb3NwZi1saW5rLW92ZXJsb2FkLTEwDQo+PiA+PiBhcyBQcm9wb3NlZCBTdGFuZGFyZCBv biBiZWhhbGYgb2YgdGhlIE9TUEYgd29ya2luZyBncm91cC4NCj4+ID4+DQo+PiA+PiBQbGVhc2Ug dmVyaWZ5IHRoZSBkb2N1bWVudCdzIHN0YXRlIGF0DQo+PiA+PiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9zcGYtbGluay1vdmVybG9hZC8NCj4+ID4+DQo+PiA+ DQo+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+IE9TUEYgbWFpbGluZyBsaXN0DQo+PiA+IE9TUEZAaWV0Zi5vcmcNCj4+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3BmDQo+PiA+IC4NCj4+ID4NCj4+IA0KPg0K Pg0KPg0KDQo= From nobody Fri Dec 15 11:15:15 2017 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 98590129406 for ; Fri, 15 Dec 2017 11:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 AmpHL_LDUFoS for ; Fri, 15 Dec 2017 11:15:08 -0800 (PST) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 7E56C126CC7 for ; Fri, 15 Dec 2017 11:15:08 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id B1032E0CCA; Fri, 15 Dec 2017 19:15:07 +0000 (UTC) Received: by request3.lax.icann.org (Postfix, from userid 48) id 71F25C20667; Fri, 15 Dec 2017 19:15:07 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-prot-param-comment@iana.org In-Reply-To: <5A323BC6.80209@cisco.com> References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> <5A323BC6.80209@cisco.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #992646 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: luay.jalil@verizon.com, akatlas@gmail.com, pushpasis.ietf@gmail.com, shraddha@juniper.net, adrian@olddog.co.com, ospf@ietf.org, ppsenak@cisco.com, hannes@gredler.at, akr@cisco.com, jefftant.ietf@gmail.com, db3546@att.com, mnanduri@ebay.com, aretana.ietf@gmail.com Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 15 Dec 2017 19:15:07 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 19:15:11 -0000 Hi Acee, Peter, Acee replied: > >Is the first registry, "OSPF Extended Link TLVs Registry," meant to refer > >to "OSPFv2 Extended Link Opaque LSA TLVs" or "OSPFv2 Extended Link TLV > >Sub-TLVs"? In the first of those, values 4, 5, and 11 are available. In > >the second, values 4 and 5 are not available. Please see > > > >https://www.iana.org/assignments/ospfv2-parameters > > Sounds good to me. Are we making the assignments in OSPF Extended Link TLVs Registry, which does have the values available? It looks like Peter wrote below that these should instead be allocated from the second option, the OSPFv2 Extended Link TLV Sub-TLVs registry, where values 4 and 5 have already been assigned. thanks, Amanda On Thu Dec 14 08:52:23 2017, ppsenak@cisco.com wrote: > Hi Acee, > > On 14/12/17 01:39 , Acee Lindem (acee) wrote: > > Please provide allocations for the code points in > > draft-ietf-ospf-link-overload-10.txt: > > > > OSPF Extended Link TLVs Registry > > more precisely, these should be allocated from "OSPFv2 Extended Link TLV > Sub-TLVs" registry. The text in the draft should be updated as well to > reflect the correct registry name. At this point it says "OSPF Extended > Link TLVs Registry", which would suggest it is from a different, top > level TLV registry. > > Also I see that value 5 has been taken by RFC8169 already. > > thanks, > Peter > > > > > i) Link-Overload sub-TLV - Suggested value 5 > > > > ii) Remote IPv4 address sub-TLV - Suggested value 4 > > > > iii) Local/Remote Interface ID sub-TLV - Suggested Value 11 > > > > OSPFV3 Router Link TLV Registry > > > > i) Link-Overload sub-TLV - suggested value 4 > > > > BGP-LS Link NLRI Registry [RFC7752] > > > > i)Link-Overload TLV - Suggested 1101 > > > > Thanks, > > > > Acee > > > > On 12/13/17, 2:57 PM, "Acee Lindem (acee)" wrote: > > > >> Acee Lindem has requested publication of draft-ietf-ospf-link-overload-10 > >> as Proposed Standard on behalf of the OSPF working group. > >> > >> Please verify the document's state at > >> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ > >> > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > . > > > From nobody Sat Dec 16 10:11:14 2017 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 D094A126CF6 for ; Sat, 16 Dec 2017 10:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 thNnWyuz9oDX for ; Sat, 16 Dec 2017 10:11:11 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF84A12422F for ; Sat, 16 Dec 2017 10:11:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4304; q=dns/txt; s=iport; t=1513447871; x=1514657471; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hCVhrV1zpVTm5DyKdrQUfclZy+8dZT97olUUqwqbf5Q=; b=VbcS1pr3qq10LUvnVXsP/ccqeIQ7LTR7Jm6RC9bcv1ZpfGKlAE4ctWgj 9OEhe5WWLbsHTET3oEOZoOMA49XBDD7AEbAxCiyBijtvNNQPAVl7Ajqy/ rduHbqL0EhrfCy05H9JzCGsHvYOXYegY5ik4k7g7NCvJ35O4xttLFL3fY Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AACxYDVa/4kNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N/iiGPB4IAlyGCFQoYC4UYAhqEZj8YAQEBAQEBAQE?= =?us-ascii?q?Bax0LhSQBAQEDAQEhEToLEAIBCBgCAiYCAgIlCxUQAgQOBYoqEKddgieKZQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGQWBD4Jfgg6DP4MsgUmBZQEBgW0Xgn6CYwWSG5E?= =?us-ascii?q?hAod9jS2CFoYTi0qNG4kwAhEZAYE6AR85gU9vFTyCKYJfKYFOeIlOgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,411,1508803200"; d="scan'208";a="331360700" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Dec 2017 18:11:10 +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 vBGIBA1G005588 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Dec 2017 18:11:10 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.1320.4; Sat, 16 Dec 2017 13:11:09 -0500 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.1320.000; Sat, 16 Dec 2017 13:11:09 -0500 From: "Acee Lindem (acee)" To: "iana-prot-param-comment@iana.org" CC: "adrian@olddog.co.com" , "mnanduri@ebay.com" , "luay.jalil@verizon.com" , "ospf@ietf.org" Thread-Topic: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 Thread-Index: AQHTdHQRIguhjQmtOke8EJ3PPxRuDKNEyTOCgAGAVYA= Date: Sat, 16 Dec 2017 18:11:09 +0000 Message-ID: References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> <5A323BC6.80209@cisco.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.198] Content-Type: text/plain; charset="utf-8" Content-ID: <52F819B8AD86394FB5730662D2FF5D3E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 16 Dec 2017 18:11:14 -0000 SGkgQW1hbmRhLCANCg0KUmlnaHQgLSBhc3NpZ25tZW50cyBmb3IgdGhlIFJlbW90ZSBJUHY0IGFk ZHJlc3MgU3ViLVRMViwgTG9jYWwvUmVtb3RlDQpJbnRlcmZhY2UgSUQgU3ViLVRMViwgYW5kIExp bmstT3ZlcmxvYWQgU3ViLVRMViBzaG91bGQgYmUgdGFrZW4gZnJvbSB0aGUNCnVuYXNzaWduZWQg dmFsdWVzICg3LTMyNzY3KS4gVGhlIHZhbHVlcyBpbiB0aGUgZHJhZnQgd2VyZSBzdWdnZXN0ZWQg c2luY2UNCnRoZXkgd2VyZSB1bmFzc2lnbmVkIHdoZW4gdGhlIGRyYWZ0IHdhcyBmaXJzdCBhdXRo b3JlZC4gSG93ZXZlciwgdG8gdGhlDQpiZXN0IG9mIG15IGtub3dsZWRnZSwgdGhlcmUgYXJlIG5v IGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGVzZSB2YWx1ZXMuDQoNClRoYW5rcywNCkFjZWUgDQoN Ck9uIDEyLzE1LzE3LCAyOjE1IFBNLCAiT1NQRiBvbiBiZWhhbGYgb2YgQW1hbmRhIEJhYmVyIHZp YSBSVCINCjxvc3BmLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGlhbmEtcHJvdC1wYXJh bS1jb21tZW50QGlhbmEub3JnPg0Kd3JvdGU6DQoNCj5IaSBBY2VlLCBQZXRlciwNCj4NCj5BY2Vl IHJlcGxpZWQ6IA0KPg0KPj4gPklzIHRoZSBmaXJzdCByZWdpc3RyeSwgIk9TUEYgRXh0ZW5kZWQg TGluayBUTFZzIFJlZ2lzdHJ5LCIgbWVhbnQgdG8NCj4+cmVmZXINCj4+ID50byAgIk9TUEZ2MiBF eHRlbmRlZCBMaW5rIE9wYXF1ZSBMU0EgVExWcyIgb3IgIk9TUEZ2MiBFeHRlbmRlZCBMaW5rIFRM Vg0KPj4gPlN1Yi1UTFZzIj8gSW4gdGhlIGZpcnN0IG9mIHRob3NlLCB2YWx1ZXMgNCwgNSwgYW5k IDExIGFyZSBhdmFpbGFibGUuIEluDQo+PiA+dGhlIHNlY29uZCwgdmFsdWVzIDQgYW5kIDUgYXJl IG5vdCBhdmFpbGFibGUuIFBsZWFzZSBzZWUNCj4+ID4NCj4+ID5odHRwczovL3d3dy5pYW5hLm9y Zy9hc3NpZ25tZW50cy9vc3BmdjItcGFyYW1ldGVycw0KPj4gDQo+PiBTb3VuZHMgZ29vZCB0byBt ZS4NCj4NCj5BcmUgd2UgbWFraW5nIHRoZSBhc3NpZ25tZW50cyBpbiBPU1BGIEV4dGVuZGVkIExp bmsgVExWcyBSZWdpc3RyeSwgd2hpY2gNCj5kb2VzIGhhdmUgdGhlIHZhbHVlcyBhdmFpbGFibGU/ IEl0IGxvb2tzIGxpa2UgUGV0ZXIgd3JvdGUgYmVsb3cgdGhhdA0KPnRoZXNlIHNob3VsZCBpbnN0 ZWFkIGJlIGFsbG9jYXRlZCBmcm9tIHRoZSBzZWNvbmQgb3B0aW9uLCB0aGUgT1NQRnYyDQo+RXh0 ZW5kZWQgTGluayBUTFYgU3ViLVRMVnMgcmVnaXN0cnksIHdoZXJlIHZhbHVlcyA0IGFuZCA1IGhh dmUgYWxyZWFkeQ0KPmJlZW4gYXNzaWduZWQuDQo+DQo+dGhhbmtzLA0KPkFtYW5kYQ0KPg0KPk9u IFRodSBEZWMgMTQgMDg6NTI6MjMgMjAxNywgcHBzZW5ha0BjaXNjby5jb20gd3JvdGU6DQo+PiBI aSBBY2VlLA0KPj4gDQo+PiBPbiAxNC8xMi8xNyAwMTozOSAsIEFjZWUgTGluZGVtIChhY2VlKSB3 cm90ZToNCj4+ID4gUGxlYXNlIHByb3ZpZGUgYWxsb2NhdGlvbnMgZm9yIHRoZSBjb2RlIHBvaW50 cyBpbg0KPj4gPiBkcmFmdC1pZXRmLW9zcGYtbGluay1vdmVybG9hZC0xMC50eHQ6DQo+PiA+DQo+ PiA+ICAgT1NQRiBFeHRlbmRlZCBMaW5rIFRMVnMgUmVnaXN0cnkNCj4+IA0KPj4gbW9yZSBwcmVj aXNlbHksIHRoZXNlIHNob3VsZCBiZSBhbGxvY2F0ZWQgZnJvbSAiT1NQRnYyIEV4dGVuZGVkIExp bmsNCj4+VExWIA0KPj4gU3ViLVRMVnMiIHJlZ2lzdHJ5LiBUaGUgdGV4dCBpbiB0aGUgZHJhZnQg c2hvdWxkIGJlIHVwZGF0ZWQgYXMgd2VsbCB0bw0KPj4gcmVmbGVjdCB0aGUgY29ycmVjdCByZWdp c3RyeSBuYW1lLiBBdCB0aGlzIHBvaW50IGl0IHNheXMgIk9TUEYgRXh0ZW5kZWQNCj4+IExpbmsg VExWcyBSZWdpc3RyeSIsIHdoaWNoIHdvdWxkIHN1Z2dlc3QgaXQgaXMgZnJvbSBhIGRpZmZlcmVu dCwgdG9wDQo+PiBsZXZlbCBUTFYgcmVnaXN0cnkuDQo+PiANCj4+IEFsc28gSSBzZWUgdGhhdCB2 YWx1ZSA1IGhhcyBiZWVuIHRha2VuIGJ5IFJGQzgxNjkgYWxyZWFkeS4NCj4+IA0KPj4gdGhhbmtz LA0KPj4gUGV0ZXINCj4+IA0KPj4gPg0KPj4gPiAgICAgaSkgTGluay1PdmVybG9hZCBzdWItVExW IC0gU3VnZ2VzdGVkIHZhbHVlIDUNCj4+ID4NCj4+ID4gICAgIGlpKSBSZW1vdGUgSVB2NCBhZGRy ZXNzIHN1Yi1UTFYgLSBTdWdnZXN0ZWQgdmFsdWUgNA0KPj4gPg0KPj4gPiAgICAgaWlpKSBMb2Nh bC9SZW1vdGUgSW50ZXJmYWNlIElEIHN1Yi1UTFYgLSBTdWdnZXN0ZWQgVmFsdWUgMTENCj4+ID4N Cj4+ID4gICAgIE9TUEZWMyBSb3V0ZXIgTGluayBUTFYgUmVnaXN0cnkNCj4+ID4NCj4+ID4gICAg IGkpIExpbmstT3ZlcmxvYWQgc3ViLVRMViAtIHN1Z2dlc3RlZCB2YWx1ZSA0DQo+PiA+DQo+PiA+ ICAgICBCR1AtTFMgTGluayBOTFJJIFJlZ2lzdHJ5IFtSRkM3NzUyXQ0KPj4gPg0KPj4gPiBpKUxp bmstT3ZlcmxvYWQgVExWIC0gU3VnZ2VzdGVkIDExMDENCj4+ID4NCj4+ID4gVGhhbmtzLA0KPj4g Pg0KPj4gPiBBY2VlDQo+PiA+DQo+PiA+IE9uIDEyLzEzLzE3LCAyOjU3IFBNLCAiQWNlZSBMaW5k ZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gPg0KPj4gPj4gQWNlZSBMaW5k ZW0gaGFzIHJlcXVlc3RlZCBwdWJsaWNhdGlvbiBvZg0KPj5kcmFmdC1pZXRmLW9zcGYtbGluay1v dmVybG9hZC0xMA0KPj4gPj4gYXMgUHJvcG9zZWQgU3RhbmRhcmQgb24gYmVoYWxmIG9mIHRoZSBP U1BGIHdvcmtpbmcgZ3JvdXAuDQo+PiA+Pg0KPj4gPj4gUGxlYXNlIHZlcmlmeSB0aGUgZG9jdW1l bnQncyBzdGF0ZSBhdA0KPj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1vc3BmLWxpbmstb3ZlcmxvYWQvDQo+PiA+Pg0KPj4gPg0KPj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiBPU1BGIG1haWxpbmcg bGlzdA0KPj4gPiBPU1BGQGlldGYub3JnDQo+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb3NwZg0KPj4gPiAuDQo+PiA+DQo+PiANCj4NCj4NCj4NCj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPk9TUEYgbWFpbGluZyBsaXN0 DQo+T1NQRkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b3NwZg0KDQo= From nobody Mon Dec 18 12:23:33 2017 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 1075C12D876; Mon, 18 Dec 2017 12:23:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , akatlas@gmail.com, draft-ietf-ospf-segment-routing-extensions@ietf.org, ospf@ietf.org, Acee Lindem , acee@cisco.com, ospf-chairs@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151362859306.18458.2393617352151993973.idtracker@ietfa.amsl.com> Date: Mon, 18 Dec 2017 12:23:13 -0800 Archived-At: Subject: [OSPF] Protocol Action: 'OSPF Extensions for Segment Routing' to Proposed Standard (draft-ietf-ospf-segment-routing-extensions-24.txt) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:23:13 -0000 The IESG has approved the following document: - 'OSPF Extensions for Segment Routing' (draft-ietf-ospf-segment-routing-extensions-24.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-segment-routing-extensions/ Technical Summary This document describes the OSPFv2 extensions for segment routing including Prefix-SID, Adjacency-SID, and Binding-SID. The extensions are based on RFC 7770. Working Group Summary The Working Group discussion has been dominated by the initial vendors that implemented the specification (Juniper, Cisco, and Nokia). We've gone through several iterations over the last two and half years. The document has completed two separate IPR polls. It is in its second Working Group last call due to some additional protocol encodings and clarifications on the handling of error situations. The second Working Group last call is preceding without questions or significant comments. The ERO and binding-SID extensions were removed due to AD comments and these changes were Working Group last called. Document Quality The document has been implemented by a number of vendors (refer to the implementation status section) and has been stable now for a few months. In fact, the only changes have been edits and clarifications based on WG last-call and chair review. Personnel Acee Lindem is the Document Shepherd. Alia Atlas is the Responsible Area Director. From nobody Mon Dec 18 16:55:47 2017 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 EDEE4124234; Mon, 18 Dec 2017 16:55:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151364494494.7472.544860435737482060@ietfa.amsl.com> Date: Mon, 18 Dec 2017 16:55:44 -0800 Archived-At: Subject: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-lsa-extend-19.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 00:55:45 -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 WG of the IETF. Title : OSPFv3 LSA Extendibility Authors : Acee Lindem Abhay Roy Dirk Goethals Veerendranatha Reddy Vallem Fred Baker Filename : draft-ietf-ospf-ospfv3-lsa-extend-19.txt Pages : 38 Date : 2017-12-18 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-19 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv3-lsa-extend-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-19 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 Dec 18 17:14:38 2017 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 A0D85127735 for ; Mon, 18 Dec 2017 17:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.509 X-Spam-Level: X-Spam-Status: No, score=-13.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 chDhJoylyAR0 for ; Mon, 18 Dec 2017 17:14:34 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E621C127286 for ; Mon, 18 Dec 2017 17:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3376; q=dns/txt; s=iport; t=1513646073; x=1514855673; h=from:cc:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vXL8NiYBIglFLOwdosiAmlQ+oV/x1Z/IZACFbAvAhQQ=; b=Zw+J+267ODkw8h4TU3+8McLT0flpOCHGmHRyFItkQSA90A1GY/u8sE09 /5jrEGUfKeK3jRTs8Hbf8x/fZpGJ/UCu4CF6bBcQd+nrJZqDt4jJYR6Dj mXKxGv/cIpPaFF37ZCAcfGvw70/svF+l4fP4OA3dOe6c0TWP0aGcQDHqI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQDUZjha/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQYDweDf4ohjwqBRQSXWIIVChgNhRYCGgyEYT8YAQEBAQE?= =?us-ascii?q?BAQEBayiFGwkCAQMBASEROgsQAgEIGgImAgICJQsVEAISBYVzhDcQq26CJ4pqA?= =?us-ascii?q?QEBAQEBAQMBAQEBAQEBASCBD4Jfgg6DP4Msgy4BAReEaxSCTwWjPAKHfY0tghZ?= =?us-ascii?q?jhTCLSo0biTACERkBgToBHzmBT28VGCSBBAiBHQmETXiIfIEVAQEF?= X-IronPort-AV: E=Sophos;i="5.45,423,1508803200"; d="scan'208";a="333987858" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2017 01:14:32 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vBJ1EW3f005984 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Dec 2017 01:14:32 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 18 Dec 2017 20:14:31 -0500 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.1320.000; Mon, 18 Dec 2017 20:14:31 -0500 From: "Acee Lindem (acee)" CC: "ospf@ietf.org" Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-lsa-extend-19.txt Thread-Index: AQHTeGa5GeCi6CrlekGbY2YdnXXDZg== Date: Tue, 19 Dec 2017 01:14:31 +0000 Message-ID: References: <151364494494.7472.544860435737482060@ietfa.amsl.com> In-Reply-To: <151364494494.7472.544860435737482060@ietfa.amsl.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.198] Content-Type: text/plain; charset="utf-8" Content-ID: <8B66E6FB0FB5C04AAADFF51FF1A881B6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-lsa-extend-19.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 19 Dec 2017 01:14:37 -0000 VGhpcyB2ZXJzaW9uIGZpeGVzIHRoZSAiSUFOQSBDb25zaWRlcmF0aW9ucyIgT1NQRnYzIEV4dGVu ZGVkIExTQSBTdWItVExWDQpyZWdpc3RyeSB0byBtYXRjaCB0aGUgYm9keSBvZiB0aGUgZHJhZnQu IEFkZGl0aW9uYWxseSwgbW9yZSBndWlkYW5jZSBpcw0KcHJvdmlkZWQgaW4gdGhlIG1hbmFnZW1l bnQgYW5kIGFsbG9jYXRpb24gb2YgdGhlIGFkZGVkIHJlZ2lzdHJpZXMuIEhlbmNlLA0KdGhlIGNo YW5nZXMgYXJlIGNvbmZpcm1lZCB0byB0aGUg4oCcSUFOQSBDb25zaWRlcmF0aW9uc+KAnSBzZWN0 aW9uLg0KDQpPbiAxMi8xOC8xNywgNzo1NSBQTSwgIk9TUEYgb24gYmVoYWxmIG9mIGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyINCjxvc3BmLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj5kaXJlY3Rv cmllcy4NCj5UaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBPcGVuIFNob3J0ZXN0IFBh dGggRmlyc3QgSUdQIFdHIG9mIHRoZQ0KPklFVEYuDQo+DQo+ICAgICAgICBUaXRsZSAgICAgICAg ICAgOiBPU1BGdjMgTFNBIEV4dGVuZGliaWxpdHkNCj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6 IEFjZWUgTGluZGVtDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBBYmhheSBSb3kNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgIERpcmsgR29ldGhhbHMNCj4gICAgICAgICAgICAgICAgICAg ICAgICAgIFZlZXJlbmRyYW5hdGhhIFJlZGR5IFZhbGxlbQ0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgRnJlZCBCYWtlcg0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW9zcGYtb3Nw ZnYzLWxzYS1leHRlbmQtMTkudHh0DQo+CVBhZ2VzICAgICAgICAgICA6IDM4DQo+CURhdGUgICAg ICAgICAgICA6IDIwMTctMTItMTgNCj4NCj5BYnN0cmFjdDoNCj4gICBPU1BGdjMgcmVxdWlyZXMg ZnVuY3Rpb25hbCBleHRlbnNpb24gYmV5b25kIHdoYXQgY2FuIHJlYWRpbHkgYmUgZG9uZQ0KPiAg IHdpdGggdGhlIGZpeGVkLWZvcm1hdCBMaW5rIFN0YXRlIEFkdmVydGlzZW1lbnQgKExTQSkgYXMg ZGVzY3JpYmVkIGluDQo+ICAgUkZDIDUzNDAuICBXaXRob3V0IExTQSBleHRlbnNpb24sIGF0dHJp YnV0ZXMgYXNzb2NpYXRlZCB3aXRoIE9TUEZ2Mw0KPiAgIGxpbmtzIGFuZCBhZHZlcnRpc2VkIElQ djYgcHJlZml4ZXMgbXVzdCBiZSBhZHZlcnRpc2VkIGluIHNlcGFyYXRlDQo+ICAgTFNBcyBhbmQg Y29ycmVsYXRlZCB0byB0aGUgZml4ZWQtZm9ybWF0IExTQXMuICBUaGlzIGRvY3VtZW50IGV4dGVu ZHMNCj4gICB0aGUgTFNBIGZvcm1hdCBieSBlbmNvZGluZyB0aGUgZXhpc3RpbmcgT1NQRnYzIExT QSBpbmZvcm1hdGlvbiBpbg0KPiAgIFR5cGUtTGVuZ3RoLVZhbHVlIChUTFYpIHR1cGxlcyBhbmQg YWxsb3dpbmcgYWR2ZXJ0aXNlbWVudCBvZg0KPiAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gd2l0 aCBhZGRpdGlvbmFsIFRMVnMuICBCYWNrd2FyZCBjb21wYXRpYmlsaXR5DQo+ICAgbWVjaGFuaXNt cyBhcmUgYWxzbyBkZXNjcmliZWQuDQo+DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1vc3BmLW9zcGZ2My1sc2EtZXh0ZW5kLw0KPg0KPlRoZXJlIGFyZSBhbHNv IGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vc3BmLW9zcGZ2My1sc2EtZXh0ZW5kLTE5DQo+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9zcGYtb3NwZnYzLWxzYS1leHRl bmQtMTkNCj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUg YXQ6DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3NwZi1v c3BmdjMtbHNhLWV4dGVuZC0xOQ0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlzc2lvbg0KPnVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5PU1BGIG1haWxp bmcgbGlzdA0KPk9TUEZAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29zcGYNCg0K From nobody Tue Dec 19 14:17:57 2017 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 63EAC12D867; Tue, 19 Dec 2017 14:17:56 -0800 (PST) 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 fGlC3-nkXtgC; Tue, 19 Dec 2017 14:17:55 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 A1F3D12D848; Tue, 19 Dec 2017 14:17:51 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id e30so4979032lfb.9; Tue, 19 Dec 2017 14:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qDUpbjVsGsJe4pSTQ7T4LkDcdhiLMls/huwAY6fLOLA=; b=Rk3S2mmuEcvmnwRQrZAUtY70JiJrEX8Ctu2kWpoiD3nISD0O9pmczT0HyGeqfZAaX9 LM/4SqsM0ebrX4UwnXc+fkT/lIcNxGsHvtwG7w1HfBpLvCIFW97iMWCditAJ9mY5HB2Z SOs0OOGrtZwOcTuD7jn31FKY1pWSxNNe2x0ods568TcBfVJbQlxWelzqYrlIJz2HpMGt zgaUQ6GrE03ogVJJWsq2x3XpgigDzY4b9u/vRRkmBML+up1isy+Y8AGTYMfjt2abE1Ku 4AKvJ/snakTj+uSQttqVUhCFz8+pQyhd8dbDXNXYz/GleG37JAXYErrMpx5OLv65elMl bjhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qDUpbjVsGsJe4pSTQ7T4LkDcdhiLMls/huwAY6fLOLA=; b=T9raAjp4bLYeY6hGBZnXo+DqhLA0acIbS3AizYbTJ0Gpd83N/h0X3TOfGxbVVCGMA1 EPxjJ0JKO5MJowWAisseZGvWiPtOS4n2lQRQ1b7sslNlIdt5hrrkhw0capZ+7t/dJwAP ktQiqf5WydZ3eYxQ/ozHh0d/PPOcJ24BxNNp1/VwZBGCf3Uri8PPwguexc1nhQdx+HyA xhkM4/lcUcMFY7nxX3qHv6nQOSc/5HXTXQ9SlANeD4mcwUr2ubVj3E+IcdA/jmB1tLTw Khh8uy+RFtQJsb1ycojeHVpklYicpvQPcMqD8W0IaOXpWFk99gDO19xzv0IXGl7o+bIN IDhA== X-Gm-Message-State: AKGB3mJ1siv/UHwl1s7Nnez0KwtOKiEQbP06vO3p2G0OLjavC7M51as/ iWkFHACPe5xCTbZgKlXNjAe6ohZSWtkLwYdiyVWrGNcm X-Google-Smtp-Source: ACJfBotx3TksextMziMW08QleqCoGJF6co8H2ikKBdiokMl8tah1+KJP35IxdhDv4Elnoy+uyhRbrdUrGCpwwQFFfuU= X-Received: by 10.25.90.200 with SMTP id y69mr3035473lfk.44.1513721869451; Tue, 19 Dec 2017 14:17:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.56.79 with HTTP; Tue, 19 Dec 2017 14:17:48 -0800 (PST) From: Alia Atlas Date: Tue, 19 Dec 2017 17:17:48 -0500 Message-ID: To: draft-ietf-ospf-link-overload@ietf.org, OSPF List Content-Type: multipart/alternative; boundary="f403045cb3925145c50560b8d6a0" Archived-At: Subject: [OSPF] AD review of draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 19 Dec 2017 22:17:56 -0000 --f403045cb3925145c50560b8d6a0 Content-Type: text/plain; charset="UTF-8" As is customary, I have done my AD review of draft-ietf-ospf-link-overload-10. First, I would like to thank the authors - Shraddha, Pushpasis, Hannes, Mohan, and Luay - as well as the WG for their hard work on this document. I have several minor comments that should be resolved before it goes to IETF Last Call. 1) Personally, not having all of OSPFv2 and OSPFv3 readily in my head, I would find it helpful to have some examples where the Link Type, Link ID, and Link Data aren't enough to differentiate the parallel links. I am, of course, familiar with this issue for IS-IS - but I don't recall running into when implementing LFA. I would find it useful to see some examples of a topology with the LSA with TLV & sub-TLVs to handle some of the cases - particularly interacting with parallel links. 2) If there is the issue with parallel links, why isn't there a remote IPv6 address sub-TLV for use with OSPFv3? 3) The Remote IPv4 address and Local/Remote Interface ID sub-TLVs imply that they are narrowing the scope of the Extended Link Opaque TLV from multiple parallel links to one. However, there is no specific wording explaining how they would be generally applied (and yet the naming implies that they might be) or the implications for other sub-TLVs that might be included or how to handle the new need for multiple Extended Link Opaque TLVs that aren't supported in RFC 7684. From RFC 7684, it is clear that: " If multiple OSPFv2 Extended Link Opaque LSAs include the same link, the attributes from the Opaque LSA with the lowest Opaque ID will be used." and that there should be only one Extended Link TLV. For instance, what happens if a SID sub-TLV is also specified? What if a SID sub-TLV was specified in an Extended Link TLV - and now the router wants to advertise a link-overload for only one of the particularly parallel links? Regards, Alia --f403045cb3925145c50560b8d6a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As is customary, I have done my AD review of draft-ietf-os= pf-link-overload-10.=C2=A0 First, I would like to thank the authors - Shrad= dha, Pushpasis, Hannes, Mohan, and Luay - as well as the WG for their hard = work on this document.

I have several minor comments tha= t should be resolved before it goes to IETF Last Call.

=
1) Personally, not having all of OSPFv2 and OSPFv3 readily in my head,= I would find it helpful to have some examples where the Link Type, Link ID= , and Link Data aren't enough to differentiate the parallel links.=C2= =A0 I am, of course, familiar with this issue for IS-IS - but I don't r= ecall running into when implementing LFA.=C2=A0 I would find it useful to s= ee some examples of a topology with the LSA with TLV & sub-TLVs to hand= le some of the cases - particularly interacting with parallel links.
<= div>
2) If there is the issue with parallel links, why isn= 9;t there a remote IPv6 address sub-TLV for use with OSPFv3?

=
3) The Remote IPv4 address and Local/Remote Interface ID sub-TLV= s imply that they are narrowing the scope of the Extended Link Opaque TLV= =C2=A0 from multiple parallel links to one.=C2=A0 However, there is no spec= ific wording explaining how they would be generally applied (and yet the na= ming implies that they might be) or the implications for other sub-TLVs tha= t might be included or how to handle the new need for multiple Extended Lin= k Opaque TLVs that aren't supported in RFC 7684.=C2=A0 =C2=A0 From RFC = 7684, it is clear that: " If multiple OSPFv2 Extended Link Opaque LSAs= include the same link, the attributes from the Opaque LSA with the lowest = Opaque ID will be used." and that there should be only one Extended Li= nk TLV.

For instance, what happens if a SID sub-TL= V is also specified?=C2=A0 What if a SID sub-TLV was specified in an Extend= ed Link TLV - and now the router wants to advertise a link-overload for onl= y one of the particularly parallel links?

Rega= rds,
Alia
--f403045cb3925145c50560b8d6a0-- From nobody Tue Dec 19 15:49:25 2017 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 85D5F126C3D; Tue, 19 Dec 2017 15:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 UbtSf-w2mJKf; Tue, 19 Dec 2017 15:49:21 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 6474B12D945; Tue, 19 Dec 2017 15:49:18 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id q3so18239128oth.2; Tue, 19 Dec 2017 15:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XYwd7dd0qf9RJ/XUXZUXDs2mu9NcE1UQAbPmzYE/Uc4=; b=o62OVYNkBnj/UavUMQSCknfWKO0OSThnxlbJwGmDEZegBxhuXrz/9Q/9JSGsrK0zAf WMT26k8HJWtRwtAGNQdAb2KYmJeRwGoxp2aHT+7fO9xJhjooNrL5+rVaZcCpJtVtnbr6 1mPBguDUBzsUPgmMeOXeoMWu0DL+mk0wHlagBllnXlRbP2Rdp29Z/p9V0SmMXUEUDGOk ieFJOBisf/KtFWsBc7bWY29ViPfLyORdRGWdoIZ26qUxonzT0SqYelfBFYo6PxyvWJUt YVolRjoNodAJ0mW6SCsPw7YUGsrwZUw8FpHaVq0veSDlZ4uKDb7Gy7nxG5OWBikeMPx/ t79g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XYwd7dd0qf9RJ/XUXZUXDs2mu9NcE1UQAbPmzYE/Uc4=; b=QtoHciCjOt3QN3k6ueEAD/aiBAo6KGbY46fAeZ8s8EXvwlsQ+/tmMCkxS2iDt3ddrl c3mPI4aBV4RLacyJhkp45XAra/H0DaN/s3cX3xYoHZ7buCdsIN2G7oBms1sYXfEYsyF+ Zpwftk9SXuaLZgzeUoNkeb3JkBXsHTz9HXQijrEqcj8wlM7h7UIoQ4bXFdQGWpQMOfws bmtS2rWf1wO/1/lIGNVMNbQIyYaya/aKwjVQv21c7qRmZFOI7AY1ACo98Mrl3e+8CXRX gyVl/b7fXWh7/rg/PUys8J0U63zBQ1zpPKRCV9iDiLN0KK+L7OHYRAM+TtiHKmOknStZ i6Sg== X-Gm-Message-State: AKGB3mILR6UwInHBCVX4YH7bR2CbhNbQmPdcrHPnKRMBMq87q4sVqtqX RGkDkrRyKdhfIOOwSZbG5exbR5BaCzjM5eWelgDif8Jk X-Google-Smtp-Source: ACJfBouFOjXbNqYtKxh9Yex4POyHYxQgkoUh36/wiKRBWvWPkEMPfGQpYC+KLKmBjCoKzdxsSLrBCNdHHZXNbHhEU+0= X-Received: by 10.157.47.34 with SMTP id h31mr4063352otb.362.1513727357162; Tue, 19 Dec 2017 15:49:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.4.54 with HTTP; Tue, 19 Dec 2017 15:49:16 -0800 (PST) From: Alia Atlas Date: Tue, 19 Dec 2017 18:49:16 -0500 Message-ID: To: draft-ietf-ospf-ospfv3-lsa-extend@ietf.org, OSPF List Content-Type: multipart/alternative; boundary="94eb2c0442b0691da40560ba1db2" Archived-At: Subject: [OSPF] AD review of draft-ietf-ospf-ospfv3-lsa-extend X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 19 Dec 2017 23:49:24 -0000 --94eb2c0442b0691da40560ba1db2 Content-Type: text/plain; charset="UTF-8" As is customary, I have done my AD review of draft-ietf-ospf-ospfv3-lsa-extend-19. First, I would like to thank the authors - Acee, Abhay, Dirk, Veerendranatha, and Fred- and the implementors at Nokia and Huawei (who have enabled us to move forward on this critical document) and the WG. This draft is very important for adding improved flexiblity to OSPFv3 for IPv6 compared to what we enjoy for OSPFv2. I do have some minor concerns and nits - as listed below. I am going to put this document into a 3 week IETF Last Call (given the holiday season) and place it on the telechat for Jan 25, 2018. Please do respond and update the draft in a timely fashion (given I'm on vacation until 2018). 1) Given the extensive changes to OSPFv3 and the expectation that implementations of OSPFv3 will support this, the draft should update RFC 5340 (and mention that in the abstract as well). 2) In Sec 3: it would be helpful to indicate how many levels of nesting of TLVs are supported. There are clearly TLVs and sub-TLVs. Can there be sub-sub-TLVs? Can there be an arbitrarily deep level of sub-TLVs? Please just clarify - b/c it can affect folks implementations and also assumptions for how to define the various sub-TLVs. 3) Sec 3.3: Is there a reason that sub-TLVs aren't listed in the figure? I see them in the figures for sec 3.2 and 3.4 without explanation. Consistency would be good. I could picture it being helpful to include, for instance, an SRLG or other information. 4) Sec 4.1: Please clarify whether an E-Router-LSA is malformed if it does not contain at least one Router-Link TLV. 5) Sec 4.7: I believe it is possible to have multiple IPv6 link-local addresses. I do see that RFC 5340 restricted OSPFv3 to advertising just one. Is there a strong reason that if additional are sent "Instances following the first MUST be ignored." ? Perhaps this could be a SHOULD - to allow for flexibility? 6) Sec 5: "an LSA MUST be considered malformed if it does not include any required TLV or Sub-TLVs." should be "...not include all of the required TLVs or sub-TLVs." or the equiv. 7) Sec 6.2: "Furthermore, the extended LSAs will only include those TLVs which require further specification for that new functionality. Hence, this mode of compatibility is know as "sparse-mode"." How does this interact with the Sec 5 that talks about malformed LSAs? It seems like either this would be additional Extended LSAs (not defined in this draft) or it would have to include the mandatory information (but not for all links/ routers). 8) Sec 8.2: Is there a reason to not have a sub-TLV range for either Expert Review or FCFS? There are a lot of values - and this would support experimentation. 9) Since this document is adding the "N" flag - an example for the usage would be helpful - and particularly articulating how it is different from the "LA" flag for usage. Nits: a) Sec 3.1.1: sentence missing a complete verb "The N-bit is to the Inter-Area-Prefix-TLV (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area- Prefix-TLV (Section 3.7)" b) typos: differnt addtional Regards, Alia --94eb2c0442b0691da40560ba1db2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As is customary, I have done my AD review of draft-ietf-os= pf-ospfv3-lsa-extend-19.=C2=A0 First, I would like to thank the authors - A= cee, Abhay, Dirk, Veerendranatha, and Fred- and the implementors at Nokia a= nd Huawei (who have enabled us to move forward on this critical document) a= nd the WG.=C2=A0 This draft is very important for adding improved=C2=A0 fle= xiblity to OSPFv3 for IPv6 compared to what we enjoy for OSPFv2.
<= br>
I do have some minor concerns and nits - as listed below. I a= m going to put this document into a 3 week IETF Last Call (given the holida= y season) and place it on the telechat for Jan 25, 2018.=C2=A0 Please do re= spond and update the draft in a timely fashion (given I'm on vacation u= ntil 2018).

1)=C2=A0 Given the extensive changes t= o OSPFv3 and the expectation that implementations of OSPFv3 will support th= is, the draft should update RFC 5340 (and mention that in the abstract as w= ell).

2) In Sec 3: it would be helpful to indicate= how many levels of nesting of TLVs are supported.=C2=A0 There are clearly = TLVs and sub-TLVs.=C2=A0 Can there be sub-sub-TLVs?=C2=A0 Can there be an a= rbitrarily deep level of sub-TLVs?=C2=A0 Please just clarify - b/c it can a= ffect folks implementations and also assumptions for how to define the vari= ous sub-TLVs.

3) Sec 3.3: Is there a reason that s= ub-TLVs aren't listed in the figure?=C2=A0 I see them in the figures fo= r sec 3.2 and 3.4 without explanation.=C2=A0 Consistency would be good. I c= ould picture it being helpful to include, for instance, an SRLG or other in= formation.

4) Sec 4.1: Please clarify whether an E= -Router-LSA is malformed if it does not contain at least one Router-Link TL= V.

5) Sec 4.7: I believe it is possible to have mu= ltiple IPv6 link-local addresses. I do see that RFC 5340 restricted OSPFv3 = to advertising just one.=C2=A0 Is there a strong reason that if additional = are sent=C2=A0 "Instances following the first MUST be ignored." ?= =C2=A0 Perhaps this could be a SHOULD - to allow for flexibility?

6) Sec 5: "an LSA MUST be considered malformed if it d= oes not include any required TLV or Sub-TLVs."=C2=A0 should be ".= ..not include all of the required TLVs or sub-TLVs." or the equiv.
=

7) Sec 6.2:=C2=A0"Furthermore, the=C2=A0exte= nded LSAs will only include those TLVs which require further=C2=A0specifica= tion for that new functionality.=C2=A0 Hence, this mode of compatibility is= know as "sparse-mode"."=C2=A0 How does this interact with t= he Sec 5 that talks about malformed LSAs?=C2=A0 It seems like either this w= ould be additional Extended LSAs (not defined in this draft) or it would ha= ve to include the mandatory information (but not for all links/ routers).

8) Sec 8.2: Is there a reason to not have a sub-TLV= range for either Expert Review or FCFS?=C2=A0 There are a lot of values - = and this would support experimentation.

9) Since t= his document is adding the "N" flag - an example for the usage wo= uld be helpful - and particularly articulating how it is different from the= "LA" flag for usage.

Nits:

a) = Sec 3.1.1: =C2=A0sentence missing a complete verb =C2=A0"The N-bit is = to the Inter-Area-Prefix-TLV=C2=A0 =C2=A0(Section 3.4), External-Prefix-TLV= (Section 3.6), and Intra-Area-
=C2=A0 =C2=A0Prefix-TLV (Section 3.7)&qu= ot;
b) typos: differnt =C2=A0addtional

Regards,
Alia
--94eb2c0442b0691da40560ba1db2-- From nobody Tue Dec 19 18:23:45 2017 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 15719124234; Tue, 19 Dec 2017 18:23:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-ospf-ospfv3-lsa-extend@ietf.org, akatlas@gmail.com, ospf@ietf.org, Peter Psenak , ospf-chairs@ietf.org, ppsenak@cisco.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151373662406.2677.5097816676176679813.idtracker@ietfa.amsl.com> Date: Tue, 19 Dec 2017 18:23:44 -0800 Archived-At: Subject: [OSPF] Last Call: (OSPFv3 LSA Extendibility) to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 02:23:44 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'OSPFv3 LSA Extendibility' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-01-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Dec 20 11:43:58 2017 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 24478126B6E for ; Wed, 20 Dec 2017 11:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.941 X-Spam-Level: X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 kTlOjufRyUYN for ; Wed, 20 Dec 2017 11:43:54 -0800 (PST) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 A55C51205F1 for ; Wed, 20 Dec 2017 11:43:54 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id B934FE0D36; Wed, 20 Dec 2017 19:43:53 +0000 (UTC) Received: by request3.lax.icann.org (Postfix, from userid 48) id 812B0C20677; Wed, 20 Dec 2017 19:43:53 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-prot-param-comment@iana.org In-Reply-To: References: <151319505743.30097.13501863117618500315.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #992646 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: shraddha@juniper.net, ppsenak@cisco.com, db3546@att.com, pushpasis.ietf@gmail.com, akr@cisco.com, luay.jalil@verizon.com, hannes@gredler.at, jefftant.ietf@gmail.com, akatlas@gmail.com, ospf@ietf.org, mnanduri@ebay.com, aretana.ietf@gmail.com, adrian@olddog.co.uk Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 20 Dec 2017 19:43:53 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 19:43:56 -0000 Hi all, We've made the following early allocation in the BGP-LS NLRI-Types registry: 1101 Link-Overload TLV (TEMPORARY - registered 2017-12-20, expires 2018-12-20) [draft-ietf-ospf-link-overload] Please see https://www.iana.org/assignments/bgp-ls-parameters Since this allocation and the OSPFv2 Extended Prefix TLV Sub-TLV early allocations are complete, this ticket will be closed. thanks, Amanda From nobody Thu Dec 21 15:34:10 2017 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 5F51112D7F7; Thu, 21 Dec 2017 15:34:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: ospf@ietf.org, ietf@ietf.org, draft-ietf-ospf-link-overload.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151389924330.28066.4179341895130268032@ietfa.amsl.com> Date: Thu, 21 Dec 2017 15:34:03 -0800 Archived-At: Subject: [OSPF] Genart telechat review of draft-ietf-ospf-link-overload-10 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 23:34:03 -0000 Reviewer: Joel Halpern Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-ospf-link-overload-10 Reviewer: Joel Halpern Review Date: 2017-12-21 IETF LC End Date: None IESG Telechat date: 2018-01-25 Summary: This document is almost ready for publication as a Proposed Standard. Major issues: If a remote IPv4 address is needed in some cases for link identification, then does it not follow that for IPv6 usage with OSPFv3, a remote IPv6 address is also needed? Minor issues: Why is the remote IPv4 address TLV being defined here? It is not specific to link maintenance. If this is the first place it is needed, could the text at least be clearer that this is a general purpose sub-TLV, not specific to the link maintenance indication? Nits/editorial comments: Given that this document specifically states that the problem to be solved is the desire to take a link out of service, I would strongly prefer that the option being defined by named to match the goal. The link being modified is not overloaded. Could this be renamed the link pending-maintenance indication or something along those lines? I realize the working group knows what it means. But the point of naming is so that folks looking later can understand or find the item. From nobody Fri Dec 22 02:51:20 2017 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 384D8124239; Fri, 22 Dec 2017 02:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_H2=-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=nokia.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 G-LEWGKqpTCI; Fri, 22 Dec 2017 02:51:00 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20124.outbound.protection.outlook.com [40.107.2.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F42126DEE; Fri, 22 Dec 2017 02:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E+2HI2PXB0lLsdXC3PdUTsAu6Qj0U96uyuvaph/s/18=; b=mmXRWH8GYsVHHXsprZ2WyTaEmPJyBIq9dmyUx7NFehedve+34NDEDOUJsFNAAhW8noxMBg7JJykepAKQC2U1Aprga2YphDCYDXxJU3lBK+9XRkl+jcssgCGfQFdiGRqLi3pf/oqPaUo2dpEG4BzrIqw4hrQhiwXwFz26wAWIHzk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from [135.244.199.90] (135.245.212.26) by DB6PR0701MB2134.eurprd07.prod.outlook.com (2603:10a6:4:50::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.3; Fri, 22 Dec 2017 10:50:56 +0000 From: Martin Vigoureux To: rtg-ads@ietf.org Cc: rtg-dir@ietf.org, draft-ietf-ospf-link-overload@ietf.org, ospf@ietf.org Message-ID: <44c0141a-bee1-6a79-079e-29f1ce90058b@nokia.com> Date: Fri, 22 Dec 2017 11:50:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [135.245.212.26] X-ClientProxiedBy: VI1P18901CA0016.EURP189.PROD.OUTLOOK.COM (2603:10a6:801::26) To DB6PR0701MB2134.eurprd07.prod.outlook.com (2603:10a6:4:50::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 451334ae-8556-47a2-96d0-08d54929e1ad X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603307); SRVR:DB6PR0701MB2134; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2134; 3:90avohJWnafHHj8B3PgPpGxXirpRqY7FRaM31KgOXG1gzY2ZGRMvmdmPmDCORm+6LbFHDLxvrACNs2+ndz9hbMWE9VomD7R9RZqedCBc9TpsMJl6uhlS8wNuD8Fh3VGvOEUz8C4qNedQW8HuSHxChjA3x4gFUU3ucraLsVieKzpoF854JtZ5If0/eyQAvOFZt4hHG6WKOVhRCg5cLlyGk7KSx363+hiijpLpGqojd2gxW3UtDkBajn086gfQaSBj; 25:M3Ad36bpfWkRAJt5TBkB1mt9CG/ekpWD3KLpybRT5QxuuQyRM4JW9HTwwGjqsc43b1qWrg/jcbWfm+REGrnRbSsAXg7YEHGPsNAsS/v1NLFgyGg8qLsFw0qw6Bk1JpqGUSFhdAKV1Rl2uC4L0X4YFWV+T+va23PU5pULo/4vkn5ynR3zgkrztocs/PvMcyPAxo16XG4vHrOtTKNM5JbBCu98X9d2iX8A/rkEnpnc1OXhq31g6Xze46AfDlSS4cjCHz2y0yOSJwpZs9ASMXgVDcumrjrNHgt39nZT0TQnOKjsEnjhHMupoffYk4W6Q+uMMCS0Aa3HwZ6tR9fw654JpzUMupeWBwj/cnY1isKflFg=; 31:sCD7pecJVZA0tKPQxEpX6pkk3czXRpNpx2DHMKgJPMdJoTq+7KggiabO1+HazWQxsWqjhDSMcPK/SUjT++cilUnIwtT+gpynbSqhCwFjQ1EThv+b8Tw6BWQYoPOOK9/iNhmJt1mLSiQXEk6Qdjx/Gnixj6gcUACgyNBRNvE+kb5nf+wsRcU4hDh9GpeY2dzyHusg7NEovyTEZZBUAPmqt3VP5EsrdZ69Jcn0ggqlRBI= X-MS-TrafficTypeDiagnostic: DB6PR0701MB2134: X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2134; 20:llbFYcMrGTviJQwGRPhLk55Jiju8fb889ThUpIUW963oET/Zhe4IWXZkpzNB+UKxKDE8TYn6It+uWT4cUbegF0llgB7rW9TgepYoA3DkQ7F7q8f3nJz6ZLoQLvFlrR1q9Hg3Yn84q2D7SUhGTGwn+Gno0z4xQcOyUIWiARTobVInsaK6IhNm8oyQXg8qOX70mHxYEQUfb4bNPb+eZspqr4W2RVsbs0o1nfZ7UbXiUj3OCJbHGlxaHldxTJWa0Ekj6bOOgEytFobF+JgfPpMcad0ZCUQeo43lAubHyERfOxMtngoLckMcKWXt2cp3PlMgBpjVSPZ3RK6bJBN176mN79pZeyBCsSbxpEM731FtEfQIe6faHW9E7P69IwG9lyKemFQuIrvVRcn0MIVa0vYxdZ42aBDms3JB0AytdajqEuFCs9y2S4FC1afBMu6LvFILHsnnVbtsBX3ajvw2TbTO3lINFwgOtAql2xYjiG8WFiLgDwW+4yC2k7TD5WbYOx48; 4:qRE+5cDO2TMntOkRvTHKjbIkaY6lFeo5+emIurUwzd36lEPKcXdE55PM6L70i1lwXX2p/+UA7xRzF913WHQpV/wKzUFSQPQ3MEYWa6m7IV4MX8ejYrDPc6gihPEImDr4bTJHtSurmgOsdo4teEXhADRiWdE5x8JqNM5kEHnvaAWfSqTYGUfc06X5x7yfvxOh8ako9oq2FNB+foiS0XqqKQdgsVLHtu7Ij3Efn31IDLpgXUwbHTO824dk4MnoYZpr1+KKJA4R7CyzFi2iGI4ApA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(11241501184)(806099)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041268)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB6PR0701MB2134; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR0701MB2134; X-Forefront-PRVS: 05299D545B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(39380400002)(366004)(39860400002)(396003)(376002)(346002)(189003)(199004)(377424004)(51444003)(36756003)(316002)(2361001)(4001150100001)(5660300001)(31686004)(6666003)(6916009)(97736004)(230783001)(2870700001)(4326008)(105586002)(52116002)(106356001)(2906002)(2351001)(64126003)(58126008)(50466002)(65826007)(1720100001)(3260700006)(25786009)(86362001)(450100002)(68736007)(23676004)(52146003)(305945005)(66066001)(478600001)(49976008)(83506002)(16576012)(47776003)(7736002)(6486002)(2486003)(16526018)(65806001)(65956001)(8936002)(81166006)(31696002)(59450400001)(6116002)(81156014)(67846002)(8676002)(386003)(3846002)(53936002)(78286006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2134; H:[135.244.199.90]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjIxMzQ7MjM6OXo3OHJjNDZvRGNEMGsxL2o0L254RUNQ?= =?utf-8?B?Yklpd3YzdUhpOTFFOGFrUEF4OW5QL1ZLc291Qm05ZzhOT2c0NGtpdGczeFdo?= =?utf-8?B?QXJHNmVPNklYams0SXp0K1Q1NVZKK1RNckFOTUs4ODVJVFI2SXFBdE5ZeW9C?= =?utf-8?B?MitYbm5qdVZ1YkFEQTNzZlRwZW9FQ0dKcVNaUmdNTDNZRlhCQ3NPdWN0QktL?= =?utf-8?B?bWNqMEV3aURhbk9sRW1DN2pqZjNXUDBmM3RXKy82M0ZSSjAyTmd2ZXRwb0Jn?= =?utf-8?B?L05qSTRlWnowRU00Ukx5NXBoU1VlZHhPdDE2N3dvdnExSzd5aUhTY2VNWXZm?= =?utf-8?B?bHdILzFHWlY3QTlWb1RhdkNQck02SGw4Wm5WbmtGLy82ZS9vTUpmV0Jja1Q5?= =?utf-8?B?dW94SWwwTEF6R29VZXRrWno2MlVpbFFDbE80U3lwTnZZVTkyeGMyOTR1Kzd2?= =?utf-8?B?aGl6RkorOEJjbHloRlpvZm5yV2JLOUZJWUN2L0ZsYWRyZCtEa25JaFNFOXhD?= =?utf-8?B?Z2t0RGI0NU0vMTBLbGgvN3MyMDd4RzJaaEkxMWUzS09HSUlUYXF5bDdhSjc1?= =?utf-8?B?VTBGL0sxNjFLVHE4ZFJNMlBqZEptbVd2Ujh2NytNc2FCQ29WcVVYQXlacVB1?= =?utf-8?B?TkdYaTl4R2NYMHpNdGtlS1ZLbFE0ZHQvM2lOcngxb1NSdk9hdnlOK2V2YUFX?= =?utf-8?B?U25GcUhISnk2Qi9GUkgwdEtLbi85dmlhNHpoUTB6ZWVRaW1NKzhnWE94ajYr?= =?utf-8?B?Z0FvNEZrWGp1NGcyaktjUGRkQTZ5ZjR6blhPVVdDeWNIeVNhNXJycWJaVExi?= =?utf-8?B?dlAxQmRSUjdWVExKbjZTSHVuL1hsR2FkYzAxYnBxSE1GSDJQZGgzMzA3YlNk?= =?utf-8?B?QkhKRjZxSmNTUTJEbEozWkc4ODZLcjltd2VDZ3l6LzE3aC9FR0R4T3FDdmt0?= =?utf-8?B?S2p0ci9Fb2IwRFRROVhUYzhYa21NeGgzQmZCZlBWelRHcXRENk1aeDU1NGha?= =?utf-8?B?aC9BRGVMYWpTVVdTSE5sYnRwZXpEUzZ6Wit2Zk1YbnJ3aitUdHlEcmtCR0J2?= =?utf-8?B?ZnBUYjMwUVloSlpTQkZSRFVaa3E2ZjNqajk2Mk40SG1SV0RhQnIzeVNGOFY3?= =?utf-8?B?UVZickw2bHh0K1VmY1lvNFVnZ3hqaDdsUS9PNlBVYkxmSmVYc2x5cFkwRS84?= =?utf-8?B?Y1NNUTNsSXhqNGtia3JDZlBWNkIydlRONHhwNnArNHlOalpGUEUvQnUrTC9B?= =?utf-8?B?Z2N3SGhrSm9Vdk1XVk5CVDNLTGU0Yy8rT0FIRFJqQVRQZ0xJM05TUkU0Q1ZC?= =?utf-8?B?OEQ5V3ZseXN4TnB2Wmh2QTEvZmhEVVlEQVg2dVNvV2dCTWdUSERhTjhEWUNM?= =?utf-8?B?RGxncnZ5bDJqMWgvb05kcFVFeWJiM3V2dXoreURoSk9FRVRFMkJIaUM5VlBT?= =?utf-8?B?SmUyN3UyajZwQXJ6WnlSNGM2VnF5MTI1VUVuRElFTzNwM1FHamFJcE9VSnRx?= =?utf-8?B?c1F0T2orWm84dUFuTVVDR0ZZMWcwZkRSb3Ivb3luVlkvSXpFM3FiaHlwU1NL?= =?utf-8?B?QmIvVTArTzFUcEZuUVUvMEw1RnBQWWNBWmorQ21qYUh6a1Bsakc5bEtNUlhy?= =?utf-8?B?Zlk4OVNyU0Rpdk1TNmV1RitlcmZzcWVLaUZMN2hzSUxraXQzMVNTQ1RSNmdB?= =?utf-8?B?OGtVZ2labXdXdEs0Q21uY25ZNTFXNjQ2d1pjazluRkZLTVZaY0ZkT3lmQ1Z3?= =?utf-8?B?VktBOHg3OGlyQ1REeDlqMFBkTnZtYnJwdkF4WHZqK3U0d3MwdU5pWi9Hbmor?= =?utf-8?B?NFArZHVLeXdTMG51NHVCbHBYa1FxMlJtRGJKa3h2TjRucEdqUkxYRGVEL2FM?= =?utf-8?B?UHhCUldDQmNlR00zbjNOVkszTWZGSStPK21FS1VYOVQycFFQblFNaEpmTlRu?= =?utf-8?B?MDNUSTluK0NUM2dBa3N0Y2dQVDlQK1NERUhBWE9GWmlNTFpBM3BOdlRmeTdk?= =?utf-8?B?di81WXlHaU9naW5xUXFEd01xNzk5U2Z4b0JJTnNVRmE3QnVONkxFbDN6dVBw?= =?utf-8?Q?naVkDs=3D?= X-Microsoft-Antispam-Message-Info: jlD+txUMC4cHhSPhlioN+DzW6jyU80OzN7cYq7Ij9IWZKRUir3dvwR8dE+wKlIuM7hzp7D1gxU2THemK5qFZdA== X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2134; 6:hb6dF8SIO9Vk7KB0laeucigHomGNwXiDCHfW/MFFQ78W1qGm4LsibnGZa2eGqz8WJn8IIJttLQXceeDEGJvny6LJHNtUlbVTFC0MCLm48qZJ0vxIUlwHDgAh8qWL+Y3Qf+MkznVzEik/8dxel2DaXSN5n///TVCeiXkP2AiiCqNtmt/ulCU6SAhsolNHlsEg4AH+o9vX/Zp/6HzeajiH66HLu/9M7LCc6XXTAFG5W0T1eTCNYqiyWyTSIqsKILwhXWDtlR8bzHHW7sh97SmQlrIFdPGnPnRh2tBR+e98SbUSDxAWUbyFB8dH3Af8cr3VkbarZganG63CblzJ2h8bDSar5jpjtm5rdaFP0TN7eWM=; 5:3F6YsmZTLeroxT68+qd0B9n4g4f8v5n36XUZpcXV0PQv4cNzQpDo5G2WUi9GAxTUfLxLjFHm2INTLkIkqjsc+GGkURbz+USUEpdJPT1ktUATRBVwo0hN2qUxEmOaoYhpy4Mk/lY7I6qzEug1COLplgWhKJAmioFqGr8VpkmFw7c=; 24:sanjqMFcVWfAXmBVlS9MrGc0paZtTKq9YRXySksR3UbsP5Ss8+Zom+sDuMaU259JTnUsT+AJGzzdmZZP+s51+GHwl4JLXRvhMgZ8SQ7Q4II=; 7:Sqiw2mBuGRBR/H6Y0JSAkbt4uArCFO6jRbAGpijuOKUPvL4xaisq/TmwZ+kAI1FyAP9ds0OIBVAJW0j54cDA8MWfaDk3aIh8etqo2zbTvZJiThln4mi/NJBt4BP1T0DBp2dK+w3rNZvXCrQSwad5sw4gXqIbvQqMhScSLtfGu/YOFHxO1xg07YNanFUMCP96dDaOPSn4iQzet7tHotrAPQ8zzFOKFFkRj6vqJ+LysM+chye1Q6WSZN06fqPbxfcM SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Dec 2017 10:50:56.6842 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 451334ae-8556-47a2-96d0-08d54929e1ad X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2134 Archived-At: Subject: [OSPF] RtgDir review: draft-ietf-ospf-link-overload-9 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 22 Dec 2017 10:51:15 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ospf-link-overload-9 Reviewer: Martin Vigoureux Review Date: 2017-12-22 IETF LC End Date: date-if-known Intended Status: Standard Track Summary: This document is basically ready for publication, but has nits (see Comments) that should be considered prior to publication. Comments: So, before accepting this review I took a look at the draft and told myself "oh, not long, not apparently complicated.". Then I started reading it... I have to admit that beyond the apparent simplicity of the objective, I did not understand much at first read. So I went on reading the mailing list and discovered a field of information and more specifically discussions explaining why certain design choices were made. These are missing in the draft. I think that we should not expect readers and implementers to dig into the mailing list to understand the design described in a draft. So I'd like to encourage the authors to add some text which summarizes the discussions that happened on the list and which explains why such and such design was in the end decided. Thanks -m From nobody Fri Dec 22 18:51:49 2017 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 2F4381243FE; Fri, 22 Dec 2017 18:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 c3ygwSajcPcJ; Fri, 22 Dec 2017 18:51:40 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 04E1B124319; Fri, 22 Dec 2017 18:51:40 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7782D941E81B; Sat, 23 Dec 2017 02:51:37 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 23 Dec 2017 02:51:37 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.57]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Sat, 23 Dec 2017 10:51:34 +0800 From: Xuxiaohu To: Jeff Tantsura CC: "pce@ietf.org" , "isis-wg@ietf.org" , "ospf@ietf.org" Thread-Topic: Regarding the relationship between MSD and MSD (type 1) Thread-Index: AQHTe5jxgtLouyh5yEyLK22Wd/ZSOQ== Date: Sat, 23 Dec 2017 02:51:34 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A78A4@NKGEML515-MBS.china.huawei.com> References: <254873F7-39C8-461F-B69F-8B68842181E3@gmail.com> In-Reply-To: <254873F7-39C8-461F-B69F-8B68842181E3@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [OSPF] Regarding the relationship between MSD and MSD (type 1) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 23 Dec 2017 02:51:43 -0000 SGkgSmVmZiwNCg0KKGNjZWQgdG8gUENFIGFuZCBPU1BGIFdHcyBhY2NvcmRpbmdseSkNCg0KSW4g bXkgdW5kZXJzdGFuZGluZywgdGhlIHNlbWFudGljcyBvZiB0aGUgTVNEIHRlcm1pbm9sb2d5IGFz IGRlZmluZWQgaW4gUENFLVNSIGRyYWZ0IGFuZCB0aGUgc2VtYW50aWNzIG9mIHRoZSBNU0QgKHR5 cGUgMSkgdGVybWlub2xvZ3kgYXMgZGVmaW5lZCBpbiBJR1AtTVNEIGRyYWZ0IGFyZSBhY3R1YWxs eSBpbmRpY2F0aW5nIHRoZSBzYW1lIGNhcGFiaWxpdHkgKGkuZS4sIG1heGltdW0gbGFiZWwgc3Rh Y2sgaW1wb3NpdGlvbiBkZXB0aCkgYW5kIHRoZXJlZm9yZSBzdWNoIGNhcGFiaWxpdHkgc2hvdWxk IGJlIHByb3RvY29sLWFnbm9zdGljIGFuZCBjb3VsZCBiZSBhZHZlcnRpc2VkIHZpYSBhbnkgcHJv dG9jb2wgaW5jbHVkaW5nIGJ1dCBsaW1pdGVkIHRvIFBDRVAsIElTLUlTLCBPU1BGIGFuZCBCR1At TFMuIEl0IGp1c3QgaGFwcGVucyB0aGF0IFBDRVAgb25seSBhbm5vdW5jZXMgcGVyLW5vZGUgTVNE IGNhcGFiaWxpdHkgd2hpbGUgSUdQIGFubm91bmNlcyBib3RoIHBlci1ub2RlIGFuZCBwZXItbGlu ayBNU0QgY2FwYWJpbGl0eS4gVGhlcmVmb3JlLCBpdCBzZWVtcyB3b3J0aHdoaWxlIHRvIGlyb24g b3V0IHRoZSB0ZXJtaW5vbG9neSBpbmNvbnNpc3RlbmN5IGJldHdlZW4gTVNEIGFuZCBNU0QgKHR5 cGUgMSksIElNSE8uIFBsZWFzZSBmZWVsIGZyZWUgdG8gY29ycmVjdCBtZSBpZiBteSB1bmRlcnN0 YW5kaW5nIGlzIHdyb25nLg0KDQpCeSB0aGUgd2F5LCBJJ20gdG90YWxseSBub3QgaW50ZW5kaW5n IHRvIG9iamVjdCBhbnl0aGluZzopIEkganVzdCBob3BlIHRvIGVsaW1pbmF0ZSB0aGUgcG90ZW50 aWFsIGNvbmZ1c2lvbiBhYm91dCB0aGVzZSB0d28gdGVybWlub2xvZ2llcyAoZS5nLiwgTVNEIGFu ZCBNU0QodHlwZTEpKSBvciBhdCBsZWFzdCBteSBjb25mdXNpb24uIA0KDQpCZXN0IHJlZ2FyZHMs DQpYaWFvaHUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogSmVmZiBU YW50c3VyYSBbbWFpbHRvOmplZmZ0YW50LmlldGZAZ21haWwuY29tXQ0KPiDlj5HpgIHml7bpl7Q6 IDIwMTflubQxMuaciDIz5pelIDI6NTANCj4g5pS25Lu25Lq6OiBYdXhpYW9odTsgTGVzIEdpbnNi ZXJnIChnaW5zYmVyZyk7IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCk7IENocmlzdGlhbg0KPiBI b3BwczsgaXNpcy13Z0BpZXRmLm9yZw0KPiDmioTpgIE6IGlzaXMtYWRzQGlldGYub3JnOyBkcmFm dC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZEBpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiDn rZTlpI06IOetlOWkjTogW0lzaXMtd2ddIFdHIExhc3QgQ2FsbCBmb3INCj4gZHJhZnQtaWV0Zi1p c2lzLXNlZ21lbnQtcm91dGluZy1tc2QtMDcNCj4gDQo+IFhpYW9odSwNCj4gDQo+IFBDRVAgYW5k IElTSVMoT1NQRikgYXJlIHF1aXRlIGRpZmZlcmVudCBpbiB0aGVpciBmdW5jdGlvbmFsaXR5IGFu ZCBub3QgbWVhbnQgdG8NCj4gZG8gdGhlIHNhbWUgdGhpbmcuIFdydCBTUiBlY29zeXN0ZW0sIFBD RVAgaXMgb3B0aW9uYWwsIHdoaWxlIElHUOKAmXMgYXJlDQo+IG1hbmRhdG9yeS4NCj4gV2hlbiBp dCBjb21lcyB0byBhIG5vZGUgY2FwYWJpbGl0eSwgUENFUCBhbmQgSUdQ4oCZcyBwcm92aWRlIHNh bWUgaW5mb3JtYXRpb24NCj4gYW5kIGZ1bGx5IGFsaWduZWQsIGhvd2V2ZXIgbW9yZSBncmFudWxh ciwgcGVyIGxpbmsgaW5mb3JtYXRpb24gaXMgb25seSBhdmFpbGFibGUNCj4gaW4gSUdQcywgYW5k IHRoaXMgaXMgYXMgcGVyIGRlc2lnbiAobm90IGEgYnVnKS4NCj4gUENFUCBTUiBkcmFmdCAod2hp Y2ggSeKAmW0gY28tYXV0aG9yIG9mKSB3aWxsIGJlIGxhc3QgY2FsbGVkIHNvb24sIHBsZWFzZSBt YWtlDQo+IHN1cmUgeW91IHByb3ZpZGUgeW91ciBjb21tZW50cyB0byB0aGUgUENFIFdHLg0KPiAN Cj4gVGhlIGludGVudGlvbiBvZiB0aGlzIHRocmVhZCBpcyB0byBsYXN0IGNhbGwgZHJhZnQtaWV0 Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1tc2QsDQo+IHRoYXQgaGFzIFR5cGUgMSBkZWZpbmVkIGFu ZCBjcmVhdGVzIElBTkEgcmVnaXN0cnkgZm9yIHRoZSBmdXR1cmUgVHlwZXMuDQo+IEnigJlkIGFw cHJlY2lhdGUgeW91ciBjb21tZW50cyBzcGVjaWZpY2FsbHkgdG8gdGhlIGRyYWZ0LCBhbmQgaWYg eW91IGhhdmUgZ290IGFueQ0KPiB0ZWNobmljYWwgb2JqZWN0aW9uLCB3b3VsZCBiZSBoYXBweSB0 byBhZGRyZXNzIHRoZW0uDQo+IA0KPiBUaGFua3MhDQo+IA0KPiBDaGVlcnMsDQo+IEplZmYNCj4g DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFh1eGlhb2h1IDx4dXhpYW9o dUBodWF3ZWkuY29tPg0KPiBEYXRlOiBUaHVyc2RheSwgRGVjZW1iZXIgMjEsIDIwMTcgYXQgMTY6 NDINCj4gVG86IEplZmYgVGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPiwgIkxlcyBH aW5zYmVyZyAoZ2luc2JlcmcpIg0KPiA8Z2luc2JlcmdAY2lzY28uY29tPiwgIktldGFuIFRhbGF1 bGlrYXIgKGtldGFudCkiIDxrZXRhbnRAY2lzY28uY29tPiwNCj4gQ2hyaXN0aWFuIEhvcHBzIDxj aG9wcHNAY2hvcHBzLm9yZz4sICJpc2lzLXdnQGlldGYub3JnIiA8aXNpcy13Z0BpZXRmLm9yZz4N Cj4gQ2M6ICJpc2lzLWFkc0BpZXRmLm9yZyIgPGlzaXMtYWRzQGlldGYub3JnPiwNCj4gImRyYWZ0 LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctbXNkQGlldGYub3JnIg0KPiA8ZHJhZnQtaWV0Zi1p c2lzLXNlZ21lbnQtcm91dGluZy1tc2RAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IOetlOWkjTog562U 5aSNOiBbSXNpcy13Z10gV0cgTGFzdCBDYWxsIGZvcg0KPiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVu dC1yb3V0aW5nLW1zZC0wNw0KPiANCj4gICAgIEplZmYsDQo+IA0KPiAgICAgSU1ITywgdGhlIE1T RCBvciB0aGUgTVNEKHR5cGUgMSkganVzdCBpbmRpY2F0ZXMgYSBjZXJ0YWluIGxhYmVsIGltcG9z aXRpb24NCj4gY2FwYWJpbGl0eSB3aGljaCBzaG91bGQgYmUgc2lnbmFsaW5nLWFnbm9zdGljLiBN b3JlIHNwZWNpYWxseSwgdGhlIE1TRCBvcg0KPiBNU0QodHlwZTEpIGNhcGFiaWxpdHkgY291bGQg YmUgc2lnbmFsZWQgdmlhIElHUCwgQkdQIG9yIFBDRVAuDQo+IA0KPiAgICAgSWYgdGhlIHNlbWFu dGljIG9mIE1TRCAodHlwZSAxKSBhcyBkZWZpbmVkIGluIHlvdXIgSUdQLU1TRCBkcmFmdCBlcXVh bHMgdGhlDQo+IHNlbWFudGljcyBvZiBNU0QgYXMgZGVmaW5lZCBpbiBQQ0VQLVNSIGRyYWZ0LCBJ IGJlbGlldmUgaXQnZCBiZXR0ZXIgdG8gaXJvbiBvdXQNCj4gc3VjaCB0ZXJtaW5vbG9neSBpbmNv bnNpc3RlbmN5IEFTQVAuDQo+IA0KPiAgICAgQmVzdCByZWdhcmRzLA0KPiAgICAgWGlhb2h1DQo+ IA0KPiAgICAgPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ICAgICA+IOWPkeS7tuS6ujogSmVm ZiBUYW50c3VyYSBbbWFpbHRvOmplZmZ0YW50LmlldGZAZ21haWwuY29tXQ0KPiAgICAgPiDlj5Hp gIHml7bpl7Q6IDIwMTflubQxMuaciDIy5pelIDU6MjINCj4gICAgID4g5pS25Lu25Lq6OiBYdXhp YW9odTsgTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCk7 DQo+IENocmlzdGlhbg0KPiAgICAgPiBIb3BwczsgaXNpcy13Z0BpZXRmLm9yZw0KPiAgICAgPiDm ioTpgIE6IGlzaXMtYWRzQGlldGYub3JnOyBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5n LW1zZEBpZXRmLm9yZw0KPiAgICAgPiDkuLvpopg6IFJlOiDnrZTlpI06IFtJc2lzLXdnXSBXRyBM YXN0IENhbGwgZm9yDQo+IGRyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctbXNkLTA3DQo+ ICAgICA+DQo+ICAgICA+IFh1eGlhb2h1LA0KPiAgICAgPg0KPiAgICAgPiBUbyBjbGFyaWZ5Og0K PiAgICAgPiBUaGUgY29uY2VwdCBoYWQgYmVlbiBkZXZlbG9wZWQgaW4gYm90aCwgaW4gcGFyYWxs ZWwsIGhvd2V2ZXIgUENFUA0KPiAgICAgPiBpbXBsZW1lbnRhdGlvbiBpcyBsaW1pdGVkIChub2Rl IG9ubHksIFBDQyBpbiBxdWVzdGlvbiBoYXMgdG8gaGF2ZSBQQ0VQDQo+IHNlc3Npb25zDQo+ICAg ICA+IHdpdGggdGhlIFBDRSksIGFuZCB0aGlzIGlzIGNsZWFybHkgc3RhdGVkIGluIHRoZSBkcmFm dCDigJMgaWYgTVNEIGlzIGtub3duDQo+IGZyb20gYm90aA0KPiAgICAgPiBzb3VyY2VzIChQQ0VQ IGFuZCBJR1AvQkdQLUxTKSB0aGUgbGF0ZXIgdGFrZXMgcHJlY2VkZW5jZS4gSUdQIGRyYWZ0cyBh cmUNCj4gdGhlDQo+ICAgICA+IHNvdXJjZSBvZiB0cnV0aCB3aGVuIGl0IGNvbWVzIHRvIHNlbWFu dGljcyBkZWZpbml0aW9ucy4NCj4gDQo+IA0KPiANCj4gICAgID4gUGVyc29uYWxseSwgSSBkb27i gJl0IHNlZSBhbnkgY29uZnVzaW9uIHdydCBuYW1lLCBhbGwgZHJhZnRzIGhhdmUgYmVlbg0KPiBh cm91bmQgZm9yDQo+ICAgICA+IHF1aXRlIHNvbWUgdGltZSwgcmV2aWV3ZWQgYnkgbWFueSBwZW9w bGUsIHByZXNlbnRlZCBpbiBhY2FkZW1pYSBhbmQNCj4gICAgID4gbmV0d29ya2luZyBldmVudHMs IG5vb25lIHdhcyBldmVyIGNvbmZ1c2Vk4oCmDQo+ICAgICA+DQo+ICAgICA+IEnigJltIG5vdCBz dXJlIGFib3V0IHZhbHVlIG9mIHlvdXIgcHJvcG9zYWwgZWl0aGVyLCBhbmQgSeKAmWQgbGVhdmUg dGhlDQo+IGRlY2lzaW9uDQo+ICAgICA+IHdoYXQgdG8gdXNlIHRvIHBlb3BsZSB3aG8gYXJlIHRo ZSBjb25zdW1lcnMgb2YgdGhlIHRlY2hub2xvZ3ksIHRob3NlDQo+IHdobyBhcmUNCj4gICAgID4g Z29pbmcgdG8gaW1wbGVtZW50IGl0IChhdCBsZWFzdCAzIE1TRCBpbXBsZW1lbnRhdGlvbnMgYXJl IG9uIHRoZWlyDQo+IHdheXMpLg0KPiAgICAgPg0KPiAgICAgPiBBcyB0aGUgbGFzdCBwb2ludCDi gJMgd2UgYXJlIG5vdCDigJxjb25zaWRlcmluZ+KAnSBleHBhbmRpbmcsIHRoZSBkcmFmdCBpcyBj bGVhcg0KPiBhYm91dA0KPiAgICAgPiB0aGUgZnV0dXJlIGV4dGVuc2lvbnMgdG8gY29tZSBhbmQg ZW5jb2RpbmcgaXMgZG9uZSBpbiBhIHdheSB0byBmYWNpbGl0YXRlDQo+IHN1Y2gNCj4gICAgID4g ZXh0ZW5zaW9ucy4NCj4gICAgID4gVGhpcyBpcyB0aGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwg Zm9yIHRoZSBkcmFmdCwgbm90IGEgZGlzY3Vzc2lvbiB3aGV0aGVyDQo+IHdlDQo+ICAgICA+IHNo b3VsZCBwcm9jZWVkIHdpdGggdGhlIHRlY2hub2xvZ3k6DQo+ICAgICA+IElmIHlvdSBzZWUgYW55 IHRlY2huaWNhbCBwcm9ibGVtcyB3aXRoIHRoZSBzb2x1dGlvbiBwcm9wb3NlZCDigJMgSeKAmWQg YmUNCj4gdGhlIGZpcnN0DQo+ICAgICA+IHRvIGxpc3RlbiB0byB5b3UgYW5kIGFkZHJlc3MgdGhl bSENCj4gICAgID4NCj4gICAgID4gSGFwcHkgaG9saWRheXMhDQo+ICAgICA+DQo+ICAgICA+IENo ZWVycywNCj4gICAgID4gSmVmZg0KPiAgICAgPg0KPiAgICAgPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiAgICAgPiBGcm9tOiBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4NCj4g ICAgID4gRGF0ZTogV2VkbmVzZGF5LCBEZWNlbWJlciAyMCwgMjAxNyBhdCAxODo0MA0KPiAgICAg PiBUbzogIkxlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIiA8Z2luc2JlcmdAY2lzY28uY29tPiwgIktl dGFuIFRhbGF1bGlrYXINCj4gKGtldGFudCkiDQo+ICAgICA+IDxrZXRhbnRAY2lzY28uY29tPiwg Q2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBzLm9yZz4sDQo+ICJpc2lzLXdnQGlldGYub3Jn Ig0KPiAgICAgPiA8aXNpcy13Z0BpZXRmLm9yZz4NCj4gICAgID4gQ2M6ICJpc2lzLWFkc0BpZXRm Lm9yZyIgPGlzaXMtYWRzQGlldGYub3JnPiwNCj4gICAgID4gImRyYWZ0LWlldGYtaXNpcy1zZWdt ZW50LXJvdXRpbmctbXNkQGlldGYub3JnIg0KPiAgICAgPiA8ZHJhZnQtaWV0Zi1pc2lzLXNlZ21l bnQtcm91dGluZy1tc2RAaWV0Zi5vcmc+DQo+ICAgICA+IFN1YmplY3Q6IOetlOWkjTogW0lzaXMt d2ddIFdHIExhc3QgQ2FsbCBmb3INCj4gZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1t c2QtMDcNCj4gICAgID4gUmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPg0KPiAg ICAgPiBSZXNlbnQtVG86IDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4sIDx1bWEuY2h1bmR1cmlA aHVhd2VpLmNvbT4sDQo+ICAgICA+IDxhbGRyaW4uaWV0ZkBnbWFpbC5jb20+LCA8Z2luc2JlcmdA Y2lzY28uY29tPg0KPiAgICAgPiBSZXNlbnQtRGF0ZTogV2VkLCAyMCBEZWMgMjAxNyAxODo0MDox NiAtMDgwMCAoUFNUKQ0KPiAgICAgPg0KPiAgICAgPiAgICAgSGkgTGVzLA0KPiAgICAgPg0KPiAg ICAgPiAgICAgSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgdGhlIE1TRCBjb25jZXB0IHdh cyBvcmlnaW5hdGVkIGZyb20NCj4gICAgID4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXBjZS1zZWdtZW50LXJvdXRpbmctMTEjcGFnZS03KSBhcw0KPiAgICAgPiBkZXNj cmliZWQgYmVsb3c6DQo+ICAgICA+DQo+ICAgICA+ICAgICAiVGhlICJNYXhpbXVtIFNJRCBEZXB0 aCIgKDENCj4gICAgID4gICAgICAgIG9jdGV0KSBmaWVsZCAoTVNEKSBzcGVjaWZpZXMgdGhlIG1h eGltdW0gbnVtYmVyIG9mIFNJRHMgKE1QTFMNCj4gbGFiZWwNCj4gICAgID4gICAgICAgIHN0YWNr IGRlcHRoIGluIHRoZSBjb250ZXh0IG9mIHRoaXMgZG9jdW1lbnQpIHRoYXQgYSBQQ0MgaXMNCj4g Y2FwYWJsZSBvZg0KPiAgICAgPiAgICAgICAgaW1wb3Npbmcgb24gYSBwYWNrZXQuIg0KPiAgICAg Pg0KPiAgICAgPiAgICAgQmVmb3JlIGNvbnNpZGVyaW5nIGV4cGFuZGluZyB0aGUgc2VtYW50aWNz IG9mIHRoZSBNU0QgY29uY2VwdCBhcw0KPiBkZWZpbmVkDQo+ICAgICA+IGluIHRoZSBhYm92ZSBQ Q0UtU1IgZHJhZnQsIGhvdyBhYm91dCBmaXJzdCBjb25zaWRlcmluZyByZW5hbWluZyB0aGUNCj4g Y2FwYWJpbGl0eQ0KPiAgICAgPiBvZiBpbXBvc2luZyB0aGUgbWF4aW11bSBudW1iZXIgb2YgbGFi ZWxzIHNvIGFzIHRvIGVsaW1pbmF0ZSBwb3NzaWJsZQ0KPiAgICAgPiBjb25mdXNpb25zLCBlLmcu LCBXcml0YWJsZSBMYWJlbC1zdGFjayBEZXB0aCAoV0xEKSBhcyBvcHBvc2VkIHRvIHRoZQ0KPiBS ZWFkYWJsZQ0KPiAgICAgPiBMYWJlbC1zdGFjayBEZXB0aCAoUkxEKSBhcyBkZWZpbmVkIGluDQo+ ICAgICA+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vc3BmLW1wbHMt ZWxjKSBhbmQNCj4gICAgID4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWlzaXMtbXBscy1lbGMpID8NCj4gICAgID4NCj4gICAgID4gICAgIEJlc3QgcmVnYXJkcywNCj4g ICAgID4gICAgIFhpYW9odQ0KPiAgICAgPg0KPiAgICAgPiAgICAgPiAtLS0tLemCruS7tuWOn+S7 ti0tLS0tDQo+ICAgICA+ICAgICA+IOWPkeS7tuS6ujogSXNpcy13ZyBbbWFpbHRvOmlzaXMtd2ct Ym91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIExlcw0KPiBHaW5zYmVyZw0KPiAgICAgPiAoZ2luc2Jl cmcpDQo+ICAgICA+ICAgICA+IOWPkemAgeaXtumXtDogMjAxN+W5tDEy5pyIMjHml6UgNDowMg0K PiAgICAgPiAgICAgPiDmlLbku7bkuro6IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCk7IENocmlz dGlhbiBIb3BwczsNCj4gaXNpcy13Z0BpZXRmLm9yZw0KPiAgICAgPiAgICAgPiDmioTpgIE6IGlz aXMtYWRzQGlldGYub3JnOw0KPiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZEBp ZXRmLm9yZw0KPiAgICAgPiAgICAgPiDkuLvpopg6IFJlOiBbSXNpcy13Z10gV0cgTGFzdCBDYWxs IGZvcg0KPiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZC0wNw0KPiAgICAgPiAg ICAgPg0KPiAgICAgPiAgICAgPiBLZXRhbiAtDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+ IFRoYW54IGZvciB0aGUgY29tbWVudHMuDQo+ICAgICA+ICAgICA+IEkgdGhpbmsgd2UgZG8gd2Fu dCB0byBhbGxvdyBNU0Qgc3VwcG9ydCBmb3IgdmFsdWVzIG90aGVyIHRoYW4NCj4gaW1wb3NpdGlv bg0KPiAgICAgPiAgICAgPiB2YWx1ZXMuIFdlIHdpbGwgcmV2aXNlIHRoZSB0ZXh0IHNvIHdlIGFy ZSBub3QgcmVzdHJpY3RlZCB0byBvbmx5DQo+IGltcG9zaXRpb24NCj4gICAgID4gY2FzZXMuDQo+ ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+ICAgTGVzDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ ICAgICA+DQo+ICAgICA+ICAgICA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gICAg ID4gICAgID4gPiBGcm9tOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpDQo+ICAgICA+ICAgICA+ ID4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAyMCwgMjAxNyAxOjUxIEFNDQo+ICAgICA+ICAg ICA+ID4gVG86IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBpc2lzLXdnQGll dGYub3JnDQo+ICAgICA+ICAgICA+ID4gQ2M6IGlzaXMtYWRzQGlldGYub3JnOw0KPiBkcmFmdC1p ZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZEBpZXRmLm9yZw0KPiAgICAgPiAgICAgPiA+IFN1 YmplY3Q6IFJFOiBbSXNpcy13Z10gV0cgTGFzdCBDYWxsIGZvcg0KPiAgICAgPiAgICAgPiA+IGRy YWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctbXNkLTA3DQo+ICAgICA+ICAgICA+ID4NCj4g ICAgID4gICAgID4gPiBIZWxsbywNCj4gICAgID4gICAgID4gPg0KPiAgICAgPiAgICAgPiA+IEkg c3VwcG9ydCB0aGlzIGRvY3VtZW50IGFuZCB3b3VsZCBsaWtlIHRvIGFzayB0aGUgYXV0aG9ycyBh bmQNCj4gV0cgdG8NCj4gICAgID4gICAgID4gPiBjb25zaWRlciBpZiB3ZSBjYW4gZXhwYW5kIHRo ZSBzY29wZSBvZiB0aGlzIGRyYWZ0IHRvIG5vdCBqdXN0DQo+ICAgICA+ICAgICA+ID4gImltcG9z aXRpb24iIG9mIHRoZSBTSUQgc3RhY2sgYnV0IGFsc28gb3RoZXIgc2ltaWxhciBsaW1pdHMgcmVs YXRlZA0KPiB0bw0KPiAgICAgPiBvdGhlcg0KPiAgICAgPiAgICAgPiBhY3Rpb25zIChlLmcuDQo+ ICAgICA+ICAgICA+ID4gcmVhZGluZywgcHJvY2Vzc2luZywgZXRjLikuIFdpdGggU2VnbWVudCBS b3V0aW5nLCB3ZSBhcmUgY29taW5nDQo+IGFjcm9zcw0KPiAgICAgPiAgICAgPiA+IHZhcmlvdXMg YWN0aW9ucyB0aGF0IG5vZGVzIG5lZWQgdG8gZG8gd2l0aCB0aGUgU0lEIHN0YWNrIGZvcg0KPiBk aWZmZXJlbnQNCj4gICAgID4gICAgID4gPiBwdXJwb3NlcyBhbmQgSU1ITyBpdCB3b3VsZCBiZSB1 c2VmdWwgdG8gZXh0ZW5kIHRoZSBNU0QgYWJpbGl0eQ0KPiB0bw0KPiAgICAgPiAgICAgPiA+IGNv dmVyIHRob3NlIGFzIHRoZXkgYXJpc2UuDQo+ICAgICA+ICAgICA+ID4NCj4gICAgID4gICAgID4g PiBUaGFua3MsDQo+ICAgICA+ICAgICA+ID4gS2V0YW4NCj4gICAgID4gICAgID4gPg0KPiAgICAg PiAgICAgPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICA+ICAgICA+ID4gRnJv bTogSXNpcy13ZyBbbWFpbHRvOmlzaXMtd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m DQo+IENocmlzdGlhbg0KPiAgICAgPiAgICAgPiA+IEhvcHBzDQo+ICAgICA+ICAgICA+ID4gU2Vu dDogMjAgRGVjZW1iZXIgMjAxNyAxNDowMw0KPiAgICAgPiAgICAgPiA+IFRvOiBpc2lzLXdnQGll dGYub3JnDQo+ICAgICA+ICAgICA+ID4gQ2M6IGlzaXMtYWRzQGlldGYub3JnOw0KPiBkcmFmdC1p ZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZEBpZXRmLm9yZw0KPiAgICAgPiAgICAgPiA+IFN1 YmplY3Q6IFtJc2lzLXdnXSBXRyBMYXN0IENhbGwgZm9yDQo+ICAgICA+ICAgICA+ID4gZHJhZnQt aWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1tc2QtMDcNCj4gICAgID4gICAgID4gPg0KPiAgICAg PiAgICAgPiA+DQo+ICAgICA+ICAgICA+ID4gVGhlIGF1dGhvcnMgaGF2ZSBhc2tlZCBmb3IgYW5k IHdlIGFyZSBzdGFydGluZyBhIFdHIExhc3QgQ2FsbCBvbg0KPiAgICAgPiAgICAgPiA+DQo+ICAg ICA+ICAgICA+ID4NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1tc2QvDQo+ICAgICA+ICAgICA+ID4NCj4gICAgID4gICAg ID4gPiB3aGljaCB3aWxsIGxhc3QgYW4gZXh0ZW5kZWQgNCB3ZWVrcyB0byBhbGxvdyBmb3IgeWVh ci1lbmQgUFRPDQo+IHBhdHRlcm5zLg0KPiAgICAgPiAgICAgPiA+DQo+ICAgICA+ICAgICA+ID4g QW4gSVBSIHN0YXRlbWVudCBleGlzdHM6DQo+ICAgICA+ICAgICA+ID4NCj4gICAgID4gICAgID4g Pg0KPiAgICAgPiAgICAgPiA+DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByL3Nl YXJjaC8/c3VibWl0PWRyYWZ0JmlkPWRyYWZ0LWlldGYtaXMNCj4gICAgID4gICAgID4gPiBpcy0N Cj4gICAgID4gICAgID4gPiBzZWdtZW50LXJvdXRpbmctbXNkDQo+ICAgICA+ICAgICA+ID4NCj4g ICAgID4gICAgID4gPiBBdXRob3JzIHBsZWFzZSByZXBseSB0byB0aGUgbGlzdCBpbmRpY2F0aW5n IHdoZXRoZXIgeW91IGFyZSBhd2FyZQ0KPiBvZg0KPiAgICAgPiAgICAgPiA+IGFueQ0KPiAgICAg PiAgICAgPiA+ICpuZXcqIElQUi4NCj4gICAgID4gICAgID4gPg0KPiAgICAgPiAgICAgPiA+IFRo YW5rcywNCj4gICAgID4gICAgID4gPiBDaHJpcy4NCj4gICAgID4gICAgID4gPg0KPiAgICAgPiAg ICAgPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ICAgICA+ICAgICA+ID4gSXNpcy13ZyBtYWlsaW5nIGxpc3QNCj4gICAgID4gICAgID4gPiBJc2lz LXdnQGlldGYub3JnDQo+ICAgICA+ICAgICA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pc2lzLXdnDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICA+ICAgICA+IElz aXMtd2cgbWFpbGluZyBsaXN0DQo+ICAgICA+ICAgICA+IElzaXMtd2dAaWV0Zi5vcmcNCj4gICAg ID4gICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pc2lzLXdnDQo+ ICAgICA+DQo+ICAgICA+DQo+IA0KPiANCj4gDQoNCg== From nobody Sat Dec 23 00:41:06 2017 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 89732127201; Sat, 23 Dec 2017 00:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 ynwJZyxydsc0; Sat, 23 Dec 2017 00:40:42 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 3F3B71201F8; Sat, 23 Dec 2017 00:40:42 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 010B85A08DDE3; Sat, 23 Dec 2017 08:40:39 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 23 Dec 2017 08:40:39 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.57]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Sat, 23 Dec 2017 16:40:32 +0800 From: Xuxiaohu To: "idr@ietf.org" CC: "ospf@ietf.org" , "isis-wg@ietf.org" , "spring@ietf.org" Thread-Topic: A comment regarding the relationship between RLD and ERLD Thread-Index: AQHTe8mxXY34rgOrrk2zXgV1aEAl0Q== Date: Sat, 23 Dec 2017 08:40:32 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7A3E@NKGEML515-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [OSPF] A comment regarding the relationship between RLD and ERLD X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 23 Dec 2017 08:40:46 -0000 SGkgYWxsLA0KDQpJIGp1c3QgcmVhZCB0aGUgZHJhZnQgKGRyYWZ0LWlldGYtaWRyLWJncC1scy1z ZWdtZW50LXJvdXRpbmctcmxkKSBkdWUgdG8gdGhlIGN1cmlvc2l0eSBvZiB0aGUgRVJMRCB0ZXJt aW5vbG9neS4gSSBoYXZlIHRob3VnaHQgdGhhdCB0aGlzIGRyYWZ0IGlzIGp1c3QgYWJvdXQgYSBz dHJhaWdodGZvcndhcmQgQkdQLUxTIGV4dGVuc2lvbiBmb3IgdGhlIFJMRCBjb25jZXB0IGFzIGRl ZmluZWQgaW4gZHJhZnQtaWV0Zi1vc3BmLW1wbHMtZWxjIGFuZCBkcmFmdC1pZXRmLWlzaXMtbXBs cy1lbGMgYWNjb3JkaW5nIHRvIHRoZSBkcmFmdCBuYW1lLiBIb3dldmVyIGl0IGlzbid0IGluIGZh Y3QuIE1heWJlIHRoZSBkcmFmdCBuYW1lIHNob3VsZCBoYXZlIGJlZW4gKi1lcmxkIHJhdGhlciB0 aGFuICotcmxkLg0KDQpJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50cyBvbiB0aGlzIGRyYWZ0 IChkcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLXJsZCk6DQoNCjEpIEVSTEQg bWVhbnMgRW50cm9weSBjYXBhYmxlIFJlYWRhYmxlIExhYmVsIERlcHRoIGFzIGRlZmluZWQgaW4g dGhpcyBkcmFmdC4gSG93ZXZlciwgaXQgc2FpZCAiLi4uQSBuZXR3b3JrIG5vZGUgc2lnbmFsbGlu ZyBhbiBFUkxEIE1VU1Qgc3VwcG9ydCB0aGUgYWJpbGl0eSB0byByZWFkIHRoZSBzaWduYWxsZWQg bnVtYmVyIG9mIGxhYmVscyBiZWZvcmUgYW55IGFjdGlvbiBpcyBkb25lIHVwb24gdGhlIHBhY2tl dC4uLiIgSSdtIHdvbmRlcmluZyB3aGF0IGFjdGlvbnMgb3RoZXIgdGhhbiB0aGUgRUwtYmFzZWQg TEIgYWN0aW9uIHRoZSAiYW55IGFjdGlvbiIgY291bGQgYmUgc2luY2UgdGhlIEVSTEQgaGFzIGJl ZW4gdGlnaHRseSBjb3VwbGVkIHdpdGggdGhlIEVMLWJhc2VkIExCIG1lY2hhbmlzbS4gSW4gY29u dHJhc3QsIHRoZSBSTEQgYXMgZGVmaW5lZCBpbiB0aGUgdHdvIElHUCBkcmFmdHMgaXMgbm90IHRp Z2h0bHkgY291cGxlIHdpdGggdGhlIEVMLWJhc2VkIExCIGFjdGlvbi4gSW4gb3RoZXIgd29yZHMs IHRoZSBSTEQgY2FwYWJpbGl0eSBjb3VsZCBiZSBhcHBsaWNhYmxlIHRvIG90aGVyIHVzZSBjYXNl cyBiZXNpZGVzIHRoZSBFTC1iYXNlZCBMQi4NCg0KMikgSXQgc2FpZCAiLi4uSW4gZXhpc3Rpbmcg dGVjaG5vbG9neSBib3RoIElTSVMgWzRdIGFuZCBPU1BGIFszXSBoYXZlIHByb3Bvc2VkIGV4dGVu c2lvbnMgdG8gc2lnbmFsIHRoZSBSTEQgKFJlYWRhYmxlIExhYmVsIERlcHRoKSBhbmQgRUxDIChF bnRyb3B5IExhYmVsIENhcGFiaWxpdHkpIG9mIGEgbm9kZSBvciBsaW5rLiAiIEhvd2V2ZXIsIHRo ZXJlIGlzIG5vIGV4dGVuc2lvbnMgdG8gc2lnbmFsIHRoZSBSTEQgYW5kIEVMQyBvZiBhIGxpbmss IGlmIEkgcmVtZW1iZXJlZCBjb3JyZWN0bHkgYXMgYSBjby1hdXRob3Igb2YgdGhlIGFib3ZlIHR3 byBJR1AgZHJhZnRzOikgSW4gZmFjdCwgd2hlbiB0aGUgdHdvIElHUCBkcmFmdHMgd2VyZSBpbml0 aWFsbHkgcHJvcG9zZWQsIHNvbWUgZ3V5cyBkb2VzIGFyZ3VlIHdoeSBub3QgYWR2ZXJ0aXNlIEVM QyBhbmQgUkxEIG9mIHRoZSBwZXItbGluayBncmFudWxhcml0eSBhcyB3ZWxsLiBBZnRlciBzb21l IGRpc2N1c3Npb24gaW4gSUVURiwgYSByb3VnaCBjb25zZW5zdXMgaGFkIGJlZW4gcmVhY2hlZCB0 aGF0IHRoZSBhZHZlcnRpc2VtZW50IG9mIEVMQyBhbmQgUkxEIGF0IGEgcGVyIG5vZGUgZ3JhbnVs YXJpdHkgd2FzIGdvb2QgZW5vdWdoIGF0IHRoYXQgdGltZS4gVGhhdCdzIHRoZSByZWFzb24gd2h5 IHRoZSB0d28gSUdQIGRyYWZ0cyBoYWQgbm90IGJlZW4gZXh0ZW5kZWQgdG8gYWR2ZXJ0aXNlIEVM QyBhbmQgUkxEIGF0IGEgcGVyIGxpbmsgZ3JhbnVsYXJpdHkgdGhlcmVmb3JlLiBNYXliZSB3ZSBz aG91bGQgcmVvcGVuIHN1Y2ggZGlzY3Vzc2lvbiBub3c/DQoNCjMpIEl0IHNhaWQgIi4uLmlmIGEg bmV0d29yayBTRE4gY29udHJvbGxlciBpcyBjb25uZWN0ZWQgdG8gdGhlIG5ldHdvcmsgdGhyb3Vn aCBhIEJHUC1MUyBzZXNzaW9uIGFuZCBub3QgdGhyb3VnaCBJU0lTIG9yIE9TUEYgdGVjaG5vbG9n eSwgdGhlbiBib3RoIFJMRCBhbmQgRUxDIG5lZWRzIHRvIGJlIHNpZ25hbGVkIGluIEJHUC1MUyBh Y2NvcmRpbmdseS4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBleHRlbnNpb24gQkdQLUxT IHJlcXVpcmVzIHRvIHRyYW5zcG9ydCB0aGUgY29tYmluYXRpb24gb2YgUkxEIGFuZCBFTEMgaW50 byBhY2NvcmRpbmcgRVJMRCBhdHRyaWJ1dGVzIGZvciBub2RlcyBhbmQgbGlua3MuLi4iIEkgaGF2 ZSBub3QgeWV0IGZvdW5kIGFueSBleHBsYW5hdGlvbiBhYm91dCB0aGUgbW90aXZhdGlvbiBmb3Ig YWR2ZXJ0aXNpbmcgdGhlIGNvbWJpbmF0aW9uIG9mIFJMRCBhbmQgRUxDIGludG8gYWNjb3JkaW5n IEVSTEQgYXR0cmlidXRlcyByYXRoZXIgdGhhbiBhZHZlcnRpc2luZyB0aGVzZSB0d28gYXR0cmli dXRlcyBzZXBhcmF0ZWx5LiBXb3VsZCBpdCBiZSBiZXR0ZXIgdG8gZ2l2ZSBhbnkgZXhwbGFuYXRp b24gYWJvdXQgc3VjaCBtb3RpdmF0aW9uIGluIHRoZSBQcm9ibGVtIFN0YXRlbWVudCBzZWN0aW9u Pw0KDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3 orz+yMs6IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgW21haWx0bzprZXRhbnRAY2lzY28uY29t XQ0KPiC3osvNyrG85DogMjAxN8TqMTLUwjIxyNUgMTI6MTYNCj4gytW8/sjLOiBYdXhpYW9odTsg TGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IENocmlzdGlhbiBIb3BwczsgaXNpcy13Z0BpZXRmLm9y Zw0KPiCzrcvNOiBpc2lzLWFkc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91 dGluZy1tc2RAaWV0Zi5vcmcNCj4g1vfM4jogUkU6IFtJc2lzLXdnXSBXRyBMYXN0IENhbGwgZm9y IGRyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctbXNkLTA3DQo+IA0KPiBIaSBYdSwNCj4g DQo+IEkgYW0gYXJndWluZyB0aGUgZXhhY3Qgb3Bwb3NpdGUgb2Ygd2hhdCB5b3UgYXJlIHNheWlu Zy4NCj4gDQo+IExldCB1cyBsZWF2ZSBFTEMvRVJMRCBhc2lkZSBzaW5jZSBpdCBpcyB2ZXJ5IGxp bWl0ZWQgdG8gZW50cm9weSBsYWJlbCB1c2UtY2FzZSBhbmQNCj4gdGhlIHByb3Bvc2VkIElHUC9C R1AtTFMgZW5jb2RpbmcgaXMgdmVyeSBzcGVjaWZpYyB0byB0aGF0LiBJIGFtIG5vdCBzdXJlIGlm IHRoaXMgaXMNCj4gdGhlIHRpbWUgYW55bW9yZSB0byByZXZpc2l0IHRoYXQuDQo+IA0KPiBUaGUg TVNEIHByb3Bvc2FsIGNhbWUgbGF0ZXIgYW5kIEkgc3VwcG9ydCBpcyBzaW5jZSBJJ3ZlIGZvdW5k IGl0cyB1c2UgdG8gYmUNCj4gbXVjaCBtb3JlIHdpZGVzcHJlYWQgYW5kIHRoZSBwcm9wb3NlZCBJ R1AvQkdQLUxTIHByb3RvY29sIGVuY29kaW5nIHRvIGJlDQo+IHZlcnkgZWZmaWNpZW50IGFzIGFu IGltcGxlbWVudGVyIG9mIHRoZXNlIHByb3RvY29scy4gSGVuY2UgdGhlIHJlcXVlc3QgdG8gbm90 DQo+IHJlc3RyaWN0IGl0IHRvICJ3cml0YWJsZSIgb3IgImltcG9zaXRpb24iIGNhc2VzIHNvbGVs eS4gSXQgaXMgYWxzbyBub3QganVzdCBhYm91dA0KPiAicmVhZGFiaWxpdHkiIC0gd2hpY2ggYnkg aXRzZWxmIGlzIHByZXR0eSBtZWFuaW5nbGVzcy4gRXZlbiBFUkxEIGlzIGFib3V0DQo+ICJyZWFk aW5nIiBhbmQgdGhlbiAiZG9pbmcgKnNvbWV0aGluZyBzcGVjaWZpYyogYWJvdXQgaXQiIGFzIGRp c2N1c3NlZCBpbg0KPiBpZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy4NCj4gDQo+IFRo ZXJlIGlzIG5vIHNlY29uZCB0aG91Z2h0cyBhYm91dCB0aGUgSUdQIEVMQyBkcmFmdHMgYW5kIHRo ZXkgYXJlIHZlcnkgdXNlZnVsDQo+IGFuZCBuZWNlc3NhcnkuIEp1c3QgdG8gYmUgY2xlYXIgdGhl cmUgaXMgKm5vIGZ1bmN0aW9uYWwgb3Igb3BlcmF0aW9uYWwgY2hhbmdlKg0KPiB0aGF0IEkgYW0g YXJndWluZyBmb3IgaGVyZS4gVGhlIGRpc2N1c3Npb24gaXMgcHVyZWx5IG9uIHRoZSB3YXkgdG8g aGFuZGxlIHRoZXNlDQo+IGVuY29kaW5ncyBhbmQgd2hldGhlciB3ZSBjYW4gdXNlIHRoZSBNU0Qg bWVjaGFuaXNtIGluIGEgZ2VuZXJhbGl6ZWQNCj4gbWFubmVyLg0KPiANCj4gVGhhbmtzLA0KPiBL ZXRhbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWHV4aWFvaHUg W21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiBTZW50OiAyMSBEZWNlbWJlciAyMDE3IDA4 OjEwDQo+IFRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPjsg S2V0YW4gVGFsYXVsaWthciAoa2V0YW50KQ0KPiA8a2V0YW50QGNpc2NvLmNvbT47IENocmlzdGlh biBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBpc2lzLXdnQGlldGYub3JnDQo+IENjOiBpc2lz LWFkc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1tc2RAaWV0Zi5v cmcNCj4gU3ViamVjdDogtPC4tDogW0lzaXMtd2ddIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0 Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1tc2QtMDcNCj4gDQo+IEhpIExlcywNCj4gDQo+IElmIEkg dW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHRoZSBNU0QgY29uY2VwdCB3YXMgb3JpZ2luYXRlZCBm cm9tDQo+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wY2Utc2VnbWVu dC1yb3V0aW5nLTExI3BhZ2UtNykgYXMNCj4gZGVzY3JpYmVkIGJlbG93Og0KPiANCj4gIlRoZSAi TWF4aW11bSBTSUQgRGVwdGgiICgxDQo+ICAgIG9jdGV0KSBmaWVsZCAoTVNEKSBzcGVjaWZpZXMg dGhlIG1heGltdW0gbnVtYmVyIG9mIFNJRHMgKE1QTFMgbGFiZWwNCj4gICAgc3RhY2sgZGVwdGgg aW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1bWVudCkgdGhhdCBhIFBDQyBpcyBjYXBhYmxlIG9m DQo+ICAgIGltcG9zaW5nIG9uIGEgcGFja2V0LiINCj4gDQo+IEJlZm9yZSBjb25zaWRlcmluZyBl eHBhbmRpbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgTVNEIGNvbmNlcHQgYXMgZGVmaW5lZCBpbg0K PiB0aGUgYWJvdmUgUENFLVNSIGRyYWZ0LCBob3cgYWJvdXQgZmlyc3QgY29uc2lkZXJpbmcgcmVu YW1pbmcgdGhlIGNhcGFiaWxpdHkgb2YNCj4gaW1wb3NpbmcgdGhlIG1heGltdW0gbnVtYmVyIG9m IGxhYmVscyBzbyBhcyB0byBlbGltaW5hdGUgcG9zc2libGUgY29uZnVzaW9ucywNCj4gZS5nLiwg V3JpdGFibGUgTGFiZWwtc3RhY2sgRGVwdGggKFdMRCkgYXMgb3Bwb3NlZCB0byB0aGUgUmVhZGFi bGUgTGFiZWwtc3RhY2sNCj4gRGVwdGggKFJMRCkgYXMgZGVmaW5lZCBpbiAoaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3NwZi1tcGxzLWVsYykNCj4gYW5kIChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pc2lzLW1wbHMtZWxjKSA/DQo+IA0KPiBC ZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiC3 orz+yMs6IElzaXMtd2cgW21haWx0bzppc2lzLXdnLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTGVz IEdpbnNiZXJnDQo+ID4gKGdpbnNiZXJnKQ0KPiA+ILeiy83KsbzkOiAyMDE3xOoxMtTCMjHI1SA0 OjAyDQo+ID4gytW8/sjLOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpOyBDaHJpc3RpYW4gSG9w cHM7IGlzaXMtd2dAaWV0Zi5vcmcNCj4gPiCzrcvNOiBpc2lzLWFkc0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1tc2RAaWV0Zi5vcmcNCj4gPiDW98ziOiBSZTogW0lz aXMtd2ddIFdHIExhc3QgQ2FsbCBmb3INCj4gPiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0 aW5nLW1zZC0wNw0KPiA+DQo+ID4gS2V0YW4gLQ0KPiA+DQo+ID4gVGhhbnggZm9yIHRoZSBjb21t ZW50cy4NCj4gPiBJIHRoaW5rIHdlIGRvIHdhbnQgdG8gYWxsb3cgTVNEIHN1cHBvcnQgZm9yIHZh bHVlcyBvdGhlciB0aGFuDQo+ID4gaW1wb3NpdGlvbiB2YWx1ZXMuIFdlIHdpbGwgcmV2aXNlIHRo ZSB0ZXh0IHNvIHdlIGFyZSBub3QgcmVzdHJpY3RlZCB0byBvbmx5DQo+IGltcG9zaXRpb24gY2Fz ZXMuDQo+ID4NCj4gPiAgIExlcw0KPiA+DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPiBGcm9tOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpDQo+ID4gPiBTZW50 OiBXZWRuZXNkYXksIERlY2VtYmVyIDIwLCAyMDE3IDE6NTEgQU0NCj4gPiA+IFRvOiBDaHJpc3Rp YW4gSG9wcHMgPGNob3Bwc0BjaG9wcHMub3JnPjsgaXNpcy13Z0BpZXRmLm9yZw0KPiA+ID4gQ2M6 IGlzaXMtYWRzQGlldGYub3JnOyBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZEBp ZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUkU6IFtJc2lzLXdnXSBXRyBMYXN0IENhbGwgZm9yDQo+ ID4gPiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZC0wNw0KPiA+ID4NCj4gPiA+ IEhlbGxvLA0KPiA+ID4NCj4gPiA+IEkgc3VwcG9ydCB0aGlzIGRvY3VtZW50IGFuZCB3b3VsZCBs aWtlIHRvIGFzayB0aGUgYXV0aG9ycyBhbmQgV0cgdG8NCj4gPiA+IGNvbnNpZGVyIGlmIHdlIGNh biBleHBhbmQgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQgdG8gbm90IGp1c3QNCj4gPiA+ICJpbXBv c2l0aW9uIiBvZiB0aGUgU0lEIHN0YWNrIGJ1dCBhbHNvIG90aGVyIHNpbWlsYXIgbGltaXRzIHJl bGF0ZWQNCj4gPiA+IHRvIG90aGVyDQo+ID4gYWN0aW9ucyAoZS5nLg0KPiA+ID4gcmVhZGluZywg cHJvY2Vzc2luZywgZXRjLikuIFdpdGggU2VnbWVudCBSb3V0aW5nLCB3ZSBhcmUgY29taW5nDQo+ ID4gPiBhY3Jvc3MgdmFyaW91cyBhY3Rpb25zIHRoYXQgbm9kZXMgbmVlZCB0byBkbyB3aXRoIHRo ZSBTSUQgc3RhY2sgZm9yDQo+ID4gPiBkaWZmZXJlbnQgcHVycG9zZXMgYW5kIElNSE8gaXQgd291 bGQgYmUgdXNlZnVsIHRvIGV4dGVuZCB0aGUgTVNEDQo+ID4gPiBhYmlsaXR5IHRvIGNvdmVyIHRo b3NlIGFzIHRoZXkgYXJpc2UuDQo+ID4gPg0KPiA+ID4gVGhhbmtzLA0KPiA+ID4gS2V0YW4NCj4g PiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogSXNpcy13 ZyBbbWFpbHRvOmlzaXMtd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4gPiBD aHJpc3RpYW4gSG9wcHMNCj4gPiA+IFNlbnQ6IDIwIERlY2VtYmVyIDIwMTcgMTQ6MDMNCj4gPiA+ IFRvOiBpc2lzLXdnQGlldGYub3JnDQo+ID4gPiBDYzogaXNpcy1hZHNAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctbXNkQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBb SXNpcy13Z10gV0cgTGFzdCBDYWxsIGZvcg0KPiA+ID4gZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQt cm91dGluZy1tc2QtMDcNCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlIGF1dGhvcnMgaGF2ZSBhc2tl ZCBmb3IgYW5kIHdlIGFyZSBzdGFydGluZyBhIFdHIExhc3QgQ2FsbCBvbg0KPiA+ID4NCj4gPiA+ DQo+ID4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlzaXMt c2VnbWVudC1yb3V0aW5nLW1zZA0KPiA+ID4gLw0KPiA+ID4NCj4gPiA+IHdoaWNoIHdpbGwgbGFz dCBhbiBleHRlbmRlZCA0IHdlZWtzIHRvIGFsbG93IGZvciB5ZWFyLWVuZCBQVE8gcGF0dGVybnMu DQo+ID4gPg0KPiA+ID4gQW4gSVBSIHN0YXRlbWVudCBleGlzdHM6DQo+ID4gPg0KPiA+ID4NCj4g PiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/c3VibWl0PWRyYWZ0 JmlkPWRyYWZ0LWlldGYtDQo+ID4gPiBpcw0KPiA+ID4gaXMtDQo+ID4gPiBzZWdtZW50LXJvdXRp bmctbXNkDQo+ID4gPg0KPiA+ID4gQXV0aG9ycyBwbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3QgaW5k aWNhdGluZyB3aGV0aGVyIHlvdSBhcmUgYXdhcmUgb2YNCj4gPiA+IGFueQ0KPiA+ID4gKm5ldyog SVBSLg0KPiA+ID4NCj4gPiA+IFRoYW5rcywNCj4gPiA+IENocmlzLg0KPiA+ID4NCj4gPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBJc2lz LXdnIG1haWxpbmcgbGlzdA0KPiA+ID4gSXNpcy13Z0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pc2lzLXdnDQo+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IElzaXMtd2cgbWFpbGlu ZyBsaXN0DQo+ID4gSXNpcy13Z0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXNpcy13Zw0K From nobody Sat Dec 23 01:25:17 2017 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 392721275C5; Sat, 23 Dec 2017 01:25:13 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 OoHdelSJzkFH; Sat, 23 Dec 2017 01:25:10 -0800 (PST) Received: from st13p11im-asmtp004.me.com (st13p11im-asmtp004.me.com [17.164.40.219]) (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 DDDA81201F8; Sat, 23 Dec 2017 01:25:09 -0800 (PST) Received: from process-dkim-sign-daemon.st13p11im-asmtp004.me.com by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P1E00C00PT4KY00@st13p11im-asmtp004.me.com>; Sat, 23 Dec 2017 09:25:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1514021109; bh=ixTaz46T1Bjyr4VS5XOL3MvGSPqo2WNulL4czEzLrKw=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=gE0q0tGrK8/Z3rL6dXeiZHviI9Xd/0LetMnd+KKwrLHYOXg3M7njTgEdI+f2iDnwW iq3uttXnh42ld6E+xXplNlohw96QRyuMi81J25jT3w4xn7jB5sGgggJxRIsonAWELF wTnhf5M1AZehxdr6nUUavz8Ojhy5gIQ+xM/H3yYH65mPG9gwR8wmtQdUl5daLze/W/ 0uLHnVdd1rr93BHEJCHqLcb6JONTWCNpsJXE8TnkXPCXS+bYY1EYcwjx176oNcEHa5 9tUr9z/KyMCBaLWRjfxm5GgtwzM3kJiRE3QZOF2mhkEQaPna4hRXZEQyEcwSSXTkIi Dmz/FyHnqKP0g== Received: from icloud.com ([127.0.0.1]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P1E00MVSQ5TQH00@st13p11im-asmtp004.me.com>; Sat, 23 Dec 2017 09:25:08 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-23_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1712230129 From: Gunter Van De Velde Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_AD9F1F8B-A08B-4C58-91FE-2EE280812CB2" MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 23 Dec 2017 10:25:05 +0100 In-reply-to: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7A3E@NKGEML515-MBS.china.huawei.com> Cc: "idr@ietf.org" , "ospf@ietf.org" , "spring@ietf.org" , "isis-wg@ietf.org" To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7A3E@NKGEML515-MBS.china.huawei.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [OSPF] [Idr] A comment regarding the relationship between RLD and ERLD X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 23 Dec 2017 09:25:13 -0000 --Apple-Mail=_AD9F1F8B-A08B-4C58-91FE-2EE280812CB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Xiaohu, Thanks for digging through the draft. See inline: GV> > On 23 Dec 2017, at 09:40, Xuxiaohu wrote: >=20 > Hi all, >=20 > I just read the draft (draft-ietf-idr-bgp-ls-segment-routing-rld) due = to the curiosity of the ERLD terminology. I have thought that this draft = is just about a straightforward BGP-LS extension for the RLD concept as = defined in draft-ietf-ospf-mpls-elc and draft-ietf-isis-mpls-elc = according to the draft name. However it isn't in fact. Maybe the draft = name should have been *-erld rather than *-rld. >=20 > I have the following comments on this draft = (draft-ietf-idr-bgp-ls-segment-routing-rld): >=20 > 1) ERLD means Entropy capable Readable Label Depth as defined in this = draft. However, it said "...A network node signalling an ERLD MUST = support the ability to read the signalled number of labels before any = action is done upon the packet..." I'm wondering what actions other than = the EL-based LB action the "any action" could be since the ERLD has been = tightly coupled with the EL-based LB mechanism. In contrast, the RLD as = defined in the two IGP drafts is not tightly couple with the EL-based LB = action. In other words, the RLD capability could be applicable to other = use cases besides the EL-based LB. >=20 GV> This is exactly what I asked during the IETF100 IDR slot when I = presented the updated work. The consensus was that signalling of a = readable label depth has entropy as the dominant use-case scenario. This = is now documented in:=20 https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = . = Consensus from IETF100 IDR meeting was that ERLD is the way forward for = BGP-LS based signalling, and that maybe this should also be the case for = both ISIS and OSPF drafts (however, that is different discussion). I = agree with IDR consensus and it seems the most pragmatic path forward. > 2) It said "...In existing technology both ISIS [4] and OSPF [3] have = proposed extensions to signal the RLD (Readable Label Depth) and ELC = (Entropy Label Capability) of a node or link. " However, there is no = extensions to signal the RLD and ELC of a link, if I remembered = correctly as a co-author of the above two IGP drafts:) In fact, when the = two IGP drafts were initially proposed, some guys does argue why not = advertise ELC and RLD of the per-link granularity as well. After some = discussion in IETF, a rough consensus had been reached that the = advertisement of ELC and RLD at a per node granularity was good enough = at that time. That's the reason why the two IGP drafts had not been = extended to advertise ELC and RLD at a per link granularity therefore. = Maybe we should reopen such discussion now? >=20 GV> I have no intend to open up that discussion at all, as it seems a = pragmatic consensus was reached. Steering seems to become more complex = when link based ERLD is proposed and a potential set of different ERLDs = are signalled due to capabilities of the line-card HW. If for = https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 we = just need node based ERLD, then I that is just fine. My personal opinion = is that we need node ERLD for node for sure in BGP-LS, and that link = ERLD is a nice to have. It seems relative easy and pragmatic to add both = Link and node ERLD in current version of the BGP-LS ERLD document. > 3) It said "...if a network SDN controller is connected to the network = through a BGP-LS session and not through ISIS or OSPF technology, then = both RLD and ELC needs to be signaled in BGP-LS accordingly. This = document describes the extension BGP-LS requires to transport the = combination of RLD and ELC into according ERLD attributes for nodes and = links..." I have not yet found any explanation about the motivation for = advertising the combination of RLD and ELC into according ERLD = attributes rather than advertising these two attributes separately. = Would it be better to give any explanation about such motivation in the = Problem Statement section? >=20 >=20 GV> Yes, indeed, again that was reason again that the work was presented = during IETF100 as I had some doubts myself. During IETF100 IDR meeting, = I learned and was confirmed that ERLD is now in the SPRING entropy label = draft and that hence ERLD is to be signalled for the most prominent = use-case driving readable label depth signalling https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = . I = see no reason to open that discussion again, and current BGP-LS ERLD = draft is inline the most dominant use-case scenario (Entropy based = load-balancing). I could change the existing text to refer to = https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = = and only mention ERLD (and no longer mention ELC/RLD at all) if IDR WG = find that better? Brgds, G/ > Best regards, > Xiaohu >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant) = [mailto:ketant@cisco.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5= 12:16 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg (ginsberg); = Christian Hopps; isis-wg@ietf.org >> =E6=8A=84=E9=80=81: isis-ads@ietf.org; = draft-ietf-isis-segment-routing-msd@ietf.org >> =E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07 >>=20 >> Hi Xu, >>=20 >> I am arguing the exact opposite of what you are saying. >>=20 >> Let us leave ELC/ERLD aside since it is very limited to entropy label = use-case and >> the proposed IGP/BGP-LS encoding is very specific to that. I am not = sure if this is >> the time anymore to revisit that. >>=20 >> The MSD proposal came later and I support is since I've found its use = to be >> much more widespread and the proposed IGP/BGP-LS protocol encoding to = be >> very efficient as an implementer of these protocols. Hence the = request to not >> restrict it to "writable" or "imposition" cases solely. It is also = not just about >> "readability" - which by itself is pretty meaningless. Even ERLD is = about >> "reading" and then "doing *something specific* about it" as discussed = in >> ietf-spring-segment-routing-mpls. >>=20 >> There is no second thoughts about the IGP ELC drafts and they are = very useful >> and necessary. Just to be clear there is *no functional or = operational change* >> that I am arguing for here. The discussion is purely on the way to = handle these >> encodings and whether we can use the MSD mechanism in a generalized >> manner. >>=20 >> Thanks, >> Ketan >>=20 >> -----Original Message----- >> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >> Sent: 21 December 2017 08:10 >> To: Les Ginsberg (ginsberg) ; Ketan Talaulikar = (ketant) >> ; Christian Hopps ; = isis-wg@ietf.org >> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >> Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07 >>=20 >> Hi Les, >>=20 >> If I understand it correctly, the MSD concept was originated from >> = (https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#page-7) = as >> described below: >>=20 >> "The "Maximum SID Depth" (1 >> octet) field (MSD) specifies the maximum number of SIDs (MPLS label >> stack depth in the context of this document) that a PCC is capable = of >> imposing on a packet." >>=20 >> Before considering expanding the semantics of the MSD concept as = defined in >> the above PCE-SR draft, how about first considering renaming the = capability of >> imposing the maximum number of labels so as to eliminate possible = confusions, >> e.g., Writable Label-stack Depth (WLD) as opposed to the Readable = Label-stack >> Depth (RLD) as defined in = (https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc) >> and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc) ? >>=20 >> Best regards, >> Xiaohu >>=20 >>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Isis-wg = [mailto:isis-wg-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Les Ginsberg >>> (ginsberg) >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97= =A5 4:02 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant); Christian = Hopps; isis-wg@ietf.org >>> =E6=8A=84=E9=80=81: isis-ads@ietf.org; = draft-ietf-isis-segment-routing-msd@ietf.org >>> =E4=B8=BB=E9=A2=98: Re: [Isis-wg] WG Last Call for >>> draft-ietf-isis-segment-routing-msd-07 >>>=20 >>> Ketan - >>>=20 >>> Thanx for the comments. >>> I think we do want to allow MSD support for values other than >>> imposition values. We will revise the text so we are not restricted = to only >> imposition cases. >>>=20 >>> Les >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Ketan Talaulikar (ketant) >>>> Sent: Wednesday, December 20, 2017 1:51 AM >>>> To: Christian Hopps ; isis-wg@ietf.org >>>> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >>>> Subject: RE: [Isis-wg] WG Last Call for >>>> draft-ietf-isis-segment-routing-msd-07 >>>>=20 >>>> Hello, >>>>=20 >>>> I support this document and would like to ask the authors and WG to >>>> consider if we can expand the scope of this draft to not just >>>> "imposition" of the SID stack but also other similar limits related >>>> to other >>> actions (e.g. >>>> reading, processing, etc.). With Segment Routing, we are coming >>>> across various actions that nodes need to do with the SID stack for >>>> different purposes and IMHO it would be useful to extend the MSD >>>> ability to cover those as they arise. >>>>=20 >>>> Thanks, >>>> Ketan >>>>=20 >>>> -----Original Message----- >>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of >>>> Christian Hopps >>>> Sent: 20 December 2017 14:03 >>>> To: isis-wg@ietf.org >>>> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >>>> Subject: [Isis-wg] WG Last Call for >>>> draft-ietf-isis-segment-routing-msd-07 >>>>=20 >>>>=20 >>>> The authors have asked for and we are starting a WG Last Call on >>>>=20 >>>>=20 >>>> = https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd >>>> / >>>>=20 >>>> which will last an extended 4 weeks to allow for year-end PTO = patterns. >>>>=20 >>>> An IPR statement exists: >>>>=20 >>>>=20 >>>> = https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf- >>>> is >>>> is- >>>> segment-routing-msd >>>>=20 >>>> Authors please reply to the list indicating whether you are aware = of >>>> any >>>> *new* IPR. >>>>=20 >>>> Thanks, >>>> Chris. >>>>=20 >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>=20 >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg@ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_AD9F1F8B-A08B-4C58-91FE-2EE280812CB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Xiaohu,

Thanks for = digging through the draft.

See inline: GV>

On 23 = Dec 2017, at 09:40, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi = all,

I just read the draft = (draft-ietf-idr-bgp-ls-segment-routing-rld) due to the curiosity of the = ERLD terminology. I have thought that this draft is just about a = straightforward BGP-LS extension for the RLD concept as defined in = draft-ietf-ospf-mpls-elc and draft-ietf-isis-mpls-elc according to the = draft name. However it isn't in fact. Maybe the draft name should have = been *-erld rather than *-rld.

I have the = following comments on this draft = (draft-ietf-idr-bgp-ls-segment-routing-rld):

1) ERLD means Entropy capable Readable Label Depth as defined = in this draft. However, it said "...A network node signalling an ERLD = MUST support the ability to read the signalled number of labels before = any action is done upon the packet..." I'm wondering what actions other = than the EL-based LB action the "any action" could be since the ERLD has = been tightly coupled with the EL-based LB mechanism. In contrast, the = RLD as defined in the two IGP drafts is not tightly couple with the = EL-based LB action. In other words, the RLD capability could be = applicable to other use cases besides the EL-based LB.


GV> = This is exactly what I asked during the IETF100 IDR slot when I = presented the updated work. The consensus was that signalling of a = readable label depth has entropy as the dominant use-case scenario. This = is now documented in: 
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07. Consensus from IETF100 IDR meeting was that ERLD is the way = forward for BGP-LS based signalling, and that maybe this should also be = the case for both ISIS and OSPF drafts (however, that is different = discussion).  I agree with IDR consensus and it seems the most = pragmatic path forward.


2) It said "...In existing technology both ISIS [4] and OSPF = [3] have proposed extensions to signal the RLD (Readable Label Depth) = and ELC (Entropy Label Capability) of a node or link. " However, there = is no extensions to signal the RLD and ELC of a link, if I remembered = correctly as a co-author of the above two IGP drafts:) In fact, when the = two IGP drafts were initially proposed, some guys does argue why not = advertise ELC and RLD of the per-link granularity as well. After some = discussion in IETF, a rough consensus had been reached that the = advertisement of ELC and RLD at a per node granularity was good enough = at that time. That's the reason why the two IGP drafts had not been = extended to advertise ELC and RLD at a per link granularity therefore. = Maybe we should reopen such discussion now?


GV> = I have no intend to open up that discussion at all, as it seems a = pragmatic consensus was reached. Steering seems to become more complex = when link based ERLD is proposed and a potential set of different ERLDs = are signalled due to capabilities of the line-card HW.  If for https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07 we just need node based ERLD, then I that is just fine. My = personal opinion is that we need node ERLD for node for sure in BGP-LS, = and that link ERLD is a nice to have. It seems relative easy and = pragmatic to add both Link and node ERLD in current version of the = BGP-LS ERLD document.

3) It said "...if a network = SDN controller is connected to the network through a BGP-LS session and = not through ISIS or OSPF technology, then both RLD and ELC needs to be = signaled in BGP-LS accordingly.  This document describes the = extension BGP-LS requires to transport the combination of RLD and ELC = into according ERLD attributes for nodes and links..." I have not yet = found any explanation about the motivation for advertising the = combination of RLD and ELC into according ERLD attributes rather than = advertising these two attributes separately. Would it be better to give = any explanation about such motivation in the Problem Statement = section?



GV> = Yes, indeed, again that was reason again that the work was presented = during IETF100 as I had some doubts myself. During IETF100 IDR meeting, = I learned and was confirmed that ERLD is now in the SPRING entropy label = draft and that hence ERLD is to be signalled for the most prominent = use-case driving readable label depth signalling
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07. I see no reason to open that discussion again, and current = BGP-LS ERLD draft is inline the most dominant use-case scenario (Entropy = based load-balancing). I could change the existing text to refer = to https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07 and only mention ERLD (and no longer mention ELC/RLD at = all) if IDR WG find that better?

Brgds,

G/

Best regards,
Xiaohu

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 12:16
=E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg = (ginsberg); Christian Hopps; isis-wg@ietf.org
=E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07

Hi = Xu,

I am arguing the exact opposite of what = you are saying.

Let us leave ELC/ERLD aside = since it is very limited to entropy label use-case and
the = proposed IGP/BGP-LS encoding is very specific to that. I am not sure if = this is
the time anymore to revisit that.

The MSD proposal came later and I support is since I've found = its use to be
much more widespread and the proposed = IGP/BGP-LS protocol encoding to be
very efficient as an = implementer of these protocols. Hence the request to not
restrict it to "writable" or "imposition" cases solely. It is = also not just about
"readability" - which by itself is = pretty meaningless. Even ERLD is about
"reading" and then = "doing *something specific* about it" as discussed in
ietf-spring-segment-routing-mpls.

There is no second thoughts about the IGP ELC drafts and they = are very useful
and necessary. Just to be clear there is = *no functional or operational change*
that I am arguing = for here. The discussion is purely on the way to handle these
encodings and whether we can use the MSD mechanism in a = generalized
manner.

Thanks,
Ketan

-----Original = Message-----
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: 21 = December 2017 08:10
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; = Ketan Talaulikar (ketant)
<ketant@cisco.com>; = Christian Hopps <chopps@chopps.org>; isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07

Hi = Les,

If I understand it correctly, the MSD = concept was originated from
(https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#p= age-7) as
described below:

"The "Maximum SID Depth" (1
  octet) = field (MSD) specifies the maximum number of SIDs (MPLS label
  stack depth in the context of this document) = that a PCC is capable of
  imposing on a = packet."

Before considering expanding the = semantics of the MSD concept as defined in
the above = PCE-SR draft, how about first considering renaming the capability of
imposing the maximum number of labels so as to eliminate = possible confusions,
e.g., Writable Label-stack Depth = (WLD) as opposed to the Readable Label-stack
Depth (RLD) = as defined in (https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc)
and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc) = ?

Best regards,
Xiaohu

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Isis-wg [mailto:isis-wg-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Les = Ginsberg
(ginsberg)
=E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 4:02
=E6=94=B6=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant); = Christian Hopps; isis-wg@ietf.org
=E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98: Re: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07

Ketan -

Thanx for the = comments.
I think we do want to allow MSD support for = values other than
imposition values. We will revise the = text so we are not restricted to only
imposition cases.

 Les


-----Original Message-----
From: Ketan = Talaulikar (ketant)
Sent: Wednesday, December 20, 2017 = 1:51 AM
To: Christian Hopps <chopps@chopps.org>; = isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: RE: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07

Hello,

I support this document = and would like to ask the authors and WG to
consider if we = can expand the scope of this draft to not just
"imposition" = of the SID stack but also other similar limits related
to = other
actions (e.g.
reading, processing, etc.). With Segment = Routing, we are coming
across various actions that nodes = need to do with the SID stack for
different purposes and = IMHO it would be useful to extend the MSD
ability to cover = those as they arise.

Thanks,
Ketan

-----Original = Message-----
From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of
Christian Hopps
Sent: 20 December 2017 14:03
To: isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07


The authors have asked for and we are starting = a WG Last Call on


https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routin= g-msd
/

which will last = an extended 4 weeks to allow for year-end PTO patterns.

An IPR statement exists:


https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3D= draft-ietf-
is
is-
segment-routing-msd

Authors = please reply to the list indicating whether you are aware of
any
*new* IPR.

Thanks,
Chris.

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
_____________________________________= __________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

= --Apple-Mail=_AD9F1F8B-A08B-4C58-91FE-2EE280812CB2-- From nobody Sat Dec 23 11:09:31 2017 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 B3BFC124D68; Sat, 23 Dec 2017 11:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 gjOBNvFz4KQT; Sat, 23 Dec 2017 11:09:22 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 245B91241F3; Sat, 23 Dec 2017 11:09:22 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id f190so17843003ita.5; Sat, 23 Dec 2017 11:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xa0mC6u00KNW5iQ/ShKj2Wq/dfiFeCW3e195cKj2Gv0=; b=OnkWiVnp88lZo2KC1Dv5UyhR8TtEtOlGH4DosThnNSR68SgFuFIPByBxnUSfTapQKl LHIUueUwWfL16vGHOPReIyXHjBPgufLR0AHlcfYOYKxQjOkVSO4ghvr2OFLS6n/COawy AhzEqacFWFloiHYMdjLdmyfEIBpbZvac0OGevpWRV6gIcZQfZZd9sJzctNUDnuKdNa5Y KtY23CoTwoq/g5ncYLlccdHBVFX7FFTVZhEyKtlMYNEkXjYvWlcxQPdCstsAhRW72Lrz Giay5gxwgappHJcZSOSXeSq/wbbxJ26EM1qMf/R1uhDZhiIjJoxIJnaQgs0SA/05Ez77 0ctw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xa0mC6u00KNW5iQ/ShKj2Wq/dfiFeCW3e195cKj2Gv0=; b=pwFPvTWWjnfTDs62V7cz2pjarvtircxJTi2iLzKSiUpNpgpetT8a5zQ5S7Xb7kZ48H BgQ+qspwB6algaKIhOX6rEGZ2Dsyc0VV7dyy5RRfwZ6ReYjTMxdOlSXzTibfnkVUPpnz mLqOjX1vFqwINwXf6Drv0LnISDjpsd3ki13lEvuxf6ymfdoQesx3X8YTgqxnD9mrncdt oirMCzOLGRWSCY7hx/9MHY59jeaTPNm2EX8hSTjLPqbSX+F9i9AjoLgn7rIMbiyKxUUE kQvR0rJLBtMzO9m9lMTWBM/vs3dtwoWgt5c6eA8rrSp+l+9KxfxopAKRmafch32vN5GY ev4Q== X-Gm-Message-State: AKGB3mIlk5Jsy6SMcdIjtfNykaFPDePCqax9XAqK+8cZRRa9yYFgHbJL 6MiU+gM4ajQ2xyYLs2721OtQkrri X-Google-Smtp-Source: ACJfBotVHv2H3XmYklw6MyxXxt3T2vEyZKbw6qFvZSbVu+MqgA1JMiZG3CPlSIyjOu15HQiF3lJSeg== X-Received: by 10.36.181.82 with SMTP id j18mr23668289iti.18.1514056161274; Sat, 23 Dec 2017 11:09:21 -0800 (PST) Received: from ?IPv6:2600:6c4e:2200:4cb:ac55:5e66:96a2:7f99? (2600-6c4e-2200-04cb-ac55-5e66-96a2-7f99.dhcp6.chtrptr.net. [2600:6c4e:2200:4cb:ac55:5e66:96a2:7f99]) by smtp.gmail.com with ESMTPSA id b12sm3222329ioe.38.2017.12.23.11.09.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Dec 2017 11:09:20 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-7029ADBD-356B-4FB7-8C63-2DC25D74CCC8 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Sat, 23 Dec 2017 11:09:18 -0800 Cc: Xuxiaohu , "idr@ietf.org" , "spring@ietf.org" , "isis-wg@ietf.org" , "ospf@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7A3E@NKGEML515-MBS.china.huawei.com> To: Gunter Van De Velde Archived-At: Subject: Re: [OSPF] [Idr] A comment regarding the relationship between RLD and ERLD X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 23 Dec 2017 19:09:26 -0000 --Apple-Mail-7029ADBD-356B-4FB7-8C63-2DC25D74CCC8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gunter, As I also said in Singapore - another interesting use case would be related t= o statistics, without going into semantics, we might need another SID in the= stack to uniquely identify a tunnel (domain wide)that would result in a cou= nter hit. RLD is crucial here. There would be some control plan implications on how to correlate local coun= ter name to domain wide tunnel identifier. Some YANG work as well (streaming= telemetry related). Happy Holidays everyone! Regards, Jeff > On Dec 23, 2017, at 01:25, Gunter Van De Velde wrote: >=20 > Hi Xiaohu, >=20 > Thanks for digging through the draft. >=20 > See inline: GV> >=20 >> On 23 Dec 2017, at 09:40, Xuxiaohu wrote: >>=20 >> Hi all, >>=20 >> I just read the draft (draft-ietf-idr-bgp-ls-segment-routing-rld) due to t= he curiosity of the ERLD terminology. I have thought that this draft is just= about a straightforward BGP-LS extension for the RLD concept as defined in d= raft-ietf-ospf-mpls-elc and draft-ietf-isis-mpls-elc according to the draft n= ame. However it isn't in fact. Maybe the draft name should have been *-erld r= ather than *-rld. >>=20 >> I have the following comments on this draft (draft-ietf-idr-bgp-ls-segmen= t-routing-rld): >>=20 >> 1) ERLD means Entropy capable Readable Label Depth as defined in this dra= ft. However, it said "...A network node signalling an ERLD MUST support the a= bility to read the signalled number of labels before any action is done upon= the packet..." I'm wondering what actions other than the EL-based LB action= the "any action" could be since the ERLD has been tightly coupled with the E= L-based LB mechanism. In contrast, the RLD as defined in the two IGP drafts i= s not tightly couple with the EL-based LB action. In other words, the RLD ca= pability could be applicable to other use cases besides the EL-based LB. >>=20 >=20 > GV> This is exactly what I asked during the IETF100 IDR slot when I presen= ted the updated work. The consensus was that signalling of a readable label d= epth has entropy as the dominant use-case scenario. This is now documented i= n:=20 > https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07. Conse= nsus from IETF100 IDR meeting was that ERLD is the way forward for BGP-LS ba= sed signalling, and that maybe this should also be the case for both ISIS an= d OSPF drafts (however, that is different discussion). I agree with IDR con= sensus and it seems the most pragmatic path forward. >=20 >=20 >> 2) It said "...In existing technology both ISIS [4] and OSPF [3] have pro= posed extensions to signal the RLD (Readable Label Depth) and ELC (Entropy L= abel Capability) of a node or link. " However, there is no extensions to sig= nal the RLD and ELC of a link, if I remembered correctly as a co-author of t= he above two IGP drafts:) In fact, when the two IGP drafts were initially pr= oposed, some guys does argue why not advertise ELC and RLD of the per-link g= ranularity as well. After some discussion in IETF, a rough consensus had bee= n reached that the advertisement of ELC and RLD at a per node granularity wa= s good enough at that time. That's the reason why the two IGP drafts had not= been extended to advertise ELC and RLD at a per link granularity therefore.= Maybe we should reopen such discussion now? >>=20 >=20 > GV> I have no intend to open up that discussion at all, as it seems a prag= matic consensus was reached. Steering seems to become more complex when link= based ERLD is proposed and a potential set of different ERLDs are signalled= due to capabilities of the line-card HW. If for https://tools.ietf.org/htm= l/draft-ietf-mpls-spring-entropy-label-07 we just need node based ERLD, then= I that is just fine. My personal opinion is that we need node ERLD for node= for sure in BGP-LS, and that link ERLD is a nice to have. It seems relative= easy and pragmatic to add both Link and node ERLD in current version of the= BGP-LS ERLD document. >=20 >> 3) It said "...if a network SDN controller is connected to the network th= rough a BGP-LS session and not through ISIS or OSPF technology, then both RL= D and ELC needs to be signaled in BGP-LS accordingly. This document describ= es the extension BGP-LS requires to transport the combination of RLD and ELC= into according ERLD attributes for nodes and links..." I have not yet found= any explanation about the motivation for advertising the combination of RLD= and ELC into according ERLD attributes rather than advertising these two at= tributes separately. Would it be better to give any explanation about such m= otivation in the Problem Statement section? >>=20 >>=20 >=20 > GV> Yes, indeed, again that was reason again that the work was presented d= uring IETF100 as I had some doubts myself. During IETF100 IDR meeting, I lea= rned and was confirmed that ERLD is now in the SPRING entropy label draft an= d that hence ERLD is to be signalled for the most prominent use-case driving= readable label depth signalling > https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07. I see= no reason to open that discussion again, and current BGP-LS ERLD draft is i= nline the most dominant use-case scenario (Entropy based load-balancing). I c= ould change the existing text to refer to https://tools.ietf.org/html/draft-= ietf-mpls-spring-entropy-label-07 and only mention ERLD (and no longer menti= on ELC/RLD at all) if IDR WG find that better? >=20 > Brgds, >=20 > G/ >=20 >> Best regards, >> Xiaohu >>=20 >>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant) [mailto:ketant@ci= sco.com] >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5= 12:16 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg (ginsberg); Christia= n Hopps; isis-wg@ietf.org >>> =E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-m= sd@ietf.org >>> =E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for draft-ietf-isis-segme= nt-routing-msd-07 >>>=20 >>> Hi Xu, >>>=20 >>> I am arguing the exact opposite of what you are saying. >>>=20 >>> Let us leave ELC/ERLD aside since it is very limited to entropy label us= e-case and >>> the proposed IGP/BGP-LS encoding is very specific to that. I am not sure= if this is >>> the time anymore to revisit that. >>>=20 >>> The MSD proposal came later and I support is since I've found its use to= be >>> much more widespread and the proposed IGP/BGP-LS protocol encoding to be= >>> very efficient as an implementer of these protocols. Hence the request t= o not >>> restrict it to "writable" or "imposition" cases solely. It is also not j= ust about >>> "readability" - which by itself is pretty meaningless. Even ERLD is abou= t >>> "reading" and then "doing *something specific* about it" as discussed in= >>> ietf-spring-segment-routing-mpls. >>>=20 >>> There is no second thoughts about the IGP ELC drafts and they are very u= seful >>> and necessary. Just to be clear there is *no functional or operational c= hange* >>> that I am arguing for here. The discussion is purely on the way to handl= e these >>> encodings and whether we can use the MSD mechanism in a generalized >>> manner. >>>=20 >>> Thanks, >>> Ketan >>>=20 >>> -----Original Message----- >>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>> Sent: 21 December 2017 08:10 >>> To: Les Ginsberg (ginsberg) ; Ketan Talaulikar (keta= nt) >>> ; Christian Hopps ; isis-wg@ietf.or= g >>> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >>> Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for draft-ietf-isis-= segment-routing-msd-07 >>>=20 >>> Hi Les, >>>=20 >>> If I understand it correctly, the MSD concept was originated from >>> (https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#page-7) a= s >>> described below: >>>=20 >>> "The "Maximum SID Depth" (1 >>> octet) field (MSD) specifies the maximum number of SIDs (MPLS label >>> stack depth in the context of this document) that a PCC is capable of >>> imposing on a packet." >>>=20 >>> Before considering expanding the semantics of the MSD concept as defined= in >>> the above PCE-SR draft, how about first considering renaming the capabil= ity of >>> imposing the maximum number of labels so as to eliminate possible confus= ions, >>> e.g., Writable Label-stack Depth (WLD) as opposed to the Readable Label-= stack >>> Depth (RLD) as defined in (https://tools.ietf.org/html/draft-ietf-ospf-m= pls-elc) >>> and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc) ? >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Isis-wg [mailto:isis-wg-bounces@ietf.org] =E4= =BB=A3=E8=A1=A8 Les Ginsberg >>>> (ginsberg) >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5= 4:02 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant); Christian Hopps= ; isis-wg@ietf.org >>>> =E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-= msd@ietf.org >>>> =E4=B8=BB=E9=A2=98: Re: [Isis-wg] WG Last Call for >>>> draft-ietf-isis-segment-routing-msd-07 >>>>=20 >>>> Ketan - >>>>=20 >>>> Thanx for the comments. >>>> I think we do want to allow MSD support for values other than >>>> imposition values. We will revise the text so we are not restricted to o= nly >>> imposition cases. >>>>=20 >>>> Les >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Ketan Talaulikar (ketant) >>>>> Sent: Wednesday, December 20, 2017 1:51 AM >>>>> To: Christian Hopps ; isis-wg@ietf.org >>>>> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >>>>> Subject: RE: [Isis-wg] WG Last Call for >>>>> draft-ietf-isis-segment-routing-msd-07 >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> I support this document and would like to ask the authors and WG to >>>>> consider if we can expand the scope of this draft to not just >>>>> "imposition" of the SID stack but also other similar limits related >>>>> to other >>>> actions (e.g. >>>>> reading, processing, etc.). With Segment Routing, we are coming >>>>> across various actions that nodes need to do with the SID stack for >>>>> different purposes and IMHO it would be useful to extend the MSD >>>>> ability to cover those as they arise. >>>>>=20 >>>>> Thanks, >>>>> Ketan >>>>>=20 >>>>> -----Original Message----- >>>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of >>>>> Christian Hopps >>>>> Sent: 20 December 2017 14:03 >>>>> To: isis-wg@ietf.org >>>>> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >>>>> Subject: [Isis-wg] WG Last Call for >>>>> draft-ietf-isis-segment-routing-msd-07 >>>>>=20 >>>>>=20 >>>>> The authors have asked for and we are starting a WG Last Call on >>>>>=20 >>>>>=20 >>>>> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd >>>>> / >>>>>=20 >>>>> which will last an extended 4 weeks to allow for year-end PTO patterns= . >>>>>=20 >>>>> An IPR statement exists: >>>>>=20 >>>>>=20 >>>>> https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-iet= f- >>>>> is >>>>> is- >>>>> segment-routing-msd >>>>>=20 >>>>> Authors please reply to the list indicating whether you are aware of >>>>> any >>>>> *new* IPR. >>>>>=20 >>>>> Thanks, >>>>> Chris. >>>>>=20 >>>>> _______________________________________________ >>>>> Isis-wg mailing list >>>>> Isis-wg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>=20 >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-7029ADBD-356B-4FB7-8C63-2DC25D74CCC8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gunter,

As I also said i= n Singapore - another interesting use case would be related to statistics, w= ithout going into semantics, we might need another SID in the stack to uniqu= ely identify a tunnel (domain wide)that would result in a counter hit. RLD i= s crucial here.
There would be some control plan implications on h= ow to correlate local counter name to domain wide tunnel identifier. Some YA= NG work as well (streaming telemetry related).

Happ= y Holidays everyone!

Regards,
Jeff=

On Dec 23, 2017, at 01:25, Gunter Van De Velde <guntervandeveldecc@icloud.com> wrote:

Hi Xiaohu,

Thanks for digging through the draft= .

See inline: GV&g= t;

On 23 Dec 2017, at 09:40, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi all,
I just read the draft (draft-ietf-idr-bgp-ls-seg= ment-routing-rld) due to the curiosity of the ERLD terminology. I have thoug= ht that this draft is just about a straightforward BGP-LS extension for the R= LD concept as defined in draft-ietf-ospf-mpls-elc and draft-ietf-isis-mpls-e= lc according to the draft name. However it isn't in fact. Maybe the draft na= me should have been *-erld rather than *-rld.

I= have the following comments on this draft (draft-ietf-idr-bgp-ls-segment-ro= uting-rld):

1) ERLD means Entropy capable Reada= ble Label Depth as defined in this draft. However, it said "...A network nod= e signalling an ERLD MUST support the ability to read the signalled number o= f labels before any action is done upon the packet..." I'm wondering what ac= tions other than the EL-based LB action the "any action" could be since the E= RLD has been tightly coupled with the EL-based LB mechanism. In contrast, th= e RLD as defined in the two IGP drafts is not tightly couple with the EL-bas= ed LB action. In other words, the RLD capability could be applicable to othe= r use cases besides the EL-based LB.


GV> This is exactly what I a= sked during the IETF100 IDR slot when I presented the updated work. The cons= ensus was that signalling of a readable label depth has entropy as the domin= ant use-case scenario. This is now documented in: 
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07. C= onsensus from IETF100 IDR meeting was that ERLD is the way forward for BGP-L= S based signalling, and that maybe this should also be the case for both ISI= S and OSPF drafts (however, that is different discussion).  I agree wit= h IDR consensus and it seems the most pragmatic path forward.


2) It said "...In existing technology both ISIS [4] a= nd OSPF [3] have proposed extensions to signal the RLD (Readable Label Depth= ) and ELC (Entropy Label Capability) of a node or link. " However, there is n= o extensions to signal the RLD and ELC of a link, if I remembered correctly a= s a co-author of the above two IGP drafts:) In fact, when the two IGP drafts= were initially proposed, some guys does argue why not advertise ELC and RLD= of the per-link granularity as well. After some discussion in IETF, a rough= consensus had been reached that the advertisement of ELC and RLD at a per n= ode granularity was good enough at that time. That's the reason why the two I= GP drafts had not been extended to advertise ELC and RLD at a per link granu= larity therefore. Maybe we should reopen such discussion now?
=

GV>= ; I have no intend to open up that discussion at all, as it seems a pragmati= c consensus was reached. Steering seems to become more complex when link bas= ed ERLD is proposed and a potential set of different ERLDs are signalled due= to capabilities of the line-card HW.  If for https://to= ols.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 we just need n= ode based ERLD, then I that is just fine. My personal opinion is that we nee= d node ERLD for node for sure in BGP-LS, and that link ERLD is a nice to hav= e. It seems relative easy and pragmatic to add both Link and node ERLD in cu= rrent version of the BGP-LS ERLD document.

3) It said "...if a n= etwork SDN controller is connected to the network through a BGP-LS session a= nd not through ISIS or OSPF technology, then both RLD and ELC needs to be si= gnaled in BGP-LS accordingly.  This document describes the extension BG= P-LS requires to transport the combination of RLD and ELC into according ERL= D attributes for nodes and links..." I have not yet found any explanation ab= out the motivation for advertising the combination of RLD and ELC into accor= ding ERLD attributes rather than advertising these two attributes separately= . Would it be better to give any explanation about such motivation in the Pr= oblem Statement section?


<= /div>

GV> Yes, indeed, again t= hat was reason again that the work was presented during IETF100 as I had som= e doubts myself. During IETF100 IDR meeting, I learned and was confirmed tha= t ERLD is now in the SPRING entropy label draft and that hence ERLD is to be= signalled for the most prominent use-case driving readable label depth sign= alling
https://tools.ietf.org/html/draft-ietf-mpls-= spring-entropy-label-07. I see no reason to open that discussion again, a= nd current BGP-LS ERLD draft is inline the most dominant use-case scenario (= Entropy based load-balancing). I could change the existing text to refer to&= nbsp;https://tools.ietf.org/html/draft-ietf-mpls-spring-entro= py-label-07 and only mention ERLD (and no longer mention ELC/RLD at= all) if IDR WG find that better?

Brgds,=

G/

Best regards,
Xiaohu

= -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB= =B6=E4=BA=BA: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 12:16
=E6= =94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg (ginsberg); Christian Hopps= ; isis-wg@ietf.org
=E6=8A=84=E9=80=81: = isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for draft-ietf-isis-= segment-routing-msd-07

Hi Xu,
I am arguing the exact opposite of what you are saying.

Let us leave ELC/ERLD aside since it is very limited to= entropy label use-case and
the proposed IGP/BGP-LS encoding i= s very specific to that. I am not sure if this is
the time any= more to revisit that.

The MSD proposal came lat= er and I support is since I've found its use to be
much more w= idespread and the proposed IGP/BGP-LS protocol encoding to be
= very efficient as an implementer of these protocols. Hence the request to no= t
restrict it to "writable" or "imposition" cases solely. It i= s also not just about
"readability" - which by itself is prett= y meaningless. Even ERLD is about
"reading" and then "doing *s= omething specific* about it" as discussed in
ietf-spring-segme= nt-routing-mpls.

There is no second thoughts ab= out the IGP ELC drafts and they are very useful
and necessary.= Just to be clear there is *no functional or operational change*
that I am arguing for here. The discussion is purely on the way to handle= these
encodings and whether we can use the MSD mechanism in a= generalized
manner.

Thanks,
Ketan

-----Original Message-----
From: Xuxiaohu [= mailto:xuxiaohu@huawei.com]
Sent: 21 December 2017 08:10To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Ketan Talaulikar (ketant)
<ketant@cisco.co= m>; Christian Hopps <chopps@chopps.org>; isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.o= rg
Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for= draft-ietf-isis-segment-routing-msd-07

Hi Les,=

If I understand it correctly, the MSD concept w= as originated from
(https://tools.ietf.org/htm= l/draft-ietf-pce-segment-routing-11#page-7) as
described b= elow:

"The "Maximum SID Depth" (1
  octet) field (MSD) specifies the maximum number of SIDs (MPLS l= abel
  stack depth in the context of this document)= that a PCC is capable of
  imposing on a packet."<= br class=3D"">
Before considering expanding the semantics of t= he MSD concept as defined in
the above PCE-SR draft, how about= first considering renaming the capability of
imposing the max= imum number of labels so as to eliminate possible confusions,
= e.g., Writable Label-stack Depth (WLD) as opposed to the Readable Label-stac= k
Depth (RLD) as defined in (https://tools.ietf.org/html/draft= -ietf-ospf-mpls-elc)
and (https://tools.ietf.org/html/draf= t-ietf-isis-mpls-elc) ?

Best regards,
Xiaohu

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91= =E4=BB=B6=E4=BA=BA: Isis-wg [mailto:isis-wg-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Les Ginsberg=
(ginsberg)
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4= : 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 4:02
=E6=94=B6=E4=BB=B6=E4= =BA=BA: Ketan Talaulikar (ketant); Christian Hopps; isis-wg@ietf.org
=E6=8A=84=E9=80=81= : isis-ads@ietf.org; draft= -ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98= : Re: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routi= ng-msd-07

Ketan -

= Thanx for the comments.
I think we do want to allow MSD suppor= t for values other than
imposition values. We will revise the t= ext so we are not restricted to only
imposition c= ases.

&nb= sp;Les


-----Original Message-----
From: Ketan Talaulikar (= ketant)
Sent: Wednesday, December 20, 2017 1:51 AM
To: Christian Hopps <c= hopps@chopps.org>; isi= s-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: RE: [Isis-wg] WG Last Call for
draft= -ietf-isis-segment-routing-msd-07

Hello,

I support this document and would like to ask the aut= hors and WG to
consider if we can expand the scope of this dra= ft to not just
"imposition" of the SID stack but also other si= milar limits related
to other
actio= ns (e.g.
reading, process= ing, etc.). With Segment Routing, we are coming
across various= actions that nodes need to do with the SID stack for
differen= t purposes and IMHO it would be useful to extend the MSD
abili= ty to cover those as they arise.

Thanks,
Ketan

-----Original Message-----
From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of
Christian H= opps
Sent: 20 December 2017 14:03
To: isis-wg@ietf.org
Cc: <= a href=3D"mailto:isis-ads@ietf.org" class=3D"">isis-ads@ietf.org; draft-i= etf-isis-segment-routing-msd@ietf.org
Subject: [Isis-wg] W= G Last Call for
draft-ietf-isis-segment-routing-msd-07


The authors have asked for and we are s= tarting a WG Last Call on


https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-m= sd
/

which will last an exten= ded 4 weeks to allow for year-end PTO patterns.

An IPR statement exists:


https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraf= t-ietf-
is
is-
segment-routing= -msd

Authors please reply to the list indicatin= g whether you are aware of
any
*new* IPR.

Thanks,
Chris.

_______________________________________________
Isis-wg mai= ling list
Isis-wg@ietf.org=
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg<= br class=3D"">
____________________________________= ___________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

<= /blockquote>
= --Apple-Mail-7029ADBD-356B-4FB7-8C63-2DC25D74CCC8-- From nobody Sat Dec 23 12:07:54 2017 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 A9F5612025C; Sat, 23 Dec 2017 12:07:52 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 jCZUdECN_wiW; Sat, 23 Dec 2017 12:07:49 -0800 (PST) Received: from st13p11im-asmtp004.me.com (st13p11im-asmtp004.me.com [17.164.40.219]) (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 BD2371200F3; Sat, 23 Dec 2017 12:07:49 -0800 (PST) Received: from process-dkim-sign-daemon.st13p11im-asmtp004.me.com by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P1F00600JR7NS00@st13p11im-asmtp004.me.com>; Sat, 23 Dec 2017 20:07:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1514059668; bh=oB6mn4ivHya0wBcQaVYdbwjMxTU5JECQKTM7tUHprcY=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=E9WKQDGPkcLc9sz9Z437p+JzmDsSbihNau0dwwFW7V3icNZMPGwK4yn3pbXzd1al5 /WjnPvL67a04iXKLSN1KTevGh5sDePeXAodu85Y+MjQdLc4/iGZLQfz/0Yi6zh4u0e X8vLhsSwDFBWNiD8+29Tu//T0ToPqHYOMYmylFASuiHmUFOA8lc9f8nyGfVgoCvVDQ 2qDhMcJ8m3PlyQDJ7mtD/L9Vu5PVIoorMt27mRbFD2b/OHCuo3uTbMuySK2sfxR+ff FD1RE0VHGX/PSlfFWamkv52lxlJK092zTAYIDQyi71MuU5s3YXkzdYi6F4vXb7fbOg gn5Lw1lrwkDiw== Received: from icloud.com ([127.0.0.1]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P1F001JRJWQIN30@st13p11im-asmtp004.me.com>; Sat, 23 Dec 2017 20:07:43 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-23_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1712230277 From: Gunter Van De Velde Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_C869F3AC-7CFD-460B-9EFE-8B200A03CDDD" MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 23 Dec 2017 21:07:38 +0100 In-reply-to: Cc: Xuxiaohu , "idr@ietf.org" , "spring@ietf.org" , "isis-wg@ietf.org" , "ospf@ietf.org" To: Jeff Tantsura References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7A3E@NKGEML515-MBS.china.huawei.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [OSPF] [Idr] A comment regarding the relationship between RLD and ERLD X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 23 Dec 2017 20:07:53 -0000 --Apple-Mail=_C869F3AC-7CFD-460B-9EFE-8B200A03CDDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jeff, Correct. I referenced below to =E2=80=98dominant use cases being = entropy=E2=80=9D for a reason. There is indeed use case regarding alternate marking using Synonymous = Flow Labels and another one involving=20 potential statistics marking using targeted labels. This understanding = drove to question at IETF100 IDR meeting to=20 go for either =E2=80=9CERLD=E2=80=9D or =E2=80=9CRLD/ELC=E2=80=9D (or = even additional capabilities signalled).=20 The consensus at IDR@IETF100 was that dominant use-case is entropy and = that ERLD is the logical info to signal in BGP-LS.=20 I had/have no strong bias with going either way. I just am little = dazzled that for some reason the discussion is opened up again now we = had consensus. G/ > On 23 Dec 2017, at 20:09, Jeff Tantsura = wrote: >=20 > Gunter, >=20 > As I also said in Singapore - another interesting use case would be = related to statistics, without going into semantics, we might need = another SID in the stack to uniquely identify a tunnel (domain wide)that = would result in a counter hit. RLD is crucial here. > There would be some control plan implications on how to correlate = local counter name to domain wide tunnel identifier. Some YANG work as = well (streaming telemetry related). >=20 > Happy Holidays everyone! >=20 > Regards, > Jeff >=20 > On Dec 23, 2017, at 01:25, Gunter Van De Velde = > = wrote: >=20 >> Hi Xiaohu, >>=20 >> Thanks for digging through the draft. >>=20 >> See inline: GV> >>=20 >>> On 23 Dec 2017, at 09:40, Xuxiaohu > wrote: >>>=20 >>> Hi all, >>>=20 >>> I just read the draft (draft-ietf-idr-bgp-ls-segment-routing-rld) = due to the curiosity of the ERLD terminology. I have thought that this = draft is just about a straightforward BGP-LS extension for the RLD = concept as defined in draft-ietf-ospf-mpls-elc and = draft-ietf-isis-mpls-elc according to the draft name. However it isn't = in fact. Maybe the draft name should have been *-erld rather than *-rld. >>>=20 >>> I have the following comments on this draft = (draft-ietf-idr-bgp-ls-segment-routing-rld): >>>=20 >>> 1) ERLD means Entropy capable Readable Label Depth as defined in = this draft. However, it said "...A network node signalling an ERLD MUST = support the ability to read the signalled number of labels before any = action is done upon the packet..." I'm wondering what actions other than = the EL-based LB action the "any action" could be since the ERLD has been = tightly coupled with the EL-based LB mechanism. In contrast, the RLD as = defined in the two IGP drafts is not tightly couple with the EL-based LB = action. In other words, the RLD capability could be applicable to other = use cases besides the EL-based LB. >>>=20 >>=20 >> GV> This is exactly what I asked during the IETF100 IDR slot when I = presented the updated work. The consensus was that signalling of a = readable label depth has entropy as the dominant use-case scenario. This = is now documented in:=20 >> https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = . = Consensus from IETF100 IDR meeting was that ERLD is the way forward for = BGP-LS based signalling, and that maybe this should also be the case for = both ISIS and OSPF drafts (however, that is different discussion). I = agree with IDR consensus and it seems the most pragmatic path forward. >>=20 >>=20 >>> 2) It said "...In existing technology both ISIS [4] and OSPF [3] = have proposed extensions to signal the RLD (Readable Label Depth) and = ELC (Entropy Label Capability) of a node or link. " However, there is no = extensions to signal the RLD and ELC of a link, if I remembered = correctly as a co-author of the above two IGP drafts:) In fact, when the = two IGP drafts were initially proposed, some guys does argue why not = advertise ELC and RLD of the per-link granularity as well. After some = discussion in IETF, a rough consensus had been reached that the = advertisement of ELC and RLD at a per node granularity was good enough = at that time. That's the reason why the two IGP drafts had not been = extended to advertise ELC and RLD at a per link granularity therefore. = Maybe we should reopen such discussion now? >>>=20 >>=20 >> GV> I have no intend to open up that discussion at all, as it seems a = pragmatic consensus was reached. Steering seems to become more complex = when link based ERLD is proposed and a potential set of different ERLDs = are signalled due to capabilities of the line-card HW. If for = https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = we = just need node based ERLD, then I that is just fine. My personal opinion = is that we need node ERLD for node for sure in BGP-LS, and that link = ERLD is a nice to have. It seems relative easy and pragmatic to add both = Link and node ERLD in current version of the BGP-LS ERLD document. >>=20 >>> 3) It said "...if a network SDN controller is connected to the = network through a BGP-LS session and not through ISIS or OSPF = technology, then both RLD and ELC needs to be signaled in BGP-LS = accordingly. This document describes the extension BGP-LS requires to = transport the combination of RLD and ELC into according ERLD attributes = for nodes and links..." I have not yet found any explanation about the = motivation for advertising the combination of RLD and ELC into according = ERLD attributes rather than advertising these two attributes separately. = Would it be better to give any explanation about such motivation in the = Problem Statement section? >>>=20 >>>=20 >>=20 >> GV> Yes, indeed, again that was reason again that the work was = presented during IETF100 as I had some doubts myself. During IETF100 IDR = meeting, I learned and was confirmed that ERLD is now in the SPRING = entropy label draft and that hence ERLD is to be signalled for the most = prominent use-case driving readable label depth signalling >> https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = . I = see no reason to open that discussion again, and current BGP-LS ERLD = draft is inline the most dominant use-case scenario (Entropy based = load-balancing). I could change the existing text to refer to = https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = = and only mention ERLD (and no longer mention ELC/RLD at all) if IDR WG = find that better? >>=20 >> Brgds, >>=20 >> G/ >>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant) = [mailto:ketant@cisco.com ] >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97= =A5 12:16 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg (ginsberg); = Christian Hopps; isis-wg@ietf.org >>>> =E6=8A=84=E9=80=81: isis-ads@ietf.org ; = draft-ietf-isis-segment-routing-msd@ietf.org = >>>> =E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07 >>>>=20 >>>> Hi Xu, >>>>=20 >>>> I am arguing the exact opposite of what you are saying. >>>>=20 >>>> Let us leave ELC/ERLD aside since it is very limited to entropy = label use-case and >>>> the proposed IGP/BGP-LS encoding is very specific to that. I am not = sure if this is >>>> the time anymore to revisit that. >>>>=20 >>>> The MSD proposal came later and I support is since I've found its = use to be >>>> much more widespread and the proposed IGP/BGP-LS protocol encoding = to be >>>> very efficient as an implementer of these protocols. Hence the = request to not >>>> restrict it to "writable" or "imposition" cases solely. It is also = not just about >>>> "readability" - which by itself is pretty meaningless. Even ERLD is = about >>>> "reading" and then "doing *something specific* about it" as = discussed in >>>> ietf-spring-segment-routing-mpls. >>>>=20 >>>> There is no second thoughts about the IGP ELC drafts and they are = very useful >>>> and necessary. Just to be clear there is *no functional or = operational change* >>>> that I am arguing for here. The discussion is purely on the way to = handle these >>>> encodings and whether we can use the MSD mechanism in a generalized >>>> manner. >>>>=20 >>>> Thanks, >>>> Ketan >>>>=20 >>>> -----Original Message----- >>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com = ] >>>> Sent: 21 December 2017 08:10 >>>> To: Les Ginsberg (ginsberg) >; Ketan Talaulikar (ketant) >>>> >; Christian Hopps = >; isis-wg@ietf.org = >>>> Cc: isis-ads@ietf.org ; = draft-ietf-isis-segment-routing-msd@ietf.org = >>>> Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07 >>>>=20 >>>> Hi Les, >>>>=20 >>>> If I understand it correctly, the MSD concept was originated from >>>> = (https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#page-7 = ) = as >>>> described below: >>>>=20 >>>> "The "Maximum SID Depth" (1 >>>> octet) field (MSD) specifies the maximum number of SIDs (MPLS = label >>>> stack depth in the context of this document) that a PCC is = capable of >>>> imposing on a packet." >>>>=20 >>>> Before considering expanding the semantics of the MSD concept as = defined in >>>> the above PCE-SR draft, how about first considering renaming the = capability of >>>> imposing the maximum number of labels so as to eliminate possible = confusions, >>>> e.g., Writable Label-stack Depth (WLD) as opposed to the Readable = Label-stack >>>> Depth (RLD) as defined in = (https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc = ) >>>> and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc = ) ? >>>>=20 >>>> Best regards, >>>> Xiaohu >>>>=20 >>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Isis-wg = [mailto:isis-wg-bounces@ietf.org ] = =E4=BB=A3=E8=A1=A8 Les Ginsberg >>>>> (ginsberg) >>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97= =A5 4:02 >>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant); Christian = Hopps; isis-wg@ietf.org >>>>> =E6=8A=84=E9=80=81: isis-ads@ietf.org ; = draft-ietf-isis-segment-routing-msd@ietf.org = >>>>> =E4=B8=BB=E9=A2=98: Re: [Isis-wg] WG Last Call for >>>>> draft-ietf-isis-segment-routing-msd-07 >>>>>=20 >>>>> Ketan - >>>>>=20 >>>>> Thanx for the comments. >>>>> I think we do want to allow MSD support for values other than >>>>> imposition values. We will revise the text so we are not = restricted to only >>>> imposition cases. >>>>>=20 >>>>> Les >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ketan Talaulikar (ketant) >>>>>> Sent: Wednesday, December 20, 2017 1:51 AM >>>>>> To: Christian Hopps >; isis-wg@ietf.org >>>>>> Cc: isis-ads@ietf.org ; = draft-ietf-isis-segment-routing-msd@ietf.org = >>>>>> Subject: RE: [Isis-wg] WG Last Call for >>>>>> draft-ietf-isis-segment-routing-msd-07 >>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> I support this document and would like to ask the authors and WG = to >>>>>> consider if we can expand the scope of this draft to not just >>>>>> "imposition" of the SID stack but also other similar limits = related >>>>>> to other >>>>> actions (e.g. >>>>>> reading, processing, etc.). With Segment Routing, we are coming >>>>>> across various actions that nodes need to do with the SID stack = for >>>>>> different purposes and IMHO it would be useful to extend the MSD >>>>>> ability to cover those as they arise. >>>>>>=20 >>>>>> Thanks, >>>>>> Ketan >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org = ] On Behalf Of >>>>>> Christian Hopps >>>>>> Sent: 20 December 2017 14:03 >>>>>> To: isis-wg@ietf.org >>>>>> Cc: isis-ads@ietf.org ; = draft-ietf-isis-segment-routing-msd@ietf.org = >>>>>> Subject: [Isis-wg] WG Last Call for >>>>>> draft-ietf-isis-segment-routing-msd-07 >>>>>>=20 >>>>>>=20 >>>>>> The authors have asked for and we are starting a WG Last Call on >>>>>>=20 >>>>>>=20 >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd = >>>>>> / >>>>>>=20 >>>>>> which will last an extended 4 weeks to allow for year-end PTO = patterns. >>>>>>=20 >>>>>> An IPR statement exists: >>>>>>=20 >>>>>>=20 >>>>>> = https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf- = = >>>>>> is >>>>>> is- >>>>>> segment-routing-msd >>>>>>=20 >>>>>> Authors please reply to the list indicating whether you are aware = of >>>>>> any >>>>>> *new* IPR. >>>>>>=20 >>>>>> Thanks, >>>>>> Chris. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Isis-wg mailing list >>>>>> Isis-wg@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/isis-wg = >>>>>=20 >>>>> _______________________________________________ >>>>> Isis-wg mailing list >>>>> Isis-wg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/isis-wg = >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr = >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf = --Apple-Mail=_C869F3AC-7CFD-460B-9EFE-8B200A03CDDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jeff,

Correct. I = referenced below to =E2=80=98dominant use cases being entropy=E2=80=9D = for a reason.

There is indeed use case regarding alternate marking using = Synonymous Flow Labels and another one involving 
potential statistics marking using targeted labels. This = understanding drove to question at IETF100 IDR meeting = to 
go for either =E2=80=9CERLD=E2=80=9D or = =E2=80=9CRLD/ELC=E2=80=9D (or even additional capabilities = signalled). 

The consensus at IDR@IETF100 was that dominant use-case is = entropy and that ERLD is the logical info to signal in = BGP-LS. 
I had/have no strong bias with going = either way. I just am little dazzled that for some reason the discussion = is opened up again now we had consensus.

G/

On 23 = Dec 2017, at 20:09, Jeff Tantsura <jefftant.ietf@gmail.com> wrote:

Gunter,
As I also said in Singapore = - another interesting use case would be related to statistics, without = going into semantics, we might need another SID in the stack to uniquely = identify a tunnel (domain wide)that would result in a counter hit. RLD = is crucial here.
There would be some control = plan implications on how to correlate local counter name to domain wide = tunnel identifier. Some YANG work as well (streaming telemetry = related).

Happy Holidays everyone!

Regards,
Jeff

On Dec 23, 2017, at 01:25, Gunter Van De Velde <guntervandeveldecc@icloud.com> wrote:

Hi = Xiaohu,

Thanks for = digging through the draft.

See inline: GV>

On 23 = Dec 2017, at 09:40, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi = all,

I just read the draft = (draft-ietf-idr-bgp-ls-segment-routing-rld) due to the curiosity of the = ERLD terminology. I have thought that this draft is just about a = straightforward BGP-LS extension for the RLD concept as defined in = draft-ietf-ospf-mpls-elc and draft-ietf-isis-mpls-elc according to the = draft name. However it isn't in fact. Maybe the draft name should have = been *-erld rather than *-rld.

I have the = following comments on this draft = (draft-ietf-idr-bgp-ls-segment-routing-rld):

1) ERLD means Entropy capable Readable Label Depth as defined = in this draft. However, it said "...A network node signalling an ERLD = MUST support the ability to read the signalled number of labels before = any action is done upon the packet..." I'm wondering what actions other = than the EL-based LB action the "any action" could be since the ERLD has = been tightly coupled with the EL-based LB mechanism. In contrast, the = RLD as defined in the two IGP drafts is not tightly couple with the = EL-based LB action. In other words, the RLD capability could be = applicable to other use cases besides the EL-based LB.


GV> This is exactly what I asked = during the IETF100 IDR slot when I presented the updated work. The = consensus was that signalling of a readable label depth has entropy as = the dominant use-case scenario. This is now documented = in: 
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07. Consensus from IETF100 IDR meeting was that ERLD is the way = forward for BGP-LS based signalling, and that maybe this should also be = the case for both ISIS and OSPF drafts (however, that is different = discussion).  I agree with IDR consensus and it seems the most = pragmatic path forward.


2) It said "...In existing technology both ISIS [4] and OSPF = [3] have proposed extensions to signal the RLD (Readable Label Depth) = and ELC (Entropy Label Capability) of a node or link. " However, there = is no extensions to signal the RLD and ELC of a link, if I remembered = correctly as a co-author of the above two IGP drafts:) In fact, when the = two IGP drafts were initially proposed, some guys does argue why not = advertise ELC and RLD of the per-link granularity as well. After some = discussion in IETF, a rough consensus had been reached that the = advertisement of ELC and RLD at a per node granularity was good enough = at that time. That's the reason why the two IGP drafts had not been = extended to advertise ELC and RLD at a per link granularity therefore. = Maybe we should reopen such discussion now?


GV> I have no intend to open up that = discussion at all, as it seems a pragmatic consensus was reached. = Steering seems to become more complex when link based ERLD is proposed = and a potential set of different ERLDs are signalled due to capabilities = of the line-card HW.  If for https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07 we just need = node based ERLD, then I that is just fine. My personal opinion is that = we need node ERLD for node for sure in BGP-LS, and that link ERLD is a = nice to have. It seems relative easy and pragmatic to add both Link and = node ERLD in current version of the BGP-LS ERLD document.

3) It said "...if a network SDN controller is connected to = the network through a BGP-LS session and not through ISIS or OSPF = technology, then both RLD and ELC needs to be signaled in BGP-LS = accordingly.  This document describes the extension BGP-LS requires = to transport the combination of RLD and ELC into according ERLD = attributes for nodes and links..." I have not yet found any explanation = about the motivation for advertising the combination of RLD and ELC into = according ERLD attributes rather than advertising these two attributes = separately. Would it be better to give any explanation about such = motivation in the Problem Statement section?



GV> Yes, indeed, again that was = reason again that the work was presented during IETF100 as I had some = doubts myself. During IETF100 IDR meeting, I learned and was confirmed = that ERLD is now in the SPRING entropy label draft and that hence ERLD = is to be signalled for the most prominent use-case driving readable = label depth signalling
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07. I see no reason to open that discussion again, and current = BGP-LS ERLD draft is inline the most dominant use-case scenario (Entropy = based load-balancing). I could change the existing text to refer = to https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07 and only mention ERLD (and no longer mention ELC/RLD at = all) if IDR WG find that better?

Brgds,

G/

Best = regards,
Xiaohu

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=E5=8F=91=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 12:16
=E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg = (ginsberg); Christian Hopps; isis-wg@ietf.org
=E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07

Hi = Xu,

I am arguing the exact opposite of what = you are saying.

Let us leave ELC/ERLD aside = since it is very limited to entropy label use-case and
the = proposed IGP/BGP-LS encoding is very specific to that. I am not sure if = this is
the time anymore to revisit that.

The MSD proposal came later and I support is since I've found = its use to be
much more widespread and the proposed = IGP/BGP-LS protocol encoding to be
very efficient as an = implementer of these protocols. Hence the request to not
restrict it to "writable" or "imposition" cases solely. It is = also not just about
"readability" - which by itself is = pretty meaningless. Even ERLD is about
"reading" and then = "doing *something specific* about it" as discussed in
ietf-spring-segment-routing-mpls.

There is no second thoughts about the IGP ELC drafts and they = are very useful
and necessary. Just to be clear there is = *no functional or operational change*
that I am arguing = for here. The discussion is purely on the way to handle these
encodings and whether we can use the MSD mechanism in a = generalized
manner.

Thanks,
Ketan

-----Original = Message-----
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: 21 = December 2017 08:10
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; = Ketan Talaulikar (ketant)
<ketant@cisco.com>; = Christian Hopps <chopps@chopps.org>; isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07

Hi = Les,

If I understand it correctly, the MSD = concept was originated from
(https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#p= age-7) as
described below:

"The "Maximum SID Depth" (1
  octet) = field (MSD) specifies the maximum number of SIDs (MPLS label
  stack depth in the context of this document) that = a PCC is capable of
  imposing on a packet."

Before considering expanding the semantics of = the MSD concept as defined in
the above PCE-SR draft, how = about first considering renaming the capability of
imposing = the maximum number of labels so as to eliminate possible confusions,
e.g., Writable Label-stack Depth (WLD) as opposed to the = Readable Label-stack
Depth (RLD) as defined in (https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc)
and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc) = ?

Best regards,
Xiaohu

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Isis-wg [mailto:isis-wg-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Les = Ginsberg
(ginsberg)
=E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 4:02
=E6=94=B6=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant); = Christian Hopps; isis-wg@ietf.org
=E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98: Re: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07

Ketan -

Thanx for the = comments.
I think we do want to allow MSD support for = values other than
imposition values. We will revise the = text so we are not restricted to only
imposition cases.

 Les


-----Original Message-----
From: Ketan = Talaulikar (ketant)
Sent: Wednesday, December 20, 2017 = 1:51 AM
To: Christian Hopps <chopps@chopps.org>; isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: RE: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07

Hello,

I support this document = and would like to ask the authors and WG to
consider if we = can expand the scope of this draft to not just
"imposition" = of the SID stack but also other similar limits related
to = other
actions (e.g.
reading, processing, etc.). With Segment = Routing, we are coming
across various actions that nodes = need to do with the SID stack for
different purposes and = IMHO it would be useful to extend the MSD
ability to cover = those as they arise.

Thanks,
Ketan

-----Original = Message-----
From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of
Christian Hopps
Sent: 20 December 2017 14:03
To: isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07


The authors have asked for and we are starting = a WG Last Call on


https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routin= g-msd
/

which will last = an extended 4 weeks to allow for year-end PTO patterns.

An IPR statement exists:


https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3D= draft-ietf-
is
is-
segment-routing-msd

Authors = please reply to the list indicating whether you are aware of
any
*new* IPR.

Thanks,
Chris.

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
_____________________________________= __________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

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

= --Apple-Mail=_C869F3AC-7CFD-460B-9EFE-8B200A03CDDD-- From nobody Tue Dec 26 15:33:00 2017 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 13BB0120227; Tue, 26 Dec 2017 15:32:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151433117405.29778.2327579034978153393@ietfa.amsl.com> Date: Tue, 26 Dec 2017 15:32:54 -0800 Archived-At: Subject: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-lsa-extend-20.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 23:32:54 -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 WG of the IETF. Title : OSPFv3 LSA Extendibility Authors : Acee Lindem Abhay Roy Dirk Goethals Veerendranatha Reddy Vallem Fred Baker Filename : draft-ietf-ospf-ospfv3-lsa-extend-20.txt Pages : 38 Date : 2017-12-26 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. This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-20 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv3-lsa-extend-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 26 15:36:16 2017 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 19208120046 for ; Tue, 26 Dec 2017 15:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.51 X-Spam-Level: X-Spam-Status: No, score=-13.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 WiJEEludN_Rr for ; Tue, 26 Dec 2017 15:36:05 -0800 (PST) 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 7319F126C19 for ; Tue, 26 Dec 2017 15:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3232; q=dns/txt; s=iport; t=1514331365; x=1515540965; h=from:cc:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=uDiq0OCIH+umFGZl3916bXtVRwhQlNOf+AgxcWr0NJk=; b=MnoH7WLmrMgbE2VbMEc67AmBbfmlYi//qsRjmUAldynlB0Iuvhi5l3pJ 80UVZJs7lHKbAp02n/7urtDHWxXIO3NYVn2bFg8M+qf/ICyDq26I20Bn8 j7zDqgz5zYPzXoYiBhup6afppJ7m7wPyQMsOf5Dob8vagU83IVFb1TvCv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAwCM3EJa/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQYDweDf5k6gUUEl2GCFQoYDYUWAhoMhC5AFwEBAQEBAQE?= =?us-ascii?q?BAWsohRsJAgEDAQEhEToLEAIBCBoCJgICAiULFRACEgWFc4Q7EKccgieKTwEBA?= =?us-ascii?q?QEBAQEDAQEBAQEBAQEggQ+CfYIShm2DLwEBF4RtFIJRBaNMAogBjTKCF2WFMYt?= =?us-ascii?q?QjSSJMgIRGQGBOwEhAjWBT28VGSSBBAiBHQmETniJKYEWAQEF?= X-IronPort-AV: E=Sophos;i="5.45,462,1508803200"; d="scan'208";a="48860969" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Dec 2017 23:36:04 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vBQNa4hg019268 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 26 Dec 2017 23:36:04 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.1320.4; Tue, 26 Dec 2017 18:36:03 -0500 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.1320.000; Tue, 26 Dec 2017 18:36:03 -0500 From: "Acee Lindem (acee)" CC: "ospf@ietf.org" Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-lsa-extend-20.txt Thread-Index: AQHTfqHrJRH77qXRp0mbIeje0MZu4aNWR0kA Date: Tue, 26 Dec 2017 23:36:03 +0000 Message-ID: References: <151433117405.29778.2327579034978153393@ietfa.amsl.com> In-Reply-To: <151433117405.29778.2327579034978153393@ietfa.amsl.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.198] Content-Type: text/plain; charset="utf-8" Content-ID: <3CCC135F2CB37B4D849DB7C9BE3C9D6B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-lsa-extend-20.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 26 Dec 2017 23:36:09 -0000 VGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyBBbGlh4oCZcyBSb3V0aW5nIEFEIGNvbW1lbnRzLg0KVGhh bmtzLA0KQWNlZQ0KDQpPbiAxMi8yNi8xNywgNjozMiBQTSwgIk9TUEYgb24gYmVoYWxmIG9mIGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyINCjxvc3BmLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCj4NCj5BIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj5k aXJlY3Rvcmllcy4NCj5UaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBPcGVuIFNob3J0 ZXN0IFBhdGggRmlyc3QgSUdQIFdHIG9mIHRoZQ0KPklFVEYuDQo+DQo+ICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBPU1BGdjMgTFNBIEV4dGVuZGliaWxpdHkNCj4gICAgICAgIEF1dGhvcnMgICAg ICAgICA6IEFjZWUgTGluZGVtDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBBYmhheSBSb3kN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgIERpcmsgR29ldGhhbHMNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgIFZlZXJlbmRyYW5hdGhhIFJlZGR5IFZhbGxlbQ0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgRnJlZCBCYWtlcg0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW9z cGYtb3NwZnYzLWxzYS1leHRlbmQtMjAudHh0DQo+CVBhZ2VzICAgICAgICAgICA6IDM4DQo+CURh dGUgICAgICAgICAgICA6IDIwMTctMTItMjYNCj4NCj5BYnN0cmFjdDoNCj4gICBPU1BGdjMgcmVx dWlyZXMgZnVuY3Rpb25hbCBleHRlbnNpb24gYmV5b25kIHdoYXQgY2FuIHJlYWRpbHkgYmUgZG9u ZQ0KPiAgIHdpdGggdGhlIGZpeGVkLWZvcm1hdCBMaW5rIFN0YXRlIEFkdmVydGlzZW1lbnQgKExT QSkgYXMgZGVzY3JpYmVkIGluDQo+ICAgUkZDIDUzNDAuICBXaXRob3V0IExTQSBleHRlbnNpb24s IGF0dHJpYnV0ZXMgYXNzb2NpYXRlZCB3aXRoIE9TUEZ2Mw0KPiAgIGxpbmtzIGFuZCBhZHZlcnRp c2VkIElQdjYgcHJlZml4ZXMgbXVzdCBiZSBhZHZlcnRpc2VkIGluIHNlcGFyYXRlDQo+ICAgTFNB cyBhbmQgY29ycmVsYXRlZCB0byB0aGUgZml4ZWQtZm9ybWF0IExTQXMuICBUaGlzIGRvY3VtZW50 IGV4dGVuZHMNCj4gICB0aGUgTFNBIGZvcm1hdCBieSBlbmNvZGluZyB0aGUgZXhpc3RpbmcgT1NQ RnYzIExTQSBpbmZvcm1hdGlvbiBpbg0KPiAgIFR5cGUtTGVuZ3RoLVZhbHVlIChUTFYpIHR1cGxl cyBhbmQgYWxsb3dpbmcgYWR2ZXJ0aXNlbWVudCBvZg0KPiAgIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gd2l0aCBhZGRpdGlvbmFsIFRMVnMuICBCYWNrd2FyZCBjb21wYXRpYmlsaXR5DQo+ICAgbWVj aGFuaXNtcyBhcmUgYWxzbyBkZXNjcmliZWQuDQo+DQo+ICAgVGhpcyBkb2N1bWVudCB1cGRhdGVz IFJGQyA1MzQwLCAiT1NQRiBmb3IgSVB2NiIsIGFuZCBSRkMgNTgzOCwNCj4gICAiU3VwcG9ydCBv ZiBBZGRyZXNzIEZhbWlsaWVzIGluIE9TUEZ2MyIuDQo+DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vc3BmLW9zcGZ2My1sc2EtZXh0ZW5kLw0KPg0KPlRoZXJl IGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vc3BmLW9zcGZ2My1sc2EtZXh0ZW5kLTIwDQo+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9zcGYtb3NwZnYz LWxzYS1leHRlbmQtMjANCj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtb3NwZi1vc3BmdjMtbHNhLWV4dGVuZC0yMA0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlzc2lv bg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5P U1BGIG1haWxpbmcgbGlzdA0KPk9TUEZAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29zcGYNCg0K From nobody Tue Dec 26 15:56:43 2017 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 B325A124BE8; Tue, 26 Dec 2017 15:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 yElqBr49bzeZ; Tue, 26 Dec 2017 15:56:39 -0800 (PST) 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 099E7120227; Tue, 26 Dec 2017 15:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32807; q=dns/txt; s=iport; t=1514332599; x=1515542199; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TpyBYHzJvSVVNV8DqBx/2y7zMFdg5364fcHHSm7phpM=; b=HYQ4dW/C6mXJcGuekB3FgeQWZjycuAKJcDwwDnm44E+PYEyz/1zB8w7j 77AFDbi/eEwnnrqIJcZWSZ5gNolS5JVykAhfRpQc/JMa1bHWk/aHhv3gY mL0ZwM5bsXRbCy3a8dCBdExT7KSj4PW0i5IlXRLA0UPpxQlnGSMtcW2jy g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AgC14EJa/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRS+BWicHg3+ZOoIBiQeOIoIVAgiFOwIahDpAFwEBAQEBAQE?= =?us-ascii?q?BAWsohSMBAQEBAyNIHgIBCA4DAwECIQcDAgICHxEUCQgCBAESiUpMAxWlewGBN?= =?us-ascii?q?IInhzQNgw4BAQEBAQEBAQIBAQEBAQEBAQEBAR00g1iCEoM+AYMugmtFggUJBga?= =?us-ascii?q?Ca4JlBZlhiS49ApA1hH6CF4YWi1CKVIMOiHQCERkBgTsBIAE3gU9vFT2CKYRXe?= =?us-ascii?q?IkpgRYBAQE?= X-IronPort-AV: E=Sophos; i="5.45,462,1508803200"; d="scan'208,217"; a="49395022" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Dec 2017 23:56:38 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id vBQNubwu014266 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Dec 2017 23:56:37 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Dec 2017 18:56:36 -0500 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.1320.000; Tue, 26 Dec 2017 18:56:36 -0500 From: "Acee Lindem (acee)" To: Alia Atlas , "draft-ietf-ospf-ospfv3-lsa-extend@ietf.org" , OSPF List Thread-Topic: AD review of draft-ietf-ospf-ospfv3-lsa-extend Thread-Index: AQHTeSQE+Az+7DK54E+CppwYGnjEMaNWWACA Date: Tue, 26 Dec 2017 23:56:36 +0000 Message-ID: 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.198] Content-Type: multipart/alternative; boundary="_000_D668482DE6F38aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] AD review of draft-ietf-ospf-ospfv3-lsa-extend X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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, 26 Dec 2017 23:56:42 -0000 --_000_D668482DE6F38aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxpYSwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBJICBiZWxpZXZlIHRoYXQgdGhl IOKAkzIwIHZlcnNpb24gYWRkcmVzc2VzIHRoZW0uIFBsZWFzZSAgc2VlIGlubGluZS4NCg0KRnJv bTogQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29t Pj4NCkRhdGU6IFR1ZXNkYXksIERlY2VtYmVyIDE5LCAyMDE3IGF0IDY6NDkgUE0NClRvOiAiZHJh ZnQtaWV0Zi1vc3BmLW9zcGZ2My1sc2EtZXh0ZW5kQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRm LW9zcGYtb3NwZnYzLWxzYS1leHRlbmRAaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1vc3BmLW9zcGZ2 My1sc2EtZXh0ZW5kQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9zcGYtb3NwZnYzLWxzYS1l eHRlbmRAaWV0Zi5vcmc+PiwgT1NQRiBXRyBMaXN0IDxvc3BmQGlldGYub3JnPG1haWx0bzpvc3Bm QGlldGYub3JnPj4NClN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW9zcGYtb3NwZnYz LWxzYS1leHRlbmQNClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4+DQpSZXNlbnQtVG86IEFjZWUgTGluZGVtIDxhY2VlQGNp c2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+PiwgPGFrckBjaXNjby5jb208bWFpbHRvOmFr ckBjaXNjby5jb20+PiwgIkdvZXRoYWxzLCBEaXJrIChOb2tpYSAtIEJFL0FudHdlcnApIiA8ZGly ay5nb2V0aGFsc0Bub2tpYS5jb208bWFpbHRvOmRpcmsuZ29ldGhhbHNAbm9raWEuY29tPj4sIDx2 YWxsZW0udmVlcmVuZHJhQGdtYWlsLmNvbTxtYWlsdG86dmFsbGVtLnZlZXJlbmRyYUBnbWFpbC5j b20+PiwgRnJlZCBCYWtlciA8ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPG1haWx0bzpmcmVkYmFr ZXIuaWV0ZkBnbWFpbC5jb20+Pg0KUmVzZW50LURhdGU6IFR1ZXNkYXksIERlY2VtYmVyIDE5LCAy MDE3IGF0IDY6NDkgUE0NCg0KQXMgaXMgY3VzdG9tYXJ5LCBJIGhhdmUgZG9uZSBteSBBRCByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1vc3BmLW9zcGZ2My1sc2EtZXh0ZW5kLTE5LiAgRmlyc3QsIEkgd291 bGQgbGlrZSB0byB0aGFuayB0aGUgYXV0aG9ycyAtIEFjZWUsIEFiaGF5LCBEaXJrLCBWZWVyZW5k cmFuYXRoYSwgYW5kIEZyZWQtIGFuZCB0aGUgaW1wbGVtZW50b3JzIGF0IE5va2lhIGFuZCBIdWF3 ZWkgKHdobyBoYXZlIGVuYWJsZWQgdXMgdG8gbW92ZSBmb3J3YXJkIG9uIHRoaXMgY3JpdGljYWwg ZG9jdW1lbnQpIGFuZCB0aGUgV0cuICBUaGlzIGRyYWZ0IGlzIHZlcnkgaW1wb3J0YW50IGZvciBh ZGRpbmcgaW1wcm92ZWQgIGZsZXhpYmxpdHkgdG8gT1NQRnYzIGZvciBJUHY2IGNvbXBhcmVkIHRv IHdoYXQgd2UgZW5qb3kgZm9yIE9TUEZ2Mi4NCg0KSSBkbyBoYXZlIHNvbWUgbWlub3IgY29uY2Vy bnMgYW5kIG5pdHMgLSBhcyBsaXN0ZWQgYmVsb3cuIEkgYW0gZ29pbmcgdG8gcHV0IHRoaXMgZG9j dW1lbnQgaW50byBhIDMgd2VlayBJRVRGIExhc3QgQ2FsbCAoZ2l2ZW4gdGhlIGhvbGlkYXkgc2Vh c29uKSBhbmQgcGxhY2UgaXQgb24gdGhlIHRlbGVjaGF0IGZvciBKYW4gMjUsIDIwMTguICBQbGVh c2UgZG8gcmVzcG9uZCBhbmQgdXBkYXRlIHRoZSBkcmFmdCBpbiBhIHRpbWVseSBmYXNoaW9uIChn aXZlbiBJJ20gb24gdmFjYXRpb24gdW50aWwgMjAxOCkuDQoNCjEpICBHaXZlbiB0aGUgZXh0ZW5z aXZlIGNoYW5nZXMgdG8gT1NQRnYzIGFuZCB0aGUgZXhwZWN0YXRpb24gdGhhdCBpbXBsZW1lbnRh dGlvbnMgb2YgT1NQRnYzIHdpbGwgc3VwcG9ydCB0aGlzLCB0aGUgZHJhZnQgc2hvdWxkIHVwZGF0 ZSBSRkMgNTM0MCAoYW5kIG1lbnRpb24gdGhhdCBpbiB0aGUgYWJzdHJhY3QgYXMgd2VsbCkuDQoN CkkgaGF2ZSBpbmRpY2F0ZWQgdGhhdCB0aGUgZHJhZnQgdXBkYXRlcyBib3RoIFJGQyA1MzQwIGFu ZCBSRkMgNTgzOC4NCg0KMikgSW4gU2VjIDM6IGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gaW5kaWNh dGUgaG93IG1hbnkgbGV2ZWxzIG9mIG5lc3Rpbmcgb2YgVExWcyBhcmUgc3VwcG9ydGVkLiAgVGhl cmUgYXJlIGNsZWFybHkgVExWcyBhbmQgc3ViLVRMVnMuICBDYW4gdGhlcmUgYmUgc3ViLXN1Yi1U TFZzPyAgQ2FuIHRoZXJlIGJlIGFuIGFyYml0cmFyaWx5IGRlZXAgbGV2ZWwgb2Ygc3ViLVRMVnM/ ICBQbGVhc2UganVzdCBjbGFyaWZ5IC0gYi9jIGl0IGNhbiBhZmZlY3QgZm9sa3MgaW1wbGVtZW50 YXRpb25zIGFuZCBhbHNvIGFzc3VtcHRpb25zIGZvciBob3cgdG8gZGVmaW5lIHRoZSB2YXJpb3Vz IHN1Yi1UTFZzLg0KDQpUaGlzIGlzIHJlYWxseSBub3QgYW4gaXNzdWUgYXMgZGVtb25zdHJhdGVk IGJ5IHRoZSBuZXN0aW5nIG9mIFN1Yi1UTFZzIGluIEdNUExTIHRlY2hub2xvZ3kgc3BlY2lmaWMg T1NQRiBURSBMU0FzLiBJIHRoaW5rIGl0IGlzIGEgbWlzdGFrZSB0aGF0IGEgYmlnIGRlYWwgaXMg bWFkZSBvZiB0aGlzIGluIElTLUlTLiBOZXZlcnRoZWxlc3MsIEkgaGF2ZSBhZGRlZDoNCg0KICAg V2hpbGUgdGhpcyBkb2N1bWVudCBvbmx5IGRlc2NyaWJlcyB0aGUgdXNhZ2Ugb2YgVExWcyBhbmQN CiAgIFN1Yi1UTFZzLCBTdWItVExWcyBtYXkgYmUgbmVzdGVkIHRvIGFueSBsZXZlbCBhcyBsb25n IGFzIHRoZSBTdWItVExWcw0KICAgYXJlIGZ1bGx5IHNwZWNpZmllZCBpbiB0aGUgc3BlY2lmaWNh dGlvbiBmb3IgdGhlIHN1YnN1bWluZyBTdWItVExWLg0KDQozKSBTZWMgMy4zOiBJcyB0aGVyZSBh IHJlYXNvbiB0aGF0IHN1Yi1UTFZzIGFyZW4ndCBsaXN0ZWQgaW4gdGhlIGZpZ3VyZT8gIEkgc2Vl IHRoZW0gaW4gdGhlIGZpZ3VyZXMgZm9yIHNlYyAzLjIgYW5kIDMuNCB3aXRob3V0IGV4cGxhbmF0 aW9uLiAgQ29uc2lzdGVuY3kgd291bGQgYmUgZ29vZC4gSSBjb3VsZCBwaWN0dXJlIGl0IGJlaW5n IGhlbHBmdWwgdG8gaW5jbHVkZSwgZm9yIGluc3RhbmNlLCBhbiBTUkxHIG9yIG90aGVyIGluZm9y bWF0aW9uLg0KDQpUaGUgcmVhc29uIHRoYXQgdGhlcmUgYXJlIG5vIFN1Yi1UTFZzIGRlc2NyaWJl ZCwgaXMgdGhhdCBub25lIGFyZSBhbGxvd2VkIGZvciB0aGUgQXR0YWNoZWQtUm91dGVycyBUTFYu IFRoZSByZWFzb25pbmcgZm9yIGlzIGluY2x1ZGVkIGluIHRoZSB0ZXh0Lg0KDQoNCiAgIFRoZXJl IGFyZSB0d28gcmVhc29ucyBmb3Igbm90IGhhdmluZyBhIHNlcGFyYXRlIFRMViBvciBzdWItVExW IGZvcg0KICAgZWFjaCBhZGphY2VudCBuZWlnaGJvci4gIFRoZSBmaXJzdCBpcyB0byBkaXNjb3Vy YWdlIHVzaW5nIHRoZSBFLQ0KICAgTmV0d29yay1MU0EgZm9yIG1vcmUgdGhhbiBpdHMgY3VycmVu dCByb2xlIG9mIHNvbGVseSBhZHZlcnRpc2luZyB0aGUNCiAgIHJvdXRlcnMgYXR0YWNoZWQgdG8g YSBtdWx0aS1hY2Nlc3MgbmV0d29yay4gIFRoZSByb3V0ZXIncyBtZXRyaWMgYXMNCiAgIHdlbGwg YXMgdGhlIGF0dHJpYnV0ZXMgb2YgaW5kaXZpZHVhbCBhdHRhY2hlZCByb3V0ZXJzIHNob3VsZCBi ZQ0KICAgYWR2ZXJ0aXNlZCBpbiB0aGVpciByZXNwZWN0aXZlIEUtUm91dGVyLUxTQXMuICBUaGUg c2Vjb25kIHJlYXNvbiBpcw0KICAgdGhhdCB0aGVyZSBpcyBvbmx5IGEgc2luZ2xlIEUtTmV0d29y ay1MU0EgcGVyIG11bHRpLWFjY2VzcyBsaW5rIHdpdGgNCiAgIHRoZSBMaW5rIFN0YXRlIElEIHNl dCB0byB0aGUgRGVzaWduYXRlZCBSb3V0ZXIncyBJbnRlcmZhY2UgSUQgYW5kLA0KICAgY29uc2Vx dWVudGx5LCBjb21wYWN0IGVuY29kaW5nIGhhcyBiZWVuIGNob3NlbiB0byBkZWNyZWFzZSB0aGUN CiAgIGxpa2VsaWhvb2QgdGhhdCB0aGUgc2l6ZSBvZiB0aGUgRS1OZXR3b3JrLUxTQSB3aWxsIHJl cXVpcmUgSVB2Ng0KICAgZnJhZ21lbnRhdGlvbiB3aGVuIGFkdmVydGlzZWQgaW4gYW4gT1NQRnYz IExpbmsgU3RhdGUgVXBkYXRlIHBhY2tldC4NCg0KDQo0KSBTZWMgNC4xOiBQbGVhc2UgY2xhcmlm eSB3aGV0aGVyIGFuIEUtUm91dGVyLUxTQSBpcyBtYWxmb3JtZWQgaWYgaXQgZG9lcyBub3QgY29u dGFpbiBhdCBsZWFzdCBvbmUgUm91dGVyLUxpbmsgVExWLg0KDQpJIGhhdmUgYWRkZWQgdGhpcy4N Cg0KICAgRGVwZW5kaW5nIG9uIHRoZSBpbXBsZW1lbnRhdGlvbiwgaXQgaXMgcGVyZmVjdGx5IHZh bGlkIGZvciBhbiBFLQ0KICAgUm91dGVyLUxTQSB0byBub3QgY29udGFpbiBhbnkgUm91dGVyLUxp bmsgVExWcy4gIEhvd2V2ZXIsIHRoaXMgd291bGQNCiAgIGltcGx5IHRoYXQgdGhlIE9TUEZ2MyBy b3V0ZXIgZG9lc24ndCBoYXZlIGFueSBhY3RpdmUgaW50ZXJmYWNlcyBpbg0KICAgdGhlIGNvcnJl c3BvbmRpbmcgYXJlYSBhbmQgc3VjaCBFLVJvdXRlci1MU0Egd291bGQgbmV2ZXIgYmUgZmxvb2Rl ZA0KICAgdG8gb3RoZXIgT1NQRnYzIHJvdXRlcnMgaW4gdGhlIGFyZWEuDQoNCg0KNSkgU2VjIDQu NzogSSBiZWxpZXZlIGl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgbXVsdGlwbGUgSVB2NiBsaW5rLWxv Y2FsIGFkZHJlc3Nlcy4gSSBkbyBzZWUgdGhhdCBSRkMgNTM0MCByZXN0cmljdGVkIE9TUEZ2MyB0 byBhZHZlcnRpc2luZyBqdXN0IG9uZS4gIElzIHRoZXJlIGEgc3Ryb25nIHJlYXNvbiB0aGF0IGlm IGFkZGl0aW9uYWwgYXJlIHNlbnQgICJJbnN0YW5jZXMgZm9sbG93aW5nIHRoZSBmaXJzdCBNVVNU IGJlIGlnbm9yZWQuIiA/ICBQZXJoYXBzIHRoaXMgY291bGQgYmUgYSBTSE9VTEQgLSB0byBhbGxv dyBmb3IgZmxleGliaWxpdHk/DQoNCk9rIOKAkyBJIGhhdmUgY2hhbmdlZCB0aGlzIGFsdGhvdWdo IEnigJltIG5vdCBmYW1pbGlhciB3aXRoIHRoZSB1c2UgY2FzZSBmb3IgbXVsdGlwbGVzLg0KDQo2 KSBTZWMgNTogImFuIExTQSBNVVNUIGJlIGNvbnNpZGVyZWQgbWFsZm9ybWVkIGlmIGl0IGRvZXMg bm90IGluY2x1ZGUgYW55IHJlcXVpcmVkIFRMViBvciBTdWItVExWcy4iICBzaG91bGQgYmUgIi4u Lm5vdCBpbmNsdWRlIGFsbCBvZiB0aGUgcmVxdWlyZWQgVExWcyBvciBzdWItVExWcy4iIG9yIHRo ZSBlcXVpdi4NCg0KSSBoYXZlIGZpeGVkIHRoaXMuDQoNCiAgIEFkZGl0aW9uYWxseSwgYW4gTFNB IE1VU1QgYmUgY29uc2lkZXJlZCBtYWxmb3JtZWQgaWYgaXQgZG9lcyBub3QNCiAgIGluY2x1ZGUg YWxsIG9mIHRoZSByZXF1aXJlZCBUTFZzIGFuZCBTdWItVExWcy4NCg0KDQoNCjcpIFNlYyA2LjI6 ICJGdXJ0aGVybW9yZSwgdGhlIGV4dGVuZGVkIExTQXMgd2lsbCBvbmx5IGluY2x1ZGUgdGhvc2Ug VExWcyB3aGljaCByZXF1aXJlIGZ1cnRoZXIgc3BlY2lmaWNhdGlvbiBmb3IgdGhhdCBuZXcgZnVu Y3Rpb25hbGl0eS4gIEhlbmNlLCB0aGlzIG1vZGUgb2YgY29tcGF0aWJpbGl0eSBpcyBrbm93IGFz ICJzcGFyc2UtbW9kZSIuIiAgSG93IGRvZXMgdGhpcyBpbnRlcmFjdCB3aXRoIHRoZSBTZWMgNSB0 aGF0IHRhbGtzIGFib3V0IG1hbGZvcm1lZCBMU0FzPyAgSXQgc2VlbXMgbGlrZSBlaXRoZXIgdGhp cyB3b3VsZCBiZSBhZGRpdGlvbmFsIEV4dGVuZGVkIExTQXMgKG5vdCBkZWZpbmVkIGluIHRoaXMg ZHJhZnQpIG9yIGl0IHdvdWxkIGhhdmUgdG8gaW5jbHVkZSB0aGUgbWFuZGF0b3J5IGluZm9ybWF0 aW9uIChidXQgbm90IGZvciBhbGwgbGlua3MvIHJvdXRlcnMpLg0KDQpJIGhhdmUgY2xhcmlmaWVk IHRoaXMuDQoNCiAgIEZ1cnRoZXJtb3JlLCB0aG9zZSAgZXh0ZW5kZWQgTFNBcyB3aWxsIG9ubHkg aW5jbHVkZSB0aGUgdG9wLWxldmVsIFRMVnMNCiAgIChlLmcuLCBSb3V0ZXItTGluayBUTFZzIG9y IEludGVyLUFyZWEgVExWcykgd2hpY2ggcmVxdWlyZSBmdXJ0aGVyIHNwZWNpZmljYXRpb24NCiAg ICBmb3IgdGhhdCAgbmV3IGZ1bmN0aW9uYWxpdHkuICBIb3dldmVyLCBpZiBhIHRvcC1sZXZlbCBU TFYgaXMgYWR2ZXJ0aXNlZCwgaXQNCiAgIE1VU1QgaW5jbHVkZSByZXF1aXJlZCBTdWItVExWcyBv ciBpdCB3aWxsIGJlIGNvbnNpZGVyZWQgbWFsZm9ybWVkIGFzDQogICBkZXNjcmliZWQgaW4gU2Vj dGlvbiA1Lg0KDQoNCjgpIFNlYyA4LjI6IElzIHRoZXJlIGEgcmVhc29uIHRvIG5vdCBoYXZlIGEg c3ViLVRMViByYW5nZSBmb3IgZWl0aGVyIEV4cGVydCBSZXZpZXcgb3IgRkNGUz8gIFRoZXJlIGFy ZSBhIGxvdCBvZiB2YWx1ZXMgLSBhbmQgdGhpcyB3b3VsZCBzdXBwb3J0IGV4cGVyaW1lbnRhdGlv bi4NCg0KT2sg4oCTIEkgdG9vayB0aGVzZSBmcm9tIHRoZSB1bmFsbG9jYXRlZCByYW5nZSBmb3Ig Ym90aCBUTFZzIGFuZCBTdWItVExWcy4NCg0KICAgVHlwZXMgaW4gdGhlIHJhbmdlIDMzMDI0LTQ1 MDU1IGFyZSB0byBiZSBhc3NpZ25lZCBvbiBhIEZDRlMgYmFzaXMNCiAgIHN1YmplY3QgdG8gSUVU RiBleHBlcnQgcmV2aWV3Lg0KDQoNCjkpIFNpbmNlIHRoaXMgZG9jdW1lbnQgaXMgYWRkaW5nIHRo ZSAiTiIgZmxhZyAtIGFuIGV4YW1wbGUgZm9yIHRoZSB1c2FnZSB3b3VsZCBiZSBoZWxwZnVsIC0g YW5kIHBhcnRpY3VsYXJseSBhcnRpY3VsYXRpbmcgaG93IGl0IGlzIGRpZmZlcmVudCBmcm9tIHRo ZSAiTEEiIGZsYWcgZm9yIHVzYWdlLg0KDQpJIGJlbGlldmUgdGhpcyBpcyBpbiBzZWN0aW9uIDMu MS4xIGFscmVhZHk6DQoNCiAgIFRoZSBOLWJpdCBpcyBzZXQgaW4gUHJlZml4T3B0aW9ucyBmb3Ig YSBob3N0IGFkZHJlc3MNCiAgIChQcmVmaXhMZW5ndGg9MTI4KSB0aGF0IGlkZW50aWZpZXMgdGhl IGFkdmVydGlzaW5nIHJvdXRlci4gIFdoaWxlIGl0DQogICBpcyBzaW1pbGFyIHRvIHRoZSBMQS1i aXQsIHRoZXJlIGFyZSB0d28gZGlmZmVyZW5jZXMuICBUaGUgYWR2ZXJ0aXNpbmcNCiAgIHJvdXRl ciBNQVkgY2hvb3NlIE5PVCB0byBzZXQgdGhlIE4tYml0IGV2ZW4gd2hlbiB0aGUgYWJvdmUgY29u ZGl0aW9ucw0KICAgYXJlIG1ldC4gIElmIHRoZSBOLWJpdCBpcyBzZXQgYW5kIHRoZSBQcmVmaXhM ZW5ndGggaXMgTk9UIDEyOCwgdGhlDQogICBOLWJpdCBNVVNUIGJlIGlnbm9yZWQuICBBZGRpdGlv bmFsbHksIHRoZSBOLWJpdCBpcyBwcm9wYWdhdGVkIGluIHRoZQ0KICAgUHJlZml4T3B0aW9ucyB3 aGVuIGFuIE9TUEZ2MyBBcmVhIEJvcmRlciBSb3V0ZXIgKEFCUikgb3JpZ2luYXRlcyBhbg0KICAg SW50ZXItQXJlYS1QcmVmaXgtTFNBIGZvciBhbiBJbnRyYS1BcmVhIHJvdXRlIHdoaWNoIGhhcyB0 aGUgTi1iaXQgc2V0DQogICBpbiB0aGUgUHJlZml4T3B0aW9ucy4gIFNpbWlsYXJseSwgdGhlIE4t Yml0IGlzIHByb3BhZ2F0ZWQgaW4gdGhlDQogICBQcmVmaXhPcHRpb25zIHdoZW4gYW4gT1NQRnYz IE5TU0EgQUJSIG9yaWdpbmF0ZXMgYW4gRXh0ZW5kZWQtQVMtDQogICBFeHRlcm5hbC1MU0EgY29y cmVzcG9uZGluZyB0byBhbiBOU1NBIHJvdXRlIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMNCiAg IG9mIFJGQyAzMTAxIChbTlNTQV0pLiAgVGhlIE4tYml0IGlzIGFkZGVkIHRvIHRoZSBJbnRlci1B cmVhLVByZWZpeC0NCiAgIFRMViAoU2VjdGlvbiAzLjQpLCBFeHRlcm5hbC1QcmVmaXgtVExWIChT ZWN0aW9uIDMuNiksIGFuZCBJbnRyYS1BcmVhLQ0KICAgUHJlZml4LVRMViAoU2VjdGlvbiAzLjcp LiAgVGhlIE4tYml0IGlzIHVzZWZ1bCBmb3IgYXBwbGljYXRpb25zIHN1Y2gNCiAgIGFzIGlkZW50 aWZ5aW5nIHRoZSBwcmVmaXhlcyBjb3JyZXNwb25kaW5nIHRvIE5vZGUgU2VnbWVudCBJZGVudGlm aWVycw0KICAgKFNJRHMpIGluIFNlZ21lbnQgUm91dGluZyBbU0VHTUVOVC1ST1VUSU5HXS4NCg0K DQpOaXRzOg0KDQphKSBTZWMgMy4xLjE6ICBzZW50ZW5jZSBtaXNzaW5nIGEgY29tcGxldGUgdmVy YiAgIlRoZSBOLWJpdCBpcyB0byB0aGUgSW50ZXItQXJlYS1QcmVmaXgtVExWICAgKFNlY3Rpb24g My40KSwgRXh0ZXJuYWwtUHJlZml4LVRMViAoU2VjdGlvbiAzLjYpLCBhbmQgSW50cmEtQXJlYS0N CiAgIFByZWZpeC1UTFYgKFNlY3Rpb24gMy43KSINCmIpIHR5cG9zOiBkaWZmZXJudCAgYWRkdGlv bmFsDQoNCkZpeGVkLg0KDQpUaGFua3MsDQpBY2VlDQoNCg0KUmVnYXJkcywNCkFsaWENCg== --_000_D668482DE6F38aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <24A22BD11D303048BFF49CEFF6880043@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K SGkgQWxpYSwmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KVGhhbmtzIGZvciB5b3VyIGNv bW1lbnRzLiBJICZuYnNwO2JlbGlldmUgdGhhdCB0aGUg4oCTMjAgdmVyc2lvbiBhZGRyZXNzZXMg dGhlbS4gUGxlYXNlICZuYnNwO3NlZSBpbmxpbmUuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JE RVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5H LUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JE RVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFE RElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9z cGFuPkFsaWEgQXRsYXMgJmx0OzxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+YWth dGxhc0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5EYXRlOiA8L3NwYW4+VHVlc2RheSwgRGVjZW1iZXIgMTksIDIwMTcgYXQgNjo0OSBQTTxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9 Im1haWx0bzpkcmFmdC1pZXRmLW9zcGYtb3NwZnYzLWxzYS1leHRlbmRAaWV0Zi5vcmciPmRyYWZ0 LWlldGYtb3NwZi1vc3BmdjMtbHNhLWV4dGVuZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9zcGYtb3NwZnYzLWxzYS1leHRlbmRAaWV0Zi5vcmciPmRy YWZ0LWlldGYtb3NwZi1vc3BmdjMtbHNhLWV4dGVuZEBpZXRmLm9yZzwvYT4mZ3Q7LA0KIE9TUEYg V0cgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9zcGZAaWV0Zi5vcmciPm9zcGZAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3Nw YW4+QUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3NwZi1vc3BmdjMtbHNhLWV4dGVuZDxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5SZXNlbnQtRnJvbTogPC9zcGFuPiZsdDs8YSBo cmVmPSJtYWlsdG86YWxpYXMtYm91bmNlc0BpZXRmLm9yZyI+YWxpYXMtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlJlc2VudC1Ubzog PC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFj ZWVAY2lzY28uY29tPC9hPiZndDssICZsdDs8YSBocmVmPSJtYWlsdG86YWtyQGNpc2NvLmNvbSI+ YWtyQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDtHb2V0aGFscywgRGlyayAoTm9raWEgLSBCRS9B bnR3ZXJwKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpcmsuZ29ldGhhbHNAbm9raWEuY29t Ij5kaXJrLmdvZXRoYWxzQG5va2lhLmNvbTwvYT4mZ3Q7LA0KICZsdDs8YSBocmVmPSJtYWlsdG86 dmFsbGVtLnZlZXJlbmRyYUBnbWFpbC5jb20iPnZhbGxlbS52ZWVyZW5kcmFAZ21haWwuY29tPC9h PiZndDssIEZyZWQgQmFrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVkYmFrZXIuaWV0ZkBnbWFp bC5jb20iPmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlJlc2VudC1EYXRlOiA8L3NwYW4+VHVlc2RheSwgRGVjZW1iZXIg MTksIDIwMTcgYXQgNjo0OSBQTTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9S REVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAg NTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5BcyBpcyBjdXN0b21hcnksIEkgaGF2 ZSBkb25lIG15IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW9zcGYtb3NwZnYzLWxzYS1leHRlbmQt MTkuJm5ic3A7IEZpcnN0LCBJIHdvdWxkIGxpa2UgdG8gdGhhbmsgdGhlIGF1dGhvcnMgLSBBY2Vl LCBBYmhheSwgRGlyaywgVmVlcmVuZHJhbmF0aGEsIGFuZCBGcmVkLSBhbmQgdGhlIGltcGxlbWVu dG9ycyBhdCBOb2tpYSBhbmQgSHVhd2VpICh3aG8gaGF2ZSBlbmFibGVkIHVzIHRvIG1vdmUNCiBm b3J3YXJkIG9uIHRoaXMgY3JpdGljYWwgZG9jdW1lbnQpIGFuZCB0aGUgV0cuJm5ic3A7IFRoaXMg ZHJhZnQgaXMgdmVyeSBpbXBvcnRhbnQgZm9yIGFkZGluZyBpbXByb3ZlZCZuYnNwOyBmbGV4aWJs aXR5IHRvIE9TUEZ2MyBmb3IgSVB2NiBjb21wYXJlZCB0byB3aGF0IHdlIGVuam95IGZvciBPU1BG djIuDQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBkbyBoYXZlIHNvbWUgbWlub3Ig Y29uY2VybnMgYW5kIG5pdHMgLSBhcyBsaXN0ZWQgYmVsb3cuIEkgYW0gZ29pbmcgdG8gcHV0IHRo aXMgZG9jdW1lbnQgaW50byBhIDMgd2VlayBJRVRGIExhc3QgQ2FsbCAoZ2l2ZW4gdGhlIGhvbGlk YXkgc2Vhc29uKSBhbmQgcGxhY2UgaXQgb24gdGhlIHRlbGVjaGF0IGZvciBKYW4gMjUsIDIwMTgu Jm5ic3A7IFBsZWFzZSBkbyByZXNwb25kIGFuZCB1cGRhdGUgdGhlIGRyYWZ0IGluIGEgdGltZWx5 IGZhc2hpb24NCiAoZ2l2ZW4gSSdtIG9uIHZhY2F0aW9uIHVudGlsIDIwMTgpLjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+MSkmbmJzcDsgR2l2ZW4gdGhlIGV4dGVuc2l2ZSBjaGFuZ2Vz IHRvIE9TUEZ2MyBhbmQgdGhlIGV4cGVjdGF0aW9uIHRoYXQgaW1wbGVtZW50YXRpb25zIG9mIE9T UEZ2MyB3aWxsIHN1cHBvcnQgdGhpcywgdGhlIGRyYWZ0IHNob3VsZCB1cGRhdGUgUkZDIDUzNDAg KGFuZCBtZW50aW9uIHRoYXQgaW4gdGhlIGFic3RyYWN0IGFzIHdlbGwpLjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij4NCkkgaGF2ZSBpbmRpY2F0ZWQgdGhhdCB0aGUgZHJhZnQgdXBkYXRlcyBib3RoIFJG QyA1MzQwIGFuZCBSRkMgNTgzOC48L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP TiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19B VFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xp ZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IGRpcj0ibHRyIj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4yKSBJbiBTZWMgMzog aXQgd291bGQgYmUgaGVscGZ1bCB0byBpbmRpY2F0ZSBob3cgbWFueSBsZXZlbHMgb2YgbmVzdGlu ZyBvZiBUTFZzIGFyZSBzdXBwb3J0ZWQuJm5ic3A7IFRoZXJlIGFyZSBjbGVhcmx5IFRMVnMgYW5k IHN1Yi1UTFZzLiZuYnNwOyBDYW4gdGhlcmUgYmUgc3ViLXN1Yi1UTFZzPyZuYnNwOyBDYW4gdGhl cmUgYmUgYW4gYXJiaXRyYXJpbHkgZGVlcCBsZXZlbCBvZiBzdWItVExWcz8mbmJzcDsgUGxlYXNl IGp1c3QgY2xhcmlmeSAtIGIvYyBpdCBjYW4gYWZmZWN0DQogZm9sa3MgaW1wbGVtZW50YXRpb25z IGFuZCBhbHNvIGFzc3VtcHRpb25zIGZvciBob3cgdG8gZGVmaW5lIHRoZSB2YXJpb3VzIHN1Yi1U TFZzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L3NwYW4+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NClRoaXMgaXMgcmVhbGx5IG5vdCBhbiBpc3N1ZSBh cyBkZW1vbnN0cmF0ZWQgYnkgdGhlIG5lc3Rpbmcgb2YgU3ViLVRMVnMgaW4gR01QTFMgdGVjaG5v bG9neSBzcGVjaWZpYyBPU1BGIFRFIExTQXMuIEkgdGhpbmsgaXQgaXMgYSBtaXN0YWtlIHRoYXQg YSBiaWcgZGVhbCBpcyBtYWRlIG9mIHRoaXMgaW4gSVMtSVMuIE5ldmVydGhlbGVzcywgSSBoYXZl IGFkZGVkOjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDtXaGlsZSB0aGlzIGRvY3VtZW50IG9ubHkgZGVzY3JpYmVzIHRoZSB1c2FnZSBvZiBUTFZzIGFu ZDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7U3ViLVRMVnMsIFN1Yi1UTFZzIG1heSBiZSBuZXN0ZWQgdG8gYW55IGxldmVsIGFz IGxvbmcgYXMgdGhlIFN1Yi1UTFZzPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDthcmUgZnVsbHkgc3BlY2lmaWVkIGluIHRoZSBz cGVjaWZpY2F0aW9uIGZvciB0aGUgc3Vic3VtaW5nIFN1Yi1UTFYuPC9mb250PjwvZGl2Pg0KPC9k aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4 OyI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIg c3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFS R0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+MykgU2VjIDMuMzogSXMgdGhlcmUgYSByZWFzb24gdGhhdCBz dWItVExWcyBhcmVuJ3QgbGlzdGVkIGluIHRoZSBmaWd1cmU/Jm5ic3A7IEkgc2VlIHRoZW0gaW4g dGhlIGZpZ3VyZXMgZm9yIHNlYyAzLjIgYW5kIDMuNCB3aXRob3V0IGV4cGxhbmF0aW9uLiZuYnNw OyBDb25zaXN0ZW5jeSB3b3VsZCBiZSBnb29kLiBJIGNvdWxkIHBpY3R1cmUgaXQgYmVpbmcgaGVs cGZ1bCB0byBpbmNsdWRlLCBmb3IgaW5zdGFuY2UsIGFuIFNSTEcgb3Igb3RoZXIgaW5mb3JtYXRp b24uPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N Cjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSByZWFzb24gdGhhdCB0aGVyZSBh cmUgbm8gU3ViLVRMVnMgZGVzY3JpYmVkLCBpcyB0aGF0IG5vbmUgYXJlIGFsbG93ZWQgZm9yIHRo ZSBBdHRhY2hlZC1Sb3V0ZXJzIFRMVi4gVGhlIHJlYXNvbmluZyBmb3IgaXMgaW5jbHVkZWQgaW4g dGhlIHRleHQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtUaGVyZSBhcmUgdHdvIHJlYXNvbnMgZm9yIG5v dCBoYXZpbmcgYSBzZXBhcmF0ZSBUTFYgb3Igc3ViLVRMViBmb3I8L2Rpdj4NCjxkaXY+Jm5ic3A7 ICZuYnNwO2VhY2ggYWRqYWNlbnQgbmVpZ2hib3IuICZuYnNwO1RoZSBmaXJzdCBpcyB0byBkaXNj b3VyYWdlIHVzaW5nIHRoZSBFLTwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7TmV0d29yay1MU0Eg Zm9yIG1vcmUgdGhhbiBpdHMgY3VycmVudCByb2xlIG9mIHNvbGVseSBhZHZlcnRpc2luZyB0aGU8 L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO3JvdXRlcnMgYXR0YWNoZWQgdG8gYSBtdWx0aS1hY2Nl c3MgbmV0d29yay4gJm5ic3A7VGhlIHJvdXRlcidzIG1ldHJpYyBhczwvZGl2Pg0KPGRpdj4mbmJz cDsgJm5ic3A7d2VsbCBhcyB0aGUgYXR0cmlidXRlcyBvZiBpbmRpdmlkdWFsIGF0dGFjaGVkIHJv dXRlcnMgc2hvdWxkIGJlPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDthZHZlcnRpc2VkIGluIHRo ZWlyIHJlc3BlY3RpdmUgRS1Sb3V0ZXItTFNBcy4gJm5ic3A7VGhlIHNlY29uZCByZWFzb24gaXM8 L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO3RoYXQgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBFLU5l dHdvcmstTFNBIHBlciBtdWx0aS1hY2Nlc3MgbGluayB3aXRoPC9kaXY+DQo8ZGl2PiZuYnNwOyAm bmJzcDt0aGUgTGluayBTdGF0ZSBJRCBzZXQgdG8gdGhlIERlc2lnbmF0ZWQgUm91dGVyJ3MgSW50 ZXJmYWNlIElEIGFuZCw8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO2NvbnNlcXVlbnRseSwgY29t cGFjdCBlbmNvZGluZyBoYXMgYmVlbiBjaG9zZW4gdG8gZGVjcmVhc2UgdGhlPC9kaXY+DQo8ZGl2 PiZuYnNwOyAmbmJzcDtsaWtlbGlob29kIHRoYXQgdGhlIHNpemUgb2YgdGhlIEUtTmV0d29yay1M U0Egd2lsbCByZXF1aXJlIElQdjY8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO2ZyYWdtZW50YXRp b24gd2hlbiBhZHZlcnRpc2VkIGluIGFuIE9TUEZ2MyBMaW5rIFN0YXRlIFVwZGF0ZSBwYWNrZXQu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09V VExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRm IDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+NCkgU2Vj IDQuMTogUGxlYXNlIGNsYXJpZnkgd2hldGhlciBhbiBFLVJvdXRlci1MU0EgaXMgbWFsZm9ybWVk IGlmIGl0IGRvZXMgbm90IGNvbnRhaW4gYXQgbGVhc3Qgb25lIFJvdXRlci1MaW5rIFRMVi48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFu Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBoYXZlIGFkZGVkIHRoaXMuJm5ic3A7PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO0RlcGVuZGluZyBv biB0aGUgaW1wbGVtZW50YXRpb24sIGl0IGlzIHBlcmZlY3RseSB2YWxpZCBmb3IgYW4gRS08L2Rp dj4NCjxkaXY+Jm5ic3A7ICZuYnNwO1JvdXRlci1MU0EgdG8gbm90IGNvbnRhaW4gYW55IFJvdXRl ci1MaW5rIFRMVnMuICZuYnNwO0hvd2V2ZXIsIHRoaXMgd291bGQ8L2Rpdj4NCjxkaXY+Jm5ic3A7 ICZuYnNwO2ltcGx5IHRoYXQgdGhlIE9TUEZ2MyByb3V0ZXIgZG9lc24ndCBoYXZlIGFueSBhY3Rp dmUgaW50ZXJmYWNlcyBpbjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7dGhlIGNvcnJlc3BvbmRp bmcgYXJlYSBhbmQgc3VjaCBFLVJvdXRlci1MU0Egd291bGQgbmV2ZXIgYmUgZmxvb2RlZDwvZGl2 Pg0KPGRpdj4mbmJzcDsgJm5ic3A7dG8gb3RoZXIgT1NQRnYzIHJvdXRlcnMgaW4gdGhlIGFyZWEu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09V VExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRm IDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+NSkgU2Vj IDQuNzogSSBiZWxpZXZlIGl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgbXVsdGlwbGUgSVB2NiBsaW5r LWxvY2FsIGFkZHJlc3Nlcy4gSSBkbyBzZWUgdGhhdCBSRkMgNTM0MCByZXN0cmljdGVkIE9TUEZ2 MyB0byBhZHZlcnRpc2luZyBqdXN0IG9uZS4mbmJzcDsgSXMgdGhlcmUgYSBzdHJvbmcgcmVhc29u IHRoYXQgaWYgYWRkaXRpb25hbCBhcmUgc2VudCZuYnNwOyAmcXVvdDtJbnN0YW5jZXMgZm9sbG93 aW5nIHRoZSBmaXJzdCBNVVNUIGJlIGlnbm9yZWQuJnF1b3Q7ID8mbmJzcDsNCiBQZXJoYXBzIHRo aXMgY291bGQgYmUgYSBTSE9VTEQgLSB0byBhbGxvdyBmb3IgZmxleGliaWxpdHk/PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk9rIOKAkyBJIGhhdmUgY2hhbmdlZCB0aGlzIGFsdGhvdWdo IEnigJltIG5vdCBmYW1pbGlhciB3aXRoIHRoZSB1c2UgY2FzZSBmb3IgbXVsdGlwbGVzLiAmbmJz cDs8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FV T1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1 OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj42KSBTZWMgNTogJnF1b3Q7YW4gTFNBIE1VU1QgYmUg Y29uc2lkZXJlZCBtYWxmb3JtZWQgaWYgaXQgZG9lcyBub3QgaW5jbHVkZSBhbnkgcmVxdWlyZWQg VExWIG9yIFN1Yi1UTFZzLiZxdW90OyZuYnNwOyBzaG91bGQgYmUgJnF1b3Q7Li4ubm90IGluY2x1 ZGUgYWxsIG9mIHRoZSByZXF1aXJlZCBUTFZzIG9yIHN1Yi1UTFZzLiZxdW90OyBvciB0aGUgZXF1 aXYuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N Cjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgaGF2ZSBmaXhlZCB0aGlzLiZuYnNw OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtBZGRp dGlvbmFsbHksIGFuIExTQSBNVVNUIGJlIGNvbnNpZGVyZWQgbWFsZm9ybWVkIGlmIGl0IGRvZXMg bm90PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtpbmNsdWRlIGFsbCBvZiB0aGUgcmVxdWlyZWQg VExWcyBhbmQgU3ViLVRMVnMuPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bh biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Ymxv Y2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJP UkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAw IDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjcpIFNlYyA2LjI6Jm5ic3A7JnF1b3Q7RnVy dGhlcm1vcmUsIHRoZSZuYnNwO2V4dGVuZGVkIExTQXMgd2lsbCBvbmx5IGluY2x1ZGUgdGhvc2Ug VExWcyB3aGljaCByZXF1aXJlIGZ1cnRoZXImbmJzcDtzcGVjaWZpY2F0aW9uIGZvciB0aGF0IG5l dyBmdW5jdGlvbmFsaXR5LiZuYnNwOyBIZW5jZSwgdGhpcyBtb2RlIG9mIGNvbXBhdGliaWxpdHkg aXMga25vdyBhcyAmcXVvdDtzcGFyc2UtbW9kZSZxdW90Oy4mcXVvdDsmbmJzcDsgSG93IGRvZXMg dGhpcyBpbnRlcmFjdCB3aXRoIHRoZSBTZWMgNSB0aGF0IHRhbGtzIGFib3V0DQogbWFsZm9ybWVk IExTQXM/Jm5ic3A7IEl0IHNlZW1zIGxpa2UgZWl0aGVyIHRoaXMgd291bGQgYmUgYWRkaXRpb25h bCBFeHRlbmRlZCBMU0FzIChub3QgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0KSBvciBpdCB3b3VsZCBo YXZlIHRvIGluY2x1ZGUgdGhlIG1hbmRhdG9yeSBpbmZvcm1hdGlvbiAoYnV0IG5vdCBmb3IgYWxs IGxpbmtzLyByb3V0ZXJzKS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBoYXZlIGNs YXJpZmllZCB0aGlzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PiZuYnNw OyAmbmJzcDtGdXJ0aGVybW9yZSwgdGhvc2UgJm5ic3A7ZXh0ZW5kZWQgTFNBcyB3aWxsIG9ubHkg aW5jbHVkZSB0aGUgdG9wLWxldmVsIFRMVnMmbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNw OyhlLmcuLCBSb3V0ZXItTGluayBUTFZzIG9yIEludGVyLUFyZWEgVExWcykgd2hpY2ggcmVxdWly ZSBmdXJ0aGVyIHNwZWNpZmljYXRpb248L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyBmb3IgdGhh dCAmbmJzcDtuZXcgZnVuY3Rpb25hbGl0eS4gJm5ic3A7SG93ZXZlciwgaWYgYSB0b3AtbGV2ZWwg VExWIGlzIGFkdmVydGlzZWQsIGl0PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtNVVNUIGluY2x1 ZGUgcmVxdWlyZWQgU3ViLVRMVnMgb3IgaXQgd2lsbCBiZSBjb25zaWRlcmVkIG1hbGZvcm1lZCBh czwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4mbmJzcDs8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VU TE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYg NSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj44KSBTZWMg OC4yOiBJcyB0aGVyZSBhIHJlYXNvbiB0byBub3QgaGF2ZSBhIHN1Yi1UTFYgcmFuZ2UgZm9yIGVp dGhlciBFeHBlcnQgUmV2aWV3IG9yIEZDRlM/Jm5ic3A7IFRoZXJlIGFyZSBhIGxvdCBvZiB2YWx1 ZXMgLSBhbmQgdGhpcyB3b3VsZCBzdXBwb3J0IGV4cGVyaW1lbnRhdGlvbi48L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+T2sg4oCTIEkgdG9vayB0aGVzZSBmcm9tIHRoZSB1bmFsbG9jYXRl ZCByYW5nZSBmb3IgYm90aCBUTFZzIGFuZCBTdWItVExWcy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7VHlwZXMgaW4gdGhlIHJhbmdlIDMz MDI0LTQ1MDU1IGFyZSB0byBiZSBhc3NpZ25lZCBvbiBhIEZDRlMgYmFzaXM8L2Rpdj4NCjxkaXY+ Jm5ic3A7ICZuYnNwO3N1YmplY3QgdG8gSUVURiBleHBlcnQgcmV2aWV3LjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURE SU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjkpIFNpbmNlIHRoaXMgZG9jdW1l bnQgaXMgYWRkaW5nIHRoZSAmcXVvdDtOJnF1b3Q7IGZsYWcgLSBhbiBleGFtcGxlIGZvciB0aGUg dXNhZ2Ugd291bGQgYmUgaGVscGZ1bCAtIGFuZCBwYXJ0aWN1bGFybHkgYXJ0aWN1bGF0aW5nIGhv dyBpdCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgJnF1b3Q7TEEmcXVvdDsgZmxhZyBmb3IgdXNhZ2Uu PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv c3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYmVsaWV2ZSB0aGlzIGlzIGluIHNlY3Rp b24gMy4xLjEgYWxyZWFkeTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4m bmJzcDsgJm5ic3A7VGhlIE4tYml0IGlzIHNldCBpbiBQcmVmaXhPcHRpb25zIGZvciBhIGhvc3Qg YWRkcmVzczwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7KFByZWZpeExlbmd0aD0xMjgpIHRoYXQg aWRlbnRpZmllcyB0aGUgYWR2ZXJ0aXNpbmcgcm91dGVyLiAmbmJzcDtXaGlsZSBpdDwvZGl2Pg0K PGRpdj4mbmJzcDsgJm5ic3A7aXMgc2ltaWxhciB0byB0aGUgTEEtYml0LCB0aGVyZSBhcmUgdHdv IGRpZmZlcmVuY2VzLiAmbmJzcDtUaGUgYWR2ZXJ0aXNpbmc8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZu YnNwO3JvdXRlciBNQVkgY2hvb3NlIE5PVCB0byBzZXQgdGhlIE4tYml0IGV2ZW4gd2hlbiB0aGUg YWJvdmUgY29uZGl0aW9uczwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7YXJlIG1ldC4gJm5ic3A7 SWYgdGhlIE4tYml0IGlzIHNldCBhbmQgdGhlIFByZWZpeExlbmd0aCBpcyBOT1QgMTI4LCB0aGU8 L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO04tYml0IE1VU1QgYmUgaWdub3JlZC4gJm5ic3A7QWRk aXRpb25hbGx5LCB0aGUgTi1iaXQgaXMgcHJvcGFnYXRlZCBpbiB0aGU8L2Rpdj4NCjxkaXY+Jm5i c3A7ICZuYnNwO1ByZWZpeE9wdGlvbnMgd2hlbiBhbiBPU1BGdjMgQXJlYSBCb3JkZXIgUm91dGVy IChBQlIpIG9yaWdpbmF0ZXMgYW48L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO0ludGVyLUFyZWEt UHJlZml4LUxTQSBmb3IgYW4gSW50cmEtQXJlYSByb3V0ZSB3aGljaCBoYXMgdGhlIE4tYml0IHNl dDwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7aW4gdGhlIFByZWZpeE9wdGlvbnMuICZuYnNwO1Np bWlsYXJseSwgdGhlIE4tYml0IGlzIHByb3BhZ2F0ZWQgaW4gdGhlPC9kaXY+DQo8ZGl2PiZuYnNw OyAmbmJzcDtQcmVmaXhPcHRpb25zIHdoZW4gYW4gT1NQRnYzIE5TU0EgQUJSIG9yaWdpbmF0ZXMg YW4gRXh0ZW5kZWQtQVMtPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtFeHRlcm5hbC1MU0EgY29y cmVzcG9uZGluZyB0byBhbiBOU1NBIHJvdXRlIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDM8L2Rp dj4NCjxkaXY+Jm5ic3A7ICZuYnNwO29mIFJGQyAzMTAxIChbTlNTQV0pLiAmbmJzcDtUaGUgTi1i aXQgaXMgYWRkZWQgdG8gdGhlIEludGVyLUFyZWEtUHJlZml4LTwvZGl2Pg0KPGRpdj4mbmJzcDsg Jm5ic3A7VExWIChTZWN0aW9uIDMuNCksIEV4dGVybmFsLVByZWZpeC1UTFYgKFNlY3Rpb24gMy42 KSwgYW5kIEludHJhLUFyZWEtPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtQcmVmaXgtVExWIChT ZWN0aW9uIDMuNykuICZuYnNwO1RoZSBOLWJpdCBpcyB1c2VmdWwgZm9yIGFwcGxpY2F0aW9ucyBz dWNoPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDthcyBpZGVudGlmeWluZyB0aGUgcHJlZml4ZXMg Y29ycmVzcG9uZGluZyB0byBOb2RlIFNlZ21lbnQgSWRlbnRpZmllcnM8L2Rpdj4NCjxkaXY+Jm5i c3A7ICZuYnNwOyhTSURzKSBpbiBTZWdtZW50IFJvdXRpbmcgW1NFR01FTlQtUk9VVElOR10uPC9k aXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NF Q1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Tml0czo8L2Rp dj4NCjxicj4NCmEpIFNlYyAzLjEuMTogJm5ic3A7c2VudGVuY2UgbWlzc2luZyBhIGNvbXBsZXRl IHZlcmIgJm5ic3A7JnF1b3Q7VGhlIE4tYml0IGlzIHRvIHRoZSBJbnRlci1BcmVhLVByZWZpeC1U TFYmbmJzcDsgJm5ic3A7KFNlY3Rpb24gMy40KSwgRXh0ZXJuYWwtUHJlZml4LVRMViAoU2VjdGlv biAzLjYpLCBhbmQgSW50cmEtQXJlYS08YnI+DQombmJzcDsgJm5ic3A7UHJlZml4LVRMViAoU2Vj dGlvbiAzLjcpJnF1b3Q7PGJyPg0KYikgdHlwb3M6IGRpZmZlcm50ICZuYnNwO2FkZHRpb25hbDwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+Rml4ZWQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWU8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxibG9ja3F1b3RlIGlkPSJN QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNi NWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpB bGlhPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D668482DE6F38aceeciscocom_-- From nobody Wed Dec 27 09:45:06 2017 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 9F62D1270FC; Wed, 27 Dec 2017 09:45:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ospf@ietf.org, acee@cisco.com, ospf-chairs@ietf.org, akatlas@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151439670460.29721.11208577911942463924.idtracker@ietfa.amsl.com> Date: Wed, 27 Dec 2017 09:45:04 -0800 Archived-At: Subject: [OSPF] ospf - New Meeting Session Request for IETF 101 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 17:45:05 -0000 A new meeting session request has just been submitted by Acee Lindem, a Chair of the ospf working group. --------------------------------------------------------- Working Group Name: Open Shortest Path First IGP Area Name: Routing Area Session Requester: Acee Lindem Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: idr rtgwg dcrouting Second Priority: spring bess netmod People who must be present: Acee Lindem Abhay Roy Alia Atlas Resources Requested: Special Requests: This 2.5 hour session is a joint meeting with IS-IS so they must be scheduled in the same time slot and room. --------------------------------------------------------- From nobody Thu Dec 28 12:33:14 2017 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 9023C126DCA; Thu, 28 Dec 2017 12:33:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151449318857.3102.6921937119521632539@ietfa.amsl.com> Date: Thu, 28 Dec 2017 12:33:08 -0800 Archived-At: Subject: [OSPF] I-D Action: draft-ietf-ospf-sr-yang-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 20:33:08 -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 WG of the IETF. Title : Yang Data Model for OSPF SR (Segment Routing) Protocol Authors : Derek Yeung Yingzhen Qu Jeffrey Zhang Ing-Wher Chen Acee Lindem Filename : draft-ietf-ospf-sr-yang-03.txt Pages : 24 Date : 2017-12-28 Abstract: This document defines a YANG data model that can be used to configure and manage OSPF Segment Routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-sr-yang-03 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-sr-yang-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-sr-yang-03 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/