From nobody Sat Jul 1 13:34:27 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D1A129AE3; Sat, 1 Jul 2017 13:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Q1KO-Wd0hbbo; Sat, 1 Jul 2017 13:34:12 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE11126B7E; Sat, 1 Jul 2017 13:34:12 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id b40so12674142qtb.2; Sat, 01 Jul 2017 13:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc:message-id :references:to; bh=HNcbrU4LQZJstVWyH4j+2BBBoc/yc7RmD4A12btjrUo=; b=h2l2z3y2bgK15c79sjRFIKXKwzeG9DbynnD8PqzJz+FHdN951MIkQGAoUxOAOOpcho XMFZbDyyGWHQzIesHnHAz6NBaJOnd/khSjD6GIQmGnU2dHRR69aHeOc5gvseo5eKLoW9 KR/U1bRVzFpVd0op1fkSxXMQvd23h4jFPbusnI3p+oktnc63BKn/iuxaEBzmiKMshNRX 4u0DmPuWA2+H+4V/uFu4Rw0Iga/+o73VVIdWR/+sJxfgteKtJjv6cOC4vIH2fifPzTy0 1Q8PFQpO671xVE2GRY94/yVIBiya1Ee5uSm9CMMdijX63k/655VS1un0WrasoO8psGil Jy5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=HNcbrU4LQZJstVWyH4j+2BBBoc/yc7RmD4A12btjrUo=; b=cBXDcIm6NmHCYlVdobxVAKqXpgWomfk3cMLVvDVqaVMX1h345PzNbVEp4YI61c+DYI 3GzR3mG2rEEQb764XUpUr+ur/U7BBO2LAwRvAq1ROP8QyvG4Bqs1uxLs2HFsHaVtQINX AEGUR2MaHFtEQHM+CbmDFFS5l+SzrjNmDE3UfMPfk6uJrzPWCoVL85SzrUtMURC4e/JY v3V+wE+HcnlSPJDKr0fT939RUgTV03rLi3/enu6KiW6CBGT5HfrvABcRvgqCI1mqPCPW +k/QtfiD4pNUN7tAJt7Zw+AkJ8BWLII+6ZhBK74gWcoMWFoyQVPKHwz7ZX5ywmtVH0QZ sGbw== X-Gm-Message-State: AKS2vOwx+Lyb28MaFQeASL7w0UJzeUYqsve0s1NKCBe10mSiN5J+bz8G jQR5SGZfii5xJg== X-Received: by 10.200.10.202 with SMTP id g10mr23016306qti.227.1498941251525; Sat, 01 Jul 2017 13:34:11 -0700 (PDT) Received: from ?IPv6:2602:306:ccb0:73f9:cca:31e4:cb2c:2296? ([2602:306:ccb0:73f9:cca:31e4:cb2c:2296]) by smtp.gmail.com with ESMTPSA id i29sm9859202qkh.4.2017.07.01.13.34.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Jul 2017 13:34:11 -0700 (PDT) Sender: Carlos Pignataro Content-Type: multipart/alternative; boundary="Apple-Mail=_19DAFABE-315A-4752-9B34-E3D98391E727" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carlos Pignataro In-Reply-To: <28678_1498828104_59564D48_28678_291_3_53C29892C857584299CBF5D05346208A477E0608@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Sat, 1 Jul 2017 16:34:10 -0400 Cc: "Ruediger.Geib@telekom.de" , Alvaro Retana , "spring-chairs@ietf.org" , "spring@ietf.org" , "draft-ietf-spring-oam-usecase@ietf.org" X-Mao-Original-Outgoing-Id: 520633588.796231-dae715229c5318bfd9a7a306fc2feeee Message-Id: <0EA75BE5-D812-46E8-ABD6-C36E5190708D@cisco.com> References: <28678_1498828104_59564D48_28678_291_3_53C29892C857584299CBF5D05346208A477E0608@OPEXCLILM21.corporate.adroot.infra.ftgroup> To: Bruno Decraene X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [spring] AD Review of draft-ietf-spring-oam-usecase-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 20:34:17 -0000 --Apple-Mail=_19DAFABE-315A-4752-9B34-E3D98391E727 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Many thanks for your detailed review, Alvaro! Alvaro, Bruno, Please find inline a couple additional comments (also marked =E2=80=9CED=E2= =80=9D) in addition to the editor comments on Ruediger=E2=80=99s = response. > On Jun 30, 2017, at 9:08 AM, bruno.decraene@orange.com = wrote: >=20 > Hi Ruediger, > =20 > Please see inline [Bruno] > =20 > From: Ruediger.Geib@telekom.de = [mailto:Ruediger.Geib@telekom.de ]=20 > Sent: Monday, June 26, 2017 8:52 AM > To: aretana@cisco.com > Cc: spring-chairs@ietf.org ; DECRAENE = Bruno IMT/OLN; spring@ietf.org ; = draft-ietf-spring-oam-usecase@ietf.org = > Subject: AW: AD Review of draft-ietf-spring-oam-usecase-06 > =20 > Hi Alvaro, > =20 > we are fine, hope you are too - thanks for your review and comments. = As we work with two editors, our comments are marked [ED]. > =20 > =20 > [AR] Major: > =20 > [AR] M1. The Introduction says that the monitoring system described in = this document will be simplified =E2=80=9Cby enabling MPLS topology = detection based on IGP signaled segments as specified by = [I-D.ietf-isis-segment-routing-extensions], = [I-D.ietf-ospf-segment-routing-extensions] and = [I-D.ietf-idr-bgp-ls-segment-routing-ext]=E2=80=A6 This topology = awareness can be used for OAM purposes as described by this document.=E2=80= =9D This sounds as if those extensions are critical to the monitoring = system; IOW, Normative. However, the extensions are not mentioned in = the document anymore, so I would think that the concept is what is = important here, right? In lieu of making the references Normative, = please consider simply generically referring to topology awareness in = the Introduction (as you do elsewhere) and take the references out. > =20 >=20 [ED] This was a great point, thank you. > [ED] The sentence is changed to: > As compared to pre Segment Routing approaches, Segment Routing is = expected to > simplify such a monitoring system by enabling MPLS topology = detection based on IGP signaled > segments. The MPLS topology should be detected and correlated with = the IGP topology, which > is too detected by IGP signaling. > =20 > [ED] Added IGP topology, as this is important or useful at least and = wasn=E2=80=99t made explicit here. > =20 > ############# > =20 > M2. Section 12. (Security Considerations). This section seems to be = just a random collection of thoughts, and not a well thought out = description of potential threats and possible mitigation. Please take a = look at rfc3552. I have some specific comments: > =20 > 609 12. Security Considerations > =20 > 611 As mentioned in the introduction, a PMS monitoring = packet should > 612 never leave the domain where it originated.=20 > =20 > What is the risk? How can it be mitigated? > =20 > 612 = It therefore should > 613 never use stale MPLS or IGP routing information.=20 > =20 > I=E2=80=99m not sure if you mean that using stale information leads to = leaking, or if not using it can prevent it. In either case, how can the = PMS (or transit LSRs) recognize and prevent its use? > =20 > 613 = Further, assigning > 614 different label ranges for different purposes may be = useful. A well > 615 known global service level range may be excluded for = utilisation > 616 within PMS measurement packets.=20 > =20 > Now you seem to be talking about isolation of the management traffic. = Again, what are we avoiding here? I note that the text only says that = this =E2=80=9Cmay be useful=E2=80=9D, so there are probably cases where = it isn=E2=80=99t necessary =E2=80=93 when, why? > =20 > =20 > 616 = These ideas shouldn't start a > 617 discussion. They rather should point out, that such a = discussion is > 618 required when SR based OAM mechanisms like a SR are = standardised. > =20 > =E2=80=9Cshouldn=E2=80=99t start a discussion=E2=80=A6[but] such a = discussion is required=E2=80=A6=E2=80=9D Hmmm=E2=80=A6 > =20 > =E2=80=9CSR based OAM mechanisms like a SR=E2=80=9D -- ?? > =20 > It sounds like you=E2=80=99re trying to say that OAM mechanisms should = consider something, what? Domain boundaries? Stale information? = Isolation?=20 > =20 > I am a little confused, but this document =E2=80=9Cdescribes a system = using MPLS data plane path monitoring capabilities=E2=80=9D using SR =E2=80= =93 which I thought meant that no new SR based OAM mechanisms are to be = standardized. Section 10 talks about potential extensions that are not = part of what is presented here=E2=80=A6 What did I miss?=20 > =20 > 620 Should the approach of a PMS connected to an SR domain = by a tunnel be > 621 picked up, some fundamental MPLS security properties = need to be > 622 discussed.=20 > =20 > Picked up=E2=80=A6?? Do you mean used, implemented, ?? > =20 > What =E2=80=9Cfundamental MPLS security properties=E2=80=9D are you = referring to? Because you are describing approach here, this document = is the place to at least mention those =E2=80=9Cfundamental MPLS = security properties=E2=80=9D. > =20 > 622 MPLS domains so far allow to = separate the MPLS network > 623 from an IP network by allowing no tunneled MPLS access = to an MPLS > 624 domain. > =20 > This does seem like a potential security issue. What are the risks? = How can they be mitigated? > =20 > [ED] You are right, the security discussion should be more precise. = The text is hopefully better: > =20 > The PMS builds packets with intent of performing OAM tasks. It uses = address information based on topology information, rather than a = protocol. > =20 > The PMS allows to insert traffic into non-SR domains. This may be = required in the case of an LDP domain attached to the SR domain, but it = can be used to compromise security in the case of external IP domains = and MPLS based VPNs. > =20 > To avoid a PMS to insert traffic into an MPLS VPN domain, one or more = sets of label ranges may be reserved for service labels within an SR = domain. The PMS should be configured to reject usage of these service = label values. In the same way, misuse of IP destination addresses is = blocked if only IP-destination address values conforming to RFC 8029 are = settable by the PMS. > =20 > To limit potential misuse, access to a PMS needs to be authorized and = should be logged. OAM supported by a PMS requires skilled personal and = hence only experts requiring PMS access should be allowed to access such = a system. It is recommended to directly attach a PMS to an SR domain. = Connecting a PMS to an SR domain is technically possible, but adds = further security issues. A tunnel based access of a PMS to an SR domain = is not recommended. > =20 > Traffic insertion by a PMS may be unintended, especially if the IGP or = MPLS topology stored locally are in stale state. As soon as the PMS has = an indication, that its IGP or MPLS topology are stale, it should stop = operations involving network sections whose topology may not be = accurate. Note however that it is a task of an OAM system to discover = and locate network sections having where forwarding behavior is not = matching control plane state. As soon as a PMS or an operator of a PMS = has the impression, that the PMS topology information is stale, measures = need to be taken to refresh the topology information. These measures = should be part of the PMS design. Matching forwarding and control plane = state by periodically automated execution of RFC 8029 mechanisms may be = such a feature. Whenever network maintenance tasks are performed by = operators, the PMS topology discovery should be started asynchronously = after network maintenance has been finished. > =20 > A PMS loosing network connectivity or crashing must remove all IGP and = MPLS topology information prior to restarting operation. > =20 > A PMS may operate routine measurements. If these are automated, care = must be taken to avoid unintended traffic insertion. On the other hand, = large scale operation based on operator configuration itself is a source = of unintended misconfigurations and should be avoided. > =20 > ######### > =20 > M3. References > =20 > - RFC4379 was obsoleted by RFC8029. Please update the references and = check to make sure they are still valid. > - I-D.ietf-spring-segment-routing should be Normative. > =20 > [ED] Done in the draft. > =20 > =20 > Minor: > =20 > P1. Consider merging the Acronyms and Terminology sections =E2=80=93 = or at least putting both of them after the Introduction. I know that = this would mean that some acronyms would have to be expanded in the = Introduction. > =20 > [ED] Next draft version. > =20 > ####### > =20 > P2. =E2=80=9CBFD or LSP Ping format=E2=80=9D=E2=80=A6references? > =20 > [ED] Next draft version. [ED] Good point as well. In addition to adding the references, we also = add ICMP and S-BFD for completeness. > =20 > ####### > =20 > P3. The reference to I-D.ietf-spring-sr-oam-requirement seems = superfluous to me as there is no analysis to confirm that the = requirements are met or even in line with the use cases presented =E2=80=93= nor do I think there=E2=80=99s a need for that. > =20 > [ED] Ok, we will remove the reference. > =20 > ######## > =20 > P4. Terminology > =20 > P4.1. The definition of Continuity Check is copied exactly from = rfc7276 =E2=80=93 and there seems to be no special meaning when related = to segment routing. Suggestion: just include a statement that the = terminology in rfc7276 is used. > =20 > [ED] Bruno asked us to better distinguish between CC and CV, that=E2=80=99= s why both definitions were repeated. If Bruno is ok with your proposal = to just refer to rfc 7276, I happily will do so. > =20 > [Bruno] I=E2=80=99m fine with a reference to RFC 7276. Given that the = terminology section of RFC 7276 is 10 pages long, I=E2=80=99d propose to = also indicate the related section (i.e. RFC 7276 section 2.2.7) > =20 >=20 [ED] Good point, Bruno. Done. > ######### > =20 > P4.2. The definition of Connectivity Verification taken from rfc7276 = doesn=E2=80=99t match what that RFC says; instead, it looks like the = definition included here is a summary/interpretation. Suggestion: = again, just reference rfc7276 as a whole =E2=80=93 this will avoid = definitions that don=E2=80=99t match. > =20 > [ED] See above. If Bruno (or others) prefer to repeat the rfc7276 = text, we=E2=80=99ll do so in both cases and adapt text to the original. = If readers can be expected to have the definitions in mind, the bare = reference is fine. > =20 > [Bruno] idem. [ED] Ditto. > =20 > Thanks, > --Bruno > =20 > ########## > =20 > P4.3. =E2=80=9CRFC 4379 [RFC4379] specifies a Connectivity = Verification for MPLS domains.=E2=80=9D=20 > =20 > P4.3.1. RFC4379 has been obsoleted by RFC8029.=20 > =20 > [ED] Will be solved together with your M3 in the next draft version. > =20 > ######### > =20 > P4.3.2. I tried looking at those RFCs to figure out what was the = purpose this seemingly random sentence is, knowing that the concepts = from rfc7276 are the dominant ones, but couldn=E2=80=99t. Please = consider rewriting or removing. > =20 > [ED] Sentence P4.3. will be removed. > =20 > ########## > =20 > P4.3.3. Related =E2=80=93 Section 5.1 says: =E2=80=9C=E2=80=A6should = support RFC 4379 and its standardised extensions.=E2=80=9D RFC4379 was = updated by several RFCs, but RFC8029 isn=E2=80=99t. Does that change = this phrase? Do you need to specifically point at which extensions are = needed? > =20 > [ED] Proposed rewording: > The routers of the monitored domain should support RFC 8029 and = [I-D.draft-ietf-mpls-spring-lsp-ping] to incorporate existing and coming = standard MPLS trace route features. > =20 > ########## > =20 > P5. In 5.3: =E2=80=9CSuch a design is not within scope of this = document.=E2=80=9D What design? I guess you mean going through the = details for those cases. If so, then we can get rid of this sentence. > =20 > [ED] Sentence will be removed. > =20 > ########### > =20 > P6. Section 7: > =20 > =E2=80=9CIn the above example=E2=80=A6=E2=80=9D You mean the one = illustrated in Figure 1, right? > =20 > [ED] Figure 1 will be referenced. > =20 > =E2=80=9Cthree IP Performance Measurement Work Group (IPPM WG) = standard conformant Measurement Agents=E2=80=9D Please reference the = agents explicitly =E2=80=93 no need to mention the WG. > =20 > [ED] RFC6808 will be referenced. > =20 > s/statistical test published by the IPPM WG[RFC6576]/statistical test = in [RFC6576] > =20 > [ED] OK. > =20 > ############ > =20 > P7. Section 9 (Connectivity Verification Using PMS). Section 3 = already says that =E2=80=9CThis document proposes the use of SR based = network monitoring as a new Continuity Check method. In some special = cases, it also covers some limited Connectivity Verification. When = applicable, this is indicated in the description of the use case.=E2=80=9D= So it seems to me that this Section is not needed. The text = doesn=E2=80=99t seem to provide anything more beyond that statement. > =20 > [ED] Carlos, I think Nagendra proposed this text (but may be it was = Nobo). I=E2=80=99ll check with Nagendra, I prefer removing the = statement. > =20 >=20 [ED] Section 9 revamped, and improved in content. We believe there is = value in keeping it. > ########### > =20 > P8. Section 10. (Extensions of Specifications Relevant to this Use = Case) also doesn=E2=80=99t seem to say much, specially because rfc4379 = has already been obsoleted=E2=80=A6 > =20 > [ED] Section will be removed. > =20 > ########### > =20 > Nits: > =20 > N1. =E2=80=9Cpre Segment Routing=E2=80=9D is used in several places, = seemingly interchangeably with =E2=80=9Cnon segment routing=E2=80=9D. = Please be consistent. Personally, I prefer =E2=80=9Cnon segment = routing=E2=80=9D. > =20 > [ED] Will be changed to =E2=80=9Cnon=E2=80=9D > =20 > N2. s/as specified by specified by/as specified by > =20 > [ED] Will be changed. > =20 > N3. I find that the Introduction reads in parts like a marketing = brochure. It would be ideal if you could reword and focus=E2=80=A6 > =20 > [ED] Some Adjectives will be removed, but we=E2=80=99d prefer not to = rewrite it all. > =20 > N4. s/by RFC4379 (using the Downstream (Detailed) Mapping information = resulting from a "tree trace", see [RFC4379]/by RFC4379 (using the = Downstream (Detailed) Mapping information resulting from a "tree trace" = Don=E2=80=99t need the second reference. > =20 > [ED] 2nd ref will be removed. > =20 > N5. s/T-LDP/tLDP > The RFC Editor=E2=80=99s abbreviation list uses it that way. = [https://www.rfc-editor.org/materials/abbrev.expansion.txt = > =20 > [ED] Will be changed. > =20 > N6. s/Obviously/ > =20 > [ED] Will be removed. > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. Thanks again, =E2=80=94 Carlos Pignataro, carlos@cisco.com =E2=80=9CSometimes I use big words that I do not fully understand, to = make myself sound more photosynthesis." --Apple-Mail=_19DAFABE-315A-4752-9B34-E3D98391E727 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Many thanks for your detailed review, = Alvaro!

Alvaro, = Bruno,

Please = find inline a couple additional comments (also marked =E2=80=9CED=E2=80=9D= ) in addition to the editor comments on Ruediger=E2=80=99s = response.

On Jun 30, 2017, at 9:08 AM, bruno.decraene@orange.com wrote:

Hi Ruediger,

 

Please = see inline [Bruno]

 

From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
Sent: Monday, June 26, 2017 8:52 AM
To: aretana@cisco.com
Cc: spring-chairs@ietf.org; DECRAENE Bruno IMT/OLN; spring@ietf.org; draft-ietf-spring-oam-usecase@ietf.org
Subject: AW: AD Review of = draft-ietf-spring-oam-usecase-06

 

Hi Alvaro,

 

we are fine, hope you are too - thanks for your review and = comments. As we work with two editors, our comments are marked [ED].

 

 

[AR] Major:

 

[AR] M1. = The Introduction says that the monitoring system described in this = document will be simplified =E2=80=9Cby enabling MPLS topology detection = based on IGP signaled segments as specified by = [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and = [I-D.ietf-idr-bgp-ls-segment-routing-ext]=E2=80=A6 This = topology awareness can be used for OAM purposes as described by this = document.=E2=80=9D  This sounds as if those extensions are critical = to the monitoring system; IOW, Normative.  However, the extensions = are not mentioned in the document anymore, so I would think that the concept is = what is important here, right?  In lieu of making the references = Normative, please consider simply generically referring to topology = awareness in the Introduction (as you do elsewhere) and take the references out.

 



[ED] This was a great point, thank = you.

[ED] The sentence is changed = to:

   As = compared to pre Segment Routing  approaches, Segment Routing is = expected to

   simplify such a monitoring system by = enabling MPLS topology detection based on IGP signaled

   segments. The MPLS = topology should be detected and correlated with the IGP topology, which

   is = too detected by IGP signaling.

 

[ED] Added IGP = topology, as this is important or useful at least and wasn=E2=80=99t = made explicit here.

 

#############

 

M2. Section 12. (Security Considerations).  This section = seems to be just a random collection of thoughts, and not a well thought = out description of potential threats and possible mitigation.  Please take a look at rfc3552.  I have some specific comments:

 

609         12.  = Security Considerations

 

611         =    As mentioned in the introduction, a PMS monitoring packet = should

612         =    never leave the domain where it originated. 

 

What is the = risk?  How can it be mitigated?

 

612          =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             It = therefore should

613         =    never use stale MPLS or IGP routing information. 

 

I=E2=80=99m not = sure if you mean that using stale information leads to leaking, or if = not using it can prevent it.  In either case, how can the PMS (or = transit LSRs) recognize and prevent its use?

 

613          =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =        Further, assigning

614         =    different label ranges for different purposes may be = useful.  A well

615         =    known global service level range may be excluded for = utilisation

616         =    within PMS measurement packets. 

 

Now you seem to be = talking about isolation of the management traffic.  Again, what are = we avoiding here?  I note that the text only says that this =E2=80=9C= may be useful=E2=80=9D, so there are probably cases where it isn=E2=80=99t necessary =E2=80=93 when, why?

 

 

616          =           =             &n= bsp;           &nbs= p;            =             &n= bsp;       These ideas shouldn't = start a

617         =    discussion.  They rather should point out, that such a = discussion is

618         =    required when SR based OAM mechanisms like a SR are = standardised.

 

=E2=80=9Cshouldn=E2=80= =99t start a discussion=E2=80=A6[but] such a discussion is = required=E2=80=A6=E2=80=9D   Hmmm=E2=80=A6

 

=E2=80=9CSR based = OAM mechanisms like a SR=E2=80=9D -- ??

 

It sounds like you=E2=80=99re trying to say that OAM = mechanisms should consider something, what?  Domain boundaries? = Stale information? Isolation? 

 

I am a little = confused, but this document =E2=80=9Cdescribes a system using MPLS data = plane path monitoring capabilities=E2=80=9D using SR =E2=80=93 which I = thought meant that no new SR based OAM mechanisms are to be standardized.  Section 10 talks about potential extensions that = are not part of what is presented here=E2=80=A6 What did I miss? 

 

620         =    Should the approach of a PMS connected to an SR domain by a = tunnel be

621         =    picked up, some fundamental MPLS security properties need = to be

622         =    discussed. 

 

Picked = up=E2=80=A6??  Do you mean used, implemented, ??

 

What =E2=80=9Cfundame= ntal MPLS security properties=E2=80=9D are you referring to?  = Because you are describing approach here, this document is the place to = at least mention those =E2=80=9Cfundamental MPLS security = properties=E2=80=9D.

 

622          =             &n= bsp;           &nbs= p;   MPLS domains so far allow to separate the MPLS = network

623         =    from an IP network by allowing no tunneled MPLS access to = an MPLS

624         =    domain.

 

This does seem like a potential security issue.  What = are the risks? How can they be mitigated?

 

[ED] You are right, = the security discussion should be more precise. The text is hopefully = better:

 

The PMS builds = packets with intent of performing OAM tasks. It uses address information = based on topology information, rather than a protocol.

 

The PMS allows to = insert traffic into non-SR domains. This may be required in the case of = an LDP domain attached to the SR domain, but it can be used to = compromise security in the case of external  IP domains and MPLS based VPNs.

 

To avoid a PMS to = insert traffic into an MPLS VPN domain, one or more sets of label ranges = may be reserved for service labels within an SR domain. The PMS should = be configured to reject usage of these service label values. In the same way, misuse of IP = destination addresses is blocked if only IP-destination address values = conforming to RFC 8029 are settable by the PMS.

 

To limit potential = misuse, access to a PMS needs to be authorized and should be logged. OAM = supported by a PMS requires skilled personal and hence only experts = requiring PMS access should be allowed to access such a system. It is recommended to = directly attach a PMS to an SR domain. Connecting a PMS to an SR domain = is technically possible, but adds further security issues. A tunnel = based access of a PMS to an SR domain is not recommended.

 

Traffic insertion = by a PMS may be unintended, especially if the IGP or MPLS topology = stored locally are in stale state. As soon as the PMS has an indication, = that its IGP or MPLS topology are stale, it should stop operations involving network sections whose = topology may not be accurate. Note however that it is a task of an OAM = system to discover and locate network sections having where forwarding = behavior is not matching control plane state. As soon as a PMS or an operator of a PMS has the impression, that the = PMS topology information is stale, measures need to be taken to refresh = the topology information. These measures should be part of the PMS = design. Matching forwarding and control plane state by periodically automated execution of RFC 8029 mechanisms may be such = a feature. Whenever network maintenance tasks are performed by = operators, the PMS topology discovery should be started asynchronously = after network maintenance has been finished.

 

A PMS loosing = network connectivity or crashing must remove all IGP and MPLS topology = information prior to restarting operation.

 

A PMS may operate = routine measurements. If these are automated, care must be taken to = avoid unintended traffic insertion. On the other hand, large scale = operation based on operator configuration itself is a source of unintended misconfigurations and = should be avoided.

 

#########

 

M3. References

 

- RFC4379 was obsoleted by RFC8029.  Please update the = references and check to make sure they are still valid.

- I-D.ietf-spring-segment-routing = should be Normative.

 

[ED] Done in the draft.

 

 

Minor:

 

P1. Consider merging the Acronyms and Terminology sections = =E2=80=93 or at least putting both of them after the Introduction.  = I know that this would mean that some acronyms would have to be expanded in the Introduction.

 

[ED] Next draft version.

 

#######

 

P2. =E2=80=9CBFD or LSP Ping format=E2=80=9D=E2=80=A6references= ?

 

[ED] Next draft = version.



[ED] = Good point as well. In addition to adding the references, we also add = ICMP and S-BFD for completeness.


 

#######

 

P3. The reference to I-D.ietf-spring-sr-oam-requirement seems = superfluous to me as there is no analysis to confirm that the = requirements are met or even in line with the use cases presented =E2=80=93= nor do I think there=E2=80=99s a need for that.

 

[ED] Ok, we will = remove the reference.

 

########

 

P4. Terminology

 

P4.1. The definition of Continuity Check is copied exactly = from rfc7276 =E2=80=93 and there seems to be no special meaning when = related to segment routing.  Suggestion: just include a statement = that the terminology in rfc7276 is used.

 

[ED] Bruno asked us to better distinguish between CC and CV, = that=E2=80=99s why both definitions were repeated. If Bruno is ok with = your proposal to just refer to rfc 7276, I happily will do so.

 

[Bruno]= I=E2=80=99m fine with a reference to RFC 7276. Given that the = terminology section of RFC 7276 is 10 pages long, I=E2=80=99d propose to = also indicate the related section (i.e. RFC 7276 section 2.2.7)

 



[ED] Good point, Bruno. Done.

#########

 

P4.2. The = definition of Connectivity Verification taken from rfc7276 doesn=E2=80=99t= match what that RFC says; instead, it looks like the definition = included here is a summary/interpretation.  Suggestion: again, just reference rfc7276 as a whole =E2=80=93 this will avoid = definitions that don=E2=80=99t match.

 

[ED] See above. If Bruno (or others) prefer to repeat the = rfc7276 text, we=E2=80=99ll do so in both cases and adapt text to the = original. If readers can be expected to have the definitions in mind, = the bare reference is fine.

 

[Bruno]= idem.


[ED] Ditto.

 

Thanks,

--Bruno

 

##########

 

P4.3. =E2=80=9CRFC = 4379 [RFC4379] specifies a Connectivity Verification for MPLS = domains.=E2=80=9D 

 

P4.3.1. RFC4379 has = been obsoleted by RFC8029. 

 

[ED] Will be solved = together with your M3 in the next draft version.

 

#########

 

P4.3.2. I tried = looking at those RFCs to figure out what was the purpose this seemingly = random sentence is, knowing that the concepts from rfc7276 are the = dominant ones, but couldn=E2=80=99t.  Please consider rewriting or removing.

 

[ED] Sentence P4.3. will be removed.

 

##########

 

P4.3.3. Related = =E2=80=93  Section 5.1 says: =E2=80=9C=E2=80=A6should support RFC = 4379 and its standardised extensions.=E2=80=9D  RFC4379 was updated = by several RFCs, but RFC8029 isn=E2=80=99t.  Does that change this = phrase?  Do you need to specifically point at which extensions are needed?

 

[ED] Proposed = rewording:

The routers of the = monitored domain should support RFC 8029 and = [I-D.draft-ietf-mpls-spring-lsp-ping] to incorporate existing and coming = standard MPLS trace route features.

 

##########

 

P5. In 5.3: =E2=80=9CSuch a design is not within scope of = this document.=E2=80=9D  What design?  I guess you mean going = through the details for those cases.  If so, then we can get rid of = this sentence.

 

[ED] Sentence will be removed.

 

###########

 

P6.  Section = 7:

 

=E2=80=9CIn the = above example=E2=80=A6=E2=80=9D  You mean the one illustrated in = Figure 1, right?

 

[ED] Figure 1 will be referenced.

 

=E2=80=9Cthree IP = Performance Measurement Work Group (IPPM WG) standard conformant = Measurement Agents=E2=80=9D  Please reference the agents explicitly = =E2=80=93 no need to mention the WG.

 

[ED] RFC6808 will be referenced.

 

s/statistical test = published by the IPPM WG[RFC6576]/statistical test in [RFC6576]

 

[ED] OK.

 

############

 

P7. Section 9 (Connectivity Verification Using PMS).  = Section 3 already says that =E2=80=9CThis document proposes the use of = SR based network monitoring as a new Continuity Check method.  In = some special cases, it also covers some limited Connectivity Verification.  = When applicable, this is indicated in the description of the use = case.=E2=80=9D  So it seems to me that this Section is not = needed.   The text doesn=E2=80=99t seem to provide anything = more beyond that statement.

 

[ED] Carlos, I think Nagendra proposed this text (but may be = it was Nobo). I=E2=80=99ll check with Nagendra, I prefer removing the = statement.

 



[ED] Section 9 revamped, and improved = in content. We believe there is value in keeping it.


###########

 

P8.  Section = 10. (Extensions of Specifications Relevant to this Use Case) also = doesn=E2=80=99t seem to say much, specially because rfc4379 has already = been obsoleted=E2=80=A6

 

[ED] Section will be removed.

 

###########

 

Nits:

 

N1. =E2=80=9Cpre = Segment Routing=E2=80=9D is used in several places, seemingly = interchangeably with =E2=80=9Cnon segment routing=E2=80=9D.  Please = be consistent.  Personally, I prefer =E2=80=9Cnon segment = routing=E2=80=9D.

 

[ED] Will be changed to =E2=80=9Cnon=E2=80=9D

 

N2. s/as specified = by specified by/as specified by

 

[ED] Will be changed.

 

N3. I find that the Introduction reads in parts like a = marketing brochure.  It would be ideal if you could reword and = focus=E2=80=A6

 

[ED] Some Adjectives will be removed, but we=E2=80=99d prefer = not to rewrite it all.

 

N4. s/by RFC4379 (using the Downstream (Detailed) Mapping = information resulting from a "tree trace", see [RFC4379]/by RFC4379 = (using the Downstream (Detailed) Mapping information resulting from a "tree trace"    Don=E2=80=99t need the second = reference.

 

[ED] 2nd ref will be removed.

 

N5. = s/T-LDP/tLDP

The RFC Editor=E2=80=99= s abbreviation list uses it that way.  [https://www.rfc-editor.org/materials/abbrev.expansion.txt

 

[ED] Will be changed.

 

N6. s/Obviously/

 

[ED] Will be removed.

 

_______________________________________________________________=
__________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged =
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
Thanks again,

=E2=80=94
Carlos Pignataro, carlos@cisco.com

=E2=80=9CSometimes I use big = words that I do not fully understand, to make myself sound = more photosynthesis."

= --Apple-Mail=_19DAFABE-315A-4752-9B34-E3D98391E727-- From nobody Sat Jul 1 13:34:57 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E06E129AD3; Sat, 1 Jul 2017 13:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=no 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 Tqh0MXJQrfn6; Sat, 1 Jul 2017 13:34:55 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 6D4B8129AB7; Sat, 1 Jul 2017 13:34:46 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id r30so121090808qtc.0; Sat, 01 Jul 2017 13:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Gg/yELuH9yzxrkwfHD7hG5J3O5Zxa9jGiVHmCOZ2PsEEszo+opZ/2ml5C2nGktkbh4 p4DZGfz9GH4TQXWVvTRSaqK1gqcG4AI7o0Ak5ePQDZLz2fpiVDaEwAfrRClF9XMugRv/ QEoh3nVs8cCVy9SYgwLOa8nAMOMzh2euIWlZgH4s2N1aZxFe2KnGqhLuSqEK6IIxkJBB 99zHd6/ZeBjSysEb3NgUMRd9AJWiZpLfakZxzjvvI/5G3xR6HVWXp9dPNtMNxRfKximM H2WjlpZmE/0JJgJChZTYrXnSoNclz0Hi0Wn0dFldhWtSfLPo01uOMz3ZyoLgY4NKW1iU qoiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=T+xHJvBhZM4gPbHPXhdpu0zrbWOvnAXZHSNrozSV2JpKlF4e5D0sAr0Q0RLWVQGSmx eP4ktuWxi8lpRakunHK0vdEOn4DDPH6MLMRzuRHH9vak2sv7x/FnylCt0aCXdcS7O5LU HheCCdPxW04f0H+Exz9Jrh2RdJVy6Xeaf/MZRAELKVBlQWi51ZPBR19yyl0keZzWCR6T JBmtobrEGNC97DfW27TiCP9vytfFgWkeVoyvy80Vk47AqKZkjLR4JDU1R4a7cCk9U9PB XTSU6y+3jYbklrA7XF7TggSIBA9SpwW+vAXo13S8Mz3P8actW8bY6eCaUy9laU753amZ 3/tQ== X-Gm-Message-State: AIVw111pOmNhCcW+7JQHoC5x20O3ymHH8VaLyQwDv+b10h+nQVEtb9Vu p00dchSSBU4oJg== X-Received: by 10.200.46.16 with SMTP id r16mr18014449qta.209.1498941285678; Sat, 01 Jul 2017 13:34:45 -0700 (PDT) Received: from rtp-cpignata-nitro2.cisco.com ([173.38.117.67]) by smtp.gmail.com with ESMTPSA id c26sm9921202qte.63.2017.07.01.13.34.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Jul 2017 13:34:45 -0700 (PDT) Sender: Carlos Pignataro Content-Type: text/plain Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carlos Pignataro In-Reply-To: <28678_1498828104_59564D48_28678_291_3_53C29892C857584299CBF5D05346208A477E0608@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Sat, 1 Jul 2017 16:34:26 -0400 Cc: "Ruediger.Geib@telekom.de" , Alvaro Retana , "spring-chairs@ietf.org" , "spring@ietf.org" , "draft-ietf-spring-oam-usecase@ietf.org" X-Mao-Original-Outgoing-Id: 520634066.155632-5738f2c34e615a169cb11459292ee1c5 Content-Transfer-Encoding: 7bit Message-Id: References: <28678_1498828104_59564D48_28678_291_3_53C29892C857584299CBF5D05346208A477E0608@OPEXCLILM21.corporate.adroot.infra.ftgroup> To: Bruno Decraene X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [spring] AD Review of draft-ietf-spring-oam-usecase-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 20:34:56 -0000 From nobody Sat Jul 1 13:52:09 2017 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10580129AD3; Sat, 1 Jul 2017 13:52:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149894232203.532.4624737237119698628@ietfa.amsl.com> Date: Sat, 01 Jul 2017 13:52:02 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-oam-usecase-07.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 20:52:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : A Scalable and Topology-Aware MPLS Dataplane Monitoring System Authors : Ruediger Geib Clarence Filsfils Carlos Pignataro Nagendra Kumar Filename : draft-ietf-spring-oam-usecase-07.txt Pages : 18 Date : 2017-07-01 Abstract: This document describes features of a path monitoring system and related use cases. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS Ping and LSP Trace, in a very complementary way. MPLS topology awareness reduces management and control plane involvement of OAM measurements while enabling new OAM features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-oam-usecase-07 https://datatracker.ietf.org/doc/html/draft-ietf-spring-oam-usecase-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-oam-usecase-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 Sat Jul 1 13:52:51 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56912129AD3; Sat, 1 Jul 2017 13:52:34 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 hV3108t04Vah; Sat, 1 Jul 2017 13:52:32 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19A7129AEA; Sat, 1 Jul 2017 13:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13820; q=dns/txt; s=iport; t=1498942352; x=1500151952; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K6WG6hFKIWZp+9v5nMZMa8j5Iy21KNL592HCmBqynbs=; b=hqRws3pN0NaKS9LEo/sbdmiHAPgVwcMlCftAvzy7WgoEQETjJSswgtQU XuxSmXOBUuhAEb9sj46+rF+d/hHtsGrU5/PFjuxbmJsLEMnkYyviy+eEu zVW3jaPDJy/ezE0o6q6nw3dJ2E1ETJxH501sURGapkl1BBTTHWCCLsn22 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQBoClhZ/4sNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1mBcQeDZYoZoj6FK4IRhhwCGoJ/PxgBAgEBAQEBAQFrKIUZBiNWEAI?= =?us-ascii?q?BCD8DAgICMBQRAgQOBYlLZLIggiaLUAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DJ?= =?us-ascii?q?4NMgWErgnmHfTCCMQWJT4hWjFoCk3+CDIVKikeVLwEfOIEKdRVbAYUAHIFmdog?= =?us-ascii?q?+gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,294,1496102400"; d="scan'208,217";a="448178266" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2017 20:52:31 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v61KqUVQ025136 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 1 Jul 2017 20:52:30 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 1 Jul 2017 16:52:30 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sat, 1 Jul 2017 16:52:29 -0400 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" CC: "rtg-dir@ietf.org" , "spring@ietf.org" , "ietf@ietf.org" , "draft-ietf-spring-oam-usecase.all@ietf.org" Thread-Topic: Rtgdir last call review of draft-ietf-spring-oam-usecase-06 Thread-Index: AQHS61uWxVbWnw4SLk2wgKSt4LG4WKI/xD6A Date: Sat, 1 Jul 2017 20:52:29 +0000 Message-ID: <6B35D999-331B-4DB3-A9F1-C2BEF4EC0944@cisco.com> References: <149813817013.30481.17524594111387704082@ietfa.amsl.com> In-Reply-To: <149813817013.30481.17524594111387704082@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.118.116.131] Content-Type: multipart/alternative; boundary="_000_6B35D999331B4DB3A9F1C2BEF4EC0944ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Rtgdir last call review of draft-ietf-spring-oam-usecase-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 20:52:35 -0000 --_000_6B35D999331B4DB3A9F1C2BEF4EC0944ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHJldmlldywgSm9lbCENCg0KUmV2aXNpb24gLTA3LCBqdXN0IHN1Ym1p dHRlZCwgc2hvdWxkIGFkZHJlc3MgYWxsIHlvdXIgY29uY2VybnMgYW5kIHN1Z2dlc3Rpb25zLiBQ bGVhc2UgbGV0IHVzIGtub3cgb3RoZXJ3aXNlLg0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoN Ck9uIEp1biAyMiwgMjAxNywgYXQgOToyOSBBTSwgSm9lbCBIYWxwZXJuIDxqbWhAam9lbGhhbHBl cm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4gd3JvdGU6DQoNClJldmlld2VyOiBK b2VsIEhhbHBlcm4NClJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQoNClRoaXMgaXMgYSBydGctZGly IHJlcXVlc3RlZCByZXZpZXcuDQoNClN1bW1hcnk6IFJlYWR5IGZvciBwdWJsaWNhdGlvbiBhcyBh biBJbmZvcm1hdGlvbmFsIFJGQyB3aXRoIHNvbWUgbWlub3IgaXRlbXMNCnRoYXQgc2hvdWxkIGJl IGNvbnNpZGVyZWQuDQoNCk1ham9yOiBOL0ENCg0KTWlub3I6DQogICBUaGUgaW50cm9kdWN0aW9u IHRyZWF0cyBoYXZpbmcgYSBzaW5nbGUgY2VudHJhbGl6ZWQgbW9uaXRvcmluZyBzeXN0ZW0gYXMg YW4NCiAgIHVuYWxsb3llZCBwb3NpdGl2ZS4gIFRvIHNldCBjb250ZXh0IHByb3Blcmx5LCBpdCB3 b3VsZCBzZWVtIG1vcmUNCiAgIGFwcHJvcHJpYXRlIHRvIG5vdGUgdGhhdCBtYW55IG9wZXJhdG9y cyBmaW5kIHN1Y2ggY2VudHJhbCBzeXN0ZW1zIHVzZWZ1bCwNCiAgIGFuZCB0aGUgYXBwcm9hY2gg ZGVzY3JpYmVkIGhlcmUgZW5hYmxlcyB0aGF0IHdoZW4gZGVzaXJlZC4NCg0KICAgVGhlIHJlZmVy ZW5jZSBpbiB0aGUgaW50cm9kdWN0aW9uIHRvIElHUCB0b3BvbG9neSBkaXNjb3ZlcnkgaXMgdmVy eQ0KICAgY29uZnVzaW5nLiAiQWRkaW5nIE1QTFMgdG9wb2xvZ3kgYXdhcmVuZXNzIHRvIGFuIElH UCBzcGVha2luZyBkZXZpY2UgaGVuY2UNCiAgIGVuYWJsZXMgYSBzaW1wbGUgYW5kIHNjYWxhYmxl IGRhdGEgcGxhbmUgYmFzZWQgbW9uaXRvcmluZyBtZWNoYW5pc20uIiAgQXMNCiAgIG5vdGVkIGxh dGVyIGluIHRoZSBkb2N1bWVudCwgbGluay1zdGF0ZSBJR1BzIHByb3ZpZGUgdG9wb2xvZ3kgYXdh cmVuZXNzLg0KICAgU28gd2hhdCBpcyB0aGlzIHBhcnQgb2YgdGhlIGludHJvZHVjdGlvbiB0cnlp bmcgdG8gc2F5PyAgKFNpZGUtbm90ZSwgbm90DQogICBhbGwgSUdQcyBhcmUgbGluayBzdGF0ZSwg YWx0aG91Z2ggdGhlIGFwcGxpY2FiaWxpdHkgb2YgQmFiZWwgb3IgUklQIHRvIE1QTFMNCiAgIFNl Z21lbnQgUm91dGluZyBpcyBjbGVhcmx5IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1l bnQuKQ0KDQogICBJbiBzZWN0aW9uIDUuMSBpbiBkaXNjdXNzaW5nIHBhdGggdHJhY2UgdGhlIHJl ZmVyZW5jZSBpcyB0byBSRkMgNDM3OSB3aGljaA0KICAgaXMgYSBjbGVhciBzb3VyY2UgZm9yIHBh dGggdHJhY2UuICBIb3dldmVyLCB0aGUgdGV4dCByZWZlcnMgdG8gInRyZWUNCiAgIHRyYWNlIi4g IFdoaWxlIHRoYXQgbWF5IGhhdmUgYmVjb21lIGEgY29tbW9uIHBocmFzZSBmb3IgdGhlIHVzYWdl LCBpdCBpcw0KICAgbm90IHVzZWQgaW4gUkZDIDQzNzkuICBUaGUgdGVybSBzaG91bGQgZWl0aGVy IGJlIGV4cGxhaW4sIGluY2x1ZGUgYQ0KICAgc3VpdGFibGUgcmVmZXJlbmNlLCBvciBub3QgYmUg dXNlZC4NCg0KICBJbiBzZWN0aW9uIDUuMyBvbiBmYXVsdCBpc29sYXRpb24sIHRoZSB0ZXh0IG5v dGVzIHRoYXQgdGhlIG9ubHkgZGlmZmVyZW5jZQ0KICBiZXR3ZWVuIHRoZSB0ZXN0IHdoaWNoIHN1 Y2NlZWRzIGFuZCB0aGF0IHdoaWNoIGZhaWxzIGlzIHRoZSBkaWZmZXJlbmNlIHRoZQ0KICB0aGUg YWRqYWNlbmN5IFNJRC4gIFRoZSB0ZXh0IHRoZW4gZ29lcyBvbiB0byBzYXkgIkFzc3VtaW5nIHRo ZSBzZWNvbmQgcHJvYmUNCiAgaGFzIGJlZW4gcm91dGVkIGNvcnJlY3RseSwgdGhlIGZhdWx0IG11 c3QgaGF2ZSBiZWVuIG9jY3VycmluZyBpbiBSMiB3aGljaA0KICBkaWRuJ3QgZm9yd2FyZCB0aGUg cGFja2V0IHRvIHRoZSBpbnRlcmZhY2UgaWRlbnRpZmllZCBieSBpdHMgQWRqYWNlbmN5IFNJRA0K ICA2NjMuIiAgVGhhdCBkb2VzIG5vdCBmb2xsb3cuICBJZiB0aGUgbGluayBhcyBmYWlsZWQgaW4g YW4gdW5kZXRlY3RlZCBmYXNoaW9uDQogIChlaXRoZXIgaW4gb25lIGRpcmVjdGlvbiBvciBib3Ro KSwgUjIgd291bGQgYmUgZnVuY3Rpb25pbmcgZmluZSBhbmQgdGhlDQogIHN5bXB0b20gd291bGQg YmUgdGhlIHNhbWUuICBSZW1vdGVseSBkZXRlY3RpbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBS Mg0KICBmYWlsaW5nIHRvIGZvcndhcmQgYW5kIHRoZSBsaW5rIG5vdCB3b3JraW5nIHNlZW1zIGEg bXVjaCBoYXJkZXIgdGFzay4NCg0KICAgVGhlIGNsYWltIHRoYXQgdGhlIFBNUyBjYW4gLyBzaG91 bGQgKGludGVudCBpcyBhbWJpZ3VvdXMpIG5vdGlmeSB0aGUgcm91dGVyDQogICB3aGVuIGl0IGRl dGVjdHMgYSBwYXRoIGZhaWx1cmUgcmFpc2VzIGEgbnVtYmVyIG9mIGlzc3Vlcy4gICBJdCBpcyBu b3QgYXQNCiAgIGFsbCBjbGVhciB3aGF0IHRoZSByb3V0ZXIgd291bGQgZG8gd2l0aCB0aGUgbm90 aWZpY2F0aW9uLiAgKGUuZy4gSWYgaXQNCiAgIHJlbW92ZWQgdGhlIGxpbmsgZnJvbSBzZXJ2aWNl LCB0aGVuIGZ1dHVyZSBtb25pdG9yaW5nIHdvdWxkIG5vdCBiZSBhYmxlIHRvDQogICBkZXRlY3Qg dGhhdCB0aGUgbGluayB3YXMgd29ya2luZy4pICBFaXRoZXIgdGhpcyBuZWVkcyB0byBiZWNvbWUg YQ0KICAgc2lnbmlmaWNhbnRseSBsYXJnZXIgc2VjdGlvbiwgb3IgKG1vcmUgbGlrZWx5KSB0aGUg dGV4dCBuZWVkcyB0byBiZSByZW1vdmVkLg0KDQpFZGl0b3JpYWw6DQogICBDaGFwdGVyIDcgaXMg dGl0bGVkIGRlYWxpbmcgd2l0aCBub24tU1IgZW52aXJvbm1lbnRzLiAgV2hpY2ggbWFrZXMgc2Vu c2UuDQogICBUaGUgdGV4dCB0aGVuIHN3aXRjaGVzIHRvIHVzaW5nICJwcmUtU1IiIGluc3RlYWQg b2YgIm5vbi1TUiIuICBJIHdvdWxkDQogICByZWNvbW1lbmQgdGhhdCBhbGwgdXNlcyBvZiAicHJl LVNSIiBiZSBjaGFuZ2VkIHRvICJub24tU1IiLg0KDQoNCuKAlA0KQ2FybG9zIFBpZ25hdGFybywg Y2FybG9zQGNpc2NvLmNvbTxtYWlsdG86Y2FybG9zQGNpc2NvLmNvbT4NCg0K4oCcU29tZXRpbWVz IEkgdXNlIGJpZyB3b3JkcyB0aGF0IEkgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2Ug bXlzZWxmIHNvdW5kIG1vcmUgcGhvdG9zeW50aGVzaXMuIg0KDQo= --_000_6B35D999331B4DB3A9F1C2BEF4EC0944ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <373CD0989D13A848AC179573BDD1D29F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmtzIGZvciB5b3VyIHJldmll dywgSm9lbCEmbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPlJldmlzaW9uIC0wNywganVzdCBzdWJtaXR0ZWQsIHNob3VsZCBhZGRyZXNzIGFs bCB5b3VyIGNvbmNlcm5zIGFuZCBzdWdnZXN0aW9ucy4gUGxlYXNlIGxldCB1cyBrbm93IG90aGVy d2lzZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPlRoYW5rcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+T24gSnVuIDIyLCAyMDE3LCBhdCA5OjI5IEFNLCBKb2VsIEhhbHBlcm4gJmx0OzxhIGhy ZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiBjbGFzcz0iIj5qbWhAam9lbGhhbHBlcm4u Y29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5l d2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+UmV2aWV3ZXI6IEpvZWwgSGFs cGVybjxiciBjbGFzcz0iIj4NClJldmlldyByZXN1bHQ6IEhhcyBOaXRzPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KVGhpcyBpcyBhIHJ0Zy1kaXIgcmVxdWVzdGVkIHJldmlldy48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTdW1tYXJ5OiBSZWFkeSBmb3IgcHVibGljYXRpb24gYXMg YW4gSW5mb3JtYXRpb25hbCBSRkMgd2l0aCBzb21lIG1pbm9yIGl0ZW1zPGJyIGNsYXNzPSIiPg0K dGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpN YWpvcjogTi9BPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTWlub3I6PGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIGludHJvZHVjdGlvbiB0cmVhdHMgaGF2aW5nIGEgc2lu Z2xlIGNlbnRyYWxpemVkIG1vbml0b3Jpbmcgc3lzdGVtIGFzIGFuPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7dW5hbGxveWVkIHBvc2l0aXZlLiAmbmJzcDtUbyBzZXQgY29udGV4dCBw cm9wZXJseSwgaXQgd291bGQgc2VlbSBtb3JlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7YXBwcm9wcmlhdGUgdG8gbm90ZSB0aGF0IG1hbnkgb3BlcmF0b3JzIGZpbmQgc3VjaCBjZW50 cmFsIHN5c3RlbXMgdXNlZnVsLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2FuZCB0 aGUgYXBwcm9hY2ggZGVzY3JpYmVkIGhlcmUgZW5hYmxlcyB0aGF0IHdoZW4gZGVzaXJlZC48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtUaGUgcmVmZXJlbmNl IGluIHRoZSBpbnRyb2R1Y3Rpb24gdG8gSUdQIHRvcG9sb2d5IGRpc2NvdmVyeSBpcyB2ZXJ5PGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Y29uZnVzaW5nLiAmcXVvdDtBZGRpbmcgTVBM UyB0b3BvbG9neSBhd2FyZW5lc3MgdG8gYW4gSUdQIHNwZWFraW5nIGRldmljZSBoZW5jZTxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2VuYWJsZXMgYSBzaW1wbGUgYW5kIHNjYWxhYmxl IGRhdGEgcGxhbmUgYmFzZWQgbW9uaXRvcmluZyBtZWNoYW5pc20uJnF1b3Q7ICZuYnNwO0FzPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7bm90ZWQgbGF0ZXIgaW4gdGhlIGRvY3VtZW50 LCBsaW5rLXN0YXRlIElHUHMgcHJvdmlkZSB0b3BvbG9neSBhd2FyZW5lc3MuIDxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwO1NvIHdoYXQgaXMgdGhpcyBwYXJ0IG9mIHRoZSBpbnRyb2R1 Y3Rpb24gdHJ5aW5nIHRvIHNheT8gJm5ic3A7KFNpZGUtbm90ZSwgbm90PGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7YWxsIElHUHMgYXJlIGxpbmsgc3RhdGUsIGFsdGhvdWdoIHRoZSBh cHBsaWNhYmlsaXR5IG9mIEJhYmVsIG9yIFJJUCB0byBNUExTPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7U2VnbWVudCBSb3V0aW5nIGlzIGNsZWFybHkgb3V0c2lkZSB0aGUgc2NvcGUg b2YgdGhpcyBkb2N1bWVudC4pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7SW4gc2VjdGlvbiA1LjEgaW4gZGlzY3Vzc2luZyBwYXRoIHRyYWNlIHRoZSByZWZl cmVuY2UgaXMgdG8gUkZDIDQzNzkgd2hpY2g8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDtpcyBhIGNsZWFyIHNvdXJjZSBmb3IgcGF0aCB0cmFjZS4gJm5ic3A7SG93ZXZlciwgdGhlIHRl eHQgcmVmZXJzIHRvICZxdW90O3RyZWU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDt0 cmFjZSZxdW90Oy4gJm5ic3A7V2hpbGUgdGhhdCBtYXkgaGF2ZSBiZWNvbWUgYSBjb21tb24gcGhy YXNlIGZvciB0aGUgdXNhZ2UsIGl0IGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 bm90IHVzZWQgaW4gUkZDIDQzNzkuICZuYnNwO1RoZSB0ZXJtIHNob3VsZCBlaXRoZXIgYmUgZXhw bGFpbiwgaW5jbHVkZSBhPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7c3VpdGFibGUg cmVmZXJlbmNlLCBvciBub3QgYmUgdXNlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDtJbiBzZWN0aW9uIDUuMyBvbiBmYXVsdCBpc29sYXRpb24sIHRoZSB0ZXh0IG5v dGVzIHRoYXQgdGhlIG9ubHkgZGlmZmVyZW5jZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2Jl dHdlZW4gdGhlIHRlc3Qgd2hpY2ggc3VjY2VlZHMgYW5kIHRoYXQgd2hpY2ggZmFpbHMgaXMgdGhl IGRpZmZlcmVuY2UgdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7dGhlIGFkamFjZW5jeSBT SUQuICZuYnNwO1RoZSB0ZXh0IHRoZW4gZ29lcyBvbiB0byBzYXkgJnF1b3Q7QXNzdW1pbmcgdGhl IHNlY29uZCBwcm9iZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2hhcyBiZWVuIHJvdXRlZCBj b3JyZWN0bHksIHRoZSBmYXVsdCBtdXN0IGhhdmUgYmVlbiBvY2N1cnJpbmcgaW4gUjIgd2hpY2g8 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtkaWRuJ3QgZm9yd2FyZCB0aGUgcGFja2V0IHRvIHRo ZSBpbnRlcmZhY2UgaWRlbnRpZmllZCBieSBpdHMgQWRqYWNlbmN5IFNJRDxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOzY2My4mcXVvdDsgJm5ic3A7VGhhdCBkb2VzIG5vdCBmb2xsb3cuICZuYnNw O0lmIHRoZSBsaW5rIGFzIGZhaWxlZCBpbiBhbiB1bmRldGVjdGVkIGZhc2hpb248YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsoZWl0aGVyIGluIG9uZSBkaXJlY3Rpb24gb3IgYm90aCksIFIyIHdv dWxkIGJlIGZ1bmN0aW9uaW5nIGZpbmUgYW5kIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw O3N5bXB0b20gd291bGQgYmUgdGhlIHNhbWUuICZuYnNwO1JlbW90ZWx5IGRldGVjdGluZyB0aGUg ZGlmZmVyZW5jZSBiZXR3ZWVuIFIyPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7ZmFpbGluZyB0 byBmb3J3YXJkIGFuZCB0aGUgbGluayBub3Qgd29ya2luZyBzZWVtcyBhIG11Y2ggaGFyZGVyIHRh c2suPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIGNs YWltIHRoYXQgdGhlIFBNUyBjYW4gLyBzaG91bGQgKGludGVudCBpcyBhbWJpZ3VvdXMpIG5vdGlm eSB0aGUgcm91dGVyPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7d2hlbiBpdCBkZXRl Y3RzIGEgcGF0aCBmYWlsdXJlIHJhaXNlcyBhIG51bWJlciBvZiBpc3N1ZXMuICZuYnNwOyZuYnNw O0l0IGlzIG5vdCBhdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2FsbCBjbGVhciB3 aGF0IHRoZSByb3V0ZXIgd291bGQgZG8gd2l0aCB0aGUgbm90aWZpY2F0aW9uLiAmbmJzcDsoZS5n LiBJZiBpdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO3JlbW92ZWQgdGhlIGxpbmsg ZnJvbSBzZXJ2aWNlLCB0aGVuIGZ1dHVyZSBtb25pdG9yaW5nIHdvdWxkIG5vdCBiZSBhYmxlIHRv PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ZGV0ZWN0IHRoYXQgdGhlIGxpbmsgd2Fz IHdvcmtpbmcuKSAmbmJzcDtFaXRoZXIgdGhpcyBuZWVkcyB0byBiZWNvbWUgYTxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwO3NpZ25pZmljYW50bHkgbGFyZ2VyIHNlY3Rpb24sIG9yICht b3JlIGxpa2VseSkgdGhlIHRleHQgbmVlZHMgdG8gYmUgcmVtb3ZlZC48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpFZGl0b3JpYWw6PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Q2hhcHRlciA3IGlzIHRpdGxlZCBkZWFsaW5nIHdpdGggbm9uLVNSIGVudmlyb25tZW50cy4gJm5i c3A7V2hpY2ggbWFrZXMgc2Vuc2UuIDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO1Ro ZSB0ZXh0IHRoZW4gc3dpdGNoZXMgdG8gdXNpbmcgJnF1b3Q7cHJlLVNSJnF1b3Q7IGluc3RlYWQg b2YgJnF1b3Q7bm9uLVNSJnF1b3Q7LiAmbmJzcDtJIHdvdWxkPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7cmVjb21tZW5kIHRoYXQgYWxsIHVzZXMgb2YgJnF1b3Q7cHJlLVNSJnF1b3Q7 IGJlIGNoYW5nZWQgdG8gJnF1b3Q7bm9uLVNSJnF1b3Q7LjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl ci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+ DQrigJQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQ2FybG9zIFBpZ25h dGFybywmbmJzcDs8YSBocmVmPSJtYWlsdG86Y2FybG9zQGNpc2NvLmNvbSIgY2xhc3M9IiI+Y2Fy bG9zQGNpc2NvLmNvbTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8aSBjbGFzcz0i Ij7igJxTb21ldGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkgdW5kZXJz dGFuZCwgdG8gbWFrZSBteXNlbGYgc291bmQgbW9yZSZuYnNwO3Bob3Rvc3ludGhlc2lzLiZxdW90 OzwvaT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6B35D999331B4DB3A9F1C2BEF4EC0944ciscocom_-- From nobody Sat Jul 1 13:56:32 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA88129AE8; Sat, 1 Jul 2017 13:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 WFwFqW8VHtDE; Sat, 1 Jul 2017 13:56:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19091129ADE; Sat, 1 Jul 2017 13:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3954; q=dns/txt; s=iport; t=1498942573; x=1500152173; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H8FmzOAMin7hgl4Eso7WTjxJ3lldqGb72FYbBrR/Elc=; b=A3NMuGKq5a1dbSGwDIl3IuMCwrvNj8LfEBPJuxFHk5baLc4kTSw88Dox 5Xi7IIwt92zlKTah+pXfrNxDEYwhGmLoxirkTZOzTmuYnt3h55IXVSp6h 6nTDRIOXAWpf9DZ6sZqR/ehdjFIcRJzAaOVihZp+yB/E6M1Sth/SILn3I 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAAC7C1hZ/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1mBcQeDZYoZkWyVfYIRhhwCGoJ/PxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBIxFFBQsCAQgYAgImAgICMBUQAgQOBYonCLIlgiaLUAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2BC4Icg0yBYSuCeYd9MIIxBZcoh1cCiwiId4IMhUqKR5UvAR8?= =?us-ascii?q?4gQp1FVsBhwJ2iD6BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,294,1496102400"; d="scan'208";a="264805731" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2017 20:56:12 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v61KuBf6010282 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 1 Jul 2017 20:56:12 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 1 Jul 2017 16:56:11 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sat, 1 Jul 2017 16:56:11 -0400 From: "Carlos Pignataro (cpignata)" To: Joel Jaeggli CC: "ops-dir@ietf.org" , "spring@ietf.org" , "ietf@ietf.org" , "draft-ietf-spring-oam-usecase.all@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-spring-oam-usecase-06 Thread-Index: AQHS8asSheiuQD9TpUafQQQDEffqE6I/uKYA Date: Sat, 1 Jul 2017 20:56:11 +0000 Message-ID: <25E86852-0B40-43C4-BFF2-C83088F34B5D@cisco.com> References: <149883201392.4666.499169365560986574@ietfa.amsl.com> In-Reply-To: <149883201392.4666.499169365560986574@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.118.116.131] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Opsdir last call review of draft-ietf-spring-oam-usecase-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 20:56:15 -0000 SGksIEpvZWwsDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldyEgUGxlYXNlIHNlZSBpbmxp bmUuDQoNCj4gT24gSnVuIDMwLCAyMDE3LCBhdCAxMDoxMyBBTSwgSm9lbCBKYWVnZ2xpIDxqb2Vs amFAYm9ndXMuY29tPiB3cm90ZToNCj4gDQo+IFJldmlld2VyOiBKb2VsIEphZWdnbGkNCj4gUmV2 aWV3IHJlc3VsdDogSGFzIE5pdHMNCj4gDQo+IEkgaGF2ZSByZXZpZXdlZA0KPiANCj4gZHJhZnQt aWV0Zi1zcHJpbmctb2FtLXVzZWNhc2UtMDYgYXMgcGFyIG9mIHRoZSBPUFMgZGlyZWN0b3JhdGUg cmV2aWV3IGN5Y2xlDQo+IGZvcklFVEYgbGFzdCBjYWxsLg0KPiANCj4gSW4gZ2VuZXJhbCBJIHRo aW5rIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgdG8gZ28gaG93ZXZlciBJIGhhdmUgYSBjb3VwbGUg b2YNCj4gY29uY2VybnMgdGhhdCBzaG91bGQgcHJvYmFibHkgYXQgbGVhc3QgYmUgZGlzY3Vzc2Vk IHByaW9yIHRvIElFU0cgcmV2aWV3Lg0KPiANCj4+IEZyb20gbXkgdmFudGFnZSBwb2ludCB0aGUg ZG9jdW1lbnQgaXMgbm90IHNvIG11Y2ggYSBkZXNjcmlwdGlvbiBvZiBhIHVzZSBjYXNlDQo+IG9y IHJlcXVpcmVtZW50cyBhcyBpdCBpcyB0aGUgYXJjaGl0ZWN0dXJhbCB3cmFwcGVyIGFyb3VuZA0K PiBkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWxzcC1waW5nLiBJdCdzIG1vc3QgaGVscGZ1bCBpbiBt eSBvcGluaW9uIHRvIHJldmlldyB0aGlzDQo+IG9uZSBhcyB0aG91Z2ggdGhlIG90aGVyIG9uZSB3 YXMgdGhlIGNvbXBhbmlvbiBkb2N1bWVudCwgZnJvbSB0aGlzIHZhbnRhZ2UgcG9pbnQNCj4gSSB0 aGluayB0aGUgbGF0ZXIgZG9jdW1lbnQgaXMgZWZmZWN0aXZlbHkgbm9ybWF0aXZlbHkgcmVmZXJl bmNlZC4gU2ltaWxhcmx5IHRoZQ0KPiByZWFkaW5lc3Mgb2YgdGhlIGxhdGVyIGRvY3VtZW50ICh3 aGljaCBpcyBhIGJpdCBlYXJsaWVyIGluIGl0J3MgbGlmZWN5Y2xlKQ0KPiByYWlzZXMgdGhlIHF1 ZXN0aW9uIG9mIHdoZXRoZXIgdGhpcyBvbmUgaXMgcmVhZHkgdG8gZ28uDQo+IA0KDQpJIGFncmVl IHRoYXQgdGhpcyBpcyBub3Qgc28gbXVjaCBhIHVzZS1jYXNlIGRvY3VtZW50IOKAlCBob3dldmVy LCBJIHdvdWxkIG5vdCBjaGFyYWN0ZXJpemUgdGhpcyBkb2N1bWVudCBhcyBzdGFuZGluZyBhdG9w IGRyYWZ0LWlldGYtbXBscy1zcHJpbmctbHNwLXBpbmcuIEluIGZhY3QsIHRoZSBtb25pdG9yaW5n IHN5c3RlbSBkZXNjcmliZWQsIGFzIHRoZSB0ZXh0IGFscmVhZHkgc2hvd3MsIGNhbiB1c2Ugb3Ro ZXIgT0FNIHByb3RvY29scyBhbmQgZm9ybWF0cy4gVGhhdCBpcywgaWYgdGhlIFBNUyB1c2VzIGZv ciBleGFtcGxlIEJGRCwgYW5kIHRoZXJlZm9yZSBpdCBkb2VzIG5vdCB1c2UgUkZDIDgwMjksIHRo ZW4gaXQgY2Fubm90IHVzZSBkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWxzcC1waW5nIChiZWNhdXNl IHRob3NlIGFyZSBleHRlbnNpb25zIG9mIE1QTFMgTFNQIFBpbmcpLiBGdXJ0aGVyLCB0aGUgUE1T IGNhbiBwZXJmZWN0bHkgd2VsbCAoYXMgYWxyZWFkeSBkZXNjcmliZWQpIGZ1bmN0aW9uIHdpdGgg UkZDIDgwMjkgYW5kIHdpdGhvdXQgZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1sc3AtcGluZy4gZHJh ZnQtaWV0Zi1tcGxzLXNwcmluZy1sc3AtcGluZyBwcm92aWRlcyB2ZXJ5IHVzZWZ1bCBlbmhhbmNl bWVudHMgdGhhdCB0aGUgc3lzdGVtIGNhbiBsZXZlcmFnZSwgYnV0IHRoZSBzeXN0ZW0gaXMgbm90 IHdyYXBwZWQgYXJvdW5kIHRoZSBzcGVjaWZpY2F0aW9uIG9mIGRyYWZ0LWlldGYtbXBscy1zcHJp bmctbHNwLXBpbmcuDQoNCldlIHRyaWVkIHRvIGNsYXJpZnkgdGhpcyBhIGJpdCBpbiB0aGUgdmVy c2lvbiBqdXN0IHN1Ym1pdHRlZC4NCg0KPiBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg c2VjdGlvbiB0aGUgZG9jdW1lbnQgbm90ZXM6DQo+IA0KPiAgIEFzIG1lbnRpb25lZCBpbiB0aGUg aW50cm9kdWN0aW9uLCBhIFBNUyBtb25pdG9yaW5nIHBhY2tldCBzaG91bGQNCj4gICBuZXZlciBs ZWF2ZSB0aGUgZG9tYWluIHdoZXJlIGl0IG9yaWdpbmF0ZWQuICBJdCB0aGVyZWZvcmUgc2hvdWxk DQo+ICAgbmV2ZXIgdXNlIHN0YWxlIE1QTFMgb3IgSUdQIHJvdXRpbmcgaW5mb3JtYXRpb24uDQo+ IA0KPiBJIHRoaW5rIGlzIGlzIG1vcmUgYWNjdXJhdGUgdG8gc2F5Og0KPiANCj4gVXNlIG9mIHN0 YWxlIE1QTFMgb3IgSUdQIHJvdXRpbmcgaW5mb3JtYXRpb24gY291bGQgY2F1c2UgYSBQTVMgbW9u aXRvcmluZw0KPiBwYWNrZXQgdG8gbGVhdmUgdGhlIGRvbWFpbiB3aGVyZSBpdCBvcmlnaW5hdGVk LiBQTVMgbW9uaXRvcmluZyBwYWNrZXRzIHNob3VsZA0KPiBub3QgYmUgc2VudCB1c2luZyBzdGFs ZSBNUExTIG9yIElHUCByb3V0aW5nIGluZm9ybWF0aW9uLg0KPiANCj4gQXMgaXQgaXMgbmVjZXNz YXJ5IHRvIGtub3cgdGhhdCB0aGUgaW5mb3JtYXRpb24gaXMgc3RhbGUgaXMgb3JkZXIgdG8gZm9s bG93IHRoZQ0KPiBpbnN0cnVjdGlvbiwgYXMgaXMgdGhlIGNhc2Ugd2l0aCBmb3IgZXhhbXBsZSBj b252ZXJnZW5jZSBldmVudHMgdGhhdCBtYXkgYmUNCj4gb25nb2luZyBhdCB0aGUgdGltZSBvZiBk aWFnbm9zdGljIG1lYXN1cmVtZW50Lg0KPiANCg0KDQpBZ3JlZWQuIFdlIGFkZGVkIHRoaXMgdGV4 dC4gTm90ZSBwbGVhc2UgdGhhdCBhZGRpdGlvbmFsbHksIHdlIHNpZ25pZmljYW50bHkgcmV2YW1w ZWQgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNClRoYW5rcyENCg0KPiAN Cg0K4oCUDQpDYXJsb3MgUGlnbmF0YXJvLCBjYXJsb3NAY2lzY28uY29tDQoNCuKAnFNvbWV0aW1l cyBJIHVzZSBiaWcgd29yZHMgdGhhdCBJIGRvIG5vdCBmdWxseSB1bmRlcnN0YW5kLCB0byBtYWtl IG15c2VsZiBzb3VuZCBtb3JlIHBob3Rvc3ludGhlc2lzLiINCg0K From nobody Sat Jul 1 14:07:12 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144BC124D6C; Sat, 1 Jul 2017 14:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_HELO_PASS=-0.001, 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=joelhalpern.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 eujk0Bfw9d9V; Sat, 1 Jul 2017 14:07:03 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 5126A127735; Sat, 1 Jul 2017 14:07:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 37F78403E92; Sat, 1 Jul 2017 14:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1498943223; bh=tBtXPxa3iFZjZJnN7u20NQFekBiq7+tQIy/QTv72YYY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=N7xYccuFND3s7jkyMhEXmrtM7leqFofy83jtl6JYUpFLO8ePUCy20LK2eL+TonW7d 5J7wB+x6JTtWOm/u4dkAxQVEme/X25wM2J3nAGq3i/1T98FM4tt/G0zo4xyKc/ikHm hwTXwy7ZcPXIrTsCvq8nZFMOfxBYU3oMfQmnCZpw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 3F6661C0049; Sat, 1 Jul 2017 14:07:02 -0700 (PDT) To: "Carlos Pignataro (cpignata)" Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "ietf@ietf.org" , "draft-ietf-spring-oam-usecase.all@ietf.org" References: <149813817013.30481.17524594111387704082@ietfa.amsl.com> <6B35D999-331B-4DB3-A9F1-C2BEF4EC0944@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Sat, 1 Jul 2017 17:07:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <6B35D999-331B-4DB3-A9F1-C2BEF4EC0944@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Rtgdir last call review of draft-ietf-spring-oam-usecase-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 21:07:05 -0000 Almost. I believe the earlier email had agreed to replace pre-SR with non-SR. There are two uses of pre-SR stil in the document. Otherwise, yes, these address my comments. Yours, Joel On 7/1/17 4:52 PM, Carlos Pignataro (cpignata) wrote: > Thanks for your review, Joel! > > Revision -07, just submitted, should address all your concerns and > suggestions. Please let us know otherwise. > > Thanks, > > — Carlos. > >> On Jun 22, 2017, at 9:29 AM, Joel Halpern > > wrote: >> >> Reviewer: Joel Halpern >> Review result: Has Nits >> >> This is a rtg-dir requested review. >> >> Summary: Ready for publication as an Informational RFC with some minor >> items >> that should be considered. >> >> Major: N/A >> >> Minor: >> The introduction treats having a single centralized monitoring >> system as an >> unalloyed positive. To set context properly, it would seem more >> appropriate to note that many operators find such central systems >> useful, >> and the approach described here enables that when desired. >> >> The reference in the introduction to IGP topology discovery is very >> confusing. "Adding MPLS topology awareness to an IGP speaking >> device hence >> enables a simple and scalable data plane based monitoring >> mechanism." As >> noted later in the document, link-state IGPs provide topology >> awareness. >> So what is this part of the introduction trying to say? >> (Side-note, not >> all IGPs are link state, although the applicability of Babel or RIP >> to MPLS >> Segment Routing is clearly outside the scope of this document.) >> >> In section 5.1 in discussing path trace the reference is to RFC >> 4379 which >> is a clear source for path trace. However, the text refers to "tree >> trace". While that may have become a common phrase for the usage, >> it is >> not used in RFC 4379. The term should either be explain, include a >> suitable reference, or not be used. >> >> In section 5.3 on fault isolation, the text notes that the only >> difference >> between the test which succeeds and that which fails is the >> difference the >> the adjacency SID. The text then goes on to say "Assuming the >> second probe >> has been routed correctly, the fault must have been occurring in R2 >> which >> didn't forward the packet to the interface identified by its >> Adjacency SID >> 663." That does not follow. If the link as failed in an undetected >> fashion >> (either in one direction or both), R2 would be functioning fine and the >> symptom would be the same. Remotely detecting the difference between R2 >> failing to forward and the link not working seems a much harder task. >> >> The claim that the PMS can / should (intent is ambiguous) notify >> the router >> when it detects a path failure raises a number of issues. It is >> not at >> all clear what the router would do with the notification. (e.g. If it >> removed the link from service, then future monitoring would not be >> able to >> detect that the link was working.) Either this needs to become a >> significantly larger section, or (more likely) the text needs to be >> removed. >> >> Editorial: >> Chapter 7 is titled dealing with non-SR environments. Which makes >> sense. >> The text then switches to using "pre-SR" instead of "non-SR". I would >> recommend that all uses of "pre-SR" be changed to "non-SR". >> > > — > Carlos Pignataro, carlos@cisco.com > > /“Sometimes I use big words that I do not fully understand, to make > myself sound more photosynthesis."/ > From nobody Sat Jul 1 22:15:59 2017 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21455129B38; Sat, 1 Jul 2017 22:15:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149897255810.17384.17923466885987045239@ietfa.amsl.com> Date: Sat, 01 Jul 2017 22:15:58 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-07.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 05:15:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-07.txt Pages : 30 Date : 2017-07-01 Abstract: This document defines a YANG data model ([RFC6020], [RFC7950]) for segment routing ([I-D.ietf-spring-segment-routing]) configuration and operation. This YANG model is intended to be used on network elements to configure or operate segment routing. This document defines also generic containers that SHOULD be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-07 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-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 Sun Jul 2 06:09:23 2017 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE95C129459; Sun, 2 Jul 2017 06:09:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149900096175.17218.17005658627582436586@ietfa.amsl.com> Date: Sun, 02 Jul 2017 06:09:21 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-conflict-resolution-05.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 13:09:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : Segment Routing MPLS Conflict Resolution Authors : Les Ginsberg Peter Psenak Stefano Previdi Martin Pilka Filename : draft-ietf-spring-conflict-resolution-05.txt Pages : 22 Date : 2017-07-02 Abstract: In support of Segment Routing (SR) for an MPLS data plane routing protocols advertise a variety of identifiers used to define the segments which direct forwarding of packets. In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required. This document defines the policies used to resolve these occurrences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 https://datatracker.ietf.org/doc/html/draft-ietf-spring-conflict-resolution-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-conflict-resolution-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 2 06:13:58 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49A1129459 for ; Sun, 2 Jul 2017 06:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 V8h3eXYdANLA for ; Sun, 2 Jul 2017 06:13:55 -0700 (PDT) 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 13DDE12706D for ; Sun, 2 Jul 2017 06:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2612; q=dns/txt; s=iport; t=1499001235; x=1500210835; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RtWk6cNpTYSmBmaFYooaXzYAQ1x00XKHHhWVTvphNMM=; b=XCVVEFILaYaG1q4jb0tbW1mJ3grusj2d0soyOTuK+HUnwxVGpx8Vd4gn FEqPk7YsmQmULXc9MqntrSQb1mFnB2xsLXWj+CloGI2k7Z8SHve9hpw2c M+ChdWh3bMrlGhDO8oQK6scvM6KZ/roRh1exCwRLU+Y3fBxwSVPkMG/QI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAABJ8VhZ/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1ljgQ4HjX6RapV9ghEhDYUfTwKDGT8YAQIBAQEBAQEBax0LhRg?= =?us-ascii?q?BAQEBAwEBODQXBAIBCBEEAQEfCQcnCxQJCAIEEwiKJxC0SYtKAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYMng0yBYYMkgyaHOAWefwKHRYwxghVWhHSKR5UvAR84gQp?= =?us-ascii?q?1FR8qhRMcgWZ2iC2BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,297,1496102400"; d="scan'208";a="263142327" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jul 2017 13:13:48 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v62DDmfs023474 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 2 Jul 2017 13:13:48 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 2 Jul 2017 08:13:47 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Sun, 2 Jul 2017 08:13:47 -0500 From: "Les Ginsberg (ginsberg)" To: "spring@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-conflict-resolution-05.txt Thread-Index: AQHS8zRx6wH5NIzZ/Uicje4j8kItcaJAgsrg Date: Sun, 2 Jul 2017 13:13:47 +0000 Message-ID: References: <149900096175.17218.17005658627582436586@ietfa.amsl.com> In-Reply-To: <149900096175.17218.17005658627582436586@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.3.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-conflict-resolution-05.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 13:13:57 -0000 This new version corrects errors/omissions in the definition of the generic= algorithms for detecting Prefix/SID conflicts. Some additional examples were also added. When responding to the recently started WG Last Call please review this ver= sion. Les > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Sunday, July 02, 2017 6:09 AM > To: i-d-announce@ietf.org > Cc: spring@ietf.org > Subject: [spring] I-D Action: draft-ietf-spring-conflict-resolution-05.tx= t >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Source Packet Routing in Networking of t= he > IETF. >=20 > Title : Segment Routing MPLS Conflict Resolution > Authors : Les Ginsberg > Peter Psenak > Stefano Previdi > Martin Pilka > Filename : draft-ietf-spring-conflict-resolution-05.txt > Pages : 22 > Date : 2017-07-02 >=20 > Abstract: > In support of Segment Routing (SR) for an MPLS data plane routing > protocols advertise a variety of identifiers used to define the > segments which direct forwarding of packets. In cases where the > information advertised by a given protocol instance is either > internally inconsistent or conflicts with advertisements from another > protocol instance a means of achieving consistent forwarding behavior > in the network is required. This document defines the policies used > to resolve these occurrences. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 > https://datatracker.ietf.org/doc/html/draft-ietf-spring-conflict-resoluti= on-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-conflict-resolution= -05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Sun Jul 2 12:10:51 2017 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CE31270A7; Sun, 2 Jul 2017 12:10:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149902264380.17364.14949670117918919593@ietfa.amsl.com> Date: Sun, 02 Jul 2017 12:10:43 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-oam-usecase-08.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 19:10:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : A Scalable and Topology-Aware MPLS Dataplane Monitoring System Authors : Ruediger Geib Clarence Filsfils Carlos Pignataro Nagendra Kumar Filename : draft-ietf-spring-oam-usecase-08.txt Pages : 18 Date : 2017-07-02 Abstract: This document describes features of a path monitoring system and related use cases. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS Ping and LSP Trace, in a very complementary way. MPLS topology awareness reduces management and control plane involvement of OAM measurements while enabling new OAM features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-oam-usecase-08 https://datatracker.ietf.org/doc/html/draft-ietf-spring-oam-usecase-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-oam-usecase-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 Sun Jul 2 12:11:26 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEF3124BE8; Sun, 2 Jul 2017 12:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 SS7-utQEhPxL; Sun, 2 Jul 2017 12:11:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3937127599; Sun, 2 Jul 2017 12:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16034; q=dns/txt; s=iport; t=1499022676; x=1500232276; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xOhnQoX6eRJoo3rSyRPgihqvUgxksSfN0AXJEQENux0=; b=ey0wMdnkogUHEJkEaZJqsxekTap5V76FrkFkG/yAWT9X0S9qxWo/x2Bl T4DGxXW6hgZu/f5Z4r4vp44rIS8hbZjEtT2J964Mh2MTg37OfDzgzLovl VjFUHnWfYAS1fZbsmdfu1+ZnSnVuKincNjN4IS1bRXoGCxPmrAReoiZSI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQCbRFlZ/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1mBcQeNfpFGkHSFK4IRhhwCGoJ/PxgBAgEBAQEBAQFrKIUZBiN?= =?us-ascii?q?WEAIBCD8DAgICMBQRAgQOBYlLZLFUgiaLSAEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R2DJ4NMgWErC4JuhDsSAYMvMIIxBYlPiFaFA4dXApN/ggyFSopHlS8BHzh/C3U?= =?us-ascii?q?VWwGFAByBZnaGUIEjgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,299,1496102400"; d="scan'208,217";a="448511865" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2017 19:11:15 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v62JBEkp008581 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 2 Jul 2017 19:11:14 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 2 Jul 2017 15:11:13 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sun, 2 Jul 2017 15:11:13 -0400 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" CC: "rtg-dir@ietf.org" , "spring@ietf.org" , "ietf@ietf.org" , "draft-ietf-spring-oam-usecase.all@ietf.org" Thread-Topic: Rtgdir last call review of draft-ietf-spring-oam-usecase-06 Thread-Index: AQHS61uWxVbWnw4SLk2wgKSt4LG4WKI/xD6AgAAED4CAAXH7gA== Date: Sun, 2 Jul 2017 19:11:13 +0000 Message-ID: <6B1007C6-4AE8-4244-89D6-392922984AE7@cisco.com> References: <149813817013.30481.17524594111387704082@ietfa.amsl.com> <6B35D999-331B-4DB3-A9F1-C2BEF4EC0944@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.118.116.131] Content-Type: multipart/alternative; boundary="_000_6B1007C64AE8424489D6392922984AE7ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Rtgdir last call review of draft-ietf-spring-oam-usecase-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 19:11:18 -0000 --_000_6B1007C64AE8424489D6392922984AE7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91LCBKb2VsLCB3ZWxsIHNwb3R0ZWQuIEFwb2xvZ2llcyB3ZSBjaGFuZ2VkIGFsbCBp bnN0YW5jZXMgZXhjZXB0IGZvciB0d28uIFRoaXMgaXMgbm93IGZpeGVkIGluIC0wOC4NCg0KVGhh bmtzIQ0KDQrigJQgQ2FybG9zLg0KDQpPbiBKdWwgMSwgMjAxNywgYXQgNTowNyBQTSwgSm9lbCBN LiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t Pj4gd3JvdGU6DQoNCkFsbW9zdC4NCkkgYmVsaWV2ZSB0aGUgZWFybGllciBlbWFpbCBoYWQgYWdy ZWVkIHRvIHJlcGxhY2UgcHJlLVNSIHdpdGggbm9uLVNSLiBUaGVyZSBhcmUgdHdvIHVzZXMgb2Yg cHJlLVNSIHN0aWwgaW4gdGhlIGRvY3VtZW50Lg0KDQpPdGhlcndpc2UsIHllcywgdGhlc2UgYWRk cmVzcyBteSBjb21tZW50cy4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDcvMS8xNyA0OjUyIFBNLCBD YXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6DQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3 LCBKb2VsIQ0KUmV2aXNpb24gLTA3LCBqdXN0IHN1Ym1pdHRlZCwgc2hvdWxkIGFkZHJlc3MgYWxs IHlvdXIgY29uY2VybnMgYW5kIHN1Z2dlc3Rpb25zLiBQbGVhc2UgbGV0IHVzIGtub3cgb3RoZXJ3 aXNlLg0KVGhhbmtzLA0K4oCUIENhcmxvcy4NCk9uIEp1biAyMiwgMjAxNywgYXQgOToyOSBBTSwg Sm9lbCBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3cm90ZToNCg0KUmV2aWV3ZXI6IEpv ZWwgSGFscGVybg0KUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCg0KVGhpcyBpcyBhIHJ0Zy1kaXIg cmVxdWVzdGVkIHJldmlldy4NCg0KU3VtbWFyeTogUmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIGFu IEluZm9ybWF0aW9uYWwgUkZDIHdpdGggc29tZSBtaW5vciBpdGVtcw0KdGhhdCBzaG91bGQgYmUg Y29uc2lkZXJlZC4NCg0KTWFqb3I6IE4vQQ0KDQpNaW5vcjoNCiAgVGhlIGludHJvZHVjdGlvbiB0 cmVhdHMgaGF2aW5nIGEgc2luZ2xlIGNlbnRyYWxpemVkIG1vbml0b3Jpbmcgc3lzdGVtIGFzIGFu DQogIHVuYWxsb3llZCBwb3NpdGl2ZS4gIFRvIHNldCBjb250ZXh0IHByb3Blcmx5LCBpdCB3b3Vs ZCBzZWVtIG1vcmUNCiAgYXBwcm9wcmlhdGUgdG8gbm90ZSB0aGF0IG1hbnkgb3BlcmF0b3JzIGZp bmQgc3VjaCBjZW50cmFsIHN5c3RlbXMgdXNlZnVsLA0KICBhbmQgdGhlIGFwcHJvYWNoIGRlc2Ny aWJlZCBoZXJlIGVuYWJsZXMgdGhhdCB3aGVuIGRlc2lyZWQuDQoNCiAgVGhlIHJlZmVyZW5jZSBp biB0aGUgaW50cm9kdWN0aW9uIHRvIElHUCB0b3BvbG9neSBkaXNjb3ZlcnkgaXMgdmVyeQ0KICBj b25mdXNpbmcuICJBZGRpbmcgTVBMUyB0b3BvbG9neSBhd2FyZW5lc3MgdG8gYW4gSUdQIHNwZWFr aW5nIGRldmljZSBoZW5jZQ0KICBlbmFibGVzIGEgc2ltcGxlIGFuZCBzY2FsYWJsZSBkYXRhIHBs YW5lIGJhc2VkIG1vbml0b3JpbmcgbWVjaGFuaXNtLiIgIEFzDQogIG5vdGVkIGxhdGVyIGluIHRo ZSBkb2N1bWVudCwgbGluay1zdGF0ZSBJR1BzIHByb3ZpZGUgdG9wb2xvZ3kgYXdhcmVuZXNzLg0K ICBTbyB3aGF0IGlzIHRoaXMgcGFydCBvZiB0aGUgaW50cm9kdWN0aW9uIHRyeWluZyB0byBzYXk/ ICAoU2lkZS1ub3RlLCBub3QNCiAgYWxsIElHUHMgYXJlIGxpbmsgc3RhdGUsIGFsdGhvdWdoIHRo ZSBhcHBsaWNhYmlsaXR5IG9mIEJhYmVsIG9yIFJJUCB0byBNUExTDQogIFNlZ21lbnQgUm91dGlu ZyBpcyBjbGVhcmx5IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuKQ0KDQogIElu IHNlY3Rpb24gNS4xIGluIGRpc2N1c3NpbmcgcGF0aCB0cmFjZSB0aGUgcmVmZXJlbmNlIGlzIHRv IFJGQyA0Mzc5IHdoaWNoDQogIGlzIGEgY2xlYXIgc291cmNlIGZvciBwYXRoIHRyYWNlLiAgSG93 ZXZlciwgdGhlIHRleHQgcmVmZXJzIHRvICJ0cmVlDQogIHRyYWNlIi4gIFdoaWxlIHRoYXQgbWF5 IGhhdmUgYmVjb21lIGEgY29tbW9uIHBocmFzZSBmb3IgdGhlIHVzYWdlLCBpdCBpcw0KICBub3Qg dXNlZCBpbiBSRkMgNDM3OS4gIFRoZSB0ZXJtIHNob3VsZCBlaXRoZXIgYmUgZXhwbGFpbiwgaW5j bHVkZSBhDQogIHN1aXRhYmxlIHJlZmVyZW5jZSwgb3Igbm90IGJlIHVzZWQuDQoNCiBJbiBzZWN0 aW9uIDUuMyBvbiBmYXVsdCBpc29sYXRpb24sIHRoZSB0ZXh0IG5vdGVzIHRoYXQgdGhlIG9ubHkg ZGlmZmVyZW5jZQ0KIGJldHdlZW4gdGhlIHRlc3Qgd2hpY2ggc3VjY2VlZHMgYW5kIHRoYXQgd2hp Y2ggZmFpbHMgaXMgdGhlIGRpZmZlcmVuY2UgdGhlDQogdGhlIGFkamFjZW5jeSBTSUQuICBUaGUg dGV4dCB0aGVuIGdvZXMgb24gdG8gc2F5ICJBc3N1bWluZyB0aGUgc2Vjb25kIHByb2JlDQogaGFz IGJlZW4gcm91dGVkIGNvcnJlY3RseSwgdGhlIGZhdWx0IG11c3QgaGF2ZSBiZWVuIG9jY3Vycmlu ZyBpbiBSMiB3aGljaA0KIGRpZG4ndCBmb3J3YXJkIHRoZSBwYWNrZXQgdG8gdGhlIGludGVyZmFj ZSBpZGVudGlmaWVkIGJ5IGl0cyBBZGphY2VuY3kgU0lEDQogNjYzLiIgIFRoYXQgZG9lcyBub3Qg Zm9sbG93LiAgSWYgdGhlIGxpbmsgYXMgZmFpbGVkIGluIGFuIHVuZGV0ZWN0ZWQgZmFzaGlvbg0K IChlaXRoZXIgaW4gb25lIGRpcmVjdGlvbiBvciBib3RoKSwgUjIgd291bGQgYmUgZnVuY3Rpb25p bmcgZmluZSBhbmQgdGhlDQogc3ltcHRvbSB3b3VsZCBiZSB0aGUgc2FtZS4gIFJlbW90ZWx5IGRl dGVjdGluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFIyDQogZmFpbGluZyB0byBmb3J3YXJkIGFu ZCB0aGUgbGluayBub3Qgd29ya2luZyBzZWVtcyBhIG11Y2ggaGFyZGVyIHRhc2suDQoNCiAgVGhl IGNsYWltIHRoYXQgdGhlIFBNUyBjYW4gLyBzaG91bGQgKGludGVudCBpcyBhbWJpZ3VvdXMpIG5v dGlmeSB0aGUgcm91dGVyDQogIHdoZW4gaXQgZGV0ZWN0cyBhIHBhdGggZmFpbHVyZSByYWlzZXMg YSBudW1iZXIgb2YgaXNzdWVzLiAgIEl0IGlzIG5vdCBhdA0KICBhbGwgY2xlYXIgd2hhdCB0aGUg cm91dGVyIHdvdWxkIGRvIHdpdGggdGhlIG5vdGlmaWNhdGlvbi4gIChlLmcuIElmIGl0DQogIHJl bW92ZWQgdGhlIGxpbmsgZnJvbSBzZXJ2aWNlLCB0aGVuIGZ1dHVyZSBtb25pdG9yaW5nIHdvdWxk IG5vdCBiZSBhYmxlIHRvDQogIGRldGVjdCB0aGF0IHRoZSBsaW5rIHdhcyB3b3JraW5nLikgIEVp dGhlciB0aGlzIG5lZWRzIHRvIGJlY29tZSBhDQogIHNpZ25pZmljYW50bHkgbGFyZ2VyIHNlY3Rp b24sIG9yIChtb3JlIGxpa2VseSkgdGhlIHRleHQgbmVlZHMgdG8gYmUgcmVtb3ZlZC4NCg0KRWRp dG9yaWFsOg0KICBDaGFwdGVyIDcgaXMgdGl0bGVkIGRlYWxpbmcgd2l0aCBub24tU1IgZW52aXJv bm1lbnRzLiAgV2hpY2ggbWFrZXMgc2Vuc2UuDQogIFRoZSB0ZXh0IHRoZW4gc3dpdGNoZXMgdG8g dXNpbmcgInByZS1TUiIgaW5zdGVhZCBvZiAibm9uLVNSIi4gIEkgd291bGQNCiAgcmVjb21tZW5k IHRoYXQgYWxsIHVzZXMgb2YgInByZS1TUiIgYmUgY2hhbmdlZCB0byAibm9uLVNSIi4NCg0K4oCU DQpDYXJsb3MgUGlnbmF0YXJvLCBjYXJsb3NAY2lzY28uY29tPG1haWx0bzpjYXJsb3NAY2lzY28u Y29tPiA8bWFpbHRvOmNhcmxvc0BjaXNjby5jb20+DQov4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3 b3JkcyB0aGF0IEkgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5k IG1vcmUgcGhvdG9zeW50aGVzaXMuIi8NCg0K4oCUDQpDYXJsb3MgUGlnbmF0YXJvLCBjYXJsb3NA Y2lzY28uY29tPG1haWx0bzpjYXJsb3NAY2lzY28uY29tPg0KDQrigJxTb21ldGltZXMgSSB1c2Ug YmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFuZCwgdG8gbWFrZSBteXNlbGYg c291bmQgbW9yZSBwaG90b3N5bnRoZXNpcy4iDQoNCg== --_000_6B1007C64AE8424489D6392922984AE7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <362EA5C4B14AD84FB8EF340BAAB1854D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmsgeW91LCBKb2VsLCB3ZWxs IHNwb3R0ZWQuIEFwb2xvZ2llcyB3ZSBjaGFuZ2VkIGFsbCBpbnN0YW5jZXMgZXhjZXB0IGZvciB0 d28uIFRoaXMgaXMgbm93IGZpeGVkIGluIC0wOC4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDEsIDIwMTcsIGF0IDU6MDcgUE0sIEpvZWwg TS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIGNsYXNz PSIiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0i QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij5BbG1vc3QuPGJyIGNsYXNzPSIiPg0KSSBiZWxpZXZlIHRoZSBlYXJsaWVyIGVtYWlsIGhhZCBh Z3JlZWQgdG8gcmVwbGFjZSBwcmUtU1Igd2l0aCBub24tU1IuIFRoZXJlIGFyZSB0d28gdXNlcyBv ZiBwcmUtU1Igc3RpbCBpbiB0aGUgZG9jdW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KT3RoZXJ3aXNlLCB5ZXMsIHRoZXNlIGFkZHJlc3MgbXkgY29tbWVudHMuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KWW91cnMsPGJyIGNsYXNzPSIiPg0KSm9lbDxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCk9uIDcvMS8xNyA0OjUyIFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGln bmF0YSkgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+VGhhbmtzIGZvciB5b3VyIHJldmlldywgSm9lbCE8YnIgY2xhc3M9IiI+DQpSZXZpc2lvbiAt MDcsIGp1c3Qgc3VibWl0dGVkLCBzaG91bGQgYWRkcmVzcyBhbGwgeW91ciBjb25jZXJucyBhbmQg c3VnZ2VzdGlvbnMuIFBsZWFzZSBsZXQgdXMga25vdyBvdGhlcndpc2UuPGJyIGNsYXNzPSIiPg0K VGhhbmtzLDxiciBjbGFzcz0iIj4NCuKAlCBDYXJsb3MuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gSnVuIDIyLCAyMDE3LCBhdCA5OjI5IEFNLCBKb2Vs IEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiBjbGFzcz0i Ij5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20iIGNsYXNzPSIiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7 IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClJldmlld2VyOiBKb2VsIEhhbHBl cm48YnIgY2xhc3M9IiI+DQpSZXZpZXcgcmVzdWx0OiBIYXMgTml0czxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NClRoaXMgaXMgYSBydGctZGlyIHJlcXVlc3RlZCByZXZpZXcuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KU3VtbWFyeTogUmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIGFu IEluZm9ybWF0aW9uYWwgUkZDIHdpdGggc29tZSBtaW5vciBpdGVtczxiciBjbGFzcz0iIj4NCnRo YXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTWFq b3I6IE4vQTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk1pbm9yOjxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwO1RoZSBpbnRyb2R1Y3Rpb24gdHJlYXRzIGhhdmluZyBhIHNpbmdsZSBjZW50 cmFsaXplZCBtb25pdG9yaW5nIHN5c3RlbSBhcyBhbjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw O3VuYWxsb3llZCBwb3NpdGl2ZS4gJm5ic3A7VG8gc2V0IGNvbnRleHQgcHJvcGVybHksIGl0IHdv dWxkIHNlZW0gbW9yZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2FwcHJvcHJpYXRlIHRvIG5v dGUgdGhhdCBtYW55IG9wZXJhdG9ycyBmaW5kIHN1Y2ggY2VudHJhbCBzeXN0ZW1zIHVzZWZ1bCw8 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDthbmQgdGhlIGFwcHJvYWNoIGRlc2NyaWJlZCBoZXJl IGVuYWJsZXMgdGhhdCB3aGVuIGRlc2lyZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7VGhlIHJlZmVyZW5jZSBpbiB0aGUgaW50cm9kdWN0aW9uIHRvIElHUCB0b3Bv bG9neSBkaXNjb3ZlcnkgaXMgdmVyeTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2NvbmZ1c2lu Zy4gJnF1b3Q7QWRkaW5nIE1QTFMgdG9wb2xvZ3kgYXdhcmVuZXNzIHRvIGFuIElHUCBzcGVha2lu ZyBkZXZpY2UgaGVuY2U8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtlbmFibGVzIGEgc2ltcGxl IGFuZCBzY2FsYWJsZSBkYXRhIHBsYW5lIGJhc2VkIG1vbml0b3JpbmcgbWVjaGFuaXNtLiZxdW90 OyAmbmJzcDtBczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO25vdGVkIGxhdGVyIGluIHRoZSBk b2N1bWVudCwgbGluay1zdGF0ZSBJR1BzIHByb3ZpZGUgdG9wb2xvZ3kgYXdhcmVuZXNzLjxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwO1NvIHdoYXQgaXMgdGhpcyBwYXJ0IG9mIHRoZSBpbnRyb2R1 Y3Rpb24gdHJ5aW5nIHRvIHNheT8gJm5ic3A7KFNpZGUtbm90ZSwgbm90PGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7YWxsIElHUHMgYXJlIGxpbmsgc3RhdGUsIGFsdGhvdWdoIHRoZSBhcHBsaWNh YmlsaXR5IG9mIEJhYmVsIG9yIFJJUCB0byBNUExTPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 U2VnbWVudCBSb3V0aW5nIGlzIGNsZWFybHkgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudC4pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7SW4gc2VjdGlv biA1LjEgaW4gZGlzY3Vzc2luZyBwYXRoIHRyYWNlIHRoZSByZWZlcmVuY2UgaXMgdG8gUkZDIDQz Nzkgd2hpY2g8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtpcyBhIGNsZWFyIHNvdXJjZSBmb3Ig cGF0aCB0cmFjZS4gJm5ic3A7SG93ZXZlciwgdGhlIHRleHQgcmVmZXJzIHRvICZxdW90O3RyZWU8 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDt0cmFjZSZxdW90Oy4gJm5ic3A7V2hpbGUgdGhhdCBt YXkgaGF2ZSBiZWNvbWUgYSBjb21tb24gcGhyYXNlIGZvciB0aGUgdXNhZ2UsIGl0IGlzPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7bm90IHVzZWQgaW4gUkZDIDQzNzkuICZuYnNwO1RoZSB0ZXJt IHNob3VsZCBlaXRoZXIgYmUgZXhwbGFpbiwgaW5jbHVkZSBhPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7c3VpdGFibGUgcmVmZXJlbmNlLCBvciBub3QgYmUgdXNlZC48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQombmJzcDtJbiBzZWN0aW9uIDUuMyBvbiBmYXVsdCBpc29sYXRpb24sIHRo ZSB0ZXh0IG5vdGVzIHRoYXQgdGhlIG9ubHkgZGlmZmVyZW5jZTxiciBjbGFzcz0iIj4NCiZuYnNw O2JldHdlZW4gdGhlIHRlc3Qgd2hpY2ggc3VjY2VlZHMgYW5kIHRoYXQgd2hpY2ggZmFpbHMgaXMg dGhlIGRpZmZlcmVuY2UgdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7dGhlIGFkamFjZW5jeSBTSUQu ICZuYnNwO1RoZSB0ZXh0IHRoZW4gZ29lcyBvbiB0byBzYXkgJnF1b3Q7QXNzdW1pbmcgdGhlIHNl Y29uZCBwcm9iZTxiciBjbGFzcz0iIj4NCiZuYnNwO2hhcyBiZWVuIHJvdXRlZCBjb3JyZWN0bHks IHRoZSBmYXVsdCBtdXN0IGhhdmUgYmVlbiBvY2N1cnJpbmcgaW4gUjIgd2hpY2g8YnIgY2xhc3M9 IiI+DQombmJzcDtkaWRuJ3QgZm9yd2FyZCB0aGUgcGFja2V0IHRvIHRoZSBpbnRlcmZhY2UgaWRl bnRpZmllZCBieSBpdHMgQWRqYWNlbmN5IFNJRDxiciBjbGFzcz0iIj4NCiZuYnNwOzY2My4mcXVv dDsgJm5ic3A7VGhhdCBkb2VzIG5vdCBmb2xsb3cuICZuYnNwO0lmIHRoZSBsaW5rIGFzIGZhaWxl ZCBpbiBhbiB1bmRldGVjdGVkIGZhc2hpb248YnIgY2xhc3M9IiI+DQombmJzcDsoZWl0aGVyIGlu IG9uZSBkaXJlY3Rpb24gb3IgYm90aCksIFIyIHdvdWxkIGJlIGZ1bmN0aW9uaW5nIGZpbmUgYW5k IHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwO3N5bXB0b20gd291bGQgYmUgdGhlIHNhbWUuICZuYnNw O1JlbW90ZWx5IGRldGVjdGluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFIyPGJyIGNsYXNzPSIi Pg0KJm5ic3A7ZmFpbGluZyB0byBmb3J3YXJkIGFuZCB0aGUgbGluayBub3Qgd29ya2luZyBzZWVt cyBhIG11Y2ggaGFyZGVyIHRhc2suPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7VGhlIGNsYWltIHRoYXQgdGhlIFBNUyBjYW4gLyBzaG91bGQgKGludGVudCBpcyBhbWJp Z3VvdXMpIG5vdGlmeSB0aGUgcm91dGVyPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7d2hlbiBp dCBkZXRlY3RzIGEgcGF0aCBmYWlsdXJlIHJhaXNlcyBhIG51bWJlciBvZiBpc3N1ZXMuICZuYnNw OyZuYnNwO0l0IGlzIG5vdCBhdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2FsbCBjbGVhciB3 aGF0IHRoZSByb3V0ZXIgd291bGQgZG8gd2l0aCB0aGUgbm90aWZpY2F0aW9uLiAmbmJzcDsoZS5n LiBJZiBpdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3JlbW92ZWQgdGhlIGxpbmsgZnJvbSBz ZXJ2aWNlLCB0aGVuIGZ1dHVyZSBtb25pdG9yaW5nIHdvdWxkIG5vdCBiZSBhYmxlIHRvPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7ZGV0ZWN0IHRoYXQgdGhlIGxpbmsgd2FzIHdvcmtpbmcuKSAm bmJzcDtFaXRoZXIgdGhpcyBuZWVkcyB0byBiZWNvbWUgYTxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwO3NpZ25pZmljYW50bHkgbGFyZ2VyIHNlY3Rpb24sIG9yIChtb3JlIGxpa2VseSkgdGhlIHRl eHQgbmVlZHMgdG8gYmUgcmVtb3ZlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpFZGl0 b3JpYWw6PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Q2hhcHRlciA3IGlzIHRpdGxlZCBkZWFs aW5nIHdpdGggbm9uLVNSIGVudmlyb25tZW50cy4gJm5ic3A7V2hpY2ggbWFrZXMgc2Vuc2UuPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7VGhlIHRleHQgdGhlbiBzd2l0Y2hlcyB0byB1c2luZyAm cXVvdDtwcmUtU1ImcXVvdDsgaW5zdGVhZCBvZiAmcXVvdDtub24tU1ImcXVvdDsuICZuYnNwO0kg d291bGQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtyZWNvbW1lbmQgdGhhdCBhbGwgdXNlcyBv ZiAmcXVvdDtwcmUtU1ImcXVvdDsgYmUgY2hhbmdlZCB0byAmcXVvdDtub24tU1ImcXVvdDsuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K4oCUPGJyIGNsYXNzPSIi Pg0KQ2FybG9zIFBpZ25hdGFybywgPGEgaHJlZj0ibWFpbHRvOmNhcmxvc0BjaXNjby5jb20iIGNs YXNzPSIiPmNhcmxvc0BjaXNjby5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86Y2FybG9zQGNp c2NvLmNvbSIgY2xhc3M9IiI+bWFpbHRvOmNhcmxvc0BjaXNjby5jb208L2E+Jmd0OzxiciBjbGFz cz0iIj4NCi/igJxTb21ldGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkg dW5kZXJzdGFuZCwgdG8gbWFrZSBteXNlbGYgc291bmQgbW9yZSBwaG90b3N5bnRoZXNpcy4mcXVv dDsvPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCuKAlDwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl OyIgY2xhc3M9IiI+DQpDYXJsb3MgUGlnbmF0YXJvLCZuYnNwOzxhIGhyZWY9Im1haWx0bzpjYXJs b3NAY2lzY28uY29tIiBjbGFzcz0iIj5jYXJsb3NAY2lzY28uY29tPC9hPjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxpIGNsYXNzPSIiPuKAnFNvbWV0aW1lcyBJIHVzZSBiaWcgd29yZHMg dGhhdCBJIGRvIG5vdCBmdWxseSB1bmRlcnN0YW5kLCB0byBtYWtlIG15c2VsZiBzb3VuZCBtb3Jl Jm5ic3A7cGhvdG9zeW50aGVzaXMuJnF1b3Q7PC9pPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_6B1007C64AE8424489D6392922984AE7ciscocom_-- From nobody Sun Jul 2 13:14:55 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB0E127867; Sun, 2 Jul 2017 13:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 7qpxMJUMceCp; Sun, 2 Jul 2017 13:14:40 -0700 (PDT) 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 ED09E126B72; Sun, 2 Jul 2017 13:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7424; q=dns/txt; s=iport; t=1499026480; x=1500236080; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=h5MY+zUcSfVXBpEr6VM9/QColp2+UV1VySd8aZYd1wQ=; b=AK9pkKAl61LoBsMNKzCmC+TcIdHSuPFU5xnpoYej9eQIGhIzhOkzqLaF Oz2omRPQ8pwDZfaaOkt3ZE21wYE/sFP7NQETxwc2ujBOkrpyOAdX/aL09 DMf+AJOBqoP9G0zFc/RrTPBraqZRQrmY+3uwCQUesr4PRc7I4RwrwJIqe c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AADiU1lZ/4gNJK1WBhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMsLWOBDgeNfpFGIpV9ghEshXACGoJ/PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBIxE3DgULAgEGAg4GBAICJgICAjAVEAIEDgUbigwIEJN4nWOCJotIA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4Icg0yBYSsLgm6EXIMhMIIxBZ5/Aod?= =?us-ascii?q?FgnqJQIIMhUqDcYZWlS8BHziBCnUVWwGFAByBZnaHc4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,299,1496102400"; d="scan'208";a="263247295" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jul 2017 20:14:30 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v62KETLU015124 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 2 Jul 2017 20:14:30 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 2 Jul 2017 16:14:29 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sun, 2 Jul 2017 16:14:29 -0400 From: "Carlos Pignataro (cpignata)" To: Pete Resnick CC: "gen-art@ietf.org" , "spring@ietf.org" , "ietf@ietf.org" , "draft-ietf-spring-oam-usecase.all@ietf.org" Thread-Topic: Genart last call review of draft-ietf-spring-oam-usecase-06 Thread-Index: AQHS8DzDWIhR6rTu8UG+oA8joThdh6JBQjKA Date: Sun, 2 Jul 2017 20:14:29 +0000 Message-ID: References: <149867468440.7527.6305996146978005032@ietfa.amsl.com> In-Reply-To: <149867468440.7527.6305996146978005032@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.118.116.131] Content-Type: text/plain; charset="utf-8" Content-ID: <15DAEEE9C75F9D4DBBAC78E11FC52853@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Genart last call review of draft-ietf-spring-oam-usecase-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 20:14:42 -0000 SGksIFBldGUsDQoNCk1hbnkgdGhhbmtzIGZvciB0aGUgdGltZSB0byByZWFkIGFuZCByZXZpZXcg dGhpcyBkb2N1bWVudCENCg0KTGlrZSBSdWVkaWdlciwgSSB3aWxsIGxldCB0aGUgc2hlcGhlcmQs IGNoYWlycywgYW5kIEFEIHdlaWdodCBpbiDigJQgYnV0IGluIHRoZSBtZWFudGltZSwgSSB3YW50 ZWQgdG8gb2ZmZXIgYSBjb3VwbGUgb2Ygb2JzZXJ2YXRpb25zIGZvciBjb25zaWRlcmF0aW9uLiBQ bGVhc2Ugc2VlIGlubGluZS4NCg0KDQo+IE9uIEp1biAyOCwgMjAxNywgYXQgMjozMSBQTSwgUGV0 ZSBSZXNuaWNrIDxwcmVzbmlja0BxdGkucXVhbGNvbW0uY29tPiB3cm90ZToNCj4gDQo+IFJldmll d2VyOiBQZXRlIFJlc25pY2sNCj4gUmV2aWV3IHJlc3VsdDogTm90IFJlYWR5DQo+IA0KPiBJIGFt IHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJh bCBBcmVhDQo+IFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50 cyBiZWluZyBwcm9jZXNzZWQNCj4gYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLiAgUGxl YXNlIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QNCj4gbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxs IGNvbW1lbnRzLg0KPiANCj4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZB USBhdA0KPiANCj4gPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZh cT4uDQo+IA0KPiBEb2N1bWVudDogZHJhZnQtaWV0Zi1zcHJpbmctb2FtLXVzZWNhc2UtMDYNCj4g UmV2aWV3ZXI6IFBldGUgUmVzbmljaw0KPiBSZXZpZXcgRGF0ZTogMjAxNy0wNi0yOA0KPiBJRVRG IExDIEVuZCBEYXRlOiAyMDE3LTA2LTMwDQo+IElFU0cgVGVsZWNoYXQgZGF0ZTogTm90IHNjaGVk dWxlZCBmb3IgYSB0ZWxlY2hhdA0KPiANCj4gU3VtbWFyeTogTm90IFJlYWR5IGZvciBwdWJsaWNh dGlvbiBhcyBJbmZvcm1hdGlvbmFsLCBidXQgbWlnaHQgYmUgUmVhZHkgZm9yDQo+IHB1YmxpY2F0 aW9uIGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiBNYWpvciBpc3N1ZXM6DQo+IA0KPiBUaGlz IGlzIGFuIGFkbWl0dGVkbHkgdW51c3VhbCByZXZpZXcuIEkgaGF2ZSByZWFkIHRocm91Z2ggdGhl IGVudGlyZSBkb2N1bWVudCwNCj4gYW5kIHRoZSB0ZWNobmljYWwgd29yayBzZWVtcyBmaW5lLCBi dXQgaXMgd2VsbCBiZXlvbmQgbXkgdGVjaG5pY2FsIGV4cGVydGlzZSwNCj4gc28gSSBjYW4ndCBy ZWFsbHkgY29tbWVudCBvbiB0aGUgdGVjaG5pY2FsIGNvcnJlY3RuZXNzLiBIb3dldmVyLCBpdCBp cw0KPiBhYnNvbHV0ZWx5IGNsZWFyIHRvIG1lIHRoYXQgdGhpcyBpcyAqbm90KiBhICJ1c2UgY2Fz ZSIgZG9jdW1lbnQgYXQgYWxsDQoNCkkgYWdyZWUgd2l0aCB0aGUgYXNzZXNzbWVudCB0aGF0IHRo aXMgaXMgbm90IGEg4oCcdXNlLWNhc2XigJ0gZG9jdW1lbnQgKGluIGEgc3RyaWN0IG9yIHRyYWRp dGlvbmFsIHNlbnNlKTsgdGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBkZXBsb3ltZW50IGNhc2Ug YW5kIGEgc29sdXRpb24gdG8gYSB1c2UgY2FzZSwgdXNpbmcgZXhpc3RpbmcgdGVjaG5vbG9neSBi bG9ja3MuIEl0IGRvZXMgbm90IGRlZmluZSBuZXcgcHJvdG9jb2wgbm9yIChtb3JlIGltcG9ydGFu dGx5KSBjcmVhdGVzIGludGVyb3BlcmFiaWxpdHkgY29uc2lkZXJhdGlvbnMuIA0KDQo+IGFuZCBJ DQo+IGRvbid0IHRoaW5rIGl0J3MgYXBwcm9wcmlhdGUgYXMgYW4gSW5mb3JtYXRpb25hbCBkb2N1 bWVudC4NCg0KTm93LCByZWdhcmRpbmcgdGhlIG1vc3QgYXBwcm9wcmlhdGUgaW50ZW5kZWQgc3Rh dHVzLCBJIGNvdWxkIHBlcnNvbmFsbHkgYXJndWUgYm90aCBzaWRlcywgYW5kIGZyYW5rbHksIEkg ZG8gbm90IGhhdmUgYSBzdHJvbmcgcHJlZmVyZW5jZSBvciBjb25jZXJuIGVpdGhlciB3YXkuIA0K DQpUaGUgbmV0IG9mIGl0IGlzIHRoYXQgdGhpcyAoaW5mb3JtYXRpb25hbC9zcGVjaWZpY2F0aW9u KSBkb2N1bWVudCBkb2VzIG5vdCBjcmVhdGUgcmVxdWlyZW1lbnRzIGZvciBTUFJJTkcgbm9kZXMs IGNoYW5nZXMgaW4gU1BSSU5HLCBub3IgZXhwb3NlcyBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4g SXQgYmFzaWNhbGx5IGxldmVyYWdlcyBhcy1pcyB0aGUgdW5kZXJseWluZyBjYXBhYmlsaXRpZXMg Y3JlYXRlZCB3aXRoIFNQUklORy4gRnJvbSB0aGF0IGFuZ2xlLCBJbmZvcm1hdGlvbmFsIGlzIGEg dmVyeSBhcHByb3ByaWF0ZSBmaXQuIE9uIHRoZSBvdGhlciBoYW5kLCBJIGRvIG5vdCBkaXNhZ3Jl ZSB3aXRoIHRoaXMgZG9jdW1lbnQgc3BlY2lmeWluZyBhIHN5c3RlbSwgYW5kIHRoZSBwbGF5LW9m LXdvcmRzIHRoYXQgcmVzdWx0cyBpbiBzdGFuZGFyZHMtdHJhY2sg4oCUIHNvIGl0IGlzIGEgc3Bl YyBmb3IgdGhlIHBhdGggbW9uaXRvcmluZyBzeXN0ZW0sIGJ1dCBwcm92aWRlcyBpbmZvcm1hdGlv biB0byB0aGUgbmV0d29yayBhbmQgdG8gU1BSSU5HIHNwZWNzIG9uIGhvdyB0aGUgbmV3IHRlY2gg Y2FuIGJlIHVzZWQuDQoNCk5ldC1uZXQsIEkgc2VlIEluZm9ybWF0aW9uYWwgYnV0IGNhbiB1bmRl cnN0YW5kIHlvdXIgcmF0aW9uYWxlLg0KDQpJbiBhbnkgY2FzZSwgd2hhdCBkb2VzIGNvbmNlcm4g bWUgbW9yZSBpcyB3aGV0aGVyIGEgcG90ZW50aWFsIGNoYW5nZSBvZiBpbnRlbmRlZCBzdGF0dXMg d291bGQgYWRkIHNpZ25pZmljYW50IGRlbGF5IGFuZCByZXNldCBwcm9jZXNzIHRpbWVycyBvbiBh IHRpbWVsaW5lIHRoYXQgaXMgYWxyZWFkeSBvdmVyc3RyZXRjaGVkIGFuZCBhIHZlcnkgc2xvdyBw cm9ncmVzc+KApg0KDQo+IFRoaXMgaXMgY2xlYXJseSBhDQo+ICpzcGVjaWZpY2F0aW9uKiBvZiBh IHBhdGggbW9uaXRvcmluZyBzeXN0ZW0uIEl0IGdpdmVzIGd1aWRhbmNlcyBhcyB0byByZXF1aXJl ZCwNCj4gcmVjb21tZW5kZWQsIGFuZCBvcHRpb25hbCBwYXJhbWV0ZXJzLCBhbmQgc3BlY2lmaWVz IGhvdyB0byB1c2UgZGlmZmVyZW50DQo+IHByb3RvY29sIHBpZWNlcy4gSXQgaXMgYXQgdGhlIHZl cnkgbGVhc3Qgd2hhdCBSRkMgMjAyNiByZWZlcnMgdG8gYXMgYW4NCj4gIkFwcGxpY2FiaWxpdHkg U3RhdGVtZW50IChBUykiIChzZWUgUkZDIDIwMjYsIHNlYy4gMy4yKS4gSXQgKm1pZ2h0KiBiZSBh IEJDUCwNCj4gYnV0IGl0IGlzIG5vdCBzdHJpY3RseSBnaXZpbmcgImNvbW1vbiBndWlkZWxpbmVz IGZvciBwb2xpY2llcyBhbmQgb3BlcmF0aW9ucyINCj4gKDIwMjYsIHNlYy4gNSksIHNvIEkgZG9u J3QgcmVhbGx5IHRoaW5rIHRoYXQncyByaWdodCwgYW5kIGluc3RlYWQgdGhpcyBzaG91bGQNCj4g YmUgb2ZmZXJlZCBmb3IgUHJvcG9zZWQgU3RhbmRhcmQuIEVpdGhlciB3YXksIEkgdGhpbmsgSW5m b3JtYXRpb25hbCBpcyBub3QNCj4gY29ycmVjdC4gSW1wb3J0YW50bHksIEkgdGhpbmsgdGhlcmUg aXMgYSBnb29kIGxpa2VsaWhvb2QgdGhhdCB0aGlzIGRvY3VtZW50IGhhcw0KPiBub3QgcmVjZWl2 ZWQgdGhlIGFwcHJvcHJpYXRlIGFtb3VudCBvZiByZXZpZXc7IHBlb3BsZSB0ZW5kIHRvIGlnbm9y ZQ0KPiBJbmZvcm1hdGlvbmFsICJ1c2UgY2FzZSIgZG9jdW1lbnRzLA0KDQpUaGlzLCBob3dldmVy LCBJIHRoaW5rIGlzIGFuIGluYXBwcm9wcmlhdGUgZXh0cmFwb2xhdGlvbi4gQWx0aG91Z2ggdGhl IHNoZXBoZXJkLCBXRyBhbmQgY2hhaXJzIGFscmVhZHkgY29uc2lkZXJlZCB0aGUgaW50ZW5kZWQg c3RhdHVzLCBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byByZS10aGluayB3aGF04oCZcyBiZXN0 IGZvciB0aGlzIGRvY3VtZW50IGluIHRoZSBjb250ZXh0IG9mIHRoZSBtZXJpdHMsIHN0cnVjdHVy ZSBhbmQgZ29hbHMuIEJ1dCBqdXN0aWZ5aW5nIGl0IG5vdCBiZWluZyBpbmZvcm1hdGlvbmFsIGJl Y2F1c2Ug4oCccGVvcGxlIHRlbmQgdG8gaWdub3JlIFvigKZd4oCdIHNlZW1zIGEgcmVkIGhlcnJp bmcuIA0KDQo+IGFuZCB0aGVyZSBoYXZlIGJlZW4gbm8gTGFzdCBDYWxsIGNvbW1lbnRzDQo+IGJl eW9uZCBKb2VsJ3MgUlRHIEFyZWEgUmV2aWV3Lg0KDQpXaXRoaW4gU1BSSU5HLCB0aGlzIGRvY3Vt ZW50IGRhdGVzIHRoZSBvcmlnaW5zIG9mIHRoZSBXRy4gSXQgd2FzIHByZXNlbnRlZCBpbiBtYW55 IFdHcyBudW1lcm91cyB0aW1lcyBhbmQgaXRlcmF0ZWQgdGhyb3VnaCBtYW55IHZlcnNpb25zICh3 aXRoaW4gdGhyZWUgZmlsZW5hbWVzKSBhcyB2YXJpb3VzIHJldmlld3MgY2FtZSBpbi4gSeKAmWQg cmVjb21tZW5kIHlvdSBhbHNvIGdvIGJhY2sgYW5kIGNoZWNrIHRoZSB0aW1lbGluZS4gSSB3b3Vs ZCBub3QgYWxzbyBtYWtlIGhhcmQgY29uY2x1c2lvbnMgYmFzZWQgb24gTEMgdHJhZmZpYy4NCg0K PiBFdmVuIGluIElFU0cgcmV2aWV3LCBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50DQo+IG9ubHkg dGFrZXMgdGhlIHNwb25zb3JpbmcgQUQgdG8gYXBwcm92ZTsgZXZlcnkgb3RoZXIgQUQgY2FuIHN1 bW1hcmlseSBpZ25vcmUNCj4gdGhlIGRvY3VtZW50LCBvciBldmVuIGJhbGxvdCBBQlNUQUlOLCBh bmQgdGhlIGRvY3VtZW50IHdpbGwgc3RpbGwgYmUgcHVibGlzaGVkDQo+ICh0aG91Z2ggdGhhdCBk b2VzIG5vdCBub3JtYWxseSBoYXBwZW4pLiBUaGlzIGRvY3VtZW50IHNob3VsZCBoYXZlIG11Y2gg bW9yZQ0KPiB0aGFuIHRoYXQgbGV2ZWwgb2YgcmV2aWV3LiBJIHN0cm9uZ2x5IHJlY29tbWVuZCB0 byB0aGUgV0cgYW5kIEFEIHRoYXQgdGhpcw0KPiBkb2N1bWVudCBiZSB3aXRoZHJhd24gYXMgYW4g SW5mb3JtYXRpb25hbCBkb2N1bWVudCBhbmQgcmVzdWJtaXR0ZWQgZm9yIFByb3Bvc2VkDQo+IFN0 YW5kYXJkIGFuZCBoYXZlIHRoYXQgbGV2ZWwgb2YgcmV2aWV3IGFuZCBzY3J1dGlueSBhcHBsaWVk IHRvIGl0Lg0KDQpBcyBJIHNhaWQsIEkgYW0gaGFwcHkgd2l0aCBlaXRoZXIgc3RhdHVzIGFuZCBj YW4gc2VlIGFyZ3VtZW50cyBib3RoIHdheXMuIEkgd291bGQgbm90IG9iamVjdCB0byBhIGNoYW5n ZS4gDQoNCkhvd2V2ZXIsIHBlcnNvbmFsbHksIEkgZG8gbm90IHNlZSB0aGUgbmVlZC4NCg0KPiAN Cj4gTWlub3IgaXNzdWVzOg0KPiANCj4gTm9uZS4NCj4gDQo+IE5pdHMvZWRpdG9yaWFsIGNvbW1l bnRzOg0KPiANCj4gVGhpcyBkb2N1bWVudCByZWZlcnMgdG8gUkZDIDQzNzksIHdoaWNoIGhhcyBi ZWVuIG9ic29sZXRlZCBieSBSRkMgODAyOS4gSXQNCj4gc2VlbXMgbGlrZSB0aGUgcmVmZXJlbmNl cyBzaG91bGQgYmUgdXBkYXRlZC4NCj4gDQo+IA0KDQpJbmRlZWQuIERvbmUgaW4gLTA3IGFuZCAt MDguDQoNClRoYW5rcyBhZ2FpbiwgUGV0ZSENCg0K4oCUDQpDYXJsb3MgUGlnbmF0YXJvLCBjYXJs b3NAY2lzY28uY29tDQoNCuKAnFNvbWV0aW1lcyBJIHVzZSBiaWcgd29yZHMgdGhhdCBJIGRvIG5v dCBmdWxseSB1bmRlcnN0YW5kLCB0byBtYWtlIG15c2VsZiBzb3VuZCBtb3JlIHBob3Rvc3ludGhl c2lzLiINCg0K From nobody Tue Jul 4 08:39:44 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCDC131648; Tue, 4 Jul 2017 08:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 R2KKrcsqR2cN; Tue, 4 Jul 2017 08:39:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4675D1320E2; Tue, 4 Jul 2017 08:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2784; q=dns/txt; s=iport; t=1499182781; x=1500392381; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oXinpEfuhX5Uai5/kXVcfjYRpWQFEB/WPPJ3gmy724A=; b=bDXCEU4XOTmyWp7tu1XT+zkKkEhoiFWj8FenJ2yP8yljYSN81gMDQYe+ /HxLIbhXYZAjHOHJ69lYKtjR5rcAJISBhaeQptGzFX4vpNbJblWBR9wk2 EgBdPx4RDHq0U75mAptUEtKwtM3TxDEu1hzA+fv2dy9W7DZphixLxmwcb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAQBftltZ/4YNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1mBcweDaIoZkXWWAIIRhhwCGoJwPxgBAgEBAQEBAQFrKIUYAQEBAQM?= =?us-ascii?q?jETcDBgUOAgIBCBEDAQIDAiYCAgIZFxUICAIEDgUIiiexKYImi0UBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdBYEGghyFLYMkhDsRAgEygnyCYQWXKYddApN6ghWFSop?= =?us-ascii?q?IlTIBHzh/C3UVSYcVdogdgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,309,1496102400"; d="scan'208";a="265798897" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jul 2017 15:39:40 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v64FdeqZ021551 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Jul 2017 15:39:40 GMT Received: from xch-aln-011.cisco.com (173.36.7.21) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 4 Jul 2017 10:39:39 -0500 Received: from xch-aln-011.cisco.com ([173.36.7.21]) by XCH-ALN-011.cisco.com ([173.36.7.21]) with mapi id 15.00.1210.000; Tue, 4 Jul 2017 10:39:39 -0500 From: "Siva Sivabalan (msiva)" To: Loa Andersson CC: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "spring@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-spring-lsp-ping Thread-Index: AQHS9NVvTdoDe73QckywwLl7XTlvH6JDwp0g Date: Tue, 4 Jul 2017 15:39:39 +0000 Message-ID: <908efce8432e4f9aac5ebf0495c7afce@XCH-ALN-011.cisco.com> References: <14c7b495-b3ce-8f81-d7ef-7abc33424acb@pi.nu> <92fdf4fe-a12b-74ae-864d-b53bd094c3bb@pi.nu> In-Reply-To: <92fdf4fe-a12b-74ae-864d-b53bd094c3bb@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.255.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] IPR poll on draft-ietf-mpls-spring-lsp-ping X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 15:39:43 -0000 DQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBJRVRGIGRyYWZ0Lg0K DQpUaGFua3MsDQpTaXZhDQoNCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpT dWJqZWN0OiBJUFIgcG9sbCBvbiBkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWxzcC1waW5nDQpEYXRl OiBNb24sIDUgSnVuIDIwMTcgMDk6Mzk6MDggKzAyMDANCkZyb206IExvYSBBbmRlcnNzb24gPGxv YUBwaS5udT4NClRvOiBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPg0KQ0M6IGRyYWZ0LWll dGYtbXBscy1zcHJpbmctbHNwLXBpbmdAaWV0Zi5vcmcNCjxkcmFmdC1pZXRmLW1wbHMtc3ByaW5n LWxzcC1waW5nQGlldGYub3JnPiwgbXBscy1jaGFpcnNAaWV0Zi5vcmcgPG1wbHMtY2hhaXJzQGll dGYub3JnPiwgc3ByaW5nQGlldGYub3JnIDxzcHJpbmdAaWV0Zi5vcmc+DQoNCldvcmtpbmcgR3Jv dXAsIGF1dGhvcnMsDQoNCldlIGhhdmUgc3RhcnRlZCB0byBwcmVwYXJlIHRoZSB0aGUgZHJhZnQt aWV0Zi1tcGxzLXNwcmluZy1sc3AtcGluZyBmb3Igd2dsYywgcHJpb3IgdG8gdGhlIHdnbGMgd2Ug bmVlZCB0byBkbyBhbiBJUFIgcG9sbC4NCg0KVGhpcyBtYWlsIHN0YXJ0cyB0aGlzIElQUiBwb2xs Lg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYt bXBscy1zcHJpbmctbHNwLXBpbmc/DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9z ZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5 LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KDQpObyBJUFIgZGlzY2xvc3VyZXMg aGF2ZSBiZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBvbiBkcmFmdC1pZXRmLW1wbHMtIHNwcmluZy1s c3AtcGluZyBvciB0aGUgaW5kaXZpZHVhbCBkb2N1bWVudCBpdCByZXBsYWNlZC4NCg0KSWYgeW91 IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJl c3BvbmQgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUg YXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50 IHRvIHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZh bmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQg ZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQoNCklmIHlvdSBhcmUgb24gdGhlIE1Q TFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRy aWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3 YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3Jt YW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClNpbmNlIHRoaXMgZG9jdW1lbnQgbWlnaHQgYmUgb2Yg aW50ZXJlc3QgZm9yIHRoZSBTUFJJTkcgd2csIGl0IGhhcyBiZWVuIGNvcGllZCB0byB0aGUgU1BS SU5HIHdnIG1haWxpbmcgbGlzdC4NCg0KL0xvYQ0KbXBscyB3ZyBjby1jaGFpcg0KLS0gDQoNCg0K TG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1 YXdlaS5jb20NClNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9h QHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3 MzkgODEgMjEgNjQNCg0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAg ICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NClNlbmlvciBNUExTIEV4cGVydCAgICAg ICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25z dWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== From nobody Fri Jul 7 06:07:38 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7136F1201F2; Fri, 7 Jul 2017 06:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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 gK8K-IhfazPZ; Fri, 7 Jul 2017 06:07:16 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34060131444; Fri, 7 Jul 2017 06:07:12 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id C109516024B; Fri, 7 Jul 2017 15:07:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 71AABC0081; Fri, 7 Jul 2017 15:07:10 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0352.000; Fri, 7 Jul 2017 15:07:10 +0200 From: To: "Carlos Pignataro (cpignata)" , Pete Resnick CC: "gen-art@ietf.org" , "spring@ietf.org" , "ietf@ietf.org" , "draft-ietf-spring-oam-usecase.all@ietf.org" Thread-Topic: Genart last call review of draft-ietf-spring-oam-usecase-06 Thread-Index: AQHS8DzDWIhR6rTu8UG+oA8joThdh6JBQjKAgAceyfA= Date: Fri, 7 Jul 2017 13:07:09 +0000 Message-ID: <5238_1499432830_595F877E_5238_249_1_53C29892C857584299CBF5D05346208A477F5711@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <149867468440.7527.6305996146978005032@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Genart last call review of draft-ietf-spring-oam-usecase-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 13:07:18 -0000 SGkgUGV0ZSwgQ2FybG9zLA0KDQo+IEZyb206IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBb bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0gID4gU2VudDogU3VuZGF5LCBKdWx5IDAyLCAyMDE3 IDEwOjE0IFBNDQo+IA0KID4gSGksIFBldGUsDQogPiANCiA+IE1hbnkgdGhhbmtzIGZvciB0aGUg dGltZSB0byByZWFkIGFuZCByZXZpZXcgdGhpcyBkb2N1bWVudCENCiA+IA0KID4gTGlrZSBSdWVk aWdlciwgSSB3aWxsIGxldCB0aGUgc2hlcGhlcmQsIGNoYWlycywgYW5kIEFEIHdlaWdodCBpbiDi gJQgYnV0IGluIHRoZSBtZWFudGltZSwgSQ0KID4gd2FudGVkIHRvIG9mZmVyIGEgY291cGxlIG9m IG9ic2VydmF0aW9ucyBmb3IgY29uc2lkZXJhdGlvbi4gUGxlYXNlIHNlZSBpbmxpbmUuDQogPiAN CiA+IA0KID4gPiBPbiBKdW4gMjgsIDIwMTcsIGF0IDI6MzEgUE0sIFBldGUgUmVzbmljayA8cHJl c25pY2tAcXRpLnF1YWxjb21tLmNvbT4gd3JvdGU6DQogPiA+DQogPiA+IFJldmlld2VyOiBQZXRl IFJlc25pY2sNCiA+ID4gUmV2aWV3IHJlc3VsdDogTm90IFJlYWR5DQogPiA+DQogPiA+IEkgYW0g dGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFs IEFyZWENCiA+ID4gUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1l bnRzIGJlaW5nIHByb2Nlc3NlZA0KID4gPiBieSB0aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIu ICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdA0KID4gPiBsaWtlIGFueSBvdGhlciBs YXN0IGNhbGwgY29tbWVudHMuDQogPiA+DQogPiA+IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVh c2Ugc2VlIHRoZSBGQVEgYXQNCiA+ID4NCiA+ID4gPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L2dlbi93aWtpL0dlbkFydGZhcT4uDQogPiA+DQogPiA+IERvY3VtZW50OiBkcmFmdC1pZXRmLXNw cmluZy1vYW0tdXNlY2FzZS0wNg0KID4gPiBSZXZpZXdlcjogUGV0ZSBSZXNuaWNrDQogPiA+IFJl dmlldyBEYXRlOiAyMDE3LTA2LTI4DQogPiA+IElFVEYgTEMgRW5kIERhdGU6IDIwMTctMDYtMzAN CiA+ID4gSUVTRyBUZWxlY2hhdCBkYXRlOiBOb3Qgc2NoZWR1bGVkIGZvciBhIHRlbGVjaGF0DQog PiA+DQogPiA+IFN1bW1hcnk6IE5vdCBSZWFkeSBmb3IgcHVibGljYXRpb24gYXMgSW5mb3JtYXRp b25hbCwgYnV0IG1pZ2h0IGJlIFJlYWR5IGZvcg0KID4gPiBwdWJsaWNhdGlvbiBhcyBQcm9wb3Nl ZCBTdGFuZGFyZA0KID4gPg0KID4gPiBNYWpvciBpc3N1ZXM6DQogPiA+DQogPiA+IFRoaXMgaXMg YW4gYWRtaXR0ZWRseSB1bnVzdWFsIHJldmlldy4gSSBoYXZlIHJlYWQgdGhyb3VnaCB0aGUgZW50 aXJlIGRvY3VtZW50LA0KID4gPiBhbmQgdGhlIHRlY2huaWNhbCB3b3JrIHNlZW1zIGZpbmUsIGJ1 dCBpcyB3ZWxsIGJleW9uZCBteSB0ZWNobmljYWwgZXhwZXJ0aXNlLA0KID4gPiBzbyBJIGNhbid0 IHJlYWxseSBjb21tZW50IG9uIHRoZSB0ZWNobmljYWwgY29ycmVjdG5lc3MuIEhvd2V2ZXIsIGl0 IGlzDQogPiA+IGFic29sdXRlbHkgY2xlYXIgdG8gbWUgdGhhdCB0aGlzIGlzICpub3QqIGEgInVz ZSBjYXNlIiBkb2N1bWVudCBhdCBhbGwNCiA+IA0KID4gSSBhZ3JlZSB3aXRoIHRoZSBhc3Nlc3Nt ZW50IHRoYXQgdGhpcyBpcyBub3QgYSDigJx1c2UtY2FzZeKAnSBkb2N1bWVudCAoaW4gYSBzdHJp Y3Qgb3IgdHJhZGl0aW9uYWwNCiA+IHNlbnNlKTsgdGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBk ZXBsb3ltZW50IGNhc2UgYW5kIGEgc29sdXRpb24gdG8gYSB1c2UgY2FzZSwgdXNpbmcNCiA+IGV4 aXN0aW5nIHRlY2hub2xvZ3kgYmxvY2tzLiBJdCBkb2VzIG5vdCBkZWZpbmUgbmV3IHByb3RvY29s IG5vciAobW9yZSBpbXBvcnRhbnRseSkgY3JlYXRlcw0KID4gaW50ZXJvcGVyYWJpbGl0eSBjb25z aWRlcmF0aW9ucy4NCg0KQXMgdGhlIGRvYyBzaGVwaGVyZCwgSSBhZ3JlZSB0aGF0IHRoaXMgZG9j dW1lbnQgaXMgbW9yZSB0aGFuIGEgdXNlIGNhc2UgYW5kIGRlc2NyaWJlcyBib3RoIGEgdXNlIGNh c2UgKHNlY3Rpb25zIDEsIDQpIGFuZCBhIG1vbml0b3Jpbmcgc3lzdGVtIChzZWN0aW9ucyAzIGFu ZCA2IHRvIDgpLiBBbmQgdGhlcmUgaXMgZXZlbiBhbiBpbXBsZW1lbnRhdGlvbiByZXBvcnQ6IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZWlwbml0ei1zcHJpbmctcG1zLWltcGxl bWVudGF0aW9uLXJlcG9ydC0wMA0KDQpIb3dldmVyLCB0aGUgc29sdXRpb24gcmVsYXRlZCBwYXJ0 IGRvZXMgbm90IHJlcXVpcmUgc3RhbmQgdHJhY2sgZG9jdW1lbnQgYXMgaXQgcnVucyBhcyBhIHN0 YW5kYWxvbmUgZGV2aWNlIHdpdGggbm8gbmVlZCBmb3IgaW50ZXJvcGVyYWJpbGl0eS4gSW5kZWVk LCB0aGUgc29sdXRpb24gbGV2ZXJhZ2VzIFNlZ21lbnQgUm91dGluZy9TUFJJTkcgc28gdGhhdCBh IHVuaXF1ZSBub2RlIGlzIHVzZWQgYXMgYm90aCB0aGUgc2VuZGVyIGFuZCB0aGUgcmVjZWl2ZXIu IEFzIHN1Y2gsIHRoZSBzeXN0ZW0gaXMgZnJlZSB0byB1c2UgYW55IE9BTSBwcm90b2NvbC9wYWNr ZXQgZm9ybWF0IHdpdGggbm8gaW50ZXJvcGVyYWJpbGl0eSBjb25zaWRlcmF0aW9uLiBJdCBsb29r cyB0byBtZSB0aGF0IHN1Y2ggZnJlZWRvbSBpcyBwYXJ0IG9mIHRoaXMgUGF0aCBNb25pdG9yaW5n IFN5c3RlbSB1c2UgY2FzZS9zeXN0ZW0uDQpQbHVzLCBJIGZlYXIgdGhhdCBtb3ZpbmcgdG8gc3Rh bmRhcmQgdHJhY2sgd291bGQgbWVhbiBjaGFuZ2luZyB0aGUgZG9jdW1lbnQgaW50byBhIHByZWNp c2Ugc3BlY2lmaWNhdGlvbiAoZS5nLiB3aGljaCBPQU0gdG9vbChzKSB0byB1c2UgYW5kIHRoZSB3 YXkgdG8gdXNlIHRoZW0pIHdoaWNoIHdhcyBub3QgdGhlIGdvYWwsIG1heSByZXF1aXJlIHNpZ25p ZmljYW50IHdvcmsgYW5kIGRlbGF5LCBhbmQgbWF5IGV2ZW4gYmUgc3Vib3B0aW1hbCBpbiByZW1v dmluZyBmcmVlZG9tLg0KDQpUTDtEUjogT24gbXkgc2lkZSwgSSBkb24ndCBmZWVsIHRoYXQgdGhl IGRvY3VtZW50IG5lZWRzIHRvIGJlIHN0YW5kYXJkIHRyYWNrLiBCdXQgSSBndWVzcyB0aGF0IHVs dGltYXRlbHkgdGhlIGRlY2lzaW9uIGlzIG9uIHRoZSBBRC9JRVNHIHNpZGUuDQoNClRoYW5rcywN Ci0tQnJ1bm8NCiANCiA+ID4gYW5kIEkNCiA+ID4gZG9uJ3QgdGhpbmsgaXQncyBhcHByb3ByaWF0 ZSBhcyBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50Lg0KID4gDQogPiBOb3csIHJlZ2FyZGluZyB0 aGUgbW9zdCBhcHByb3ByaWF0ZSBpbnRlbmRlZCBzdGF0dXMsIEkgY291bGQgcGVyc29uYWxseSBh cmd1ZSBib3RoIHNpZGVzLA0KID4gYW5kIGZyYW5rbHksIEkgZG8gbm90IGhhdmUgYSBzdHJvbmcg cHJlZmVyZW5jZSBvciBjb25jZXJuIGVpdGhlciB3YXkuDQogPiANCiA+IFRoZSBuZXQgb2YgaXQg aXMgdGhhdCB0aGlzIChpbmZvcm1hdGlvbmFsL3NwZWNpZmljYXRpb24pIGRvY3VtZW50IGRvZXMg bm90IGNyZWF0ZQ0KID4gcmVxdWlyZW1lbnRzIGZvciBTUFJJTkcgbm9kZXMsIGNoYW5nZXMgaW4g U1BSSU5HLCBub3IgZXhwb3NlcyBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4gSXQNCiA+IGJhc2lj YWxseSBsZXZlcmFnZXMgYXMtaXMgdGhlIHVuZGVybHlpbmcgY2FwYWJpbGl0aWVzIGNyZWF0ZWQg d2l0aCBTUFJJTkcuIEZyb20gdGhhdCBhbmdsZSwNCiA+IEluZm9ybWF0aW9uYWwgaXMgYSB2ZXJ5 IGFwcHJvcHJpYXRlIGZpdC4gT24gdGhlIG90aGVyIGhhbmQsIEkgZG8gbm90IGRpc2FncmVlIHdp dGggdGhpcw0KID4gZG9jdW1lbnQgc3BlY2lmeWluZyBhIHN5c3RlbSwgYW5kIHRoZSBwbGF5LW9m LXdvcmRzIHRoYXQgcmVzdWx0cyBpbiBzdGFuZGFyZHMtdHJhY2sg4oCUIHNvDQogPiBpdCBpcyBh IHNwZWMgZm9yIHRoZSBwYXRoIG1vbml0b3Jpbmcgc3lzdGVtLCBidXQgcHJvdmlkZXMgaW5mb3Jt YXRpb24gdG8gdGhlIG5ldHdvcmsgYW5kIHRvDQogPiBTUFJJTkcgc3BlY3Mgb24gaG93IHRoZSBu ZXcgdGVjaCBjYW4gYmUgdXNlZC4NCiA+IA0KID4gTmV0LW5ldCwgSSBzZWUgSW5mb3JtYXRpb25h bCBidXQgY2FuIHVuZGVyc3RhbmQgeW91ciByYXRpb25hbGUuDQogPiANCiA+IEluIGFueSBjYXNl LCB3aGF0IGRvZXMgY29uY2VybiBtZSBtb3JlIGlzIHdoZXRoZXIgYSBwb3RlbnRpYWwgY2hhbmdl IG9mIGludGVuZGVkIHN0YXR1cw0KID4gd291bGQgYWRkIHNpZ25pZmljYW50IGRlbGF5IGFuZCBy ZXNldCBwcm9jZXNzIHRpbWVycyBvbiBhIHRpbWVsaW5lIHRoYXQgaXMgYWxyZWFkeQ0KID4gb3Zl cnN0cmV0Y2hlZCBhbmQgYSB2ZXJ5IHNsb3cgcHJvZ3Jlc3PigKYNCiA+IA0KID4gPiBUaGlzIGlz IGNsZWFybHkgYQ0KID4gPiAqc3BlY2lmaWNhdGlvbiogb2YgYSBwYXRoIG1vbml0b3Jpbmcgc3lz dGVtLiBJdCBnaXZlcyBndWlkYW5jZXMgYXMgdG8gcmVxdWlyZWQsDQogPiA+IHJlY29tbWVuZGVk LCBhbmQgb3B0aW9uYWwgcGFyYW1ldGVycywgYW5kIHNwZWNpZmllcyBob3cgdG8gdXNlIGRpZmZl cmVudA0KID4gPiBwcm90b2NvbCBwaWVjZXMuIEl0IGlzIGF0IHRoZSB2ZXJ5IGxlYXN0IHdoYXQg UkZDIDIwMjYgcmVmZXJzIHRvIGFzIGFuDQogPiA+ICJBcHBsaWNhYmlsaXR5IFN0YXRlbWVudCAo QVMpIiAoc2VlIFJGQyAyMDI2LCBzZWMuIDMuMikuIEl0ICptaWdodCogYmUgYSBCQ1AsDQogPiA+ IGJ1dCBpdCBpcyBub3Qgc3RyaWN0bHkgZ2l2aW5nICJjb21tb24gZ3VpZGVsaW5lcyBmb3IgcG9s aWNpZXMgYW5kIG9wZXJhdGlvbnMiDQogPiA+ICgyMDI2LCBzZWMuIDUpLCBzbyBJIGRvbid0IHJl YWxseSB0aGluayB0aGF0J3MgcmlnaHQsIGFuZCBpbnN0ZWFkIHRoaXMgc2hvdWxkDQogPiA+IGJl IG9mZmVyZWQgZm9yIFByb3Bvc2VkIFN0YW5kYXJkLiBFaXRoZXIgd2F5LCBJIHRoaW5rIEluZm9y bWF0aW9uYWwgaXMgbm90DQogPiA+IGNvcnJlY3QuIEltcG9ydGFudGx5LCBJIHRoaW5rIHRoZXJl IGlzIGEgZ29vZCBsaWtlbGlob29kIHRoYXQgdGhpcyBkb2N1bWVudCBoYXMNCiA+ID4gbm90IHJl Y2VpdmVkIHRoZSBhcHByb3ByaWF0ZSBhbW91bnQgb2YgcmV2aWV3OyBwZW9wbGUgdGVuZCB0byBp Z25vcmUNCiA+ID4gSW5mb3JtYXRpb25hbCAidXNlIGNhc2UiIGRvY3VtZW50cywNCiA+IA0KID4g VGhpcywgaG93ZXZlciwgSSB0aGluayBpcyBhbiBpbmFwcHJvcHJpYXRlIGV4dHJhcG9sYXRpb24u IEFsdGhvdWdoIHRoZSBzaGVwaGVyZCwgV0cgYW5kDQogPiBjaGFpcnMgYWxyZWFkeSBjb25zaWRl cmVkIHRoZSBpbnRlbmRlZCBzdGF0dXMsIEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIHJlLXRo aW5rIHdoYXTigJlzIGJlc3QNCiA+IGZvciB0aGlzIGRvY3VtZW50IGluIHRoZSBjb250ZXh0IG9m IHRoZSBtZXJpdHMsIHN0cnVjdHVyZSBhbmQgZ29hbHMuIEJ1dCBqdXN0aWZ5aW5nIGl0IG5vdA0K ID4gYmVpbmcgaW5mb3JtYXRpb25hbCBiZWNhdXNlIOKAnHBlb3BsZSB0ZW5kIHRvIGlnbm9yZSBb 4oCmXeKAnSBzZWVtcyBhIHJlZCBoZXJyaW5nLg0KID4gDQogPiA+IGFuZCB0aGVyZSBoYXZlIGJl ZW4gbm8gTGFzdCBDYWxsIGNvbW1lbnRzDQogPiA+IGJleW9uZCBKb2VsJ3MgUlRHIEFyZWEgUmV2 aWV3Lg0KID4gDQogPiBXaXRoaW4gU1BSSU5HLCB0aGlzIGRvY3VtZW50IGRhdGVzIHRoZSBvcmln aW5zIG9mIHRoZSBXRy4gSXQgd2FzIHByZXNlbnRlZCBpbiBtYW55IFdHcw0KID4gbnVtZXJvdXMg dGltZXMgYW5kIGl0ZXJhdGVkIHRocm91Z2ggbWFueSB2ZXJzaW9ucyAod2l0aGluIHRocmVlIGZp bGVuYW1lcykgYXMgdmFyaW91cw0KID4gcmV2aWV3cyBjYW1lIGluLiBJ4oCZZCByZWNvbW1lbmQg eW91IGFsc28gZ28gYmFjayBhbmQgY2hlY2sgdGhlIHRpbWVsaW5lLiBJIHdvdWxkIG5vdCBhbHNv DQogPiBtYWtlIGhhcmQgY29uY2x1c2lvbnMgYmFzZWQgb24gTEMgdHJhZmZpYy4NCiA+IA0KID4g PiBFdmVuIGluIElFU0cgcmV2aWV3LCBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50DQogPiA+IG9u bHkgdGFrZXMgdGhlIHNwb25zb3JpbmcgQUQgdG8gYXBwcm92ZTsgZXZlcnkgb3RoZXIgQUQgY2Fu IHN1bW1hcmlseSBpZ25vcmUNCiA+ID4gdGhlIGRvY3VtZW50LCBvciBldmVuIGJhbGxvdCBBQlNU QUlOLCBhbmQgdGhlIGRvY3VtZW50IHdpbGwgc3RpbGwgYmUgcHVibGlzaGVkDQogPiA+ICh0aG91 Z2ggdGhhdCBkb2VzIG5vdCBub3JtYWxseSBoYXBwZW4pLiBUaGlzIGRvY3VtZW50IHNob3VsZCBo YXZlIG11Y2ggbW9yZQ0KID4gPiB0aGFuIHRoYXQgbGV2ZWwgb2YgcmV2aWV3LiBJIHN0cm9uZ2x5 IHJlY29tbWVuZCB0byB0aGUgV0cgYW5kIEFEIHRoYXQgdGhpcw0KID4gPiBkb2N1bWVudCBiZSB3 aXRoZHJhd24gYXMgYW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudCBhbmQgcmVzdWJtaXR0ZWQgZm9y IFByb3Bvc2VkDQogPiA+IFN0YW5kYXJkIGFuZCBoYXZlIHRoYXQgbGV2ZWwgb2YgcmV2aWV3IGFu ZCBzY3J1dGlueSBhcHBsaWVkIHRvIGl0Lg0KID4gDQogPiBBcyBJIHNhaWQsIEkgYW0gaGFwcHkg d2l0aCBlaXRoZXIgc3RhdHVzIGFuZCBjYW4gc2VlIGFyZ3VtZW50cyBib3RoIHdheXMuIEkgd291 bGQgbm90DQogPiBvYmplY3QgdG8gYSBjaGFuZ2UuDQogPiANCiA+IEhvd2V2ZXIsIHBlcnNvbmFs bHksIEkgZG8gbm90IHNlZSB0aGUgbmVlZC4NCiA+IA0KID4gPg0KID4gPiBNaW5vciBpc3N1ZXM6 DQogPiA+DQogPiA+IE5vbmUuDQogPiA+DQogPiA+IE5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOg0K ID4gPg0KID4gPiBUaGlzIGRvY3VtZW50IHJlZmVycyB0byBSRkMgNDM3OSwgd2hpY2ggaGFzIGJl ZW4gb2Jzb2xldGVkIGJ5IFJGQyA4MDI5LiBJdA0KID4gPiBzZWVtcyBsaWtlIHRoZSByZWZlcmVu Y2VzIHNob3VsZCBiZSB1cGRhdGVkLg0KID4gPg0KID4gPg0KID4gDQogPiBJbmRlZWQuIERvbmUg aW4gLTA3IGFuZCAtMDguDQogPiANCiA+IFRoYW5rcyBhZ2FpbiwgUGV0ZSENCiA+IA0KID4g4oCU DQogPiBDYXJsb3MgUGlnbmF0YXJvLCBjYXJsb3NAY2lzY28uY29tDQogPiANCiA+IOKAnFNvbWV0 aW1lcyBJIHVzZSBiaWcgd29yZHMgdGhhdCBJIGRvIG5vdCBmdWxseSB1bmRlcnN0YW5kLCB0byBt YWtlIG15c2VsZiBzb3VuZCBtb3JlDQogPiBwaG90b3N5bnRoZXNpcy4iDQoNCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo YW5rIHlvdS4KCg== From nobody Mon Jul 10 05:58:21 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF97129B07 for ; Mon, 10 Jul 2017 05:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 kpzHJ65i6JSy for ; Mon, 10 Jul 2017 05:58:17 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00128.outbound.protection.outlook.com [40.107.0.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519C81296CF for ; Mon, 10 Jul 2017 05:58:17 -0700 (PDT) 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=Ki9ZKsMTIti12w/4DvpW4jq7I4cQw1xfhZNVwLu/cBo=; b=aPd4jXF4c3HKpd+KekJdkJ5mpKq2xI76Kts+oCQzQSxhDkz9UYhSNDyafODvzuXuKEWO2voKqNyqzvuP2S/rxaxZDquZxUi2NOPYUztJsoCVBb5SHYdKEvUYVRleEK6WFkYOj1o/+276MBp7eSpBf3JtHKkmeYET3EiT6TpGFco= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; Received: from [192.168.0.13] (88.182.48.47) by AM5PR0701MB2468.eurprd07.prod.outlook.com (2603:10a6:203:10::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Mon, 10 Jul 2017 12:58:14 +0000 To: spring@ietf.org References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> From: Martin Vigoureux Message-ID: <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> Date: Mon, 10 Jul 2017 14:58:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [88.182.48.47] X-ClientProxiedBy: DB6PR07CA0020.eurprd07.prod.outlook.com (2603:10a6:6:2d::30) To AM5PR0701MB2468.eurprd07.prod.outlook.com (2603:10a6:203:10::8) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b12c65f4-bcfa-43ca-5f8f-08d4c7935405 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2468; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2468; 3:b+bJBB/O0H8+pFQZludkF5ZuhGIm7/TN0bh0Ktm9Xc9weQHiZMM1i0DNxzA9J2ste0gzAayTTax2+oiq4jvDVDLV6dfSuoZEk69MfkaaC6l5HBY1bXEBSLDHxCl1pqueR4JMSP6pvAWrPhxq4omCYxLMWRpFlh+KVLyklqhfT3KhJW6MikeJ3AT1unMWl/hGnvCV4ztQZDijDdIltpuYvEFPHpkPyyZRrYVOlGjd31LJdrp510Twl0hqyt04smEmYk6+FzdIrcoYcNRhM2Dr9/hHIWcWQAhs5xhZA+r3MOH0MPuXW1I9LxPWaatBe+xFpei1eGJnXYAqv2ECxOOG1Uv64cyycbHlIJluBz21nRqHPJDNQUlABRjPrXZbZlQNtz6ScGXZsZArTVJXTEDHuGu7MD5rkQGfu1cUesZieqJt4pNY+fC/WpsWNvknJc9MibM/GYHLWRai1bVLF7iDYObter8B7oQajYrem7Zh2CzeYGxJ7NNqEb21JtOD4ZZE0J8aeguZZW7jFk5GmRujbDxYp+K5Pe/gAe8+JhQ96koicJnGSx1igoNWRta3V6SEltJGgAx5iX5SKL+YBiL4dBQHfahEkj4qVCEpBMRWQxnDWI3Y+VcFpPYhxgNbhqRbJdTkwrCYUjMTxHaaavciD7aG16a+Kh/K9n+VVdpCPFdKgJtTu51oZGMUAdyJQZCZFx9QM4GJKEFBmu6uJSvzejsqMCLaPClvOisPj3Xk7xSSJS4YGmz25EIcCGWA7YB/e27a7kLRgcyg+Jw02+a5nw== X-MS-TrafficTypeDiagnostic: AM5PR0701MB2468: X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2468; 25:EGirJKCYdU3Neect28s/blvu1VJc5W1y6tdX21e/Cgu0VmpzssvhYCcrByeyntKT99H2wivn4y7vgErFauJfUwOyB6ZimePg10PTRuguLKRsnW8ic3WcwtMoIHMI0D1t6kLoG81Skqk+P1/X5UUV+NnwVVPGfDZRrLiKT/YF794MyDTdYUvAJPYB0C7KkzPMr0VNL31KnmCAkS8I3/cxiy1iOW5KtD3gt5mZORuXHU5+XjIz55NOBqt/hDD3W1tP/4F/0Wk39Dap8L6y3KaNYXbof51tun37a2jd/fewUdjYqzBsBpGWjDTsuex0/yQljTwGZHUyh9tzYc3ZqGhchvL38/hzx07Ja2d6f2rMnhEiOUc/AAS0X8C47wXmfz9qsyq9a6F7NmTWW0LxDfYvKkwJ8/zVYKfHLPx4IYz06VUavU9qW98MhPDoUZ8qguZFZQfhdNploSCbRPGNRw+mjIDDRbzlUKqbYEwptGIqiuGx6by1aQiuyyTH/lfQWXiH7f0OHBr3WwQY8x/EWgzDrzK8aa1pVk+YiInC3YA3Gu76R53CPZ/rZ9jKadlIxVApjZdb59Oli2U3e1+JhhAXNxtm0yEi6rAymbfIHTVJb2fMdQBMCKEqBjWWrImf9YYd3AdheDEw6r8O6DiXWAe33+Q0QTnyGasXqbpgbqDEjHcTgEqZgtUPSTsR6mHCfwDQepCQLnOSuznt67XRfeskCGnYUoYRfe1G1hSbJZXu0u+V3Z0BIqDdgU4DPhxZMiEluxlnoicFRNRKsBG9EXmpbXQXCKnqIUp5bxF9Uo8/IXCa72oNHTYhlUZgILkuxUfj7oGlXcN1E29WHRJDRpOHp1EcbgIZI1+1aAc0p8qVCk5evqaDQsE4v0/D7o7T1gD/l2QFU/gzmYor6EOVflj7ag9+gBQdjdt2dswydVLoBqY= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2468; 31:4xy5nuKPFrGbrdvcMhexRqVhtUSRd1/B14JepksvpzkN2z72W6v0kK3qUjvcQes9yNA7uPEzEjPnRiN48eUQY9uTTPkPyeAd+TmNRB7lfILpr0yFulgb3JhMgTYB5MsFrKVWlMdI9IR0f90G3gtQQzpw0i1Il4mGi70NhOxBEyYvBUuze1A+u7LbjBAKtgbm3ThnWGTwv6sUqcMgtTCBxLa59YLdfv007q/fz/4LIfdS6Us8/QIjnB7WeF7aooyymIkIzwOzocy/BbZr4myMf2w9tSAiOUqcH8k7xmlZPEjqR0OudPMpMl6X6E94G1hQnix/wLRLfY5s6rvAiKGyi8vTigPLxNbjdDNrVql8HXSaoCiIlqo0gCafhGugz/vQVgL3ewzHjH/xPOYTad3NJDZDxxiZ9ZNWinAVqbSmDfmVxScsDX5rm4UshCkY9BO/wVGmlBxQU6TklAMVSdJWo4Zjt3V1wUimL2/u8dTW/Wh96cUyJetm2xJ31XtYvUGezWv77dD3tYGZAeRGvN95Hre13gpFx8vPh7WtlwZvRciaI2inW84WuIj1z0vE+VB+oNXG4kwTHYb5mkZUcr0aeWbrOs7L+MiGgomkWoOCcOGyX1UnxV7Z7edNxKBFyeQJ0x3Zt1m2gmmRaetMkx/gxwy6BCcJXBpPN0vONEYulnSQAi+kKIo4KvnHVQ8Vv4qu7cVPKWp77NYgqBrRr/aEKA== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2468; 20:D1NOzPEyRMNDMBn78ckEqX8RYgEM1uqiVgxKTZgeUeI+urvIWZTF8aaOAvfKv66l3nLR2wEVnTlG8rs4mVejDCKRRz+g6eG+MV19YhO1K8vA5X+koi6SUMkzE4i5h9gfXtiiT+ssK3G7FyMec0qZfXrQ4TtirNkwzXFaXxxSIRbBD1OwLd0TBWoqN8zf/9p4uO7FBwk/6p8ODj7XejnoKipPd2O2Zz1In6H+Hl1joNp2mJpQEgMb7BmP+j3W2nUflIT/IiJAbOq+IkjBz6DWY/T/yst9fH66HOTzNGJ3Qnz5t254iYPdlp/LyobGaxbrLotd2UrnOEidXDcqAErhqDLF8jzWWn+zwEQfkiBVoHVS77MHeImuROG3Y6foHATsPeqrNz1Ucb9pnC1YOYN7/2nepOsfvqlfkPCDv/P3eWXjFlrZyNaMbTZXX7kEtBCRbHVCJZ6zizQa+eqzgkJZ8jucCDOoAhKohJr+ycEJtU0lGH6zesWMu6iqC7M9uxkb X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(133145235818549)(120809045254105)(236129657087228)(48057245064654)(209349559609743); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2468; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2468; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM5PR0701MB2468; 4:L4pC5Ef7Np+/vZA5lydjmA4HOYIQzM5nOUts?= =?Windows-1252?Q?nDnG6otWAyEVb3HDqUN7qByrcSTgmpccxp8j1CYmWaGtZm0kgci57+Kn?= =?Windows-1252?Q?BM7Y/4EXlAxVSffe0cZ6WLHyL6Bg8nbpv7xCA+mS9AQv/Dmdebzi9nbB?= =?Windows-1252?Q?CeUscgAetv7WPLdfGpolE8IXvasPqpq5Yh8NEa+Yh1cyUM4Y3V0+/abo?= =?Windows-1252?Q?/AzsL9pvXytsULNQPiHPCY4/t2UvKZ79dazyLp+V7ZGnZG35lbOZrCwA?= =?Windows-1252?Q?Sdi/756sZkMh1zaVe8FD6XDHcN/TEh6EnNPeutyB5mgb0AhcJzIVUV8X?= =?Windows-1252?Q?4sapF+/9xsgF700vpERwgGUaiQ+rpbY5XXlVqdYk0bJZv+ZS63rVSCAK?= =?Windows-1252?Q?3Hu13P+sU+eGvLqn3Iv2d7Z0eqeiWx7kHsMyiIM9z5rrLzGPQ3vZwgrM?= =?Windows-1252?Q?aDweXTHRG/YqTO0JFHoor88XuBbN+K4Zs+sg/fCMfTgHfMqeBOQ9yfmZ?= =?Windows-1252?Q?pn8nTvBsAObZ0TcMUMvLHPj6DV2S24nvD6L062ACt+bDUkdpyPHgSMj6?= =?Windows-1252?Q?QD/uxOOAVezeFtKfdInfc7A7nWCYLSqpFKT6ut63cJZvC+eUqVXg+NCt?= =?Windows-1252?Q?YSTmTHb6lkkp2iv3/f8x7Axe1GtTr3Gd6oGYYoOjPEF6N2Q2tE9b8Zxn?= =?Windows-1252?Q?G9mvZmYt0Vur6TzlAoEEeSt1eEkNB0Ti4lAoZw8f+/q4aCAF+SvkobrR?= =?Windows-1252?Q?yAj+bXKGcoomx9VJy3pCVgxLUDgkx0rsDps+dP6bV9rc4Mu32nODE2zc?= =?Windows-1252?Q?2r71w417DHyDLr+wCwTano2Mo5rgWK6iMyIUhrvIrVBqmZQlsa5xwiqG?= =?Windows-1252?Q?VUcVR8qB+dWU0D5w2STJKQRgscePrgtYbyHDfKZKv0LTejinU5dtc4fx?= =?Windows-1252?Q?xYjjGbFK8OAFODAXpIZQWupRVWaCDcA8rdUNrMMVGU50EEGyh9z5Nadr?= =?Windows-1252?Q?v8HzQ+wtSZ6envfCQbTAoX80Sf5D4rfkEqgpa7zIq403ONG6vqAr1spZ?= =?Windows-1252?Q?X3nxptPsK2yJkRxHHjowS/5pp3URXcvvmqzlOX1K4k2CMkRbufINxcU7?= =?Windows-1252?Q?5ucnzCkPyDFJD3mni6L5bjFGM6lBHGB2Qk/nbxqxrIUVwJPZh2YTq7uD?= =?Windows-1252?Q?CkFkXiTgwsUEiUNWlDnHULGxOYj1PlCCIApVRwGjnkziIjYHolhlxex7?= =?Windows-1252?Q?bbumrEU7TqdfoFQyaYR3lJawZXaf+lKFZp78YrV+lKhqlxi/oNu8moii?= =?Windows-1252?Q?pnxiSiAx9OxYwj1r0q7vSHIKmx0z6ShEkDwO97IfQts0BZoxEeTk8Bie?= =?Windows-1252?Q?wibZD8zuM/UA39Xhh78SSWEVTz9nN45KxYtsVJyPtweuYr+BGp5/5E57?= =?Windows-1252?Q?v8d2S7AoYNbKnPxZrB0LSMq3Uc2QnxIQ+CWVTe8VNtkcHQh+G467oEzX?= =?Windows-1252?Q?UTd6Cjqpk4Jrx2YG3Eli02yTzdLwU1LNsL4edgKVoOLemWnfDg=3D=3D?= X-Forefront-PRVS: 03648EFF89 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6049001)(6009001)(39840400002)(39850400002)(39410400002)(39860400002)(39400400002)(39450400003)(189998001)(4001350100001)(86362001)(3846002)(6116002)(33646002)(47776003)(65956001)(38730400002)(65806001)(66066001)(31696002)(81166006)(2870700001)(8676002)(76176999)(110136004)(83506001)(54356999)(50986999)(5660300001)(6246003)(305945005)(7350300001)(65826007)(117156002)(229853002)(77096006)(6486002)(36756003)(2906002)(6306002)(478600001)(966005)(25786009)(50466002)(23746002)(42186005)(31686004)(6916009)(53936002)(6666003)(2361001)(2351001)(2950100002)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2468; H:[192.168.0.13]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM5PR0701MB2468; 23:+h6T9pFafmV6iRGCDldjVJ+foyB8d1fb6SI?= =?Windows-1252?Q?OkhadfNl3rnCzToUZiVgyXDG4LkahM/vTYzMcVuSkeWKSUZrv3R853s9?= =?Windows-1252?Q?KrwNSPENYTLWE8tf20qfJ/qQo3QBDRMIr2GHPrle2Pk/phi+D4shoZ9p?= =?Windows-1252?Q?jIGM18cJibcaDLQ/hXWJXULmNWWr0oOj/PO3KSNztt8GNmEhCrAMWGKz?= =?Windows-1252?Q?gL80/YnLEJqzRRArzENPjaFQO+ISXINjvnYYKNuA39UICD03gOa/R1Sb?= =?Windows-1252?Q?emOuuTCUViWJgrVtgVn25q186t+NVOShwkmnjV/yjmVehN4a7NTXYvqM?= =?Windows-1252?Q?UUVOdOPWSzGOL1mpW0WJOfH5LhnUKL/fu33aJahITNqBy23/sP3u3T78?= =?Windows-1252?Q?KaEl8NOWkDhhKGrL3n5q/QRV0YfKqHnrcHT1zTf8ZiFv/MK3rs4N+oAC?= =?Windows-1252?Q?OP0mT7kwTDwM1su7IDymvbE2dJFqZ1P7yIeZfd6axsfJ9x/fW4YpYrxS?= =?Windows-1252?Q?j8rjMQcIXIzfclu2XMhn9wwtrEjLjn28G6pj6Tul3qrb2yXj6U82ViY1?= =?Windows-1252?Q?PHmlBUTJ3zrVCdVqIEhd70qrX6AuzWk8aC4Yh2B5xrp5MiQln3t1Lxr7?= =?Windows-1252?Q?3MX2NuKw0pTeakEz73e5+7ugtGxUHTNp7nzeIc+c/e1/C+VjZRbXkWL+?= =?Windows-1252?Q?RxY9OFeyGxkvGs4HYvLhOo2tX71ki5Or6Yr0E+EBkxjeL6IUy7WsoGJ4?= =?Windows-1252?Q?dAJ7wUg2HOVQYYkxzLTcUgz13Ph4+tGIh3JGdcd10q/xyP5TMYPuO1Gg?= =?Windows-1252?Q?0Zly6Bg+C+3s0be1uMkKrHrx9b4Zu9DmfZyg0IyytqpiO+U1nHVoQVDs?= =?Windows-1252?Q?x7xgGkz3KdTsWjbdg2GqFeJjaznP9SObjRYgv/7p1+6Sehf/acn9PXX6?= =?Windows-1252?Q?zyeX9MdSPTV6q4FzRAzInY8AqoOB4PUnI4PT/3IZpESbF7pnPQ3f58QN?= =?Windows-1252?Q?EvSTuZ5l3bT6jb1teZJse2l+21aKZt7UvAKPoFiZltEwf6oLjuGipHOB?= =?Windows-1252?Q?mye5MMFERWLdQ9hhBN449fwIBPqYLuvq2NCEUfG0s10aa5qeHhxq1cKK?= =?Windows-1252?Q?y0hDqB8g6lS4lhRuVhh4dA4/QsNVv1pWh0KmF79I3abe2uEfXfMrX2CF?= =?Windows-1252?Q?4n+xanFKLNHcoIBREV28ryQxD7tPIk4n6V9xgfqBNl1WM7YSqeHp2wzk?= =?Windows-1252?Q?0y96h6HsVIF77S4u1ya3NPuMhKHEax38ctopEM72ujvZrBf19NLQUipV?= =?Windows-1252?Q?HZh3ywKXKW2VgDFlTX2hizkb969/gACNoE19vSt5Eq0grxrwsgKxAKz1?= =?Windows-1252?Q?IgtTRXN4X6YWvAPk1C/7IPta1+w+kG/UtYhQgHhnjVPMNrDpT4tUyxtJ?= =?Windows-1252?Q?6TuJYoU7g92CVKmk65oqeW79uEzzkc6bIUaLKXYKfuEBW21NM9TyFWnL?= =?Windows-1252?Q?iIPPJGo4=3D?= X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM5PR0701MB2468; 6:gkkc9CuDUds7+DcEfx5CpAvg6BedBvht2MYy?= =?Windows-1252?Q?qi7u8vVpdnDvWr8cNCAJ71/E5SOd/cias/rMj71BCqknmQoJ6/q+8Xjf?= =?Windows-1252?Q?+fCXcKq35E061awdbFpFPSIQ57Z3Iy2tULMqA2WvucTJXQrsbyjSaQYn?= =?Windows-1252?Q?vpHx7fbkZ/9InZLxCsiNMBl/U7/cEo9NkMzuvedn/nNXQXi/tcYS3zIn?= =?Windows-1252?Q?XzP3dlBaYILTaFXk4UGNlxjdJAg2y5tlf+xFcoDyZChyE04oeW3oFE/u?= =?Windows-1252?Q?Ai0WFls9m35x4LPpDqCAnL7/or9t/m8cS/iEobpR66H8gRfTBHpwb1bt?= =?Windows-1252?Q?/pRlOAXJdVmbYTm+qPXmMXOQhbGF8reUsgBASMVH0aqKAvueiG/uQUw4?= =?Windows-1252?Q?2QC8DnWVOdplW/PNWj+YEmWuJxNn4VOAObIUq2f/bUBIJLbPQBpWoHVr?= =?Windows-1252?Q?5GJ/9mgntsoBvcF5aggKSmr5o82+QuqgKmrhuVUkyQpfuctJK0g31Epe?= =?Windows-1252?Q?mGWN6F/kacfPexAAaYVOPtng+yQdCt0PC6zj50QHw3EtFEryPtjHt/z9?= =?Windows-1252?Q?Mvb6xe/3Q2e1ENh8zpaevEqSTl4X7pF4VEBAYAcCQAhjSTN/u5C7jskP?= =?Windows-1252?Q?X9H14MVcobAMKY0crwvtxtUpBjwYm1HjMkgUrrQnJopboGsJPdAFnjS+?= =?Windows-1252?Q?v7AQQ4RfOqsA7Z7GlPCk/pTaHj4a1ow/gQo11MgBjc3UKXjjaaGkPA4U?= =?Windows-1252?Q?jTLF8G7VvsU+Myb5SMegIuN4xCz8HhzfdvoQ1jm+uwHLj53OcAIYQ6cN?= =?Windows-1252?Q?j+CoIKHe9nQfG4XbdPZofnd12qCsUQbQeyvsDmXsjZ2eE619wBtG5IZZ?= =?Windows-1252?Q?xaqrLsbwAmXcSulfuhl2JlELZiPoYOcIDG7/sx6HdLi7HrxbeMkcf5Yz?= =?Windows-1252?Q?BnX5XaxexEcw7O8+6AunHoW0EFfz+2OZ3uz8YTqqPaRhPms7a66IfvGD?= =?Windows-1252?Q?WHMk4pCoFjOWnCCDeKhfN7086gqKHh7k+BmLoaaBG97HE/uybUhy4t1v?= =?Windows-1252?Q?seHi8WlrymbnxhuD4zQwhi4tj4suooIDbv1D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2468; 5:hUJZP+68rsIUGQSkj8TBCnVvkITCX4mGsqvz9H+54dUJpii8JqDjHwf/nxGb26/X7vMvwjUbhRxrM4Fw6SZSa2LtuBjkHJp5l+Ci9YgdqPaRP7r8YOajYJAMQGy06C8Hp3ihSSpR9DkjvXF64czc2/nUYY6sBWkjKEiNaaakrmgGzAAD6jAOwtOBXGF+YrrlOaOb1Nj2G8YwpilPO/BIRRBBYSVh3G1RhSu8smjCniAnQXnZ8Se7cvIdScw62T+KyqSSvDyZ2ah7O8TvYg2dt4r4lMBO1Uk7E64yM4fi47MUC5eMNEWVTSn+47me3owLF0tDKrrE/6Bc10S0SRkBH1WnI0UWXl1NsKbl/H8mPMEgrKo1Q2AokIf4n5t7A0IYchkASTrfX9uAUllRy3wfC7s9TDcGZr7ChckbMnfVaHG131mAmG7mJ+4LmbtDlrYgvX1N36xFIUY1LRV0lCxnEYR5rKlwxtKjINR6WJKCflbHrURFAVsQvlvzBCUAIEwn; 24:hTaNmvVNqFHA58JldWWLw//FE4/UkGgloQVqojfPZxeiQ2yv8pN8JTC79uBG5POuONlyGR0bT9AKLBas+DgmPjniQ4MnugiFhUmhcCCxHMs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2468; 7:UViheDgM5zRUMERu6Fn1W9woloqwBpgYbJPXVwckK52+67PzVuPct4yy/eb1qU3ZdKC2BGQg7uBmHnqZ10wSjhkFo6KQdLwHQYFe7htGmuRS5IibwBQUeRGeiDnXxHTz/ewcOO/Vy4gVpUo7xqLkQ6KFcxAnROmxaHxzR2fP1vq3VP0EvSm3fwkOWuhOZoArOJ1RZ0FEkrqd8Ewgxjs4uXU3+HYwPPGB6P23i8jMlLebfpABeK27+hmoGvEDi6p1UqaQkHZX9c4iG4glFEaw5+opuu93o5U4fzjvfG8LPKTD6OmcHyFDhsvBCY8PQVglj2Kl+O8zZ91OiMWwBXR2yjDJXVVWBZ5az6O6qjp6Qas3LuYuF2wjVhJDuvm3Lrqv43FHCfJjKPAQjHtYIt/iCD/75ru++sppag6DYqRHLlJ5X5mfZnoUkfkJEnHHH1mmBcdtcgmK3+5yi3q/ADsXMSjR08Wbgs+5MWRlz9yrIdhULvS2/kE3P7UiWi/NkIp1t1rMckYQoH1nqTlll7dhhd/dka4l4mEU35D8UeuTBuRW+gC/p3XMl4RcH7ufEZiQZHIDbBWXsidco921y2IsqcUVbpfFOuLZWB/6zBKLEaQ0+pA1bxCBtIVtr/a+Vt/SNQ9bej5P3BHSWFg9fJcVIzoui/YDjnsGhgaPxgVEphxZ/Po9k1VDjBL3lYYR5ior67Uqc1dYpvIK+kw5K81tx2U6hgW3/feE7R7suzLVVPMmkxtkxO5CfqhtmNV5ATuopEFoF7X8lzoczq9xACxokruutfA4HzxxisMQvZNWrjM= X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2017 12:58:14.3155 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2468 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 12:58:19 -0000 WG, We are half-way through the WG Last Call and I am very surprised to only see a single answer to it. I am not sure I'll move this forward with only silence as support. -m Le 29/06/2017 à 15:28, Martin Vigoureux a écrit : > Hello Working Group, > > This email starts a Working Group Last Call on > draft-ietf-spring-conflict-resolution-04 [1] which is considered mature > and ready for a final working group review. > > ¤ Please read this document if you haven't read the most recent > version yet, and send your comments to the list, no later than > *21st of July*. > Note that this is *not only* a call for comments on the document; it is > also a call for support (or not) to publish this document as a Proposed > Standard RFC. > > ¤ *Coincidentally*, we are also polling for knowledge of any IPR that > applies to draft-ietf-spring-conflict-resolution, to ensure that IPR has > been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, > 3669 and 5378 for more details). > > If you are listed as an Author or Contributor of > draft-ietf-spring-conflict-resolution-04 please respond to this email > and indicate whether or not you are aware of any relevant IPR. > > Note that, as of today, no IPR has been disclosed against this document > or its earlier versions. > > Thank you, > Martin > > [1] https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/ > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Mon Jul 10 07:12:51 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C3A127076 for ; Mon, 10 Jul 2017 07:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=previdi-net.20150623.gappssmtp.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 twccli2VBxjo for ; Mon, 10 Jul 2017 07:12:47 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 4F7C312EAF0 for ; Mon, 10 Jul 2017 07:12:47 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id c11so140600385wrc.3 for ; Mon, 10 Jul 2017 07:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=previdi-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=AfbqkS7C++/dkzZ7BOEH7MrX88Xh7/7OdcUC/fMBM/Y=; b=ID7rrzwef16o3uUqw7u+enxi1YWs6htLfnKq3YvY0qhe8VmGz7siQk9Nc9R6/HzfRA +SgDGMK2SsBvOdoV+CgiEIYJxRX0jgfrir58PJks3hvDfK63WfzwlQGJkYXQvfrv3VqY qVR96QMeuc8CpeSexhE1B1NOe1pGlaTs7d1vVaVVJ0nTSRBArTZrTCaPXMrsVq7In/5w sfdeyscRITI95p4VyPVGSeBoNCsDxCVlEBBcMNHAmj+CZLhpiXLvghR+QMBW8eGL/Zlk Q769HksZdpz5oeg/SSCaahRCsp83c+9wKWfru44+6mvPuC3tblGT59yl8O8AWWC3g1w7 50Bg== 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 :content-transfer-encoding:message-id:references:to; bh=AfbqkS7C++/dkzZ7BOEH7MrX88Xh7/7OdcUC/fMBM/Y=; b=HVgCNG76AZdW84pVQj88daknQOkmnunIaaoQaGERAGVH9cdGYlq3VJWw9WuWZLmcdB XAxS1XSqUmlIcl/J7f8Z9I3ZAuaSqKIet1f8VILkdF5WhsosEnzlBQk74jlWLLtTNClh ElXD9k9GVyu31q2TqEKqz9adBgdEY8u7XfckmT8uCNZ+FifcYdiJJy6AP7ifypmI73rx f6w08zhqN0jyhUqpvESxj7Pfb4yYHffkCchNqq6QqVIYO0SdZIOm+/+5UfDFTsyVh+LJ 5r3G2jqDNw9dL6I37ae2/ZN9Vp/EeO5gKAUFzcnAj+djFQd/6eWybcGntwgfImD/HPK/ soew== X-Gm-Message-State: AIVw113GG7/9oHIJF05DB/BXKYNDCdmjwQKbRqBn5RtgtkJ/K8av0pSY R0DpUJMX4rdEyvn8 X-Received: by 10.28.222.214 with SMTP id v205mr756517wmg.68.1499695965817; Mon, 10 Jul 2017 07:12:45 -0700 (PDT) Received: from ?IPv6:2001:420:c0c0:1003::84? ([2001:420:c0c0:1003::84]) by smtp.gmail.com with ESMTPSA id b30sm7066359wra.42.2017.07.10.07.12.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Jul 2017 07:12:44 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: stefano previdi In-Reply-To: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> Date: Mon, 10 Jul 2017 16:12:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F1782DC-9EEA-4026-84FF-AB642FE8E55F@previdi.net> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> To: Martin Vigoureux , SPRING WG X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 14:12:49 -0000 I strongly support the publication of this draft. I=92m not aware of any IPR related to the mechanisms described in the = draft. s. > On Jun 29, 2017, at 3:28 PM, Martin Vigoureux = wrote: >=20 > Hello Working Group, >=20 > This email starts a Working Group Last Call on = draft-ietf-spring-conflict-resolution-04 [1] which is considered mature = and ready for a final working group review. >=20 > =A4 Please read this document if you haven't read the most recent > version yet, and send your comments to the list, no later than > *21st of July*. > Note that this is *not only* a call for comments on the document; it = is also a call for support (or not) to publish this document as a = Proposed Standard RFC. >=20 > =A4 *Coincidentally*, we are also polling for knowledge of any IPR = that applies to draft-ietf-spring-conflict-resolution, to ensure that = IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, = 4879, 3669 and 5378 for more details). >=20 > If you are listed as an Author or Contributor of > draft-ietf-spring-conflict-resolution-04 please respond to this email = and indicate whether or not you are aware of any relevant IPR. >=20 > Note that, as of today, no IPR has been disclosed against this = document or its earlier versions. >=20 > Thank you, > Martin >=20 > [1] = https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/ >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Jul 10 07:20:59 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F23131798 for ; Mon, 10 Jul 2017 07:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 30ESY4Lo8qe2 for ; Mon, 10 Jul 2017 07:20:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF54131790 for ; Mon, 10 Jul 2017 07:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3159; q=dns/txt; s=iport; t=1499696455; x=1500906055; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=MiTp/wYPkpWc9oVO1/Jq9jpkXnIsF47cydd7u9R2QIc=; b=jbzdUVS2vdBsIx2jH6LPQ9yPVWZw641WNCwVVgZ/Kb/oCVexwHItqVlQ GI/5V6Y57mS8XazOq8Gpv6J+OGSq5nm3WSYrKTWxavmZDWBM5TSYPuQgY MgSgAJaYg6jIMzcemJKl5aAWern5NmSv6GdmOmrqh7vXVLC+NYEu8bbV4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAABrjGNZ/4cNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy0tZIEUB44CkWqWBIIRIQuFIU8CgyQ/GAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAwEBG1EXBAIBCBEEAQEoBycLFAkIAgQBEggTihQQrQOLQQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgyiDTIFhgySEOxIBhhAFkRaOCAKHRoJ8iT2CFYVLg3KGWZU?= =?us-ascii?q?/AR84fwt1FUmHFnaGNoEjgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,340,1496102400"; d="scan'208";a="271760558" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2017 14:20:54 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6AEKsFf009344 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Jul 2017 14:20:54 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Jul 2017 09:20:53 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Mon, 10 Jul 2017 09:20:53 -0500 From: "Les Ginsberg (ginsberg)" To: Martin Vigoureux , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nuokzsm0yt5P0y/+D1uKMVbQqJNamsA//++5pA= Date: Mon, 10 Jul 2017 14:20:53 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> In-Reply-To: <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.107.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 14:20:58 -0000 A few comments from my perspective as co-author. This is a problem for which it is important to have a standardized solution= , so moving the draft forward is an important part of successfully deployin= g Segment Routing over an MPLS dataplane.=20 This draft has been the subject of lively debate over the last 1.5 years - = and I have contributed to that debate in part because of concerns about the= complexity of the defined solution ("ignore overlap only"). Since the draft was last presented in Seoul I have spent time discussing th= e requirements with multiple operators and I have become convinced that the= deployment cases do indeed require the solution that is defined in the dra= ft. I therefore support the draft without reservation and encourage others = to do the same. I think the latest version (note it is V5 - which corrected= a few errors that existed in V4) is a mature document which addresses real= world deployment cases. Martin - I am not aware of any IPR relevant to this draft. Les > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin > Vigoureux > Sent: Monday, July 10, 2017 5:58 AM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion >=20 > WG, >=20 > We are half-way through the WG Last Call and I am very surprised to only = see > a single answer to it. >=20 > I am not sure I'll move this forward with only silence as support. >=20 > -m >=20 > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > > Hello Working Group, > > > > This email starts a Working Group Last Call on > > draft-ietf-spring-conflict-resolution-04 [1] which is considered > > mature and ready for a final working group review. > > > > =A4 Please read this document if you haven't read the most recent > > version yet, and send your comments to the list, no later than *21st > > of July*. > > Note that this is *not only* a call for comments on the document; it > > is also a call for support (or not) to publish this document as a > > Proposed Standard RFC. > > > > =A4 *Coincidentally*, we are also polling for knowledge of any IPR that > > applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > > has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > > 4879, > > 3669 and 5378 for more details). > > > > If you are listed as an Author or Contributor of > > draft-ietf-spring-conflict-resolution-04 please respond to this email > > and indicate whether or not you are aware of any relevant IPR. > > > > Note that, as of today, no IPR has been disclosed against this > > document or its earlier versions. > > > > Thank you, > > Martin > > > > [1] > > https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution > > / > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Jul 10 07:29:55 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F73130A92; Mon, 10 Jul 2017 07:29:46 -0700 (PDT) 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 RvORiNdOrfWC; Mon, 10 Jul 2017 07:29:45 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1669124B0A; Mon, 10 Jul 2017 07:29:44 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id j53so55208505uaa.2; Mon, 10 Jul 2017 07:29:44 -0700 (PDT) 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=3t0UHBR8QiIgShP16L+yi6tM3DXXbv6xDUTMy+O0vxA=; b=fslFMzvCWfnUKGIqN/EfjZCDOwH5QsFxKI9wUdHqBK0Eo+6RhMLpi8M2eIimtTG5fm L6DMyoKx1/NfAwI8MrLOhRDGO/Uj17K5SCvb1GIU0lzjtdT1pAVX1SQjFAy9HxP/JSIb zQ0Czr0+0DGRydISaRRYCZtYdzYhiOE8sJNA6mkR+ZogmrBYzgJOMjkbfIdQfi5MPAbq yas8ZuS2PB6G5QaKmE/DKzsHJAix+0KyKZPaIYaoAstFSjcCNuVXUrnyHlbJEjqR1ris TtYIkU4edyK00LKjCMxeIiSITVYGda9Sry3q1po8CrXbTZ+CYNFV52ZQ9nmziBMZv4bs 3nUg== 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=3t0UHBR8QiIgShP16L+yi6tM3DXXbv6xDUTMy+O0vxA=; b=CF9rZKMsJy+rdJovCQkaTGrqqj70MrE+M3qjSZ9PTuoMA/pLUcaFWdxFhKVtciebJp cMFS7Islrz2Cgu7tNfeUVHNF/DDbbdZCI7bd/ABPp4T2fZAsF4tc13auVjQ4U+iJpAfk 6kvXfzAYOTrB7OIsdX9mKnNw0MsxwdXQbPlrKesfxdThuU/YKrquUS/lshDuMj/P8pMZ ZUzOSnYsk0oJkvipn/PGtQtXYU4+PxtsIUTYVXjJ6iIYBwHvUXERwertSRw26xu5ORY5 fjMnHm5CWaofgQVMNlwuT67YcViLlCJY4KrXHNDru1u74o3GybASmpgekhhUkMkCkkNE Ctvg== X-Gm-Message-State: AIVw111ohUJQZf+V/wQz2T/BeuRLNfsRFiXxVgtLVaNhPc50L9eGaGR7 fs1bHqnGnjtkx54Z4vnxx5DdD/t7Ww== X-Received: by 10.176.90.201 with SMTP id x9mr9217904uae.129.1499696984040; Mon, 10 Jul 2017 07:29:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.5.35 with HTTP; Mon, 10 Jul 2017 07:29:43 -0700 (PDT) In-Reply-To: <908efce8432e4f9aac5ebf0495c7afce@XCH-ALN-011.cisco.com> References: <14c7b495-b3ce-8f81-d7ef-7abc33424acb@pi.nu> <92fdf4fe-a12b-74ae-864d-b53bd094c3bb@pi.nu> <908efce8432e4f9aac5ebf0495c7afce@XCH-ALN-011.cisco.com> From: George Swallow Date: Mon, 10 Jul 2017 10:29:43 -0400 Message-ID: To: "Siva Sivabalan (msiva)" Cc: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="f403045f8b520128490553f76ac0" Archived-At: Subject: Re: [spring] IPR poll on draft-ietf-mpls-spring-lsp-ping X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 14:29:47 -0000 --f403045f8b520128490553f76ac0 Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR related to this IETF draft. George On Tue, Jul 4, 2017 at 11:39 AM, Siva Sivabalan (msiva) wrote: > > I am not aware of any IPR related to this IETF draft. > > Thanks, > Siva > > -------- Forwarded Message -------- > Subject: IPR poll on draft-ietf-mpls-spring-lsp-ping > Date: Mon, 5 Jun 2017 09:39:08 +0200 > From: Loa Andersson > To: mpls@ietf.org > CC: draft-ietf-mpls-spring-lsp-ping@ietf.org > , mpls-chairs@ietf.org < > mpls-chairs@ietf.org>, spring@ietf.org > > Working Group, authors, > > We have started to prepare the the draft-ietf-mpls-spring-lsp-ping for > wglc, prior to the wglc we need to do an IPR poll. > > This mail starts this IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-spring-lsp-ping? > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details). > > No IPR disclosures have been submitted directly on draft-ietf-mpls- > spring-lsp-ping or the individual document it replaced. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant IPR. > *The response needs to be sent to the MPLS WG mailing list.* The document > will not advance to the next stage until a response has been received from > each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Since this document might be of interest for the SPRING wg, it has been > copied to the SPRING wg mailing list. > > /Loa > mpls wg co-chair > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --f403045f8b520128490553f76ac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR related to this IETF draft.=

George

On Tue, Jul= 4, 2017 at 11:39 AM, Siva Sivabalan (msiva) <msiva@cisco.com> wrote:

I am not aware of any IPR related to this IETF draft.

Thanks,
Siva

-------- Forwarded Message --------
Subject: IPR poll on draft-ietf-mpls-spring-lsp-ping
Date: Mon, 5 Jun 2017 09:39:= 08 +0200
From: Loa Andersson <loa@pi.nu>
To: mpls@ietf.org <mpls@ietf.org>
CC: draft-ietf-= mpls-spring-lsp-ping@ietf.org
<draft-ietf-= mpls-spring-lsp-ping@ietf.org>, mpls-chairs@ietf.org <mpls-chairs@ietf.org>, spring@= ietf.org <spring@ietf.org>=

Working Group, authors,

We have started to prepare the the draft-ietf-mpls-spring-lsp-ping for= wglc, prior to the wglc we need to do an IPR poll.

This mail starts this IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-spring-lsp-pi= ng?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details).

No IPR disclosures have been submitted directly on draft-ietf-mpls- spring-= lsp-ping or the individual document it replaced.

If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. *Th= e response needs to be sent to the MPLS WG mailing list.* The document will= not advance to the next stage until a response has been received from each= author and contributor.

If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules.

Since this document might be of interest for the SPRING wg, it has been cop= ied to the SPRING wg mailing list.

/Loa
mpls wg co-chair
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@m= ail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@m= ail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

--f403045f8b520128490553f76ac0-- From nobody Mon Jul 10 14:50:25 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEBE13190F for ; Mon, 10 Jul 2017 14:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 qOek6fD5p4VR for ; Mon, 10 Jul 2017 14:50:17 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02155131919 for ; Mon, 10 Jul 2017 14:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2804; q=dns/txt; s=iport; t=1499723417; x=1500933017; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=fEhUh2uxf7a3+zewgmH6GGmcIX04hvnwhvQJ76y3KnM=; b=VTu0u+Gkep1BQoAhLrNgNZ2ASu0F2UX8lcGZu/GRyZ2+Swfq5XtPsWl4 9VAPKJdip6lGVwzmUSqDDP+ppQKy6RFFaszw+CszFMJaNPKc7iZhT8g6e o1E6Rz+Wy9bCZPUVzghjaeokF2kSuH+bTwRspm1gAeYPY3Bl3fQb3zq0y M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAAAC9mNZ/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgKRa5YDghEhC4R8TwIagxI/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEBARsGETobAgEIGAICJgICAiULFRACBAESiicIEKtagiaLPQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgQuCHYNMggyCeYQ7EgEcF4J8MIIxBZ8eAodGjEK?= =?us-ascii?q?CDIVLg3KGWZU/AR84fwt1FUkSAYcDdoY0gSOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,342,1496102400"; d="scan'208";a="257930945" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2017 21:50:16 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v6ALoFU2010149 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Jul 2017 21:50:16 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Jul 2017 17:50:15 -0400 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1210.000; Mon, 10 Jul 2017 17:50:15 -0400 From: "Gaurav Dawra (gdawra)" To: stefano previdi , Martin Vigoureux , SPRING WG Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS+YaYbleQ9GxEuEySp3vBEdAvs6JNZ60A Date: Mon, 10 Jul 2017 21:50:15 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <1F1782DC-9EEA-4026-84FF-AB642FE8E55F@previdi.net> In-Reply-To: <1F1782DC-9EEA-4026-84FF-AB642FE8E55F@previdi.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.80.174] Content-Type: text/plain; charset="utf-8" Content-ID: <63A6217802660D459587977BC01003D9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 21:50:19 -0000 KzENCg0KU3VwcG9ydCB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBkcmFmdC4NCg0KUmVnYXJkcywN CiANCkdhdXJhdg0KDQpPbiA3LzEwLzE3LCA3OjEyIEFNLCAic3ByaW5nIG9uIGJlaGFsZiBvZiBz dGVmYW5vIHByZXZpZGkiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc3Rl ZmFub0BwcmV2aWRpLm5ldD4gd3JvdGU6DQoNCiAgICBJIHN0cm9uZ2x5IHN1cHBvcnQgdGhlIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQuDQogICAgDQogICAgSeKAmW0gIG5vdCBhd2FyZSBvZiBh bnkgSVBSIHJlbGF0ZWQgdG8gdGhlIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4N CiAgICANCiAgICBzLg0KICAgIA0KICAgIA0KICAgID4gT24gSnVuIDI5LCAyMDE3LCBhdCAzOjI4 IFBNLCBNYXJ0aW4gVmlnb3VyZXV4IDxtYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbT4gd3JvdGU6 DQogICAgPiANCiAgICA+IEhlbGxvIFdvcmtpbmcgR3JvdXAsDQogICAgPiANCiAgICA+IFRoaXMg ZW1haWwgc3RhcnRzIGEgV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1zcHJp bmctY29uZmxpY3QtcmVzb2x1dGlvbi0wNCBbMV0gd2hpY2ggaXMgY29uc2lkZXJlZCBtYXR1cmUg YW5kIHJlYWR5IGZvciBhIGZpbmFsIHdvcmtpbmcgZ3JvdXAgcmV2aWV3Lg0KICAgID4gDQogICAg PiDCpCBQbGVhc2UgcmVhZCB0aGlzIGRvY3VtZW50IGlmIHlvdSBoYXZlbid0IHJlYWQgdGhlIG1v c3QgcmVjZW50DQogICAgPiB2ZXJzaW9uIHlldCwgYW5kIHNlbmQgeW91ciBjb21tZW50cyB0byB0 aGUgbGlzdCwgbm8gbGF0ZXIgdGhhbg0KICAgID4gKjIxc3Qgb2YgSnVseSouDQogICAgPiBOb3Rl IHRoYXQgdGhpcyBpcyAqbm90IG9ubHkqIGEgY2FsbCBmb3IgY29tbWVudHMgb24gdGhlIGRvY3Vt ZW50OyBpdCBpcyBhbHNvIGEgY2FsbCBmb3Igc3VwcG9ydCAob3Igbm90KSB0byBwdWJsaXNoIHRo aXMgZG9jdW1lbnQgYXMgYSBQcm9wb3NlZCBTdGFuZGFyZCBSRkMuDQogICAgPiANCiAgICA+IMKk ICpDb2luY2lkZW50YWxseSosIHdlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBh bnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0 aW9uLCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ug d2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBm b3IgbW9yZSBkZXRhaWxzKS4NCiAgICA+IA0KICAgID4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYW4g QXV0aG9yIG9yIENvbnRyaWJ1dG9yIG9mDQogICAgPiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGlj dC1yZXNvbHV0aW9uLTA0IHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgYW5kIGluZGljYXRl IHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4NCiAgICA+ IA0KICAgID4gTm90ZSB0aGF0LCBhcyBvZiB0b2RheSwgbm8gSVBSIGhhcyBiZWVuIGRpc2Nsb3Nl ZCBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQgb3IgaXRzIGVhcmxpZXIgdmVyc2lvbnMuDQogICAgPiAN CiAgICA+IFRoYW5rIHlvdSwNCiAgICA+IE1hcnRpbg0KICAgID4gDQogICAgPiBbMV0gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVz b2x1dGlvbi8NCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCiAgICA+IHNwcmluZyBtYWlsaW5nIGxpc3QNCiAgICA+IHNwcmluZ0Bp ZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJp bmcNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgIHNwcmluZyBtYWlsaW5nIGxpc3QNCiAgICBzcHJpbmdAaWV0Zi5vcmcNCiAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KICAgIA0KDQo= From nobody Mon Jul 10 18:27:10 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF656129B41 for ; Mon, 10 Jul 2017 18:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 nzb8gSqgHfKY for ; Mon, 10 Jul 2017 18:27:07 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C402120725 for ; Mon, 10 Jul 2017 18:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2194; q=dns/txt; s=iport; t=1499736427; x=1500946027; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QHdK3ViqJf7WBtCBPRBBc9uQ2SUzByVxkExt6aW19+k=; b=EG4ihkWtBdsyUrWkNU9vdSCcTZLVm6LENXo8HNhzhYvcG0PBjeEJD71b f91Vn4jBUxyb4GqR3DstlmGJp75wgkk5yD6HUTxWVgP7kc0EQrx33Qh6C lCkCk4xi/C3b9+DIbS/qDpfcWSvpl9/gN2kcPfnvgdQFsaBJcwp90Ztqp Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAABYKGRZ/4MNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy0tZIEUB44Cp26CESELhHxPAhqDEj8YAQIBAQEBAQEBayiFGQIBAwE?= =?us-ascii?q?BGwYROhsCAQgaAiYCAgIlCxUQAgQBEoovEKtEgiaLPQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARgFgQuCHYVYgnmEOxIBHBeCfDCCMQWXNYdpAodGjEKCDIVLg3KGWZU?= =?us-ascii?q?/AR84fwt1FUkSAYcDdoY0gSOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,343,1496102400"; d="scan'208";a="453448098" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2017 01:27:06 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6B1R6Rb030263 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Jul 2017 01:27:06 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Jul 2017 20:27:05 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Mon, 10 Jul 2017 20:27:05 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Martin Vigoureux , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8NuouEEc36VjGUqa6TKiRnSivaJN+KiA Date: Tue, 11 Jul 2017 01:27:05 +0000 Message-ID: <298957EF-3F44-4A5F-8B88-94344D7C157C@cisco.com> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> In-Reply-To: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.244.137] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 01:27:09 -0000 U3VwcG9ydC4NCg0KVGhhbmtzLA0KTmFnZW5kcmENCg0KT24gNi8yOS8xNywgOToyOCBBTSwgInNw cmluZyBvbiBiZWhhbGYgb2YgTWFydGluIFZpZ291cmV1eCIgPHNwcmluZy1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBtYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbT4gd3JvdGU6DQoNCiAg ICBIZWxsbyBXb3JraW5nIEdyb3VwLA0KICAgIA0KICAgIFRoaXMgZW1haWwgc3RhcnRzIGEgV29y a2luZyBHcm91cCBMYXN0IENhbGwgb24gDQogICAgZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3Qt cmVzb2x1dGlvbi0wNCBbMV0gd2hpY2ggaXMgY29uc2lkZXJlZCBtYXR1cmUgDQogICAgYW5kIHJl YWR5IGZvciBhIGZpbmFsIHdvcmtpbmcgZ3JvdXAgcmV2aWV3Lg0KICAgIA0KICAgIMKkIFBsZWFz ZSByZWFkIHRoaXMgZG9jdW1lbnQgaWYgeW91IGhhdmVuJ3QgcmVhZCB0aGUgbW9zdCByZWNlbnQN CiAgICB2ZXJzaW9uIHlldCwgYW5kIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdCwgbm8g bGF0ZXIgdGhhbg0KICAgICoyMXN0IG9mIEp1bHkqLg0KICAgIE5vdGUgdGhhdCB0aGlzIGlzICpu b3Qgb25seSogYSBjYWxsIGZvciBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQ7IGl0IGlzIA0KICAg IGFsc28gYSBjYWxsIGZvciBzdXBwb3J0IChvciBub3QpIHRvIHB1Ymxpc2ggdGhpcyBkb2N1bWVu dCBhcyBhIFByb3Bvc2VkIA0KICAgIFN0YW5kYXJkIFJGQy4NCiAgICANCiAgICDCpCAqQ29pbmNp ZGVudGFsbHkqLCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0 aGF0IA0KICAgIGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlv biwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyANCiAgICBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlh bmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIA0KICAgIDM2Njkg YW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQogICAgDQogICAgSWYgeW91IGFyZSBsaXN0ZWQg YXMgYW4gQXV0aG9yIG9yIENvbnRyaWJ1dG9yIG9mDQogICAgZHJhZnQtaWV0Zi1zcHJpbmctY29u ZmxpY3QtcmVzb2x1dGlvbi0wNCBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIA0KICAgIGFu ZCBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJ UFIuDQogICAgDQogICAgTm90ZSB0aGF0LCBhcyBvZiB0b2RheSwgbm8gSVBSIGhhcyBiZWVuIGRp c2Nsb3NlZCBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQgDQogICAgb3IgaXRzIGVhcmxpZXIgdmVyc2lv bnMuDQogICAgDQogICAgVGhhbmsgeW91LA0KICAgIE1hcnRpbg0KICAgIA0KICAgIFsxXSBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1y ZXNvbHV0aW9uLw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgc3ByaW5nIG1haWxpbmcgbGlzdA0KICAgIHNwcmluZ0BpZXRmLm9y Zw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQogICAg DQoNCg== From nobody Mon Jul 10 20:24:15 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19B7129B29; Mon, 10 Jul 2017 20:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=akamai.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 6QcYu2TDspUR; Mon, 10 Jul 2017 20:24:12 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 EB51012EC13; Mon, 10 Jul 2017 20:24:11 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v6B3Lv8M002321; Tue, 11 Jul 2017 04:24:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+sediaAJmdNm1rGbBHnofYVDucgrPirqU1YEiXLtTdw=; b=lyExTG6q5jbOIsh25YLRdZ84CS8NnmSqjvAavGPnC6q/uPdPKKHlhngjVzwiOfWI+uoA q0L4pZ56BVcXbfQqQ9mtoQ3sFFf9C2mSPFsc5NH+bv9Fo3RlCJhgGvCl3vJpGhLcN1TL SieyQ15C31xgnXPX8HijOUT3+rXVTyrdpBtk2ihWu4NIle11SIG0n2NhUVFc4k6GOPbG gDltUCidDWFfWqVQMfztb2e9SI9Z6Ghwaf5Dq+7XXTHjUwmhZIK6P2d3qHMk1oplwhpY jncx4l1El68qFARipYSdr/KyzbXBDiyrPkyNAFQ9Mz9nHArmpPD8QD4v9KTn1hpCfN1w BQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2bjwyrj647-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Jul 2017 04:24:09 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6B3MIZI030789; Mon, 10 Jul 2017 23:24:08 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bjtqux55n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 10 Jul 2017 23:24:08 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Jul 2017 23:24:07 -0400 Received: from USMA1EX-DAG1MB4.msg.corp.akamai.com (172.27.123.104) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Jul 2017 23:24:07 -0400 Received: from USMA1EX-DAG1MB4.msg.corp.akamai.com ([172.27.123.104]) by usma1ex-dag1mb4.msg.corp.akamai.com ([172.27.123.104]) with mapi id 15.00.1263.000; Mon, 10 Jul 2017 23:24:07 -0400 From: "Holland, Jake" To: "hackathon@ietf.org" CC: "mboned@ietf.org" , "spring@ietf.org" Thread-Topic: Multicast over Spring Thread-Index: AQHS+fUn5Vdu7knicE6JTOhopFNDnQ== Date: Tue, 11 Jul 2017 03:24:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.226] Content-Type: text/plain; charset="utf-8" Content-ID: <87A7CC1BBEBD4B42BD1C32086D16D290@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-11_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707110050 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-11_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707110050 Archived-At: Subject: [spring] Multicast over Spring X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 03:24:14 -0000 Q2hhbXBpb25zOg0KLSBKYWtlIEhvbGxhbmQNCi0gSm9obiBCcnpvem93c2tpDQoNClByb2plY3Q6 DQotIEV4cGVyaW1lbnRpbmcgd2l0aCBJUHY2IE11bHRpY2FzdCB0cmFuc3BvcnQgb3ZlciBTZWdt ZW50IFJvdXRpbmcsIHVzaW5nIEFNVCBmb3IgbWVtYmVyc2hpcCBzaWduYWxpbmcuDQoNClNwZWNp ZmljYXRpb25zOg0KLSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFu LXNlZ21lbnQtcm91dGluZy1oZWFkZXItMDYNCi0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc0NTANCg0KSW1wbGVtZW50YXRpb246DQotIGh0dHBzOi8vZ2l0aHViLmNvbS9HcnVtcHlP bGRUcm9sbC9hbXQNCi0gaHR0cHM6Ly9naXRodWIuY29tL0dydW1weU9sZFRyb2xsL2FtdC1vcGVu d3J0DQoNCg0KDQo= From nobody Mon Jul 10 23:00:16 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46648129562 for ; Mon, 10 Jul 2017 23:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1024-bit key) header.d=ifne.eu 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 89MLAaVmN9vt for ; Mon, 10 Jul 2017 23:00:13 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 5BD9B1200F3 for ; Mon, 10 Jul 2017 23:00:13 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id c11so167753601wrc.3 for ; Mon, 10 Jul 2017 23:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ifne.eu; s=google-ifne.eu; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=7x/8pSZc1zS7feVk+q9rQ9pNcesjvsMvO9SuUJvzZ/c=; b=Bzi/zovCTMbK3kXgeQblM0Zrf/0nZECkuuSoKAcWhEcvkzK+YGzLnUlbtFPBr18GmV t8ix4SGZsQVZ4l09mpUW/XiHLm2WIDm//AxGbmCPEA9ohc7TOYfBs9K+52LGdEddd9Om KO9j/BtDxHVx42sF9wX+VoEfRE6xvg6RvPo9M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=7x/8pSZc1zS7feVk+q9rQ9pNcesjvsMvO9SuUJvzZ/c=; b=cknDNVAYVx7SK2vhXGsfObmSMGzaBsSUIR8hiAv/Oi978FyEXCgJzJ9g5izqixS9jH ikX+ZfktMJ/D+wcK8X0XQZGYCnd+D0URV5AcaJMQiJFjKRpWfCR3TyE1hnf6iUSO9Cia yJxvHQ68V5h8w5gNGntg3BSPVS4xAAQ4jBOoMYvL/oqbHjdQxzT1cg/jeE8GCnk/4+Oz KVHuXnmOWlMR5KbC+d0VQDJvF3LYGR0eHEo9zzbKpfYmb0cjBGSd0aPneskgcy/Y6bl4 C6W2iVRJlASG3RQLNQGj2hgPd3XOvxUWEyIR23l2MQNkw5Ff3BFIL0M4h5Yrb2n6Gdht brdA== X-Gm-Message-State: AIVw1135NwMUq6DAoUiU34prfqN1ca6aXRk9jp2Uu5JHbKFeHn1YvE2t mAybjqHykpH3KNNdC38= X-Received: by 10.28.166.137 with SMTP id p131mr9951269wme.5.1499752811834; Mon, 10 Jul 2017 23:00:11 -0700 (PDT) Received: from [192.168.1.20] (bband-dyn167.178-41-206.t-com.sk. [178.41.206.167]) by smtp.gmail.com with ESMTPSA id e31sm20990788wre.54.2017.07.10.23.00.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 23:00:11 -0700 (PDT) Sender: Martin Pilka To: Martin Vigoureux , spring@ietf.org References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> From: martin@infobox.sk Message-ID: <07355667-ecdc-949f-e39a-b551ea51c08d@infobox.sk> Date: Tue, 11 Jul 2017 08:00:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 06:00:15 -0000 Hello Martin, I support the draft as co-author. I am not aware of any relevant IPR. Thanks, Martin On 07/10/2017 02:58 PM, Martin Vigoureux wrote: > WG, > > We are half-way through the WG Last Call and I am very surprised to only > see a single answer to it. > > I am not sure I'll move this forward with only silence as support. > > -m > > Le 29/06/2017 à 15:28, Martin Vigoureux a écrit : >> Hello Working Group, >> >> This email starts a Working Group Last Call on >> draft-ietf-spring-conflict-resolution-04 [1] which is considered mature >> and ready for a final working group review. >> >> ¤ Please read this document if you haven't read the most recent >> version yet, and send your comments to the list, no later than >> *21st of July*. >> Note that this is *not only* a call for comments on the document; it is >> also a call for support (or not) to publish this document as a Proposed >> Standard RFC. >> >> ¤ *Coincidentally*, we are also polling for knowledge of any IPR that >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR has >> been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, >> 3669 and 5378 for more details). >> >> If you are listed as an Author or Contributor of >> draft-ietf-spring-conflict-resolution-04 please respond to this email >> and indicate whether or not you are aware of any relevant IPR. >> >> Note that, as of today, no IPR has been disclosed against this document >> or its earlier versions. >> >> Thank you, >> Martin >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/ >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Jul 10 23:26:44 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB33131460 for ; Mon, 10 Jul 2017 23:26:42 -0700 (PDT) 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 oodCU8gHBDrs for ; Mon, 10 Jul 2017 23:26:40 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 C7A8212EBF9 for ; Mon, 10 Jul 2017 23:26:39 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id r103so168633529wrb.0 for ; Mon, 10 Jul 2017 23:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GIcGCxaNvLIkxiQb++P0ykZuF/c713ErN7teIs0Sh78=; b=f4kFiu4IYYYmtvztkTlAYCSXdUnpNDAPQYMmOzDB/+FIhUqdmWo465tg+GE/MiYc/+ 9Aiw+7pgLGys6bcMhuIikMcdFSnxuvsc+AWXvtmN7V/RpRvjLcQotCO3irjgO01Gqp1G XJhU94QXkzAV9zWIkqt/A9+pPz9H3G6yOe8J1hhLVIQBarrQVEYf4oxfI42wmnx9naVm saHu6tmqlzyuMC45zAMwo+Jxo2DedR18jMeZX+8cQ+ZhSNgZOpWLLYaR/3NrjeG5bJf2 6i5hRejijuls5kbqYaIZdKS0ssVfzk4KFLCIE/i/g+YGRyeo8z6SWGClNH/XRzo+K1+d mBqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GIcGCxaNvLIkxiQb++P0ykZuF/c713ErN7teIs0Sh78=; b=b3/4jL/ehEBFRXpYcL5rTT0u33aJlxuGqt7feb1TTJqVFFbrzqyrQn/yFLkrNIizLs +0qLeOmD7L4zNHImIPyaDEsui3xvFvYyIyqrngRmvZMz0+p3zjR4/XBBiVDNC4b1ECsf t+L4G+IH1tMFjVk7OZPwy99iji87LwdUrxz9WhNQwb8iB7jKfX9LyDluqOOdxXxtSTGT kUKrUuJVNj0irs5miO5+Iv/xjqejGtZqerKU3y40tS64D7nQtfHSfWM9IfznjyntRuq+ CmVi8WkD3KcmZaMtlqROXwDnBjpPwqlAf4YP6NNXfeiTJgoY3412ClqiZfzvv0xSQOnk W86Q== X-Gm-Message-State: AIVw1117Y1jgT0ATjnB4a8x19QnqQxAmEAPd8apTlQtCuoU5cQqltz8E Drwch3J7pXam7Vh5FXRF3iD+tYY4Dw== X-Received: by 10.80.216.5 with SMTP id o5mr1408392edj.178.1499754398392; Mon, 10 Jul 2017 23:26:38 -0700 (PDT) MIME-Version: 1.0 References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <07355667-ecdc-949f-e39a-b551ea51c08d@infobox.sk> In-Reply-To: <07355667-ecdc-949f-e39a-b551ea51c08d@infobox.sk> From: Jeff Tantsura Date: Tue, 11 Jul 2017 06:26:27 +0000 Message-ID: To: martin@infobox.sk, Martin Vigoureux , spring@ietf.org Content-Type: multipart/alternative; boundary="089e082233542aa674055404c8b8" Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 06:26:43 -0000 --089e082233542aa674055404c8b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes/support On Mon, Jul 10, 2017 at 23:00 wrote: > Hello Martin, > I support the draft as co-author. I am not aware of any relevant IPR. > Thanks, > Martin > > On 07/10/2017 02:58 PM, Martin Vigoureux wrote: > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to onl= y > > see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =C3=A0 15:28, Martin Vigoureux a =C3=A9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered matur= e > >> and ready for a final working group review. > >> > >> =C2=A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than > >> *21st of July*. > >> Note that this is *not only* a call for comments on the document; it i= s > >> also a call for support (or not) to publish this document as a Propose= d > >> Standard RFC. > >> > >> =C2=A4 *Coincidentally*, we are also polling for knowledge of any IPR = that > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR h= as > >> been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this documen= t > >> or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/ > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > >> > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --089e082233542aa674055404c8b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes/support
On Mon, Jul 10, = 2017 at 23:00 <martin@infobox.sk> wrote:
Hello Martin,
I support the draft as co-author. I am not aware of any relevant IPR.
Thanks,
Martin

On 07/10/2017 02:58 PM, Martin Vigoureux wrote:
> WG,
>
> We are half-way through the WG Last Call and I am very surprised to on= ly
> see a single answer to it.
>
> I am not sure I'll move this forward with only silence as support.=
>
> -m
>
> Le 29/06/2017 =C3=A0 15:28, Martin Vigoureux a =C3=A9crit :
>> Hello Working Group,
>>
>> This email starts a Working Group Last Call on
>> draft-ietf-spring-conflict-resolution-04 [1] which is considered m= ature
>> and ready for a final working group review.
>>
>> =C2=A4 Please read this document if you haven't read the most = recent
>> version yet, and send your comments to the list, no later than
>> *21st of July*.
>> Note that this is *not only* a call for comments on the document; = it is
>> also a call for support (or not) to publish this document as a Pro= posed
>> Standard RFC.
>>
>> =C2=A4 *Coincidentally*, we are also polling for knowledge of any = IPR that
>> applies to draft-ietf-spring-conflict-resolution, to ensure that I= PR has
>> been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4= 879,
>> 3669 and 5378 for more details).
>>
>> If you are listed as an Author or Contributor of
>> draft-ietf-spring-conflict-resolution-04 please respond to this em= ail
>> and indicate whether or not you are aware of any relevant IPR.
>>
>> Note that, as of today, no IPR has been disclosed against this doc= ument
>> or its earlier versions.
>>
>> Thank you,
>> Martin
>>
>> [1] https://datatrac= ker.ietf.org/doc/draft-ietf-spring-conflict-resolution/
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/spring
>>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--089e082233542aa674055404c8b8-- From nobody Tue Jul 11 01:04:26 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE5E12EC3B for ; Tue, 11 Jul 2017 01:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 c64NTrL61vvK for ; Tue, 11 Jul 2017 01:04:23 -0700 (PDT) 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 E685F129AC4 for ; Tue, 11 Jul 2017 01:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1916; q=dns/txt; s=iport; t=1499760257; x=1500969857; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=uOaDgoS8ZHDIfn7wWMgBSOXwYUqmyPlhTOufZd4ykmM=; b=MKWLZLOVUmu+H1+DC2ySm5HBU6KVi81TFLu8BS3QzXUtLPKEGhKXiYwx zSCQBko4vbbXY0LI/PSIJEvXtZboEQ6lfeK+ZfTm6vjgbdswtgb0MlOcr 1MeiG+mcvO2Fc3/LgMFr291AQ1wnfQhnGa8YQCdNIHzACFn68b8HuN8dF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAAC0hWRZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD6BFI4Jc5B5lgOCESELhHtPAoNuGAECAQEBAQEBAWsohRkBAQE?= =?us-ascii?q?DAQEbFQEFNgoRCxgJFg8JAwIBAgEVMAYBDAYCAQGKKxCuKBKLOQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEaBYMog02FBYQ7EgGGEAEEnx+HSIxEggyFS4NPI4ZclUIfOH8?= =?us-ascii?q?LMSEIGxVJhxg+NoV+gjABAQE?= X-IronPort-AV: E=Sophos;i="5.40,345,1496102400"; d="scan'208";a="654187713" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2017 08:04:12 +0000 Received: from [10.60.140.54] (ams-ppsenak-nitro5.cisco.com [10.60.140.54]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6B84Cbf000424; Tue, 11 Jul 2017 08:04:12 GMT Message-ID: <5964867C.1020100@cisco.com> Date: Tue, 11 Jul 2017 10:04:12 +0200 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: Martin Vigoureux , spring@ietf.org References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> In-Reply-To: <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 08:04:25 -0000 Support as co-author. I am not aware of any IPR relevant to this draft. Peter On 10/07/17 14:58 , Martin Vigoureux wrote: > WG, > > We are half-way through the WG Last Call and I am very surprised to only > see a single answer to it. > > I am not sure I'll move this forward with only silence as support. > > -m > > Le 29/06/2017 à 15:28, Martin Vigoureux a écrit : >> Hello Working Group, >> >> This email starts a Working Group Last Call on >> draft-ietf-spring-conflict-resolution-04 [1] which is considered mature >> and ready for a final working group review. >> >> ¤ Please read this document if you haven't read the most recent >> version yet, and send your comments to the list, no later than >> *21st of July*. >> Note that this is *not only* a call for comments on the document; it is >> also a call for support (or not) to publish this document as a Proposed >> Standard RFC. >> >> ¤ *Coincidentally*, we are also polling for knowledge of any IPR that >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR has >> been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, >> 3669 and 5378 for more details). >> >> If you are listed as an Author or Contributor of >> draft-ietf-spring-conflict-resolution-04 please respond to this email >> and indicate whether or not you are aware of any relevant IPR. >> >> Note that, as of today, no IPR has been disclosed against this document >> or its earlier versions. >> >> Thank you, >> Martin >> >> [1] >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/ >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > . > From nobody Tue Jul 11 03:41:39 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC348127342 for ; Tue, 11 Jul 2017 03:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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 oeKHeL-UOUF9 for ; Tue, 11 Jul 2017 03:41:36 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DB9126BF3 for ; Tue, 11 Jul 2017 03:41:35 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id E8D3F12056F; Tue, 11 Jul 2017 12:41:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id CB524400A2; Tue, 11 Jul 2017 12:41:33 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0352.000; Tue, 11 Jul 2017 12:41:33 +0200 From: To: Martin Vigoureux CC: "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS+Xw4eYbV396iOEWHYb6m0yEo+aJOZ/ww Date: Tue, 11 Jul 2017 10:41:32 +0000 Message-ID: <14653_1499769693_5964AB5D_14653_463_1_53C29892C857584299CBF5D05346208A477FDEB9@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> In-Reply-To: <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 10:41:38 -0000 Martin, As an individual contributor, I have read all versions of this document and= support progressing -05 to the IESG. Unless we believe error never happen, a standardized conflict resolution pr= ocedure is needed to safely deploy MPLS Segment Routing in a multi-vendor n= etwork. Some implementations are waiting for this document to be advanced t= o RFC in order to implement the stable behavior. IMO, -05 is ready: - "SR Global Block Inconsistency" is ready for months (>1 year) - "SR-MPLS Segment Identifier Conflicts" required more time to progress and= explored multiple options, but after much work from the authors, -05 seems= ready to me. For forwarding nodes, it defines a per FEC preference rule li= miting the conflict resolution to only the FEC (prefix/SID) which indeed fa= ce conflicting advertisements. For non-forwarding nodes (e.g. network contr= ollers, PCE...), it allows more freedom in the SID to be used (or discarded= ), including a simplified procedure disregarding all conflicting entries. Thanks, Regards, --Bruno > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Vigour= eux > Sent: Monday, July 10, 2017 2:58 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolu= tion >=20 > WG, >=20 > We are half-way through the WG Last Call and I am very surprised to only > see a single answer to it. >=20 > I am not sure I'll move this forward with only silence as support. >=20 > -m >=20 > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > > Hello Working Group, > > > > This email starts a Working Group Last Call on > > draft-ietf-spring-conflict-resolution-04 [1] which is considered mature > > and ready for a final working group review. > > > > =A4 Please read this document if you haven't read the most recent > > version yet, and send your comments to the list, no later than > > *21st of July*. > > Note that this is *not only* a call for comments on the document; it is > > also a call for support (or not) to publish this document as a Proposed > > Standard RFC. > > > > =A4 *Coincidentally*, we are also polling for knowledge of any IPR that > > applies to draft-ietf-spring-conflict-resolution, to ensure that IPR h= as > > been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, > > 3669 and 5378 for more details). > > > > If you are listed as an Author or Contributor of > > draft-ietf-spring-conflict-resolution-04 please respond to this email > > and indicate whether or not you are aware of any relevant IPR. > > > > Note that, as of today, no IPR has been disclosed against this document > > or its earlier versions. > > > > Thank you, > > Martin > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolu= tion/ > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jul 11 03:46:20 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB19127180 for ; Tue, 11 Jul 2017 03:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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 cHHfxvBlkQsF for ; Tue, 11 Jul 2017 03:46:17 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74FE9126BF3 for ; Tue, 11 Jul 2017 03:46:17 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id CC774A01C2 for ; Tue, 11 Jul 2017 12:46:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id AA8F31A00B3 for ; Tue, 11 Jul 2017 12:46:15 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0352.000; Tue, 11 Jul 2017 12:46:15 +0200 From: To: "spring@ietf.org" Thread-Topic: [mpls] draft-ietf-mpls-spring-lsp-ping Thread-Index: AQHS+ifG3LnmOt6bQEeazgDral5HgaJOcLQg Date: Tue, 11 Jul 2017 10:46:14 +0000 Message-ID: <1883_1499769975_5964AC77_1883_373_25_53C29892C857584299CBF5D05346208A477FDF06@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <73fd0b3e-2a71-4859-5dd5-d04bf12dda7f@pi.nu> In-Reply-To: <73fd0b3e-2a71-4859-5dd5-d04bf12dda7f@pi.nu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [spring] FW: [mpls] draft-ietf-mpls-spring-lsp-ping X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 10:46:19 -0000 Hi all, FYI, draft-ietf-mpls-spring-lsp-ping is been last called in the _MPLS_ WG. As this is related to MPLS SPRING, you may want to read, review and comment= on the MPLS WG. Thanks, Regards, --Bruno -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, July 11, 2017 11:26 AM To: mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-ietf-mpls-spring-lsp-ping@ietf.org Subject: [mpls] draft-ietf-mpls-spring-lsp-ping Working Groups, This is to initiate a two week MPLS working group last call in on draft-ietf-mpls-spring-lsp-ping-03. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors and contributors have stated on the working group mailing list that they are not aware of any other IPRs that relates to this document. As usual when a wglc is across an IETF week we do not count that week, this working group last call therefore ends August 1, 2017. /Loa MPLS wg co-chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jul 11 12:01:50 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E3A1317AE for ; Tue, 11 Jul 2017 12:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 5GZz_fY8zh2J for ; Tue, 11 Jul 2017 12:01:47 -0700 (PDT) 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 245601317C2 for ; Tue, 11 Jul 2017 12:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7250; q=dns/txt; s=iport; t=1499799693; x=1501009293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qQ31LVtp9B/BJ/IxG8q/jJsgUbL49Hr0DE0z43vVENg=; b=UJQu9p9SNSDQ51UTzkHQQc4LW2VJ0L/eb/RahYS7CtUAoxkr0yHvj+vG +pBb5uvdnnMJlWy4/zELGFxUKtxBsECcowhrdYMm8Je0OE0WTCNE0P5dP xVMbMDrAVD+5FNXflfjX84rSioJ3nOE0V2973jGfJkpqn5+FxPrKcXyFM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAAAVIGVZ/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgKRb5YDghEhC4R7TwIagyQ/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEBARsGEToLBQcEAgEIEQQBAQMCIwMCAgIlCxQBCAgCBAENBYonCBCrd?= =?us-ascii?q?oImiyIBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELgh2FLoMkhDsSATOCfIJhBZ8?= =?us-ascii?q?kAodGg0WIf4IMhUuDcoZclUYBHzh/C3UVSYUTHIFndoV+gSOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,347,1496102400"; d="scan'208";a="268789144" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2017 19:01:31 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6BJ1VVC012287 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Jul 2017 19:01:31 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.1210.3; Tue, 11 Jul 2017 15:01:31 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 11 Jul 2017 15:01:30 -0400 From: "Acee Lindem (acee)" To: "bruno.decraene@orange.com" , Martin Vigoureux CC: "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8NupyUnmDnQic0iwdln4sTHgaqJNWagAgAFsNACAAEiYAA== Date: Tue, 11 Jul 2017 19:01:30 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <14653_1499769693_5964AB5D_14653_463_1_53C29892C857584299CBF5D05346208A477FDEB9@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <14653_1499769693_5964AB5D_14653_463_1_53C29892C857584299CBF5D05346208A477FDEB9@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 19:01:49 -0000 SSBmdWxseSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQgYW5kLCBub3cgdGhhdCB3ZSBoYXZlIHJlYWNo ZWQgY29uc2Vuc3VzLA0KYmVsaWV2ZSB3ZSBzaG91bGQgcHVibGlzaCBpdCBiZWZvcmUgYW55b25l IGNoYW5nZXMgdGhlaXIgbWluZHPigKYNCg0KSSBoYXZlIHJldmlld2VkIHRoZSAtMDUgdmVyc2lv biBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KDQogICAgMS4gU2VjdGlvbiAzLjEg LSBNYWtlIGl0IGNsZWFyIHRoYXQgYSBsYXJnZXIgcHJlZmVyZW5jZSBpcyBtb3JlDQpwcmVmZXJy ZWQuIFdoaWxlIHRoaXMgaXMgc3RhdGVkIGluIHNlY3Rpb24gMy4zLCBpdCBtdXN0IGJlIGluZmVy cmVkIGluDQpzZWN0aW9uIDMuMSB0byB1bmRlcnN0YW5kIHRoZSB0ZXh0Lg0KICAgIDIuIEV4cGFu ZCBhY3JvbnltcyBvbiBmaXJzdCB1c2UsIGUuZy4sIFNJRCBhbmQgU1JNUy4NCiAgICAzLiBJbiBz ZWN0aW9uIDMuOCwgZG8gd2Ugd2FudCB0byBzdWdnZXN0IHRoYXQgdGhlIGNvbmZsaWN0aW5nDQpj b25maWd1cmF0aW9uIG5vdCBiZSDigJxhY2NlcHRlZOKAnSByYXRoZXIgdGhhbiBub3Qg4oCcYWR2 ZXJ0aXNlZOKAnT8NCg0KSSBhbHNvIGhhdmUgYSBudW1iZXIgb2YgZWRpdG9yaWFsIHN1Z2dlc3Rp b25zIHdoaWNoIEkgd2lsbCBzZW50IHRvIHRoZQ0KYXV0aG9ycyBvZmZsaW5lLiANCg0KVGhhbmtz LA0KQWNlZSANCg0KT24gNy8xMS8xNywgNjo0MSBBTSwgInNwcmluZyBvbiBiZWhhbGYgb2YgYnJ1 bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSINCjxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCj5NYXJ0aW4sDQo+DQo+ QXMgYW4gaW5kaXZpZHVhbCBjb250cmlidXRvciwgSSBoYXZlIHJlYWQgYWxsIHZlcnNpb25zIG9m IHRoaXMgZG9jdW1lbnQNCj5hbmQgc3VwcG9ydCBwcm9ncmVzc2luZyAtMDUgdG8gdGhlIElFU0cu DQo+DQo+VW5sZXNzIHdlIGJlbGlldmUgZXJyb3IgbmV2ZXIgaGFwcGVuLCBhIHN0YW5kYXJkaXpl ZCBjb25mbGljdCByZXNvbHV0aW9uDQo+cHJvY2VkdXJlIGlzIG5lZWRlZCB0byBzYWZlbHkgZGVw bG95IE1QTFMgU2VnbWVudCBSb3V0aW5nIGluIGENCj5tdWx0aS12ZW5kb3IgbmV0d29yay4gU29t ZSBpbXBsZW1lbnRhdGlvbnMgYXJlIHdhaXRpbmcgZm9yIHRoaXMgZG9jdW1lbnQNCj50byBiZSBh ZHZhbmNlZCB0byBSRkMgaW4gb3JkZXIgdG8gaW1wbGVtZW50IHRoZSBzdGFibGUgYmVoYXZpb3Iu DQo+DQo+SU1PLCAtMDUgaXMgcmVhZHk6DQo+LSAiU1IgR2xvYmFsIEJsb2NrIEluY29uc2lzdGVu Y3kiIGlzIHJlYWR5IGZvciBtb250aHMgKD4xIHllYXIpDQo+LSAiU1ItTVBMUyBTZWdtZW50IElk ZW50aWZpZXIgQ29uZmxpY3RzIiByZXF1aXJlZCBtb3JlIHRpbWUgdG8gcHJvZ3Jlc3MNCj5hbmQg ZXhwbG9yZWQgbXVsdGlwbGUgb3B0aW9ucywgYnV0IGFmdGVyIG11Y2ggd29yayBmcm9tIHRoZSBh dXRob3JzLCAtMDUNCj5zZWVtcyByZWFkeSB0byBtZS4gRm9yIGZvcndhcmRpbmcgbm9kZXMsIGl0 IGRlZmluZXMgYSBwZXIgRkVDIHByZWZlcmVuY2UNCj5ydWxlIGxpbWl0aW5nIHRoZSBjb25mbGlj dCByZXNvbHV0aW9uIHRvIG9ubHkgdGhlIEZFQyAocHJlZml4L1NJRCkgd2hpY2gNCj5pbmRlZWQg ZmFjZSBjb25mbGljdGluZyBhZHZlcnRpc2VtZW50cy4gRm9yIG5vbi1mb3J3YXJkaW5nIG5vZGVz IChlLmcuDQo+bmV0d29yayBjb250cm9sbGVycywgUENFLi4uKSwgaXQgYWxsb3dzIG1vcmUgZnJl ZWRvbSBpbiB0aGUgU0lEIHRvIGJlDQo+dXNlZCAob3IgZGlzY2FyZGVkKSwgaW5jbHVkaW5nIGEg c2ltcGxpZmllZCBwcm9jZWR1cmUgZGlzcmVnYXJkaW5nIGFsbA0KPmNvbmZsaWN0aW5nIGVudHJp ZXMuDQo+DQo+VGhhbmtzLA0KPlJlZ2FyZHMsDQo+LS1CcnVubw0KPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4NCj5WaWdvdXJldXgNCj4gPiBTZW50OiBNb25kYXks IEp1bHkgMTAsIDIwMTcgMjo1OCBQTQ0KPiA+IFRvOiBzcHJpbmdAaWV0Zi5vcmcNCj4gPiBTdWJq ZWN0OiBSZTogW3NwcmluZ10gV0cgTGFzdCBDYWxsIGZvcg0KPmRyYWZ0LWlldGYtc3ByaW5nLWNv bmZsaWN0LXJlc29sdXRpb24NCj4gPiANCj4gPiBXRywNCj4gPiANCj4gPiBXZSBhcmUgaGFsZi13 YXkgdGhyb3VnaCB0aGUgV0cgTGFzdCBDYWxsIGFuZCBJIGFtIHZlcnkgc3VycHJpc2VkIHRvDQo+ b25seQ0KPiA+IHNlZSBhIHNpbmdsZSBhbnN3ZXIgdG8gaXQuDQo+ID4gDQo+ID4gSSBhbSBub3Qg c3VyZSBJJ2xsIG1vdmUgdGhpcyBmb3J3YXJkIHdpdGggb25seSBzaWxlbmNlIGFzIHN1cHBvcnQu DQo+ID4gDQo+ID4gLW0NCj4gPiANCj4gPiBMZSAyOS8wNi8yMDE3IMOgIDE1OjI4LCBNYXJ0aW4g Vmlnb3VyZXV4IGEgw6ljcml0IDoNCj4gPiA+IEhlbGxvIFdvcmtpbmcgR3JvdXAsDQo+ID4gPg0K PiA+ID4gVGhpcyBlbWFpbCBzdGFydHMgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbg0KPiA+ ID4gZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi0wNCBbMV0gd2hpY2ggaXMg Y29uc2lkZXJlZA0KPm1hdHVyZQ0KPiA+ID4gYW5kIHJlYWR5IGZvciBhIGZpbmFsIHdvcmtpbmcg Z3JvdXAgcmV2aWV3Lg0KPiA+ID4NCj4gPiA+IMKkIFBsZWFzZSByZWFkIHRoaXMgZG9jdW1lbnQg aWYgeW91IGhhdmVuJ3QgcmVhZCB0aGUgbW9zdCByZWNlbnQNCj4gPiA+IHZlcnNpb24geWV0LCBh bmQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBubyBsYXRlciB0aGFuDQo+ID4gPiAq MjFzdCBvZiBKdWx5Ki4NCj4gPiA+IE5vdGUgdGhhdCB0aGlzIGlzICpub3Qgb25seSogYSBjYWxs IGZvciBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQ7IGl0DQo+aXMNCj4gPiA+IGFsc28gYSBjYWxs IGZvciBzdXBwb3J0IChvciBub3QpIHRvIHB1Ymxpc2ggdGhpcyBkb2N1bWVudCBhcyBhDQo+UHJv cG9zZWQNCj4gPiA+IFN0YW5kYXJkIFJGQy4NCj4gPiA+DQo+ID4gPiDCpCAqQ29pbmNpZGVudGFs bHkqLCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0DQo+ ID4gPiBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24sIHRv IGVuc3VyZSB0aGF0IElQUg0KPmhhcw0KPiA+ID4gYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5j ZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LA0KPjQ4NzksDQo+ID4gPiAzNjY5 IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KPiA+ID4NCj4gPiA+IElmIHlvdSBhcmUgbGlz dGVkIGFzIGFuIEF1dGhvciBvciBDb250cmlidXRvciBvZg0KPiA+ID4gZHJhZnQtaWV0Zi1zcHJp bmctY29uZmxpY3QtcmVzb2x1dGlvbi0wNCBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsDQo+ ID4gPiBhbmQgaW5kaWNhdGUgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVs ZXZhbnQgSVBSLg0KPiA+ID4NCj4gPiA+IE5vdGUgdGhhdCwgYXMgb2YgdG9kYXksIG5vIElQUiBo YXMgYmVlbiBkaXNjbG9zZWQgYWdhaW5zdCB0aGlzDQo+ZG9jdW1lbnQNCj4gPiA+IG9yIGl0cyBl YXJsaWVyIHZlcnNpb25zLg0KPiA+ID4NCj4gPiA+IFRoYW5rIHlvdSwNCj4gPiA+IE1hcnRpbg0K PiA+ID4NCj4gPiA+IFsxXSANCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uLw0KPiA+ID4NCj4gPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBzcHJpbmcgbWFp bGluZyBsaXN0DQo+ID4gPiBzcHJpbmdAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+ID4gPg0KPiA+IA0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc3ByaW5nIG1haWxpbmcg bGlzdA0KPiA+IHNwcmluZ0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3ByaW5nDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPmNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+cGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleg0KPnJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0K PmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcw0KPmVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwNCj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZQ0KPm91IGZhbHNpZmllLiBNZXJjaS4NCj4NCj5UaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZA0KPmluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+ dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uDQo+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KPmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4NCj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUNCj5iZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4NCj5UaGFuayB5b3UuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5zcHJpbmcgbWFpbGluZyBsaXN0DQo+c3ByaW5nQGlldGYu b3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0K From nobody Tue Jul 11 12:46:19 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DD71317BE for ; Tue, 11 Jul 2017 12:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 m5EYPiIjL4Jq for ; Tue, 11 Jul 2017 12:46:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438701317B6 for ; Tue, 11 Jul 2017 12:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9542; q=dns/txt; s=iport; t=1499802375; x=1501011975; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0GkEkAE8uRUQpkX+31mgUdt2Kp+SFpne3756WT3cZFo=; b=UlTGJKppINRXgo9za3dg+2pTiUQhQt3LBpnDKWV+9HPGaTxfdozrU0gc DEOSE/ntdhZAQr0g4TwOsRAB7lR+PYjvQX+kDY4fbxgiB3eavB/7bzO1P eeVATXmr4i9PtbV9lYsKvQJdeU44srnr5rxiZSH72wqtVxOCaViJR3EnY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAACpKmVZ/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgKRb5YDghEhC4R7TwIagyQ/GAECAQEBAQEBAWsoQg6?= =?us-ascii?q?ESAEBAQECAQEBGwYROgsFBwQCAQgRBAEBAQICIwMCAgIlCxQBCAgCBAENBQiKH?= =?us-ascii?q?wgQq2OCJosgAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4Idg02BYYMkhDsSATO?= =?us-ascii?q?CfIJhBZ8kAodGg0WIdoIVhUuDcoZclUYBHzh/C3UVSYUTHIFndoU/Mg0XB4EFA?= =?us-ascii?q?YEMAQEB?= X-IronPort-AV: E=Sophos;i="5.40,347,1496102400"; d="scan'208";a="258379281" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2017 19:46:14 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6BJkDdt020881 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Jul 2017 19:46:14 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Jul 2017 14:46:13 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 11 Jul 2017 14:46:13 -0500 From: "Les Ginsberg (ginsberg)" To: "Acee Lindem (acee)" , "bruno.decraene@orange.com" , Martin Vigoureux CC: "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nuokzsm0yt5P0y/+D1uKMVbQqJNamsAgAFsNACAAIuwAP//tluw Date: Tue, 11 Jul 2017 19:46:13 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <14653_1499769693_5964AB5D_14653_463_1_53C29892C857584299CBF5D05346208A477FDEB9@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 19:46:17 -0000 QWNlZSAtDQoNClRoYW54IGZvciB5b3VyIHN1cHBvcnQgYWJkIHlvdXIgY29tbWVudHMuDQpSZXNw b25zZXMgaW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNw cmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBM aW5kZW0NCj4gKGFjZWUpDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTEsIDIwMTcgMTI6MDIgUE0N Cj4gVG86IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb207IE1hcnRpbiBWaWdvdXJldXgNCj4gQ2M6 IHNwcmluZ0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NwcmluZ10gV0cgTGFzdCBDYWxsIGZv ciBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uDQo+IA0KPiBJIGZ1bGx5IHN1 cHBvcnQgdGhpcyBkb2N1bWVudCBhbmQsIG5vdyB0aGF0IHdlIGhhdmUgcmVhY2hlZCBjb25zZW5z dXMsDQo+IGJlbGlldmUgd2Ugc2hvdWxkIHB1Ymxpc2ggaXQgYmVmb3JlIGFueW9uZSBjaGFuZ2Vz IHRoZWlyIG1pbmRz4oCmDQo+IA0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhlIC0wNSB2ZXJzaW9uIGFu ZCBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHM6DQo+IA0KPiAgICAgMS4gU2VjdGlvbiAzLjEg LSBNYWtlIGl0IGNsZWFyIHRoYXQgYSBsYXJnZXIgcHJlZmVyZW5jZSBpcyBtb3JlIHByZWZlcnJl ZC4NCj4gV2hpbGUgdGhpcyBpcyBzdGF0ZWQgaW4gc2VjdGlvbiAzLjMsIGl0IG11c3QgYmUgaW5m ZXJyZWQgaW4gc2VjdGlvbiAzLjEgdG8NCj4gdW5kZXJzdGFuZCB0aGUgdGV4dC4NCg0KW0xlczpd IEFncmVlZC4NCg0KPiAgICAgMi4gRXhwYW5kIGFjcm9ueW1zIG9uIGZpcnN0IHVzZSwgZS5nLiwg U0lEIGFuZCBTUk1TLg0KDQpbTGVzOl0gQUNLDQoNCj4gICAgIDMuIEluIHNlY3Rpb24gMy44LCBk byB3ZSB3YW50IHRvIHN1Z2dlc3QgdGhhdCB0aGUgY29uZmxpY3RpbmcgY29uZmlndXJhdGlvbg0K PiBub3QgYmUg4oCcYWNjZXB0ZWTigJ0gcmF0aGVyIHRoYW4gbm90IOKAnGFkdmVydGlzZWTigJ0/ DQo+IA0KW0xlczpdIEkgZG9uJ3QgdGhpbmsgc28uDQoNCldoaWxlIGl0IGlzIHBvc3NpYmxlIHRo YXQgc3VjaCBhIGNoZWNrIGNvdWxkIGJlIHJ1biBhcyBlYWNoIGNvbmZpZ3VyYXRpb24gbGluZSBp cyBlbnRlcmVkLCBzdGF0aW5nIHRoYXQgdGhpcyBpcyB0aGUgd2F5IGl0IHNob3VsZCBiZSBkb25l IGNvbnN0cmFpbnMgYW4gaW1wbGVtZW50YXRpb24gdW5uZWNlc3NhcmlseS4gVGhhdCBpcyBjZXJ0 YWlubHkgYSByZWFzb25hYmxlIHdheSBvZiBpbXBsZW1lbnRpbmcgaXQsIGJ1dCBub3QgdGhlIG9u bHkgd2F5LiBGb3IgZXhhbXBsZSwgIGEgbm9kZSBjb3VsZCBhbGxvdyBTUk1TIGNvbmZpZ3VyYXRp b24gdG8gYmUgZW50ZXJlZCBsb2NhbGx5IHdpdGhvdXQgdmFsaWRhdGluZyBpdCB1bnRpbCB0aGUg dXNlciBpbmRpY2F0ZXMgICJjb25maWd1cmF0aW9uIGNvbXBsZXRlIi4gVGhlbiAgdGhlIGNvbmZs aWN0IHJlc29sdXRpb24gYWxnb3JpdGhtIGNvdWxkIGJlIHJ1biAiYXMgaWYgdGhlIGNvbmZpZ3Vy ZWQgdmFsdWVzIHdlcmUgYWR2ZXJ0aXNlZCIgdG8gZGV0ZWN0IGNvbmZsaWN0cyBiZWZvcmUgYWR2 ZXJ0aXNlbWVudCBpcyBlbmFibGVkLg0KDQpJIGRvbuKAmXQgdGhpbmsgd2UgY2FyZSB3aGljaCB3 YXkgYW4gaW1wbGVtZW50YXRpb24gY2hvb3NlcyB0byBnbyAtIHRoZSB1c2VmdWwgYml0IGlzIHRo YXQgdGhlIGNoZWNrIGlzIHBlcmZvcm1lZCBCRUZPUkUgdGhlIGNvbmZpZyBpcyBhZHZlcnRpc2Vk IGFuZCBzdGFydHMgdG8gYmUgdXNlZC4NCg0KDQo+IEkgYWxzbyBoYXZlIGEgbnVtYmVyIG9mIGVk aXRvcmlhbCBzdWdnZXN0aW9ucyB3aGljaCBJIHdpbGwgc2VudCB0byB0aGUgYXV0aG9ycw0KPiBv ZmZsaW5lLg0KDQpbTGVzOl0gVGhhbnggZm9yIHRob3NlIGFzIHdlbGwuDQoNCiAgICBMZXMNCg0K PiANCj4gVGhhbmtzLA0KPiBBY2VlDQo+IA0KPiBPbiA3LzExLzE3LCA2OjQxIEFNLCAic3ByaW5n IG9uIGJlaGFsZiBvZiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIg0KPiA8c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+DQo+IHdy b3RlOg0KPiANCj4gPk1hcnRpbiwNCj4gPg0KPiA+QXMgYW4gaW5kaXZpZHVhbCBjb250cmlidXRv ciwgSSBoYXZlIHJlYWQgYWxsIHZlcnNpb25zIG9mIHRoaXMgZG9jdW1lbnQNCj4gPmFuZCBzdXBw b3J0IHByb2dyZXNzaW5nIC0wNSB0byB0aGUgSUVTRy4NCj4gPg0KPiA+VW5sZXNzIHdlIGJlbGll dmUgZXJyb3IgbmV2ZXIgaGFwcGVuLCBhIHN0YW5kYXJkaXplZCBjb25mbGljdA0KPiA+cmVzb2x1 dGlvbiBwcm9jZWR1cmUgaXMgbmVlZGVkIHRvIHNhZmVseSBkZXBsb3kgTVBMUyBTZWdtZW50IFJv dXRpbmcgaW4NCj4gPmEgbXVsdGktdmVuZG9yIG5ldHdvcmsuIFNvbWUgaW1wbGVtZW50YXRpb25z IGFyZSB3YWl0aW5nIGZvciB0aGlzDQo+ID5kb2N1bWVudCB0byBiZSBhZHZhbmNlZCB0byBSRkMg aW4gb3JkZXIgdG8gaW1wbGVtZW50IHRoZSBzdGFibGUNCj4gYmVoYXZpb3IuDQo+ID4NCj4gPklN TywgLTA1IGlzIHJlYWR5Og0KPiA+LSAiU1IgR2xvYmFsIEJsb2NrIEluY29uc2lzdGVuY3kiIGlz IHJlYWR5IGZvciBtb250aHMgKD4xIHllYXIpDQo+ID4tICJTUi1NUExTIFNlZ21lbnQgSWRlbnRp ZmllciBDb25mbGljdHMiIHJlcXVpcmVkIG1vcmUgdGltZSB0byBwcm9ncmVzcw0KPiA+YW5kIGV4 cGxvcmVkIG11bHRpcGxlIG9wdGlvbnMsIGJ1dCBhZnRlciBtdWNoIHdvcmsgZnJvbSB0aGUgYXV0 aG9ycywNCj4gPi0wNSBzZWVtcyByZWFkeSB0byBtZS4gRm9yIGZvcndhcmRpbmcgbm9kZXMsIGl0 IGRlZmluZXMgYSBwZXIgRkVDDQo+ID5wcmVmZXJlbmNlIHJ1bGUgbGltaXRpbmcgdGhlIGNvbmZs aWN0IHJlc29sdXRpb24gdG8gb25seSB0aGUgRkVDDQo+ID4ocHJlZml4L1NJRCkgd2hpY2ggaW5k ZWVkIGZhY2UgY29uZmxpY3RpbmcgYWR2ZXJ0aXNlbWVudHMuIEZvciBub24tDQo+IGZvcndhcmRp bmcgbm9kZXMgKGUuZy4NCj4gPm5ldHdvcmsgY29udHJvbGxlcnMsIFBDRS4uLiksIGl0IGFsbG93 cyBtb3JlIGZyZWVkb20gaW4gdGhlIFNJRCB0byBiZQ0KPiA+dXNlZCAob3IgZGlzY2FyZGVkKSwg aW5jbHVkaW5nIGEgc2ltcGxpZmllZCBwcm9jZWR1cmUgZGlzcmVnYXJkaW5nIGFsbA0KPiA+Y29u ZmxpY3RpbmcgZW50cmllcy4NCj4gPg0KPiA+VGhhbmtzLA0KPiA+UmVnYXJkcywNCj4gPi0tQnJ1 bm8NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBzcHJpbmcg W21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbg0KPiA+ Vmlnb3VyZXV4DQo+ID4gPiBTZW50OiBNb25kYXksIEp1bHkgMTAsIDIwMTcgMjo1OCBQTQ0KPiA+ ID4gVG86IHNwcmluZ0BpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtzcHJpbmddIFdHIExh c3QgQ2FsbCBmb3INCj4gPmRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24NCj4g PiA+DQo+ID4gPiBXRywNCj4gPiA+DQo+ID4gPiBXZSBhcmUgaGFsZi13YXkgdGhyb3VnaCB0aGUg V0cgTGFzdCBDYWxsIGFuZCBJIGFtIHZlcnkgc3VycHJpc2VkIHRvDQo+ID5vbmx5DQo+ID4gPiBz ZWUgYSBzaW5nbGUgYW5zd2VyIHRvIGl0Lg0KPiA+ID4NCj4gPiA+IEkgYW0gbm90IHN1cmUgSSds bCBtb3ZlIHRoaXMgZm9yd2FyZCB3aXRoIG9ubHkgc2lsZW5jZSBhcyBzdXBwb3J0Lg0KPiA+ID4N Cj4gPiA+IC1tDQo+ID4gPg0KPiA+ID4gTGUgMjkvMDYvMjAxNyDDoCAxNToyOCwgTWFydGluIFZp Z291cmV1eCBhIMOpY3JpdCA6DQo+ID4gPiA+IEhlbGxvIFdvcmtpbmcgR3JvdXAsDQo+ID4gPiA+ DQo+ID4gPiA+IFRoaXMgZW1haWwgc3RhcnRzIGEgV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24N Cj4gPiA+ID4gZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi0wNCBbMV0gd2hp Y2ggaXMgY29uc2lkZXJlZA0KPiA+bWF0dXJlDQo+ID4gPiA+IGFuZCByZWFkeSBmb3IgYSBmaW5h bCB3b3JraW5nIGdyb3VwIHJldmlldy4NCj4gPiA+ID4NCj4gPiA+ID4gwqQgUGxlYXNlIHJlYWQg dGhpcyBkb2N1bWVudCBpZiB5b3UgaGF2ZW4ndCByZWFkIHRoZSBtb3N0IHJlY2VudA0KPiA+ID4g PiB2ZXJzaW9uIHlldCwgYW5kIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdCwgbm8gbGF0 ZXIgdGhhbg0KPiA+ID4gPiAqMjFzdCBvZiBKdWx5Ki4NCj4gPiA+ID4gTm90ZSB0aGF0IHRoaXMg aXMgKm5vdCBvbmx5KiBhIGNhbGwgZm9yIGNvbW1lbnRzIG9uIHRoZSBkb2N1bWVudDsNCj4gPiA+ ID4gaXQNCj4gPmlzDQo+ID4gPiA+IGFsc28gYSBjYWxsIGZvciBzdXBwb3J0IChvciBub3QpIHRv IHB1Ymxpc2ggdGhpcyBkb2N1bWVudCBhcyBhDQo+ID5Qcm9wb3NlZA0KPiA+ID4gPiBTdGFuZGFy ZCBSRkMuDQo+ID4gPiA+DQo+ID4gPiA+IMKkICpDb2luY2lkZW50YWxseSosIHdlIGFyZSBhbHNv IHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSDQo+ID4gPiA+IHRoYXQgYXBwbGllcyB0 byBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uLCB0byBlbnN1cmUNCj4gPiA+ ID4gdGhhdCBJUFINCj4gPmhhcw0KPiA+ID4gPiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNl IHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksDQo+ID40ODc5LA0KPiA+ID4gPiAz NjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KPiA+ID4gPg0KPiA+ID4gPiBJZiB5b3Ug YXJlIGxpc3RlZCBhcyBhbiBBdXRob3Igb3IgQ29udHJpYnV0b3Igb2YNCj4gPiA+ID4gZHJhZnQt aWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi0wNCBwbGVhc2UgcmVzcG9uZCB0byB0aGlz DQo+ID4gPiA+IGVtYWlsIGFuZCBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJl IG9mIGFueSByZWxldmFudCBJUFIuDQo+ID4gPiA+DQo+ID4gPiA+IE5vdGUgdGhhdCwgYXMgb2Yg dG9kYXksIG5vIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgYWdhaW5zdCB0aGlzDQo+ID5kb2N1bWVu dA0KPiA+ID4gPiBvciBpdHMgZWFybGllciB2ZXJzaW9ucy4NCj4gPiA+ID4NCj4gPiA+ID4gVGhh bmsgeW91LA0KPiA+ID4gPiBNYXJ0aW4NCj4gPiA+ID4NCj4gPiA+ID4gWzFdDQo+ID5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNv bHV0aW9uLw0KPiA+ID4gPg0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ID4gPiA+IHNw cmluZ0BpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwcmluZw0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ID4g PiBzcHJpbmdAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3ByaW5nDQo+ID4NCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fXw0KPiA+X19fIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cw0KPiA+Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMg cGFzIGV0cmUgZGlmZnVzZXMsDQo+ID5leHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhcg0KPiA+ZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUNCj4g PmxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzDQo+ID5kJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUNCj4gPmFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuDQo+ID4NCj4gPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkDQo+ID5pbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUNCj4gPmRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ID5JZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k DQo+ID5kZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID5BcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUNCj4gPmJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+VGhhbmsg eW91Lg0KPiA+DQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+c3ByaW5nIG1haWxpbmcgbGlzdA0KPiA+c3ByaW5nQGlldGYub3JnDQo+ID5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc3ByaW5nIG1haWxpbmcg bGlzdA0KPiBzcHJpbmdAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmcNCg== From nobody Tue Jul 11 12:49:37 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66C21317C6 for ; Tue, 11 Jul 2017 12:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 O6mjyFE-vmST for ; Tue, 11 Jul 2017 12:49:33 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD581317C2 for ; Tue, 11 Jul 2017 12:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10058; q=dns/txt; s=iport; t=1499802573; x=1501012173; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oYnF2cq9spElwgcnvybyfYMjiMDm8+cIACMcnEwbHlU=; b=MtUdUtBv0utgnTtMXpIQ/u3RqP0vmZoB6+ng0s9xRHfL70Cv6nYGj3Wp ExdoLJ5oOYwaG5zM3fDWKnW1bXZWxPDDUgxegQ4+3rUQDtXrsAxAenmQ4 zt2Zv7OHQOVYLpzAnO1ceI3+7EWcp5K5fr/87fQwkJnu445uw6tOZaYrJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAAAnK2VZ/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgKRb5YDghEhC4R7TwIagyQ/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEBARsGEToLBQcEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQBDQWKJwgQq?= =?us-ascii?q?2OCJosgAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4IdhS6DJIQ7EgEzgnyCYQW?= =?us-ascii?q?XO4dpAodGg0WIf4IMhUuDcoZclUYBHzh/C3UVSYUTHIFndoVxDRcHgQWBDQEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.40,347,1496102400"; d="scan'208";a="271788730" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2017 19:49:32 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v6BJnVsL016792 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Jul 2017 19:49:31 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Jul 2017 15:49:30 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 11 Jul 2017 15:49:30 -0400 From: "Acee Lindem (acee)" To: "Les Ginsberg (ginsberg)" , "bruno.decraene@orange.com" , Martin Vigoureux CC: "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8NupyUnmDnQic0iwdln4sTHgaqJNWagAgAFsNACAAEiYAIAAT5aA//+914A= Date: Tue, 11 Jul 2017 19:49:30 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <14653_1499769693_5964AB5D_14653_463_1_53C29892C857584299CBF5D05346208A477FDEB9@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <8E329DF3C026A54BB17C40B4FBB1EC90@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 19:49:36 -0000 SGkgTGVzLCANCg0KSSBhZ3JlZSB3aXRoIHRoZSByZXNwb25zZXMuDQoNCk9uIDcvMTEvMTcsIDM6 NDYgUE0sICJMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSIgPGdpbnNiZXJnQGNpc2NvLmNvbT4gd3Jv dGU6DQoNCj5BY2VlIC0NCj4NCj5UaGFueCBmb3IgeW91ciBzdXBwb3J0IGFiZCB5b3VyIGNvbW1l bnRzLg0KPlJlc3BvbnNlcyBpbmxpbmUuDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBBY2VlIExpbmRlbQ0KPj4gKGFjZWUpDQo+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDEx LCAyMDE3IDEyOjAyIFBNDQo+PiBUbzogYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTsgTWFydGlu IFZpZ291cmV1eA0KPj4gQ2M6IHNwcmluZ0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzcHJp bmddIFdHIExhc3QgQ2FsbCBmb3INCj4+ZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1 dGlvbg0KPj4gDQo+PiBJIGZ1bGx5IHN1cHBvcnQgdGhpcyBkb2N1bWVudCBhbmQsIG5vdyB0aGF0 IHdlIGhhdmUgcmVhY2hlZCBjb25zZW5zdXMsDQo+PiBiZWxpZXZlIHdlIHNob3VsZCBwdWJsaXNo IGl0IGJlZm9yZSBhbnlvbmUgY2hhbmdlcyB0aGVpciBtaW5kc+KApg0KPj4gDQo+PiBJIGhhdmUg cmV2aWV3ZWQgdGhlIC0wNSB2ZXJzaW9uIGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHM6 DQo+PiANCj4+ICAgICAxLiBTZWN0aW9uIDMuMSAtIE1ha2UgaXQgY2xlYXIgdGhhdCBhIGxhcmdl ciBwcmVmZXJlbmNlIGlzIG1vcmUNCj4+cHJlZmVycmVkLg0KPj4gV2hpbGUgdGhpcyBpcyBzdGF0 ZWQgaW4gc2VjdGlvbiAzLjMsIGl0IG11c3QgYmUgaW5mZXJyZWQgaW4gc2VjdGlvbiAzLjENCj4+ dG8NCj4+IHVuZGVyc3RhbmQgdGhlIHRleHQuDQo+DQo+W0xlczpdIEFncmVlZC4NCj4NCj4+ICAg ICAyLiBFeHBhbmQgYWNyb255bXMgb24gZmlyc3QgdXNlLCBlLmcuLCBTSUQgYW5kIFNSTVMuDQo+ DQo+W0xlczpdIEFDSw0KPg0KPj4gICAgIDMuIEluIHNlY3Rpb24gMy44LCBkbyB3ZSB3YW50IHRv IHN1Z2dlc3QgdGhhdCB0aGUgY29uZmxpY3RpbmcNCj4+Y29uZmlndXJhdGlvbg0KPj4gbm90IGJl IOKAnGFjY2VwdGVk4oCdIHJhdGhlciB0aGFuIG5vdCDigJxhZHZlcnRpc2Vk4oCdPw0KPj4gDQo+ W0xlczpdIEkgZG9uJ3QgdGhpbmsgc28uDQo+DQo+V2hpbGUgaXQgaXMgcG9zc2libGUgdGhhdCBz dWNoIGEgY2hlY2sgY291bGQgYmUgcnVuIGFzIGVhY2ggY29uZmlndXJhdGlvbg0KPmxpbmUgaXMg ZW50ZXJlZCwgc3RhdGluZyB0aGF0IHRoaXMgaXMgdGhlIHdheSBpdCBzaG91bGQgYmUgZG9uZQ0K PmNvbnN0cmFpbnMgYW4gaW1wbGVtZW50YXRpb24gdW5uZWNlc3NhcmlseS4gVGhhdCBpcyBjZXJ0 YWlubHkgYQ0KPnJlYXNvbmFibGUgd2F5IG9mIGltcGxlbWVudGluZyBpdCwgYnV0IG5vdCB0aGUg b25seSB3YXkuIEZvciBleGFtcGxlLCAgYQ0KPm5vZGUgY291bGQgYWxsb3cgU1JNUyBjb25maWd1 cmF0aW9uIHRvIGJlIGVudGVyZWQgbG9jYWxseSB3aXRob3V0DQo+dmFsaWRhdGluZyBpdCB1bnRp bCB0aGUgdXNlciBpbmRpY2F0ZXMgICJjb25maWd1cmF0aW9uIGNvbXBsZXRlIi4gVGhlbg0KPnRo ZSBjb25mbGljdCByZXNvbHV0aW9uIGFsZ29yaXRobSBjb3VsZCBiZSBydW4gImFzIGlmIHRoZSBj b25maWd1cmVkDQo+dmFsdWVzIHdlcmUgYWR2ZXJ0aXNlZCIgdG8gZGV0ZWN0IGNvbmZsaWN0cyBi ZWZvcmUgYWR2ZXJ0aXNlbWVudCBpcw0KPmVuYWJsZWQuDQo+DQo+SSBkb27igJl0IHRoaW5rIHdl IGNhcmUgd2hpY2ggd2F5IGFuIGltcGxlbWVudGF0aW9uIGNob29zZXMgdG8gZ28gLSB0aGUNCj51 c2VmdWwgYml0IGlzIHRoYXQgdGhlIGNoZWNrIGlzIHBlcmZvcm1lZCBCRUZPUkUgdGhlIGNvbmZp ZyBpcyBhZHZlcnRpc2VkDQo+YW5kIHN0YXJ0cyB0byBiZSB1c2VkLg0KDQpUaGF0IGlzIHJlYXNv bmFibGUuDQoNClRoYW5rcywNCkFjZWUNCg0KPg0KPg0KPj4gSSBhbHNvIGhhdmUgYSBudW1iZXIg b2YgZWRpdG9yaWFsIHN1Z2dlc3Rpb25zIHdoaWNoIEkgd2lsbCBzZW50IHRvIHRoZQ0KPj5hdXRo b3JzDQo+PiBvZmZsaW5lLg0KPg0KPltMZXM6XSBUaGFueCBmb3IgdGhvc2UgYXMgd2VsbC4NCj4N Cj4gICAgTGVzDQo+DQo+PiANCj4+IFRoYW5rcywNCj4+IEFjZWUNCj4+IA0KPj4gT24gNy8xMS8x NywgNjo0MSBBTSwgInNwcmluZyBvbiBiZWhhbGYgb2YgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bSINCj4+IDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYnJ1bm8uZGVjcmFl bmVAb3JhbmdlLmNvbT4NCj4+IHdyb3RlOg0KPj4gDQo+PiA+TWFydGluLA0KPj4gPg0KPj4gPkFz IGFuIGluZGl2aWR1YWwgY29udHJpYnV0b3IsIEkgaGF2ZSByZWFkIGFsbCB2ZXJzaW9ucyBvZiB0 aGlzIGRvY3VtZW50DQo+PiA+YW5kIHN1cHBvcnQgcHJvZ3Jlc3NpbmcgLTA1IHRvIHRoZSBJRVNH Lg0KPj4gPg0KPj4gPlVubGVzcyB3ZSBiZWxpZXZlIGVycm9yIG5ldmVyIGhhcHBlbiwgYSBzdGFu ZGFyZGl6ZWQgY29uZmxpY3QNCj4+ID5yZXNvbHV0aW9uIHByb2NlZHVyZSBpcyBuZWVkZWQgdG8g c2FmZWx5IGRlcGxveSBNUExTIFNlZ21lbnQgUm91dGluZyBpbg0KPj4gPmEgbXVsdGktdmVuZG9y IG5ldHdvcmsuIFNvbWUgaW1wbGVtZW50YXRpb25zIGFyZSB3YWl0aW5nIGZvciB0aGlzDQo+PiA+ ZG9jdW1lbnQgdG8gYmUgYWR2YW5jZWQgdG8gUkZDIGluIG9yZGVyIHRvIGltcGxlbWVudCB0aGUg c3RhYmxlDQo+PiBiZWhhdmlvci4NCj4+ID4NCj4+ID5JTU8sIC0wNSBpcyByZWFkeToNCj4+ID4t ICJTUiBHbG9iYWwgQmxvY2sgSW5jb25zaXN0ZW5jeSIgaXMgcmVhZHkgZm9yIG1vbnRocyAoPjEg eWVhcikNCj4+ID4tICJTUi1NUExTIFNlZ21lbnQgSWRlbnRpZmllciBDb25mbGljdHMiIHJlcXVp cmVkIG1vcmUgdGltZSB0byBwcm9ncmVzcw0KPj4gPmFuZCBleHBsb3JlZCBtdWx0aXBsZSBvcHRp b25zLCBidXQgYWZ0ZXIgbXVjaCB3b3JrIGZyb20gdGhlIGF1dGhvcnMsDQo+PiA+LTA1IHNlZW1z IHJlYWR5IHRvIG1lLiBGb3IgZm9yd2FyZGluZyBub2RlcywgaXQgZGVmaW5lcyBhIHBlciBGRUMN Cj4+ID5wcmVmZXJlbmNlIHJ1bGUgbGltaXRpbmcgdGhlIGNvbmZsaWN0IHJlc29sdXRpb24gdG8g b25seSB0aGUgRkVDDQo+PiA+KHByZWZpeC9TSUQpIHdoaWNoIGluZGVlZCBmYWNlIGNvbmZsaWN0 aW5nIGFkdmVydGlzZW1lbnRzLiBGb3Igbm9uLQ0KPj4gZm9yd2FyZGluZyBub2RlcyAoZS5nLg0K Pj4gPm5ldHdvcmsgY29udHJvbGxlcnMsIFBDRS4uLiksIGl0IGFsbG93cyBtb3JlIGZyZWVkb20g aW4gdGhlIFNJRCB0byBiZQ0KPj4gPnVzZWQgKG9yIGRpc2NhcmRlZCksIGluY2x1ZGluZyBhIHNp bXBsaWZpZWQgcHJvY2VkdXJlIGRpc3JlZ2FyZGluZyBhbGwNCj4+ID5jb25mbGljdGluZyBlbnRy aWVzLg0KPj4gPg0KPj4gPlRoYW5rcywNCj4+ID5SZWdhcmRzLA0KPj4gPi0tQnJ1bm8NCj4+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPiA+IEZyb206IHNwcmluZyBbbWFpbHRv OnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluDQo+PiA+Vmlnb3Vy ZXV4DQo+PiA+ID4gU2VudDogTW9uZGF5LCBKdWx5IDEwLCAyMDE3IDI6NTggUE0NCj4+ID4gPiBU bzogc3ByaW5nQGlldGYub3JnDQo+PiA+ID4gU3ViamVjdDogUmU6IFtzcHJpbmddIFdHIExhc3Qg Q2FsbCBmb3INCj4+ID5kcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uDQo+PiA+ ID4NCj4+ID4gPiBXRywNCj4+ID4gPg0KPj4gPiA+IFdlIGFyZSBoYWxmLXdheSB0aHJvdWdoIHRo ZSBXRyBMYXN0IENhbGwgYW5kIEkgYW0gdmVyeSBzdXJwcmlzZWQgdG8NCj4+ID5vbmx5DQo+PiA+ ID4gc2VlIGEgc2luZ2xlIGFuc3dlciB0byBpdC4NCj4+ID4gPg0KPj4gPiA+IEkgYW0gbm90IHN1 cmUgSSdsbCBtb3ZlIHRoaXMgZm9yd2FyZCB3aXRoIG9ubHkgc2lsZW5jZSBhcyBzdXBwb3J0Lg0K Pj4gPiA+DQo+PiA+ID4gLW0NCj4+ID4gPg0KPj4gPiA+IExlIDI5LzA2LzIwMTcgw6AgMTU6Mjgs IE1hcnRpbiBWaWdvdXJldXggYSDDqWNyaXQgOg0KPj4gPiA+ID4gSGVsbG8gV29ya2luZyBHcm91 cCwNCj4+ID4gPiA+DQo+PiA+ID4gPiBUaGlzIGVtYWlsIHN0YXJ0cyBhIFdvcmtpbmcgR3JvdXAg TGFzdCBDYWxsIG9uDQo+PiA+ID4gPiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0 aW9uLTA0IFsxXSB3aGljaCBpcyBjb25zaWRlcmVkDQo+PiA+bWF0dXJlDQo+PiA+ID4gPiBhbmQg cmVhZHkgZm9yIGEgZmluYWwgd29ya2luZyBncm91cCByZXZpZXcuDQo+PiA+ID4gPg0KPj4gPiA+ ID4gwqQgUGxlYXNlIHJlYWQgdGhpcyBkb2N1bWVudCBpZiB5b3UgaGF2ZW4ndCByZWFkIHRoZSBt b3N0IHJlY2VudA0KPj4gPiA+ID4gdmVyc2lvbiB5ZXQsIGFuZCBzZW5kIHlvdXIgY29tbWVudHMg dG8gdGhlIGxpc3QsIG5vIGxhdGVyIHRoYW4NCj4+ID4gPiA+ICoyMXN0IG9mIEp1bHkqLg0KPj4g PiA+ID4gTm90ZSB0aGF0IHRoaXMgaXMgKm5vdCBvbmx5KiBhIGNhbGwgZm9yIGNvbW1lbnRzIG9u IHRoZSBkb2N1bWVudDsNCj4+ID4gPiA+IGl0DQo+PiA+aXMNCj4+ID4gPiA+IGFsc28gYSBjYWxs IGZvciBzdXBwb3J0IChvciBub3QpIHRvIHB1Ymxpc2ggdGhpcyBkb2N1bWVudCBhcyBhDQo+PiA+ UHJvcG9zZWQNCj4+ID4gPiA+IFN0YW5kYXJkIFJGQy4NCj4+ID4gPiA+DQo+PiA+ID4gPiDCpCAq Q29pbmNpZGVudGFsbHkqLCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55 IElQUg0KPj4gPiA+ID4gdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0 LXJlc29sdXRpb24sIHRvIGVuc3VyZQ0KPj4gPiA+ID4gdGhhdCBJUFINCj4+ID5oYXMNCj4+ID4g PiA+IGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2Vl IFJGQ3MgMzk3OSwNCj4+ID40ODc5LA0KPj4gPiA+ID4gMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBk ZXRhaWxzKS4NCj4+ID4gPiA+DQo+PiA+ID4gPiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhbiBBdXRo b3Igb3IgQ29udHJpYnV0b3Igb2YNCj4+ID4gPiA+IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0 LXJlc29sdXRpb24tMDQgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcw0KPj4gPiA+ID4gZW1haWwgYW5k IGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50DQo+ PklQUi4NCj4+ID4gPiA+DQo+PiA+ID4gPiBOb3RlIHRoYXQsIGFzIG9mIHRvZGF5LCBubyBJUFIg aGFzIGJlZW4gZGlzY2xvc2VkIGFnYWluc3QgdGhpcw0KPj4gPmRvY3VtZW50DQo+PiA+ID4gPiBv ciBpdHMgZWFybGllciB2ZXJzaW9ucy4NCj4+ID4gPiA+DQo+PiA+ID4gPiBUaGFuayB5b3UsDQo+ PiA+ID4gPiBNYXJ0aW4NCj4+ID4gPiA+DQo+PiA+ID4gPiBbMV0NCj4+ID5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9u Lw0KPj4gPiA+ID4NCj4+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiA+ID4gPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+PiA+ID4gPiBzcHJp bmdAaWV0Zi5vcmcNCj4+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3ByaW5nDQo+PiA+ID4gPg0KPj4gPiA+DQo+PiA+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4gPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ PiA+ID4gc3ByaW5nQGlldGYub3JnDQo+PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zcHJpbmcNCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IF9fX19fX19fX19fX19fDQo+PiA+X19f IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+DQo+ PiA+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zDQo+PiA+Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsDQo+PiA+ZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXINCj4+ID5l cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZQ0KPj4gPmxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzDQo+PiA+ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+PiA+YWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4+ID4NCj4+ID5UaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZA0KPj4g PmluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5v dCBiZQ0KPj4gPmRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uDQo+PiA+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KPj4gPmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4NCj4+ID5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUNCj4+ID5iZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCj4+ID5UaGFuayB5b3UuDQo+PiA+DQo+PiA+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5zcHJpbmcgbWFpbGluZyBsaXN0 DQo+PiA+c3ByaW5nQGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmcNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4+IHNwcmluZ0BpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0K From nobody Fri Jul 14 07:51:45 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8D13190D for ; Fri, 14 Jul 2017 07:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 WB8b8BS3nCUg for ; Fri, 14 Jul 2017 07:51:42 -0700 (PDT) Received: from owl2.lab.dtag.de (Owl2.lab.DTAG.DE [194.25.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id 43113131905 for ; Fri, 14 Jul 2017 07:51:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id 7E96FC6AF1 for ; Fri, 14 Jul 2017 16:51:40 +0200 (CEST) Received: from owl2.lab.dtag.de ([127.0.0.1]) by localhost (owl2.lab.dtag.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKR0IVw8YNa6 for ; Fri, 14 Jul 2017 16:51:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id A5DB4C6F3F for ; Fri, 14 Jul 2017 16:51:39 +0200 (CEST) Received: from dhcp-85.intranet (p5797B4A3.dip0.t-ipconnect.de [87.151.180.163]) by owl2.lab.dtag.de (Postfix) with ESMTPSA id 8C4D9C6AF1 for ; Fri, 14 Jul 2017 16:51:39 +0200 (CEST) To: spring@ietf.org References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> From: Martin Horneffer Message-ID: <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> Date: Fri, 14 Jul 2017 16:51:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 14:51:44 -0000 Strong support from me, too. From an operator's point of view this is really needed. Best regards, Martin Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > WG, > > We are half-way through the WG Last Call and I am very surprised to > only see a single answer to it. > > I am not sure I'll move this forward with only silence as support. > > -m > > Le 29/06/2017 à 15:28, Martin Vigoureux a écrit : >> Hello Working Group, >> >> This email starts a Working Group Last Call on >> draft-ietf-spring-conflict-resolution-04 [1] which is considered mature >> and ready for a final working group review. >> >> ¤ Please read this document if you haven't read the most recent >> version yet, and send your comments to the list, no later than >> *21st of July*. >> Note that this is *not only* a call for comments on the document; it is >> also a call for support (or not) to publish this document as a Proposed >> Standard RFC. >> >> ¤ *Coincidentally*, we are also polling for knowledge of any IPR that >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR has >> been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, >> 3669 and 5378 for more details). >> >> If you are listed as an Author or Contributor of >> draft-ietf-spring-conflict-resolution-04 please respond to this email >> and indicate whether or not you are aware of any relevant IPR. >> >> Note that, as of today, no IPR has been disclosed against this document >> or its earlier versions. >> >> Thank you, >> Martin >> >> [1] >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/ >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Sat Jul 15 05:23:09 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A3C130133 for ; Sat, 15 Jul 2017 05:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kRvEJ8YA_kpT for ; Sat, 15 Jul 2017 05:23:06 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171D012EC51 for ; Sat, 15 Jul 2017 05:23:06 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2BC70340E14 for ; Sat, 15 Jul 2017 14:23:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.18656); Sat, 15 Jul 2017 14:23:04 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Sat, 15 Jul 2017 14:23:04 +0200 (CEST) Received: from dhcp-80c0.meeting.ietf.org (account ietf@trammell.ch [31.133.128.192] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 23819275 for spring@ietf.org; Sat, 15 Jul 2017 14:23:03 +0200 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_91539C1A-8963-4B99-931A-0E8DC50956E1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sat, 15 Jul 2017 14:23:02 +0200 References: <481A6610-DC1F-437E-BB6E-AA8DE757803F@trammell.ch> To: spring@ietf.org Message-Id: <8421A36B-A926-4EF0-97EE-EE8444124CA1@trammell.ch> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [spring] Fwd: Proposed Path Aware Networking Research Group in Prague X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 12:23:08 -0000 --Apple-Mail=_91539C1A-8963-4B99-931A-0E8DC50956E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, and apologies for the cross-posting, We'll be having a first meeting of the proposed Path Aware Networking (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress Hall 3. As source routing is a key enabling technology for path aware networking, this is clearly of interest to SPRING, so I hope you'll have a chance to drop by. Olivier Bonaventure will give a review and overview of research to date in this space, and Adrian Perrig will present a fully path-aware Internet architecture, as an illustration of what is possible when path-awareness is promoted to a first-order goal. =46rom our proposed charter = (https://datatracker.ietf.org/group/panrg/about): The Internet architecture assumes a division between the end-to-end functionality of the transport layer and the properties of the path = between the endpoints. The path is assumed to be invisible, homogeneous, singular, = with dynamics solely determined by the connectivity of the endpoints and the = Internet control plane. Endpoints have very little information about the paths = over which their traffic is carried, and no control at all beyond the destination = address. Increased diversity in access networks, and ubiquitous mobile = connectivity, have made this architecture's assumptions about paths less tenable. Multipath protocols taking advantage of this mobile connectivity begin to show us = a way forward, though: if endpoints cannot control the path, at least they can determine the properties of the path by choosing among paths available = to them. This research group aims to support research in bringing path awareness = to transport and application layer protocols, and to bring research in this = space to the attention of the Internet engineering and protocol design = community. The scope of work within the RG includes, but is not strictly limited = to: - communication and discovery of information about the properties of a = path on local networks and in internetworks, exploration of trust and risk = models associated with this information, and algorithms for path selection at endpoints based on this information. - algorithms for making transport-layer scheduling decisions based on information about path properties. - algorithms for reconciling path selection at endpoints with widely = deployed routing protocols and network operations best practices. The research group's scope overlaps with existing IETF and IRTF efforts, = and will collaborate with groups chartered to work on multipath transport = protocols (MPTCP, QUIC, TSVWG), congestion control in multiply-connected = environments (ICCRG), and alternate routing architectures (e.g. LISP), and is related = to the questions raised in the multiple recent BoF sessions that have = addressed path awareness and multiply-connected networks (e.g. SPUD, PLUS, = BANANA). The PAN(P)RG intends to meet at each IETF meeting until a determination is made whether or not to charter it. Afterward, the RG = intends to meet at 1-3 IETF meetings per year, and hold one workshop per year, = collocated with a related academic conference. Thanks, cheers Brian (as co-chair PAN PRG) --Apple-Mail=_91539C1A-8963-4B99-931A-0E8DC50956E1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZagkmAAoJEIoSt78L6kajWJAP/0T6xgAZxiSP9cgNZRUehroZ Cw9Mm+B0cewqb+fY/9VGfLywvBO1DvV/mf4SzeAkmLCugHgGzFbXj+dFU8hesuwy YSQJU8wwn9ooCe2ahCSgk5HlCWZP1D9oqqllf9GRZnwnkaYKSLgtj22v65TIK5b/ E7SZYujMURcfsAnJXiv01S99hGpTRY8g2GR9bZvYWvAf8DXcsJblSDKhyiOYsfuU 5IzrKceH83gxLFMoc1wZCoDWHjKg45ANHG834zvyI+RgPvl8K/bWDy4VRMXbelql qbRoesTeBo9gsgPsY8PXoya47L1kA0z4WcqddvFSm/6z4lvn0vSGXiqakuN1vAJj KN4Vvn8skxDUS93o+OYiYCFtFqr/rscDneSY9hUNTnPI7Pi81vAQ2PJjhgwqB+Eg Uzbv29c8Fj6RDz41aWdBQqUwDOiH7dfUyiKslqysw/bt5WJL8B/LLq961qgMLK9u tAfLqGfaCJxKE83NXkm0W6GwptsOwT6qI9f63in0+gnMcTFy+bfoWMIfWCZYAihJ vJkH8DSnGiNbulVdeZL9zm3K+8aRPP3LsWNKF2umYBnC8a76lPzMtg1thKg8E922 DXlG0rQalzVbtEbXmi3P5R7SF01NuPkaikTWvSyPuRERuEeby8Hd9u6xaT3W+nks gOFfBK3JC1mYETxyn0Nu =Tlnf -----END PGP SIGNATURE----- --Apple-Mail=_91539C1A-8963-4B99-931A-0E8DC50956E1-- From nobody Wed Jul 19 00:10:05 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56B8131B8B; Wed, 19 Jul 2017 00:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=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_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 QMt9YTr6I10w; Wed, 19 Jul 2017 00:10:02 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.145]) (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 803F0131B89; Wed, 19 Jul 2017 00:09:58 -0700 (PDT) Received: from [85.158.136.83] by server-9.bemta-5.messagelabs.com id BA/E6-01994-4C50F695; Wed, 19 Jul 2017 07:09:56 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSeUgUcRTH9zfXTubatJv5WlaKtaRDF40KpQP DCKHsgP5QsWOscXdpd9Z21rDosJO07KAUj0oF2zCVwjQiW8tV8sqO7aAkxTzK1LALzYxqx1nL /hk+v/d97/veGx6NK59RappLsXFWnjVpKS9i0bzvs4NrSUtsyMV34WGvh5rkYUMdJ7Cw1ivFZ Fj9k1EUQUQVFY1gG1AcaeQTLCnbSMOXrHoyKTMqpbqujkhFx1amIy+aYI7j8PLXS0J8KJkLGB yp76SkRwcC+71+lI4m0RSzHMpL2iiRpzFboLCgFheTcCYbh5qGNEIUVMxSuN74zJMUAVmdn0m JdVDWWiUXmWDmQE5D5Vi+gomHH5cvjTVAzHQYbirFRMYZP2jtzh9jYBgouvsYl9gXPnT9IsXG iElD4BoYlUuCFmpKzngK/MGVfxJJ3EnBt1JB4miw38h2G9FuDoCK3s2iDzAdGLxqK6CkeBCcy tNI8RsIMj8OejwtUH2zBklCOwmOk+c8ggbsw3c8Qg8JLUfHf4Ua2p6nIYk10PvGQUqr8eC49Z uS1p8KjTndxFkUmDth69wJabkT0qR4EBRUfaEkXgD2wn58nB/e78ImxguQ/BqaK3DW3Zw1eGG oLsFq1BtsZtZoCg4NWawzc4LA6jkTmyDotlvM5ch9VAdlMnQbtZ1f50QzaEzrq6gM4GOVPgmW HXsMrGDYak02cYITaWhaC4pQwhKrnGrl9FxKotHkvsxxGWhv7TTFOlFWCEmsWTDqJakJhdPl2 SNDGO0cbRjG6AfiV0nwFp5T+yk2igWMWGBI5v/ajd+6C/mrVQokk8mU3kmc1Wy0/a/3IT8aaV UKjejibeRtf7v2uQfC3AOpok3iQDb2n6RORZt8CKVr9WPH5KtLV5V2/nQ5quvjLFMy9J9SU3c mFi2pWhPnH0HaA8u85bNwVeaKF+sP5Jix0/GRj8r2ZWxdxn3VRRbnjT6Keh95OL55X/P+tP7J zkNYRQa6qX068CS5PcTQHNh17G3f/KiWwZ7Pu2a2XiZiRkL4mL3h84hI59616VpCMLCh83Grw P4BsC7NYOYDAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-36.messagelabs.com!1500448192!102225156!1 X-Originating-IP: [52.41.248.36] X-StarScan-Received: X-StarScan-Version: 9.4.25; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 29857 invoked from network); 19 Jul 2017 07:09:55 -0000 Received: from ec2-52-41-248-36.us-west-2.compute.amazonaws.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (52.41.248.36) by server-11.tower-36.messagelabs.com with AES256-SHA256 encrypted SMTP; 19 Jul 2017 07:09:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=96bdXM6A65GoGJ6p0vYX6P5eEf1CgMURw6PWZTl7ijM=; b=PtR2DZY9bBQgKISeDYzAxI4kNHctouKB5aOteVN91I+eT3Yu1+Wy4pGZYuCUlsMoMghNMVyLIdC2yf4/P4Yy4WM/ZztW2ApL0DxU72K0xOGK0qd/Z1rN7fS3bm5wDJQGXw16ppLqHxjHWuPr2a6g6ViqCyC+c7wS0DwuR3mVEvU= Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by HE1PR0302MB2634.eurprd03.prod.outlook.com (10.171.94.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Wed, 19 Jul 2017 07:09:51 +0000 Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::1084:6d84:d4da:fac3]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::1084:6d84:d4da:fac3%14]) with mapi id 15.01.1282.011; Wed, 19 Jul 2017 07:09:50 +0000 From: Alexander Vainshtein To: "draft-ietf-spring-anycast-segment@ietf.org" CC: "spring@ietf.org" , Michael Gorokhovsky , Shell Nakash , Dmitry Valdman , Rotem Cohen , Ron Sdayoor , "mpls@ietf.org" , "draft-mpls-shen-egress-protection-framework@ietf.org" Thread-Topic: Anycast segments and context-specific label spaces Thread-Index: AdMAXJkJ1clImMhlSCmQwtRBBfPkPw== Date: Wed, 19 Jul 2017 07:09:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.182.117.158] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0302MB2634; 7:oFBZGOoIu19RsjPUFY0CY2VWnx92bVDYjyH2M2KD5uIfAzN3sbFCLOVQkFvA+NobtMZKpSuVkcsFheA7FFJuV0l39PO2ou+RA222l8/paTKO/ZpihBt+1kYddZLOsvFT9Myiae0r0Ldkpv+l3bZjUhp0DF4xdbqPAW5A/g0ttMrRaGS/HqUirPCr3kP/gj83y9kR+xqq+I6Q5hjpdj7QBlHsJsB0u3e+ZjDN/Zi+4VoT5sY7k1s6R0vTEtSxQIH2rRYkr7sUGZKPNowFL6VwnsbOTsZ7T6UPBtNxj82S+6RDWqPq4yhMLY+lSPLaedbXZb9EEaQmwAyn9xGKNpJWGXRnHXkY4JpyN7AYs99hUZH70tSdRDVXT1y+iLJk+wQAacU/4Gxn9FftFaAebFRHELxoWDJddi5qgUJDuNZlX8djNOECXmryOjCzE8FMEPyucBiRlutqOHa9hRfkR5TUiR0Jmmz+r1xh5BRYLEXBl1Hf6MRrR+qiIG+J36R1fHAXMPlwQGeAtsLaMJFV0S42eAPDDJc1gqHDzNfjFkZwowYref0w788f8YQOeqvgD8Ax1SjQCkGsLmnrQDJAU4dvRU9/4PL1yltkrvc9WfinP/ZcZvfx7A4/AvAnIWN+dh6N6Ox5vsrLfiUGUuILlapCNYtzcXcpAHg/EGya3E7wHlm0NNM8bW9SMTSZ3UT8d3kv7wZtMME/i7wNcKRPvXreyqKFgKzbgebKF/2wamBsS3w3K3+CG0J7cf2iWD/NY/Dw5OzvBbTWZWsFVnn04f4bHB4/WrJAAuPsTAd8RAGkA2M= x-ms-office365-filtering-correlation-id: 7d787ce3-1c46-40cb-2ec8-08d4ce7525a1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0302MB2634; x-ms-traffictypediagnostic: HE1PR0302MB2634: x-exchange-antispam-report-test: UriScan:(151999592597050)(120809045254105)(26388249023172)(236129657087228)(148574349560750)(21748063052155)(279101305709854)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(2017060910075)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0302MB2634; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0302MB2634; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39450400003)(39840400002)(39400400002)(39850400002)(53754006)(252514010)(72206003)(8936002)(74316002)(5660300001)(7736002)(790700001)(102836003)(3846002)(66066001)(189998001)(3660700001)(6116002)(2900100001)(5640700003)(8676002)(14454004)(81166006)(2501003)(7696004)(478600001)(5250100002)(606006)(25786009)(86362001)(2906002)(33656002)(4326008)(38730400002)(3280700002)(53936002)(6916009)(5630700001)(2351001)(450100002)(6506006)(110136004)(6436002)(9686003)(236005)(54906002)(6306002)(54896002)(50986999)(55016002)(54356999)(99286003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0302MB2634; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR03MB171360288107E28C92D721009DA60AM4PR03MB1713eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 07:09:50.2492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0302MB2634 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] Anycast segments and context-specific label spaces X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:10:05 -0000 --_000_AM4PR03MB171360288107E28C92D721009DA60AM4PR03MB1713eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have read the draft in question, and, from my POV, it defines, under the n= ame of Virtual LFIB, a dedicated context-specific label space (see RFC 53= 31) in the devices that are assigned= with one or more anycast segments, and uses the labels such devices alloc= ate for these segments as the context labels identifying this space. If my understanding is correct: * Explicit mapping of the definitions of the draft to already defi= ned and well-understood MPLS architectural mechanisms would greatly improv= e its readability. It would also greatly help the implementers, especially= if they have already implemented (or consider implementation of) context-= specific label spaces in their devices * Adding the relevant references (including a normative reference = to RFC 5331) seems necessary Using context-specific label spaces and context labels in conjunction with= anycast (or anycast-like) functionality in MPLS is not new. One example = (as indicated in Eric Rosen's email) is the PW Endpoint Fast Failure Protection m= echanism defined in RFC 8104. The ana= logy looks important to me since anycast groups are commonly considered as= a protection mechanism (and not just as a load-balancing one). I also thi= nk that relationships between this draft and the egress protection framewo= rk one are worth looking at carefully. My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM4PR03MB171360288107E28C92D721009DA60AM4PR03MB1713eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I have read the draft in question, and, from my POV, it defines, under the name of Vir= tual LFIB,  a dedicated context-specific label space (see RFC 5331)  in the= devices that are assigned with one or more anycast segments, and uses the= labels such devices allocate for these segments as the context labels identifying this space.

 

If my understanding is correct:

·         Explicit mapping o= f the definitions of the draft to already defined and well-understood MPLS= architectural mechanisms would greatly improve its readability. It would = also greatly help the implementers, especially if they have already implemented (or consider implementation of) context-= specific label spaces in their devices

·         Adding the relevan= t references (including a normative reference to RFC 5331) seems necessary=

 

Using context-specific label spaces and context lab= els in conjunction with anycast (or anycast-like) functionality  in M= PLS is not new. One example (as indicated in Eric Rosen’s email)  is the PW Endpoint Fast Failure Pro= tection mechanism defined in RFC 8104. The analogy = looks important to me since anycast groups are commonly considered as a pr= otection mechanism (and not just as a load-balancing one). I also think th= at relationships between this draft and the egress protection framework one are worth looking at carefully.

 

My 2c,

Sasha

 

Office: +972-39266302

Cell:      +972-549266= 302

Email:   Alexander.Vainshtein@ecitele.com=

 


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM4PR03MB171360288107E28C92D721009DA60AM4PR03MB1713eurp_-- From nobody Thu Jul 20 00:17:22 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FEF130889; Wed, 19 Jul 2017 21:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVr-xZFuNIQM; Wed, 19 Jul 2017 21:34:39 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82A212EC51; Wed, 19 Jul 2017 21:34:38 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id x125so8509438ywa.0; Wed, 19 Jul 2017 21:34:38 -0700 (PDT) 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=N7PYQ7tVPG8FR7jzlLj2cWAOff3n8BJxpiQPoDcahH8=; b=XL+UzPhCk62rEQJyfMcKRv/ZEtgNcJu1nwLYh+9B7XGQyqiLtvboYYcTrlCuKJvCgP MLskRdkO/bWTV6bPFkHJZlrb6dGX3ricPLgQgr8Dm7zJdiAIe9DZjcn+E2mq7rBbsTwY JysHPeiTse76MgFFP1UplTgKAJ8QjCtWvDtU16q0eexHmdPU0jlYRtQMM0Iw09gLWIpg mnl0dBaI93hElJqBuMnZE+QgVDrS3I9QaOe9rIqsncJ1bhiAKIoACnCb4G7Ayybu8DPX mwjwwCCa+d6IVkecN3GudnAXmSagK8LwwHV+x8JttCdj8oo18GkxQZpBIMDNRTfgtrsB nu2A== 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=N7PYQ7tVPG8FR7jzlLj2cWAOff3n8BJxpiQPoDcahH8=; b=sk4TNjkPGaSTDxAuhV1HPjA1/EOVp7dZ5sdZaMbyWjZeJC5rpPag54BK7FCj37PfGs 6++0qnUJyEb2saD0sulrJ2FSI1+U3CU+WcTyI+2+9fSE24jNIAxcCoQiZcu0wEMVHkfR tUeXgiARxde7KqVMBC8f+VwHIWScmDid/EVJF/b+MHxJ8L4Khe5aDatHwXmNJdqHZzAp OGKQx+D6canygUMsSPHx4FumnW5RTr8GMdPWgxPpmuNCUXi4Mkhllk7AmM4VWKiJF+ce QZ/R9zi9JqmtIRPySobwIJFflZBCtg5KUPzQzWecQZFN9MCGJuU/saGJOSIIV6DbOwty LbbA== X-Gm-Message-State: AIVw111/n0Wqf1sMaj6dYPT6wFLiJoLf1RRll+nDi5kFO34hZ8i+s+oH 8LxoXBkwhOGoytla2jnS3agXUsMHVQ== X-Received: by 10.13.242.196 with SMTP id b187mr1621493ywf.161.1500525277781; Wed, 19 Jul 2017 21:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.6.199 with HTTP; Wed, 19 Jul 2017 21:34:37 -0700 (PDT) In-Reply-To: References: From: Pushpasis Sarkar Date: Wed, 19 Jul 2017 21:34:37 -0700 Message-ID: To: Alexander Vainshtein Cc: "draft-ietf-spring-anycast-segment@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , "draft-mpls-shen-egress-protection-framework@ietf.org" , Shell Nakash , Michael Gorokhovsky , Dmitry Valdman , Ron Sdayoor , Rotem Cohen Content-Type: multipart/alternative; boundary="94eb2c03401028a5310554b84459" Archived-At: X-Mailman-Approved-At: Thu, 20 Jul 2017 00:17:21 -0700 Subject: Re: [spring] Anycast segments and context-specific label spaces X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 04:34:42 -0000 --94eb2c03401028a5310554b84459 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sasha, Thanks a lot for taking time to read the document and providing the much appreciated comments. Please find some comments inline. On Wed, Jul 19, 2017 at 12:09 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Hi all, > > I have read the draft > > in question, and, from my POV, it defines, under the name of Virtual LFIB= , *a > dedicated context-specific label space* (see RFC 5331 > ) in the devices that are assigned > with one or more anycast segments, and uses the labels such devices > allocate for these segments as the *context labels* identifying this > space. > [Pushpasis] Yes, that is correct. I will add a reference to RFC 5331 in the next version. > > > If my understanding is correct: > > =C2=B7 Explicit mapping of the definitions of the draft to alread= y > defined and well-understood MPLS architectural mechanisms would greatly > improve its readability. It would also greatly help the implementers, > especially if they have already implemented (or consider implementation o= f) > context-specific label spaces in their devices > [Pushpasis] At the time of writing this draft, there were already some implementations of context-specific label space , and so I thought adding those implementation details will not be useful, especially during the WGLC last calls. Implementation minute details are not welcome I assume from the WGLC reviews I have gone through so far. But l can sure add some reference to RFC5331. > =C2=B7 Adding the relevant references (including a normative refe= rence > to RFC 5331) seems necessary > > > > Using context-specific label spaces and context labels in conjunction wit= h > anycast (or anycast-like) functionality in MPLS is not new. One example > (as indicated in Eric Rosen=E2=80=99s email > ) is > the PW Endpoint Fast Failure Protection mechanism defined in RFC 8104 > . > [Pushpasis] Yes, use of context-specific label space is not new. And working in Juniper for sometime I have a good idea of its application. But using it to provide a means to do anycast segments using MPLS dataplane is very much new. And to my knowledge till date there is no other way to achieve this without recursive label lookup and context-specific label spaces. > The analogy looks important to me since anycast groups are commonly > considered as a protection mechanism (and not just as a load-balancing on= e). > [Pushpasis] Actually, about the usecases I have discussed some of the operators I have discussed with so far on this, almost all them are about policy-based-routing, load-balancing and providing disjoint paths. Offcourse disjoint paths can be used for protection as well as load-balancing. > I also think that relationships between this draft and the egress > protection framework > > one are worth looking at carefully. > [Pushpasis] First the egress protection drafts does not seem to have gone through WG adoption. Next though these two drafts use the same mechanisms, the exact problem they try to solve are not exactly related. Nevertheless, I value your comments, suggestions and thoughts a lot, and thank you very much for providing the insights. I will definitely work on them and address them in the next draft. Thanks once again and best regards, -Pushpasis > > My 2c, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > ____________________________________________________________ > _______________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ____________________________________________________________ > _______________ > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --94eb2c03401028a5310554b84459 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sasha,

Thanks a lot for taking time = to read the document and providing the much appreciated comments. Please fi= nd some comments inline.

On Wed, Jul 19, 2017 at 12:09 AM, Alexander Vai= nshtein <Alexander.Vainshtein@ecitele.com> wr= ote:

Hi all,

I have read the draft in question, and, from my POV, it defines, under the name of Virt= ual LFIB, =C2=A0a dedicated context-specific label space (see RFC 5331<= /a>) =C2=A0in the devices that are assigned with one or more anycast segmen= ts, and uses the labels such devices allocate for these segments as the context labels identifying this space.

<= div>[Pushpasis] Yes, that is correct. I will add a reference to RFC 5331 in= the next version.

=C2=A0

If my understanding is correct:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Explicit mapping of th= e definitions of the draft to already defined and well-understood MPLS arch= itectural mechanisms would greatly improve its readability. It would also g= reatly help the implementers, especially if they have already implemented (or consider implementation of) context-s= pecific label spaces in their devices

[Pushpasis] First the egress protection drafts do= es not seem to have gone through WG adoption. Next though these two drafts = use the same mechanisms, the exact problem they try to solve are not exactl= y related.

Nevertheless, I value your comments, su= ggestions and thoughts a lot, and thank you very much for providing the ins= ights. I will definitely work on them and address them in the next draft.

Thanks once again and best regards,
-Push= pasis


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

--94eb2c03401028a5310554b84459-- From nobody Thu Jul 20 04:50:22 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5461712969E; Thu, 20 Jul 2017 04:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.88 X-Spam-Level: X-Spam-Status: No, score=-6.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 VW1bpo8h4lTJ; Thu, 20 Jul 2017 04:35:59 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.107]) (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 8C23B131C13; Thu, 20 Jul 2017 04:35:55 -0700 (PDT) Received: from [193.109.255.99] by server-3.bemta-6.messagelabs.com id A1/C6-03044-99590795; Thu, 20 Jul 2017 11:35:53 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTeUgUURzHfTM7O1M58Vwtfy1GtBVZpGaULEV hdGBCpBSBHeRsjbtLe7Gz1vpPdFCRRhRdumkuuhaWaah025aB5haVV8WWZwdpVJBRqV0z++ya P3583vt+f+/3neENR2v61FpOdLtEp02w6NSjVXNnfJ0al3/ckTE72DpBH+gboPUtDV5WHywrZ /S3nuXR+sZHwyiZSbnq6WBTfL5BKo1ax5htBrs7kzE9PlPHOg6/Q+6z+z6wO9HXPpSLRnEqvI +GmzdyctFoToOPUuAffkWRRTeCnmA/o7jUeCFUn+9QKxyFE2DvtZ8qxUTjIyooe98UMkXiFDg YuM0Q0wooqHkw0jAf2k900WTcNCipfM8qzOMNcP1ZKU2mlSC4cPCy3MBxo3A61NxMVjwIj4cv gQpKYRpHQ/BlcYgBY/DdeEgTHgd9L34wxJ+H4Lp3EdmfDPmdhSzhidBSnIeUWYB71RAMdI0IK +G0Zw+jzAU8BWrfbCTb3RS8LtcSngUFuxtZ0tuM4GLnKUQEO7z9OEQToZMB36XOkXQx8LSiji JCmRqePD7Jkk+khY62A4hwDLx5XsccRrGef96OsA3e+ltDzOMIaCp4qfLIAWk8A6quJRDLZDi W18MSjoW9hUXsv/texJ5DsZLo3CY64+YkxRucZqPJZRXMlrjE2UnxVlGSBKNoEQxS/Ga7tRrJ 1ytMfq6g+970ejSBo3TjeFW6I0Mz1mDfkmMSJNMmZ7ZFlOpRDMfpgB84JmsRTtEourPMFvmO/ paBC9dF8c2KzEsOwSqZjUQKoGWcJ3/wM8VVh2rt8N0vFFcfqg1K1ahsdpuojeZLlWasNJuybX +O/v0HtKCJ2kgeyWE14Q7RaTW7/tf7UTSHdJF8iXJKuNnm+pOgXw5HyeF6l4fCuYS/knYnqk/ TfLbS3oRg5e21lVntQf2t7su526u+n2rPGti8aky/P613kne48VDEkvSrW2ur2Omrn9fNaw3z ta3xZ7YVFzVUpDJL03pSh/wZbm3prgWfolY0L2hKilu73Z+TaH8SnzlfW/4NJU25mD20mL1T4 25ef2/R4P4UW2DH0R/hXcmRMTqVZBISZ9JOSfgFSJz1gfwDAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-48.messagelabs.com!1500550548!119553610!1 X-Originating-IP: [52.41.248.36] X-StarScan-Received: X-StarScan-Version: 9.4.25; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 31613 invoked from network); 20 Jul 2017 11:35:51 -0000 Received: from ec2-52-41-248-36.us-west-2.compute.amazonaws.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-7.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 20 Jul 2017 11:35:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WxuK1Yz8KmkiH5zhoflAnikYgrYFJCK4XNldFQ8BNiU=; b=A6uVqUy0zCSFYaTPLi65G6I2a00JWICNtJ1i0k+N7wMZqrY3S5hbfhrFbMtksl5mt095lzL/5WQR48cFIRfei4BRfpYbmhuv1WX5yqjFHLK0DmUYqXL82vatVee9b2l5p0226Kuoco+t4v4p4G/UDZSxcOE0OvapOz1skqoL6T4= Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by DB6PR0301MB2278.eurprd03.prod.outlook.com (10.168.54.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Thu, 20 Jul 2017 11:35:46 +0000 Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::1084:6d84:d4da:fac3]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::1084:6d84:d4da:fac3%14]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 11:35:46 +0000 From: Alexander Vainshtein To: Pushpasis Sarkar CC: "draft-ietf-spring-mpls-anycast-segment-all@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , Shell Nakash , Michael Gorokhovsky , Dmitry Valdman , Ron Sdayoor , "Rotem Cohen" , "draft-mpls-shen-egress-protection-framework-all@ietf.org" Thread-Topic: [spring] Anycast segments and context-specific label spaces Thread-Index: AdMAXJkJ1clImMhlSCmQwtRBBfPkPwAtOVWAAAwQu0A= Date: Thu, 20 Jul 2017 11:35:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0301MB2278; 7:yKqxgKcrAO0xakP6Eay8hGtaAppG9A+Hr4jnknREkGmgdGL+nXZbtcjgSfCwoxWkAA0Z90BglWmCjQrsVv8rns5k2dqvavj5+KRdqm9gu+3KpBrhEnBRsv9Qhd1EEjqoI0ommygyi/RV8NxF8BDamksXS7ptSCuSraGtdhEnWd2cKnAwVg9U+IY+HELWlnr1zidt9bBLrFeXTUpc2OGWmA77OWTgBGdtgzyNKJOz4aVXBF0ERYck7dPOHOeZsNmGPjyzvF728D+GMAftrE7NyekEG5WeFPvUDy2F+x1rCjiUE6l8KwNaUHbPq72A8eyg1la18c9oh11D7zytQNvq8QLzMx+caKSHyzDBPA4U5RPVAFwhar4vlqeMVT9Y2lrDlbJ6SevgrOzXKwhQAdNOp9nf2j2xBEFtBwYRLMO/6vMqa91wOkRc153waj7/L4nzHUrqOAGtaY3k7Z2X7E5XdIZaBZ51+A4pyBdgTSP3IfZk1hZxLI3iZGiqLCAzY1Y70WtLKylnBdG1nxIgww0IrZ2RTyxoe4yvLNBVGyRow4fSyCJv/AhJO5Yv25RHWKXpqVoSHiiKz8J5Af4q0lQdGxqPUZIPAyLTTH0XSWa8Cxrf9JVYUWrXqmD24KwJvVJEzTSHlZ0H0Ey2m6+B/q1Q8LyeZJBZlalwdpSevUA2GHfie+iumcGwDgZCpykDWfFRGfND/yjUEyC7JEmiNPxKDKYqASL1VQCfv78i32gySkw6BJNLTILdZ8CEm13eUwuAT08T9E1bPqcyVQ0Sq+flJoUnVSuoHE1UMKbXEfPskb4= x-ms-office365-filtering-correlation-id: d29c195e-3888-403b-ec59-08d4cf6376ab x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0301MB2278; x-ms-traffictypediagnostic: DB6PR0301MB2278: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(120809045254105)(26388249023172)(236129657087228)(48057245064654)(148574349560750)(21748063052155)(279101305709854)(209349559609743); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(2017060910075)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0301MB2278; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0301MB2278; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39410400002)(39850400002)(39400400002)(24454002)(53754006)(45984002)(377454003)(252514010)(790700001)(6116002)(102836003)(3846002)(19609705001)(110136004)(38730400002)(6246003)(39060400002)(2906002)(14454004)(6436002)(189998001)(54906002)(3280700002)(55016002)(3660700001)(99286003)(33656002)(6306002)(25786009)(5250100002)(9686003)(86362001)(66066001)(50986999)(229853002)(2900100001)(76176999)(606006)(6916009)(2950100002)(72206003)(54356999)(53546010)(54896002)(236005)(53936002)(6506006)(478600001)(966005)(8676002)(5660300001)(81166006)(7736002)(8936002)(74316002)(7696004)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0301MB2278; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR03MB1713F3F964B211B6A5B667869DA70AM4PR03MB1713eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 11:35:46.4523 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0301MB2278 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Thu, 20 Jul 2017 04:50:20 -0700 Subject: Re: [spring] Anycast segments and context-specific label spaces X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:36:04 -0000 --_000_AM4PR03MB1713F3F964B211B6A5B667869DA70AM4PR03MB1713eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHVzaHBhc2lzIGhpIQpMb3RzIG9mIHRoYW5rcyBmb3IgYSBwcm9tcHQgYW5kIGRldGFpbGVkIHJl c3BvbnNlLgpZb3VyIGNvbmZpcm1hdGlvbiByZWdhcmRpbmcgZGUtZmFjdG8gdXNhZ2Ugb2YgY29u dGV4dCBsYWJlbCBzcGFjZXMgYW5kIGNvbnRleHQgbGFiZWxzIGluIGNvbmp1bmN0aW9uIHdpdGgg YW55Y2FzdCBzZWdtZW50cyBpcyB2ZXJ5IGltcG9ydGFudCBhbmQgZW5jb3VyYWdpbmcuCgpBdCB0 aGUgc2FtZSB0aW1lIEkgZGlzYWdyZWUgd2l0aCB5b3VyIHBvc2l0aW9uIHdoZW4geW91IHNheSB0 aGF0IOKAnHRoZXJlIHdlcmUgYWxyZWFkeSBzb21lIGltcGxlbWVudGF0aW9ucyBvZiBjb250ZXh0 LXNwZWNpZmljIGxhYmVsIHNwYWNlICwgYW5kIHNvIEkgdGhvdWdodCBhZGRpbmcgdGhvc2UgaW1w bGVtZW50YXRpb24gZGV0YWlscyB3aWxsIG5vdCBiZSB1c2VmdWzigJ0uIEZyb20gbXkgUE9WIGNv bnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2VzIGFyZSBhbiBpbXBvcnRhbnQgZWxlbWVudCBvZiB0 aGUgTVBMUyBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZSwgdGhlcmVmb3JlIGV4cGxpY2l0bHkgc3Bl Y2lmeWluZyBpdCBhcyBhbiBlbGVtZW50IG9mIHlvdXIgc29sdXRpb24gY2Fubm90IGJlIGNvbnNp ZGVyZWQgYXMgYW4g4oCcaW1wbGVtZW50YXRpb24gZGV0YWls4oCdLgoKSSBhbHNvIHRoaW5rIHRo YXQgdXNpbmcgdGhlIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2VzIGFuZCB0aGVpciBjb250 ZXh0IGxhYmVscyBleHBsaWNpdGx5IGNvdWxkIGltcHJvdmUgYXBwbGljYWJpbGl0eSBvZiB0aGUg c29sdXRpb24gYnkgdHJlYXRpbmcgZWFjaCBhbnljYXN0IHNlZ21lbnQgY29uZmlndXJlZCBvbiB0 aGUgZGV2aWNlIGFzIGEgZGVkaWNhdGVkIGNvbnRleHQgd2l0aCBpdHMgb3duIGNvbnRleHQtc3Bl Y2lmaWMgbGFiZWwgc3BhY2UgYW5kIGNvbnRleHQgbGFiZWwuICBJbiB5b3VyIHRlcm1zLCB5b3Ug Y291bGQgdXNlIGEgZGVkaWNhdGVkIENBLVNSR0IgcGVyIGFueWNhc3QgcHJlZml4IHdpdGggdGhl IEFQU0wgZm9yIHRoaXMgc2VnbWVudCBpZGVudGlmeWluZyBzcGVjaWZpYyBDQS1TUkdCIHRvIGJl IGxvb2tlZCB1cC4gT2YgY291cnNlIHRoaXMgd291bGQgbm90IHByZWNsdWRlIHVzaW5nIHRoZSBz YW1lIENBLVNSR0IgZm9yIG11bHRpcGxlIGFueWNhc3QgcHJlZml4ZXMg4oCTIGJ1dCwgb24gdGhl IG90aGVyIGhhbmQsIHRoaXMgd291bGQgcHJvdmlkZSBmb3IgYmV0dGVyIGZsZXhpYmlsaXR5IGFz IG5ldyBhbnljYXN0IHNlZ21lbnRzIGFyZSBhZGRlZCB3aXRoIG1vcmUgdHJhZmZpYyBmbG93cyB1 c2luZyB0aGVtLgoKSG9wZWZ1bGx5IHRoZXNlIG5vdGVzIHdpbGwgYmUgdXNlZnVsLgoKUmVnYXJk cywKU2FzaGEKCk9mZmljZTogKzk3Mi0zOTI2NjMwMgpDZWxsOiAgICAgICs5NzItNTQ5MjY2MzAy CkVtYWlsOiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tCgpGcm9tOiBQdXNocGFz aXMgU2Fya2FyIFttYWlsdG86cHVzaHBhc2lzLmlldGZAZ21haWwuY29tXQpTZW50OiBUaHVyc2Rh eSwgSnVseSAyMCwgMjAxNyA3OjM1IEFNClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+CkNjOiBkcmFmdC1pZXRmLXNwcmluZy1hbnljYXN0 LXNlZ21lbnRAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgZHJhZnQt bXBscy1zaGVuLWVncmVzcy1wcm90ZWN0aW9uLWZyYW1ld29ya0BpZXRmLm9yZzsgU2hlbGwgTmFr YXNoIDxTaGVsbC5OYWthc2hAZWNpdGVsZS5jb20+OyBNaWNoYWVsIEdvcm9raG92c2t5IDxNaWNo YWVsLkdvcm9raG92c2t5QGVjaXRlbGUuY29tPjsgRG1pdHJ5IFZhbGRtYW4gPERtaXRyeS5WYWxk bWFuQGVjaXRlbGUuY29tPjsgUm9uIFNkYXlvb3IgPFJvbi5TZGF5b29yQGVjaXRlbGUuY29tPjsg Um90ZW0gQ29oZW4gPFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPgpTdWJqZWN0OiBSZTogW3Nwcmlu Z10gQW55Y2FzdCBzZWdtZW50cyBhbmQgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZXMKCkhp IFNhc2hhLAoKVGhhbmtzIGEgbG90IGZvciB0YWtpbmcgdGltZSB0byByZWFkIHRoZSBkb2N1bWVu dCBhbmQgcHJvdmlkaW5nIHRoZSBtdWNoIGFwcHJlY2lhdGVkIGNvbW1lbnRzLiBQbGVhc2UgZmlu ZCBzb21lIGNvbW1lbnRzIGlubGluZS4KCgpPbiBXZWQsIEp1bCAxOSwgMjAxNyBhdCAxMjowOSBB TSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t PG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+IHdyb3RlOgpIaSBhbGws CkkgaGF2ZSByZWFkIHRoZSBkcmFmdDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1zcHJpbmctbXBscy1hbnljYXN0LXNlZ21lbnRzLTAxPiBpbiBxdWVzdGlvbiwgYW5kLCBm cm9tIG15IFBPViwgaXQgZGVmaW5lcywgdW5kZXIgdGhlIG5hbWUgb2YgVmlydHVhbCBMRklCLCAg YSBkZWRpY2F0ZWQgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZSAoc2VlIFJGQyA1MzMxPGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MzMxPikgIGluIHRoZSBkZXZpY2VzIHRoYXQg YXJlIGFzc2lnbmVkIHdpdGggb25lIG9yIG1vcmUgYW55Y2FzdCBzZWdtZW50cywgYW5kIHVzZXMg dGhlIGxhYmVscyBzdWNoIGRldmljZXMgYWxsb2NhdGUgZm9yIHRoZXNlIHNlZ21lbnRzIGFzIHRo ZSBjb250ZXh0IGxhYmVscyBpZGVudGlmeWluZyB0aGlzIHNwYWNlLgpbUHVzaHBhc2lzXSBZZXMs IHRoYXQgaXMgY29ycmVjdC4gSSB3aWxsIGFkZCBhIHJlZmVyZW5jZSB0byBSRkMgNTMzMSBpbiB0 aGUgbmV4dCB2ZXJzaW9uLgoKCklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdDoKCuKAoiAg ICAgICAgIEV4cGxpY2l0IG1hcHBpbmcgb2YgdGhlIGRlZmluaXRpb25zIG9mIHRoZSBkcmFmdCB0 byBhbHJlYWR5IGRlZmluZWQgYW5kIHdlbGwtdW5kZXJzdG9vZCBNUExTIGFyY2hpdGVjdHVyYWwg bWVjaGFuaXNtcyB3b3VsZCBncmVhdGx5IGltcHJvdmUgaXRzIHJlYWRhYmlsaXR5LiBJdCB3b3Vs ZCBhbHNvIGdyZWF0bHkgaGVscCB0aGUgaW1wbGVtZW50ZXJzLCBlc3BlY2lhbGx5IGlmIHRoZXkg aGF2ZSBhbHJlYWR5IGltcGxlbWVudGVkIChvciBjb25zaWRlciBpbXBsZW1lbnRhdGlvbiBvZikg Y29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZXMgaW4gdGhlaXIgZGV2aWNlcwpbUHVzaHBhc2lz XSBBdCB0aGUgdGltZSBvZiB3cml0aW5nIHRoaXMgZHJhZnQsIHRoZXJlIHdlcmUgYWxyZWFkeSBz b21lIGltcGxlbWVudGF0aW9ucyBvZiBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlICwgYW5k IHNvIEkgdGhvdWdodCBhZGRpbmcgdGhvc2UgaW1wbGVtZW50YXRpb24gZGV0YWlscyB3aWxsIG5v dCBiZSB1c2VmdWwsIGVzcGVjaWFsbHkgZHVyaW5nIHRoZSBXR0xDIGxhc3QgY2FsbHMuIEltcGxl bWVudGF0aW9uIG1pbnV0ZSBkZXRhaWxzIGFyZSBub3Qgd2VsY29tZSBJIGFzc3VtZSBmcm9tIHRo ZSBXR0xDIHJldmlld3MgSSBoYXZlIGdvbmUgdGhyb3VnaCBzbyBmYXIuIEJ1dCBsIGNhbiBzdXJl IGFkZCBzb21lIHJlZmVyZW5jZSB0byBSRkM1MzMxLgoK4oCiICAgICAgICAgQWRkaW5nIHRoZSBy ZWxldmFudCByZWZlcmVuY2VzIChpbmNsdWRpbmcgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIFJG QyA1MzMxKSBzZWVtcyBuZWNlc3NhcnkKClVzaW5nIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3Bh Y2VzIGFuZCBjb250ZXh0IGxhYmVscyBpbiBjb25qdW5jdGlvbiB3aXRoIGFueWNhc3QgKG9yIGFu eWNhc3QtbGlrZSkgZnVuY3Rpb25hbGl0eSAgaW4gTVBMUyBpcyBub3QgbmV3LiBPbmUgZXhhbXBs ZSAoYXMgaW5kaWNhdGVkIGluIEVyaWMgUm9zZW7igJlzIGVtYWlsPGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzEyNjU5Lmh0bWw+KSAgaXMgdGhl IFBXIEVuZHBvaW50IEZhc3QgRmFpbHVyZSBQcm90ZWN0aW9uIG1lY2hhbmlzbSBkZWZpbmVkIGlu IFJGQyA4MTA0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTA0Pi4KW1B1c2hwYXNp c10gWWVzLCB1c2Ugb2YgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZSBpcyBub3QgbmV3LiBB bmQgd29ya2luZyBpbiBKdW5pcGVyIGZvciBzb21ldGltZSBJIGhhdmUgYSBnb29kIGlkZWEgb2Yg aXRzIGFwcGxpY2F0aW9uLiBCdXQgdXNpbmcgaXQgdG8gcHJvdmlkZSBhIG1lYW5zIHRvIGRvIGFu eWNhc3Qgc2VnbWVudHMgdXNpbmcgTVBMUyBkYXRhcGxhbmUgaXMgdmVyeSBtdWNoIG5ldy4gQW5k IHRvIG15IGtub3dsZWRnZSB0aWxsIGRhdGUgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IHRvIGFjaGll dmUgdGhpcyB3aXRob3V0IHJlY3Vyc2l2ZSBsYWJlbCBsb29rdXAgYW5kIGNvbnRleHQtc3BlY2lm aWMgbGFiZWwgc3BhY2VzLgoKVGhlIGFuYWxvZ3kgbG9va3MgaW1wb3J0YW50IHRvIG1lIHNpbmNl IGFueWNhc3QgZ3JvdXBzIGFyZSBjb21tb25seSBjb25zaWRlcmVkIGFzIGEgcHJvdGVjdGlvbiBt ZWNoYW5pc20gKGFuZCBub3QganVzdCBhcyBhIGxvYWQtYmFsYW5jaW5nIG9uZSkuCltQdXNocGFz aXNdIEFjdHVhbGx5LCBhYm91dCB0aGUgdXNlY2FzZXMgSSBoYXZlIGRpc2N1c3NlZCBzb21lIG9m IHRoZSBvcGVyYXRvcnMgSSBoYXZlIGRpc2N1c3NlZCB3aXRoIHNvIGZhciBvbiB0aGlzLCBhbG1v c3QgYWxsIHRoZW0gYXJlIGFib3V0IHBvbGljeS1iYXNlZC1yb3V0aW5nLCAgbG9hZC1iYWxhbmNp bmcgYW5kIHByb3ZpZGluZyBkaXNqb2ludCBwYXRocy4gT2ZmY291cnNlIGRpc2pvaW50IHBhdGhz IGNhbiBiZSB1c2VkIGZvciBwcm90ZWN0aW9uIGFzIHdlbGwgYXMgbG9hZC1iYWxhbmNpbmcuCgpJ IGFsc28gdGhpbmsgdGhhdCByZWxhdGlvbnNoaXBzIGJldHdlZW4gdGhpcyBkcmFmdCBhbmQgdGhl IGVncmVzcyBwcm90ZWN0aW9uIGZyYW1ld29yazxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1zaGVuLW1wbHMtZWdyZXNzLXByb3RlY3Rpb24tZnJhbWV3b3JrLz9pbmNsdWRl X3RleHQ9MT4gb25lIGFyZSB3b3J0aCBsb29raW5nIGF0IGNhcmVmdWxseS4KW1B1c2hwYXNpc10g Rmlyc3QgdGhlIGVncmVzcyBwcm90ZWN0aW9uIGRyYWZ0cyBkb2VzIG5vdCBzZWVtIHRvIGhhdmUg Z29uZSB0aHJvdWdoIFdHIGFkb3B0aW9uLiBOZXh0IHRob3VnaCB0aGVzZSB0d28gZHJhZnRzIHVz ZSB0aGUgc2FtZSBtZWNoYW5pc21zLCB0aGUgZXhhY3QgcHJvYmxlbSB0aGV5IHRyeSB0byBzb2x2 ZSBhcmUgbm90IGV4YWN0bHkgcmVsYXRlZC4KCk5ldmVydGhlbGVzcywgSSB2YWx1ZSB5b3VyIGNv bW1lbnRzLCBzdWdnZXN0aW9ucyBhbmQgdGhvdWdodHMgYSBsb3QsIGFuZCB0aGFuayB5b3UgdmVy eSBtdWNoIGZvciBwcm92aWRpbmcgdGhlIGluc2lnaHRzLiBJIHdpbGwgZGVmaW5pdGVseSB3b3Jr IG9uIHRoZW0gYW5kIGFkZHJlc3MgdGhlbSBpbiB0aGUgbmV4dCBkcmFmdC4KClRoYW5rcyBvbmNl IGFnYWluIGFuZCBiZXN0IHJlZ2FyZHMsCi1QdXNocGFzaXMKCgpNeSAyYywKU2FzaGEKCk9mZmlj ZTogKzk3Mi0zOTI2NjMwMgpDZWxsOiAgICAgICs5NzItNTQ5MjY2MzAyCkVtYWlsOiAgIEFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbT4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMg aW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24g d2hpY2ggaXMKQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJ IFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMKdHJhbnNtaXNzaW9uIGluIGVycm9y LCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxl dGUgdGhlIG9yaWdpbmFsCmFuZCBhbGwgY29waWVzIHRoZXJlb2YuCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5n IG1haWxpbmcgbGlzdApzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcKCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQg b25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgCkNPTkZJREVOVElBTCBhbmQg d2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIAp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1t YWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgCmFuZCBhbGwg Y29waWVzIHRoZXJlb2YuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo= --_000_AM4PR03MB1713F3F964B211B6A5B667869DA70AM4PR03MB1713eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bAoJe21hcmdpbjowY207CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTIuMHB0 OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Ymx1ZTsKCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQK CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpwdXJwbGU7Cgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30KcC5tNzQ5MDc0Njg3Mjk5NjUxOTE0NG1zb2xpc3RwYXJhZ3JhcGgsIGxpLm03 NDkwNzQ2ODcyOTk2NTE5MTQ0bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm03NDkwNzQ2ODcyOTk2NTE5 MTQ0bXNvbGlzdHBhcmFncmFwaAoJe21zby1zdHlsZS1uYW1lOm1fNzQ5MDc0Njg3Mjk5NjUxOTE0 NG1zb2xpc3RwYXJhZ3JhcGg7Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsKCW1hcmdpbi1yaWdo dDowY207Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsKCW1hcmdpbi1sZWZ0OjBjbTsKCWZv bnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9CnNw YW4uRW1haWxTdHlsZTE4Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7Cglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsKCWNvbG9yOiM0NDU0NkE7Cglmb250LXdlaWdodDpu b3JtYWw7Cglmb250LXN0eWxlOm5vcm1hbDsKCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQou TXNvQ2hwRGVmYXVsdAoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5OwoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQpAcGFnZSBXb3JkU2VjdGlvbjEKCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsKCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQpkaXYuV29yZFNl Y3Rpb24xCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPgo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPgo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPgo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPgo8L2hlYWQ+Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEiPlB1c2hwYXNpcyBo aSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNDQ1NDZBIj5Mb3RzIG9mIHRoYW5rcyBmb3IgYSBwcm9tcHQgYW5kIGRldGFp bGVkIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEiPllvdXIgY29uZmlybWF0aW9uIHJlZ2FyZGlu ZyBkZS1mYWN0byB1c2FnZSBvZiBjb250ZXh0IGxhYmVsIHNwYWNlcyBhbmQgY29udGV4dCBsYWJl bHMgaW4gY29uanVuY3Rpb24gd2l0aCBhbnljYXN0IHNlZ21lbnRzIGlzIHZlcnkgaW1wb3J0YW50 IGFuZCBlbmNvdXJhZ2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZB Ij5BdCB0aGUgc2FtZSB0aW1lIEkgZGlzYWdyZWUgd2l0aCB5b3VyIHBvc2l0aW9uIHdoZW4geW91 IHNheSB0aGF0IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhp Z2hsaWdodDp5ZWxsb3ciPnRoZXJlIHdlcmUgYWxyZWFkeSBzb21lIGltcGxlbWVudGF0aW9ucwog b2YgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBzcGFjZSAsIGFuZCBzbyBJIHRob3VnaHQgYWRkaW5n IHRob3NlIGltcGxlbWVudGF0aW9uIGRldGFpbHMgd2lsbCBub3QgYmUgdXNlZnVsPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBIj7igJ0uIEZyb20gbXkgUE9WIGNvbnRleHQtc3Bl Y2lmaWMgbGFiZWwgc3BhY2VzIGFyZSBhbiBpbXBvcnRhbnQgZWxlbWVudAogb2YgdGhlIE1QTFMg ZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUsIHRoZXJlZm9yZSBleHBsaWNpdGx5IHNwZWNpZnlpbmcg aXQgYXMgYW4gZWxlbWVudCBvZiB5b3VyIHNvbHV0aW9uIGNhbm5vdCBiZSBjb25zaWRlcmVkIGFz IGFuIOKAnGltcGxlbWVudGF0aW9uIGRldGFpbOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNDQ1NDZBIj5JIGFsc28gdGhpbmsgdGhhdCB1c2luZyB0aGUgY29udGV4dC1zcGVj aWZpYyBsYWJlbCBzcGFjZXMgYW5kIHRoZWlyIGNvbnRleHQgbGFiZWxzIGV4cGxpY2l0bHkgY291 bGQgaW1wcm92ZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBzb2x1dGlvbiBieSB0cmVhdGluZyBlYWNo IGFueWNhc3QKIHNlZ21lbnQgY29uZmlndXJlZCBvbiB0aGUgZGV2aWNlIGFzIGEgZGVkaWNhdGVk IGNvbnRleHQgd2l0aCBpdHMgb3duIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2UgYW5kIGNv bnRleHQgbGFiZWwuICZuYnNwO0luIHlvdXIgdGVybXMsIHlvdSBjb3VsZCB1c2UgYSBkZWRpY2F0 ZWQgQ0EtU1JHQiBwZXIgYW55Y2FzdCBwcmVmaXggd2l0aCB0aGUgQVBTTCBmb3IgdGhpcyBzZWdt ZW50IGlkZW50aWZ5aW5nIHNwZWNpZmljIENBLVNSR0IgdG8gYmUgbG9va2VkCiB1cC4gT2YgY291 cnNlIHRoaXMgd291bGQgbm90IHByZWNsdWRlIHVzaW5nIHRoZSBzYW1lIENBLVNSR0IgZm9yIG11 bHRpcGxlIGFueWNhc3QgcHJlZml4ZXMg4oCTIGJ1dCwgb24gdGhlIG90aGVyIGhhbmQsIHRoaXMg d291bGQgcHJvdmlkZSBmb3IgYmV0dGVyIGZsZXhpYmlsaXR5IGFzIG5ldyBhbnljYXN0IHNlZ21l bnRzIGFyZSBhZGRlZCB3aXRoIG1vcmUgdHJhZmZpYyBmbG93cyB1c2luZyB0aGVtLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEiPkhvcGVmdWxseSB0aGVzZSBub3RlcyB3 aWxsIGJlIHVzZWZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEiPlNhc2hhPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzQ0NTQ2QSI+T2ZmaWNlOiAmIzQzOzk3Mi0zOTI2NjMwMjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEi PkNlbGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM0NDU0NkEiPkVtYWlsOiZuYnNwOyZuYnNwOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gUHVzaHBhc2lzIFNhcmthciBbbWFpbHRvOnB1c2hwYXNpcy5pZXRm QGdtYWlsLmNvbV0KPGJyPgo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMjAsIDIwMTcgNzoz NSBBTTxicj4KPGI+VG86PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7QWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20mZ3Q7PGJyPgo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtc3ByaW5n LWFueWNhc3Qtc2VnbWVudEBpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgc3ByaW5nQGlldGYub3Jn OyBkcmFmdC1tcGxzLXNoZW4tZWdyZXNzLXByb3RlY3Rpb24tZnJhbWV3b3JrQGlldGYub3JnOyBT aGVsbCBOYWthc2ggJmx0O1NoZWxsLk5ha2FzaEBlY2l0ZWxlLmNvbSZndDs7IE1pY2hhZWwgR29y b2tob3Zza3kgJmx0O01pY2hhZWwuR29yb2tob3Zza3lAZWNpdGVsZS5jb20mZ3Q7OyBEbWl0cnkg VmFsZG1hbiAmbHQ7RG1pdHJ5LlZhbGRtYW5AZWNpdGVsZS5jb20mZ3Q7OwogUm9uIFNkYXlvb3Ig Jmx0O1Jvbi5TZGF5b29yQGVjaXRlbGUuY29tJmd0OzsgUm90ZW0gQ29oZW4gJmx0O1JvdGVtLkNv aGVuQGVjaXRlbGUuY29tJmd0Ozxicj4KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBBbnlj YXN0IHNlZ21lbnRzIGFuZCBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+Cjxk aXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFNhc2hhLDxvOnA+PC9vOnA+PC9wPgo8ZGl2Pgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBhIGxvdCBmb3IgdGFraW5nIHRpbWUgdG8gcmVhZCB0 aGUgZG9jdW1lbnQgYW5kIHByb3ZpZGluZyB0aGUgbXVjaCBhcHByZWNpYXRlZCBjb21tZW50cy4g UGxlYXNlIGZpbmQgc29tZSBjb21tZW50cyBpbmxpbmUuPG86cD48L286cD48L3A+CjwvZGl2Pgo8 ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+Cjxk aXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8ZGl2Pgo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1bCAxOSwgMjAxNyBhdCAxMjowOSBBTSwgQWxleGFu ZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+CjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+CjxkaXY+CjxkaXY+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkkgaGF2ZSByZWFkIHRoZQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctbXBscy1hbnljYXN0LXNlZ21lbnRzLTAxIiB0YXJn ZXQ9Il9ibGFuayI+CmRyYWZ0PC9hPiBpbiBxdWVzdGlvbiwgYW5kLCBmcm9tIG15IFBPViwgaXQg ZGVmaW5lcywgdW5kZXIgdGhlIG5hbWUgb2YgVmlydHVhbCBMRklCLCAmbmJzcDs8aT5hIGRlZGlj YXRlZCBjb250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlPC9pPiAoc2VlCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MzMxIiB0YXJnZXQ9Il9ibGFuayI+UkZDIDUzMzE8 L2E+KSAmbmJzcDtpbiB0aGUgZGV2aWNlcyB0aGF0IGFyZSBhc3NpZ25lZCB3aXRoIG9uZSBvciBt b3JlIGFueWNhc3Qgc2VnbWVudHMsIGFuZCB1c2VzIHRoZSBsYWJlbHMgc3VjaCBkZXZpY2VzIGFs bG9jYXRlIGZvciB0aGVzZSBzZWdtZW50cyBhcyB0aGUKPGk+Y29udGV4dCBsYWJlbHM8L2k+IGlk ZW50aWZ5aW5nIHRoaXMgc3BhY2UuPG86cD48L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9ibG9j a3F1b3RlPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bUHVzaHBhc2lzXSBZZXMsIHRoYXQg aXMgY29ycmVjdC4gSSB3aWxsIGFkZCBhIHJlZmVyZW5jZSB0byBSRkMgNTMzMSBpbiB0aGUgbmV4 dCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+CjwvZGl2Pgo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPgo8ZGl2Pgo8ZGl2Pgo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdDo8bzpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9Im03NDkwNzQ2ODcyOTk2NTE5MTQ0bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwv c3Bhbj5FeHBsaWNpdCBtYXBwaW5nIG9mIHRoZSBkZWZpbml0aW9ucyBvZiB0aGUgZHJhZnQgdG8g YWxyZWFkeSBkZWZpbmVkIGFuZCB3ZWxsLXVuZGVyc3Rvb2QgTVBMUyBhcmNoaXRlY3R1cmFsIG1l Y2hhbmlzbXMgd291bGQgZ3JlYXRseSBpbXByb3ZlIGl0cyByZWFkYWJpbGl0eS4gSXQgd291bGQg YWxzbyBncmVhdGx5IGhlbHAgdGhlIGltcGxlbWVudGVycywgZXNwZWNpYWxseSBpZiB0aGV5IGhh dmUgYWxyZWFkeSBpbXBsZW1lbnRlZCAob3IKIGNvbnNpZGVyIGltcGxlbWVudGF0aW9uIG9mKSBj b250ZXh0LXNwZWNpZmljIGxhYmVsIHNwYWNlcyBpbiB0aGVpciBkZXZpY2VzPG86cD48L286cD48 L3A+CjwvZGl2Pgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5bUHVzaHBhc2lzXSBBdCB0aGUgdGltZSBvZiB3cml0aW5nIHRoaXMgZHJhZnQsIHRoZXJlIHdl cmUgYWxyZWFkeSBzb21lIGltcGxlbWVudGF0aW9ucyBvZiBjb250ZXh0LXNwZWNpZmljIGxhYmVs IHNwYWNlICwgYW5kIHNvIEkgdGhvdWdodCBhZGRpbmcgdGhvc2UgaW1wbGVtZW50YXRpb24gZGV0 YWlscyB3aWxsIG5vdCBiZSB1c2VmdWwsIGVzcGVjaWFsbHkgZHVyaW5nIHRoZSBXR0xDIGxhc3Qg Y2FsbHMuIEltcGxlbWVudGF0aW9uCiBtaW51dGUgZGV0YWlscyBhcmUgbm90IHdlbGNvbWUgSSBh c3N1bWUgZnJvbSB0aGUgV0dMQyByZXZpZXdzIEkgaGF2ZSBnb25lIHRocm91Z2ggc28gZmFyLiBC dXQgbCBjYW4gc3VyZSBhZGQgc29tZSByZWZlcmVuY2UgdG8gUkZDNTMzMS48bzpwPjwvbzpwPjwv cD4KPC9kaXY+CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJtNzQ5MDc0Njg3Mjk5 NjUxOTE0NG1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wi PsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+QWRkaW5nIHRoZSByZWxldmFu dCByZWZlcmVuY2VzIChpbmNsdWRpbmcgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIFJGQyA1MzMx KSBzZWVtcyBuZWNlc3Nhcnk8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Vc2luZyBjb250ZXh0 LXNwZWNpZmljIGxhYmVsIHNwYWNlcyBhbmQgY29udGV4dCBsYWJlbHMgaW4gY29uanVuY3Rpb24g d2l0aCBhbnljYXN0IChvciBhbnljYXN0LWxpa2UpIGZ1bmN0aW9uYWxpdHkgJm5ic3A7aW4gTVBM UyBpcyBub3QgbmV3LiBPbmUgZXhhbXBsZSAoYXMgaW5kaWNhdGVkIGluCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzEyNjU5Lmh0 bWwiIHRhcmdldD0iX2JsYW5rIj4KRXJpYyBSb3NlbuKAmXMgZW1haWw8L2E+KSAmbmJzcDtpcyB0 aGUgUFcgRW5kcG9pbnQgRmFzdCBGYWlsdXJlIFByb3RlY3Rpb24gbWVjaGFuaXNtIGRlZmluZWQg aW4KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxMDQiIHRhcmdldD0i X2JsYW5rIj5SRkMgODEwNDwvYT4uIDxvOnA+CjwvbzpwPjwvcD4KPC9kaXY+CjwvZGl2Pgo8L2Js b2NrcXVvdGU+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPltQdXNocGFzaXNdIFllcywgdXNl IG9mIGNvbnRleHQtc3BlY2lmaWMgbGFiZWwgc3BhY2UgaXMgbm90IG5ldy4gQW5kIHdvcmtpbmcg aW4gSnVuaXBlciBmb3Igc29tZXRpbWUgSSBoYXZlIGEgZ29vZCBpZGVhIG9mIGl0cyBhcHBsaWNh dGlvbi4gQnV0IHVzaW5nIGl0IHRvIHByb3ZpZGUgYSBtZWFucyB0byBkbyBhbnljYXN0IHNlZ21l bnRzIHVzaW5nIE1QTFMgZGF0YXBsYW5lIGlzIHZlcnkgbXVjaCBuZXcuIEFuZAogdG8gbXkga25v d2xlZGdlIHRpbGwgZGF0ZSB0aGVyZSBpcyBubyBvdGhlciB3YXkgdG8gYWNoaWV2ZSB0aGlzIHdp dGhvdXQgcmVjdXJzaXZlIGxhYmVsIGxvb2t1cCBhbmQgY29udGV4dC1zcGVjaWZpYyBsYWJlbCBz cGFjZXMuPG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+CjxkaXY+CjxkaXY+CjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGhlIGFuYWxvZ3kgbG9va3MgaW1wb3J0YW50IHRvIG1lIHNpbmNl IGFueWNhc3QgZ3JvdXBzIGFyZSBjb21tb25seSBjb25zaWRlcmVkIGFzIGEgcHJvdGVjdGlvbiBt ZWNoYW5pc20gKGFuZCBub3QganVzdCBhcyBhIGxvYWQtYmFsYW5jaW5nIG9uZSkuPG86cD48L286 cD48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9y bWFsIj5bUHVzaHBhc2lzXSBBY3R1YWxseSwgYWJvdXQgdGhlIHVzZWNhc2VzIEkgaGF2ZSBkaXNj dXNzZWQgc29tZSBvZiB0aGUgb3BlcmF0b3JzIEkgaGF2ZSBkaXNjdXNzZWQgd2l0aCBzbyBmYXIg b24gdGhpcywgYWxtb3N0IGFsbCB0aGVtIGFyZSBhYm91dCBwb2xpY3ktYmFzZWQtcm91dGluZywg Jm5ic3A7bG9hZC1iYWxhbmNpbmcgYW5kIHByb3ZpZGluZyBkaXNqb2ludCBwYXRocy4gT2ZmY291 cnNlIGRpc2pvaW50IHBhdGhzCiBjYW4gYmUgdXNlZCBmb3IgcHJvdGVjdGlvbiBhcyB3ZWxsIGFz IGxvYWQtYmFsYW5jaW5nLjxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+CjwvZGl2Pgo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPgo8ZGl2Pgo8 ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWxzbyB0aGluayB0aGF0IHJlbGF0aW9uc2hp cHMgYmV0d2VlbiB0aGlzIGRyYWZ0IGFuZCB0aGUKPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtc2hlbi1tcGxzLWVncmVzcy1wcm90ZWN0aW9uLWZyYW1ld29y ay8/aW5jbHVkZV90ZXh0PTEiIHRhcmdldD0iX2JsYW5rIj4KZWdyZXNzIHByb3RlY3Rpb24gZnJh bWV3b3JrPC9hPiBvbmUgYXJlIHdvcnRoIGxvb2tpbmcgYXQgY2FyZWZ1bGx5LjxvOnA+PC9vOnA+ PC9wPgo8L2Rpdj4KPC9kaXY+CjwvYmxvY2txdW90ZT4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+W1B1c2hwYXNpc10gRmlyc3QgdGhlIGVncmVzcyBwcm90ZWN0aW9uIGRyYWZ0cyBkb2VzIG5v dCBzZWVtIHRvIGhhdmUgZ29uZSB0aHJvdWdoIFdHIGFkb3B0aW9uLiBOZXh0IHRob3VnaCB0aGVz ZSB0d28gZHJhZnRzIHVzZSB0aGUgc2FtZSBtZWNoYW5pc21zLCB0aGUgZXhhY3QgcHJvYmxlbSB0 aGV5IHRyeSB0byBzb2x2ZSBhcmUgbm90IGV4YWN0bHkgcmVsYXRlZC48bzpwPjwvbzpwPjwvcD4K PC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8 L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmV2ZXJ0aGVsZXNzLCBJIHZhbHVlIHlv dXIgY29tbWVudHMsIHN1Z2dlc3Rpb25zIGFuZCB0aG91Z2h0cyBhIGxvdCwgYW5kIHRoYW5rIHlv dSB2ZXJ5IG11Y2ggZm9yIHByb3ZpZGluZyB0aGUgaW5zaWdodHMuIEkgd2lsbCBkZWZpbml0ZWx5 IHdvcmsgb24gdGhlbSBhbmQgYWRkcmVzcyB0aGVtIGluIHRoZSBuZXh0IGRyYWZ0LjxvOnA+PC9v OnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3Mgb25jZSBhZ2Fp biBhbmQgYmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LVB1c2hwYXNpczxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPgo8 ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk15IDJjLDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlNhc2hhPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T2ZmaWNlOiAmIzQzOzk3 Mi0zOTI2NjMwMjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNlbGw6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxvOnA+PC9vOnA+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkVtYWlsOiZuYnNwOyZuYnNwOwo8YSBocmVmPSJt YWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5B bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgo8YnI+ClRoaXMgZS1tYWlsIG1l c3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5m b3JtYXRpb24gd2hpY2ggaXMKPGJyPgpDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9w cmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcwo8YnI+CnRy YW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9y IGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbAo8YnI+CmFuZCBhbGwgY29waWVzIHRo ZXJlb2YuPGJyPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4Kc3ByaW5nIG1haWxp bmcgbGlzdDxicj4KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYu b3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4KPC9ibG9ja3F1b3RlPgo8L2Rpdj4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9k aXY+CjxiciBjbGVhcj0iYm90aCI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4KPEJSPgpUaGlzIGUt bWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRh aW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIDxCUj4KQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkg YmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg PEJSPgp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBw aG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgPEJSPgphbmQgYWxsIGNv cGllcyB0aGVyZW9mLjxCUj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPgo8L2JvZHk+CjwvaHRtbD4K Cg== --_000_AM4PR03MB1713F3F964B211B6A5B667869DA70AM4PR03MB1713eurp_-- From nobody Thu Jul 20 23:44:29 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958911250B8 for ; Thu, 20 Jul 2017 23:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=juniper.net 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 UbuCFqyNFqqk for ; Thu, 20 Jul 2017 23:44:25 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0133.outbound.protection.outlook.com [104.47.40.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1685B124D85 for ; Thu, 20 Jul 2017 23:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sRoGBDomOuViWbTlWeBlvONnwtLI5kYYnO3MsjWIA24=; b=lCPrPVJ4UXj/J85EyZehyVVq/0157mbWGLvvd/FO4fGg4pdlEKN7T+M/ZrDP3TLExIHJDFUeyRXkdwLASoRT41c2q/Enezae39/gpl/Ue62Ro7Ax0+8cyYwZqCzQuygDO7c6oL7oY6zzIESejX2u7hlZHfvmtQGGSKHZj6W8kbU= Received: from CY1PR05MB2714.namprd05.prod.outlook.com (10.167.18.8) by CY1PR05MB2204.namprd05.prod.outlook.com (10.166.192.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Fri, 21 Jul 2017 06:44:23 +0000 Received: from CY1PR05MB2714.namprd05.prod.outlook.com ([10.167.18.8]) by CY1PR05MB2714.namprd05.prod.outlook.com ([10.167.18.8]) with mapi id 15.01.1282.008; Fri, 21 Jul 2017 06:44:23 +0000 From: Shraddha Hegde To: "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS/NN8VkET5jeHE0aVgjgvlbOfdqJd3UHw Date: Fri, 21 Jul 2017 06:44:23 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> In-Reply-To: <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> 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=shraddha@juniper.net; x-originating-ip: [116.197.184.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR05MB2204; 7:DADTr+cMVtmzNF/coxSWDqeiN+enGcs6NJLn++Lh7qiinQaNvKgF3wyvLf8kF8zRE/sDKJh5Ku9wJkCruY13jEn4MOxCSGvztlifwdvh/ya6EggMQl0XRZMbyG+XQw8zKfljL9ssuIvSfPMOpP+1fcWgAZjcjjk0bAvD4QwDozQmw9w8guxlC31042fkMcx7TwN0f58X9/8ldpfFjW/FOQxc+w1iTDO5aBPHuNjvz3PgagaCCYvL2IfAgvnda3nvMEmZlm+TIvA2DTvn96ZH0aoivRqhjYLpWjD3roClLuURM3JpPlPeRge38UzihmqIsZ7j7jLN27sDkTFIX2AzIEivDQ4b0oCfAWPYz2tbionxkfd9KUyHvR/Q+zsnKBiIb6jpZ9WWdAyJkFe5h7gRTbUhW3UO1lnzbJtBzVsVWkg8M/iKDCkrKLfDy+42Lr/eE8L2Fv+h+/AdbYuzdnAXV9/FdHjMmOMDluO4Jq9TCf0iyg2lZsMvfkkbryDb42t7Bh1lcIUBeQ5C7qZEaoRkqxkS2h25B5uVXqxTWk+bpMtJvyzh9AaMsR6gUgY1sKcfIKa/0PW72UmNhr2mMue8w2akvx5YGFnYD4Gt3Aeo13/cFQcuf3ZzC4Af5ofM6RYRtHsQHoyQy3IDaF0W12lH3lMIfh/5jMa/Qvbz2aqsvujF9YeSDn/wrLfgKoaS5OtHevD057lCCfjxrrl7J5CzbuTCXeiVfy3d/rr5oi7nUrZm2NAw8AXgqPQQWBK97RWcoUdb1z8J64SDZz8yFTAy+FARX6njZaM/8ACUtEjwioY= x-ms-office365-filtering-correlation-id: ae46e922-af0e-4d2e-12a0-08d4d003ec65 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB2204; x-ms-traffictypediagnostic: CY1PR05MB2204: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB2204; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB2204; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39400400002)(39850400002)(39840400002)(39410400002)(189002)(13464003)(199003)(377454003)(8676002)(81166006)(101416001)(86362001)(14454004)(8936002)(7736002)(966005)(33656002)(478600001)(2351001)(53546010)(105586002)(230783001)(102836003)(1730700003)(7696004)(5640700003)(99286003)(55016002)(6306002)(6506006)(9686003)(66066001)(25786009)(6436002)(189998001)(106356001)(3846002)(81156014)(6116002)(38730400002)(53936002)(97736004)(6246003)(68736007)(2906002)(2900100001)(229853002)(77096006)(3660700001)(74316002)(5660300001)(6916009)(305945005)(2950100002)(3280700002)(2501003)(54356999)(110136004)(76176999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2204; H:CY1PR05MB2714.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 06:44:23.4127 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2204 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 06:44:28 -0000 SPRING WG, Conflict resolution is an important problem to solve and it is important to= =20 Standardize this draft.=20 I generally support the draft but have a few major comments which I hope th= e authors will work on. =20 1.Conflict resolution and forwarding Section 3.4 has the statement "Active Entries in the database may be used in forwarding." =09 This is a very loose statement which does not enforce implemen= tations to program the forwarding plane with the active database entries.=20 This does not ensure traffic drops are minimized. =09 The Forwarding plane programming aspects are completely missing in the doc= ument. A separate section is needed which describes the different aspects of prog= ramming the forwarding plane. =09 2. Protocol independent resolution and impact on network migrations In case of network migration from one protocol to other for ex= : OSPF-SR to ISIS-SR, it is useful to associate protocol preferences on a local node= to the SID advertisement and feed into the conflict resolution. This would make sure the conflicts = will always=20 have a winner which is an advertisement from protocol with preferred admin= -distance. =09 There is need for introducing another preference value specific to protoco= l preference and make it the top rule in the preference rule hierarchy. =09 This would also solve the issue of MT-ID numbers being different in differ= ent protocols as the SIDs would be compared within a protocol advertisement. 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF a= reas, It's possible that the conflicts are not visible in entire domain but are visible only on the= border router as the border routers have the database of both domains. The conflict resolution preference Rules should be enhanced to include = the Level information in the preference rule. A new parameter called sub-domain should be defined. =09 One could propose using existing SRMS preference values and assigning pre= fixes with preference values based on levels they are advertised in. This introduces more complex confi= guration requirements on the=20 network. The objective of this draft is to achieve consistent behaviours i= n case of misconfigurations and introducing more configurations as a solution does not help. =09 =09 Based on the Advertisement originated in ISIS Level or OSPF area below va= lues are defined. =09 Level 1 , non-zero OSPF area =3D1 Level 2, OSPF Area 0 =3D 2 Non IGPs set subdomain =3D 0 =09 Preference algorithm is changed as 1. Higher protocol preference wins 2. smaller sub-domain wins =09 3. Higher srms preference value wins=20 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins =20 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. sin= ce the all these rules are applied within protocol it's safe to compa= re topology IDs 10. Smaller starting SID wins Rgds Shraddha -----Original Message----- From: Martin Horneffer [mailto:maho@nic.dtag.de]=20 Sent: Friday, July 14, 2017 8:22 PM To: spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Strong support from me, too. From an operator's point of view this is really needed. Best regards, Martin Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > WG, > > We are half-way through the WG Last Call and I am very surprised to=20 > only see a single answer to it. > > I am not sure I'll move this forward with only silence as support. > > -m > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : >> Hello Working Group, >> >> This email starts a Working Group Last Call on >> draft-ietf-spring-conflict-resolution-04 [1] which is considered=20 >> mature and ready for a final working group review. >> >> =A4 Please read this document if you haven't read the most recent=20 >> version yet, and send your comments to the list, no later than *21st=20 >> of July*. >> Note that this is *not only* a call for comments on the document; it=20 >> is also a call for support (or not) to publish this document as a=20 >> Proposed Standard RFC. >> >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR that= =20 >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR=20 >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979,=20 >> 4879, >> 3669 and 5378 for more details). >> >> If you are listed as an Author or Contributor of >> draft-ietf-spring-conflict-resolution-04 please respond to this email=20 >> and indicate whether or not you are aware of any relevant IPR. >> >> Note that, as of today, no IPR has been disclosed against this=20 >> document or its earlier versions. >> >> Thank you, >> Martin >> >> [1] >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio >> n/ >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Mon Jul 24 13:27:16 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DBF131F16 for ; Mon, 24 Jul 2017 13:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 ZzXbuORgJX6z for ; Mon, 24 Jul 2017 13:27:11 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789D6131F0D for ; Mon, 24 Jul 2017 13:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50145; q=dns/txt; s=iport; t=1500928031; x=1502137631; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=pw3TH58xwYEl23k4OR4KNGUG2n6XFzsdGcxGPObyraI=; b=WiPjyIHkLh57kWBbWXih5hBOe0sbQpNbU9TfwepLijbkc7ANTjwkHceI 30X5oTYWxP2MNfwAGiW/97I3obopBbHUBzpTPAwIw1tBQc9UbTRVb2CuW cEftNq58IRM2o2qcpx9KgFx6w/f/zb2x1okNWTFDrHHl+p9d8e/d91p8J Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAABGV3ZZ/49dJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm8+LWSBFAeOBZFolgWCDwMhAQqETE8Cg2s/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEBARgDEEEEDAcEAgEIEQQBASEBBgcnCxQJCAIEARIIE4kwXAgQsV+LS?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiDTYFgAYIYgQyEPBIBQhCFPgWRJ44?= =?us-ascii?q?nAodMgwGJRoIVhVCDeIZjlWMBHzhZJgt1FUmFExyBZ3aHMoEjgQ4BAQE?= X-IronPort-AV: E=Sophos;i="5.40,408,1496102400"; d="scan'208,217";a="458824267" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2017 20:27:09 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v6OKR9qv026781 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Jul 2017 20:27:09 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Jul 2017 15:27:09 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Mon, 24 Jul 2017 15:27:09 -0500 From: "Les Ginsberg (ginsberg)" To: Shraddha Hegde , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nuokzsm0yt5P0y/+D1uKMVbQqJNamsAgAZpFICACngugIAENtLA Date: Mon, 24 Jul 2017 20:27:08 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.118.86] Content-Type: multipart/alternative; boundary="_000_a92a1ad9796e4c9d9e0732852a08d414XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 20:27:14 -0000 --_000_a92a1ad9796e4c9d9e0732852a08d414XCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network= . > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement= . [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR tha= t > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > >> > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --_000_a92a1ad9796e4c9d9e0732852a08d414XCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 

>

> 2.  Protocol independent resolution and= impact on network migrations

>       &nb= sp;      In case of network migration from one pro= tocol to other for ex: OSPF-

> SR to ISIS-SR,

>       &nb= sp;      it is useful to associate protocol prefer= ences on a local node to the SID

> advertisement

>        &n= bsp;    and feed into the conflict resolution. This would ma= ke sure the

> conflicts will always

>        &n= bsp;    have a winner which is an advertisement from protoco= l with

> preferred admin-distance.

>

>        &n= bsp;    There is need for introducing another preference val= ue specific to

> protocol preference

>        &n= bsp;    and make it the top rule in the preference rule hier= archy.

>

 =

[Les:] "admin= distance" is a locally defined preference which is not advertised. It= is therefore not possible to include it as a parameter in an algorithm whi= ch requires a consistent answer on all nodes throughout the network.

 

>        &n= bsp;    This would also solve the issue of MT-ID numbers bei= ng different in

> different protocols

>        &n= bsp;    as the SIDs would be compared within a protocol adve= rtisement.

 

[Les:] I do not understand what relationshi= p you see between "protocol preference" and "MT-ID".

MT-ID values are scoped by  the protoc= ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS = supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to= be used by different protocols when advertising routes for the same physical topology. This is why the draft's use of &quo= t;topology" is not as MTID but rather as a locally scoped identifier. = >From Section 3:

 

" Note: Top= ology is a locally scoped identifier assigned by each

   rou= ter.  Although it may have an association with Multitopology

   Ide= ntifiers (MTID) advertised by routing protocols it is NOT

   equ= ivalent to these identifiers.  MTIDs are scoped by a given routing

   pro= tocol.  MTID ranges are protocol specific and there may be<= /i>

   sta= ndardized protocol specific MTID assignments for topologies of a=

   spe= cific type (e.g., an AFI specific topology).  As mapping entries<= /o:p>

   can= be sourced from multiple protocols it is not possible to use a<= /i>

   net= work scoped identifier for a topology when storing mapping entries

   in = the local database."

 

Topology is then used to detect different s= copes for a mapping entry - which may result in a SID conflict if the same = SID is used in different topologies, but it cannot be used as a tiebreaker = since its value is local and any preference (e.g., higher value wins)  is not guaranteed to result in consistent = answers on all nodes in the network. Which is why we have Section 3.3 Rule = #8:

 

   &qu= ot;8.  If topology IDs are NOT identical both entries MUST be ignored&= quot;

 

 

>

> 3. In case of hierarchical IGP networks with= multiple ISIS Levels or OSPF areas,

> It's possible that the

>      conflicts are = not visible in entire domain but are visible only on the border<= /p>

> router as the border routers

>      have the datab= ase of both domains.

>     The conflict resolut= ion preference Rules should be enhanced to include the

> Level information in the preference rule.

>     A new parameter call= ed sub-domain should be defined.

>

>        &n= bsp;            = ;        One could propose using existin= g SRMS preference values

> and assigning prefixes with preference value= s

>        &n= bsp;    based on levels they are advertised in. This introdu= ces more complex

> configuration requirements on the=

>        &n= bsp;    network. The objective of this draft is to achieve c= onsistent

> behaviours in case of misconfigurations and<= o:p>

>        &n= bsp;    introducing more configurations as a solution does n= ot help.

>

>

>        &n= bsp;            = ;        Based on the Advertisement orig= inated in ISIS Level or OSPF

> area below values are defined.

>

>        &n= bsp;            = ;        Level 1 , non-zero OSPF area = =3D1

>        &n= bsp;            = ;        Level 2, OSPF Area 0 =3D 2=

>        &n= bsp;            = ;        Non IGPs set subdomain =3D 0

>

>        &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  Preference algorithm is changed as

>

>     1. Higher protocol p= reference wins

 

[Les:] I have e= xplained above why protocol preference cannot be used.

 

>    2. smaller sub-domain wins=

>     3. Higher srms prefe= rence value wins

>     4. Smaller range win= s

>     5.IPv6 entry wins ov= er IPv4 entry

>     6.Longer prefix leng= th wins

>     7.Smaller starting a= ddress (considered as an unsigned integer

>        va= lue) wins

>     8.Smaller algorithm = wins

>     9. Smaller topology = Id wins >>>>>>>>>>..Moved above SID compariso= n.

> since the all these rules are applied

>        &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;      within protocol it's safe to compare = topology IDs

[Les:] No ̵= 1; it isn’t – as explained above.

>     10. Smaller starting= SID wins

>

[Les:] SIDs are= assigned either by the node(s) originating the prefix reachability adverti= sement or by SRMS advertisements. The latter are level/area agnostic - and = even you are agreeing that we should not change that.

There is then n= o reason for the SID to be altered as it is advertised into different areas= .  Which leads us to the conclusion that SIDs are not level/area speci= fic.

 

If your concern= is that border routers who may have more entries in their SID database tha= n intra-area routers may come to a different conclusion as regards conflict= s - I agree with you - but I do not believe your proposal resolves the problem.

Consider the fo= llowing simple topology:

 

A1-----A2------= B2-----B1

 

All nodes run I= S-IS.

A1 is a Level-1= router in Area A. It advertises: 1.1.1.1/32 SID 100<= /b>

A2 is a Level-1= -2 router in Area A

 

B1 is a Level-1= router in Area B. It advertises: 2.2.2.2/32 SID 100<= /b>

B2 is a Level-1= -2 router in Area B

 

If Level 1 rout= es are leaked into Level 2 but NOT down into Level 1, we have the following= SID databases on the four routers:

 

A1<= /p>

1.1.1.1/32 100

A2<= /p>

1.1.1.1/32 100

2.2.2.2/32 100

B1<= /p>

2.2.2.2/32 100

B2<= /p>

1.1.1.1/32 100

2.2.2.2/32 100

 

 

Here are the activ= e entries on each node comparing the two algorithms

 

Node

Draft Algorithm<= /o:p>

Shraddha Algorithm

A1<= /p>

1.1.1.1/32 100

1.1.1.1/32 100

A2<= /p>

1.1.1.1/32 100

1.1.1.1/32 100

B1<= /p>

2.2.2.2/32 100

2.2.2.2/32 100

B2<= /p>

1.1.1.1/32 100

2.2.2.2/32 100

 

There is a trad= eoff here between being able to forward some inter-area traffic entering th= e network via the L2 sub-domain but impacting some intra-area traffic = vs being able to forward all intra-area traffic but no inter-area traffic.

Not clear which= strategy is “better” – but it is clear that neither stra= tegy eliminates all issues. Given that the same SID database will NOT exist= on all routers in multi-area deployments some risk exists and cannot be totally eliminated.

 

I do agree that= we should try to minimize the use of conflicting SIDs for inter-area traff= ic. What is lacking in the draft is a statement that conflicting SIDs shoul= d not be leaked out of an area. I will work on a statement in the draft to make that point clear.

Thanx for bring= ing this issue up.

 

  &nb= sp; Les

 

>

>

> Rgds

> Shraddha

>

> -----Original Message-----

> From: Martin Horneffer [mailt= o:maho@nic.dtag.de]

> Sent: Friday, July 14, 2017 8:22 PM

> To: spring@ietf.org=

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> Strong support from me, too.

>

>  From an operator's point of view this = is really needed.

>

> Best regards, Martin

>

>

> Am 10.07.17 um 14:58 schrieb Martin Vigoureu= x:

> >

> > WG,

> >

> > We are half-way through the WG Last Cal= l and I am very surprised to

> > only see a single answer to it.

> >

> > I am not sure I'll move this forward wi= th only silence as support.

> >

> > -m

> >

> > Le 29/06/2017 =E0 15:28, Martin Vigoure= ux a =E9crit :

> >> Hello Working Group,

> >>

> >> This email starts a Working Group L= ast Call on

> >> draft-ietf-spring-conflict-resoluti= on-04 [1] which is considered

> >> mature and ready for a final workin= g group review.

> >>

> >> =A4 Please read this document if yo= u haven't read the most recent

> >> version yet, and send your comments= to the list, no later than *21st

> >> of July*.

> >> Note that this is *not only* a call= for comments on the document; it

> >> is also a call for support (or not)= to publish this document as a

> >> Proposed Standard RFC.

> >>

> >> =A4 *Coincidentally*, we are also p= olling for knowledge of any IPR that

> >> applies to draft-ietf-spring-confli= ct-resolution, to ensure that IPR

> >> has been disclosed in compliance wi= th IETF IPR rules (see RFCs 3979,

> >> 4879,

> >> 3669 and 5378 for more details).

> >>

> >> If you are listed as an Author or C= ontributor of

> >> draft-ietf-spring-conflict-resoluti= on-04 please respond to this email

> >> and indicate whether or not you are= aware of any relevant IPR.

> >>

> >> Note that, as of today, no IPR has = been disclosed against this

> >> document or its earlier versions.

> >>

> >> Thank you,

> >> Martin

> >>

> >> [1]

> >> https://datatracker.i= etf.org/doc/draft-ietf-spring-conflict-resolutio

> >> n/

> >>

> >> ___________________________________= ____________

> >> spring mailing list

> >> = spring@ietf.org

> >> https://www.ietf.org/= mailman/listinfo/spring

> >>

> >

> > _______________________________________= ________

> > spring mailing list

> > spring@ietf.org

> > https://www.ietf.org/= mailman/listinfo/spring

> >

>

>

> ____________________________________________= ___

> spring mailing list

> spring@ietf.org

> https://www.ietf.org/= mailman/listinfo/spring

--_000_a92a1ad9796e4c9d9e0732852a08d414XCHALN001ciscocom_-- From nobody Tue Jul 25 15:42:09 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29914131FCA; Tue, 25 Jul 2017 15:42:07 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 jh9UC1p8a-zo; Tue, 25 Jul 2017 15:42:05 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35DF3131FC7; Tue, 25 Jul 2017 15:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13164; q=dns/txt; s=iport; t=1501022525; x=1502232125; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ULPvqOQWiUInnMv8uA1O42PHgu82Ps00DzcC2lVc8I4=; b=aD6ecVLxXgfCcohFnBtuTkGyw2H1OgC/5l0lP4kO5CXrOZ0UBhkJEMHA +oxuwjdOvEqBg3RCkHQXyjvUDFsBDd/55UzAbpUE2NPVo6EqBcRlMPA+d NdLnJmGjYhMdxILKZJVlp/eYx5DW2Sd5OYVCLHLHLgP1OMJTXCRm7zoR7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAABsyHdZ/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEUB44FkUeIUogqhSyCEoVHAhqDHj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGQYjVhACAQYCEi0DAgICHxEUAw4CBAENBYlLTAMVknmdZIImJ4cUDYQDAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYMog02BYCwLgm6CV4UvMIIxAQSXVIdHPAKPLYR?= =?us-ascii?q?wggyFUIpdiU6CRolUAR84gQp3FVsBhwZ2iCeBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,412,1496102400"; d="scan'208,217";a="461181833" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jul 2017 22:42:04 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6PMg4Za021097 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2017 22:42:04 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Jul 2017 17:42:03 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 25 Jul 2017 17:42:03 -0500 From: "Alvaro Retana (aretana)" To: "Carlos Pignataro (cpignata)" , Bruno Decraene CC: "Ruediger.Geib@telekom.de" , "spring-chairs@ietf.org" , "spring@ietf.org" , "draft-ietf-spring-oam-usecase@ietf.org" Thread-Topic: AD Review of draft-ietf-spring-oam-usecase-06 Thread-Index: AQHS5rM4ViD6dxlDU0uHlm6ThU+d86I2wwTwgAav1bCAAmZbAIAlmKGA Date: Tue, 25 Jul 2017 22:42:03 +0000 Message-ID: <5BDA0E8E-6068-40E1-A149-2F479072E43A@cisco.com> References: <28678_1498828104_59564D48_28678_291_3_53C29892C857584299CBF5D05346208A477E0608@OPEXCLILM21.corporate.adroot.infra.ftgroup> <0EA75BE5-D812-46E8-ABD6-C36E5190708D@cisco.com> In-Reply-To: <0EA75BE5-D812-46E8-ABD6-C36E5190708D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_5BDA0E8E606840E1A1492F479072E43Aciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] AD Review of draft-ietf-spring-oam-usecase-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 22:42:07 -0000 --_000_5BDA0E8E606840E1A1492F479072E43Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkkgbG9va2VkIC0wOCBhbmQgYWxtb3N0IGV2ZXJ5dGhpbmcgbG9va3MgZ29vZCB0byBt ZS4NCg0KVGhlIG9ubHkgZXhjZXB0aW9uIGlzIHRoZSByZXN1bHQgZnJvbSB0aGUgY29tbWVudCBi ZWxvdzoNCg0KDQogIDEuICBBbGwgdGhlIG5ldyByZWZlcmVuY2VzIHNob3VsZCBiZSBJbmZvcm1h dGl2ZSBhcyB0aGV5IHNlZW0gdG8ganVzdCBiZSBleGFtcGxlczog4oCcUGFja2V0cyBmcm9tIGEg dmFyaWV0eSBvZiBwcm90b2NvbHMgY2FuIGJlIHVzZWQgdG8gY2hlY2sgY29udGludWl0eS4gIFRo ZXNlIGluY2x1ZGXigKbigJ0uDQogIDIuICBbbml0XSBBIHJlZmVyZW5jZSB0byB0aGUgYmFzZSBz aG91bGQgYmUgZW5vdWdoOiBmb3IgZXhhbXBsZSwgcmZjNzg4MCBzaG91bGQgYmUgZW5vdWdoIGZv ciBTLUJGRDsgbm8gbmVlZCB0byBtZW50aW9uIGFsbC4NCg0KSeKAmWxsIGxlYXZlIHRoaXMgZG9j dW1lbnQgd2FpdGluZyBmb3IgdGhlIEFyY2hpdGVjdHVyZSBzbyB3ZSBjYW4gcHJvZ3Jlc3MgdGhl bSB0b2dldGhlci4gIFBsZWFzZSB1cGRhdGUgdGhlIHJlZmVyZW5jZXMgd2hlbiB5b3UgZ2V0IGEg Y2hhbmNlLCBubyBodXJyeS4NCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQoNCk9uIDcvMS8xNywgNDoz NCBQTSwgIkNhcmxvcyBQaWduYXRhcm8gb24gYmVoYWxmIG9mIENhcmxvcyBQaWduYXRhcm8gKGNw aWduYXRhKSIgPGNwaWduYXRhQGdtYWlsLmNvbTxtYWlsdG86Y3BpZ25hdGFAZ21haWwuY29tPiBv biBiZWhhbGYgb2YgY3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+ PiB3cm90ZToNCg0KIyMjIyMjIw0KDQpQMi4g4oCcQkZEIG9yIExTUCBQaW5nIGZvcm1hdOKAneKA pnJlZmVyZW5jZXM/DQoNCltFRF0gTmV4dCBkcmFmdCB2ZXJzaW9uLg0KDQoNCltFRF0gR29vZCBw b2ludCBhcyB3ZWxsLiBJbiBhZGRpdGlvbiB0byBhZGRpbmcgdGhlIHJlZmVyZW5jZXMsIHdlIGFs c28gYWRkIElDTVAgYW5kIFMtQkZEIGZvciBjb21wbGV0ZW5lc3MuDQoNCg0KDQo= --_000_5BDA0E8E606840E1A1492F479072E43Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1B6D28C8DDDFA545AF401F7A2E29285F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206 MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdl aWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExMTM1MjQ4NTg7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjgyMzkzOTI3OCAtMTA3MTI0 ODQ5NCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6 IlwoJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5JIGxvb2tlZCAtMDggYW5kIGFsbW9zdCBldmVyeXRoaW5nIGxvb2tzIGdvb2QgdG8gbWUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlRoZSBvbmx5IGV4Y2VwdGlvbiBpcyB0aGUgcmVzdWx0IGZyb20gdGhl IGNvbW1lbnQgYmVsb3c6Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbGwgdGhlIG5ldyByZWZlcmVuY2VzIHNob3Vs ZCBiZSBJbmZvcm1hdGl2ZSBhcyB0aGV5IHNlZW0gdG8ganVzdCBiZSBleGFtcGxlczog4oCcUGFj a2V0cyBmcm9tIGEgdmFyaWV0eSBvZiBwcm90b2NvbHMNCiBjYW4gYmUgdXNlZCB0byBjaGVjayBj b250aW51aXR5LiZuYnNwOyBUaGVzZSBpbmNsdWRl4oCm4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltuaXRdIEEgcmVmZXJlbmNl IHRvIHRoZSBiYXNlIHNob3VsZCBiZSBlbm91Z2g6IGZvciBleGFtcGxlLCByZmM3ODgwIHNob3Vs ZCBiZSBlbm91Z2ggZm9yIFMtQkZEOyBubyBuZWVkIHRvIG1lbnRpb24NCiBhbGwuPG86cD48L286 cD48L3NwYW4+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPknigJlsbCBsZWF2ZSB0aGlzIGRvY3VtZW50IHdhaXRpbmcgZm9yIHRoZSBB cmNoaXRlY3R1cmUgc28gd2UgY2FuIHByb2dyZXNzIHRoZW0gdG9nZXRoZXIuJm5ic3A7IFBsZWFz ZSB1cGRhdGUgdGhlIHJlZmVyZW5jZXMgd2hlbiB5b3UgZ2V0IGEgY2hhbmNlLCBubyBodXJyeS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbHZhcm8uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIDcvMS8xNywgNDozNCBQTSwgJnF1b3Q7Q2FybG9zIFBpZ25hdGFybyBvbiBiZWhhbGYgb2Yg Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y3Bp Z25hdGFAZ21haWwuY29tIj5jcGlnbmF0YUBnbWFpbC5jb208L2E+IG9uIGJlaGFsZiBvZg0KPGEg aHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSI+Y3BpZ25hdGFAY2lzY28uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IyMjIyMjIzwvc3Bhbj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UDIuIOKAnEJGRCBvciBMU1AgUGluZyBm b3JtYXTigJ3igKZyZWZlcmVuY2VzPzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+W0VEXSBOZXh0IGRyYWZ0IHZlcnNpb24uPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7 LHNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPltF RF0gR29vZCBwb2ludCBhcyB3ZWxsLiBJbiBhZGRpdGlvbiB0byBhZGRpbmcgdGhlIHJlZmVyZW5j ZXMsIHdlIGFsc28gYWRkIElDTVAgYW5kIFMtQkZEIGZvciBjb21wbGV0ZW5lc3MuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_5BDA0E8E606840E1A1492F479072E43Aciscocom_-- From nobody Tue Jul 25 15:56:42 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F0D132004; Tue, 25 Jul 2017 15:56:41 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 6Lz2pcayrQu0; Tue, 25 Jul 2017 15:56:39 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6736D132001; Tue, 25 Jul 2017 15:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10830; q=dns/txt; s=iport; t=1501023399; x=1502232999; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Isrz1eS4inZI0Tbbevyl1/4iARNedr7MmX/VFmaV12Q=; b=mc48U5VH/VmjXW6QtFTOnutH7OWug0ZynghbFJK8Tm9UWWALFwnOmefy LUjJd8FJCVLCeqIdiqwq3OuO3ARPj70hZ6VHGVwKX3H4gpz6QOS6Mnin0 hfUckDy+tcdDlPGFPJm8KhvV5Js1/tEXtdSVz7KPDai+NvXCT8F4r9ap1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAABVzHdZ/5NdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9rgWUTjgyaGYgqhSyCEoVHAoM4PxgBAgEBAQEBAQFrKIUZBnkQAgE?= =?us-ascii?q?IEi0HIREUAw4CBA4FiUtMAxWyb4c6DYQDAQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?YMog02BYCyCeYJXhV+CMQWXVIdHPAKPLYRwggyFUIpdiU6CRolUAR84gQp3FVs?= =?us-ascii?q?BhwZ2iTUBAQE?= X-IronPort-AV: E=Sophos;i="5.40,412,1496102400"; d="scan'208,217";a="459177015" 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; 25 Jul 2017 22:56:22 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6PMuLUj008553 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2017 22:56:22 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Jul 2017 18:56:21 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 25 Jul 2017 18:56:21 -0400 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" CC: Bruno Decraene , "Ruediger.Geib@telekom.de" , "spring-chairs@ietf.org" , "spring@ietf.org" , "draft-ietf-spring-oam-usecase@ietf.org" Thread-Topic: AD Review of draft-ietf-spring-oam-usecase-06 Thread-Index: AQHS5rM4ViD6dxlDU0uHlm6ThU+d86I2wwTwgAav1bCAAlWYAIAl266A///A8Y4= Date: Tue, 25 Jul 2017 22:56:21 +0000 Message-ID: <8C6937FD-3D27-43AE-933A-AD47A587055B@cisco.com> References: <28678_1498828104_59564D48_28678_291_3_53C29892C857584299CBF5D05346208A477E0608@OPEXCLILM21.corporate.adroot.infra.ftgroup> <0EA75BE5-D812-46E8-ABD6-C36E5190708D@cisco.com>, <5BDA0E8E-6068-40E1-A149-2F479072E43A@cisco.com> In-Reply-To: <5BDA0E8E-6068-40E1-A149-2F479072E43A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_8C6937FD3D2743AE933AAD47A587055Bciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] AD Review of draft-ietf-spring-oam-usecase-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 22:56:41 -0000 --_000_8C6937FD3D2743AE933AAD47A587055Bciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll take care of it. Thanks! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Jul 25, 2017, at 18:42, Alvaro Retana (aretana) > wrote: Hi! I looked -08 and almost everything looks good to me. The only exception is the result from the comment below: 1. All the new references should be Informative as they seem to just be = examples: "Packets from a variety of protocols can be used to check continu= ity. These include...". 2. [nit] A reference to the base should be enough: for example, rfc7880 = should be enough for S-BFD; no need to mention all. I'll leave this document waiting for the Architecture so we can progress th= em together. Please update the references when you get a chance, no hurry. Thanks! Alvaro. On 7/1/17, 4:34 PM, "Carlos Pignataro on behalf of Carlos Pignataro (cpigna= ta)" on behalf of cpignata@c= isco.com> wrote: ####### P2. "BFD or LSP Ping format"...references? [ED] Next draft version. [ED] Good point as well. In addition to adding the references, we also add = ICMP and S-BFD for completeness. --_000_8C6937FD3D2743AE933AAD47A587055Bciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'll take care of it. Thanks!

Excuze typofraphicak errows

On Jul 25, 2017, at 18:42, Alvaro Retana (aretana) <aretana@cisco.com> wrote:

Hi!

 

I looked -08 and almost everything looks good to me= .

 

The only exception is the result from the comment b= elow: 

 

  1. All the new references should be Informative as they seem to just be= examples: “Packets from a variety of protocols can be used to check continuity.  These include…”.
  2. [nit] A reference to the base should be enough: for = example, rfc7880 should be enough for S-BFD; no need to mention all.

 

I’ll leave this document waiting for the Arch= itecture so we can progress them together.  Please update the referenc= es when you get a chance, no hurry.

 

Thanks!

 

Alvaro.

 

On 7/1/17, 4:34 PM, "Carlos Pignataro on behalf= of Carlos Pignataro (cpignata)" <cpignata@gmail.com on behalf of cpignata@cisco.com> wrote:

 

#######

 =

P2. “BFD or LSP Ping format”= ;…references?

 =

[ED] Next draft version.=

 

 

[ED] Good point as well. In additio= n to adding the references, we also add ICMP and S-BFD for completeness.

 



--_000_8C6937FD3D2743AE933AAD47A587055Bciscocom_-- From nobody Tue Jul 25 22:37:07 2017 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F56124D68; Tue, 25 Jul 2017 22:36:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150104741811.26382.8374189671050459586@ietfa.amsl.com> Date: Tue, 25 Jul 2017 22:36:58 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-oam-usecase-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 05:36:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : A Scalable and Topology-Aware MPLS Dataplane Monitoring System Authors : Ruediger Geib Clarence Filsfils Carlos Pignataro Nagendra Kumar Filename : draft-ietf-spring-oam-usecase-09.txt Pages : 18 Date : 2017-07-25 Abstract: This document describes features of a path monitoring system and related use cases. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS Ping and LSP Trace, in a very complementary way. MPLS topology awareness reduces management and control plane involvement of OAM measurements while enabling new OAM features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-oam-usecase-09 https://datatracker.ietf.org/doc/html/draft-ietf-spring-oam-usecase-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-oam-usecase-09 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 Jul 25 22:40:58 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA1B1243F3; Tue, 25 Jul 2017 22:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 klNLCJsQoqfP; Tue, 25 Jul 2017 22:40:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D321200FC; Tue, 25 Jul 2017 22:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17848; q=dns/txt; s=iport; t=1501047656; x=1502257256; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=143LUbP8xknuD96FY+U9PdQMZOdL/v0p/UiKJGIID8c=; b=gBfScixN8YQ6coG9sdDHGwZYbnAlHvLoCbktd3At4xK0hxvnD/s85bmu 4uyWcJCUmA4G2XpYTqsGO8m+mSUS7lMzXE2F2hqaykOU7XJWHPD2QKCfi LKrGHVULEtIHA4kpCYE+nxMY6vqqnkwDYQqb710M1+02UUMhUq30hJ6br 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AABAKnhZ/5hdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9rgVEUEweOBZobiCuFLoIShUcCGoMfPxgBAgEBAQEBAQFrKIUZBiN?= =?us-ascii?q?WEAIBBgISLQMCAgIfERQDDgIEDgWJS0wDFZNBnWSCJoc8DYQDAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYMog02BYAErgnmCV4UvMIIxBZdWh0c8Ao8uhHCCDIVQil2?= =?us-ascii?q?JT4JGiVYBHziBCncVWwGHBnaIJ4EOAQEB?= X-IronPort-AV: E=Sophos;i="5.40,413,1496102400"; d="scan'208,217";a="272472320" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2017 05:40:55 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6Q5es58005485 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Jul 2017 05:40:55 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Jul 2017 01:40:54 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 26 Jul 2017 01:40:54 -0400 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" CC: Bruno Decraene , "Ruediger.Geib@telekom.de" , "spring-chairs@ietf.org" , "spring@ietf.org" , "draft-ietf-spring-oam-usecase@ietf.org" Thread-Topic: AD Review of draft-ietf-spring-oam-usecase-06 Thread-Index: AQHS5rM4ViD6dxlDU0uHlm6ThU+d86I2wwTwgAav1bCAAlWYAIAl266AgAB1CQA= Date: Wed, 26 Jul 2017 05:40:54 +0000 Message-ID: <18A24B00-0BE8-4D9B-B10E-9E9DEFECBA94@cisco.com> References: <28678_1498828104_59564D48_28678_291_3_53C29892C857584299CBF5D05346208A477E0608@OPEXCLILM21.corporate.adroot.infra.ftgroup> <0EA75BE5-D812-46E8-ABD6-C36E5190708D@cisco.com> <5BDA0E8E-6068-40E1-A149-2F479072E43A@cisco.com> In-Reply-To: <5BDA0E8E-6068-40E1-A149-2F479072E43A@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.24.7.20] Content-Type: multipart/alternative; boundary="_000_18A24B000BE84D9BB10E9E9DEFECBA94ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] AD Review of draft-ietf-spring-oam-usecase-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 05:40:58 -0000 --_000_18A24B000BE84D9BB10E9E9DEFECBA94ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEFsdmFybywNCg0KV2UganVzdCBwb3N0ZWQgcmV2IC0wOSwgYWRkcmVzc2luZyB0aGVzZS4N Cg0KUGxlYXNlIG5vdGUgdGhhdCByZWdhcmRpbmcgIjIuIFtuaXRd4oCdLCB3ZSBsZWZ0IHRoZSBh ZGRpdGlvbmFsIHJlZmVyZW5jZXMuIEZvciBleGFtcGxlLCByZmM3ODgwIGluIGl0c2VsZiBpcyBu b3Qgc3VmZmljaWVudCwgYW5kIHJmYzc4ODEgZGVmaW5lcyBTLUJGRCBmb3IgTVBMUy4gcmZjNzg4 MiBzcGVjaWZpY2FsbHkgdGFsa3MgYWJvdXQgdGhpcyB1c2UgY2FzZSBpbiBTZWN0aW9uIDMuNCBh bmQgdGhlcmVmb3JlIHNlZW1zIHVzZWZ1bCBpbmZvcm1hdGlvbiB0byBjaXRlLiBGb3IgY29tcGxl dGVuZXNzLCBhbmQgc2luY2UgeW91IG1hcmtlZCB0aGlzIGFzIGEgbml0LCB3ZSBsZWZ0IHRob3Nl IGluLCBidXQgbW92ZWQgdGhlbSB0byBJbmZvcm1hdGl2ZS4NCg0KVGhhbmtzIQ0KDQrigJQgQ2Fy bG9zLg0KDQpPbiBKdWwgMjUsIDIwMTcsIGF0IDM6NDIgUE0sIEFsdmFybyBSZXRhbmEgKGFyZXRh bmEpIDxhcmV0YW5hQGNpc2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+PiB3cm90ZToN Cg0KSGkhDQoNCkkgbG9va2VkIC0wOCBhbmQgYWxtb3N0IGV2ZXJ5dGhpbmcgbG9va3MgZ29vZCB0 byBtZS4NCg0KVGhlIG9ubHkgZXhjZXB0aW9uIGlzIHRoZSByZXN1bHQgZnJvbSB0aGUgY29tbWVu dCBiZWxvdzoNCg0KDQogIDEuICBBbGwgdGhlIG5ldyByZWZlcmVuY2VzIHNob3VsZCBiZSBJbmZv cm1hdGl2ZSBhcyB0aGV5IHNlZW0gdG8ganVzdCBiZSBleGFtcGxlczog4oCcUGFja2V0cyBmcm9t IGEgdmFyaWV0eSBvZiBwcm90b2NvbHMgY2FuIGJlIHVzZWQgdG8gY2hlY2sgY29udGludWl0eS4g IFRoZXNlIGluY2x1ZGXigKbigJ0uDQogIDIuICBbbml0XSBBIHJlZmVyZW5jZSB0byB0aGUgYmFz ZSBzaG91bGQgYmUgZW5vdWdoOiBmb3IgZXhhbXBsZSwgcmZjNzg4MCBzaG91bGQgYmUgZW5vdWdo IGZvciBTLUJGRDsgbm8gbmVlZCB0byBtZW50aW9uIGFsbC4NCg0KDQpJ4oCZbGwgbGVhdmUgdGhp cyBkb2N1bWVudCB3YWl0aW5nIGZvciB0aGUgQXJjaGl0ZWN0dXJlIHNvIHdlIGNhbiBwcm9ncmVz cyB0aGVtIHRvZ2V0aGVyLiAgUGxlYXNlIHVwZGF0ZSB0aGUgcmVmZXJlbmNlcyB3aGVuIHlvdSBn ZXQgYSBjaGFuY2UsIG5vIGh1cnJ5Lg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0KT24gNy8xLzE3 LCA0OjM0IFBNLCAiQ2FybG9zIFBpZ25hdGFybyBvbiBiZWhhbGYgb2YgQ2FybG9zIFBpZ25hdGFy byAoY3BpZ25hdGEpIiA8Y3BpZ25hdGFAZ21haWwuY29tPG1haWx0bzpjcGlnbmF0YUBnbWFpbC5j b20+IG9uIGJlaGFsZiBvZiBjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2Nv LmNvbT4+IHdyb3RlOg0KDQojIyMjIyMjDQoNClAyLiDigJxCRkQgb3IgTFNQIFBpbmcgZm9ybWF0 4oCd4oCmcmVmZXJlbmNlcz8NCg0KW0VEXSBOZXh0IGRyYWZ0IHZlcnNpb24uDQoNCg0KW0VEXSBH b29kIHBvaW50IGFzIHdlbGwuIEluIGFkZGl0aW9uIHRvIGFkZGluZyB0aGUgcmVmZXJlbmNlcywg d2UgYWxzbyBhZGQgSUNNUCBhbmQgUy1CRkQgZm9yIGNvbXBsZXRlbmVzcy4NCg0KDQoNCg0K4oCU DQpDYXJsb3MgUGlnbmF0YXJvLCBjYXJsb3NAY2lzY28uY29tPG1haWx0bzpjYXJsb3NAY2lzY28u Y29tPg0KDQrigJxTb21ldGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkg dW5kZXJzdGFuZCwgdG8gbWFrZSBteXNlbGYgc291bmQgbW9yZSBwaG90b3N5bnRoZXNpcy4iDQoN Cg== --_000_18A24B000BE84D9BB10E9E9DEFECBA94ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksIEFsdmFybywNCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldlIGp1c3QgcG9zdGVk IHJldiAtMDksIGFkZHJlc3NpbmcgdGhlc2UuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QbGVhc2Ugbm90ZSB0aGF0IHJlZ2FyZGluZyAm cXVvdDsyLiBbbml0XeKAnSwgd2UgbGVmdCB0aGUgYWRkaXRpb25hbCByZWZlcmVuY2VzLiBGb3Ig ZXhhbXBsZSwgcmZjNzg4MCBpbiBpdHNlbGYgaXMgbm90IHN1ZmZpY2llbnQsIGFuZCByZmM3ODgx IGRlZmluZXMgUy1CRkQgZm9yIE1QTFMuIHJmYzc4ODIgc3BlY2lmaWNhbGx5IHRhbGtzIGFib3V0 IHRoaXMgdXNlIGNhc2UgaW4gU2VjdGlvbiAzLjQgYW5kIHRoZXJlZm9yZSBzZWVtcyB1c2VmdWwN CiBpbmZvcm1hdGlvbiB0byBjaXRlLiBGb3IgY29tcGxldGVuZXNzLCBhbmQgc2luY2UgeW91IG1h cmtlZCB0aGlzIGFzIGEgbml0LCB3ZSBsZWZ0IHRob3NlIGluLCBidXQgbW92ZWQgdGhlbSB0byBJ bmZvcm1hdGl2ZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPlRoYW5rcyE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+T24gSnVsIDI1LCAyMDE3LCBhdCAzOjQyIFBNLCBBbHZhcm8gUmV0YW5hIChh cmV0YW5hKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyZXRhbmFAY2lzY28uY29tIiBjbGFzcz0iIj5h cmV0YW5hQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1p bnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+SGkhPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48bzpw IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkkgbG9va2VkIC0w OCBhbmQgYWxtb3N0IGV2ZXJ5dGhpbmcgbG9va3MgZ29vZCB0byBtZS48bzpwIGNsYXNzPSIiPjwv bzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+VGhlIG9ubHkgZXhjZXB0aW9uIGlzIHRoZSByZXN1bHQgZnJv bSB0aGUgY29tbWVudCBiZWxvdzombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPG9s IHN0YXJ0PSIxIiB0eXBlPSIxIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMGluOyBtYXJnaW4tdG9w OiAwaW47IiBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkFsbCB0aGUgbmV3IHJl ZmVyZW5jZXMgc2hvdWxkIGJlIEluZm9ybWF0aXZlIGFzIHRoZXkgc2VlbSB0byBqdXN0IGJlIGV4 YW1wbGVzOiDigJxQYWNrZXRzIGZyb20gYSB2YXJpZXR5IG9mIHByb3RvY29scyBjYW4gYmUgdXNl ZCB0byBjaGVjayBjb250aW51aXR5LiZuYnNwOyBUaGVzZSBpbmNsdWRl4oCm4oCdLjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+W25pdF0gQSBy ZWZlcmVuY2UgdG8gdGhlIGJhc2Ugc2hvdWxkIGJlIGVub3VnaDogZm9yIGV4YW1wbGUsIHJmYzc4 ODAgc2hvdWxkIGJlIGVub3VnaCBmb3IgUy1CRkQ7IG5vIG5lZWQgdG8gbWVudGlvbiBhbGwuPG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9saT48L29sPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5J4oCZbGwgbGVhdmUgdGhpcyBk b2N1bWVudCB3YWl0aW5nIGZvciB0aGUgQXJjaGl0ZWN0dXJlIHNvIHdlIGNhbiBwcm9ncmVzcyB0 aGVtIHRvZ2V0aGVyLiZuYnNwOyBQbGVhc2UgdXBkYXRlIHRoZSByZWZlcmVuY2VzIHdoZW4geW91 IGdldCBhIGNoYW5jZSwgbm8gaHVycnkuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPlRoYW5rcyE8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxv OnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+QWx2YXJvLjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpPbiA3LzEv MTcsIDQ6MzQgUE0sICZxdW90O0NhcmxvcyBQaWduYXRhcm8gb24gYmVoYWxmIG9mIENhcmxvcyBQ aWduYXRhcm8gKGNwaWduYXRhKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGdt YWlsLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l OyIgY2xhc3M9IiI+Y3BpZ25hdGFAZ21haWwuY29tPC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5vbiBiZWhhbGYgb2Y8c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNp c2NvLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l OyIgY2xhc3M9IiI+Y3BpZ25hdGFAY2lzY28uY29tPC9hPiZndDsNCiB3cm90ZTo8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFy Z2luLWJvdHRvbTogNXB0OyIgY2xhc3M9IiIgdHlwZT0iY2l0ZSI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUg c29saWQ7IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVwdDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7 IHBhZGRpbmc6IDBpbiAwaW4gMGluIDRwdDsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+IyMjIyMjIzwv c3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+UDIuIOKAnEJGRCBvciBMU1AgUGluZyBmb3JtYXTigJ3igKZyZWZlcmVuY2Vz Pzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+W0VEXSBOZXh0IGRyYWZ0IHZlcnNpb24uPC9zcGFuPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0 LXN0YW5kYXJkLCBzZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdl YmtpdC1zdGFuZGFyZCwgc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1p bHk6IC13ZWJraXQtc3RhbmRhcmQsIHNlcmlmOyIgY2xhc3M9IiI+W0VEXSBHb29kIHBvaW50IGFz IHdlbGwuIEluIGFkZGl0aW9uIHRvIGFkZGluZyB0aGUgcmVmZXJlbmNlcywgd2UgYWxzbyBhZGQg SUNNUCBhbmQgUy1CRkQgZm9yIGNvbXBsZXRlbmVzcy48L3NwYW4+PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0K4oCUPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4N CkNhcmxvcyBQaWduYXRhcm8sJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmNhcmxvc0BjaXNjby5jb20i IGNsYXNzPSIiPmNhcmxvc0BjaXNjby5jb208L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGkgY2xhc3M9IiI+4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3b3JkcyB0aGF0IEkgZG8gbm90 IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5kIG1vcmUmbmJzcDtwaG90b3N5 bnRoZXNpcy4mcXVvdDs8L2k+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_18A24B000BE84D9BB10E9E9DEFECBA94ciscocom_-- From nobody Thu Jul 27 20:30:59 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B0132203 for ; Thu, 27 Jul 2017 20:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 Jt8aMePgEBJz for ; Thu, 27 Jul 2017 20:30:54 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0094.outbound.protection.outlook.com [104.47.36.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1E51321FC for ; Thu, 27 Jul 2017 20:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eB05qXK+yl9seQnxPLVqZv1G7qu5f4k0QW+ljwVCzyU=; b=c8EO4MAPOZ6AYJRE+Nt9H6BFtn2mjpRE+yX9QGZRF/BD2hUKCqG++rdUucldMBXphwvIHNoIqOSaWJ5CsG9sMlHnQeHelnBhOe44zfM0mJ7IPAvY732slg6r/bcwcQwYhCZ0cxthNeR3jku6p8vKBCPcN9P+mAgkKuzB95gznKQ= Received: from BN3PR05MB2706.namprd05.prod.outlook.com (10.167.2.135) by BN3PR05MB2641.namprd05.prod.outlook.com (10.166.72.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Fri, 28 Jul 2017 03:30:52 +0000 Received: from BN3PR05MB2706.namprd05.prod.outlook.com ([10.167.2.135]) by BN3PR05MB2706.namprd05.prod.outlook.com ([10.167.2.135]) with mapi id 15.01.1304.016; Fri, 28 Jul 2017 03:30:52 +0000 From: Shraddha Hegde To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS/NN8VkET5jeHE0aVgjgvlbOfdqJd3UHwgAWfiQCABAJAYA== Date: Fri, 28 Jul 2017 03:30:52 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> In-Reply-To: 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=shraddha@juniper.net; x-originating-ip: [116.197.184.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR05MB2641; 7:mYr18C1Dg1sa5jJlkaatG7j+3jyhnDnGVIb/GxDH/s+vBR+Pxngo+vk0yan1MLlt0n32ksDfdMeXl+ZyweYeH+l5d3K4Ys7tPU46fNuG08HbDjFKNFeJSGV9aQtldSroB/sb4HOpNoVwfCBTge29H3aqxmbEkQ0iCPCYoGBw83fin8F1S5QVvu0v/nZ3eMV5AmPJGTK0fCuXgQfndRO9UxuTX4A//unasidJCQVewv9tO+iOV/k1xYzYH8xwVUd4j98ZYsnahDecMLF0nLejC84pgKcfROtpd6apjIKkNIIu4gHPxuYDOYwbfHzSggsE36cRqPY9tAZjoSlgRV8Ra7+2h3hKYx0swQQlDBRI9X7gMwcr81/DM8SH20R7Xen4UxzvgWE9aCuxvc5wxzJO2qDrkk/r7vrvmCDYXr2j6851DyU6F8416d/JJH4balAWaZf/MdVKZsEAgjEDFpOa5BsJ0s7mtDP5fDtbJQnUoVto2W0rhxCKt9+PDbqj8B29GJ4P09TwTcteUw5TPZw4xxeFBxoFmOkQV5NPt5J/3P7rPRfsOQ5ddj1clmT3CNc3ZugUeSs1q0Yt2ofgiiJzQinRLsq0WuEOjbgtRb1feQe15mrbfealmOfwOk/aJOUE/pkrCiwtAXecktUo7IGkqjcm9P6GaKLOQ+kCN0eJZx17NW2yBQ4wWB5ELwObPk6MBY2gek89YsA9MeKtSJ8OlCt+U04SyODEtpbpdxgVgn/oKFEP8EkP+egG43FJHET6L7wbnlI1MmjuUVotQkNMpdz82Rmjm550fT8scVs0gtQ= x-ms-office365-filtering-correlation-id: a6772ac6-0e93-49cc-c64e-08d4d5690c80 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR05MB2641; x-ms-traffictypediagnostic: BN3PR05MB2641: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(138986009662008)(95692535739014)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR05MB2641; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR05MB2641; x-forefront-prvs: 03827AF76E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39850400002)(39410400002)(39860400002)(39450400003)(39400400002)(199003)(189002)(377454003)(13464003)(51914003)(561944003)(101416001)(53936002)(6506006)(81166006)(33656002)(81156014)(189998001)(105586002)(8676002)(106356001)(6436002)(53946003)(966005)(25786009)(93886004)(66066001)(230783001)(14454004)(2501003)(6116002)(54896002)(99286003)(68736007)(6306002)(55016002)(236005)(9686003)(38730400002)(6246003)(3280700002)(53546010)(97736004)(606006)(8936002)(3660700001)(229853002)(478600001)(76176999)(2906002)(74316002)(77096006)(54356999)(2900100001)(50986999)(790700001)(102836003)(3846002)(19609705001)(86362001)(2950100002)(7696004)(5660300001)(7736002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2641; H:BN3PR05MB2706.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR05MB270660621544E65EA06B04F6D5BF0BN3PR05MB2706namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2017 03:30:52.3662 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2641 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 03:30:58 -0000 --_000_BN3PR05MB270660621544E65EA06B04F6D5BF0BN3PR05MB2706namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network= . Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde ; spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network= . In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement= . [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR tha= t > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > >> > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --_000_BN3PR05MB270660621544E65EA06B04F6D5BF0BN3PR05MB2706namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.<= /o:p>

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsber= g@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shraddha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 

“In cases where the
   information advertised by a given protocol instance is ei=
ther
   internally inconsistent or conflicts with advertisements =
from another
   protocol instance a means of achieving consistent forward=
ing behavior
   in the network is required.”
 
If the draft is not going to address the forwardi=
ng plane detail w.r.t conflicting entries it is definitely not meeting the<=
o:p>
The objective described above.<=
/i>
 
Take an example of a conflict
(192, 192.0.2.1/32, 200, 1, 0, 0)
   (192, 192.0.2.222/32, 200, 1, 0, 0)<=
o:p>
   SID 200 has been assigned to 192.0.2=
.1/32 by the
   first advertisement.
   The second advertisement assigns SID=
 200 to 192.0.2.222/32.
 
In this case after applying the preference rules<=
o:p>
(192, 192.0.2.1/32, 200, 1, 0, 0)
 Becomes active entry.<=
/pre>

 


As per the text in the draft,” it may be us=
ed in forwarding” so some implementations

May choose to program forwarding plane and some m=
ay not which does not give a consistent forwarding behavior


Across implementations.=



 


 


 


 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 =



[Les:] "admin=
 distance" is a locally defined preference which is not advertised. It=
 is therefore not possible to include it as a parameter in an algorithm whi=
ch requires a consistent answer on all nodes throughout
 the network.


 


<Shraddha>  In migration cases, topolo=
gies across two different protocols are not congruent causing inconsistent =
behavior.


        &=
nbsp;           &nbs=
p;  Using admin-distance as an input parameter keeps the conflict reso=
lution with-in the protocol and guarantees


        &=
nbsp;           &nbs=
p; Consistent behavior across all the nodes corresponding to that protocol.=



 


        &=
nbsp;           &nbs=
p;The drafts tries to address this scenario partially between IGP and BGP b=
y suggesting preference values. But that does not solve the


Problem between two different IGPs. 


 


 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each

   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing


   pro=
tocol.  MTID ranges are protocol specific and there may be<=
/i>


   sta=
ndardized protocol specific MTID assignments for topologies of a=



   spe=
cific type (e.g., an AFI specific topology).  As mapping entries<=
/o:p>


   can=
 be sourced from multiple protocols it is not possible to use a<=
/i>


   net=
work scoped identifier for a topology when storing mapping entries


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.

> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have e=
xplained above why protocol preference cannot be used.


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No ̵=
1; it isn’t – as explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are=
 assigned either by the node(s) originating the prefix reachability adverti=
sement or by SRMS advertisements. The latter are level/area agnostic - and =
even you are agreeing that we should
 not change that.


There is then n=
o reason for the SID to be altered as it is advertised into different areas=
.  Which leads us to the conclusion that SIDs are not level/area speci=
fic.


 


If your concern=
 is that border routers who may have more entries in their SID database tha=
n intra-area routers may come to a different conclusion as regards conflict=
s - I agree with you - but I do not
 believe your proposal resolves the problem.


Consider the fo=
llowing simple topology:


 


A1-----A2------=
B2-----B1


 


All nodes run I=
S-IS.


A1 is a Level-1=
 router in Area A. It advertises: 1.1.1.1/32 SID 100<=
/b>


A2 is a Level-1=
-2 router in Area A


 


B1 is a Level-1=
 router in Area B. It advertises: 2.2.2.2/32 SID 100<=
/b>


B2 is a Level-1=
-2 router in Area B


 


If Level 1 rout=
es are leaked into Level 2 but NOT down into Level 1, we have the following=
 SID databases on the four routers:


 








A1<=
/p>




1.1.1.1/32 100








A2<=
/p>




1.1.1.1/32 100


2.2.2.2/32 100








B1<=
/p>




2.2.2.2/32 100








B2<=
/p>




1.1.1.1/32 100


2.2.2.2/32 100








 


 


Here are the activ=
e entries on each node comparing the two algorithms

 








Node




Draft Algorithm<=
/o:p>




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100




1.1.1.1/32 100








A2<=
/p>




1.1.1.1/32 100




1.1.1.1/32 100








B1<=
/p>




2.2.2.2/32 100




2.2.2.2/32 100








B2<=
/p>




1.1.1.1/32 100




2.2.2.2/32 100








 


There is a trad=
eoff here between being able to forward some inter-area traffic entering th=
e network via the L2 sub-domain but impacting some intra-area traffic =
 vs being able to forward all intra-area
 traffic but no inter-area traffic.


Not clear which=
 strategy is “better” – but it is clear that neither stra=
tegy eliminates all issues. Given that the same SID database will NOT exist=
 on all routers in multi-area deployments some risk exists
 and cannot be totally eliminated.


 


I do agree that=
 we should try to minimize the use of conflicting SIDs for inter-area traff=
ic. What is lacking in the draft is a statement that conflicting SIDs shoul=
d not be leaked out of an area. I will
 work on a statement in the draft to make that point clear.


 


<Shraddha> Not leaking the conflicting SIDs=
 makes sense. But Even if the conflicting SIDs are not leaked across bounda=
ries, there is still a possibility that inter-area/intra-area traffic gets =
misforwarded at the area boundary. This issue can cause potential security =
risks as the traffic can get delivered to unintended node.The best option i=
s to ignore both conflicting entries when they belong to different area/lev=
el


 


     1. Higher protocol prefe=
rence wins


    2. If the entries belong to di=
fferent sub-domains ignore both entries


     3. Higher srms preferenc=
e value wins


     4. Smaller range wins


     5.IPv6 entry wins over I=
Pv4 entry


     6.Longer prefix length w=
ins


     7.Smaller starting addre=
ss (considered as an unsigned integer


        value)=
 wins


     8.Smaller algorithm wins=



     9. Smaller topology Id <=
o:p>


    10. Smaller starting SID =
wins


 


 


 


Thanx for bring=
ing this issue up.


 


  &nb=
sp; Les


 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> spring mailing list


> >> =
spring@ietf.org


> >> 
https://www.ietf.org/=
mailman/listinfo/spring


> >>


> >


> > _______________________________________=
________


> > spring mailing list


> > spring@ietf.org


> > 
https://www.ietf.org/=
mailman/listinfo/spring


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring
--_000_BN3PR05MB270660621544E65EA06B04F6D5BF0BN3PR05MB2706namp_-- From nobody Fri Jul 28 03:43:06 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF0F1318A8 for ; Fri, 28 Jul 2017 03:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.389 X-Spam-Level: X-Spam-Status: No, score=-5.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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 UwTOJ-8f1nCe for ; Fri, 28 Jul 2017 03:42:59 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5201200ED for ; Fri, 28 Jul 2017 03:42:58 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4DCA72050A; Fri, 28 Jul 2017 12:42:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 0DB9640066; Fri, 28 Jul 2017 12:42:57 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0352.000; Fri, 28 Jul 2017 12:42:56 +0200 From: To: Shraddha Hegde , "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS/NN8VkET5jeHE0aVgjgvlbOfdqJd3UHwgAWfiQCABAJAYIABng6A Date: Fri, 28 Jul 2017 10:42:55 +0000 Message-ID: <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47828C93OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 10:43:05 -0000 --_000_53C29892C857584299CBF5D05346208A47828C93OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Always as an individual contributor, thanks to Shraddha comments, a few poi= nt below 1) Conflict resolution per LSDB or across LSDB I've haven't re-read all text, but I'm not certain that the current text sp= ecifies whether the conflict resolution must be run on a per LSDB basis, or= across all LSDB. I think we'll agree that we all implementation be consist= ent on this point, hence this need to be specified. 2) Conflict resolution per LSDB or across LSDB ? I believe Les means across LSDB but Shraddha raised interesting questions r= egarding this, using area/level or IGP transitioning use cases. a) Thesis: On the "per LSDB" side: Running conflict resolution on a per LSDB ensure that this conflict resolut= ion runs on the same data, which is required to get the same result. Otherw= ise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topolo= gies) we have inconsistencies. b) Antithesis: On the "across LSDB" side: We need consistency across the network, hence across LSDBs. c) Synthesis We seem to have a tradeoff issue as we can't have both. However, it seems t= o me that the consistency issue with different LSDB is not specific to SR c= onflict resolution. We can have it with regular IP routing/forwarding. Henc= e this may favor enforcing consistency within LSDB which we can still enfor= ce. Some (two) details inlined [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network. Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network. In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement. [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= >From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic [Bruno] I'm not sure to undertand what is meant by "level/area agnostic". I= n IS-IS, SRMS advertisements seems to be able to be scoped on a per area/le= vel basis using the S-flag https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#s= ection-2.4 - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. [Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area= or not. If it does, it could take into account both SIDs: incoming label f= rom the SID of the incoming area, outgoing label from the SID of the outgoi= ng area. Not that different from LDP which select the label on a per neighb= or basis...even though LDP does not do routing i.e. does not natively have = this information. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR that > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > >> > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A47828C93OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Always = as an individual contributor, thanks to Shraddha comments, a few point belo= w

&n= bsp;

= 1)      Conflict resolution per LSDB or across LSDB

I’= ;ve haven’t re-read all text, but I’m not certain that the curr= ent text specifies whether the conflict resolution must be run on a per LSD= B basis, or across all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be spec= ified.

&n= bsp;

&n= bsp;

= 2)      Conflict resolution per LSDB or across LSDB ?

I belie= ve Les means across LSDB but Shraddha raised interesting questions regardin= g this, using area/level or IGP transitioning use cases.<= /p>

= a)      Thesis: On the “per LSDB” side:

Running= conflict resolution on a per LSDB ensure that this conflict resolution run= s on the same data, which is required to get the same result. Otherwise, as= per Shraddha’s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.=

&n= bsp;

= b)      Antithesis: On the “across LSDB” side:

We need= consistency across the network, hence across LSDBs.

&n= bsp;

= c)       Synthesis

We seem= to have a tradeoff issue as we can’t have both. However, it seems to= me that the consistency issue with different LSDB is not specific to SR co= nflict resolution. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within L= SDB which we can still enforce.

&n= bsp;

&n= bsp;

Some (t= wo) details inlined [Bruno]

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks = for the response.

&n= bsp;

 &= nbsp; It is important  to keep the network functioning correctly in ca= se of transitioning from

 &= nbsp; one protocol to the other.

 &= nbsp;

 &= nbsp; Let us assume a case of OSPF SR network transitioning to ISIS SR= network.

 &= nbsp; Most typical transitioning technique is ships in the night where both= protocols will be

 &= nbsp; enabled in the network with OSPF having better preference and th= e issue in ISIS routing do

 &= nbsp; not affect the traffic. Once the ISIS deployment is complete, the tra= ffic will be switched

 &= nbsp; to ISIS by changing preference.

 &= nbsp;

 &= nbsp; In case of OSPF-SR transitioning to ISIS SR, because of the conf= lict resolution

 &= nbsp; rules that the conflicts are protocol independent, it is possibl= e that config mistakes in ISIS

 &= nbsp; will bring down the routes in OSPF. The ISIS topology and OSPF topolo= gy is not expected to be congruent

 &= nbsp; during transition,

 &= nbsp; so the conflicts seen on each node combining the two views will not b= e similar.

 &= nbsp; This has potential to cause routing loops/ traffic drops in the = network.

 &= nbsp;

 &= nbsp; I suggest to add the protocol-preference as one of the parameter= s in the preference algorithm

 &= nbsp; with this being on the top of the list.

 &= nbsp; The resultant conflict resolution will be consistent on ISIS topology= and OSPF topology

 &= nbsp;and is the best suited model for ships in the night transitions.<= /o:p>

&n= bsp;

Pls see= inline for other responses.

&n= bsp;

Rgds

Shraddh= a

&n= bsp;

&n= bsp;

From: Les Ginsberg (ginsberg) [= mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -=

 

Thanx for the comments - res= ponses inline.

 

> -----Original Message--= ---

> From: spring [mailto:spring-bounces@ietf.org] On = Behalf Of Shraddha Hegde

> Sent: Thursday, July 20= , 2017 11:44 PM

> To: spring@ietf.org

> Subject: Re: [spring] W= G Last Call for draft-ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is = an important problem to solve and it is important to

> Standardize this draft.=

>

> I generally support the= draft but have a few major comments which I hope

> the authors will work o= n.

>

>

>  1.Conflict resolu= tion and forwarding

>

>    =          Section 3.4 has the statem= ent

>    =          "Active Entries in th= e database may be used in forwarding."

>

>    =           This is a very loose= statement which does not enforce

> implementations to prog= ram the forwarding plane

>     = ;        with the active database entrie= s.

>     = ;        This does not ensure traffic dr= ops are minimized.

>

= [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" ent= ries will be used . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated wit= h a prefix which is not actually reachable. So the language in the draft is= intentional and is correct.

<Shraddha> The language in the draft is ambiguous and it does not h= elp achieve consistent forwarding behavior across implementations.

            &= nbsp;         Prefixes that are not= reachable may not be used in forwarding which is acceptable but the draft = does not mandate that the reachable prefixes which are active

            &= nbsp;       MUST be programmed. Normative lan= guage is necessary in the draft w.r.t using active entries in forwarding.

 

&= nbsp;

>     = ;        The Forwarding plane programmin= g aspects are completely missing in

> the document.

>     = ;        A separate section is needed wh= ich describes the different aspects

> of programming the forw= arding plane.

 

[Les:] This is NOT in = scope for this draft. If you want a description of how SR MPLS forwarding w= orks please see draft-ietf-spring-segment-routing-mpls.

 

<Shraddha> The point I am bringing up here is not how SR MPLS forwa= rding works. It is w.r.t to programming the forwarding plane when there is = a conflict.

            &= nbsp;         

The abstract section has below statement

 

“In cases where the
   information advertised by a given pr=
otocol instance is either
   internally inconsistent or conflicts=
 with advertisements from another
   protocol instance a means of achievi=
ng consistent forwarding behavior
   in the network is required.”
 
If the draft is not go=
ing to address the forwarding plane detail w.r.t conflicting entries it is =
definitely not meeting the
The objective describe=
d above.
 
Take an example of a c=
onflict
(192, 192.0.2.1/32, 20=
0, 1, 0, 0)
   (192, 192=
.0.2.222/32, 200, 1, 0, 0)
   SID 200 h=
as been assigned to 192.0.2.1/32 by the
   first adv=
ertisement.
   The secon=
d advertisement assigns SID 200 to 192.0.2.222/32.
 
In this case after app=
lying the preference rules
(192, 192.0.2.1/32, 20=
0, 1, 0, 0)
 Becomes active entry.=

 
As per the text in the=
 draft,” it may be used in forwarding” so some implementations<=
o:p>
May choose to program =
forwarding plane and some may not which does not give a consistent forwardi=
ng behavior
Across implementations=
.
 
 

 

 

>

> 2.  Protocol indep= endent resolution and impact on network migrations

>    =           In case of network m= igration from one protocol to other for ex: OSPF-

> SR to ISIS-SR,

>    =           it is useful to asso= ciate protocol preferences on a local node to the SID

> advertisement

>     = ;        and feed into the conflict reso= lution. This would make sure the

> conflicts will always

>     = ;        have a winner which is an adver= tisement from protocol with

> preferred admin-distanc= e.

>

>     = ;        There is need for introducing a= nother preference value specific to

> protocol preference

>     = ;        and make it the top rule in the= preference rule hierarchy.

>

&nbs= p;

[Le= s:] "admin distance" is a locally defined preference which is not= advertised. It is therefore not possible to include it as a parameter in a= n algorithm which requires a consistent answer on all nodes throughout the network.

<= o:p> 

<Shraddha>  =
;In migration cases, topologies across two different protocols are not cong=
ruent causing inconsistent behavior.
   &nbs=
p;            &=
nbsp;      Using admin-distance as an input parame=
ter keeps the conflict resolution with-in the protocol and guarantees<=
/o:p>
   &nbs=
p;            &=
nbsp;     Consistent behavior across all the nodes corr=
esponding to that protocol.
 
   &nbs=
p;            &=
nbsp;    The drafts tries to address this scenario part=
ially between IGP and BGP by suggesting preference values. But that does no=
t solve the
Problem between two di=
fferent IGPs. 
 

&= nbsp;

>     = ;        This would also solve the issue= of MT-ID numbers being different in

> different protocols

>     = ;        as the SIDs would be compared w= ithin a protocol advertisement.

 

[Les:] I do not unders= tand what relationship you see between "protocol preference" and = "MT-ID".

MT-ID values are scope= d by  the protocol which uses them. For example, OSPFv2 supports a 7 b= it MT-ID while IS-IS supports a 12 bit MT-ID. It is therefore possible for = non-matching MTIDs to be used by different protocols when advertising routes for the same physical topology. This is = why the draft's use of "topology" is not as MTID but rather as a = locally scoped identifier. >From Section 3:

 

" Note: Topology is a locally scoped identifier assigned by eac= h

   router.  Although it may have an association with = Multitopology

   Identifiers (MTID) advertised by routing protocols it i= s NOT

   equivalent to these identifiers.  MTIDs are scoped= by a given routing

   protocol.  MTID ranges are protocol specific and t= here may be

   standardized protocol specific MTID assignments for top= ologies of a

   specific type (e.g., an AFI specific topology).  A= s mapping entries

   can be sourced from multiple protocols it is not possib= le to use a

   network scoped identifier for a topology when storing m= apping entries

   in the local database."<= /p>

 

Topology is then used = to detect different scopes for a mapping entry - which may result in a SID = conflict if the same SID is used in different topologies, but it cannot be = used as a tiebreaker since its value is local and any preference (e.g., higher value wins)  is not guarant= eed to result in consistent answers on all nodes in the network. Which is w= hy we have Section 3.3 Rule #8:

 

   "8.  If topology IDs are NOT identical both e= ntries MUST be ignored"

<= Shraddha> Lets keep this discussion on-hold until we decide on the proto= col preference and migration issues.=

 

>

> 3. In case of hierarchi= cal IGP networks with multiple ISIS Levels or OSPF areas,=

> It's possible that the<= o:p>

>    =   conflicts are not visible in entire domain but are visible only on t= he border

> router as the border ro= uters

>    =   have the database of both domains.

>    = The conflict resolution preference Rules should be enhanced to include the=

> Level information in th= e preference rule.

>    = A new parameter called sub-domain should be defined.

>

>     = ;            &n= bsp;           One could = propose using existing SRMS preference values

> and assigning prefixes = with preference values

>     = ;        based on levels they are advert= ised in. This introduces more complex

> configuration requireme= nts on the

>     = ;        network. The objective of this = draft is to achieve consistent

> behaviours in case of m= isconfigurations and

>     = ;        introducing more configurations= as a solution does not help.

>

>

>     = ;            &n= bsp;           Based on t= he Advertisement originated in ISIS Level or OSPF

> area below values are d= efined.

>

>     = ;            &n= bsp;           Level 1 , = non-zero OSPF area =3D1

>     = ;            &n= bsp;           Level 2, O= SPF Area 0 =3D 2

>     = ;            &n= bsp;           Non IGPs s= et subdomain =3D 0

>

>     = ;            &n= bsp;            = ;            &n= bsp;            = ;      Preference algorithm is changed as

>

>    = 1. Higher protocol preference wins

=  

= [Les:] I have explained above why protocol preference cannot be used.<= /o:p>

&= nbsp;

>    2. sm= aller sub-domain wins

>    = 3. Higher srms preference value wins

>    = 4. Smaller range wins

>    = 5.IPv6 entry wins over IPv4 entry

>    = 6.Longer prefix length wins

>    = 7.Smaller starting address (considered as an unsigned integer

>    =     value) wins

>    = 8.Smaller algorithm wins

>    = 9. Smaller topology Id wins >>>>>>>>>>..Move= d above SID comparison.

> since the all these rul= es are applied

>     = ;             &= nbsp;           &nbs= p;            &= nbsp;         within protocol = it's safe to compare topology IDs

= [Les:] No – it isn’t – as explained above.=

>    = 10. Smaller starting SID wins

>

= [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic<= o:p>

[Bruno] I’m not sure to undertand what is meant by “level/are= a agnostic”. In IS-IS, SRMS advertisements seems to be able to be sco= ped on a per area/level basis using the S-flag

https://tools.ietf.org/html/draft-ietf-isis-segmen= t-routing-extensions-13#section-2.4

 

= - and even you are agreeing that we should not change that.

= There is then no reason for the SID to be altered as it is advertised into = different areas.  Which leads us to the conclusion that SIDs are not l= evel/area specific.

=  

= If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal resolves the problem.=

= Consider the following simple topology:

=  

= A1-----A2------B2-----B1

=  

= All nodes run IS-IS.

= A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100

= A2 is a Level-1-2 router in Area A

=  

= B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100

= B2 is a Level-1-2 router in Area B

=  

= If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers:

&= nbsp;

A1<= /p>

1.1.1.1/32 100

A2<= /p>

1.1.1.1/32 100

2.2.2.2/32 100

B1<= /p>

2.2.2.2/32 100

B2<= /p>

1.1.1.1/32 100

2.2.2.2/32 100

&= nbsp;

&= nbsp;

Her= e are the active entries on each node comparing the two algorithms

&= nbsp;

Node

Draft Algorithm<= /o:p>

Shraddha Algorithm

A1<= /p>

1.1.1.1/32 100

1.1.1.1/32 100

A2<= /p>

1.1.1.1/32 100

1.1.1.1/32 100

B1<= /p>

2.2.2.2/32 100

2.2.2.2/32 100

B2<= /p>

1.1.1.1/32 100

2.2.2.2/32 100

&= nbsp;

= There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic  vs being able to forward all intra-area traffic but no inter-area traffic.

[Bruno] For MPLS transit, the ABR knows whether the traffic leaves the ar= ea or not. If it does, it could take into account both SIDs: incoming label= from the SID of the incoming area, outgoing label from the SID of the outgoing area. Not that different from LDP which= select the label on a per neighbor basis…even though LDP does not do= routing i.e. does not natively have this information.

= Not clear which strategy is “better” – but it is clear th= at neither strategy eliminates all issues. Given that the same SID database= will NOT exist on all routers in multi-area deployments some risk exists and cannot be totally eliminated.

=  

= I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement in the draft to make that point clear.=

 

<Shraddha> Not l=
eaking the conflicting SIDs makes sense. But Even if the conflicting SIDs a=
re not leaked across boundaries, there is still a possibility that inter-ar=
ea/intra-area traffic gets misforwarded at the area boundary. This issue ca=
n cause potential security risks as the traffic can get delivered to uninte=
nded node.The best option is to ignore both conflicting entries when they b=
elong to different area/level
 
   &nbs=
p; 1. Higher protocol preference wins
    2. =
If the entries belong to different sub-domains ignore both entries
   &nbs=
p; 3. Higher srms preference value wins
   &nbs=
p; 4. Smaller range wins
   &nbs=
p; 5.IPv6 entry wins over IPv4 entry
   &nbs=
p; 6.Longer prefix length wins
   &nbs=
p; 7.Smaller starting address (considered as an unsigned integer=

   &nbs=
p;    value) wins
   &nbs=
p; 8.Smaller algorithm wins
   &nbs=
p; 9. Smaller topology Id 
   &nbs=
p;10. Smaller starting SID wins
 

 

 

= Thanx for bringing this issue up.

=  

=     Les

&= nbsp;

>

>

> Rgds<= /p>

> Shraddha

>

> -----Original Message--= ---

> From: Martin Horneffer = [mailto:maho@nic.dtag.de]

> Sent: Friday, July 14, = 2017 8:22 PM

> To: spring@ietf.org

> Subject: Re: [spring] W= G Last Call for draft-ietf-spring-conflict-resolution

>

> Strong support from me,= too.

>

>  From an operator'= s point of view this is really needed.

>

> Best regards, Martin

>

>

> Am 10.07.17 um 14:58 sc= hrieb Martin Vigoureux:

> ><= /p>

> > WG,

> ><= /p>

> > We are half-way th= rough the WG Last Call and I am very surprised to

> > only see a single = answer to it.

> ><= /p>

> > I am not sure I'll= move this forward with only silence as support.

> ><= /p>

> > -m

> ><= /p>

> > Le 29/06/2017 =E0 = 15:28, Martin Vigoureux a =E9crit :

> >> Hello Working = Group,

> >>

> >> This email sta= rts a Working Group Last Call on

> >> draft-ietf-spr= ing-conflict-resolution-04 [1] which is considered

> >> mature and rea= dy for a final working group review.

> >>

> >> =A4 Please rea= d this document if you haven't read the most recent

> >> version yet, a= nd send your comments to the list, no later than *21st

> >> of July*.=

> >> Note that this= is *not only* a call for comments on the document; it

> >> is also a call= for support (or not) to publish this document as a

> >> Proposed Stand= ard RFC.

> >>

> >> =A4 *Coinciden= tally*, we are also polling for knowledge of any IPR that=

> >> applies to dra= ft-ietf-spring-conflict-resolution, to ensure that IPR

> >> has been discl= osed in compliance with IETF IPR rules (see RFCs 3979,

> >> 4879,

> >> 3669 and 5378 = for more details).

> >>

> >> If you are lis= ted as an Author or Contributor of

> >> draft-ietf-spr= ing-conflict-resolution-04 please respond to this email

> >> and indicate w= hether or not you are aware of any relevant IPR.

> >>

> >> Note that, as = of today, no IPR has been disclosed against this

> >> document or it= s earlier versions.

> >>

> >> Thank you,

> >> Martin

> >>

> >> [1]=

> >> https://datatracker.i= etf.org/doc/draft-ietf-spring-conflict-resolutio

> >> n/<= /span>

> >>

> >> ______________= _________________________________

> >> spring mailing= list

> >> spring@ietf.org

> >> https://www.ietf.org/= mailman/listinfo/spring

> >>

> ><= /p>

> > __________________= _____________________________

> > spring mailing lis= t

> > spri= ng@ietf.org

> > https://www.ietf.org/= mailman/listinfo/spring

> ><= /p>

>

>

> _______________________= ________________________

> spring mailing list

> spring@ie= tf.org

> https://www.ietf.org/= mailman/listinfo/spring

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A47828C93OPEXCLILM21corp_-- From nobody Fri Jul 28 15:18:32 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBB9131DA4 for ; Fri, 28 Jul 2017 15:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 3lZS6tlQEVk7 for ; Fri, 28 Jul 2017 15:18:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B11131CEB for ; Fri, 28 Jul 2017 15:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=82537; q=dns/txt; s=iport; t=1501280306; x=1502489906; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=59yvqrnBhcc8qlGlKVlKjzRdR9cy1RozWE+529YYQyw=; b=nA3QvrRamqjqTfx8KH5ln0jYxaIVt2xCb2cX+Gld2h61D6ODNKlxIwjI Q/nMRgD0yEH/7eV3Yuy42c27q5P2n4ncQh84Q7sp1TZvZQnY6DRrZ9mBq phak3/N1qzdda6X8sb5D7PY4BXi5UoiFfNObwFyeHSOxmGKAQXuEBkaDY Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0AQAxt3tZ/51dJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm8+LWRtJweOBo95gWuWCw6CAQMhAQqETE8Cg3Q/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAgEBARgBAhBBBAwHBAIBCBEEAQEhAQYHJwsUCQgCBAESCBOJMFwIE?= =?us-ascii?q?LF/iz8BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMog02BYAGCG4EMhEABEgEmBxg?= =?us-ascii?q?QAoU8BZE0hiyIDQKHTYMCiUyCFYVSg3iGZpVxAR84WSYLdxVJhRYcgWd2h0+BI?= =?us-ascii?q?4EOAQEB?= X-IronPort-AV: E=Sophos;i="5.40,427,1496102400"; d="scan'208,217";a="275935757" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2017 22:18:23 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v6SMINFW002841 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2017 22:18:23 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Jul 2017 17:18:22 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Fri, 28 Jul 2017 17:18:22 -0500 From: "Les Ginsberg (ginsberg)" To: Shraddha Hegde , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nuokzsm0yt5P0y/+D1uKMVbQqJNamsAgAZpFICACngugIAENtLAgAaTbgCAAN688A== Date: Fri, 28 Jul 2017 22:18:22 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.90.196] Content-Type: multipart/alternative; boundary="_000_c4662815efe94d25a81449d885a4fc0fXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 22:18:30 -0000 --_000_c4662815efe94d25a81449d885a4fc0fXCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Shraddha - Protocol preference (commonly known as admin distance) is a locally configu= red value which is not advertised. Therefore there is no way for one node t= o know what preference another node has assigned to different protocols. If= admin distance is used as part of the conflict resolution algorithm there = is therefore no way to guarantee consistency on different nodes. I have po= inted this out previously - you have not acknowledged this. Let's use your example below - transitioning a network from OSPF to IS-IS = - to show how using admin distance in the conflict resolution algorithm res= ults in inconsistency. Consider the following simple network: A---B---C---D Node A originates the prefix 1.1.1.1/32. The network is using OSPF and OSPF is advertising SID 100 for 1.1.1.1. All = nodes use SID 100 in their forwarding planes. The customer wants to transition to IS-IS, and so starts configuring IS-IS = on each node, but makes sure that initially the admin distance assigned to= IS-IS is greater than (less preferred) than that of OSPF. In configuring IS-IS the customer makes a mistake and assigns SID 200 to 1.= 1.1.1. (This presumes a protocol centric model for configuring SIDs - whic= h I do not recommend - but let's ignore that for now.) The customer is now ready to switch the network to IS-IS and starts to do s= o by changing the admin distance of IS-IS on Node D to be more preferred. Using your proposal, Node D would now choose SID 200 as the Active SID for = prefix 1.1.1.1. But on Node C, OSPF is still the more preferred protocol, so on Node C SID = 100 is being used for 1.1.1.1. As soon as the admin distance change is made on Node D, the label associate= d with SID 200 will be programmed in forwarding to send traffic addressed t= o 1.1.1.1 via Node C. But in Node C's forwarding plane SID 100 is being used, so when the packet = arrives at Node C it will get dropped. Contrast that with the behavior when using algorithm currently defined in = the draft. In the presence of the two conflicting advertisements: (192, 1.1.1.1/32, 100, 1, 0, 0) (192, 1.1.1.1/32, 200, 1, 0, 0) SID 100 will be declared the winner (Rule #7: Lower SID wins) This will be true regardless of which protocol is the "best" at any moment = in time on any node. So even when IS-IS becomes the winning protocol on Nod= e D the forwarding plane continues to use SID 100 on all nodes. Therefore, = forwarding is not compromised when transitioning from one protocol to anoth= er. Of course, a far better strategy is to make SID configuration independent o= f the protocol. Then when introducing a new protocol both protocols would o= btain and advertise the same SID value for the same prefix and the problem = state described above would simply never occur. HTH clarify why your suggestion is not viable. Les From: Shraddha Hegde [mailto:shraddha@juniper.net] Sent: Thursday, July 27, 2017 8:31 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network= . Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network= . In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement= . [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR tha= t > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > >> > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --_000_c4662815efe94d25a81449d885a4fc0fXCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Shraddha –<= /o:p>

 

Protocol preference (c= ommonly known as admin distance) is a locally configured value which is not= advertised. Therefore there is no way for one node to know what preference= another node has assigned to different protocols. If admin distance is used as part of the conflict resolution al= gorithm there is therefore no way to guarantee consistency on different nod= es.  I have pointed this out previously – you have not acknowled= ged this.

 

Let’s use your e= xample below  - transitioning a network from OSPF to IS-IS – to = show how using admin distance in the conflict resolution algorithm results = in inconsistency.

 

Consider the following= simple network:

 

A---B---C---D

 

Node A originates the = prefix 1.1.1.1/32.

The network is using O= SPF and OSPF is advertising SID 100 for 1.1.1.1. All nodes use SID 100 in t= heir forwarding planes.

 

The customer wants to = transition to IS-IS, and so starts configuring IS-IS on each node, but make= s sure that initially  the admin distance assigned to IS-IS is greater= than (less preferred) than that of OSPF.

In configuring IS-IS t= he customer makes a mistake and assigns SID 200 to 1.1.1.1.  (This pre= sumes a protocol centric model for configuring SIDs – which I do not = recommend – but let’s ignore that for now.)

 

The customer is now re= ady to switch the network to IS-IS and starts to do so by changing the admi= n distance of IS-IS on Node D to be more preferred.

Using your proposal, N= ode D would now choose SID 200 as the Active SID for prefix 1.1.1.1.

But on Node C, OSPF is= still the more preferred protocol, so on Node C SID 100 is being used for = 1.1.1.1.

 

As soon as the admin d= istance change is made on Node D, the label associated with SID 200 will be= programmed in forwarding to send traffic addressed to 1.1.1.1 via Node C.<= o:p>

But in Node C’s = forwarding plane SID 100 is being used, so when the packet arrives at Node = C it will get dropped.

 

Contrast that with the= behavior  when using algorithm currently defined in the draft. In the= presence of the two conflicting advertisements:

 

(192, 1.1.1.1/32, 100,= 1, 0, 0)

(192, 1.1.1.1/32, 200,= 1, 0, 0)

 

SID 100 will be declar= ed the winner (Rule #7: Lower SID wins)

This will be true rega= rdless of which protocol is the “best” at any moment in time on= any node. So even when IS-IS becomes the winning protocol on Node D the fo= rwarding plane continues to use SID 100 on all nodes. Therefore, forwarding is not compromised when transitioning from one proto= col to another.

 

Of course, a far bette= r strategy is to make SID configuration independent of the protocol. Then w= hen introducing a new protocol both protocols would obtain and advertise th= e same SID value for the same prefix and the problem state described above would simply never occur.=

 

HTH clarify why your s= uggestion is not viable.

 

   Les<= /o:p>

 

 

 

From: Shraddha= Hegde [mailto:shraddha@juniper.net]
Sent: Thursday, July 27, 2017 8:31 PM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.<= /o:p>

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 

“In cases where the

   information advertised by a given protocol instance is ei=
ther


   internally inconsistent or conflicts with advertisements =
from another


   protocol instance a means of achieving consistent forward=
ing behavior


   in the network is required.”


 


If the draft is not going to address =
the forwarding plane detail w.r.t conflicting entries it is definitely not =
meeting the


The objective described above.


 

Take an example of a conflict


(192, 192.0.2.1/32, 200, 1, 0, 0)


   (192, 192.0.2.222/32, 20=
0, 1, 0, 0)


   SID 200 has been assigne=
d to 192.0.2.1/32 by the


   first advertisement.


   The second advertisement=
 assigns SID 200 to 192.0.2.222/32.


 

In this case after applying the prefe=
rence rules


(192, 192.0.2.1/32, 200, 1, 0, 0)


 Becomes active entry.


 

As per the text in the draft,” =
it may be used in forwarding” so some implementations


May choose to program forwarding plan=
e and some may not which does not give a consistent forwarding behavior


Across implementations.


 

 


 


 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 =



[Les:] "admin=
 distance" is a locally defined preference which is not advertised. It=
 is therefore not possible to include it as a parameter in an algorithm whi=
ch requires a consistent answer on all nodes throughout
 the network.


 


<Shraddha>  In migration c=
ases, topologies across two different protocols are not congruent causing i=
nconsistent behavior.


      &=
nbsp;           &nbs=
p;    Using admin-distance as an input parameter keeps the c=
onflict resolution with-in the protocol and guarantees


      &=
nbsp;           &nbs=
p;   Consistent behavior across all the nodes corresponding to th=
at protocol.


 

      &=
nbsp;           &nbs=
p;  The drafts tries to address this scenario partially between I=
GP and BGP by suggesting preference values. But that does not solve the


Problem between two different IGPs. <=
o:p>


 

 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each

   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing


   pro=
tocol.  MTID ranges are protocol specific and there may be<=
/i>


   sta=
ndardized protocol specific MTID assignments for topologies of a=



   spe=
cific type (e.g., an AFI specific topology).  As mapping entries<=
/o:p>


   can=
 be sourced from multiple protocols it is not possible to use a<=
/i>


   net=
work scoped identifier for a topology when storing mapping entries


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.

> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have e=
xplained above why protocol preference cannot be used.


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No ̵=
1; it isn’t – as explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are=
 assigned either by the node(s) originating the prefix reachability adverti=
sement or by SRMS advertisements. The latter are level/area agnostic - and =
even you are agreeing that we should
 not change that.


There is then n=
o reason for the SID to be altered as it is advertised into different areas=
.  Which leads us to the conclusion that SIDs are not level/area speci=
fic.


 


If your concern=
 is that border routers who may have more entries in their SID database tha=
n intra-area routers may come to a different conclusion as regards conflict=
s - I agree with you - but I do not
 believe your proposal resolves the problem.


Consider the fo=
llowing simple topology:


 


A1-----A2------=
B2-----B1


 


All nodes run I=
S-IS.


A1 is a Level-1=
 router in Area A. It advertises: 1.1.1.1/32 SID 100<=
/b>


A2 is a Level-1=
-2 router in Area A


 


B1 is a Level-1=
 router in Area B. It advertises: 2.2.2.2/32 SID 100<=
/b>


B2 is a Level-1=
-2 router in Area B


 


If Level 1 rout=
es are leaked into Level 2 but NOT down into Level 1, we have the following=
 SID databases on the four routers:


 








A1<=
/p>




1.1.1.1/32 100








A2<=
/p>




1.1.1.1/32 100


2.2.2.2/32 100








B1<=
/p>




2.2.2.2/32 100








B2<=
/p>




1.1.1.1/32 100


2.2.2.2/32 100








 


 


Here are the activ=
e entries on each node comparing the two algorithms

 








Node




Draft Algorithm<=
/o:p>




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100




1.1.1.1/32 100








A2<=
/p>




1.1.1.1/32 100




1.1.1.1/32 100








B1<=
/p>




2.2.2.2/32 100




2.2.2.2/32 100








B2<=
/p>




1.1.1.1/32 100




2.2.2.2/32 100








 


There is a trad=
eoff here between being able to forward some inter-area traffic entering th=
e network via the L2 sub-domain but impacting some intra-area traffic =
 vs being able to forward all intra-area
 traffic but no inter-area traffic.


Not clear which=
 strategy is “better” – but it is clear that neither stra=
tegy eliminates all issues. Given that the same SID database will NOT exist=
 on all routers in multi-area deployments some risk exists
 and cannot be totally eliminated.


 


I do agree that=
 we should try to minimize the use of conflicting SIDs for inter-area traff=
ic. What is lacking in the draft is a statement that conflicting SIDs shoul=
d not be leaked out of an area. I will
 work on a statement in the draft to make that point clear.


 


<Shraddha> Not leaking the conf=
licting SIDs makes sense. But Even if the conflicting SIDs are not leaked a=
cross boundaries, there is still a possibility that inter-area/intra-area t=
raffic gets misforwarded at the area boundary. This issue can cause potenti=
al security risks as the traffic can get delivered to unintended node.The b=
est option is to ignore both conflicting entries when they belong to differ=
ent area/level


 

     1. Higher pr=
otocol preference wins


    2. If the entries =
belong to different sub-domains ignore both entries


     3. Higher sr=
ms preference value wins


     4. Smaller r=
ange wins


     5.IPv6 entry=
 wins over IPv4 entry


     6.Longer pre=
fix length wins


     7.Smaller st=
arting address (considered as an unsigned integer=



      &=
nbsp; value) wins


     8.Smaller al=
gorithm wins


     9. Smaller t=
opology Id 


    10. Smaller s=
tarting SID wins


 

 


 


Thanx for bring=
ing this issue up.


 


  &nb=
sp; Les


 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> spring mailing list


> >> =
spring@ietf.org


> >> 
https://www.ietf.org/=
mailman/listinfo/spring


> >>


> >


> > _______________________________________=
________


> > spring mailing list


> > spring@ietf.org


> > 
https://www.ietf.org/=
mailman/listinfo/spring


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring
--_000_c4662815efe94d25a81449d885a4fc0fXCHALN001ciscocom_-- From nobody Fri Jul 28 15:25:24 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EB5131E7B for ; Fri, 28 Jul 2017 15:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 IuW_L99I8T3F for ; Fri, 28 Jul 2017 15:25:17 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2220D1321B9 for ; Fri, 28 Jul 2017 15:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=89410; q=dns/txt; s=iport; t=1501280716; x=1502490316; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=0LiaxVkomqkN3lAdCkAjPQYRrA5FhDVUAu39sqS3gHU=; b=f88P7o5xwMGylGA5dWjVOLq4SrKLDB7UabItRZ5p130ESKXBJZeVfFdR bO6OCiafbvhISfVJZh8CL/LQMKZdxb7SaVU0N4F0DDlG1YplhsqWDd741 lORnEmi21j5lwX5PrdJeqdovFv5yPtGhxMw0Dsz0gfyTOb9CojQJbKqUr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAABluHtZ/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWRtJweOBo95gWuWCw6CAQMhAQyESk8Cg3Q/GAECAQEBAQE?= =?us-ascii?q?BAWsohRgBAQEBAgEBARgBAhBBBAwHBAIBCBEEAQEWCwEGBycLFAkIAgQBEggTi?= =?us-ascii?q?TBcCBCxfos/AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDKINNgWABghuBDIQwEAE?= =?us-ascii?q?SASYHGAYKAgeFNQWRNIYsiA0Ch02DAolMghWFUoN4hmaVcQEfOFkmC3cVSYUWH?= =?us-ascii?q?IFndgGHToEjgQ4BAQE?= X-IronPort-AV: E=Sophos;i="5.40,427,1496102400"; d="scan'208,217";a="458152840" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 22:25:13 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6SMPDKu021119 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2017 22:25:13 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Jul 2017 17:25:12 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Fri, 28 Jul 2017 17:25:12 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" , Shraddha Hegde , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nuokzsm0yt5P0y/+D1uKMVbQqJNamsAgAZpFICACngugIAENtLAgAaTbgCAAHi3gIAAbspg Date: Fri, 28 Jul 2017 22:25:12 +0000 Message-ID: <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.90.196] Content-Type: multipart/alternative; boundary="_000_4599cc42d1a54019a2c36ef53acf5be3XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 22:25:22 -0000 --_000_4599cc42d1a54019a2c36ef53acf5be3XCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno - Please reread "Section 3.7. Guaranteeing Database Consistency.". The draft is explicit that "entries advertised by all routing protocols MUS= T be included". Also please read my recent response to Shraddha as regards the pitfalls of= using protocol specific databases for conflict resolution. Les From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Friday, July 28, 2017 3:43 AM To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Always as an individual contributor, thanks to Shraddha comments, a few poi= nt below 1) Conflict resolution per LSDB or across LSDB I've haven't re-read all text, but I'm not certain that the current text sp= ecifies whether the conflict resolution must be run on a per LSDB basis, or= across all LSDB. I think we'll agree that we all implementation be consist= ent on this point, hence this need to be specified. 2) Conflict resolution per LSDB or across LSDB ? I believe Les means across LSDB but Shraddha raised interesting questions r= egarding this, using area/level or IGP transitioning use cases. a) Thesis: On the "per LSDB" side: Running conflict resolution on a per LSDB ensure that this conflict resolut= ion runs on the same data, which is required to get the same result. Otherw= ise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topolo= gies) we have inconsistencies. b) Antithesis: On the "across LSDB" side: We need consistency across the network, hence across LSDBs. c) Synthesis We seem to have a tradeoff issue as we can't have both. However, it seems t= o me that the consistency issue with different LSDB is not specific to SR c= onflict resolution. We can have it with regular IP routing/forwarding. Henc= e this may favor enforcing consistency within LSDB which we can still enfor= ce. Some (two) details inlined [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network= . Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network= . In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement= . [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= >From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic [Bruno] I'm not sure to undertand what is meant by "level/area agnostic". I= n IS-IS, SRMS advertisements seems to be able to be scoped on a per area/le= vel basis using the S-flag https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#s= ection-2.4 - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. [Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area= or not. If it does, it could take into account both SIDs: incoming label f= rom the SID of the incoming area, outgoing label from the SID of the outgoi= ng area. Not that different from LDP which select the label on a per neighb= or basis...even though LDP does not do routing i.e. does not natively have = this information. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR tha= t > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > >> > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_4599cc42d1a54019a2c36ef53acf5be3XCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno –

 

Please reread “S= ection 3.7.  Guaranteeing Database Consistency.”.

The draft is explicit = that “entries advertised by all routing protocols MUST be included= 221;.

 

Also please read my re= cent response to  Shraddha as regards the pitfalls of using protocol s= pecific databases for conflict resolution.

 

    Les=

 

 

From: bruno.de= craene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Always as an individua= l contributor, thanks to Shraddha comments, a few point below

 

1)&n= bsp;     Conflict resol= ution per LSDB or across LSDB

I’ve haven’= ;t re-read all text, but I’m not certain that the current text specif= ies whether the conflict resolution must be run on a per LSDB basis, or acr= oss all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be specified.

 

 

2)&n= bsp;     Conflict resol= ution per LSDB or across LSDB ?

I believe Les means ac= ross LSDB but Shraddha raised interesting questions regarding this, using a= rea/level or IGP transitioning use cases.

a)&n= bsp;     Thesis: On the= “per LSDB” side:

Running conflict resol= ution on a per LSDB ensure that this conflict resolution runs on the same d= ata, which is required to get the same result. Otherwise, as per Shraddha&#= 8217;s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

 

b)&n= bsp;     Antithesis: On= the “across LSDB” side:

We need consistency ac= ross the network, hence across LSDBs.

 

c)&n= bsp;      Synthesis=

We seem to have a trad= eoff issue as we can’t have both. However, it seems to me that the co= nsistency issue with different LSDB is not specific to SR conflict resoluti= on. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within LSDB which we can still = enforce.

 

 

Some (two) details inl= ined [Bruno]

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.<= /o:p>

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 

“I=
n cases where the
&=
nbsp;  information advertised by a given protocol instance is either
&=
nbsp;  internally inconsistent or conflicts with advertisements from a=
nother
&=
nbsp;  protocol instance a means of achieving consistent forwarding be=
havior
&=
nbsp;  in the network is required.”
<=
o:p> 
If the draft is not going to addre=
ss the forwarding plane detail w.r.t conflicting entries it is definitely n=
ot meeting the
The objective described above.
 

Take an example of a conflict=



(192, 192.0.2.1/32, 200, 1, 0, 0)<=
o:p>


   (192, 192.0.2.222/32,=
 200, 1, 0, 0)


   SID 200 has been assi=
gned to 192.0.2.1/32 by the


   first advertisement.<=
o:p>


   The second advertisem=
ent assigns SID 200 to 192.0.2.222/32.


 

In this case after applying the pr=
eference rules


(192, 192.0.2.1/32, 200, 1, 0, 0)<=
o:p>


 Becomes active entry.<=
/span>


 

As per the text in the draft,̶=
1; it may be used in forwarding” so some implementations


May choose to program forwarding p=
lane and some may not which does not give a consistent forwarding behavior<=
o:p>


Across implementations.=



 

<=
o:p> 


 


 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 =



[Les:] "admin=
 distance" is a locally defined preference which is not advertised. It=
 is therefore not possible to include it as a parameter in an algorithm whi=
ch requires a consistent answer on all nodes throughout
 the network.


 


<Shraddha>  In migratio=
n cases, topologies across two different protocols are not congruent causin=
g inconsistent behavior.


     &nbs=
p;            &=
nbsp;    Using admin-distance as an input parameter keeps th=
e conflict resolution with-in the protocol and guarantees=



     &nbs=
p;            &=
nbsp;   Consistent behavior across all the nodes corresponding to=
 that protocol.


 

     &nbs=
p;            &=
nbsp;  The drafts tries to address this scenario partially betwee=
n IGP and BGP by suggesting preference values. But that does not solve the<=
o:p>


Problem between two different IGPs=
. 


 

 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each

   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing


   pro=
tocol.  MTID ranges are protocol specific and there may be<=
/i>


   sta=
ndardized protocol specific MTID assignments for topologies of a=



   spe=
cific type (e.g., an AFI specific topology).  As mapping entries<=
/o:p>


   can=
 be sourced from multiple protocols it is not possible to use a<=
/i>


   net=
work scoped identifier for a topology when storing mapping entries


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.

> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have e=
xplained above why protocol preference cannot be used.


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No ̵=
1; it isn’t – as explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are=
 assigned either by the node(s) originating the prefix reachability adverti=
sement or by SRMS advertisements. The latter are level/area agnostic=



[Bruno] IR=
17;m not sure to undertand what is meant by “level/area agnostic̶=
1;. In IS-IS, SRMS advertisements seems to be able to be scoped on a per ar=
ea/level basis using the S-flag


https://tools.ietf.org/html/draft-ietf-isis-segment-routing-exten=
sions-13#section-2.4


 


- and even you =
are agreeing that we should not change that.


There is then n=
o reason for the SID to be altered as it is advertised into different areas=
.  Which leads us to the conclusion that SIDs are not level/area speci=
fic.


 


If your concern=
 is that border routers who may have more entries in their SID database tha=
n intra-area routers may come to a different conclusion as regards conflict=
s - I agree with you - but I do not
 believe your proposal resolves the problem.


Consider the fo=
llowing simple topology:


 


A1-----A2------=
B2-----B1


 


All nodes run I=
S-IS.


A1 is a Level-1=
 router in Area A. It advertises: 1.1.1.1/32 SID 100<=
/b>


A2 is a Level-1=
-2 router in Area A


 


B1 is a Level-1=
 router in Area B. It advertises: 2.2.2.2/32 SID 100<=
/b>


B2 is a Level-1=
-2 router in Area B


 


If Level 1 rout=
es are leaked into Level 2 but NOT down into Level 1, we have the following=
 SID databases on the four routers:


 








A1<=
/p>




1.1.1.1/32 100








A2<=
/p>




1.1.1.1/32 100


2.2.2.2/32 100








B1<=
/p>




2.2.2.2/32 100








B2<=
/p>




1.1.1.1/32 100


2.2.2.2/32 100








 


 


Here are the activ=
e entries on each node comparing the two algorithms

 








Node




Draft Algorithm<=
/o:p>




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100




1.1.1.1/32 100








A2<=
/p>




1.1.1.1/32 100




1.1.1.1/32 100








B1<=
/p>




2.2.2.2/32 100




2.2.2.2/32 100








B2<=
/p>




1.1.1.1/32 100




2.2.2.2/32 100








 


There is a trad=
eoff here between being able to forward some inter-area traffic entering th=
e network via the L2 sub-domain but impacting some intra-area traffic =
 vs being able to forward all intra-area
 traffic but no inter-area traffic.


[Bruno] For M=
PLS transit, the ABR knows whether the traffic leaves the area or not. If i=
t does, it could take into account both SIDs: incoming label from the SID o=
f the incoming area, outgoing label
 from the SID of the outgoing area. Not that different from LDP which selec=
t the label on a per neighbor basis…even though LDP does not do routi=
ng i.e. does not natively have this information.<=
/p>

Not clear which=
 strategy is “better” – but it is clear that neither stra=
tegy eliminates all issues. Given that the same SID database will NOT exist=
 on all routers in multi-area deployments some risk exists
 and cannot be totally eliminated.


 


I do agree that=
 we should try to minimize the use of conflicting SIDs for inter-area traff=
ic. What is lacking in the draft is a statement that conflicting SIDs shoul=
d not be leaked out of an area. I will
 work on a statement in the draft to make that point clear.


 


<Shraddha> Not leaking the c=
onflicting SIDs makes sense. But Even if the conflicting SIDs are not leake=
d across boundaries, there is still a possibility that inter-area/intra-are=
a traffic gets misforwarded at the area boundary. This issue can cause pote=
ntial security risks as the traffic can get delivered to unintended node.Th=
e best option is to ignore both conflicting entries when they belong to dif=
ferent area/level


 

     1. Higher=
 protocol preference wins


    2. If the entri=
es belong to different sub-domains ignore both entries


     3. Higher=
 srms preference value wins


     4. Smalle=
r range wins


     5.IPv6 en=
try wins over IPv4 entry


     6.Longer =
prefix length wins


     7.Smaller=
 starting address (considered as an unsigned integer<=
/b>


     &nbs=
p;  value) wins


     8.Smaller=
 algorithm wins


     9. Smalle=
r topology Id 


    10. Smalle=
r starting SID wins


 

 


 


Thanx for bring=
ing this issue up.


 


  &nb=
sp; Les


 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> spring mailing list


> >> =
spring@ietf.org


> >> 
https://www.ietf.org/=
mailman/listinfo/spring


> >>


> >


> > _______________________________________=
________


> > spring mailing list


> > spring@ietf.org


> > 
https://www.ietf.org/=
mailman/listinfo/spring


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.


Thank you.
--_000_4599cc42d1a54019a2c36ef53acf5be3XCHALN001ciscocom_-- From nobody Sat Jul 29 16:39:32 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3481317A4; Sat, 29 Jul 2017 16:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=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 GfoVr-rYCjKI; Sat, 29 Jul 2017 16:39:15 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 22F59131C2E; Sat, 29 Jul 2017 16:39:15 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id q85so107918887pfq.1; Sat, 29 Jul 2017 16:39:15 -0700 (PDT) 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=MNQoSQ6oMmR9bLHI6/diM7OIY7Rms8k2sEorYUsGsXs=; b=nyMXznL+J8KzBBWj+74A/Ysm04aDX0UUdeaulnE9A5kwSHC9I7f8nWmA2LByV0TB3f ZxeLFiqglkdBMBLCYQmoF6R4136+H5z6EYRYPhW7ibLtB0Z++JTCuRSEjG7X+GWsXIM5 dbheonAHEvkOa35mVmExB9jba7eT0/XxDpl9V+qYbFoUjz5jcmJuiS9+SlC/XYW0NTiT KLt3fGcFYMkCBeu98p5wiWGGuUL3RMCgoVESvySl2YawLHvU4AgoVkcAxQ9L0lVL0Wze WbMRMT5UOZUG4d+WeC6UYsB2TX4Bz3s43m6aT9cEcs266emmq0B3xZy7VKXDTxP3XiZH p6FQ== 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=MNQoSQ6oMmR9bLHI6/diM7OIY7Rms8k2sEorYUsGsXs=; b=KWBh82LeFQrBSdyKVuZhB2FRolE01dXTkBsEpzjKacqfAZoFfWekjoorjzog2q/kfY 5KV6Kh+qjCmTj4K80WvTCeaihKDDgBdqqx8ISuhQgXNXHo27f7HQuqfvEvbc1vNsj1Vx QHpuur68hr3bnvy/FMyj9XNqJ/hTlOgCcfObh8w2b09rJImf83N3whPmnYm/rfZ3UThg O2ChZtps9ycXpsxIEID7PIXrFJgr2aWIAnAvSXFyWeCYUmM4R/2K9oxL1LzXSe7MS9VM vWKfJq9Db/5giMqHL/RG46Aj79Z2aOV3F++/csHc658GphYmGJ+/MA1FmSdZSahzhX20 788A== X-Gm-Message-State: AIVw1125opc2If4ud8Fq/3/muH3Be/hJwGtlFaNRplG4JMbZjQ3fzy6E X1DmUSUljRVqWlEW68NwItJcgoTxZg== X-Received: by 10.101.77.6 with SMTP id i6mr11245228pgt.181.1501371554150; Sat, 29 Jul 2017 16:39:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.138.68 with HTTP; Sat, 29 Jul 2017 16:39:13 -0700 (PDT) From: Greg Mirsky Date: Sat, 29 Jul 2017 16:39:13 -0700 Message-ID: To: "rtg-bfd@ietf.org" , "mpls@ietf.org" , spring@ietf.org Content-Type: multipart/alternative; boundary="089e08238004293d1105557d4efa" Archived-At: Subject: [spring] New draft on use of BFD Demand mode over MPLS p2p LSP X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 23:39:17 -0000 --089e08238004293d1105557d4efa Content-Type: text/plain; charset="UTF-8" Dear All, the new draft, draft-mirsky-bfd-mpls-demand , was presented at MPLS WG meeting in Prague. The draft proposes how the BFD Demand mode can be used over MPLS p2p LSP. One of use cases that likely benefit from the described procedures, in my opinion, is when multiple BFD sessions established for the same FEC between the same pair of BFD nodes, e.g. ECMP scenario, as described in RFC 7726. Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --089e08238004293d1105557d4efa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
the new draft,=C2=A0draft-= mirsky-bfd-mpls-demand, was , Shraddha Hegde , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nuokzsm0yt5P0y/+D1uKMVbQqJNamsAgAZpFICACngugIAENtLAgAaTbgCAAHi3gIAAbspggAROIOA= Date: Mon, 31 Jul 2017 16:55:20 +0000 Message-ID: <5558_1501520121_597F60F9_5558_28_1_53C29892C857584299CBF5D05346208A4782EC0E@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> <7512_1501238577_597B1531_7512_443_1_53C29892C857584299CBF5D05346208A47828C93@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> In-Reply-To: <4599cc42d1a54019a2c36ef53acf5be3@XCH-ALN-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A4782EC0EOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 16:55:30 -0000 --_000_53C29892C857584299CBF5D05346208A4782EC0EOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Les, From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, July 29, 2017 12:25 AM To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Bruno - Please reread "Section 3.7. Guaranteeing Database Consistency.". The draft is explicit that "entries advertised by all routing protocols MUS= T be included". [Bruno] ok, thanks. Also please read my recent response to Shraddha as regards the pitfalls of= using protocol specific databases for conflict resolution. [Bruno] Do we agree on the problems arising when running the conflict resolution ac= ross multiple databases? (point 2.b below; in short as different nodes may = run a different set of LSDBs, we can't reach consistent resolution) I belie= ve so since you acknowledged the problem for the specific case of L1L2 node= s running 2 LSDBs. I'm not sure that we can easily solve this problem, so at this stage, the a= lgorithm seems good enough to me. However, IMHO the document should acknowl= edge the problem (e.g. in section 3.7) for network operators to be aware o= f this issue and possibly provides some operational recommendation to minim= ize this. e.g. - during IGP migrations, if not all nodes runs both IGPs, only advertise SI= D in a single IGP (the one used by all nodes). - if applicable, prefer the flooding of SRMS advertisements across all areas ... > What is lacking in the draft is a statement that conflicting SIDs should = not be leaked out of an area Good point, thanks. If conflicting SIDs are re-advertised in L2 from multiple ABRs, there may b= e a risk of oscillations as both ABR withdraw and then re-advertise the SID= . Possibly a tie break may help (or whatever option) Thanks, Regards, --Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, July 28, 2017 3:43 AM To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Always as an individual contributor, thanks to Shraddha comments, a few poi= nt below 1) Conflict resolution per LSDB or across LSDB I've haven't re-read all text, but I'm not certain that the current text sp= ecifies whether the conflict resolution must be run on a per LSDB basis, or= across all LSDB. I think we'll agree that we all implementation be consist= ent on this point, hence this need to be specified. 2) Conflict resolution per LSDB or across LSDB ? I believe Les means across LSDB but Shraddha raised interesting questions r= egarding this, using area/level or IGP transitioning use cases. a) Thesis: On the "per LSDB" side: Running conflict resolution on a per LSDB ensure that this conflict resolut= ion runs on the same data, which is required to get the same result. Otherw= ise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topolo= gies) we have inconsistencies. b) Antithesis: On the "across LSDB" side: We need consistency across the network, hence across LSDBs. c) Synthesis We seem to have a tradeoff issue as we can't have both. However, it seems t= o me that the consistency issue with different LSDB is not specific to SR c= onflict resolution. We can have it with regular IP routing/forwarding. Henc= e this may favor enforcing consistency within LSDB which we can still enfor= ce. Some (two) details inlined [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde Sent: Friday, July 28, 2017 5:31 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network. Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network. In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement. [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= >From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic [Bruno] I'm not sure to undertand what is meant by "level/area agnostic". I= n IS-IS, SRMS advertisements seems to be able to be scoped on a per area/le= vel basis using the S-flag https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#s= ection-2.4 - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. [Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area= or not. If it does, it could take into account both SIDs: incoming label f= rom the SID of the incoming area, outgoing label from the SID of the outgoi= ng area. Not that different from LDP which select the label on a per neighb= or basis...even though LDP does not do routing i.e. does not natively have = this information. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR that > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > >> > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A4782EC0EOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Les,

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Saturday, July 29, 2017 12:25 AM
To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Bruno &= #8211;

 <= /span>

Please = reread “Section 3.7.  Guaranteeing Database Consistency.”.=

The dra= ft is explicit that “entries advertised by all routing protocols MUST= be included”.

 [Bruno] ok, thanks.<= /o:p>

&n= bsp;

Also pl= ease read my recent response to  Shraddha as regards the pitfalls of u= sing protocol specific databases for conflict resolution.

 [Bruno]=

Do we agree on the problems ari= sing when running the conflict resolution across multiple databases? (point= 2.b below; in short as different nodes may run a different set of LSDBs, w= e can’t reach consistent resolution) I believe so since you acknowledged the problem for the specific case of L= 1L2 nodes running 2 LSDBs.

I’m not sure that we can = easily solve this problem, so at this stage, the algorithm seems good enoug= h to me. However, IMHO the document should acknowledge the problem (e.g. in= section 3.7)  for network operators to be aware of this issue and possibly provides some operational recommendation = to minimize this. e.g.

- during IGP migrations, if not= all nodes runs both IGPs, only advertise SID in a single IGP (the one used= by all nodes).

- if applicable, prefer the flo= oding of SRMS advertisements across all areas

…

 

>= ; What is lacking in the draft is a statement that conflicting SIDs should = not be leaked out of an area=

Good point, thanks.<= /span>

If conflicting SIDs are re-adve= rtised in L2 from multiple ABRs, there may be a risk of oscillations as bot= h ABR withdraw and then re-advertise the SID. Possibly a tie break may help= (or whatever option)

 

Thanks,

Regards,

--Bruno

 

&n= bsp;

 &= nbsp;  Les

 <= /span>

 <= /span>

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Always = as an individual contributor, thanks to Shraddha comments, a few point belo= w

 <= /span>

1) &nbs= p;    Conflict resolution per LSDB or across LSDB

I’= ;ve haven’t re-read all text, but I’m not certain that the curr= ent text specifies whether the conflict resolution must be run on a per LSD= B basis, or across all LSDB. I think we’ll agree that we all implementation be consistent on this point, hence this need to be spec= ified.

 <= /span>

 <= /span>

2) &nbs= p;    Conflict resolution per LSDB or across LSDB ?<= o:p>

I belie= ve Les means across LSDB but Shraddha raised interesting questions regardin= g this, using area/level or IGP transitioning use cases.

a) &nbs= p;    Thesis: On the “per LSDB” side:

Running= conflict resolution on a per LSDB ensure that this conflict resolution run= s on the same data, which is required to get the same result. Otherwise, as= per Shraddha’s points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

 <= /span>

b) &nbs= p;    Antithesis: On the “across LSDB” side:

We need= consistency across the network, hence across LSDBs.

 <= /span>

c) &nbs= p;     Synthesis

We seem= to have a tradeoff issue as we can’t have both. However, it seems to= me that the consistency issue with different LSDB is not specific to SR co= nflict resolution. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within L= SDB which we can still enforce.

 <= /span>

 <= /span>

Some (t= wo) details inlined [Bruno]

 <= /span>

From: spring [ma= ilto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks = for the response.

 <= /span>

 &= nbsp; It is important  to keep the network functioning correctly in ca= se of transitioning from

 &= nbsp; one protocol to the other.

 &= nbsp;

 &= nbsp; Let us assume a case of OSPF SR network transitioning to ISIS SR= network.

 &= nbsp; Most typical transitioning technique is ships in the night where both= protocols will be

 &= nbsp; enabled in the network with OSPF having better preference and th= e issue in ISIS routing do

 &= nbsp; not affect the traffic. Once the ISIS deployment is complete, the tra= ffic will be switched

 &= nbsp; to ISIS by changing preference.

 &= nbsp;

 &= nbsp; In case of OSPF-SR transitioning to ISIS SR, because of the conf= lict resolution

 &= nbsp; rules that the conflicts are protocol independent, it is possibl= e that config mistakes in ISIS

 &= nbsp; will bring down the routes in OSPF. The ISIS topology and OSPF topolo= gy is not expected to be congruent

 &= nbsp; during transition,

 &= nbsp; so the conflicts seen on each node combining the two views will not b= e similar.

 &= nbsp; This has potential to cause routing loops/ traffic drops in the = network.

 &= nbsp;

 &= nbsp; I suggest to add the protocol-preference as one of the parameter= s in the preference algorithm

 &= nbsp; with this being on the top of the list.

 &= nbsp; The resultant conflict resolution will be consistent on ISIS topology= and OSPF topology

 &= nbsp;and is the best suited model for ships in the night transitions.

 <= /span>

Pls see= inline for other responses.<= /p>

 <= /span>

Rgds

Shraddh= a

 <= /span>

 <= /span>

From: Les Ginsberg (ginsberg) [= mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -=

 

Thanx for the comments - res= ponses inline.

 

> -----Original Message--= ---

> From: spring [mailto:spring-bounces@ietf.org] On = Behalf Of Shraddha Hegde

> Sent: Thursday, July 20= , 2017 11:44 PM

> To: spring@ietf.org

> Subject: Re: [spring] W= G Last Call for draft-ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is = an important problem to solve and it is important to

> Standardize this draft.=

>

> I generally support the= draft but have a few major comments which I hope

> the authors will work o= n.

>

>

>  1.Conflict resolu= tion and forwarding

>

>    =          Section 3.4 has the statem= ent

>    =          "Active Entries in th= e database may be used in forwarding."

>

>    =           This is a very loose= statement which does not enforce

> implementations to prog= ram the forwarding plane

>     = ;        with the active database entrie= s.

>     = ;        This does not ensure traffic dr= ops are minimized.

>

= [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" ent= ries will be used . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated wit= h a prefix which is not actually reachable. So the language in the draft is= intentional and is correct.=

<Shraddha> The language in the draft is ambiguous and it does not h= elp achieve consistent forwarding behavior across implementations.

            &= nbsp;         Prefixes that are not= reachable may not be used in forwarding which is acceptable but the draft = does not mandate that the reachable prefixes which are active

            &= nbsp;       MUST be programmed. Normative lan= guage is necessary in the draft w.r.t using active entries in forwarding.

 

 =

>     = ;        The Forwarding plane programmin= g aspects are completely missing in

> the document.

>     = ;        A separate section is needed wh= ich describes the different aspects

> of programming the forw= arding plane.

 

[Les:] This is NOT in = scope for this draft. If you want a description of how SR MPLS forwarding w= orks please see draft-ietf-spring-segment-routing-mpls.

 

<Shraddha> The point I am bringing up here is not how SR MPLS forwa= rding works. It is w.r.t to programming the forwarding plane when there is = a conflict.

            &= nbsp;         

The abstract section has below statement

 

&#=
8220;In cases where the=

   information advertised by a given protocol insta=
nce is either
   internally inconsistent or conflicts with advert=
isements from another
   protocol instance a means of achieving consisten=
t forwarding behavior
   in the network is required.”
 
If the draft is not=
 going to address the forwarding plane detail w.r.t conflicting entries it =
is definitely not meeting the
The objective descr=
ibed above.
 
Take an example of =
a conflict
(192, 192.0.2.1/32,=
 200, 1, 0, 0)
   (192, =
192.0.2.222/32, 200, 1, 0, 0)
   SID 20=
0 has been assigned to 192.0.2.1/32 by the
   first =
advertisement.
   The se=
cond advertisement assigns SID 200 to 192.0.2.222/32.
 
In this case after =
applying the preference rules
(192, 192.0.2.1/32,=
 200, 1, 0, 0)
 Becomes active ent=
ry.
 
As per the text in =
the draft,” it may be used in forwarding” so some implementatio=
ns
May choose to progr=
am forwarding plane and some may not which does not give a consistent forwa=
rding behavior
Across implementati=
ons.
 
 

 

 

>

> 2.  Protocol indep= endent resolution and impact on network migrations

>    =           In case of network m= igration from one protocol to other for ex: OSPF-

> SR to ISIS-SR,

>    =           it is useful to asso= ciate protocol preferences on a local node to the SID

> advertisement

>     = ;        and feed into the conflict reso= lution. This would make sure the

> conflicts will always

>     = ;        have a winner which is an adver= tisement from protocol with

> preferred admin-distanc= e.

>

>     = ;        There is need for introducing a= nother preference value specific to

> protocol preference

>     = ;        and make it the top rule in the= preference rule hierarchy.

>

 

[Le= s:] "admin distance" is a locally defined preference which is not= advertised. It is therefore not possible to include it as a parameter in a= n algorithm which requires a consistent answer on all nodes throughout the network.=

&= nbsp;

<Shraddha> &n=
bsp;In migration cases, topologies across two different protocols are not c=
ongruent causing inconsistent behavior.=

   &=
nbsp;           &nbs=
p;       Using admin-distance as an input par=
ameter keeps the conflict resolution with-in the protocol and guarantees
   &=
nbsp;           &nbs=
p;      Consistent behavior across all the nodes c=
orresponding to that protocol.
 
   &=
nbsp;           &nbs=
p;     The drafts tries to address this scenario p=
artially between IGP and BGP by suggesting preference values. But that does=
 not solve the
Problem between two=
 different IGPs. 

 


 =



>     =
;        This would also solve the issue=
 of MT-ID numbers being different in


> different protocols


>     =
;        as the SIDs would be compared w=
ithin a protocol advertisement.


 


[Les:] I do not unders=
tand what relationship you see between "protocol preference" and =
"MT-ID".


MT-ID values are scope=
d by  the protocol which uses them. For example, OSPFv2 supports a 7 b=
it MT-ID while IS-IS supports a 12 bit MT-ID. It is therefore possible for =
non-matching MTIDs to be used by different
 protocols when advertising routes for the same physical topology. This is =
why the draft's use of "topology" is not as MTID but rather as a =
locally scoped identifier. >From Section 3:


 <=
span lang=3D"EN-US">


" Note: Topology is a locally scoped identifier assigned by eac=
h


   router.  Although it may have an association with =
Multitopology


   Identifiers (MTID) advertised by routing protocols it i=
s NOT


   equivalent to these identifiers.  MTIDs are scoped=
 by a given routing

   protocol.  MTID ranges are protocol specific and t=
here may be


   standardized protocol specific MTID assignments for top=
ologies of a


   specific type (e.g., an AFI specific topology).  A=
s mapping entries


   can be sourced from multiple protocols it is not possib=
le to use a


   network scoped identifier for a topology when storing m=
apping entries


   in the local database."


 <=
span lang=3D"EN-US">


Topology is then used =
to detect different scopes for a mapping entry - which may result in a SID =
conflict if the same SID is used in different topologies, but it cannot be =
used as a tiebreaker since its value
 is local and any preference (e.g., higher value wins)  is not guarant=
eed to result in consistent answers on all nodes in the network. Which is w=
hy we have Section 3.3 Rule #8:


 <=
span lang=3D"EN-US">


   "8.  If topology IDs are NOT identical both e=
ntries MUST be ignored"=



<=
Shraddha> Lets keep this discussion on-hold until we decide on the proto=
col preference and migration issues.=



 


> 


> 3. In case of hierarchi=
cal IGP networks with multiple ISIS Levels or OSPF areas,=



> It's possible that the<=
o:p>


>    =
  conflicts are not visible in entire domain but are visible only on t=
he border


> router as the border ro=
uters


>    =
  have the database of both domains.


>    =
 The conflict resolution preference Rules should be enhanced to include the=



> Level information in th=
e preference rule.


>    =
 A new parameter called sub-domain should be defined.


> 


>     =
;            &n=
bsp;           One could =
propose using existing SRMS preference values


> and assigning prefixes =
with preference values


>     =
;        based on levels they are advert=
ised in. This introduces more complex


> configuration requireme=
nts on the


>     =
;        network. The objective of this =
draft is to achieve consistent


> behaviours in case of m=
isconfigurations and


>     =
;        introducing more configurations=
 as a solution does not help.


> 


> 


>     =
;            &n=
bsp;           Based on t=
he Advertisement originated in ISIS Level or OSPF


> area below values are d=
efined.


> 


>     =
;            &n=
bsp;           Level 1 , =
non-zero OSPF area =3D1


>     =
;            &n=
bsp;           Level 2, O=
SPF Area 0 =3D 2


>     =
;            &n=
bsp;           Non IGPs s=
et subdomain =3D 0


> 


>     =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      Preference algorithm is changed as


> 


>    =
 1. Higher protocol preference wins


=
 


=
[Les:] I have explained above why protocol preference cannot be used.


 =



>    2. sm=
aller sub-domain wins


>    =
 3. Higher srms preference value wins


>    =
 4. Smaller range wins


>    =
 5.IPv6 entry wins over IPv4 entry


>    =
 6.Longer prefix length wins


>    =
 7.Smaller starting address (considered as an unsigned integer


>    =
    value) wins


>    =
 8.Smaller algorithm wins


>    =
 9. Smaller topology Id wins >>>>>>>>>>..Move=
d above SID comparison.


> since the all these rul=
es are applied


>     =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;         within protocol =
it's safe to compare topology IDs


=
[Les:] No – it isn’t – as explained above.=



>    =
 10. Smaller starting SID wins


> 


=
[Les:] SIDs are assigned either by the node(s) originating the prefix reach=
ability advertisement or by SRMS advertisements. The latter are level/area =
agnostic


[Bruno] I’m not sure to undertand what is meant by “level/are=
a agnostic”. In IS-IS, SRMS advertisements seems to be able to be sco=
ped on a per area/level basis using the S-flag


https://tools.ietf.org/html/draft-ietf-isis-segmen=
t-routing-extensions-13#section-2.4=



 


=
- and even you are agreeing that we should not change that.<=
span lang=3D"EN-US">


=
There is then no reason for the SID to be altered as it is advertised into =
different areas.  Which leads us to the conclusion that SIDs are not l=
evel/area specific.

=
 


=
If your concern is that border routers who may have more entries in their S=
ID database than intra-area routers may come to a different conclusion as r=
egards conflicts - I agree with you -
 but I do not believe your proposal resolves the problem.


=
Consider the following simple topology:=



=
 


=
A1-----A2------B2-----B1


=
 


=
All nodes run IS-IS.<=
/p>

=
A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100<=
/i>


=
A2 is a Level-1-2 router in Area A=



=
 


=
B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100<=
/i>


=
B2 is a Level-1-2 router in Area B=



=
 


=
If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav=
e the following SID databases on the four routers:


 =









A1<=
/p>




1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









B1<=
/p>




2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=



2.2.2.2/32 100=









 =



 =



Her=
e are the active entries on each node comparing the two algorithms


 =









Node




Draft Algorithm




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









A2<=
/p>




1.1.1.1/32 100=





1.1.1.1/32 100=









B1<=
/p>




2.2.2.2/32 100=





2.2.2.2/32 100=









B2<=
/p>




1.1.1.1/32 100=





2.2.2.2/32 100=









 =



=
There is a tradeoff here between being able to forward some inter-area traf=
fic entering the network via the L2 sub-domain but impacting some intra-are=
a traffic  vs being able to forward all
 intra-area traffic but no inter-area traffic.


[Bruno] For MPLS transit, the ABR knows whether the traffic leaves the ar=
ea or not. If it does, it could take into account both SIDs: incoming label=
 from the SID of the incoming area, outgoing
 label from the SID of the outgoing area. Not that different from LDP which=
 select the label on a per neighbor basis…even though LDP does not do=
 routing i.e. does not natively have this information.


=
Not clear which strategy is “better” – but it is clear th=
at neither strategy eliminates all issues. Given that the same SID database=
 will NOT exist on all routers in multi-area deployments
 some risk exists and cannot be totally eliminated.


=
 


=
I do agree that we should try to minimize the use of conflicting SIDs for i=
nter-area traffic. What is lacking in the draft is a statement that conflic=
ting SIDs should not be leaked out of
 an area. I will work on a statement in the draft to make that point clear.=



 


<Shraddha> No=
t leaking the conflicting SIDs makes sense. But Even if the conflicting SID=
s are not leaked across boundaries, there is still a possibility that inter=
-area/intra-area traffic gets misforwarded at the area boundary. This issue=
 can cause potential security risks as the traffic can get delivered to uni=
ntended node.The best option is to ignore both conflicting entries when the=
y belong to different area/level


 


   &=
nbsp; 1. Higher protocol preference wins


    =
2. If the entries belong to different sub-domains ignore both entries


   &=
nbsp; 3. Higher srms preference value wins


   &=
nbsp; 4. Smaller range wins<=
/span>


   &=
nbsp; 5.IPv6 entry wins over IPv4 entry=



   &=
nbsp; 6.Longer prefix length wins<=
/o:p>


   &=
nbsp; 7.Smaller starting address (considered as an unsigned integer<=
/i>


   &=
nbsp;    value) wins


   &=
nbsp; 8.Smaller algorithm wins


   &=
nbsp; 9. Smaller topology Id 


   &=
nbsp;10. Smaller starting SID wins=



 


 


 


=
Thanx for bringing this issue up.<=
/o:p>


=
 


=
    Les


 =



> 


> 


> Rgds<=
/p>

> Shraddha


> 


> -----Original Message--=
---


> From: Martin Horneffer =
[mailto:maho@nic.dtag.de]


> Sent: Friday, July 14, =
2017 8:22 PM


> To: 
spring@ietf.org


> Subject: Re: [spring] W=
G Last Call for draft-ietf-spring-conflict-resolution


> 


> Strong support from me,=
 too.


> 


>  From an operator'=
s point of view this is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 sc=
hrieb Martin Vigoureux:


> ><=
/p>

> > WG,


> ><=
/p>

> > We are half-way th=
rough the WG Last Call and I am very surprised to


> > only see a single =
answer to it.


> ><=
/p>

> > I am not sure I'll=
 move this forward with only silence as support.


> ><=
/p>

> > -m


> ><=
/p>

> > Le 29/06/2017 =E0 =
15:28, Martin Vigoureux a =E9crit :


> >> Hello Working =
Group,


> >>


> >> This email sta=
rts a Working Group Last Call on


> >> draft-ietf-spr=
ing-conflict-resolution-04 [1] which is considered


> >> mature and rea=
dy for a final working group review.


> >>


> >> =A4 Please rea=
d this document if you haven't read the most recent


> >> version yet, a=
nd send your comments to the list, no later than *21st


> >> of July*.=



> >> Note that this=
 is *not only* a call for comments on the document; it


> >> is also a call=
 for support (or not) to publish this document as a


> >> Proposed Stand=
ard RFC.


> >>


> >> =A4 *Coinciden=
tally*, we are also polling for knowledge of any IPR that=



> >> applies to dra=
ft-ietf-spring-conflict-resolution, to ensure that IPR


> >> has been discl=
osed in compliance with IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 =
for more details).


> >>


> >> If you are lis=
ted as an Author or Contributor of


> >> draft-ietf-spr=
ing-conflict-resolution-04 please respond to this email

> >> and indicate w=
hether or not you are aware of any relevant IPR.


> >>


> >> Note that, as =
of today, no IPR has been disclosed against this


> >> document or it=
s earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]=



> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/<=
/span>


> >>


> >> ______________=
_________________________________


> >> spring mailing=
 list


> >> 
spring@ietf.org


> >> 
https://www.ietf.org/=
mailman/listinfo/spring


> >>


> ><=
/p>

> > __________________=
_____________________________


> > spring mailing lis=
t


> > spri=
ng@ietf.org


> > 
https://www.ietf.org/=
mailman/listinfo/spring


> ><=
/p>

> 


> 


> _______________________=
________________________


> spring mailing list


> spring@ie=
tf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring


_=
___________________________________________________________________________=
_____________________________________________
&=
nbsp;
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc<=
/o:p>
p=
as etre diffuses, exploites ou copies sans autorisation. Si vous avez recu =
ce message par erreur, veuillez le signaler
a=
 l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
&=
nbsp;
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.=

I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.<=
/span>
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A4782EC0EOPEXCLILM21corp_-- From nobody Mon Jul 31 10:26:46 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE471326D7 for ; Mon, 31 Jul 2017 10:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 BgFCSmoea9H0 for ; Mon, 31 Jul 2017 10:26:37 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0109.outbound.protection.outlook.com [104.47.38.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BEE61326EE for ; Mon, 31 Jul 2017 10:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EBSgW41CZDyWW8FDlIEwsCJg2TIqKsVVhs7UrOLmDxI=; b=NO0K1pFTMUf5752JiB4F96SWAVgLKcRJe+yrUuZqXWUSfoyO2eOr1sbLgef9lmWs7x1zMf+sPdweCerJz98P64r+rnS59WwGz2f22Vk3ET9zdbJH/ODd1/pfXF4UnNbg18HGQPuZYm4bx7LfMsMcTgNHf/spiuOct2i43ajZx1o= Received: from CY1PR05MB2714.namprd05.prod.outlook.com (10.167.18.8) by CY1PR05MB1978.namprd05.prod.outlook.com (10.162.216.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Mon, 31 Jul 2017 17:26:35 +0000 Received: from CY1PR05MB2714.namprd05.prod.outlook.com ([10.167.18.8]) by CY1PR05MB2714.namprd05.prod.outlook.com ([10.167.18.8]) with mapi id 15.01.1320.010; Mon, 31 Jul 2017 17:26:35 +0000 From: Shraddha Hegde To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS/NN8VkET5jeHE0aVgjgvlbOfdqJd3UHwgAWfiQCABAJAYIACZicAgAReXrA= Date: Mon, 31 Jul 2017 17:26:34 +0000 Message-ID: References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> In-Reply-To: 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=shraddha@juniper.net; x-originating-ip: [116.197.184.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR05MB1978; 6:iltwDgtQ3I8yxLWhUVNCJdYle6UI7cjBx9wN2YzQhUxMMgSK/w09oLS1FUYucKcahAfNzf394QLfp/Cj5iTS80PwnjZhF3GFKu6LU7JjHm+tjtRchP+RigxZ9yPnz2XPS8KA2kU5B5dbDsRtJNX4Q1ZGV9gsZ8n1IL2Z8mUYJKaV/dE6nhEzIsy+lwbKID7495sXRnQ4CEN/J7ybBoI3EYBUbZkUU5xEORMlEY+bczbYMHlnobPj2seUTLHGqs6t9qilKHJZK58017HaM1IaqUDie9tXX3UDevylKhFHuAA9czI2gHQcaGhGJk88PBLrzf66mINIUWoltx3bAfkZUg==; 5:osK521TkPFmRK6HO8UIR2VzvVx0YfG1PGPKmLLx++0GEyXiGT9/qGc46soKXM61wozgIfR4oiTbIbeJ+Ks1ewWN+Qtw5RIKuidKSQVRsEujPgCwsOUx7GBJ9FTG6QUQFjFgTS+xn6ww142PS8WjRGA==; 24:jaB+SqQds8bGi+BZpjhbP6Ese59JL/lmZp+qUKSJ7ESg242a1BT7t2lCEHoNZzsk4K60HUPXOCw2zmfpS50Y7N3HzfZ6wYSv1DKGXCL/6jk=; 7:v3QA/rziiy3H2Z2SzWdVa+ZMaZ/FTExZiQ4RNcTOjyJsZwSk11nUrq6HwjGzqkjqWMU3rW8+leqSCnrF5vHR7QIsQ6ryoR/cL/DpOgfudTLyHJchPh/YTeWrkOZgA+vRUl1i7H4javvIk24nq9/rXEZOBPxC81W6La+jMf68HMUHtyOJMUH+cvL2e5I/gWY1x0+3TYDFH4a1OpRWBz5V+yNmPIdNDwOCsl9rrnWDA44= x-ms-office365-filtering-correlation-id: 6340bdaa-ac26-4910-c58a-08d4d8394b15 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB1978; x-ms-traffictypediagnostic: CY1PR05MB1978: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(138986009662008)(95692535739014)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB1978; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB1978; x-forefront-prvs: 03853D523D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39860400002)(39400400002)(39410400002)(39850400002)(39840400002)(189002)(51914003)(377454003)(13464003)(199003)(74316002)(2501003)(68736007)(33656002)(16200700003)(53946003)(230783001)(790700001)(236005)(606006)(14454004)(966005)(3846002)(38730400002)(6246003)(102836003)(3280700002)(6116002)(3660700001)(6436002)(86362001)(53936002)(53546010)(2906002)(55016002)(99286003)(6306002)(9686003)(54896002)(19609705001)(97736004)(189998001)(106356001)(561944003)(101416001)(25786009)(8676002)(81156014)(81166006)(54356999)(76176999)(105586002)(50986999)(2950100002)(6506006)(478600001)(229853002)(66066001)(5660300001)(2900100001)(7696004)(77096006)(93886004)(7736002)(8936002)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB1978; H:CY1PR05MB2714.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR05MB271449E326A6C6686520140FD5B20CY1PR05MB2714namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2017 17:26:34.9129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB1978 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 17:26:43 -0000 --_000_CY1PR05MB271449E326A6C6686520140FD5B20CY1PR05MB2714namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Les, When the protocol preference is different across different nodes OSPF and I= SIS do not guarantee that there would not be traffic loops/drops. The misconfigurations can cause traffic loops when the different protocols = are active on different nodes even without SR so I don't see a point In bringing up such a case for comparison. Lets keep the solution to the problem aside for a moment. Do you agree that= the draft algorithm in current form has potential issues When database is not consistent across all nodes? Do you think this is a pr= oblem we should try to solve? Pls see inline for details... Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, July 29, 2017 3:48 AM To: Shraddha Hegde ; spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Shraddha - Protocol preference (commonly known as admin distance) is a locally configu= red value which is not advertised. Therefore there is no way for one node t= o know what preference another node has assigned to different protocols. If= admin distance is used as part of the conflict resolution algorithm there = is therefore no way to guarantee consistency on different nodes. I have po= inted this out previously - you have not acknowledged this. Let's use your example below - transitioning a network from OSPF to IS-IS = - to show how using admin distance in the conflict resolution algorithm res= ults in inconsistency. Consider the following simple network: A---B---C---D Node A originates the prefix 1.1.1.1/32. The network is using OSPF and OSPF is advertising SID 100 for 1.1.1.1. All = nodes use SID 100 in their forwarding planes. The customer wants to transition to IS-IS, and so starts configuring IS-IS = on each node, but makes sure that initially the admin distance assigned to= IS-IS is greater than (less preferred) than that of OSPF. In configuring IS-IS the customer makes a mistake and assigns SID 200 to 1.= 1.1.1. (This presumes a protocol centric model for configuring SIDs - whic= h I do not recommend - but let's ignore that for now.) The customer is now ready to switch the network to IS-IS and starts to do s= o by changing the admin distance of IS-IS on Node D to be more preferred. Using your proposal, Node D would now choose SID 200 as the Active SID for = prefix 1.1.1.1. But on Node C, OSPF is still the more preferred protocol, so on Node C SID = 100 is being used for 1.1.1.1. As I pointed out different protocol being active on different no= des should be operator's responsibility and is not addressed Even when SR is not enabled. Whereas, it is important to make sure during migrati= on when only a few nodes have ISIS enabled, it does not impact OSPF. The draft algorithm does not gracefully handle this= and makes migrations much more painful by affecting the running network Due to misconfigs in the new protocol. As soon as the admin distance change is made on Node D, the label associate= d with SID 200 will be programmed in forwarding to send traffic addressed t= o 1.1.1.1 via Node C. But in Node C's forwarding plane SID 100 is being used, so when the packet = arrives at Node C it will get dropped. Contrast that with the behavior when using algorithm currently defined in = the draft. In the presence of the two conflicting advertisements: (192, 1.1.1.1/32, 100, 1, 0, 0) (192, 1.1.1.1/32, 200, 1, 0, 0) SID 100 will be declared the winner (Rule #7: Lower SID wins) This will be true regardless of which protocol is the "best" at any moment = in time on any node. So even when IS-IS becomes the winning protocol on Nod= e D the forwarding plane continues to use SID 100 on all nodes. Therefore, = forwarding is not compromised when transitioning from one protocol to anoth= er. You have chosen a situation that is favoring the algorithm in th= e draft. Consider (192, 1.1.1.1/32, 200, 1, 0, 0) >>>>>>>>>>>>OSPF (192, 1.1.1.1/32, 100, 1, 0, 0) >>>>>>>>>>>>ISIS Consider when the customer has configured ISIS on on= ly a few nodes. On some nodes ISIS advertisement wins and uses 100 to forwa= rd but Gets dropped on next node as ISIS isn't running . Of course, a far better strategy is to make SID configuration independent o= f the protocol. Then when introducing a new protocol both protocols would o= btain and advertise the same SID value for the same prefix and the problem = state described above would simply never occur. There are so many nuances to migration. One protocol doesn't beh= ave same as the other simply because these are two different implementation= s and would have some different behaviors. It is always a best practice to = keep the new protocol getting configured separate from the existing protoco= l, bring up the new protocol , verify all is well and then switchover to ne= w protocol on all nodes. In this regard some may prefer keeping the SIDs ad= vertised in two protocols separate and so its important to address the case= when different SIDs are advertised in the protocol. HTH clarify why your suggestion is not viable. Les From: Shraddha Hegde [mailto:shraddha@juniper.net] Sent: Thursday, July 27, 2017 8:31 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network= . Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network= . In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement= . [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR tha= t > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > >> > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --_000_CY1PR05MB271449E326A6C6686520140FD5B20CY1PR05MB2714namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Les,=

 

When the protocol pref= erence is different across different nodes OSPF and ISIS do not guarantee t= hat there would not be traffic loops/drops.

The misconfigurations = can cause traffic loops when the different protocols are active on differen= t nodes even without SR so I don’t see a point

In bringing up such a = case for comparison.

 

Lets keep the solution= to the problem aside for a moment. Do you agree that the draft  algor= ithm in current form has potential issues

When database is not c= onsistent across all nodes? Do you think this is a problem we should try to= solve?

 

Pls see inline for det= ails…

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsber= g@cisco.com]
Sent: Saturday, July 29, 2017 3:48 AM
To: Shraddha Hegde <shraddha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha –<= /o:p>

 

Protocol preference (c= ommonly known as admin distance) is a locally configured value which is not= advertised. Therefore there is no way for one node to know what preference= another node has assigned to different protocols. If admin distance is used as part of the conflict resolution al= gorithm there is therefore no way to guarantee consistency on different nod= es.  I have pointed this out previously – you have not acknowled= ged this.

 

Let’s use your e= xample below  - transitioning a network from OSPF to IS-IS – to = show how using admin distance in the conflict resolution algorithm results = in inconsistency.

 

Consider the following= simple network:

 

A---B---C---D

 

Node A originates the = prefix 1.1.1.1/32.

The network is using O= SPF and OSPF is advertising SID 100 for 1.1.1.1. All nodes use SID 100 in t= heir forwarding planes.

 

The customer wants to = transition to IS-IS, and so starts configuring IS-IS on each node, but make= s sure that initially  the admin distance assigned to IS-IS is greater= than (less preferred) than that of OSPF.

In configuring IS-IS t= he customer makes a mistake and assigns SID 200 to 1.1.1.1.  (This pre= sumes a protocol centric model for configuring SIDs – which I do not = recommend – but let’s ignore that for now.)

 

The customer is now re= ady to switch the network to IS-IS and starts to do so by changing the admi= n distance of IS-IS on Node D to be more preferred.

Using your proposal, N= ode D would now choose SID 200 as the Active SID for prefix 1.1.1.1.

But on Node C, OSPF is= still the more preferred protocol, so on Node C SID 100 is being used for = 1.1.1.1.

<Shraddha> As I poin= ted out different protocol being active on different nodes should be operat= or’s responsibility and is not addressed

    &n= bsp;            = ;      Even when SR is not enabled.

    &n= bsp;            = ; 

    &n= bsp;            = ;      Whereas, it is important to make sure = during migration when only a few nodes have ISIS enabled, it does not impac= t OSPF.

    &n= bsp;            = ;       The draft algorithm does not graceful= ly handle this and makes migrations much more painful by affecting the runn= ing network

    &n= bsp;            = ;        Due to misconfigs in the new pr= otocol.

 

As soon as the admin d= istance change is made on Node D, the label associated with SID 200 will be= programmed in forwarding to send traffic addressed to 1.1.1.1 via Node C.<= o:p>

But in Node C’s = forwarding plane SID 100 is being used, so when the packet arrives at Node = C it will get dropped.

 

Contrast that with the= behavior  when using algorithm currently defined in the draft. In the= presence of the two conflicting advertisements:

 

(192, 1.1.1.1/32, 100,= 1, 0, 0)

(192, 1.1.1.1/32, 200,= 1, 0, 0)

 

SID 100 will be declar= ed the winner (Rule #7: Lower SID wins)

This will be true rega= rdless of which protocol is the “best” at any moment in time on= any node. So even when IS-IS becomes the winning protocol on Node D the fo= rwarding plane continues to use SID 100 on all nodes. Therefore, forwarding is not compromised when transitioning from one proto= col to another.

<Shraddha> You have = chosen a situation that is favoring the algorithm in the draft.<= /span>

    &n= bsp;            = ;      Consider

    &n= bsp;            = ;        (192, 1.1.1.1/32, 200, 1, 0, 0)  >>>>>>>&g= t;>>>>OSPF

    &n= bsp;            = ;        (192, 1.1.1.1/32, 100, 1, 0, 0)=   >>>>>>>>>>>>ISIS

    &n= bsp;            = ;      Consider when the customer has configured I= SIS on only a few nodes. On some nodes ISIS advertisement wins and uses 100= to forward but

    &n= bsp;            = ;      Gets dropped on next node as ISIS isn&= #8217;t running .

 

 

Of course, a far bette= r strategy is to make SID configuration independent of the protocol. Then w= hen introducing a new protocol both protocols would obtain and advertise th= e same SID value for the same prefix and the problem state described above would simply never occur.=

 

<Shraddha> There are= so many nuances to migration. One protocol doesn’t behave same as th= e other simply because these are two different implementations and would ha= ve some different behaviors. It is always a best practice to keep the new protocol getting configured separate from the exi= sting protocol, bring up the new protocol , verify all is well and then swi= tchover to new protocol on all nodes. In this regard some may prefer keepin= g the SIDs advertised in two protocols separate and so its important to address the case when different SIDs are = advertised in the protocol.

 

HTH clarify why your s= uggestion is not viable.

 

   Les<= /o:p>

 

 

 

From: Shraddha Hegde [mailto:shraddha@juniper.net]
Sent: Thursday, July 27, 2017 8:31 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.<= /o:p>

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 

“In cases where the
   information advertised by a given protocol instance is ei=
ther
   internally inconsistent or conflicts with advertisements =
from another
   protocol instance a means of achieving consistent forward=
ing behavior
   in the network is required.”
 
If the draft is not going to address the forwardi=
ng plane detail w.r.t conflicting entries it is definitely not meeting the<=
o:p>
The objective described above.<=
/i>
 
Take an example of a conflict
(192, 192.0.2.1/32, 200, 1, 0, 0)
   (192, 192.0.2.222/32, 200, 1, 0, 0)<=
o:p>
   SID 200 has been assigned to 192.0.2=
.1/32 by the
   first advertisement.
   The second advertisement assigns SID=
 200 to 192.0.2.222/32.
 
In this case after applying the preference rules<=
o:p>
(192, 192.0.2.1/32, 200, 1, 0, 0)
 Becomes active entry.<=
/pre>

 


As per the text in the draft,” it may be us=
ed in forwarding” so some implementations

May choose to program forwarding plane and some m=
ay not which does not give a consistent forwarding behavior


Across implementations.=



 


 


 


 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 =



[Les:] "admin=
 distance" is a locally defined preference which is not advertised. It=
 is therefore not possible to include it as a parameter in an algorithm whi=
ch requires a consistent answer on all nodes throughout
 the network.


 


<Shraddha>  In migration cases, topolo=
gies across two different protocols are not congruent causing inconsistent =
behavior.


        &=
nbsp;           &nbs=
p;  Using admin-distance as an input parameter keeps the conflict reso=
lution with-in the protocol and guarantees


        &=
nbsp;           &nbs=
p; Consistent behavior across all the nodes corresponding to that protocol.=



 


        &=
nbsp;           &nbs=
p;The drafts tries to address this scenario partially between IGP and BGP b=
y suggesting preference values. But that does not solve the


Problem between two different IGPs. 


 


 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each

   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing


   pro=
tocol.  MTID ranges are protocol specific and there may be<=
/i>


   sta=
ndardized protocol specific MTID assignments for topologies of a=



   spe=
cific type (e.g., an AFI specific topology).  As mapping entries<=
/o:p>


   can=
 be sourced from multiple protocols it is not possible to use a<=
/i>


   net=
work scoped identifier for a topology when storing mapping entries


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.

> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have e=
xplained above why protocol preference cannot be used.


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No ̵=
1; it isn’t – as explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are=
 assigned either by the node(s) originating the prefix reachability adverti=
sement or by SRMS advertisements. The latter are level/area agnostic - and =
even you are agreeing that we should
 not change that.


There is then n=
o reason for the SID to be altered as it is advertised into different areas=
.  Which leads us to the conclusion that SIDs are not level/area speci=
fic.


 


If your concern=
 is that border routers who may have more entries in their SID database tha=
n intra-area routers may come to a different conclusion as regards conflict=
s - I agree with you - but I do not
 believe your proposal resolves the problem.


Consider the fo=
llowing simple topology:


 


A1-----A2------=
B2-----B1


 


All nodes run I=
S-IS.


A1 is a Level-1=
 router in Area A. It advertises: 1.1.1.1/32 SID 100<=
/b>


A2 is a Level-1=
-2 router in Area A


 


B1 is a Level-1=
 router in Area B. It advertises: 2.2.2.2/32 SID 100<=
/b>


B2 is a Level-1=
-2 router in Area B


 


If Level 1 rout=
es are leaked into Level 2 but NOT down into Level 1, we have the following=
 SID databases on the four routers:


 








A1<=
/p>




1.1.1.1/32 100








A2<=
/p>




1.1.1.1/32 100


2.2.2.2/32 100








B1<=
/p>




2.2.2.2/32 100








B2<=
/p>




1.1.1.1/32 100


2.2.2.2/32 100








 


 


Here are the activ=
e entries on each node comparing the two algorithms

 








Node




Draft Algorithm<=
/o:p>




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100




1.1.1.1/32 100








A2<=
/p>




1.1.1.1/32 100




1.1.1.1/32 100








B1<=
/p>




2.2.2.2/32 100




2.2.2.2/32 100








B2<=
/p>




1.1.1.1/32 100




2.2.2.2/32 100








 


There is a trad=
eoff here between being able to forward some inter-area traffic entering th=
e network via the L2 sub-domain but impacting some intra-area traffic =
 vs being able to forward all intra-area
 traffic but no inter-area traffic.


Not clear which=
 strategy is “better” – but it is clear that neither stra=
tegy eliminates all issues. Given that the same SID database will NOT exist=
 on all routers in multi-area deployments some risk exists
 and cannot be totally eliminated.


 


I do agree that=
 we should try to minimize the use of conflicting SIDs for inter-area traff=
ic. What is lacking in the draft is a statement that conflicting SIDs shoul=
d not be leaked out of an area. I will
 work on a statement in the draft to make that point clear.


 


<Shraddha> Not leaking the conflicting SIDs=
 makes sense. But Even if the conflicting SIDs are not leaked across bounda=
ries, there is still a possibility that inter-area/intra-area traffic gets =
misforwarded at the area boundary. This issue can cause potential security =
risks as the traffic can get delivered to unintended node.The best option i=
s to ignore both conflicting entries when they belong to different area/lev=
el


 


     1. Higher protocol prefe=
rence wins


    2. If the entries belong to di=
fferent sub-domains ignore both entries


     3. Higher srms preferenc=
e value wins


     4. Smaller range wins


     5.IPv6 entry wins over I=
Pv4 entry


     6.Longer prefix length w=
ins


     7.Smaller starting addre=
ss (considered as an unsigned integer


        value)=
 wins


     8.Smaller algorithm wins=



     9. Smaller topology Id <=
o:p>


    10. Smaller starting SID =
wins


 


 


 


Thanx for bring=
ing this issue up.


 


  &nb=
sp; Les


 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> spring mailing list


> >> =
spring@ietf.org


> >> 
https://www.ietf.org/=
mailman/listinfo/spring


> >>


> >


> > _______________________________________=
________


> > spring mailing list


> > spring@ietf.org


> > 
https://www.ietf.org/=
mailman/listinfo/spring


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring
--_000_CY1PR05MB271449E326A6C6686520140FD5B20CY1PR05MB2714namp_-- From nobody Mon Jul 31 12:32:19 2017 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A3213278D for ; Mon, 31 Jul 2017 12:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 KukpdiMy5ovn for ; Mon, 31 Jul 2017 12:32:13 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9225C1326DD for ; Mon, 31 Jul 2017 12:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=99420; q=dns/txt; s=iport; t=1501529533; x=1502739133; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=aYKGB5xDc9n3Nso9FJJwXBvWBkHYb3yhxBuaKsQqeYw=; b=FZIo/ruuthfQeOLz5DzGwsNR8BgwRLb2uTiSAqCX0sHSa+SLwh7KYsZl 7kIntUeBcStaQkPg3geKjQ7+gm+ZLkpiji0oOogwSPzTOSqi1fZ7uJTHr BolMiAn03D9lqUx29HQxYS1dxNSK/binJp6Wyke/jzNmFoB9f742E2uex U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAQAzhX9Z/4kNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm8+LWSBFAeOBo96gWuWCw6CAQMhAQqETE8ChAg/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAgEBARgBAhBBBAwHBAIBCBEBAwEBIQEGBycLFAMGCAIEARIIE4kwX?= =?us-ascii?q?AgQsEiLRAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiDTYFgAYIbgQyEQQESASY?= =?us-ascii?q?HGBAChTwFkTWGLIgOAodNgwJJiQSCFYVSg3iGZ5VxAR84WSYLdxVJhRYcgWd2h?= =?us-ascii?q?36BI4EOAQEB?= X-IronPort-AV: E=Sophos;i="5.41,304,1498521600"; d="scan'208,217";a="462603336" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jul 2017 19:32:10 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6VJWAM0020420 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Jul 2017 19:32:10 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Jul 2017 14:32:09 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Mon, 31 Jul 2017 14:32:09 -0500 From: "Les Ginsberg (ginsberg)" To: Shraddha Hegde , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-conflict-resolution Thread-Index: AQHS8Nuokzsm0yt5P0y/+D1uKMVbQqJNamsAgAZpFICACngugIAENtLAgAaTbgCAAN688IAEwcEA///KLAA= Date: Mon, 31 Jul 2017 19:32:09 +0000 Message-ID: <1fa1478b8945402eacf9acfd3a71b133@XCH-ALN-001.cisco.com> References: <9a7e19b3-7251-2b80-22f9-2045ac4370f8@nokia.com> <84c64d65-430d-9734-5936-235ffc1d0a79@nokia.com> <2307cf5c-f6cf-1862-78f4-b540a93ae7f2@nic.dtag.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.90.196] Content-Type: multipart/alternative; boundary="_000_1fa1478b8945402eacf9acfd3a71b133XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 19:32:18 -0000 --_000_1fa1478b8945402eacf9acfd3a71b133XCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Shraddha - All the rules defined in the draft are based on advertised values - which m= eans if two nodes have the same database and use the same set of rules they= will reach the same decision as regards conflict resolution. You cannot improve upon this by introducing a new rule based upon a value (= protocol administrative distance) which is neither guaranteed to be the sam= e on all nodes nor advertised. The only thing this accomplishes is to intro= duce the potential for further inconsistency. If we cannot agree on this, then all the rest of the details discussed belo= w do not matter. There is an important point - which the draft does explicitly state in Sect= ion 3.7: "In order to obtain consistent active entries all nodes in a network MUST have the same mapping entry database." The productive part of this thread is to highlight the ways in which databa= se inconsistency can occur. This cannot be completely eliminated, but we ca= n minimize this in a number of ways: 1)Reemphasize that a SID is a property of the prefix - NOT the protocol whi= ch advertises it This is fundamental to the SR architecture and is consistent with the way S= IDs are used in the forwarding plane. And it will eliminate the possibility= that two intra-area protocols use different SIDs for the same prefix. 2)Reduce the proliferation of "inactive" intra-area SIDs to other areas. While this is desirable, as Bruno noted in his recent reply, there is dange= r for oscillation if not done carefully. I am still thinking about how to c= orrectly specify this. 3)Perhaps the draft would benefit from some additional discussion of the wa= ys in which inconsistent databases can occur and what consequences they hav= e. (Bruno - I think this is what you are suggesting in your reply). I will also look into this. Les From: Shraddha Hegde [mailto:shraddha@juniper.net] Sent: Monday, July 31, 2017 10:27 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Les, When the protocol preference is different across different nodes OSPF and I= SIS do not guarantee that there would not be traffic loops/drops. The misconfigurations can cause traffic loops when the different protocols = are active on different nodes even without SR so I don't see a point In bringing up such a case for comparison. Lets keep the solution to the problem aside for a moment. Do you agree that= the draft algorithm in current form has potential issues When database is not consistent across all nodes? Do you think this is a pr= oblem we should try to solve? Pls see inline for details... Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, July 29, 2017 3:48 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Shraddha - Protocol preference (commonly known as admin distance) is a locally configu= red value which is not advertised. Therefore there is no way for one node t= o know what preference another node has assigned to different protocols. If= admin distance is used as part of the conflict resolution algorithm there = is therefore no way to guarantee consistency on different nodes. I have po= inted this out previously - you have not acknowledged this. Let's use your example below - transitioning a network from OSPF to IS-IS = - to show how using admin distance in the conflict resolution algorithm res= ults in inconsistency. Consider the following simple network: A---B---C---D Node A originates the prefix 1.1.1.1/32. The network is using OSPF and OSPF is advertising SID 100 for 1.1.1.1. All = nodes use SID 100 in their forwarding planes. The customer wants to transition to IS-IS, and so starts configuring IS-IS = on each node, but makes sure that initially the admin distance assigned to= IS-IS is greater than (less preferred) than that of OSPF. In configuring IS-IS the customer makes a mistake and assigns SID 200 to 1.= 1.1.1. (This presumes a protocol centric model for configuring SIDs - whic= h I do not recommend - but let's ignore that for now.) The customer is now ready to switch the network to IS-IS and starts to do s= o by changing the admin distance of IS-IS on Node D to be more preferred. Using your proposal, Node D would now choose SID 200 as the Active SID for = prefix 1.1.1.1. But on Node C, OSPF is still the more preferred protocol, so on Node C SID = 100 is being used for 1.1.1.1. As I pointed out different protocol being active on different no= des should be operator's responsibility and is not addressed Even when SR is not enabled. Whereas, it is important to make sure during migrati= on when only a few nodes have ISIS enabled, it does not impact OSPF. The draft algorithm does not gracefully handle this= and makes migrations much more painful by affecting the running network Due to misconfigs in the new protocol. As soon as the admin distance change is made on Node D, the label associate= d with SID 200 will be programmed in forwarding to send traffic addressed t= o 1.1.1.1 via Node C. But in Node C's forwarding plane SID 100 is being used, so when the packet = arrives at Node C it will get dropped. Contrast that with the behavior when using algorithm currently defined in = the draft. In the presence of the two conflicting advertisements: (192, 1.1.1.1/32, 100, 1, 0, 0) (192, 1.1.1.1/32, 200, 1, 0, 0) SID 100 will be declared the winner (Rule #7: Lower SID wins) This will be true regardless of which protocol is the "best" at any moment = in time on any node. So even when IS-IS becomes the winning protocol on Nod= e D the forwarding plane continues to use SID 100 on all nodes. Therefore, = forwarding is not compromised when transitioning from one protocol to anoth= er. You have chosen a situation that is favoring the algorithm in th= e draft. Consider (192, 1.1.1.1/32, 200, 1, 0, 0) >>>>>>>>>>>>OSPF (192, 1.1.1.1/32, 100, 1, 0, 0) >>>>>>>>>>>>ISIS Consider when the customer has configured ISIS on on= ly a few nodes. On some nodes ISIS advertisement wins and uses 100 to forwa= rd but Gets dropped on next node as ISIS isn't running . Of course, a far better strategy is to make SID configuration independent o= f the protocol. Then when introducing a new protocol both protocols would o= btain and advertise the same SID value for the same prefix and the problem = state described above would simply never occur. There are so many nuances to migration. One protocol doesn't beh= ave same as the other simply because these are two different implementation= s and would have some different behaviors. It is always a best practice to = keep the new protocol getting configured separate from the existing protoco= l, bring up the new protocol , verify all is well and then switchover to ne= w protocol on all nodes. In this regard some may prefer keeping the SIDs ad= vertised in two protocols separate and so its important to address the case= when different SIDs are advertised in the protocol. HTH clarify why your suggestion is not viable. Les From: Shraddha Hegde [mailto:shraddha@juniper.net] Sent: Thursday, July 27, 2017 8:31 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Thanks for the response. It is important to keep the network functioning correctly in case of tr= ansitioning from one protocol to the other. Let us assume a case of OSPF SR network transitioning to ISIS SR network= . Most typical transitioning technique is ships in the night where both pr= otocols will be enabled in the network with OSPF having better preference and the issue = in ISIS routing do not affect the traffic. Once the ISIS deployment is complete, the traffi= c will be switched to ISIS by changing preference. In case of OSPF-SR transitioning to ISIS SR, because of the conflict res= olution rules that the conflicts are protocol independent, it is possible that c= onfig mistakes in ISIS will bring down the routes in OSPF. The ISIS topology and OSPF topology = is not expected to be congruent during transition, so the conflicts seen on each node combining the two views will not be s= imilar. This has potential to cause routing loops/ traffic drops in the network. I suggest to add the protocol-preference as one of the parameters in the= preference algorithm with this being on the top of the list. The resultant conflict resolution will be consistent on ISIS topology an= d OSPF topology and is the best suited model for ships in the night transitions. Pls see inline for other responses. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 25, 2017 1:57 AM To: Shraddha Hegde >; spr= ing@ietf.org Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolutio= n Shraddha - Thanx for the comments - responses inline. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde > Sent: Thursday, July 20, 2017 11:44 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > SPRING WG, > > Conflict resolution is an important problem to solve and it is important = to > Standardize this draft. > > I generally support the draft but have a few major comments which I hope > the authors will work on. > > > 1.Conflict resolution and forwarding > > Section 3.4 has the statement > "Active Entries in the database may be used in forwarding." > > This is a very loose statement which does not enforce > implementations to program the forwarding plane > with the active database entries. > This does not ensure traffic drops are minimized. > [Les:] Conflict resolution is only determining which entries are eligible t= o be used in forwarding. This does not mean that all "active" entries will = be used . The most obvious example (but not the only possible one) of this = is an SRMS entry that is associated with a prefix which is not actually rea= chable. So the language in the draft is intentional and is correct. The language in the draft is ambiguous and it does not help achi= eve consistent forwarding behavior across implementations. Prefixes that are not reachable may not be used in fo= rwarding which is acceptable but the draft does not mandate that the reacha= ble prefixes which are active MUST be programmed. Normative language is necessary in = the draft w.r.t using active entries in forwarding. > The Forwarding plane programming aspects are completely missi= ng in > the document. > A separate section is needed which describes the different as= pects > of programming the forwarding plane. [Les:] This is NOT in scope for this draft. If you want a description of ho= w SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpl= s. The point I am bringing up here is not how SR MPLS forwarding wo= rks. It is w.r.t to programming the forwarding plane when there is a confli= ct. The abstract section has below statement "In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required." If the draft is not going to address the forwarding plane detail w.r.t conf= licting entries it is definitely not meeting the The objective described above. Take an example of a conflict (192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0) SID 200 has been assigned to 192.0.2.1/32 by the first advertisement. The second advertisement assigns SID 200 to 192.0.2.222/32. In this case after applying the preference rules (192, 192.0.2.1/32, 200, 1, 0, 0) Becomes active entry. As per the text in the draft," it may be used in forwarding" so some implem= entations May choose to program forwarding plane and some may not which does not give= a consistent forwarding behavior Across implementations. > > 2. Protocol independent resolution and impact on network migrations > In case of network migration from one protocol to other for = ex: OSPF- > SR to ISIS-SR, > it is useful to associate protocol preferences on a local no= de to the SID > advertisement > and feed into the conflict resolution. This would make sure t= he > conflicts will always > have a winner which is an advertisement from protocol with > preferred admin-distance. > > There is need for introducing another preference value specif= ic to > protocol preference > and make it the top rule in the preference rule hierarchy. > [Les:] "admin distance" is a locally defined preference which is not advert= ised. It is therefore not possible to include it as a parameter in an algor= ithm which requires a consistent answer on all nodes throughout the network= . In migration cases, topologies across two different protocols a= re not congruent causing inconsistent behavior. Using admin-distance as an input parameter keeps the= conflict resolution with-in the protocol and guarantees Consistent behavior across all the nodes correspondin= g to that protocol. The drafts tries to address this scenario partially be= tween IGP and BGP by suggesting preference values. But that does not solve = the Problem between two different IGPs. > This would also solve the issue of MT-ID numbers being differ= ent in > different protocols > as the SIDs would be compared within a protocol advertisement= . [Les:] I do not understand what relationship you see between "protocol pref= erence" and "MT-ID". MT-ID values are scoped by the protocol which uses them. For example, OSPF= v2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is theref= ore possible for non-matching MTIDs to be used by different protocols when = advertising routes for the same physical topology. This is why the draft's = use of "topology" is not as MTID but rather as a locally scoped identifier.= From Section 3: " Note: Topology is a locally scoped identifier assigned by each router. Although it may have an association with Multitopology Identifiers (MTID) advertised by routing protocols it is NOT equivalent to these identifiers. MTIDs are scoped by a given routing protocol. MTID ranges are protocol specific and there may be standardized protocol specific MTID assignments for topologies of a specific type (e.g., an AFI specific topology). As mapping entries can be sourced from multiple protocols it is not possible to use a network scoped identifier for a topology when storing mapping entries in the local database." Topology is then used to detect different scopes for a mapping entry - whic= h may result in a SID conflict if the same SID is used in different topolog= ies, but it cannot be used as a tiebreaker since its value is local and any= preference (e.g., higher value wins) is not guaranteed to result in consi= stent answers on all nodes in the network. Which is why we have Section 3.3= Rule #8: "8. If topology IDs are NOT identical both entries MUST be ignored" Lets keep this discussion on-hold until we decide on the protoco= l preference and migration issues. > > 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF= areas, > It's possible that the > conflicts are not visible in entire domain but are visible only on t= he border > router as the border routers > have the database of both domains. > The conflict resolution preference Rules should be enhanced to includ= e the > Level information in the preference rule. > A new parameter called sub-domain should be defined. > > One could propose using existing SRMS prefere= nce values > and assigning prefixes with preference values > based on levels they are advertised in. This introduces more = complex > configuration requirements on the > network. The objective of this draft is to achieve consistent > behaviours in case of misconfigurations and > introducing more configurations as a solution does not help. > > > Based on the Advertisement originated in ISIS= Level or OSPF > area below values are defined. > > Level 1 , non-zero OSPF area =3D1 > Level 2, OSPF Area 0 =3D 2 > Non IGPs set subdomain =3D 0 > > Preference al= gorithm is changed as > > 1. Higher protocol preference wins [Les:] I have explained above why protocol preference cannot be used. > 2. smaller sub-domain wins > 3. Higher srms preference value wins > 4. Smaller range wins > 5.IPv6 entry wins over IPv4 entry > 6.Longer prefix length wins > 7.Smaller starting address (considered as an unsigned integer > value) wins > 8.Smaller algorithm wins > 9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. > since the all these rules are applied > within protocol it's = safe to compare topology IDs [Les:] No - it isn't - as explained above. > 10. Smaller starting SID wins > [Les:] SIDs are assigned either by the node(s) originating the prefix reach= ability advertisement or by SRMS advertisements. The latter are level/area = agnostic - and even you are agreeing that we should not change that. There is then no reason for the SID to be altered as it is advertised into = different areas. Which leads us to the conclusion that SIDs are not level/= area specific. If your concern is that border routers who may have more entries in their S= ID database than intra-area routers may come to a different conclusion as r= egards conflicts - I agree with you - but I do not believe your proposal re= solves the problem. Consider the following simple topology: A1-----A2------B2-----B1 All nodes run IS-IS. A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100 A2 is a Level-1-2 router in Area A B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100 B2 is a Level-1-2 router in Area B If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we hav= e the following SID databases on the four routers: A1 1.1.1.1/32 100 A2 1.1.1.1/32 100 2.2.2.2/32 100 B1 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 Here are the active entries on each node comparing the two algorithms Node Draft Algorithm Shraddha Algorithm A1 1.1.1.1/32 100 1.1.1.1/32 100 A2 1.1.1.1/32 100 1.1.1.1/32 100 B1 2.2.2.2/32 100 2.2.2.2/32 100 B2 1.1.1.1/32 100 2.2.2.2/32 100 There is a tradeoff here between being able to forward some inter-area traf= fic entering the network via the L2 sub-domain but impacting some intra-are= a traffic vs being able to forward all intra-area traffic but no inter-are= a traffic. Not clear which strategy is "better" - but it is clear that neither strateg= y eliminates all issues. Given that the same SID database will NOT exist on= all routers in multi-area deployments some risk exists and cannot be total= ly eliminated. I do agree that we should try to minimize the use of conflicting SIDs for i= nter-area traffic. What is lacking in the draft is a statement that conflic= ting SIDs should not be leaked out of an area. I will work on a statement i= n the draft to make that point clear. Not leaking the conflicting SIDs makes sense. But Even if the co= nflicting SIDs are not leaked across boundaries, there is still a possibili= ty that inter-area/intra-area traffic gets misforwarded at the area boundar= y. This issue can cause potential security risks as the traffic can get del= ivered to unintended node.The best option is to ignore both conflicting ent= ries when they belong to different area/level 1. Higher protocol preference wins 2. If the entries belong to different sub-domains ignore both entries 3. Higher srms preference value wins 4. Smaller range wins 5.IPv6 entry wins over IPv4 entry 6.Longer prefix length wins 7.Smaller starting address (considered as an unsigned integer value) wins 8.Smaller algorithm wins 9. Smaller topology Id 10. Smaller starting SID wins Thanx for bringing this issue up. Les > > > Rgds > Shraddha > > -----Original Message----- > From: Martin Horneffer [mailto:maho@nic.dtag.de] > Sent: Friday, July 14, 2017 8:22 PM > To: spring@ietf.org > Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolut= ion > > Strong support from me, too. > > From an operator's point of view this is really needed. > > Best regards, Martin > > > Am 10.07.17 um 14:58 schrieb Martin Vigoureux: > > > > WG, > > > > We are half-way through the WG Last Call and I am very surprised to > > only see a single answer to it. > > > > I am not sure I'll move this forward with only silence as support. > > > > -m > > > > Le 29/06/2017 =E0 15:28, Martin Vigoureux a =E9crit : > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-spring-conflict-resolution-04 [1] which is considered > >> mature and ready for a final working group review. > >> > >> =A4 Please read this document if you haven't read the most recent > >> version yet, and send your comments to the list, no later than *21st > >> of July*. > >> Note that this is *not only* a call for comments on the document; it > >> is also a call for support (or not) to publish this document as a > >> Proposed Standard RFC. > >> > >> =A4 *Coincidentally*, we are also polling for knowledge of any IPR tha= t > >> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR > >> has been disclosed in compliance with IETF IPR rules (see RFCs 3979, > >> 4879, > >> 3669 and 5378 for more details). > >> > >> If you are listed as an Author or Contributor of > >> draft-ietf-spring-conflict-resolution-04 please respond to this email > >> and indicate whether or not you are aware of any relevant IPR. > >> > >> Note that, as of today, no IPR has been disclosed against this > >> document or its earlier versions. > >> > >> Thank you, > >> Martin > >> > >> [1] > >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio > >> n/ > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > >> > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --_000_1fa1478b8945402eacf9acfd3a71b133XCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Shraddha –<= /o:p>

 

All the rules defined = in the draft are based on advertised values – which means if two node= s have the same database and use the same set of rules they will reach the = same decision as regards conflict resolution.

You cannot improve upo= n this by introducing a new rule based upon a value (protocol administrativ= e distance) which is neither guaranteed to be the same on all nodes nor adv= ertised. The only thing this accomplishes is to introduce the potential for  further inconsistency.<= /span>

 

If we cannot agree on = this, then all the rest of the details discussed below do not matter.<= /o:p>

 

There is an important = point – which the draft does explicitly state in Section 3.7:

 

“In order to obt= ain consistent active entries all nodes in a network

   MUST have= the same mapping entry database.”

 

The productive part of= this thread is to highlight the ways in which database inconsistency can o= ccur. This cannot be completely eliminated, but we can minimize this in a n= umber of ways:

 

1)Reemphasize that a S= ID is a property of the prefix – NOT the protocol which advertises it=

 

This is fundamental to= the SR architecture and is consistent with the way SIDs are used in the fo= rwarding plane. And it will eliminate the possibility that two intra-area p= rotocols use different SIDs for the same prefix.

 

2)Reduce the prolifera= tion of “inactive” intra-area SIDs to other areas.

 

While this is desirabl= e, as Bruno noted in his recent reply, there is danger for oscillation if n= ot done carefully. I am still thinking about how to correctly specify this.=

 

3)Perhaps the draft wo= uld benefit from some additional discussion of the ways in which inconsiste= nt databases can occur and what consequences they have.

(Bruno – I think= this is what you are suggesting in your reply).

 

I will also look into = this.

 

   Les<= /o:p>

 

 

 

From: Shraddha= Hegde [mailto:shraddha@juniper.net]
Sent: Monday, July 31, 2017 10:27 AM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Les,=

 

When the protocol pref= erence is different across different nodes OSPF and ISIS do not guarantee t= hat there would not be traffic loops/drops.

The misconfigurations = can cause traffic loops when the different protocols are active on differen= t nodes even without SR so I don’t see a point

In bringing up such a = case for comparison.

 

Lets keep the solution= to the problem aside for a moment. Do you agree that the draft  algor= ithm in current form has potential issues

When database is not c= onsistent across all nodes? Do you think this is a problem we should try to= solve?

 

Pls see inline for det= ails…

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Saturday, July 29, 2017 3:48 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha –<= /o:p>

 

Protocol preference (c= ommonly known as admin distance) is a locally configured value which is not= advertised. Therefore there is no way for one node to know what preference= another node has assigned to different protocols. If admin distance is used as part of the conflict resolution al= gorithm there is therefore no way to guarantee consistency on different nod= es.  I have pointed this out previously – you have not acknowled= ged this.

 

Let’s use your e= xample below  - transitioning a network from OSPF to IS-IS – to = show how using admin distance in the conflict resolution algorithm results = in inconsistency.

 

Consider the following= simple network:

 

A---B---C---D

 

Node A originates the = prefix 1.1.1.1/32.

The network is using O= SPF and OSPF is advertising SID 100 for 1.1.1.1. All nodes use SID 100 in t= heir forwarding planes.

 

The customer wants to = transition to IS-IS, and so starts configuring IS-IS on each node, but make= s sure that initially  the admin distance assigned to IS-IS is greater= than (less preferred) than that of OSPF.

In configuring IS-IS t= he customer makes a mistake and assigns SID 200 to 1.1.1.1.  (This pre= sumes a protocol centric model for configuring SIDs – which I do not = recommend – but let’s ignore that for now.)

 

The customer is now re= ady to switch the network to IS-IS and starts to do so by changing the admi= n distance of IS-IS on Node D to be more preferred.

Using your proposal, N= ode D would now choose SID 200 as the Active SID for prefix 1.1.1.1.

But on Node C, OSPF is= still the more preferred protocol, so on Node C SID 100 is being used for = 1.1.1.1.

<Shraddha> As I poin= ted out different protocol being active on different nodes should be operat= or’s responsibility and is not addressed

    &n= bsp;            = ;      Even when SR is not enabled.

    &n= bsp;            = ; 

    &n= bsp;            = ;      Whereas, it is important to make sure = during migration when only a few nodes have ISIS enabled, it does not impac= t OSPF.

    &n= bsp;            = ;       The draft algorithm does not graceful= ly handle this and makes migrations much more painful by affecting the runn= ing network

    &n= bsp;            = ;        Due to misconfigs in the new pr= otocol.

 

As soon as the admin d= istance change is made on Node D, the label associated with SID 200 will be= programmed in forwarding to send traffic addressed to 1.1.1.1 via Node C.<= o:p>

But in Node C’s = forwarding plane SID 100 is being used, so when the packet arrives at Node = C it will get dropped.

 

Contrast that with the= behavior  when using algorithm currently defined in the draft. In the= presence of the two conflicting advertisements:

 

(192, 1.1.1.1/32, 100,= 1, 0, 0)

(192, 1.1.1.1/32, 200,= 1, 0, 0)

 

SID 100 will be declar= ed the winner (Rule #7: Lower SID wins)

This will be true rega= rdless of which protocol is the “best” at any moment in time on= any node. So even when IS-IS becomes the winning protocol on Node D the fo= rwarding plane continues to use SID 100 on all nodes. Therefore, forwarding is not compromised when transitioning from one proto= col to another.

<Shraddha> You have = chosen a situation that is favoring the algorithm in the draft.<= /span>

    &n= bsp;            = ;      Consider

    &n= bsp;            = ;        (192, 1.1.1.1/32, 200, 1, = 0, 0)  >>>>>>>>>>>>OSPF=

    &n= bsp;            = ;        (192, 1.1.1.1/32, 100, 1, 0, 0)=   >>>>>>>>>>>>ISIS

    &n= bsp;            = ;      Consider when the customer has configured I= SIS on only a few nodes. On some nodes ISIS advertisement wins and uses 100= to forward but

    &n= bsp;            = ;      Gets dropped on next node as ISIS isn&= #8217;t running .

 

 

Of course, a far bette= r strategy is to make SID configuration independent of the protocol. Then w= hen introducing a new protocol both protocols would obtain and advertise th= e same SID value for the same prefix and the problem state described above would simply never occur.=

 

<Shraddha> There are= so many nuances to migration. One protocol doesn’t behave same as th= e other simply because these are two different implementations and would ha= ve some different behaviors. It is always a best practice to keep the new protocol getting configured separate from the exi= sting protocol, bring up the new protocol , verify all is well and then swi= tchover to new protocol on all nodes. In this regard some may prefer keepin= g the SIDs advertised in two protocols separate and so its important to address the case when different SIDs are = advertised in the protocol.

 

HTH clarify why your s= uggestion is not viable.

 

   Les<= /o:p>

 

 

 

From: Shraddha= Hegde [mailto:shraddha@juniper.net= ]
Sent: Thursday, July 27, 2017 8:31 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Thanks for the respons= e.

 

   It is imp= ortant  to keep the network functioning correctly in case of transitio= ning from

   one proto= col to the other.

  

   Let = us assume a case of OSPF SR network transitioning to ISIS SR network.<= /o:p>

   Most typi= cal transitioning technique is ships in the night where both protocols will= be

   enab= led in the network with OSPF having better preference and the issue in ISIS= routing do

   not affec= t the traffic. Once the ISIS deployment is complete, the traffic will be sw= itched

   to ISIS b= y changing preference.

  

   In c= ase of OSPF-SR transitioning to ISIS SR, because of the conflict resolution

   rule= s that the conflicts are protocol independent, it is possible that config m= istakes in ISIS

   will brin= g down the routes in OSPF. The ISIS topology and OSPF topology is not expec= ted to be congruent

   during tr= ansition,

   so the co= nflicts seen on each node combining the two views will not be similar.

   This= has potential to cause routing loops/ traffic drops in the network.

  

   I su= ggest to add the protocol-preference as one of the parameters in the prefer= ence algorithm

   with= this being on the top of the list.

   The resul= tant conflict resolution will be consistent on ISIS topology and OSPF topol= ogy

  and is the= best suited model for ships in the night transitions.

 

Pls see inline for oth= er responses.

 

Rgds=

Shraddha

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <shrad= dha@juniper.net>; spring@ietf.org
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-re= solution

 

Shraddha -

 

Thanx for the comments - responses inline.

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegd= e

> Sent: Thursday, July 20, 2017 11:44 PM<= /o:p>

> To: sprin= g@ietf.org

> Subject: Re: [spring] WG Last Call for draft= -ietf-spring-conflict-resolution

>

> SPRING WG,

>

> Conflict resolution is an important problem = to solve and it is important to

> Standardize this draft.

>

> I generally support the draft but have a few= major comments which I hope

> the authors will work on.

>

>

>  1.Conflict resolution and forwarding

>

>       &nb= sp;     Section 3.4 has the statement

>       &nb= sp;     "Active Entries in the database may be use= d in forwarding."

>

>       &nb= sp;      This is a very loose statement which does= not enforce

> implementations to program the forwarding pl= ane

>        &n= bsp;    with the active database entries.

>        &n= bsp;    This does not ensure traffic drops are minimized.

>

[Les:] Conflict= resolution is only determining which entries are eligible to be used in fo= rwarding. This does not mean that all "active" entries will be us= ed . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix wh= ich is not actually reachable. So the language in the draft is intentional = and is correct.

<Shraddha&= gt; The language in the draft is ambiguous and it does not help achieve con= sistent forwarding behavior across implementations.

  &= nbsp;           &nbs= p;       Prefixes that are not reachable may = not be used in forwarding which is acceptable but the draft does not mandat= e that the reachable prefixes which are active

  &= nbsp;           &nbs= p;     MUST be programmed. Normative language is necess= ary in the draft w.r.t using active entries in forwarding.

 

 

>        &n= bsp;    The Forwarding plane programming aspects are complet= ely missing in

> the document.

>        &n= bsp;    A separate section is needed which describes the dif= ferent aspects

> of programming the forwarding plane.

 

[Les:] This is NOT in scope for this draft.= If you want a description of how SR MPLS forwarding works please see draft= -ietf-spring-segment-routing-mpls.

 

<Shraddha&= gt; The point I am bringing up here is not how SR MPLS forwarding works. It= is w.r.t to programming the forwarding plane when there is a conflict.

  &= nbsp;           &nbs= p;       

The abstract = section has below statement

 

“In cases where the

   information advertised by a given protocol instance is ei=
ther


   internally inconsistent or conflicts with advertisements =
from another


   protocol instance a means of achieving consistent forward=
ing behavior


   in the network is required.”


 


If the draft is not going to address =
the forwarding plane detail w.r.t conflicting entries it is definitely not =
meeting the


The objective described above.


 

Take an example of a conflict


(192, 192.0.2.1/32, 200, 1, 0, 0)


   (192, 192.0.2.222/32, 20=
0, 1, 0, 0)


   SID 200 has been assigne=
d to 192.0.2.1/32 by the


   first advertisement.


   The second advertisement=
 assigns SID 200 to 192.0.2.222/32.


 

In this case after applying the prefe=
rence rules


(192, 192.0.2.1/32, 200, 1, 0, 0)


 Becomes active entry.


 

As per the text in the draft,” =
it may be used in forwarding” so some implementations


May choose to program forwarding plan=
e and some may not which does not give a consistent forwarding behavior


Across implementations.


 

 


 


 


> 


> 2.  Protocol independent resolution and=
 impact on network migrations


>       &nb=
sp;      In case of network migration from one pro=
tocol to other for ex: OSPF-


> SR to ISIS-SR,


>       &nb=
sp;      it is useful to associate protocol prefer=
ences on a local node to the SID


> advertisement


>        &n=
bsp;    and feed into the conflict resolution. This would ma=
ke sure the


> conflicts will always


>        &n=
bsp;    have a winner which is an advertisement from protoco=
l with


> preferred admin-distance.


> 


>        &n=
bsp;    There is need for introducing another preference val=
ue specific to


> protocol preference


>        &n=
bsp;    and make it the top rule in the preference rule hier=
archy.


> 


 =



[Les:] "admin=
 distance" is a locally defined preference which is not advertised. It=
 is therefore not possible to include it as a parameter in an algorithm whi=
ch requires a consistent answer on all nodes throughout
 the network.


 


<Shraddha>  In migration c=
ases, topologies across two different protocols are not congruent causing i=
nconsistent behavior.


      &=
nbsp;           &nbs=
p;    Using admin-distance as an input parameter keeps the c=
onflict resolution with-in the protocol and guarantees


      &=
nbsp;           &nbs=
p;   Consistent behavior across all the nodes corresponding to th=
at protocol.


 

      &=
nbsp;           &nbs=
p;  The drafts tries to address this scenario partially between I=
GP and BGP by suggesting preference values. But that does not solve the


Problem between two different IGPs. <=
o:p>


 

 


>        &n=
bsp;    This would also solve the issue of MT-ID numbers bei=
ng different in


> different protocols


>        &n=
bsp;    as the SIDs would be compared within a protocol adve=
rtisement.


 


[Les:] I do not understand what relationshi=
p you see between "protocol preference" and "MT-ID".


MT-ID values are scoped by  the protoc=
ol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS =
supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to=
 be used by different protocols when advertising
 routes for the same physical topology. This is why the draft's use of &quo=
t;topology" is not as MTID but rather as a locally scoped identifier. =
>From Section 3:


 


" Note: Top=
ology is a locally scoped identifier assigned by each

   rou=
ter.  Although it may have an association with Multitopology


   Ide=
ntifiers (MTID) advertised by routing protocols it is NOT


   equ=
ivalent to these identifiers.  MTIDs are scoped by a given routing


   pro=
tocol.  MTID ranges are protocol specific and there may be<=
/i>


   sta=
ndardized protocol specific MTID assignments for topologies of a=



   spe=
cific type (e.g., an AFI specific topology).  As mapping entries<=
/o:p>


   can=
 be sourced from multiple protocols it is not possible to use a<=
/i>


   net=
work scoped identifier for a topology when storing mapping entries


   in =
the local database."


 


Topology is then used to detect different s=
copes for a mapping entry - which may result in a SID conflict if the same =
SID is used in different topologies, but it cannot be used as a tiebreaker =
since its value is local and any preference
 (e.g., higher value wins)  is not guaranteed to result in consistent =
answers on all nodes in the network. Which is why we have Section 3.3 Rule =
#8:


 


   &qu=
ot;8.  If topology IDs are NOT identical both entries MUST be ignored&=
quot;


<Shraddha> Le=
ts keep this discussion on-hold until we decide on the protocol preference =
and migration issues.


 


> 


> 3. In case of hierarchical IGP networks with=
 multiple ISIS Levels or OSPF areas,


> It's possible that the


>      conflicts are =
not visible in entire domain but are visible only on the border<=
/p>

> router as the border routers


>      have the datab=
ase of both domains.


>     The conflict resolut=
ion preference Rules should be enhanced to include the


> Level information in the preference rule.


>     A new parameter call=
ed sub-domain should be defined.


> 


>        &n=
bsp;            =
;        One could propose using existin=
g SRMS preference values


> and assigning prefixes with preference value=
s


>        &n=
bsp;    based on levels they are advertised in. This introdu=
ces more complex


> configuration requirements on the=



>        &n=
bsp;    network. The objective of this draft is to achieve c=
onsistent


> behaviours in case of misconfigurations and<=
o:p>


>        &n=
bsp;    introducing more configurations as a solution does n=
ot help.


> 


> 


>        &n=
bsp;            =
;        Based on the Advertisement orig=
inated in ISIS Level or OSPF


> area below values are defined.

> 


>        &n=
bsp;            =
;        Level 1 , non-zero OSPF area =
=3D1


>        &n=
bsp;            =
;        Level 2, OSPF Area 0 =3D 2=



>        &n=
bsp;            =
;        Non IGPs set subdomain =3D 0


> 


>        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;  Preference algorithm is changed as


> 


>     1. Higher protocol p=
reference wins


 


[Les:] I have e=
xplained above why protocol preference cannot be used.


 


>    2. smaller sub-domain wins=



>     3. Higher srms prefe=
rence value wins


>     4. Smaller range win=
s


>     5.IPv6 entry wins ov=
er IPv4 entry


>     6.Longer prefix leng=
th wins


>     7.Smaller starting a=
ddress (considered as an unsigned integer


>        va=
lue) wins


>     8.Smaller algorithm =
wins


>     9. Smaller topology =
Id wins >>>>>>>>>>..Moved above SID compariso=
n.


> since the all these rules are applied


>        &n=
bsp;            &nbs=
p;            &=
nbsp;           &nbs=
p;      within protocol it's safe to compare =
topology IDs


[Les:] No ̵=
1; it isn’t – as explained above.


>     10. Smaller starting=
 SID wins


> 


[Les:] SIDs are=
 assigned either by the node(s) originating the prefix reachability adverti=
sement or by SRMS advertisements. The latter are level/area agnostic - and =
even you are agreeing that we should
 not change that.


There is then n=
o reason for the SID to be altered as it is advertised into different areas=
.  Which leads us to the conclusion that SIDs are not level/area speci=
fic.


 


If your concern=
 is that border routers who may have more entries in their SID database tha=
n intra-area routers may come to a different conclusion as regards conflict=
s - I agree with you - but I do not
 believe your proposal resolves the problem.


Consider the fo=
llowing simple topology:


 


A1-----A2------=
B2-----B1


 


All nodes run I=
S-IS.


A1 is a Level-1=
 router in Area A. It advertises: 1.1.1.1/32 SID 100<=
/b>


A2 is a Level-1=
-2 router in Area A


 


B1 is a Level-1=
 router in Area B. It advertises: 2.2.2.2/32 SID 100<=
/b>


B2 is a Level-1=
-2 router in Area B


 


If Level 1 rout=
es are leaked into Level 2 but NOT down into Level 1, we have the following=
 SID databases on the four routers:


 








A1<=
/p>




1.1.1.1/32 100








A2<=
/p>




1.1.1.1/32 100


2.2.2.2/32 100








B1<=
/p>




2.2.2.2/32 100








B2<=
/p>




1.1.1.1/32 100


2.2.2.2/32 100








 


 


Here are the activ=
e entries on each node comparing the two algorithms

 








Node




Draft Algorithm<=
/o:p>




Shraddha Algorithm








A1<=
/p>




1.1.1.1/32 100




1.1.1.1/32 100








A2<=
/p>




1.1.1.1/32 100




1.1.1.1/32 100








B1<=
/p>




2.2.2.2/32 100




2.2.2.2/32 100








B2<=
/p>




1.1.1.1/32 100




2.2.2.2/32 100








 


There is a trad=
eoff here between being able to forward some inter-area traffic entering th=
e network via the L2 sub-domain but impacting some intra-area traffic =
 vs being able to forward all intra-area
 traffic but no inter-area traffic.


Not clear which=
 strategy is “better” – but it is clear that neither stra=
tegy eliminates all issues. Given that the same SID database will NOT exist=
 on all routers in multi-area deployments some risk exists
 and cannot be totally eliminated.


 


I do agree that=
 we should try to minimize the use of conflicting SIDs for inter-area traff=
ic. What is lacking in the draft is a statement that conflicting SIDs shoul=
d not be leaked out of an area. I will
 work on a statement in the draft to make that point clear.


 


<Shraddha> Not leaking the conf=
licting SIDs makes sense. But Even if the conflicting SIDs are not leaked a=
cross boundaries, there is still a possibility that inter-area/intra-area t=
raffic gets misforwarded at the area boundary. This issue can cause potenti=
al security risks as the traffic can get delivered to unintended node.The b=
est option is to ignore both conflicting entries when they belong to differ=
ent area/level


 

     1. Higher pr=
otocol preference wins


    2. If the entries =
belong to different sub-domains ignore both entries


     3. Higher sr=
ms preference value wins


     4. Smaller r=
ange wins


     5.IPv6 entry=
 wins over IPv4 entry


     6.Longer pre=
fix length wins


     7.Smaller st=
arting address (considered as an unsigned integer=



      &=
nbsp; value) wins


     8.Smaller al=
gorithm wins


     9. Smaller t=
opology Id 


    10. Smaller s=
tarting SID wins


 

 


 


Thanx for bring=
ing this issue up.


 


  &nb=
sp; Les


 


> 


> 


> Rgds


> Shraddha


> 


> -----Original Message-----


> From: Martin Horneffer [mailt=
o:maho@nic.dtag.de]


> Sent: Friday, July 14, 2017 8:22 PM


> To: spring@ietf.org=



> Subject: Re: [spring] WG Last Call for draft=
-ietf-spring-conflict-resolution


> 


> Strong support from me, too.


> 


>  From an operator's point of view this =
is really needed.


> 


> Best regards, Martin


> 


> 


> Am 10.07.17 um 14:58 schrieb Martin Vigoureu=
x:


> >


> > WG,


> >


> > We are half-way through the WG Last Cal=
l and I am very surprised to


> > only see a single answer to it.


> >


> > I am not sure I'll move this forward wi=
th only silence as support.


> >


> > -m


> >


> > Le 29/06/2017 =E0 15:28, Martin Vigoure=
ux a =E9crit :


> >> Hello Working Group,


> >>


> >> This email starts a Working Group L=
ast Call on


> >> draft-ietf-spring-conflict-resoluti=
on-04 [1] which is considered


> >> mature and ready for a final workin=
g group review.


> >>


> >> =A4 Please read this document if yo=
u haven't read the most recent


> >> version yet, and send your comments=
 to the list, no later than *21st


> >> of July*.


> >> Note that this is *not only* a call=
 for comments on the document; it


> >> is also a call for support (or not)=
 to publish this document as a


> >> Proposed Standard RFC.

> >>


> >> =A4 *Coincidentally*, we are also p=
olling for knowledge of any IPR that


> >> applies to draft-ietf-spring-confli=
ct-resolution, to ensure that IPR


> >> has been disclosed in compliance wi=
th IETF IPR rules (see RFCs 3979,


> >> 4879,


> >> 3669 and 5378 for more details).


> >>


> >> If you are listed as an Author or C=
ontributor of


> >> draft-ietf-spring-conflict-resoluti=
on-04 please respond to this email


> >> and indicate whether or not you are=
 aware of any relevant IPR.


> >>


> >> Note that, as of today, no IPR has =
been disclosed against this


> >> document or its earlier versions.


> >>


> >> Thank you,


> >> Martin


> >>


> >> [1]


> >> 
https://datatracker.i=
etf.org/doc/draft-ietf-spring-conflict-resolutio


> >> n/


> >>


> >> ___________________________________=
____________


> >> spring mailing list


> >> =
spring@ietf.org


> >> 
https://www.ietf.org/=
mailman/listinfo/spring


> >>


> >


> > _______________________________________=
________


> > spring mailing list


> > spring@ietf.org


> > 
https://www.ietf.org/=
mailman/listinfo/spring


> >


> 


> 


> ____________________________________________=
___


> spring mailing list


> spring@ietf.org


> 
https://www.ietf.org/=
mailman/listinfo/spring
--_000_1fa1478b8945402eacf9acfd3a71b133XCHALN001ciscocom_--